Mailman 3 July 2022 - Python-Dev

CACHE opcode in Python 3.11 bytecode
by Matthieu Dartiailh 25 Jul '22

25 Jul '22

Hi all, I am in the slow process of adding support for Python 3.11 in the bytecode project (https://github.com/MatthieuDartiailh/bytecode). While attempting to update some tests I stumbled upon the need to include CACHE opcode to get things to work. For example, one can use bytecode to manually assemble the bytecode for the function: def f(): return 24 < 42 Under Python 3.10 it would look like: f.__code__= Bytecode( [ Instr("LOAD_CONST", 24), Instr("LOAD_CONST", 42), Instr("COMPARE_OP", Compare.LT), Instr("RETURN_VALUE"), ] ).to_code() Under Python 3.11 I had to go to: f.__code__= Bytecode( [ Instr("RESUME", 0), Instr("LOAD_CONST", 24), Instr("LOAD_CONST", 42), Instr("COMPARE_OP", Compare.LT), Instr("CACHE", 0), Instr("CACHE", 0), Instr("RETURN_VALUE"), ] ).to_code() Reading the doc for the dis module I understand the need for the RESUME instruction. However the documentation is rather vague in regard of CACHE. In particular when using the first version, the code in the function ends up looking like '\x97\x00d\x00d\x01k\x00\x00\x00\x00\x00' even though bytecode generated '\x97\x00d\x00d\x01k\x00S\x00'. One can "see" that the two caches (\x00\x00\x00\x00) have been added automatically but the return disappeared. Is this a bug in 3.11 and if not where can I find more details regarding where one expect CACHE instructions to be present ? Best Matthieu C. Dartiailh PS: I know the mailing list is going to be retired but I did not yet got everything configured for Discourse.

2 1

PEP 563 and Python 3.10.
by Thomas Wouters 22 Jul '22

22 Jul '22

(Starting a new thread so as not to derail any of the ongoing discussions.) Thanks, everyone, for your thoughts on Python 3.10 and the impact of PEP 563 (postponed evaluation of annotations) becoming the default. The Steering Council has considered the issue carefully, along with many of the proposed alternatives and solutions, and we’ve decided that at this point, we simply can’t risk the compatibility breakage of PEP 563. We need to roll back the change that made stringified annotations the default, at least for 3.10. (Pablo is already working on this.) To be clear, we are not reverting PEP 563 itself. The future import will keep working like it did since Python 3.7. We’re delaying making PEP 563 string-based annotations the default until Python 3.11. This will give us time to find a solution that works for everyone (or to find a feasible upgrade path for users who currently rely on evaluated annotations). Some considerations that led us to this decision: - PEP 563’s default change is clearly too disruptive to downstream users and third-party libraries to happen right now. We can’t risk breaking even a small subset of the FastAPI/pydantic users, not to mention other uses of evaluated type annotations that we’re not aware of yet. - PEP 563 provides no warning to users of the feature it’s disabling. Without that, we can’t expect users to be aware of the upcoming breakage. The lack of a warning was by design, and made sense in a world where type annotations were only consumed by static type checkers --- but that’s not actually the situation we’re in. There are clearly existing real-world, run-time uses of type annotations that would be adversely affected by this change. - Originally, PEP 563 was scheduled to take effect in Python 4, and this changed recently (after the discussion in the Language Summit of 2020). It's possible that third-party libraries and users didn’t plan to react in the current time frame as they were not aware of this change in timing. - There isn’t enough time to properly discuss PEP 649 or any of the alternatives before the beta 1 deadline, and we really need to make sure we don’t compound errors here. We need to look for a long term solution, which isn’t possible while still maintaining the release deadlines of Python 3.10. That means we’re also deferring PEP 649 to Python 3.11. In the Steering Council’s unanimous opinion, rolling back the default flip for stringified annotations in Python 3.10 is the least disruptive of all the options. We need to continue discussing the issue and potential solutions, since this merely postpones the problem until 3.11. (For the record, postponing the change further is not off the table, either, for example if the final decision is to treat evaluated annotations as a deprecated feature, with warnings on use.) For what it’s worth, the SC is also considering what we can do to reduce the odds of something like this happening again, but that’s a separate consideration, and a multi-faceted one at that. For the Steering Council, Thomas. -- Thomas Wouters <thomas(a)python.org> Hi! I'm an email virus! Think twice before sending your email to help me spread!

6 5

Do not harass other mailing list subscribers privately
by Brett Cannon 20 Jul '22

20 Jul '22

The SC has been notified of at least one instance of someone subscribed to this list harassing another subscriber privately. We wanted to remind folks that we expect people to behave reasonably towards each other, else people risk losing access to this mailing list and other places where Python is developed per the Code of Conduct. Poor behaviour, public or private, is not acceptable and will have ramifications where we are trying to facilitate an open, considerate, and respectful community that is under our control. -Brett, on behalf of the Python steering council

2 1

compiling errors, SSL
by Kevin T 20 Jul '22

20 Jul '22

I have built this on systems at work, that are populated by CAD guys who have developed a good set of libraries to maintain in a linux distribution. Went without a hitch. I am trying to build this at home with an opensuse distribution. I am not trying to do any modifications to python, now or in the future. I am trying to build this as another software installation wants 3.7 or better and opensuse provided 3.6. I am stuck with a early compile error after the make command. I have downloaded, built and installed the openSSl.I have changed the ld.so.conf to include the newly built ssl in the list and re-ran ldconfig. Even though I have added the newly built ssl to the conf file a dump of the ldconfig does not show the locally built ssl libs. Does this process depend on LD_LIBRARY_PATH ? Defining LD_LIBRARY_PATH made no discernable difference. kevin@localhost:~/Sources/Python-3.10.5> sudo ldconfig -p | grep ssl [sudo] password for root: libssl3.so (libc6,x86-64) => /usr/lib64/libssl3.so libssl.so.1.1 (libc6,x86-64) => /usr/lib64/libssl.so.1.1 libevent_openssl-2.1.so.6 (libc6,x86-64) => /usr/lib64/libevent_openssl-2.1.so.6 The newly built ssl dir:kevin@localhost:~/Sources/Python-3.10.5> ls -lrt /usr/local/ssl total 40 drwxr-xr-x 1 root root 14 Jul 18 15:17 include drwxr-xr-x 1 root root 190 Jul 18 15:17 lib64 drwxr-xr-x 1 root root 30 Jul 18 15:17 bin drwxr-xr-x 1 root root 0 Jul 18 15:17 private drwxr-xr-x 1 root root 0 Jul 18 15:17 certs drwxr-xr-x 1 root root 36 Jul 18 15:17 misc -rw-r--r-- 1 root root 12292 Jul 18 15:17 openssl.cnf.dist -rw-r--r-- 1 root root 12292 Jul 18 15:17 openssl.cnf -rw-r--r-- 1 root root 412 Jul 18 15:17 ct_log_list.cnf.dist -rw-r--r-- 1 root root 412 Jul 18 15:17 ct_log_list.cnf drwxr-xr-x 1 root root 12 Jul 18 15:18 share I see in the web pages the known prerequisites and installed them.kevin@localhost:/usr/local/ssl/lib64> sudo zypper install python310-idle python310-devel python310-curses python310-dbm python310-tk kevin@localhost:/usr/local/ssl/lib64> sudo zypper install build-essential gdb lcov pkg-config libbz2-dev libffi-dev libgdbm-dev libgdbm-compat-dev liblzma-dev libncur ses5-dev libreadline6-dev libsqlite3-dev libssl-dev lzma lzma-dev tk-dev uuid-dev zlib1g-dev I see in the web pages this snip:Python build finished successfully! The necessary bits to build these optional modules were not found: _bz2 _dbm _gdbm _lzma _sqlite3 _ssl _tkinter _uuid readline zlib To find the necessary bits, look in setup.py in detect_modules() for the module's name.What is one supposed to do with detect_modules? Add something or remove something ? This is the config line: kevin@localhost:~/Sources/Python-3.10.5> ./configure --prefix=/usr/local --enable-optimizations --with-openssl=/usr/local/ssl --with-openssl-rpath=auto This is output from make: kevin@localhost:~/Sources/Python-3.10.5> make Rebuilding with profile guided optimizations: rm -f profile-clean-stamp make build_all CFLAGS_NODIST=" -fprofile-use -fprofile-correction" LDFLAGS_NODIST="" make[1]: Entering directory '/home/kevin/Sources/Python-3.10.5' gcc -pthread -c -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -fno-semantic-interposition -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-miss ing-field-initializers -Werror=implicit-function-declaration -fvisibility=hidden -fprofile-use -fprofile-correction -I./Include/internal -I. -I./Include -DPy_BUILD_CORE \ -DABIFLAGS='""' \ -DMULTIARCH=\"x86_64-linux-gnu\" \ -o Python/sysmodule.o ./Python/sysmodule.c gcc -pthread -c -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -fno-semantic-interposition -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-miss ing-field-initializers -Werror=implicit-function-declaration -fvisibility=hidden -fprofile-use -fprofile-correction -I./Include/internal -I. -I./Include -DPy_BUILD_CORE \ -DSOABI='"cpython-310-x86_64-linux-gnu"' \ -o Python/dynload_shlib.o ./Python/dynload_shlib.c gcc -pthread -c -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -fno-semantic-interposition -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-miss ing-field-initializers -Werror=implicit-function-declaration -fvisibility=hidden -fprofile-use -fprofile-correction -I./Include/internal -I. -I./Include -DPy_BUILD_CORE -o Mo dules/config.o Modules/config.c gcc -pthread -c -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -fno-semantic-interposition -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-miss ing-field-initializers -Werror=implicit-function-declaration -fvisibility=hidden -fprofile-use -fprofile-correction -I./Include/internal -I. -I./Include -DPy_BUILD_CORE -DPYT HONPATH='""' \ -DPREFIX='"/usr/local"' \ -DEXEC_PREFIX='"/usr/local"' \ -DVERSION='"3.10"' \ -DVPATH='""' \ -o Modules/getpath.o ./Modules/getpath.c gcc -pthread -c -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -fno-semantic-interposition -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-miss ing-field-initializers -Werror=implicit-function-declaration -fvisibility=hidden -fprofile-use -fprofile-correction -I./Include/internal -I. -I./Include -DPy_BUILD_CORE \ -DGITVERSION="\"`LC_ALL=C `\"" \ -DGITTAG="\"`LC_ALL=C `\"" \ -DGITBRANCH="\"`LC_ALL=C `\"" \ -o Modules/getbuildinfo.o ./Modules/getbuildinfo.c rm -f libpython3.10.a ar rcs libpython3.10.a Modules/getbuildinfo.o Parser/token.o Parser/pegen.o Parser/parser.o Parser/string_parser.o Parser/peg_api.o Parser/myreadline.o Parser/tokenizer.o Object s/abstract.o Objects/accu.o Objects/boolobject.o Objects/bytes_methods.o Objects/bytearrayobject.o Objects/bytesobject.o Objects/call.o Objects/capsule.o Objects/cellobject.o Obj ects/classobject.o Objects/codeobject.o Objects/complexobject.o Objects/descrobject.o Objects/enumobject.o Objects/exceptions.o Objects/genericaliasobject.o Objects/genobject.o O bjects/fileobject.o Objects/floatobject.o Objects/frameobject.o Objects/funcobject.o Objects/interpreteridobject.o Objects/iterobject.o Objects/listobject.o Objects/longobject.o Objects/dictobject.o Objects/odictobject.o Objects/memoryobject.o Objects/methodobject.o Objects/moduleobject.o Objects/namespaceobject.o Objects/object.o Objects/obmalloc.o Obje cts/picklebufobject.o Objects/rangeobject.o Objects/setobject.o Objects/sliceobject.o Objects/structseq.o Objects/tupleobject.o Objects/typeobject.o Objects/unicodeobject.o Objec ts/unicodectype.o Objects/unionobject.o Objects/weakrefobject.o Python/_warnings.o Python/Python-ast.o Python/asdl.o Python/ast.o Python/ast_opt.o Python/ast_unparse.o Python/blt inmodule.o Python/ceval.o Python/codecs.o Python/compile.o Python/context.o Python/dynamic_annotations.o Python/errors.o Python/frozenmain.o Python/future.o Python/getargs.o Pyth on/getcompiler.o Python/getcopyright.o Python/getplatform.o Python/getversion.o Python/hamt.o Python/hashtable.o Python/import.o Python/importdl.o Python/initconfig.o Python/mars hal.o Python/modsupport.o Python/mysnprintf.o Python/mystrtoul.o Python/pathconfig.o Python/preconfig.o Python/pyarena.o Python/pyctype.o Python/pyfpe.o Python/pyhash.o Python/py lifecycle.o Python/pymath.o Python/pystate.o Python/pythonrun.o Python/pytime.o Python/bootstrap_hash.o Python/structmember.o Python/symtable.o Python/sysmodule.o Python/thread.o Python/traceback.o Python/getopt.o Python/pystrcmp.o Python/pystrtod.o Python/pystrhex.o Python/dtoa.o Python/formatter_unicode.o Python/fileutils.o Python/suggestions.o Python/ dynload_shlib.o Modules/config.o Modules/getpath.o Modules/main.o Modules/gcmodule.o Modules/posixmodule.o Modules/errnomodule.o Modules/pwdmodule.o Modules/_sre.o Modules /_codecsmodule.o Modules/_weakref.o Modules/_functoolsmodule.o Modules/_operator.o Modules/_collectionsmodule.o Modules/_abc.o Modules/itertoolsmodule.o Modules/atexitmodu le.o Modules/signalmodule.o Modules/_stat.o Modules/timemodule.o Modules/_threadmodule.o Modules/_localemodule.o Modules/_iomodule.o Modules/iobase.o Modules/fileio.o Modul es/bytesio.o Modules/bufferedio.o Modules/textio.o Modules/stringio.o Modules/faulthandler.o Modules/_tracemalloc.o Modules/symtablemodule.o Modules/xxsubtype.o Python/frozen .o gcc -pthread -fno-semantic-interposition -Xlinker -export-dynamic -o python Programs/python.o libpython3.10.a -lcrypt -lpthread -ldl -lutil -lm -lm ./python -E -S -m sysconfig --generate-posix-vars ;\ if test $? -ne 0 ; then \ echo "generate-posix-vars failed" ; \ rm -f ./pybuilddir.txt ; \ exit 1 ; \ fi CC='gcc -pthread' LDSHARED='gcc -pthread -shared -fno-semantic-interposition ' OPT='-DNDEBUG -g -fwrapv -O3 -Wall' _TCLTK_INCLUDES='' _TCLTK_LIBS='' ./python -E ./setu p.py build running build running build_ext INFO: Can't locate Tcl/Tk libs and/or headers building '_ssl' extension gcc -pthread -fPIC -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -fno-semantic-interposition -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-miss ing-field-initializers -Werror=implicit-function-declaration -fvisibility=hidden -fprofile-use -fprofile-correction -I./Include/internal -I/usr/local/ssl/include -I./Include -I. -I/usr/local/include -I/home/kevin/Sources/Python-3.10.5/Include -I/home/kevin/Sources/Python-3.10.5 -c /home/kevin/Sources/Python-3.10.5/Modules/_ssl.c -o build/temp.linux-x86_6 4-3.10/home/kevin/Sources/Python-3.10.5/Modules/_ssl.o /home/kevin/Sources/Python-3.10.5/Modules/_ssl.c: In function ‘PyInit__ssl’: /home/kevin/Sources/Python-3.10.5/Modules/_ssl.c:6238:1: warning: ‘/home/kevin/Sources/Python-3.10.5/build/temp.linux-x86_64-3.10/home/kevin/Sources/Python-3.10.5/Modules/_ssl.gc da’ profile count data file not found [-Wmissing-profile] 6238 | } | ^ gcc -pthread -shared -fno-semantic-interposition build/temp.linux-x86_64-3.10/home/kevin/Sources/Python-3.10.5/Modules/_ssl.o -L/usr/local/ssl/lib -L/usr/local/lib -Wl,--enable-n ew-dtags,-R/usr/local/ssl/lib -lssl -lcrypto -o build/lib.linux-x86_64-3.10/_ssl.cpython-310-x86_64-linux-gnu.so /usr/bin/ld: cannot find -lssl /usr/bin/ld: cannot find -lcrypto collect2: error: ld returned 1 exit status building '_hashlib' extension gcc -pthread -fPIC -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -fno-semantic-interposition -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-miss ing-field-initializers -Werror=implicit-function-declaration -fvisibility=hidden -fprofile-use -fprofile-correction -I./Include/internal -I/usr/local/ssl/include -I./Include -I. -I/usr/local/include -I/home/kevin/Sources/Python-3.10.5/Include -I/home/kevin/Sources/Python-3.10.5 -c /home/kevin/Sources/Python-3.10.5/Modules/_hashopenssl.c -o build/temp.lin ux-x86_64-3.10/home/kevin/Sources/Python-3.10.5/Modules/_hashopenssl.o /home/kevin/Sources/Python-3.10.5/Modules/_hashopenssl.c: In function ‘PyInit__hashlib’: /home/kevin/Sources/Python-3.10.5/Modules/_hashopenssl.c:2287:1: warning: ‘/home/kevin/Sources/Python-3.10.5/build/temp.linux-x86_64-3.10/home/kevin/Sources/Python-3.10.5/Modules /_hashopenssl.gcda’ profile count data file not found [-Wmissing-profile] 2287 | } | ^ gcc -pthread -shared -fno-semantic-interposition build/temp.linux-x86_64-3.10/home/kevin/Sources/Python-3.10.5/Modules/_hashopenssl.o -L/usr/local/ssl/lib -L/usr/local/lib -Wl,-- enable-new-dtags,-R/usr/local/ssl/lib -lssl -lcrypto -o build/lib.linux-x86_64-3.10/_hashlib.cpython-310-x86_64-linux-gnu.so /usr/bin/ld: cannot find -lssl /usr/bin/ld: cannot find -lcrypto collect2: error: ld returned 1 exit status Python build finished successfully! The necessary bits to build these optional modules were not found: _dbm _gdbm _lzma _sqlite3 _tkinter nis readline To find the necessary bits, look in setup.py in detect_modules() for the module's name. The following modules found by detect_modules() in setup.py, have been built by the Makefile instead, as configured by the Setup files: _abc pwd time Failed to build these modules: _hashlib _ssl Could not build the ssl module! Python requires a OpenSSL 1.1.1 or newer Custom linker flags may require --with-openssl-rpath=auto running build_scripts copying and adjusting /home/kevin/Sources/Python-3.10.5/Tools/scripts/pydoc3 -> build/scripts-3.10 copying and adjusting /home/kevin/Sources/Python-3.10.5/Tools/scripts/idle3 -> build/scripts-3.10 copying and adjusting /home/kevin/Sources/Python-3.10.5/Tools/scripts/2to3 -> build/scripts-3.10 changing mode of build/scripts-3.10/pydoc3 from 644 to 755 changing mode of build/scripts-3.10/idle3 from 644 to 755 changing mode of build/scripts-3.10/2to3 from 644 to 755 renaming build/scripts-3.10/pydoc3 to build/scripts-3.10/pydoc3.10 renaming build/scripts-3.10/idle3 to build/scripts-3.10/idle3.10 renaming build/scripts-3.10/2to3 to build/scripts-3.10/2to3-3.10 gcc -pthread -fno-semantic-interposition -Xlinker -export-dynamic -o Programs/_testembed Programs/_testembed.o libpython3.10.a -lcrypt -lpthread -ldl -lutil -lm -lm sed -e "s,@EXENAME@,/usr/local/bin/python3.10," < ./Misc/python-config.in >python-config.py LC_ALL=C sed -e 's,\$($[A-Za-z0-9_]*$),\$\{\1\},g' < Misc/python-config.sh >python-config make[1]: Leaving directory '/home/kevin/Sources/Python-3.10.5' This looks to me like it is having problems with finding the ssl and causing the failure. Is it looking for 32bit versions? How do I tell it that there are no 32bit versions. Thanks for your attention. Kevin

