4 ms·

What's new: https://docs.python.org/dev/whatsnew/3.12.html https://docs.python.org/dev/whatsnew/3.12.html Summary, sorry for poor formatting, I'm not sure HN c

What's new: https://docs.python.org/dev/whatsnew/3.12.html https://docs.python.org/dev/whatsnew/3.12.html Summary, sorry for poor formatting, I'm not sure HN can do a list of any kind? New features More flexible f-string parsing, allowing many things previously disallowed (PEP 701). Support for the buffer protocol in Python code (PEP 688). A new debugging/profiling API (PEP 669). Support for isolated subinterpreters with separate Global Interpreter Locks (PEP 684). Even more improved error messages. More exceptions potentially caused by typos now make suggestions to the user. Support for the Linux perf profiler to report Python function names in traces. Many large and small performance improvements (like PEP 709 and support for the BOLT binary optimizer), delivering an estimated 5% overall performance improvement. Type annotations New type annotation syntax for generic classes (PEP 695). New override decorator for methods (PEP 698). Deprecations The deprecated wstr and wstr_length members of the C implementation of unicode objects were removed, per PEP 623. In the unittest module, a number of long deprecated methods and classes were removed. (They had been deprecated since Python 3.1 or 3.2). The deprecated smtpd and distutils modules have been removed (see PEP 594 and PEP 632. The setuptools package continues to provide the distutils module. A number of other old, broken and deprecated functions, classes and methods have been removed. Invalid backslash escape sequences in strings now warn with SyntaxWarning instead of DeprecationWarning, making them more visible. (They will become syntax errors in the future.) The internal representation of integers has changed in preparation for performance enhancements. (This should not affect most users as it is an internal detail, but it may cause problems for Cython-generated code.)

liquidpele 3y ago
Tbh the f-string stuff sounds pretty in-pythonic to me… like it would make it much harder to read and abuse.
- notatallshaw 3y ago
  What is or isn't "pythonic" is largely determined by the community not the language. Nothing is stopping the Python community from monkey patching everything like the Ruby community does. The f-string changes arrived because there was a need to formalize the syntax, so other Python parsers, for CPython to move off having a special sub-parser just for f-strings, and to be able decide whether weird edge cases were bugs or features. Once formalized it was decided not to put arbitrary limits on it just because people can write badly formatted code, people are can already do that and it's up to the Python community to choose what is or isn't "Pythonic". FYI, one of the things I'm really looking forward to is being able to write: f"Rows: {'\n'.join(rows)}\n Done!" Which in Python 3.11 is illegal syntax.
- actuallyalys 3y ago
  Python tends to be permissive and rely on convention over preventing certain practices, sometimes summed up as "we are all consenting adults." E.g., there's multiple inheritance, no private variables, and monkeypatching. I see this change as in the same vein. This change also makes it conceptually simpler [0]. It also appears to reduce technical debt by reducing differences between expressions in f-strings and in the rest of the language. [0]: https://peps.python.org/pep-0701/#how-to-teach-this https://peps.python.org/pep-0701/#how-to-teach-this
satvikpendem 3y ago
> I'm not sure HN can do a list of any kind? It can, just use `-` characters for bullets, like in Markdown. They won't render as Unicode bullet points but dashes are fine enough.
- simonw 3y ago
  You have to leave two newlines between each one though. - If you don't - Your list looks like this Whereas: - This list - Has two newlines between - Each item
  - deleted 3y ago
    [deleted]
H8crilA 3y ago
Isolated subinterpreters (PEP 684): Just how isolated are those? Is it simply a more complicated version of multiprocessing, with all the same drawbacks (communication via pipes/socket/some-other-stream)?
- progval 3y ago
  They run in the same process and can use channels for communication. https://lwn.net/Articles/820424/ https://lwn.net/Articles/820424/
- IshKebab 3y ago
  It's a less complicated version of multiprocessing because you don't have to deal with multiple processes and all the complexity that that entails. It's basically web workers / isolates for Python.
  - H8crilA 3y ago
    It looks more complicated. You get the same cumbersome communication primitive (channels), except now native code can easily get messed up. And it requires more care when developing the interpreter itself. Using multiprocessing was actually pretty easy (apart from the communication primitives, which obviously suck).
    - IshKebab 3y ago
      Multiprocessing means you need to deal with signals (which are ancient and powerful footguns), handle processes being killed, platform differences (fork vs spawn), etc. It really is a bad solution. Isolates are much much better. > You get the same cumbersome communication primitive (channels), except now native code can easily get messed up. I'm not sure what you mean by that. Native code has to be thread safe sure, but now it also can be thread safe! You can have native code that is actually properly multithreaded. A big win. > And it requires more care when developing the interpreter itself. Maybe. Not really an issue for the user though.
thanatropism 3y ago
What are the advantage of Cython over something like C++ with pybind11 or whatever the equivalent in Rustland?
- nurettin 3y ago
  It lets you refactor your code to line by line.
- claytonjy 3y ago
  Cython is similar to python and is fairly easy to write for a python user, while C++ or Rust have much larger learning curves.
  - ynik 3y ago
    However if one is using C++/Rust anyways, then it's a good idea to stay away from Cython. From afar, Cython seems like a viable solution for Python/C++ interop. But the details get messy: you need to clone the .h headers into .pxd Cython-readable headers; and more advanced template-magic C++ constructs may end up being not directly usable in Cython due to missing features or bugs in the C++ support. In the end, we ended up with quite a number of layers wrapping each other: 1. actual C++ implementation 2. actual C++ header 3. C++ wrapper implementation, avoiding constructs that Cython doesn't support 4. C++ wrapper header 5. Cython .pxd for step 4 6. Cython .pyx exposing `cdef class`es to Python with a nice Python-style API for the original C++ library. 7. Hand-written .pyi for type checking the remaining Python code, because Cython doesn't have support for auto-generating these yet. Had we used pybind11 / nanobind instead, we could have stopped at step 3. Cython started easy, but ended up being a major maintenance burden.
- deleted 3y ago
  [deleted]

liquidpele 3y ago

Tbh the f-string stuff sounds pretty in-pythonic to me… like it would make it much harder to read and abuse.

notatallshaw 3y ago
What is or isn't "pythonic" is largely determined by the community not the language. Nothing is stopping the Python community from monkey patching everything like the Ruby community does. The f-string changes arrived because there was a need to formalize the syntax, so other Python parsers, for CPython to move off having a special sub-parser just for f-strings, and to be able decide whether weird edge cases were bugs or features. Once formalized it was decided not to put arbitrary limits on it just because people can write badly formatted code, people are can already do that and it's up to the Python community to choose what is or isn't "Pythonic". FYI, one of the things I'm really looking forward to is being able to write: f"Rows: {'\n'.join(rows)}\n Done!" Which in Python 3.11 is illegal syntax.
actuallyalys 3y ago
Python tends to be permissive and rely on convention over preventing certain practices, sometimes summed up as "we are all consenting adults." E.g., there's multiple inheritance, no private variables, and monkeypatching. I see this change as in the same vein. This change also makes it conceptually simpler [0]. It also appears to reduce technical debt by reducing differences between expressions in f-strings and in the rest of the language. [0]: https://peps.python.org/pep-0701/#how-to-teach-this https://peps.python.org/pep-0701/#how-to-teach-this

satvikpendem 3y ago

> I'm not sure HN can do a list of any kind? It can, just use `-` characters for bullets, like in Markdown. They won't render as Unicode bullet points but dashes are fine enough.

simonw 3y ago
You have to leave two newlines between each one though. - If you don't - Your list looks like this Whereas: - This list - Has two newlines between - Each item
- deleted 3y ago
  [deleted]

H8crilA 3y ago

Isolated subinterpreters (PEP 684): Just how isolated are those? Is it simply a more complicated version of multiprocessing, with all the same drawbacks (communication via pipes/socket/some-other-stream)?

progval 3y ago
They run in the same process and can use channels for communication. https://lwn.net/Articles/820424/ https://lwn.net/Articles/820424/
IshKebab 3y ago
It's a less complicated version of multiprocessing because you don't have to deal with multiple processes and all the complexity that that entails. It's basically web workers / isolates for Python.
- H8crilA 3y ago
  It looks more complicated. You get the same cumbersome communication primitive (channels), except now native code can easily get messed up. And it requires more care when developing the interpreter itself. Using multiprocessing was actually pretty easy (apart from the communication primitives, which obviously suck).
  - IshKebab 3y ago
    Multiprocessing means you need to deal with signals (which are ancient and powerful footguns), handle processes being killed, platform differences (fork vs spawn), etc. It really is a bad solution. Isolates are much much better. > You get the same cumbersome communication primitive (channels), except now native code can easily get messed up. I'm not sure what you mean by that. Native code has to be thread safe sure, but now it also can be thread safe! You can have native code that is actually properly multithreaded. A big win. > And it requires more care when developing the interpreter itself. Maybe. Not really an issue for the user though.

thanatropism 3y ago

What are the advantage of Cython over something like C++ with pybind11 or whatever the equivalent in Rustland?

nurettin 3y ago
It lets you refactor your code to line by line.
claytonjy 3y ago
Cython is similar to python and is fairly easy to write for a python user, while C++ or Rust have much larger learning curves.
- ynik 3y ago
  However if one is using C++/Rust anyways, then it's a good idea to stay away from Cython. From afar, Cython seems like a viable solution for Python/C++ interop. But the details get messy: you need to clone the .h headers into .pxd Cython-readable headers; and more advanced template-magic C++ constructs may end up being not directly usable in Cython due to missing features or bugs in the C++ support. In the end, we ended up with quite a number of layers wrapping each other: 1. actual C++ implementation 2. actual C++ header 3. C++ wrapper implementation, avoiding constructs that Cython doesn't support 4. C++ wrapper header 5. Cython .pxd for step 4 6. Cython .pyx exposing `cdef class`es to Python with a nice Python-style API for the original C++ library. 7. Hand-written .pyi for type checking the remaining Python code, because Cython doesn't have support for auto-generating these yet. Had we used pybind11 / nanobind instead, we could have stopped at step 3. Cython started easy, but ended up being a major maintenance burden.
deleted 3y ago
[deleted]