equivalent of Ruby's Pathname?

[Chris Rebert]

On Tue, Feb 9, 2010 at 4:38 AM, Steve Holden <steve at 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