5 ms·

Python 3.10

41 points by hwbehrens 5y ago

hwbehrens 5y ago
I'm personally most interested in the typing and debugging improvements, but I imagine most people will be looking forward to the pattern matching (case statements).
- peakaboo 5y ago
  I love python but I think the language will slowly die if they don't do something about the GIL. So these syntax improvements are nice but not exciting.
  - d0mine 5y ago
    There were GILless Python implementations before, they didn't replace implementations that use GIL (CPython, Pypy).
    - fabioz 5y ago
      Yes, but Jython and IronPython (which were the only implementations that I know of that effectively didn't have a GIL) were much slower in general, didn't work with native extensions and were always lagging a lot on the supported version (so, yes, there's not much interest in having a GILless version with these shortcomings -- so, IMHO, CPython is right in only accepting a GIL removal if the performance in general doesn't suffer and which has a good path forward for compatibility of the existing native extensions ecosystem).
  - Zababa 5y ago
    Why do you think that? I personally think that the main "blocker" for Python is package management and installation, but that doesn't stop it from being popular.
  - PeterisP 5y ago
    See the recent discussion at https://news.ycombinator.com/item?id=29005573 https://news.ycombinator.com/item?id=29005573 - it seems to be coming and there's ongoing work to start merging a solution to GIL in the work-for-3.11 branch. They do say "Don’t expect Python 3.11 to drop the GIL just yet", but it seems likely that either 3.11 or 3.12 will have a GIL-less option that you can enable if you don't rely on any C extensions that need extra work to become concurrency-safe.
  - fabioz 5y ago
    Well, I wouldn't say that it'll slowly die given that there are many workarounds one can use to use multiple processors for CPU-heavy workloads even when the GIL is present (such as releasing it in native extensions or using multiprocessing). So, while it's discussed a lot, it seems like it did become one of the most popular languages even having a GIL -- but I guess we'll never know for sure as there are real plans to make a GILless CPython now...
- melling 5y ago
  Are there best practices and tools for using types in Python? I’d like some of the “compile time”/ editor checks in Java, for example, but with more type inference. Maybe only important classes or functions. x = 1 y = foo(bar(baz(x))) If I declare baz() with types, I’d like my editor to warn me if x is the wrong type.
  - benttoothpaste 5y ago
    Not sure about "best" practices, but Pycharm (a popular Python IDE) will warn about the wrong type in such cases.
  - aldanor 5y ago
    Short answer: use mypy
  - dragonwriter 5y ago
    > Are there best practices and tools for using types in Python? Yes. Mypy and Pyright are both quite good tools, and integrations for one or both are available for most editors.
azundo 5y ago
Quickly reading through I'm most excited about the `SyntaxError` improvements https://docs.python.org/3/whatsnew/3.10.html#syntaxerrors https://docs.python.org/3/whatsnew/3.10.html#syntaxerrors. I can't even count the number of times a missing paren or bracket has caused a syntax error in an unrelated place, so if this is indeed improved that's enough to motivate me to move to 3.10.
AStrangeMorrow 5y ago
The "switch/case" statement is now in too (or match/case here, even though it goes beyond a simple case statement). It had been rejected by Guido before (see: https://www.python.org/dev/peps/pep-3103/#rejection-notice https://www.python.org/dev/peps/pep-3103/#rejection-notice) but it seems it made its way in this time. Approved: https://www.python.org/dev/peps/pep-0634/ https://www.python.org/dev/peps/pep-0634/
- joshuamorton 5y ago
  Worth mentioning that the PEP 275 switch statement is c-styleish, in that it only matches on constant values, while the PEP 634 version handles pattern matching and destructuring, making it a lot more powerful.
semobakri 5y ago
Python3

41 points by hwbehrens 5y ago

I'm personally most interested in the typing and debugging improvements, but I imagine most people will be looking forward to the pattern matching (case statements).

peakaboo 5y ago
I love python but I think the language will slowly die if they don't do something about the GIL. So these syntax improvements are nice but not exciting.
- d0mine 5y ago
  There were GILless Python implementations before, they didn't replace implementations that use GIL (CPython, Pypy).
  - fabioz 5y ago
    Yes, but Jython and IronPython (which were the only implementations that I know of that effectively didn't have a GIL) were much slower in general, didn't work with native extensions and were always lagging a lot on the supported version (so, yes, there's not much interest in having a GILless version with these shortcomings -- so, IMHO, CPython is right in only accepting a GIL removal if the performance in general doesn't suffer and which has a good path forward for compatibility of the existing native extensions ecosystem).
- Zababa 5y ago
  Why do you think that? I personally think that the main "blocker" for Python is package management and installation, but that doesn't stop it from being popular.
- PeterisP 5y ago
  See the recent discussion at https://news.ycombinator.com/item?id=29005573 https://news.ycombinator.com/item?id=29005573 - it seems to be coming and there's ongoing work to start merging a solution to GIL in the work-for-3.11 branch. They do say "Don’t expect Python 3.11 to drop the GIL just yet", but it seems likely that either 3.11 or 3.12 will have a GIL-less option that you can enable if you don't rely on any C extensions that need extra work to become concurrency-safe.
- fabioz 5y ago
  Well, I wouldn't say that it'll slowly die given that there are many workarounds one can use to use multiple processors for CPU-heavy workloads even when the GIL is present (such as releasing it in native extensions or using multiprocessing). So, while it's discussed a lot, it seems like it did become one of the most popular languages even having a GIL -- but I guess we'll never know for sure as there are real plans to make a GILless CPython now...
melling 5y ago
Are there best practices and tools for using types in Python? I’d like some of the “compile time”/ editor checks in Java, for example, but with more type inference. Maybe only important classes or functions. x = 1 y = foo(bar(baz(x))) If I declare baz() with types, I’d like my editor to warn me if x is the wrong type.
- benttoothpaste 5y ago
  Not sure about "best" practices, but Pycharm (a popular Python IDE) will warn about the wrong type in such cases.
- aldanor 5y ago
  Short answer: use mypy
- dragonwriter 5y ago
  > Are there best practices and tools for using types in Python? Yes. Mypy and Pyright are both quite good tools, and integrations for one or both are available for most editors.

azundo 5y ago

Quickly reading through I'm most excited about the `SyntaxError` improvements https://docs.python.org/3/whatsnew/3.10.html#syntaxerrors https://docs.python.org/3/whatsnew/3.10.html#syntaxerrors. I can't even count the number of times a missing paren or bracket has caused a syntax error in an unrelated place, so if this is indeed improved that's enough to motivate me to move to 3.10.

AStrangeMorrow 5y ago

The "switch/case" statement is now in too (or match/case here, even though it goes beyond a simple case statement). It had been rejected by Guido before (see: https://www.python.org/dev/peps/pep-3103/#rejection-notice https://www.python.org/dev/peps/pep-3103/#rejection-notice) but it seems it made its way in this time. Approved: https://www.python.org/dev/peps/pep-0634/ https://www.python.org/dev/peps/pep-0634/

joshuamorton 5y ago
Worth mentioning that the PEP 275 switch statement is c-styleish, in that it only matches on constant values, while the PEP 634 version handles pattern matching and destructuring, making it a lot more powerful.

semobakri 5y ago

Python3