[Python-ideas] PEP 428: poll about the joining syntax
Georg Brandl
g.brandl at gmx.net
Fri Oct 12 18:12:26 CEST 2012
More information about the Python-ideas mailing list
Fri Oct 12 18:12:26 CEST 2012
- Previous message: [Python-ideas] PEP 428: poll about the joining syntax
- Next message: [Python-ideas] PEP 428: poll about the joining syntax
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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. It's the same argument against the "+" operator. (Apart from the other downside that it will act differently depending on *two* objects, i.e. both operands.) In contrast, the "/" operator is not defined on strings, but on numbers, and the both the confusion likelihood and failure mode of mixing numbers and strings are much less severe. It's really kind of the same reason why integer floor division was awkward with "/", and has been changed to "//" in Python 3. Georg
- Previous message: [Python-ideas] PEP 428: poll about the joining syntax
- Next message: [Python-ideas] PEP 428: poll about the joining syntax
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-ideas mailing list