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 / [EMAIL PROTECTED] / http://blog.ianbicking.org _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
