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