News for hackers. Stuff that matters.
Re:Python 3.5.0 by gh02t on Sunday September 13, 2015 @11:42AM (#10211729)
Doubt it. The @ symbol isn't implemented by default. It's just available as a syntactic element primarily for NumPy to use, though other libraries are free to use it as well.
Re:Python 3.5.0 by dalke on Sunday September 13, 2015 @12:00PM (#10211788)
I want to see it used for an XML library, since I think node@"name" is a more succinct, and domain-appropriate equivalent for node.attrib.get("name").
Re:Python 3.5.0 by gh02t on Sunday September 13, 2015 @01:56PM (#10212176)
I have kind of mixed feelings. The biggest argument against that PEP was that people would use it for things that are very unlike matrix multiplication, which can be confusing. I can kind of see the point there, but on the other hand the @ symbol really is natural for things like what you suggest.
Re:Python 3.5.0 by dalke on Sunday September 13, 2015 @02:42PM (#10212353)
Unusual operator overloading isn't that common in Python, though '%' for string processing is a big and primordial exception. Of the packages I know which use it, only PyParsing uses overloading for something non-analogous to the normal meanings.

I tried hard to think of ways to (ab)use '@', and this XML example and perhaps some sort of messaging API were the only two I could come up with where there was a natural domain-specific mapping.

One of the advantages of keeping '@' at the same precedence level and ordering as '*', '/', '%', and '//' is that it doesn't really offer much in the way of new use. If someone uses '@' for something very unlike matrix multiplication, then they could already use any of the other 4 symbols that way.

So I don't think @ ends up as an attractive nuisance.

Re:Python 3.5.0 by Macha on Sunday September 13, 2015 @06:01PM (#10212943)
It's a bit of a weak argument when pathlib is in the stdlib: https://www.python.org/dev/peps/pep-0428/#deriving-new-paths
Re:Python 3.5.0 by iso8859-1 on Sunday September 13, 2015 @03:52PM (#10212586)
Why not just use the array indexing operator for that?
Re:Python 3.5.0 by dalke on Sunday September 13, 2015 @05:10PM (#10212797)
In which way? node[1] means the second child.

If you mean node[x] returns node.attrib.get(x) when x is a string, and the nth-child when x is an integer, then I think that puts too much complexity into the API.

If you mean stay with the existing node.attrib dict-like API, then node@name is a simple shortcut for node.attrib.get(name), but it's 1) more aligned with CSS/XSL '@' notation for attribute syntax, and 2) faster in CPython.

(Just realized that '/' and '//' also make sense in that context. node / "abc" / "xyz" @ "p" would be the child "abc"'s child "xyz"'s attribute "p". Perhaps my proposal is a bad idea because it might suggest that these other forms are allowed.)