12 ms·

Python 3.11

202 points by wetpaws 5y ago

deleted 5y ago
[deleted]
gypsyharlot 5y ago
Python is deceptive. They lure you in with its simplicity, and then one day you want to deploy your software and you realize that it's more complicated than any other programming language ever conceived of.
- pansa2 5y ago
  Yes - this is the reason I've switched to Go for writing command-line apps. I don't like Go as much as Python (Go is simpler, but not as easy), but being able to compile a self-contained executable is huge. It's also great to have access to GIL-free parallelism. I don't expect Python to support either of those things any time soon.
- dijit 5y ago
  Because of dependency management, or?
  - dagw 5y ago
    Because of having to know what WSGI and ASGI are and picking the right one. Then pick which implementation of the above you want to use. Then configuring it correctly for your app. And finally make it play nicely with nginx/apache/whatever. If on the other hand you're trying to deploy a desktop app, that is an entirely different kettle of 'fun'.
    - aitchnyu 5y ago
      <dream> There is a very fast Gunicorn replacement in Rust that accepts an wsgi/asgi module and a static dir and starts serving both. It breaks performance barriers for pure Python servers. It can automagically create systemd service and nginx site or just exist as a Docker entry point.
    - maccolgan 5y ago
      That's not really a criticism of Python, is it? What do you want? One Way To Do Things with No Configuration with magical compatibility with nginx/apache/whatever ?
      - badsectoracula 5y ago
        Well, according to the Zen of Python "there should be one- and preferably only one -obvious way to do it" :-P
    - dragonwriter 5y ago
      > Because of having to know what WSGI and ASGI are and picking the right one. Then pick which implementation of the above you want to use. Then configuring it correctly for your app. And finally make it play nicely with nginx/apache/whatever. None if the Python in I deploy has to deal with any of that, all of which applies in a very narrow particular application domain. Even if it was a source of valid criticism, it would only be of using Python for that specific use, not generally.
- akmittal 5y ago
  What kind you issues you get during deployment? I think if running on right version then there should not be any issues.
  - gypsyharlot 5y ago
    https://stackoverflow.com/questions/52187362/how-to-deploy-python-script https://stackoverflow.com/questions/52187362/how-to-deploy-p... Some of these approaches work for Windows, others for Mac, some for Linux, depending on versions of Python that are installed, etc. You can get around some of the problems with pyenv and a bunch of other tools.
  - ido 5y ago
    I was originally using python (learned it in my first job back in 2001!) & that was the reason I eventually moved to other languages - python as a language is great but the tooling/ecosystem isn't for exactly these issues (or at least weren't at the time, that's also at least a decade+ ago by now). My impression at the time was that using it for server side stuff was fine (i have control of the server and simply install all the right things/versions myself) but packaging it up for end users to install on their desktops/mobile was a huge pain, there was no real easy/simple way to just export a self running installer that you double click (on windows/mac) or an IPA/APK (on ios/android) and end up with a running program the way users were used to from e.g. a bundled .net (at the time using mono, now ms provides cross platforms .net implementations themselves) or native c/c++ executable.
- DemocracyFTW 5y ago
  This is a solved problem. The community provides a handy system overview[^1] that should be good enough for most cases. [^1]: https://xkcd.com/1987/ https://xkcd.com/1987/
  - SteadBytes 5y ago
    Didn’t even need to open the link to know what it was, thanks for the laugh!
- agumonkey 5y ago
  It's probably the most voiced complaint these days, unless core devs are deaf, I bet ten solid dollars they're gonna address that soon.
  - jshen 5y ago
    It’s been like this for over a decade. I wouldn’t hold my breath. By comparison, I’m pretty sure the Ruby community adopted bundler over a decade ago.
    - agumonkey 5y ago
      Maybe they were busy on other things. Py3k, async. Now these are settled I don't see what other defect needs to be worked on
- askvictor 5y ago
  I don't know; I've just written something in .net/c# and it's pretty bloddy difficult to deploy.
  - gkbrk 5y ago
    .NET can export self-contained single-file executable that doesn't require any runtime on the target computer/server. Python has solutions like PyInstaller, but it's not built-in and requires building on the same system. In .NET, you can use the built-in tools to export binaries for Linux from Windows.
    - byteface 5y ago
      Most windows users have at least 4/5 versions of linux installed on their machine so it's a non issue. They have wsl, a base installed partition, vagrant, a VM and probably docker containers. so running one extra command to gen a windows package isn't a big deal.
    - askvictor 5y ago
      Except when you have some specific dependencies/targets that make this difficult. I'm sure I'll get there eventually, but I chose .net for this thinking it would be dead simple, and yet here I am wading through documentation and stackoverflow posts to get to my self-contained single-file executable.
  - rowanG077 5y ago
    .net/C# was one of the easiest to deploy in my experience. Just build a self-contained executable and you're done.