2 1

Presenting PEP 692: Using TypedDict for more precise **kwargs typing
by Franek Magiera 18 Jul '22

18 Jul '22

PEP 692 is posted. It proposes to use TypedDict for more precise **kwargs typing, so that **kwargs consisting of arguments of different types can be appropriately typed. It also proposes a grammar change and a new dunder. Here is a link to the PEP: https://peps.python.org/pep-0692/ And a link to the discuss thread: https://discuss.python.org/t/pep-692-using-typeddict-for-more-precise-kwarg…

1 0

[RELEASE] The cursed fourth Python 3.11 beta (3.11.0b4) is available
by Pablo Galindo Salgado 16 Jul '22

16 Jul '22

I cannot believe I am writing this, but Python 3.11.b4 is finally available!! [image: :scream:] [image: :tada:] [image: :tada:] [image: :tada:] https://www.python.org/downloads/release/python-3110b4/ ##[image: :warning:][image: :warning:][image: :warning:] PLEASE HELP US TO TEST THIS RELEASE [image: :warning:][image: :warning:][image: :warning:] Due to the modified release schedule and the stability concerns regarding the past beta releases, please, please, please, please, help us to test Python 3.11 by testing this beta releases. * if you maintain a library or a third-party package. Test the beta releases! * If you have code that you maintain at work/research centre/classroom/whatever. Test the beta releases! * If you are a multi-million corporation that uses Python. Test the beta releases! * If you are a single-person company that uses Python. Test the beta releases! * If you have a bunch of Python scripts. Test the beta releases! * If you use Python for work, research, teaching or literally for anything. Test the beta releases! * If you ... In summary: no matter who you are or what you do. Test the beta releases! Is **very** important for us that we identify all possible things that may break your code **before** the final release is done and we can only do this if you help us by testing the beta releases and then report anything that doesn't work! ## Credit where credit is due [image: :pray:] Lots of thanks to Christian Heimes, Brandt Bucher, Irit Katriel, Mark Shannon, Dennis Sweeney, Kumar Aditya and other contributors (sorry if I am missing any names) that worked really hard against time to help me and the release team with the release blockers. They are all awesome and we and the Python community are very lucky to have them in the team [image: :heart:] ## What happens with the next betas? As stated in [my previous communication]( https://mail.python.org/archives/list/python-dev@python.org/thread/3JWVCSBP…) we are in a special situation regarding beta releases. As the requirements to continue with the regular schedule are met, we are going to still target the final release of Monday, 2022-10-03. Python 3.11.0b5 was supposed to be released two days ago, so we are obviously delayed. As we are targeting the regular release schedule, I'm going to try to release 3.11.0b5 on Thursday, 2022-07-25. ## This is a beta preview of Python 3.11 Python 3.11 is still in development. 3.11.0b4 is the fourth of five planned beta release previews. Beta release previews are intended to give the wider community the opportunity to test new features and bug fixes and to prepare their projects to support the new feature release. We **strongly encourage** maintainers of third-party Python projects to **test with 3.11** during the beta phase and report issues found to [the Python bug tracker](https://github.com/python/cpython/issues) as soon as possible. While the release is planned to be feature complete entering the beta phase, it is possible that features may be modified or, in rare cases, deleted up until the start of the release candidate phase (Monday, 2021-08-02). Our goal is have no ABI changes after beta 5 and as few code changes as possible after 3.11.0rc1, the first release candidate. To achieve that, it will be **extremely important** to get as much exposure for 3.11 as possible during the beta phase. Please keep in mind that this is a preview release and its use is **not** recommended for production environments. # Major new features of the 3.11 series, compared to 3.10 Some of the new major new features and changes in Python 3.11 are: ## General changes * [PEP 657](https://www.python.org/dev/peps/pep-0657/) -- Include Fine-Grained Error Locations in Tracebacks * [PEP 654](https://www.python.org/dev/peps/pep-0654/) -- Exception Groups and except* * [PEP 680](https://www.python.org/dev/peps/pep-0680/)-- tomllib: Support for Parsing TOML in the Standard Library * [PEP 681](https://www.python.org/dev/peps/pep-0681/)-- Data Class Transforms * [bpo-46752](https://bugs.python.org/issue46752)-- Introduce task groups to asyncio * [bpo-433030](https://github.com/python/cpython/issues/34627/) -- Atomic grouping ((?>...)) and possessive quantifiers (`*+, ++, ?+, {m,n}+`) are now supported in regular expressions. * The [Faster Cpython Project](https://github.com/faster-cpython/) is already yielding some exciting results. Python 3.11 is up to 10-60% faster than Python 3.10. On average, we measured a 1.22x speedup on the standard benchmark suite. See [Faster CPython]( https://docs.python.org/3.11/whatsnew/3.11.html#faster-cpython) for details. ## Typing and typing language changes * [PEP 673](https://www.python.org/dev/peps/pep-0673/) -- Self Type * [PEP 646](https://www.python.org/dev/peps/pep-0646/)-- Variadic Generics * [PEP 675](https://www.python.org/dev/peps/pep-0675/)-- Arbitrary Literal String Type * [PEP 655](https://www.python.org/dev/peps/pep-0655/)-- Marking individual TypedDict items as required or potentially-missing <small>(Hey, **fellow core developer,** if a feature you find important is missing from this list, [let Pablo know](mailto:pablogsal@python.org ).)</small> The next pre-release of Python 3.11 will be 3.11.0b5, currently scheduled for Thursday, 2022-07-25. # More resources * [Online Documentation](https://docs.python.org/3.11/) * [PEP 664](https://www.python.org/dev/peps/pep-0664/), 3.11 Release Schedule * Report bugs at [https://bugs.python.org](https://bugs.python.org). * [Help fund Python and its community](/psf/donations/). # And now for something completely different The Planck temperature is 1.416784×10**32 K. At this temperature, the wavelength of light emitted by thermal radiation reaches the Planck length. There are no known physical models able to describe temperatures greater than the Planck temperature and a quantum theory of gravity would be required to model the extreme energies attained. Hypothetically, a system in thermal equilibrium at the Planck temperature might contain Planck-scale black holes, constantly being formed from thermal radiation and decaying via Hawking evaporation; adding energy to such a system might decrease its temperature by creating larger black holes, whose Hawking temperature is lower. Rumours say the Planck temperature can be reached in some of the hottest parts of Spain in summer. # We hope you enjoy the new releases! Thanks to all of the many volunteers who help make Python Development and these releases possible! Please consider supporting our efforts by volunteering yourself or through organization contributions to the Python Software Foundation. https://www.python.org/psf/ If you have any questions, please reach out to me or another member of the release team :) Your friendly release team, Ned Deily @nad https://discuss.python.org/u/nad Steve Dower @steve.dower https://discuss.python.org/u/steve.dower Pablo Galindo Salgado @pablogsal https://discuss.python.org/u/pablogsal

