Giovanni Bajo wrote:
> Guido van Rossum wrote:
>
>> OK. Pronouncement: PEP 355 is dead. The authors (or the PEP editor)
>> can update the PEP.
>>
>> I'm looking forward to a new PEP.
>
> It would be terrific if you gave us some clue about what is wrong in PEP355,
> so
> that the next guy does not waste his time. For instance, I find PEP355
> incredibly good for my own path manipulation (much cleaner and concise than
> the
> awful os.path+os+shutil+stat mix), and I have trouble understanding what is
> *so* wrong with it.
>
> You said "it's an amalgam of unrelated functionality", but you didn't say what
> exactly is "unrelated" for you.
Things the PEP 355 path object lumps together:
- string manipulation operations
- abstract path manipulation operations (work for non-existent filesystems)
- read-only traversal of a concrete filesystem (dir, stat, glob, etc)
- addition & removal of files/directories/links within a concrete filesystem
Dumping all of these into a single class is certainly practical from a utility
point of view, but it's about as far away from beautiful as you can get, which
creates problems from a learnability point of view, and from a
capability-based security point of view. PEP 355 itself splits the methods up
into 11 distinct categories when listing the interface.
At the very least, I would want to split the interface into separate abstract
and concrete interfaces. The abstract object wouldn't care whether or not the
path actually existed on the current filesystem (and hence could be relied on
to never raise IOError), whereas the concrete object would include the many
operations that might need to touch the real IO device. (the PEP has already
made a step in the right direction here by removing the methods that accessed
a file's contents, leaving that job to the file object where it belongs).
There's a case to be made for the abstract object inheriting from str or
unicode for compatiblity with existing code, but an alternative would be to
enhance the standard library to better support the use of non-basestring
objects to describe filesystem paths. A PEP should at least look into what
would have to change at the Python API level and the C API level to go that
route rather than the inheritance route.
For the concrete interface, the behaviour is very dependent on whether the
path refers to a file, directory or symlink on the current filesystem. For an
OO filesystem interface, does it really make sense to leave them all lumped
into the one class with a bunch of isdir() and islink() style methods? Or does
it make more sense to have a method on the abstract object that will return
the appropriate kind of filesystem info object? If the latter, then how would
you deal with the issue of state coherency (i.e. it was a file when you last
touched it on the filesystem, but someone else has since changed it to a
link)? (that last question actually lends strong support to the idea of a
*single* concrete interface that dynamically responds to changes in the
underlying filesystem).
Another key difference between the two is that the abstract objects would be
hashable and serialisable, as their state is immutable and independent of the
filesystem. For the concrete objects, the only immutable part of their state
is the path name - the rest would reflect the state of the filesystem at the
current point in time.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
