5 ms·

Python versions 3.11, 3.12 and now 3.13 have contained far fewer additions to the language than earlier 3.x versions. Instead the newest releases have been focu

by pansa2 2y ago

Python versions 3.11, 3.12 and now 3.13 have contained far fewer additions to the language than earlier 3.x versions. Instead the newest releases have been focusing on implementation improvements - and in 3.13, the new REPL, experimental JIT & GIL-free options all sound great! The language itself is (more than) complex enough already - I hope this focus on implementation quality continues.

formerly_proven 2y ago
The last couple years also saw a stringent approach to deprecations: If something is marked as deprecated, it WILL be removed in a minor release sooner than later.
- kstrauser 2y ago
  Yep. They’ve primarily (entirely?) involved removing ancient libraries from stdlib, usually with links to maintained 3rd party libraries. People who can’t/won’t upgrade to newer Pythons, perhaps because their old system that uses those old modules can’t run a newer one, aren’t affected. People using newer Pythons can replace those modules. There may be a person in the world panicking that they need to be on Python 3.13 and also need to parse Amiga IFF files, but it seems unlikely.
  - Doxin 2y ago
    I mean the stdlib is open source too, so you could always vendor deprecated stdlib modules. Most of them haven't changed in eons either so the lack of official support probably doesn't change much.
csdreamer7 2y ago
> The language itself is (more than) complex enough already - I hope this focus on implementation quality continues. As do I.
- avidphantasm 2y ago
  Agreed. I still haven’t really started using the ‘match’ statement and structural pattern matching (which I would love to use) since I still have to support Python 3.8 and 3.9. I was getting tired of thinking, “gee this new feature will be nice to use in 4 years, if I remember to…”
  - wdroz 2y ago
    After this month, Python 3.8 will be end-of-life, so maybe you can push internally to upgrade python.
tightbookkeeper 2y ago
Removing GIL only increases complexity.
- dagmx 2y ago
  For the runtime, but not the language
- bunderbunder 2y ago
  But they've worked very hard at shielding most users from that complexity. And the end result - making multithreading a truly viable alternative to multiprocessing for typical use cases - will open up many opportunities for Python users to simplify their software designs. I suppose only time will tell if that effort succeeds. But the intent is promising.
  - dangom 2y ago
    Do you have any references or examples that describe how this simplification would come about? Would love to learn more about it.
    - bunderbunder 2y ago
      See the motivation section of the PEP for a summary with citations for further reading: https://peps.python.org/pep-0703/ https://peps.python.org/pep-0703/
- pkkm 2y ago
  It definitely does, but don't you think that it could be worth it if it makes multithreading usable for CPU-heavy tasks?
  - tightbookkeeper 2y ago
    No. Python is orders of magnitude slower than even C# or Java. It’s doing hash table lookups per variable access. I would write a separate program to do the number crunching. Everyone must now pay the mental cost of multithreading for the chance that you might want to optimize something.
the__alchemist 2y ago
I've love to see a revamp of the import system. It is a continuous source of pain points when I write Python. Circular imports all over unless I structure my program explicitly with this in mind. Using python path hacks with `sys` etc to go up a directory too.
- derr1 2y ago
  Pathlib is your friend
- baq 2y ago
  For me 'from __future__ import no_cyclic_imports' would be good enough, if it's even possible
- int_19h 2y ago
  The biggest problem with Python imports is that the resolution of non-relative module names always prioritizes local files, even when the import happens in stdlib. This means that, for any `foo` that is a module name in stdlib, having foo.py in your code can break arbitrary modules in stdlib. For example, this breaks: # bisect.py ... # main.py import random with: Traceback (most recent call last): File ".../foo.py", line 1, in <module> import random File "/usr/lib/python3.12/random.py", line 62, in <module> from bisect import bisect as _bisect ImportError: cannot import name 'bisect' from 'bisect' This is very frustrating because Python stdlib is still very large and so many meaningful names are effectively reserved. People are aware of things like "sys" or "json", but e.g. did you know that "wave", "cmd", and "grp" are also standard modules? Worse yet is that these errors are not consistent. You might be inadvertently reusing an stdlib module name without even realizing it just because none of the stdlib (or third-party) modules that you import have it in their import graphs. Then you move on to a new version of Python or some of your dependencies, and suddenly it breaks because they have added an import somewhere. But even if you are careful about checking every single module name against the list of standard modules, a new Python version can still break you by introducing a new stdlib module that happens to clash with one of yours. For example, Python 3.9 added "graphlib", which is a fairly generic name.
  - 2y ago