7 10

Presenting PEP 695: Type Parameter Syntax
by Guido van Rossum 16 Jul '22

16 Jul '22

After several rounds of debate on typing-sig, I'd like to request feedback on PEP 695: https://peps.python.org/pep-0695/ I am sponsoring this PEP, which was written by Eric Traut. The PEP attempts to solve the problem that defining generic classes, functions and type aliases currently is lacking dedicated syntax, instead using the cumbersome `T = TypeVar("T", ...)` notation to create global variables that serve as type variables. As a personal historical note, I should mention that over 22 years ago I already pondered type parameters. In an old document that I saved I found the following code snippet: ``` def f<T> (a: T) -> T: ... ``` which is eerily close to the proposal in this PEP, except that the PEP uses square brackets: ``` def f[T](a: T) -> T: ... ``` It's been a long and circuitous road! I am not quoting the entire PEP here, please follow the link: https://peps.python.org/pep-0695/ -- --Guido van Rossum (python.org/~guido)

9 8

New `python` Organization Repository Policy
by Petr Viktorin 15 Jul '22

15 Jul '22

(Cross-posted from https://discuss.python.org/t/new-python-organization-repository-policy/17376 – please perfer commenting there.) Hello, When asked about adding the typing_extensions repository to the Python organization (https://github.com/python/steering-council/issues/126), the Steering Council discussed a general policy for the organization, as the current one (https://devguide.python.org/devcycle/#organization-repository-policy) seems outdated. We decided on the guidelines below. Note that existing repositories can stay under python. However, we will ask that: – PSF infrastructure be moved under the psf organization, and – all repositories under python will need to require the CLA and have two-factor authentication for all committers, otherwise move elsewhere or be archived. – Petr, on behalf of the Steering Council New Organization Repository Policy Within the GitHub Python organization, repositories are expected to relate to the Python language, the CPython reference implementation, their documentation and their development workflow. This includes, for example: - The reference implementation of Python and related repositories (i.e. CPython) - Tooling and support around CPython development (e.g. pyperformance, Bedevere) - Helpers and backports for Python/CPython features (e.g. typing-extensions, typeshed, tzdata, pythoncapi-compat) - Organization-related repositories (e.g. the Code of Conduct, .github) - Documentation and websites for all the above (e.g. python.org repository, PEPs, Devguide, docs translations) - Infrastructure for all the above (e.g. docsbuild-scripts, buildmaster-config) - Discussions and notes around official development-related processes and events (e.g. steering-council, core-sprint) Before adding a new repository, permission should be sought from the Python steering council. Note that several repositories remain in the organization for historic reasons, and would probably not be appropriate today. All non-archived repositories must require contributors to sign the PSF Contributor Agreement. Generally, new repositories should start their life under personal GitHub accounts or other GitHub orgs. It is relatively easy to move a repository to the organization once it is mature. For example, this would now apply to experimental features like asyncio, exceptiongroups or typed_ast and drafts of new guides and other documentation (e.g. redistributor-guide). General-use tools and libraries (e.g. mypy or black) should also be developed outside the python organization, unless core devs (as represented by the SC) specifically want to “bless” one implementation (as with e.g. typeshed, tzdata, or pythoncapi-compat).

3 2

Exceptions and tracebacks and frames, oh my!
by Yonatan Zunger 14 Jul '22

14 Jul '22

Hi everyone, Apologies for pinging the dev list; I'm shaving a very hairy yak, and the python-help crew, the docs, and the source are all unable to help. Context: I'm working on a library function to dump stack traces for all threads, sorta like _Py_DumpTracebackThreads but in Python and meant to be invoked from a high layer, and thus be pretty and readable and so on rather than signal-safe and robust. The hard part is combining data from thread stack frames and exceptions, since people generally want to know about these. What I'm having trouble understanding is the relationship between an exception's TB and the thread's frame. Two important differences I've noticed are that (a) the output of traceback.print_tb(sys.exc_info()[2]) and traceback.print_stack(sys.exc_info()[2].tb_frame) are markedly different -- the former gives data about where the exception was raised, while the latter about where the thread currently is, usually in an exception handler and (b) if I'm in a unittest and dump the stack for a thread starting from its current frame (using traceback.format_stack and sys._current_frames), it gives a very deep stack that includes all the unittest harness code etc., but if I dump the stack for an exception starting from its TB object, it instead is very short and focused on where the exception happened. All of which tells me that I don't understand the relationship between the exception's traceback object and the frames it points to at all. Is there somewhere that explains this particular bit of magic, or someone who's well-versed in it? I have to admit that after a few hours of spelunking the code, I can't even figure out how the exception traceback is being set in the first place. :) Again, apologies for bugging the dev list with what (I hope) is a simple question -- if there's a FM I should be reading, please let me know! Yonatan

2 1

Re: 3.11 enhanced error location - can it be smarter?
by John Belmonte 13 Jul '22

13 Jul '22

On 1/18/22 10:43 AM, Mats Wichmann wrote: > A thought - how about omitting the underline line if the > to-be-underlined part would be the whole line? I wasn't aware of this thread, but that's exactly what I implemented for 3.11.0b4. About this thread-- I understand debating solutions, but there was at least an agreement here about the problem. For visibility, it would have been better to open an issue than let the topic drop. (When filing the issue, I was wondering "how can I be alone thinking this is a problem?"-- then was surprised to see the support come out for the change.) Regards, --John

2 1