On Sat, Oct 13, 2012 at 2:27 AM, Ethan Furman firstname.lastname@example.org wrote:
Georg Brandl wrote:
Am 12.10.2012 14:45, schrieb Blake Hyde:
I'm a Python developer rather than a developer of Python, but I'd like to ask a question about this option (and implicitly vote against it, I suppose); if you specialize a method name, such as .pathjoin, aren't you implying that methods must be unambiguous even across types and classes? This seems negative. Even if .join is already used for strings, it also makes sense for this use case.
Of course different classes can have methods of the same name.
The issue here is that due to the similarity (and interchangeability) of path objects and strings it is likely that people get them mixed up every now and then, and if .join() works on both objects the failure mode (strange result from str.join when you expected path.join) is horribly confusing.
I don't understand the "horribly confusing" part. Sure, when I got them mixed up and ended up with a plain ol' string instead of a really cool Path it took a moment to figure out where I had made the error, but the traceback of "AttributeError: 'str' object has no attribute 'path'" left absolutely no room for confusion as to what the problem was.
Now, instead of retrieving an attribute, call str() and send the path name over a pipe or socket, or save it to a file. Instead of an immediate error, you'll get a bad path somewhere *else*, and have to track down where the data corruption came from (which not even be in the current process, or in a process that was even running on the current machine).
Making "+" and "Path.join" mean something different from what they mean when called on strings is, in the specific case of a path representation, far too likely to lead to data corruption bugs for us to be happy with allowing it in the standard library. This is one I think Jason Orendorff's original path.py got right, which is why my current preference is "just copy path.py and use / and Path.joinpath".