http://en.wikipedia.org/wiki/List_of_mathematical_symbols#Symbols The + symbol means addition and union of disjoint sets. A path (including a fs path) is a set of links (for a fs path, a link is a folder name). Using the + symbols has a natural interpretation as concatenation of subpaths (sets) to for form a longer path (superset). The / symbol means the quotient of a group. It always returns a subgroup. When I see path1 / path2 I would expect it to return all paths that start by path2 or contain path2, not concatenation. The fact that string paths in Unix use the / to represent concatenation is accidental. That's just how the path is serialized into a string. In fact Windows uses a different separator. I do think a serialized representation of an object makes a good example for its abstract representation. Massimo On Oct 8, 2012, at 11:06 AM, Andrew McNabb wrote:
On Tue, Oct 09, 2012 at 12:03:55AM +1100, Steven D'Aprano wrote:
/ is a symbol that means whatever the class gives it. It isn't like __init__ or __call__ that have defined language semantics, and there is no rule that says that / means division. I'll grant you that it's a strong convention, but it is just a convention.
I'll grant you that the semantics of the __truediv__ method are defined by convention.
But it's just a name. __add__ doesn't necessarily perform addition, __sub__ doesn't necessarily perform subtraction, and __or__ doesn't necessarily have anything to do with either bitwise or boolean OR. Why should we insist that __*div__ (true, floor or just plain div) must only be used for numeric division when we don't privilege other numeric operators like that?
__add__ for strings doesn't mean numerical addition, but people find it perfectly natural to speak of "adding two strings," for example. Seeing `string1.__add__(string2)` is readable, as is `operator.add(string1, string2)`. Every other example of operator overloading that I find tasteful is analogous enough to the numerical operators to retain use the name.
Since this really is a matter of personal taste, I'll end my participation in this discussion by voicing support for Nick Coghlan's suggestion of a `join` method, whether it's named `join` or `append` or something else.
-- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas