Prev: [Off topic] Radian language
Next: Python 3 minor irritation
From: Carl Banks on 8 Feb 2010 19:26
On Feb 4, 7:10 pm, Sean DiZazzo <half.ital...(a)gmail.com> wrote:
> On Feb 3, 6:08 pm, alex23 <wuwe...(a)gmail.com> wrote:
>
>
>
> > On Feb 4, 8:47 am, Phlip <phlip2...(a)gmail.com> wrote:
>
> > > Yes, calling os.path.walk() and os.path.join() all the time on raw
> > > strings is fun, but I seem to recall from my Ruby days a class called
> > > Pathname, which presented an object that behaved like a string at
> > > need, and like a filesystem path at need. path + 'folder' would
> > > call .join() and insert the / correctly, for example.
>
> > > What's the best equivalent in Python-land?
>
> > It's no longer supported, but the 3rd party 'path' module used to be
> > the go-to module for this:
>
> > >>> from path import path
>
> > C:\Python26\lib\site-packages\path.py:32: DeprecationWarning: the md5
> > module is deprecated; use hashlib instead
> >   import sys, warnings, os, fnmatch, glob, shutil, codecs, md5>>> c = path('C:\\')
> > >>> c.listdir()
>
> > [path(u'C:\\AUTOEXEC.BAT'), path(u'C:\\boot.ini'), ...]>>> (c + 'python26').listdir()
>
> > [path(u'C:\\python26\\circuits.pth_disabled_for_egg'), path(u'C:\
> > \python26\\DLLs'), ...]>>> (c / 'python26').listdir()
>
> > [path(u'C:\\python26\\circuits.pth_disabled_for_egg'), path(u'C:\
> > \python26\\DLLs'), ...]
>
> > I've hand edited the results for brevity...
>
> > The module could do with some TLC to bring it up to date, but warning
> > aside it still seems to work fine under 2.6.
>
> > (From memory, I think the original author gave up when it became clear
> > it would never be integrated into the standard lib[1], which is a
> > shame, I think there's scope for a pathtools addition to the lib that
> > provides this level of convenience...)
>
> > There was also a PEP with another possible implementation:http://www.python.org/dev/peps/pep-0355/
>
> > Hope this helps.
>
> It's too bad that something like this can't be agreed to.  I used a
> homegrown module like this for a couple of years in my early days with
> python.  It was great, but I didn't know enough at the time to make it
> really useful.
>
> Why did Path() get rejected?  Is it the idea itself, or just the
> approach that was used?  What are the complaints?

I don't know if it was the reason it was rejected, but a seriously
divisive question is whether the path should be a subset of string.

Under ordinary circumstances it would be a poor choice for inheritance
(only a few string methods would be useful fot a pathname), but some
people were fiercely adamant that paths should be passable to open()
as-in (without having to explicity convert to string). IIRC, the guy
who maintained path wavered between subclassing and not subclassing
str. I don't remember if the idea of modifying open to accept path
objects came up.


Carl Banks
From: Phlip on 9 Feb 2010 00:21
Carl Banks wrote:

> I don't know if it was the reason it was rejected, but a seriously
> divisive question is whether the path should be a subset of string.

OMG that's nothing but the OO "circle vs ellipse" non-question. Glad
to see the Committee derailed a perfectly good library over such
sophistry.

> Under ordinary circumstances it would be a poor choice for inheritance
> (only a few string methods would be useful fot a pathname), but some
> people were fiercely adamant that paths should be passable to open()
> as-in (without having to explicity convert to string).

That's just silly. To be object-based, you should say path.open('r').
fopen() and its ilk are too 1960s...

My 5th Grade science teacher, one Eunice Feight, once expressed
chagrin for submitting a proposal to Readers' Digest, and getting it
accepted. She sold them the following sloka:

Don't be clever don't be witty
Or you'll wind up BEING the Committee!

