From: Phlip on 9 Feb 2010 09:00 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 9 Feb 2010 10:23 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 9 Feb 2010 17:28 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 9 Feb 2010 19:27 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 14 Feb 2010 15:39 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 |