From: Phlip on
Gregory Ewing wrote:

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

Then refer to the same argument against implicit type conversions in C+
+.

A ::std::string must call .c_str() to turn into a lowly char*, before
passing into a C function. Advocating for 8 characters of convenience
opens the risk of silent bugs at refactor time.

> 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 that case, the package I picked seems to have "erred" on the side
of programmer convenience.

Because the basic file operations (exist, stat, move/rename, copy,
open, chmod, unlink) come as a complete and whole kit, a class should
simply present that kit, insulating against filesystem differences.

> 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.

Ah, now we get down to the root of the problem. Because Python is so
stuck on the "one best way to do it" mentality, language bigotry
prevented the Committee from picking from among several equally valid
but non-best options. And after 20 years of growth, Python still has
no Pathname class. What a mature community! C-:

--
Phlip
http://c2.com/cgi/wiki?MoreliaViridis
From: Bruno Desthuilliers on
Phlip a �crit :
> Gregory Ewing wrote:
>
>> 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.
>
> Ah, now we get down to the root of the problem. Because Python is so
> stuck on the "one best way to do it"
> mentality, language bigotry
> prevented the Committee from picking from among several equally valid
> but non-best options.

You failed to actually _read_ what you're answering to. Try again. Using
your brain, this time.

From: Chris Rebert on
On Tue, Feb 9, 2010 at 6:00 AM, Phlip <phlip2005(a)gmail.com> wrote:
<snip>
> Ah, now we get down to the root of the problem. Because Python is so
> stuck on the "one best way to do it" mentality, language bigotry
> prevented the Committee from picking from among several equally valid
> but non-best options. And after 20 years of growth, Python still has
> no Pathname class. What a mature community! C-:

Committee? I think you have us confused with C++...

*wink*,
Chris
From: Sean DiZazzo on
On Feb 8, 2:36 pm, a...(a)pythoncraft.com (Aahz) wrote:
> In article <dcace5fc-5ae9-4756-942d-6da7da2f6...(a)s36g2000prh.googlegroups..com>,
> Sean DiZazzo  <half.ital...(a)gmail.com> wrote:
>
> >On Feb 3, 6:08=A0pm, alex23 <wuwe...(a)gmail.com> wrote:
>
> >> There was also a PEP with another possible implementation:
> >>http://www.python.org/dev/peps/pep-0355/
>
> >Why did Path() get rejected?  Is it the idea itself, or just the
> >approach that was used?  What are the complaints?
>
> You should search for the discussiona around it.
> --
> Aahz (a...(a)pythoncraft.com)           <*>        http://www.pythoncraft.com/
>
> import antigravity

I read the discussion, and there was definitely some going back and
forth on whether it should be sub-classed from string, but the
conversation just seemed to stop abruptly with no decision one way of
the other. Maybe I missed a thread.

I guess being dropped without a final go-ahead is just as good as a
formal no anyway.
From: Aahz on
In article <8fc356e0-f3ed-4a67-9b37-f21561cef4a5(a)p13g2000pre.googlegroups.com>,
Sean DiZazzo <half.italian(a)gmail.com> wrote:
>On Feb 8, 2:36=A0pm, a...(a)pythoncraft.com (Aahz) wrote:
>> In article <dcace5fc-5ae9-4756-942d-6da7da2f6...(a)s36g2000prh.googlegroups=
>.com>,
>> Sean DiZazzo =A0<half.ital...(a)gmail.com> wrote:
>>>
>>>Why did Path() get rejected? Is it the idea itself, or just the
>>>approach that was used? What are the complaints?
>>
>> You should search for the discussiona around it.
>
>I read the discussion, and there was definitely some going back and
>forth on whether it should be sub-classed from string, but the
>conversation just seemed to stop abruptly with no decision one way of
>the other. Maybe I missed a thread.
>
>I guess being dropped without a final go-ahead is just as good as a
>formal no anyway.

Not quite: because it was not rejected, someone who wants to shepherd the
process forward would likely be welcomed (even if it ends up with formal
rejection). I suggest starting by writing your own summary of the
previous discussion and see if the people involved agree that your
summary is reasonably accurate. Also check to see if the original PEP
writer wants to be involved or whether zie is willing to have you take
over.

Another good (and related) starting point would be to create a reasoning
favoring one side or the other that was not brought up in previous
discussion.
--
Aahz (aahz(a)pythoncraft.com) <*> http://www.pythoncraft.com/

"At Resolver we've found it useful to short-circuit any doubt and just
refer to comments in code as 'lies'. :-)"
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: [Off topic] Radian language
Next: Python 3 minor irritation