--
Phlip
http://penbird.tumblr.com/
From: Gregory Ewing on 9 Feb 2010 01:55
Carl Banks wrote:
> I don't remember if the idea of modifying open to accept path
> objects came up.

It wouldn't just be open() that people would want modified --
it would be every other function that takes a pathname as
well.

I seem to recall another point of contention was whether
path objects should have methods for accessing the file
system (opening files, renaming them, etc.) or whether it
should confine itself to representing and manipulating
pathnames.

In any case, introducing any kind of path object at this
late stage of the language's development would result in
More Than One Way to represent pathnames, with neither of
them being the obvious choice.

--
Greg
From: Steve Holden on 9 Feb 2010 07:38
Phlip wrote:
> Carl Banks wrote:
>
>> I don't know if it was the reason it was rejected, but a seriously
>> divisive question is whether the path should be a subset of string.
>
> OMG that's nothing but the OO "circle vs ellipse" non-question. Glad
> to see the Committee derailed a perfectly good library over such
> sophistry.
>
That's nothing but the most arrant nonsense, as you would discover if
you took the trouble to read the discussion on python-dev instead of
jumping to conclusions.

>> Under ordinary circumstances it would be a poor choice for inheritance
>> (only a few string methods would be useful fot a pathname), but some
>> people were fiercely adamant that paths should be passable to open()
>> as-in (without having to explicity convert to string).
>
> That's just silly. To be object-based, you should say path.open('r').
> fopen() and its ilk are too 1960s...
>
What? Are you arguing for "myfile.txt".open('r') to be a valid Python
construct? If not then surely you can see that paths would require
different treatment from strings, which was the main thrust of the
discussion on the dev list.

I find it really irritating when the clueless come along and criticize
decisions made by the developers after thorough discussion. Not only do
decisions have to be made about how code is going to work (and work for
the next twenty years or so), but someone has to commit to maintaining
the code before it goes in (otherwise Python will be full of bit-rot).

To call your criticism ill-informed would be flattering it.

> My 5th Grade science teacher, one Eunice Feight, once expressed
> chagrin for submitting a proposal to Readers' Digest, and getting it
> accepted. She sold them the following sloka:
>
> Don't be clever don't be witty
> Or you'll wind up BEING the Committee!
>
Criticism isn't pretty
Specially when your logic's shitty.

regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
PyCon is coming! Atlanta, Feb 2010 http://us.pycon.org/
Holden Web LLC http://www.holdenweb.com/
UPCOMING EVENTS: http://holdenweb.eventbrite.com/

From: Chris Rebert on 9 Feb 2010 07:52
On Tue, Feb 9, 2010 at 4:38 AM, Steve Holden <steve(a)holdenweb.com> wrote:
> Phlip wrote:
>> Carl Banks wrote:
>>
>>> I don't know if it was the reason it was rejected, but a seriously
>>> divisive question is whether the path should be a subset of string.
>>
>> OMG that's nothing but the OO "circle vs ellipse" non-question. Glad
>> to see the Committee derailed a perfectly good library over such
>> sophistry.
>>
> That's nothing but the most arrant nonsense, as you would discover if
> you took the trouble to read the discussion on python-dev instead of
> jumping to conclusions.
>
>>> Under ordinary circumstances it would be a poor choice for inheritance
>>> (only a few string methods would be useful fot a pathname), but some
>>> people were fiercely adamant that paths should be passable to open()
>>> as-in (without having to explicity convert to string).
>>
>> That's just silly. To be object-based, you should say path.open('r').
>> fopen() and its ilk are too 1960s...
>>
> What? Are you arguing for "myfile.txt".open('r') to be a valid Python
> construct? If not then surely you can see that paths would require
> different treatment from strings, which was the main thrust of the
> discussion on the dev list.

Based on the context, I'm /pretty/ sure he was (implicitly) talking
about e.g. Path("myfile.txt").open('r').

Cheers,
Chris
--
http://blog.rebertia.com
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: [Off topic] Radian language
Next: Python 3 minor irritation