- salex89 5y ago
  Wouldn't say it better myself. Everything you gain with fast coding you lose on tackling performance issues, GIL, dependency management... Things harder to solve once you're committed to production.
  - peakaboo 5y ago
    It depends very much on what you are doing. Python for big complicated applications is a No for me also but python for extraction jobs in a ETL pipeline or data science tasks is a huge YES.
    - deleted 5y ago
      [deleted]
- matkoniecz 5y ago
  Can you be more specific about your claims? What is wrong with Python? > more complicated than any other programming language ever conceived of is definitely untrue. Even if you take only mainstream languages then there are many more annoying to deploy, ones that are more complicated and so on.
  - jshen 5y ago
    Dependency management in python is much worse than most mainstream languages.
    - matkoniecz 5y ago
      Here I agree, but it is quite far away from > more complicated than any other programming language ever conceived of
      - gypsyharlot 5y ago
        It was far easier for me to grok monads in Haskell (and it took less time), than to learn how to properly deploy a Python application. Given that monads are often a complaint and testament to the "complexity" of Haskell, I think it's unfair to make the claim that Python is uncomplicated. If you use a language for some period of time, it is very likely that you will have to deal with the tooling at some point.
      - eesmith 5y ago
        I think the "it's" in "it's more complicated" refers to deploying software, not the language itself nor its support packages.
- tigr 5y ago
  Have you ever tried to deploy an Erlang/OTP application? I find it much harder to do
  - vland 5y ago
    No, but Go and C++ are much easier to deploy.
- deleted 5y ago
  [deleted]
