6 ms·

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 op

by ricw 11y ago

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

bpicolo 11y ago
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.
- rspeer 11y ago
  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.
- 1st1 11y ago
  FWIW Tornado already supports the new syntax: http://tornado.readthedocs.org/en/latest/guide/coroutines.html#python-3-5-async-and-await http://tornado.readthedocs.org/en/latest/guide/coroutines.ht...
gh02t 11y ago
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.
- vegabook 11y ago
  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.
  - gh02t 11y ago
    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.
    - dalke 11y ago
      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").
      - gh02t 11y ago
        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.
        dalke 11y ago
        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.
6502nerdface 11y ago
> 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/ http://mypy-lang.org/
- gsnedders 11y ago
  I know PyCharms is working on using them for its type-hints as well as offering better auto-completion options.
  - techdragon 11y ago
    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.)
mands 11y ago
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.
- techdragon 11y ago
  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 )
  - TheCondor 11y ago
    Pypy is accepting donations for 3. I encourage everyone that is interested to chip in a few bucks
zo1 11y ago
"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.

by ricw 11y ago

bpicolo 11y ago

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.

rspeer 11y ago
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.
1st1 11y ago
FWIW Tornado already supports the new syntax: http://tornado.readthedocs.org/en/latest/guide/coroutines.html#python-3-5-async-and-await http://tornado.readthedocs.org/en/latest/guide/coroutines.ht...

gh02t 11y ago

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.

vegabook 11y ago
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.
- gh02t 11y ago
  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.
  - dalke 11y ago
    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").
    - gh02t 11y ago
      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.
      - dalke 11y ago
        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.

6502nerdface 11y ago

> 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/ http://mypy-lang.org/

gsnedders 11y ago
I know PyCharms is working on using them for its type-hints as well as offering better auto-completion options.
- techdragon 11y ago
  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.)

mands 11y ago

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.

techdragon 11y ago
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 )
- TheCondor 11y ago
  Pypy is accepting donations for 3. I encourage everyone that is interested to chip in a few bucks

zo1 11y ago

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