PEP 304 (was: Re: Any way to not create .pyc files?)

Bengt Richter bokr at oz.net
Sun Jun 26 15:18:35 EDT 2005


On Thu, 9 Jun 2005 18:12:35 -0500, Skip Montanaro <skip at pobox.com> wrote:

>
>    >> PEP 304 would have helped, but it appears to be deceased.  
>
>Just resting...
>
>FWIW, I reapplied it to my cvs sandbox the other day and plan to at least
>generate a new patch from that.  It's pretty much done, except...  Once upon
>a time, someone identified some problems for Windows with its multiple-root
>file system.  I've tried a couple times to dig it up, but have been
>unsuccessful.  If anyone can find it (or was the author, better yet), let me
>know.  At the very least I'd like to amend the PEP.  Ideally, I'd like to
>solve the problem and get PEP 304 going again.
>
Re multiple-root...

IMO it would be nice to have an optional way of running python so that all file system
paths would be normalized to Unix-style and platform-independent. On a windows
system, the model used by msys/MinGW could be used, where you can mount subtrees
per fstab and the "drives" wind up being /c/path for C:\path etc. And you
could potentially mount different file systems also, including /proc and /dev
synthetic things. On unix it could largely be pass-throughs, IWT, except for
mountable file system objects written in pure python which would probably need
some interfacing help.

This would also be a potential way of feeding/logging tests of software that
accesses the file system, using special mountable testing file systems.

It also lets you switch I/O sources and sinks with mounts that are external to
a particular python program being run.

Don't know how factorable all that is in python, but I would think the bulk
would be changes in os and hopefully pretty transparent elsewhere.

Regards,
Bengt Richter



More information about the Python-list mailing list