- rcarmo 5y ago
  This comment is deceptive. This is a solved problem with virtualenvs. It is why Piku (https://github.com/piku https://github.com/piku) can deploy isolated apps with ease (and actually devotes less than 80 lines of code to the actual Python deployment).
  - gypsyharlot 5y ago
    Thanks for taking the opportunity to advertise your own product, but it doesn't solve the problem.
    - rcarmo 5y ago
      It’s not a product. It’s an example of why it isn’t a problem, and it was actually _designed_ around virtualenvs, which is why it’s just a single script (again, not a product).
- globular-toast 5y ago
  When you say "deploy" do you mean "put it on a webserver"? I've deployed python Web services on to very limited environments that have nothing more than an interpreter. Nowadays I use pip-tools and docker which makes updating trivial. Do you perhaps mean distribution as an app? I've had luck with pyinstaller. There can be fiddly bits but overall it's pretty smooth. It's easier if you are targeting a system with an interpreter, like a Linux distro. Overall I just think you need to know what you're doing. I don't really think this is a bad thing. Maybe you could elaborate on what your difficulties are? From here I just don't see how it's more difficult than anything else.
  - gypsyharlot 5y ago
    Read and learn: https://sedimental.org/the_packaging_gradient.html https://sedimental.org/the_packaging_gradient.html
    - globular-toast 5y ago
      Thanks, I know all of that. What made you think I don't?
- mrlonglong 5y ago
  I recently wrote a python script to handle serial communication and uploading of a bare metal binary to my RPi3, this saves me so much time debugging now that I don't need to swap SD cards continually. Excellent tool.
faizshah 5y ago
This is just a change log its better to link to the 3.11 what’s new: https://docs.python.org/3.11/whatsnew/3.11.html https://docs.python.org/3.11/whatsnew/3.11.html
- btown 5y ago
  Between this link and the OP, we're seeing the first improvements to drop from Mark Shannon's Microsoft-funded full-time work on CPython optimization, alongside Eric Snow and Guido van Rossum: https://www.theregister.com/2021/05/19/faster_python_mark_shannon_author/ https://www.theregister.com/2021/05/19/faster_python_mark_sh... https://github.com/markshannon/faster-cpython/blob/master/plan.md https://github.com/markshannon/faster-cpython/blob/master/pl... - indicates that this is step 2 of 4, where the forthcoming steps actually plan to introduce JIT compilation! From the OP Changelog: - bpo-44590: All necessary data for executing a Python function (local variables, stack, etc) is now kept in a per-thread stack. Frame objects are lazily allocated on demand. This increases performance by about 7% on the standard benchmark suite. Introspection and debugging are unaffected as frame objects are always available when needed. Patch by Mark Shannon. And from the What's New: - “Zero-cost” exceptions are implemented. The cost of try statements is almost eliminated when no exception is raised. (Contributed by Mark Shannon in bpo-40222.) - Method calls with keywords are now faster due to bytecode changes which avoid creating bound method instances. Previously, this optimization was applied only to method calls with purely positional arguments. (Contributed by Ken Jin and Mark Shannon in bpo-26110, based on ideas implemented in PyPy.) Really, really exciting beginnings. I can't wait to see what's next!
  - zerocrates 5y ago
    With Python style favoring exceptions, I could see just the zero-cost try alone being a meaningful improvement.
    - BiteCode_dev 5y ago
      On fact, for loops are try/except under the hood.
  - 5y ago
sashk 5y ago
According to PEP-619[1], Python 3.10 release expected tomorrow, so no wonder work started on 3.11... [1]: https://www.python.org/dev/peps/pep-0619/ https://www.python.org/dev/peps/pep-0619/
- oefrha 5y ago
  Development on a new branch begins at the time of beta 1 of the previous branch, which is the feature freeze point. ("Development on a new branch" is metaphorical, there's no new git branch created at that point, just the master branch.)
ummwhat 5y ago
Just 3 more updates until Pithon 3.14
- google234123 5y ago
  one more after that for 3.14.1
  - fastball 5y ago
    Then they just need to get the patch release up to 3.14.15 for maximum enjoyment. It's doable! 2.7 got all the way up to 2.7.18 (though that was a special case).
    - blitzar 5y ago
      > though that was a special case I think this qualifies as an even more special case.
- Xavdidtheshadow 5y ago
  pi-thon
  - deleted 5y ago
    [deleted]
commit 5y ago
I'm waiting for Python for Workgroups 3.11
- Jupe 5y ago
  Close... Python 3.8.10 (default, Jun 2 2021, 10:49:15) [GCC 9.4.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> print(3.11 - 3.1) 0.009999999999999787 >>>
- eyelidlessness 5y ago
  I’m not holding my breath for Python NT however.
  - oaiey 5y ago
    Considering what happened between 2 and 3 ... I think everyone agrees that no one ever wants to reach 4 (NT).
warent 5y ago
just spent about 4 hrs getting Python 2 and pip setup on my Mac. Any time I have the misfortune of needing to use python I get cold sweats at the thought of the environment stuff. Why is this still such a massive problem?
- blondin 5y ago
  i sympathize. the problem is apple. they are (understandably) refusing to ship an up-to-date global python interpreter with macOS. not only that, they aren't removing the default 2.7 that they ship. macOS Big Sur ships Python 2.7. ha. ha. ha. none of the proposed "virtual environments" solutions are going to rescue you when you operate globally at the OS-level and not in a sandbox. been there.
  - wutbrodo 5y ago
    > they are (understandably) refusing to ship an up-to-date global python interpreter with macOS What is the understandable reasoning?
    - mbreese 5y ago
      It's pretty common to have kept `/usr/bin/python` as Python2. This is the most conservative option and won't break anything that's already running. Anyone who is using Python currently will have already installed Python 3 (or knows how to do this), and is probably using `#!/usr/bin/env python3`. As an OS vendor with many (many...) systems in the wild, you don't want to switch Python versions on people unexpectedly. Especially when it's still pretty painless to keep python2 around even if there is an installed python3. For anyone that's still using python2 (as a nearby comment mentioned), there is now at least a warning to avoid using the default Python 2.7 (/usr/bin/python). For an OS vendor, this transition takes a long time... but at least it's in process.
      - wutbrodo 5y ago
        Oh, sure, it's definitely not a good idea to change what the unqualified python binary refers to. But I interpreted "refusing to ship an up-to-date global python interpreter with macOS" as meaning that Python3 isn't shipped at all, with the binary name "python3"). Is that the case? If so, I still don't understand the reasoning.
deleted 5y ago
[deleted]
deleted 5y ago
[deleted]
Alex3917 5y ago
Love seeing all the optimizations. Is this largely the new Microsoft work?
6gvONxR4sf7o 5y ago
The new error messages look amazing.
carapace 5y ago
In https://docs.python.org/3.11/whatsnew/3.11.html https://docs.python.org/3.11/whatsnew/3.11.html : > A new function operator.call has been added, such that operator.call(obj, *args, **kwargs) == obj(*args, **kwargs). Isn't this the same as the old apply function? https://docs.python.org/2/library/functions.html#apply https://docs.python.org/2/library/functions.html#apply Ah, it was discussed: https://bugs.python.org/issue44019#msg400821 https://bugs.python.org/issue44019#msg400821 > Python2's apply has different semantics: it takes non-unpacked arguments, i.e. def apply(f, args, kwargs={}): return f(*args, **kwargs) > rather than def call(f, *args, **kwargs): return f(*args, **kwargs)
arathore 5y ago
> When printing tracebacks, the interpreter will now point to the exact expression that caused the error instead of just the line. For example: Traceback (most recent call last): File "distance.py", line 11, in <module> print(manhattan_distance(p1, p2)) ^^^^^^^^^^^^^^^^^^^^^^^^^^ File "distance.py", line 6, in manhattan_distance return abs(point_1.x - point_2.x) + abs(point_1.y - point_2.y) ^^^^^^^^^ AttributeError: 'NoneType' object has no attribute 'x' This is such a great quality of life improvement.
- RheingoldRiver 5y ago
  This is an INCREDIBLE improvement. I'm so excited for it for myself, and I think it will also do wonders for getting new programmers comfortable with the language. Seeing exactly where in the line your error is, is amazing! IMO this 100% cements Python as the single most newbie-friendly language, if there was any question before now (or at least, before the release of 3.11).
  - pletnes 5y ago
    I already move code into separate lines since this is currently missing. This is great indeed. (Although that might still make sense for debugging)
    - throwaway81523 5y ago
      It would sure be great if they made it easier to break to the debugger in case of an unhandled exception, like (setq debug-on-error t) in Emacs Lisp.
      - pletnes 5y ago
        This can be done in some IDEs. Although it can get confusimg if you’re working in an app framework that does some sort of catch-all exception handling.
        5y ago
radus 5y ago
Some nice changes: > “Zero-cost” exceptions are implemented. The cost of try statements is almost eliminated when no exception is raised. (Contributed by Mark Shannon in bpo-40222.) > Method calls with keywords are now faster due to bytecode changes which avoid creating bound method instances.
MarkSweep 5y ago
This all all exciting stuff, but 3.11 comes out in 2022. 3.10 is supposed to come out tomorrow though, you can checkout it's "What's New" here: https://docs.python.org/3.10/whatsnew/3.10.html https://docs.python.org/3.10/whatsnew/3.10.html 3.10 release schedule: https://www.python.org/dev/peps/pep-0619/ https://www.python.org/dev/peps/pep-0619/
eink-reader-32 5y ago
I noticed on https://www.python.org/downloads/ https://www.python.org/downloads/ I only see up to python 3.9. Where is 3.10 and 3.11 downloads? whats the best way to install python?
- EmilStenstrom 5y ago
  3.10 will be released tomorrow. 3.11 is still very much work in progress and is expected to drop in 2022.
  - eink-reader-32 5y ago
    Thanks this is what I was looking for. Don't know why i was down-voted for asking
eesmith 5y ago
I really enjoyed reading the discussion about the updates to TimSort, at https://bugs.python.org/issue34561 https://bugs.python.org/issue34561 .
powersnail 5y ago
The deprecation of lib2to3 has occasioned some difficulties for formatters. Neither `black` nor `yapf` can correctly format a script with the `match` syntax introduced in python 3.10, while python 3.10 is formally released tomorrow. It seems that transitioning to the new PEG parser isn't a trivial work. Certainly glad to see python 3.11 having so much performance improvements.
azinman2 5y ago
> bpo-44590: All necessary data for executing a Python function (local variables, stack, etc) is now kept in a per-thread stack. Frame objects are lazily allocated on demand. This increases performance by about 7% on the standard benchmark suite. Introspection and debugging are unaffected as frame objects are always available when needed. Patch by Mark Shannon That’s pretty massive! My impression of CPython was there were few performance improvements globally since 3. I’m having trouble finding benchmarks for all the minor versions.
- vland 5y ago
  7% is massive for C, nothing for Python, and the benchmark suite is unreliable. I'd wait for independent measurements in real world applications. Python core developers are very good at writing bloated benchmark suites that are so convoluted that no one knows what is going on. Since more than two decades, big projects like "The need for speed", pythonspeed.com pop up periodically without anything happening. But apparently that's enough to get folks excited.

202 points by wetpaws 5y ago

deleted 5y ago

[deleted]

Python is deceptive. They lure you in with its simplicity, and then one day you want to deploy your software and you realize that it's more complicated than any other programming language ever conceived of.

pansa2 5y ago
Yes - this is the reason I've switched to Go for writing command-line apps. I don't like Go as much as Python (Go is simpler, but not as easy), but being able to compile a self-contained executable is huge. It's also great to have access to GIL-free parallelism. I don't expect Python to support either of those things any time soon.
dijit 5y ago
Because of dependency management, or?
- dagw 5y ago
  Because of having to know what WSGI and ASGI are and picking the right one. Then pick which implementation of the above you want to use. Then configuring it correctly for your app. And finally make it play nicely with nginx/apache/whatever. If on the other hand you're trying to deploy a desktop app, that is an entirely different kettle of 'fun'.
  - aitchnyu 5y ago
    <dream> There is a very fast Gunicorn replacement in Rust that accepts an wsgi/asgi module and a static dir and starts serving both. It breaks performance barriers for pure Python servers. It can automagically create systemd service and nginx site or just exist as a Docker entry point.
  - maccolgan 5y ago
    That's not really a criticism of Python, is it? What do you want? One Way To Do Things with No Configuration with magical compatibility with nginx/apache/whatever ?
    - badsectoracula 5y ago
      Well, according to the Zen of Python "there should be one- and preferably only one -obvious way to do it" :-P
  - dragonwriter 5y ago
    > Because of having to know what WSGI and ASGI are and picking the right one. Then pick which implementation of the above you want to use. Then configuring it correctly for your app. And finally make it play nicely with nginx/apache/whatever. None if the Python in I deploy has to deal with any of that, all of which applies in a very narrow particular application domain. Even if it was a source of valid criticism, it would only be of using Python for that specific use, not generally.
akmittal 5y ago
What kind you issues you get during deployment? I think if running on right version then there should not be any issues.
- gypsyharlot 5y ago
  https://stackoverflow.com/questions/52187362/how-to-deploy-python-script https://stackoverflow.com/questions/52187362/how-to-deploy-p... Some of these approaches work for Windows, others for Mac, some for Linux, depending on versions of Python that are installed, etc. You can get around some of the problems with pyenv and a bunch of other tools.
- ido 5y ago
  I was originally using python (learned it in my first job back in 2001!) & that was the reason I eventually moved to other languages - python as a language is great but the tooling/ecosystem isn't for exactly these issues (or at least weren't at the time, that's also at least a decade+ ago by now). My impression at the time was that using it for server side stuff was fine (i have control of the server and simply install all the right things/versions myself) but packaging it up for end users to install on their desktops/mobile was a huge pain, there was no real easy/simple way to just export a self running installer that you double click (on windows/mac) or an IPA/APK (on ios/android) and end up with a running program the way users were used to from e.g. a bundled .net (at the time using mono, now ms provides cross platforms .net implementations themselves) or native c/c++ executable.
DemocracyFTW 5y ago
This is a solved problem. The community provides a handy system overview[^1] that should be good enough for most cases. [^1]: https://xkcd.com/1987/ https://xkcd.com/1987/
- SteadBytes 5y ago
  Didn’t even need to open the link to know what it was, thanks for the laugh!
agumonkey 5y ago
It's probably the most voiced complaint these days, unless core devs are deaf, I bet ten solid dollars they're gonna address that soon.
- jshen 5y ago
  It’s been like this for over a decade. I wouldn’t hold my breath. By comparison, I’m pretty sure the Ruby community adopted bundler over a decade ago.
  - agumonkey 5y ago
    Maybe they were busy on other things. Py3k, async. Now these are settled I don't see what other defect needs to be worked on
askvictor 5y ago
I don't know; I've just written something in .net/c# and it's pretty bloddy difficult to deploy.
- gkbrk 5y ago
  .NET can export self-contained single-file executable that doesn't require any runtime on the target computer/server. Python has solutions like PyInstaller, but it's not built-in and requires building on the same system. In .NET, you can use the built-in tools to export binaries for Linux from Windows.
  - byteface 5y ago
    Most windows users have at least 4/5 versions of linux installed on their machine so it's a non issue. They have wsl, a base installed partition, vagrant, a VM and probably docker containers. so running one extra command to gen a windows package isn't a big deal.
  - askvictor 5y ago
    Except when you have some specific dependencies/targets that make this difficult. I'm sure I'll get there eventually, but I chose .net for this thinking it would be dead simple, and yet here I am wading through documentation and stackoverflow posts to get to my self-contained single-file executable.
- rowanG077 5y ago
  .net/C# was one of the easiest to deploy in my experience. Just build a self-contained executable and you're done.
salex89 5y ago
Wouldn't say it better myself. Everything you gain with fast coding you lose on tackling performance issues, GIL, dependency management... Things harder to solve once you're committed to production.
- peakaboo 5y ago
  It depends very much on what you are doing. Python for big complicated applications is a No for me also but python for extraction jobs in a ETL pipeline or data science tasks is a huge YES.
  - deleted 5y ago
    [deleted]
matkoniecz 5y ago
Can you be more specific about your claims? What is wrong with Python? > more complicated than any other programming language ever conceived of is definitely untrue. Even if you take only mainstream languages then there are many more annoying to deploy, ones that are more complicated and so on.
- jshen 5y ago
  Dependency management in python is much worse than most mainstream languages.
  - matkoniecz 5y ago
    Here I agree, but it is quite far away from > more complicated than any other programming language ever conceived of
    - gypsyharlot 5y ago
      It was far easier for me to grok monads in Haskell (and it took less time), than to learn how to properly deploy a Python application. Given that monads are often a complaint and testament to the "complexity" of Haskell, I think it's unfair to make the claim that Python is uncomplicated. If you use a language for some period of time, it is very likely that you will have to deal with the tooling at some point.
    - eesmith 5y ago
      I think the "it's" in "it's more complicated" refers to deploying software, not the language itself nor its support packages.
tigr 5y ago
Have you ever tried to deploy an Erlang/OTP application? I find it much harder to do
- vland 5y ago
  No, but Go and C++ are much easier to deploy.
deleted 5y ago
[deleted]
rcarmo 5y ago
This comment is deceptive. This is a solved problem with virtualenvs. It is why Piku (https://github.com/piku https://github.com/piku) can deploy isolated apps with ease (and actually devotes less than 80 lines of code to the actual Python deployment).
- gypsyharlot 5y ago
  Thanks for taking the opportunity to advertise your own product, but it doesn't solve the problem.
  - rcarmo 5y ago
    It’s not a product. It’s an example of why it isn’t a problem, and it was actually _designed_ around virtualenvs, which is why it’s just a single script (again, not a product).
globular-toast 5y ago
When you say "deploy" do you mean "put it on a webserver"? I've deployed python Web services on to very limited environments that have nothing more than an interpreter. Nowadays I use pip-tools and docker which makes updating trivial. Do you perhaps mean distribution as an app? I've had luck with pyinstaller. There can be fiddly bits but overall it's pretty smooth. It's easier if you are targeting a system with an interpreter, like a Linux distro. Overall I just think you need to know what you're doing. I don't really think this is a bad thing. Maybe you could elaborate on what your difficulties are? From here I just don't see how it's more difficult than anything else.
- gypsyharlot 5y ago
  Read and learn: https://sedimental.org/the_packaging_gradient.html https://sedimental.org/the_packaging_gradient.html
  - globular-toast 5y ago
    Thanks, I know all of that. What made you think I don't?
mrlonglong 5y ago
I recently wrote a python script to handle serial communication and uploading of a bare metal binary to my RPi3, this saves me so much time debugging now that I don't need to swap SD cards continually. Excellent tool.

faizshah 5y ago

This is just a change log its better to link to the 3.11 what’s new: https://docs.python.org/3.11/whatsnew/3.11.html https://docs.python.org/3.11/whatsnew/3.11.html

btown 5y ago
Between this link and the OP, we're seeing the first improvements to drop from Mark Shannon's Microsoft-funded full-time work on CPython optimization, alongside Eric Snow and Guido van Rossum: https://www.theregister.com/2021/05/19/faster_python_mark_shannon_author/ https://www.theregister.com/2021/05/19/faster_python_mark_sh... https://github.com/markshannon/faster-cpython/blob/master/plan.md https://github.com/markshannon/faster-cpython/blob/master/pl... - indicates that this is step 2 of 4, where the forthcoming steps actually plan to introduce JIT compilation! From the OP Changelog: - bpo-44590: All necessary data for executing a Python function (local variables, stack, etc) is now kept in a per-thread stack. Frame objects are lazily allocated on demand. This increases performance by about 7% on the standard benchmark suite. Introspection and debugging are unaffected as frame objects are always available when needed. Patch by Mark Shannon. And from the What's New: - “Zero-cost” exceptions are implemented. The cost of try statements is almost eliminated when no exception is raised. (Contributed by Mark Shannon in bpo-40222.) - Method calls with keywords are now faster due to bytecode changes which avoid creating bound method instances. Previously, this optimization was applied only to method calls with purely positional arguments. (Contributed by Ken Jin and Mark Shannon in bpo-26110, based on ideas implemented in PyPy.) Really, really exciting beginnings. I can't wait to see what's next!
- zerocrates 5y ago
  With Python style favoring exceptions, I could see just the zero-cost try alone being a meaningful improvement.
  - BiteCode_dev 5y ago
    On fact, for loops are try/except under the hood.
- 5y ago

sashk 5y ago

According to PEP-619[1], Python 3.10 release expected tomorrow, so no wonder work started on 3.11... [1]: https://www.python.org/dev/peps/pep-0619/ https://www.python.org/dev/peps/pep-0619/

oefrha 5y ago
Development on a new branch begins at the time of beta 1 of the previous branch, which is the feature freeze point. ("Development on a new branch" is metaphorical, there's no new git branch created at that point, just the master branch.)

ummwhat 5y ago

Just 3 more updates until Pithon 3.14

google234123 5y ago
one more after that for 3.14.1
- fastball 5y ago
  Then they just need to get the patch release up to 3.14.15 for maximum enjoyment. It's doable! 2.7 got all the way up to 2.7.18 (though that was a special case).
  - blitzar 5y ago
    > though that was a special case I think this qualifies as an even more special case.
Xavdidtheshadow 5y ago
pi-thon
- deleted 5y ago
  [deleted]

commit 5y ago

I'm waiting for Python for Workgroups 3.11

Jupe 5y ago
Close... Python 3.8.10 (default, Jun 2 2021, 10:49:15) [GCC 9.4.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> print(3.11 - 3.1) 0.009999999999999787 >>>
eyelidlessness 5y ago
I’m not holding my breath for Python NT however.
- oaiey 5y ago
  Considering what happened between 2 and 3 ... I think everyone agrees that no one ever wants to reach 4 (NT).

warent 5y ago

just spent about 4 hrs getting Python 2 and pip setup on my Mac. Any time I have the misfortune of needing to use python I get cold sweats at the thought of the environment stuff. Why is this still such a massive problem?

blondin 5y ago
i sympathize. the problem is apple. they are (understandably) refusing to ship an up-to-date global python interpreter with macOS. not only that, they aren't removing the default 2.7 that they ship. macOS Big Sur ships Python 2.7. ha. ha. ha. none of the proposed "virtual environments" solutions are going to rescue you when you operate globally at the OS-level and not in a sandbox. been there.
- wutbrodo 5y ago
  > they are (understandably) refusing to ship an up-to-date global python interpreter with macOS What is the understandable reasoning?
  - mbreese 5y ago
    It's pretty common to have kept `/usr/bin/python` as Python2. This is the most conservative option and won't break anything that's already running. Anyone who is using Python currently will have already installed Python 3 (or knows how to do this), and is probably using `#!/usr/bin/env python3`. As an OS vendor with many (many...) systems in the wild, you don't want to switch Python versions on people unexpectedly. Especially when it's still pretty painless to keep python2 around even if there is an installed python3. For anyone that's still using python2 (as a nearby comment mentioned), there is now at least a warning to avoid using the default Python 2.7 (/usr/bin/python). For an OS vendor, this transition takes a long time... but at least it's in process.
    - wutbrodo 5y ago
      Oh, sure, it's definitely not a good idea to change what the unqualified python binary refers to. But I interpreted "refusing to ship an up-to-date global python interpreter with macOS" as meaning that Python3 isn't shipped at all, with the binary name "python3"). Is that the case? If so, I still don't understand the reasoning.

deleted 5y ago

[deleted]

deleted 5y ago

[deleted]

Alex3917 5y ago

Love seeing all the optimizations. Is this largely the new Microsoft work?

6gvONxR4sf7o 5y ago

The new error messages look amazing.

carapace 5y ago

In https://docs.python.org/3.11/whatsnew/3.11.html https://docs.python.org/3.11/whatsnew/3.11.html : > A new function operator.call has been added, such that operator.call(obj, *args, **kwargs) == obj(*args, **kwargs). Isn't this the same as the old apply function? https://docs.python.org/2/library/functions.html#apply https://docs.python.org/2/library/functions.html#apply Ah, it was discussed: https://bugs.python.org/issue44019#msg400821 https://bugs.python.org/issue44019#msg400821 > Python2's apply has different semantics: it takes non-unpacked arguments, i.e. def apply(f, args, kwargs={}): return f(*args, **kwargs) > rather than def call(f, *args, **kwargs): return f(*args, **kwargs)

arathore 5y ago

> When printing tracebacks, the interpreter will now point to the exact expression that caused the error instead of just the line. For example: Traceback (most recent call last): File "distance.py", line 11, in <module> print(manhattan_distance(p1, p2)) ^^^^^^^^^^^^^^^^^^^^^^^^^^ File "distance.py", line 6, in manhattan_distance return abs(point_1.x - point_2.x) + abs(point_1.y - point_2.y) ^^^^^^^^^ AttributeError: 'NoneType' object has no attribute 'x' This is such a great quality of life improvement.

RheingoldRiver 5y ago
This is an INCREDIBLE improvement. I'm so excited for it for myself, and I think it will also do wonders for getting new programmers comfortable with the language. Seeing exactly where in the line your error is, is amazing! IMO this 100% cements Python as the single most newbie-friendly language, if there was any question before now (or at least, before the release of 3.11).
- pletnes 5y ago
  I already move code into separate lines since this is currently missing. This is great indeed. (Although that might still make sense for debugging)
  - throwaway81523 5y ago
    It would sure be great if they made it easier to break to the debugger in case of an unhandled exception, like (setq debug-on-error t) in Emacs Lisp.
    - pletnes 5y ago
      This can be done in some IDEs. Although it can get confusimg if you’re working in an app framework that does some sort of catch-all exception handling.
      - 5y ago

radus 5y ago

Some nice changes: > “Zero-cost” exceptions are implemented. The cost of try statements is almost eliminated when no exception is raised. (Contributed by Mark Shannon in bpo-40222.) > Method calls with keywords are now faster due to bytecode changes which avoid creating bound method instances.

MarkSweep 5y ago

This all all exciting stuff, but 3.11 comes out in 2022. 3.10 is supposed to come out tomorrow though, you can checkout it's "What's New" here: https://docs.python.org/3.10/whatsnew/3.10.html https://docs.python.org/3.10/whatsnew/3.10.html 3.10 release schedule: https://www.python.org/dev/peps/pep-0619/ https://www.python.org/dev/peps/pep-0619/

eink-reader-32 5y ago

I noticed on https://www.python.org/downloads/ https://www.python.org/downloads/ I only see up to python 3.9. Where is 3.10 and 3.11 downloads? whats the best way to install python?

EmilStenstrom 5y ago
3.10 will be released tomorrow. 3.11 is still very much work in progress and is expected to drop in 2022.
- eink-reader-32 5y ago
  Thanks this is what I was looking for. Don't know why i was down-voted for asking

eesmith 5y ago

I really enjoyed reading the discussion about the updates to TimSort, at https://bugs.python.org/issue34561 https://bugs.python.org/issue34561 .

powersnail 5y ago

The deprecation of lib2to3 has occasioned some difficulties for formatters. Neither `black` nor `yapf` can correctly format a script with the `match` syntax introduced in python 3.10, while python 3.10 is formally released tomorrow. It seems that transitioning to the new PEG parser isn't a trivial work. Certainly glad to see python 3.11 having so much performance improvements.

azinman2 5y ago

> bpo-44590: All necessary data for executing a Python function (local variables, stack, etc) is now kept in a per-thread stack. Frame objects are lazily allocated on demand. This increases performance by about 7% on the standard benchmark suite. Introspection and debugging are unaffected as frame objects are always available when needed. Patch by Mark Shannon That’s pretty massive! My impression of CPython was there were few performance improvements globally since 3. I’m having trouble finding benchmarks for all the minor versions.

vland 5y ago
7% is massive for C, nothing for Python, and the benchmark suite is unreliable. I'd wait for independent measurements in real world applications. Python core developers are very good at writing bloated benchmark suites that are so convoluted that no one knows what is going on. Since more than two decades, big projects like "The need for speed", pythonspeed.com pop up periodically without anything happening. But apparently that's enough to get folks excited.