underdeserver 2y ago
For those interested in the REPL improvements: " Python now uses a new interactive shell by default, based on code from the PyPy project. When the user starts the REPL from an interactive terminal, the following new features are now supported: Multiline editing with history preservation. Direct support for REPL-specific commands like help, exit, and quit, without the need to call them as functions. Prompts and tracebacks with color enabled by default. Interactive help browsing using F1 with a separate command history. History browsing using F2 that skips output as well as the >>> and … prompts. “Paste mode” with F3 that makes pasting larger blocks of code easier (press F3 again to return to the regular prompt). " Sounds cool. Definitely need the history feature, for the few times I can't run IPython.
- user070223 2y ago
  Thanks, I just found out about .pythonstartup and setup writing history to a file and pretty printing with pprint / rich. https://www.bitecode.dev/p/happiness-is-a-good-pythonstartup https://www.bitecode.dev/p/happiness-is-a-good-pythonstartup or search for a gist
- formerly_proven 2y ago
  Presumably this also means readline (GPL) is no longer required to have any line editing beyond what a canonical-mode terminal does by itself. It seems like there is code to support libedit (BSD), but I've never managed to make Python's build system detect it.
  - zvr 2y ago
    I have managed to build Python with libedit instead of readline, but it was a custom build. If your assumption is correct, then I'm anxiously waiting for having the default Python executable in Ubuntu, for example, being licensed under a non-copyleft license. Then one would be able to build proprietary-licensed executables via PyInstaller much more easily.
- mixmastamyk 2y ago
  I hope it doesn’t break ptpython, and/or is worse than it. I’ve been using it for quite a while.
pjmlp 2y ago
Using Python on and off since version 1.6, I always like to point out that the language + standard library is quite complex, even more when taking into account all the variations across versions. Looking forward to JIT maturing from now onwards.

by pansa2 2y ago

formerly_proven 2y ago

The last couple years also saw a stringent approach to deprecations: If something is marked as deprecated, it WILL be removed in a minor release sooner than later.

kstrauser 2y ago
Yep. They’ve primarily (entirely?) involved removing ancient libraries from stdlib, usually with links to maintained 3rd party libraries. People who can’t/won’t upgrade to newer Pythons, perhaps because their old system that uses those old modules can’t run a newer one, aren’t affected. People using newer Pythons can replace those modules. There may be a person in the world panicking that they need to be on Python 3.13 and also need to parse Amiga IFF files, but it seems unlikely.
- Doxin 2y ago
  I mean the stdlib is open source too, so you could always vendor deprecated stdlib modules. Most of them haven't changed in eons either so the lack of official support probably doesn't change much.

csdreamer7 2y ago

> The language itself is (more than) complex enough already - I hope this focus on implementation quality continues. As do I.

avidphantasm 2y ago
Agreed. I still haven’t really started using the ‘match’ statement and structural pattern matching (which I would love to use) since I still have to support Python 3.8 and 3.9. I was getting tired of thinking, “gee this new feature will be nice to use in 4 years, if I remember to…”
- wdroz 2y ago
  After this month, Python 3.8 will be end-of-life, so maybe you can push internally to upgrade python.

tightbookkeeper 2y ago

Removing GIL only increases complexity.

dagmx 2y ago
For the runtime, but not the language
bunderbunder 2y ago
But they've worked very hard at shielding most users from that complexity. And the end result - making multithreading a truly viable alternative to multiprocessing for typical use cases - will open up many opportunities for Python users to simplify their software designs. I suppose only time will tell if that effort succeeds. But the intent is promising.
- dangom 2y ago
  Do you have any references or examples that describe how this simplification would come about? Would love to learn more about it.
  - bunderbunder 2y ago
    See the motivation section of the PEP for a summary with citations for further reading: https://peps.python.org/pep-0703/ https://peps.python.org/pep-0703/
