[Python-Dev] The path module PEP

[Ian Bicking]

Tony Meyer wrote:
> [Ian Bicking]
> 
>> If it were possible to use .join() for joining paths, I think I  
>> wouldn't mind so much.  But reusing a string method for something  
>> very different seems like a bad idea.  So we're left with .joinpath 
>> ().  Still better than os.path.join() I guess, but only a little.   I 
>> guess that's why I'm +1 on /.
> 
> 
> Why does reusing a string method for something very different seem  like 
> a bad idea, but reusing a mathematical operator for something  very 
> different seem like a good idea?  Path's aren't strings, so join () 
> seems the logical choice.  (There are also alternatives to  "joinpath" 
> if the name is the thing: add(), for example).

Paths are strings, that's in the PEP.

As an aside, I think it should be specified what (if any) string methods 
won't be inherited by Path (or will be specifically disabled by making 
them throw some exception).  I think .join() and __iter__ at least 
should be disabled.

>> Precedence in naming means something, and in this case all the  names 
>> have existed for a very long time (as long as Python?)  PEP 8  
>> encourages following naming precedence.  While I don't see a need  to 
>> match every existing function with a method, to the degree they  do 
>> match I see no reason why we shouldn't keep the names.  And I  see 
>> reasons why the names shouldn't be changed.
> 
> 
> PEP 8 encourages following naming precedence within a module, doesn't  
> it?  Guido has said that he'd like to have the standard library  tidied 
> up, at least somewhat (e.g. StringIO.StringIO ->  stringio.StringIO) for 
> Python 3000.  It would make it less painful if  new additions already 
> followed the plan.

I think the use of underscores or squished words isn't as bit a deal as 
the case of modules.  It's often rather ambiguous what a "word" really 
is.  At least in English word combinations slowly and ambiguously float 
towards being combined.  So abspath and abs_path both feel sufficiently 
inside the scope of PEP 8 that precedence is worth maintaining. 
rfc822's getallmatchingheaders method was going too far, but a little 
squishing doesn't bother me, if it is consistent (and it's actually 
easier to be consistent about squishing than underscores).

-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org