>> I also think the PEP is a great idea and proposes a solution to a real >> problem. But I also hear the 'directory clutter' argument and I'm really >> concerned too, having all these extra directories around (and quite a >> large number of them indeed!). > > Keep in mind that if you don't explicitly ask for the proposed feature, > you won't see any change at all. You need to run Python with the -R > switch, or set an environment variable. The average developer won't see > any clutter at all unless she is explicitly supporting multiple versions. > > > >> How about this scheme: >> >> 1. install python source files to a shared (among python installations) >> location /this/is/shared >> 2. when python X.Y imports a source file from /this/is/shared it will >> create pyc files in its private area /usr/lib/pythonX.Y/site-packages/ > > $ touch /usr/lib/python2.5/site-packages/STEVEN > touch: cannot touch `/usr/lib/python2.5/site-packages/STEVEN': Permission > denied > > There's your first problem: most users don't have write-access to the > private area.
True, I haven't thought about that (I should have though). > When you install a package, you normally do so as root, and > it all works. When you import a module and it gets compiled as a .pyc > file, you're generally running as a regular user. > > >> Time comparison would be between /this/is/shared/x.py and >> /usr/lib/pythonX.Y/site-packages/x.pyc, for instance. > > I don't quite understand what you mean by "time comparison". I meant the comparison of timestamps on .py and .pyc files in order to determine which is newer and if a recompilation should take place or not. > [...] >> In /usr/lib/pythonX.Y/site-packages there would be only pyc files with >> magic number matching python X.Y. > > Personally, I think it is a terribly idea to keep the source file and > byte code file in such radically different places. They should be kept > together. What you call "clutter" I call having the files that belong > together kept together. I see why you think so, it's reasonable, however there is compelling argument, I think, for the opposite view: namely to keep things separate. An average developer definitely wants easy access to .py files. However I see no good reason for having access to .pyc files. I for one have never inspected a .pyc file. Why would you want to have a .pyc file at hand? If we don't really want to have .pyc files in convenient locations because we (almost) never want to access them really, then I'd say it's a good idea to keep them totally separate and so make don't get in the way. >> So, basically nothing would change only the location of py and pyc files >> would be different from current behavior, but the same algorithm would >> be run to determine which one to load, when to create a pyc file, when >> to ignore the old one, etc. > > What happens when there is a .pyc file in the same location as the .py > file? Because it *will* happen. Does it get ignored, or does it take > precedence over the site specific file? > > Given: > > ./module.pyc > /usr/lib/pythonX.Y/site-packages/module.pyc > > and you execute "import module", which gets used? Note that in this > situation, there may or may not be a module.py file. > > >> What would be wrong with this setup? > > Consider: > > ./module.py > ./package/module.py > > Under your suggestion, both of these will compile to > > /usr/lib/pythonX.Y/site-packages/module.pyc I see the problems with my suggestion. However it would be great if in some other way the .pyc files could be kept out of the way. Granted, I don't have a good proposal for this. Cheers, Daniel -- Psss, psss, put it down! - http://www.cafepress.com/putitdown -- http://mail.python.org/mailman/listinfo/python-list