pkkm 2y ago
It definitely does, but don't you think that it could be worth it if it makes multithreading usable for CPU-heavy tasks?
- tightbookkeeper 2y ago
  No. Python is orders of magnitude slower than even C# or Java. It’s doing hash table lookups per variable access. I would write a separate program to do the number crunching. Everyone must now pay the mental cost of multithreading for the chance that you might want to optimize something.

the__alchemist 2y ago

I've love to see a revamp of the import system. It is a continuous source of pain points when I write Python. Circular imports all over unless I structure my program explicitly with this in mind. Using python path hacks with `sys` etc to go up a directory too.

derr1 2y ago
Pathlib is your friend
baq 2y ago
For me 'from __future__ import no_cyclic_imports' would be good enough, if it's even possible
int_19h 2y ago
The biggest problem with Python imports is that the resolution of non-relative module names always prioritizes local files, even when the import happens in stdlib. This means that, for any `foo` that is a module name in stdlib, having foo.py in your code can break arbitrary modules in stdlib. For example, this breaks: # bisect.py ... # main.py import random with: Traceback (most recent call last): File ".../foo.py", line 1, in <module> import random File "/usr/lib/python3.12/random.py", line 62, in <module> from bisect import bisect as _bisect ImportError: cannot import name 'bisect' from 'bisect' This is very frustrating because Python stdlib is still very large and so many meaningful names are effectively reserved. People are aware of things like "sys" or "json", but e.g. did you know that "wave", "cmd", and "grp" are also standard modules? Worse yet is that these errors are not consistent. You might be inadvertently reusing an stdlib module name without even realizing it just because none of the stdlib (or third-party) modules that you import have it in their import graphs. Then you move on to a new version of Python or some of your dependencies, and suddenly it breaks because they have added an import somewhere. But even if you are careful about checking every single module name against the list of standard modules, a new Python version can still break you by introducing a new stdlib module that happens to clash with one of yours. For example, Python 3.9 added "graphlib", which is a fairly generic name.
- 2y ago

underdeserver 2y ago

For those interested in the REPL improvements: " Python now uses a new interactive shell by default, based on code from the PyPy project. When the user starts the REPL from an interactive terminal, the following new features are now supported: Multiline editing with history preservation. Direct support for REPL-specific commands like help, exit, and quit, without the need to call them as functions. Prompts and tracebacks with color enabled by default. Interactive help browsing using F1 with a separate command history. History browsing using F2 that skips output as well as the >>> and … prompts. “Paste mode” with F3 that makes pasting larger blocks of code easier (press F3 again to return to the regular prompt). " Sounds cool. Definitely need the history feature, for the few times I can't run IPython.

user070223 2y ago
Thanks, I just found out about .pythonstartup and setup writing history to a file and pretty printing with pprint / rich. https://www.bitecode.dev/p/happiness-is-a-good-pythonstartup https://www.bitecode.dev/p/happiness-is-a-good-pythonstartup or search for a gist
formerly_proven 2y ago
Presumably this also means readline (GPL) is no longer required to have any line editing beyond what a canonical-mode terminal does by itself. It seems like there is code to support libedit (BSD), but I've never managed to make Python's build system detect it.
- zvr 2y ago
  I have managed to build Python with libedit instead of readline, but it was a custom build. If your assumption is correct, then I'm anxiously waiting for having the default Python executable in Ubuntu, for example, being licensed under a non-copyleft license. Then one would be able to build proprietary-licensed executables via PyInstaller much more easily.
mixmastamyk 2y ago
I hope it doesn’t break ptpython, and/or is worse than it. I’ve been using it for quite a while.

pjmlp 2y ago

Using Python on and off since version 1.6, I always like to point out that the language + standard library is quite complex, even more when taking into account all the variations across versions. Looking forward to JIT maturing from now onwards.