Barry Warsaw <barry <at> python.org> writes: > > When Python is being installed, either by a from-source 'make install' or by > the distro packager, then you'd expect the umask not to be insane. In the > latter case, it's a bug and in the former case you screwed up so you should be > able to delete and reinstall, or at the very least execute the same `find` > command that Python's own Makefile calls (in my branch) for 'make clean'. > > When you're installing packages, again, I would expect that the system > installer, or you via `easy_install` or whatever, would not have an insane > umask. Well, precisely. That's why I suggest that creating the __pycache__ directories be done *at install time* (or packaging time), and not via the core import machinery (that is, not at import time). That is, when you *know* you are the right user, with the right umask. Which also means that it can and probably should be pulled out of the core (and written in pure Python, which is also much more practical to maintain, test and debug). > I don't particularly like this much, because most people won't get the benefit > of it in a local dev environment. AFAICT it has no benefit in a local dev environment (apart from supposedly "cleaner" directories, which is not something anyone seems to consider a problem with the current CPythons). And again, this could be part of the distutils standard "setup.py install" (or "setup.py develop" with distutils2/distribute) if people care :) Regards Antoine.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4