FWIW (and at risk of getting sidetracked), we can’t add directories to user-specific paths when installing as admin - Windows Installer just doesn’t support it (unless it’s been added since I last checked). In the default case, pip can install to system packages (which are per-user by default on Windows), so it turns out not to matter.
I’d be surprised if there was much in Tools/scripts worth moving to the stdlib.
+1
After a quick scan through https://github.com/python/cpython/pull/97675, it seems like at least some of these scripts are useful still (whether for getting something specific done or as good example code), even if CPython doesn’t need them. It would be good to preserve them publicly (other than in git history) before removing them from Tools/scripts.
How much work would it be to create a new repo (“old-scripts”?) under Python · GitHub where we would add these scripts? Would there be any downsides?
(If possible, it would be nice if we could preserve git history too. Is that hard to do?)
+1
Expanding the exercise from Tools/scripts to Tools/* makes sense. I expect we could circle back to the rest after Tools/scripts is done.
Can you please be more specific? Do you have examples?
Do you expect maintenance? Or do you want to archive the project as soon as it is created? Scripts are available in Python 3.11.
Tools/i18n is one of the directories that should probably be excluded if you decide to go with widening these removals to Tools/*. It’s mentioned in Python’s gettext documentation and one of the tools there - pygettext.py - even has some added benefits over similar tools such as xgettext - e.g. support for gettext calls inside f-strings. It uses tokenize module which is comparatively more fragile than using ast module but I would say that it still performs its purpose pretty well.
2 Likes
Good point. That’s probably sufficient. I separate repo isn’t needed.
Quite easy to preserve history. Just fork and run git filter-branch --subdirectory-filter Tools HEAD (SO answer).
Oh, I should probably do this for the Tools/demo directory which I preserved in gvanrossum/old-demos. I wouldn’t feel bad at all doing a git push -f there. (I wrote many of those demos so I feel particularly motivated to preserve them somewhere other than git history.)
We could add a new repo “cpython-attic” for such older scripts, modules
and similar code.
CVS used to have a feature called the “attic” where you could keep
old stuff, which is no longer needed, but may still serve some
purpose, even if it’s just software archeology. A useful feature,
which subsequent VCSes dropped for some reason.
Be aware that, these days, the manpage for git filter-branch warns
against its own use, and recommends the more robust
git-filter-repo · PyPI tool in its stead.
But yes, cleanly preserving revision history for only specific files
is quite doable when forking into a new repository.
3 Likes
A probably easier to maintain alternative would be having a separate
branch “attic” with only those archived parts of the source tree.
That way, history is maintained, but the code won’t get installed
anywhere and also not be part of the source dist.
2 Likes
You can use the “3.11” branch to get these scripts and demos.
2 Likes
Of course, and all the other past release branches 
But that’s not
the point. A new “attic” branch would not be subject to any release
cycles and simply be used to stash away older code - much like this
worked in CVS.
The code would still be easily accessible (without having to remember
in which release it was removed from the main branch) and could be
used as basis for forks outside the python org.
What’s more important: you get to keep the history for free and
without having to run git filter scripts.
For the record, we install pathfix.py to /usr/bin in python3-devel Fedora package, as we use the script when we build Python packages. If the script goes away, we will need to ship it differently.
I was sad to see pynche (“Punchie”) go!
It was a nice, simple demo of the capabilities of tkinter (IDLE is too hard for a beginner to have a go at understanding, so I used pynche as an example in my courses. My clients often don’t have any install rights, or internet is not available, so installing is not always possible.)
And it was actually a useful colour picker.
It’s still around: it was just moved to Barry Warsaw / pynche · GitLab
@barry: Maybe you should mention your repository in What’s New in Python 3.11?
1 Like
Good idea! (P.S. I pronounce it “pinch-ee” 
)
1 Like