Hacker News Reader

Comment by ricw | Hacker News Reader

By far the most exciting news here, to me, is PEP 484 typing module. Typing support would eliminate one of pythons biggest weaknesses. Furthermore, having it optional means it can remain as easy play and prototype with while becoming "more professional."

The other features are all well rounded, with co-routines having quite some potential, though I'd have to play around with them first to assess.

Now if everything would please start moving on to Python 3 pretty please ;).

View on HN

I like the thought of coroutines, but it's definitely been especially slow for the ecosystem to adapt to asyncio so far. (And for good reason. It has new syntax that doesn't play well with non-asyncio). Adding even more syntax for the same things may slow down adoption more? Admittedly, it's much better syntax.

The optional typing is a tricky subject. I'll have to wait until there are tools actually using it to see. One of my biggest hesitances with it is that until runtime checking or really good static analysis exists, annotating things incorrectly can be too easy. I am cautiously optimistic though. The theory is fantastic, just have to wait for the follow through. The best way to sort-of statically type things right now(imo) is through namedtuples (which I make use of heavily for lightweight, strict datatypes)

Formatting for bytes and bytearray is actually one I run into a ton trying to port py2 code to py3. Pretty excited about that.

PyCharm already takes advantage of optional typing using Python 3 annotations. The typing module will allow more types to be expressed, and I assume they'll update to take advantage of annotations that involve the typing module.

FWIW Tornado already supports the new syntax: http://tornado.readthedocs.org/en/latest/guide/coroutines.ht...

> PEP 484 typing module

Looking forward to this as well. So far the only static analysis tool I'm aware of that makes use of the PEP 484 framework is mypy [1] -- does anybody happen to know of other tools in the works?

[1] http://mypy-lang.org/

I know PyCharms is working on using them for its type-hints as well as offering better auto-completion options.

And this is why I paid for Pycharm. (and why their change in pricing model is so damn awkard, I both love them and hate them at the moment.)

Heh, for me it's the matrix multiply operator. Such a minor addition will make for a pretty big improvement to my day-to-day coding experience.

Agreed but does this apply in Numpy as well? Will Python matrix multiplications just work on lists of lists in which case they're much slower? Sorry just asking from a 2.7 holdout here as this might cause me to move.

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.

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").

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.

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.

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

Why not just use the array indexing operator for that?

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.)

The @ operator won’t apply to any built-in data types. It’s only designed for numpy and other libraries.

"An upcoming release of NumPy 1.10 will add support for the new operator" [1]

[1] https://docs.python.org/3.5/whatsnew/3.5.html

The matrix multiplication operator is not implemented for any standard python data type.

The matrix multiplication PEP is actually titled "A dedicated infix operator for matrix multiplication", and that's (broadly) the only thing that it provides. Here's the arguments for why the operator should exist: https://www.python.org/dev/peps/pep-0465/#why-should-matrix-...

numpy and other libraries might/has/will implement the matrix multiplication infix operator for their array and matrix data types.

From:

http://legacy.python.org/dev/peps/pep-0465/#id24

Implementing __matmul__, __rmatmul__ and __imatmul__ will allow you to apply this operator to any given class. In that light, you could subclass the numpy matrix class yourself and simply apply these.

As for whether these will be applied to Python lists, my speculation is: I doubt it. Its possibly the most commonly used data structure, and I doubt they would add the overhead of another set of methods on each instance.

The matrix multiplication on lists could be used for the cartesian product (see itertools.product). However this operation is rather uncommon so there's no good reason to use an operator for it.

It wouldn't incur any overhead, don't know why you'd think it would. Each method of any object only needs to be stored once, not again for every instance. The overhead comes from pointers and data fields such as the length.

> Its possibly the most commonly used data structure, and I doubt they would add the overhead of another set of methods on each instance.

Unless I'm grossly mistaken, Python methods add basically no per-instance overhead (they add per-class overhead.)

If you grab the latest code in master from https://github.com/numpy/numpy you'll get support for @ in numpy. It's great!

Yep - can't wait until Python3 is the norm.

Feels like such a step back when I have to use a Python 2.x codebase - so many little annoyances.

Join us in the future!

I made python 3 a 'production readiness requirement' at the start of this year.

My two biggest Python3 complaints have stopped being 'something doesn't work' to 1: Pyston is targeting Python 2 and 2: PyPy doesn't care enough about Python 3 ( I mean seriously... PyPy + AsyncIO = EPIC )

Pypy is accepting donations for 3. I encourage everyone that is interested to chip in a few bucks

"Now if everything would please start moving on to Python 3 pretty please ;)."

Unfortunately, not always an option. Or rather, it is, but would require an immense amount of effort. Not to mention, the client wouldn't be too happy with the increase in bugs.

Working on a legacy C++/Python implementation stuck with 2.5. It's not as bad as it sounds, really. You learn to improvise, and work on python 2.7/3+ in off-hours.

Reply on news.ycombinator.com