Mailman 3 July 2022 - Python-Dev

Proposal: Allow non-default after default arguments
by Sebastian Rittau Oct. 16, 2023

Oct. 16, 2023

Currently, Python doesn't allow non-default arguments after default arguments: >>> def foo(x=None, y): pass File "<stdin>", line 1 def foo(x=None, y): pass ^ SyntaxError: non-default argument follows default argument I believe that at the time this was introduced, no use cases for this were known and this is is supposed to … [View More]prevent a source of bugs. I have two use cases for this, one fringe, but valid, the other more important: The fringe use case: Suppose you have a function that takes a 2D coordinate value as separate "x" and "y" arguments. The "x" argument is optional, the "y" argument isn't. Currently there are two ways to do this, none of them particularly great: def foo(y, x): # reverse x and y arguments, confusing ... def foo(x, y=None): # Treat the x argument as y if only one argument is provided if y is None: x, y = y, x ... To me, the "natural" solution looks like this: def foo(x=None, y): ... # Called like this: foo(1, 2) foo(y=2) This could also be useful when evolving APIs. For example there is a function "bar" that takes two required arguments. In a later version, the first argument gains a useful default, the second doesn't. There is no sensible way to evolve the API at the moment. The more important use case involves @overloads. A condensed example of a function where the return type depends on an "encoding" parameter, followed by further parameters that could be called like this: foo(123, "utf-8") # would return bytes foo(encoding="utf-8") foo(123, None) # would return str foo(encoding=None) foo(x=123) # would return str foo() This could ideally be written as: @overload def foo(x: int = ..., encoding: None = ...) -> str: ... @overload def foo(x: int = ..., encoding: str) -> bytes: ... # plus the actual implementation But due to the syntax constraint, this needs to be hacked around with a third overload: @overload def foo(x: int = ... encoding: None = ...) -> str: ... @overload def foo(x: int, encoding: str) -> bytes: ... # for foo(123, "utf-8") @overload def foo(*, encoding: str) -> bytes: ... # for foo(encoding="utf-8") Not only is this hard to read, real examples in typeshed are usually more complex, with many arguments before or after the affected argument or even multiple affected arguments. This often becomes too complex to write or maintain. Here is one example from the wild: https://github.com/python/typeshed/blob/b95b729b9e07ab21d252701af0f5b740467… Allowing non-default arguments after default arguments would solve both use cases above and eliminates a special case. I'm also not sure what exactly the current SyntaxError really protects us from. Adding a non-default after a default argument can't really lead bugs. - Sebastian [View Less]

11 14

Python multithreading without the GIL
by Sam Gross July 31, 2023

July 31, 2023

Hi, I've been working on changes to CPython to allow it to run without the global interpreter lock. I'd like to share a working proof-of-concept that can run without the GIL. The proof-of-concept involves substantial changes to CPython internals, but relatively few changes to the C-API. It is compatible with many C extensions: extensions must be rebuilt, but usually require small or no modifications to source code. I've built compatible versions of packages from the scientific Python ecosystem,… [View More]

24 48

Mixed Python/C debugging
by Skip Montanaro April 26, 2023

April 26, 2023

Having tried comp.lang.python with no response, I turn here... After at least ten years away from Python's run-time interpreter & byte code compiler, I'm getting set to familiarize myself with that again. This will, I think, entail debugging a mixed Python/C environment. I'm an Emacs user and am aware that GDB since 7.0 has support for debugging at the Python code level. Is Emacs+GDB my best bet? Are there any Python IDEs which support C-level breakpoints and debugging? Thanks, Skip

5 6

PEP 448 review
by Guido van Rossum March 29, 2023

March 29, 2023

I'm back, I've re-read the PEP, and I've re-read the long thread with "(no subject)". I think Georg Brandl nailed it: """ *I like the "sequence and dict flattening" part of the PEP, mostly because itis consistent and should be easy to understand, but the comprehension syntaxenhancements seem to be bad for readability and "comprehending" what the codedoes.The call syntax part is a mixed bag on the one hand it is nice to be consistent with the extended possibilities in literals (… [View More]flattening), but on the other hand there would be small but annoying inconsistencies anyways (e.g. the duplicate kwarg case above).* """ Greg Ewing followed up explaining that the inconsistency between dict flattening and call syntax is inherent in the pre-existing different rules for dicts vs. keyword args: {'a':1, 'a':2} results in {'a':2}, while f(a=1, a=2) is an error. (This form is a SyntaxError; the dynamic case f(a=1, **{'a': 1}) is a TypeError.) For me, allowing f(*a, *b) and f(**d, **e) and all the other combinations for function calls proposed by the PEP is an easy +1 -- it's a straightforward extension of the existing pattern, and anybody who knows what f(x, *a) does will understand f(x, *a, y, *b). Guessing what f(**d, **e) means shouldn't be hard either. Understanding the edge case for duplicate keys with f(**d, **e) is a little harder, but the error messages are pretty clear, and it is not a new edge case. The sequence and dict flattening syntax proposals are also clean and logical -- we already have *-unpacking on the receiving side, so allowing *x in tuple expressions reads pretty naturally (and the similarity with *a in argument lists certainly helps). From here, having [a, *x, b, *y] is also natural, and then the extension to other displays is natural: {a, *x, b, *y} and {a:1, **d, b:2, **e}. This, too, gets a +1 from me. So that leaves comprehensions. IIRC, during the development of the patch we realized that f(*x for x in xs) is sufficiently ambiguous that we decided to disallow it -- note that f(x for x in xs) is already somewhat of a special case because an argument can only be a "bare" generator expression if it is the only argument. The same reasoning doesn't apply (in that form) to list, set and dict comprehensions -- while f(x for x in xs) is identical in meaning to f((x for x in xs)), [x for x in xs] is NOT the same as [(x for x in xs)] (that's a list of one element, and the element is a generator expression). The basic premise of this part of the proposal is that if you have a few iterables, the new proposal (without comprehensions) lets you create a list or generator expression that iterates over all of them, essentially flattening them: >>> xs = [1, 2, 3] >>> ys = ['abc', 'def'] >>> zs = [99] >>> [*xs, *ys, *zs] [1, 2, 3, 'abc', 'def', 99] >>> But now suppose you have a list of iterables: >>> xss = [[1, 2, 3], ['abc', 'def'], [99]] >>> [*xss[0], *xss[1], *xss[2]] [1, 2, 3, 'abc', 'def', 99] >>> Wouldn't it be nice if you could write the latter using a comprehension? >>> xss = [[1, 2, 3], ['abc', 'def'], [99]] >>> [*xs for xs in xss] [1, 2, 3, 'abc', 'def', 99] >>> This is somewhat seductive, and the following is even nicer: the *xs position may be an expression, e.g.: >>> xss = [[1, 2, 3], ['abc', 'def'], [99]] >>> [*xs[:2] for xs in xss] [1, 2, 'abc', 'def', 99] >>> On the other hand, I had to explore the possibilities here by experimenting in the interpreter, and I discovered some odd edge cases (e.g. you can parenthesize the starred expression, but that seems a syntactic accident). All in all I am personally +0 on the comprehension part of the PEP, and I like that it provides a way to "flatten" a sequence of sequences, but I think very few people in the thread have supported this part. Therefore I would like to ask Neil to update the PEP and the patch to take out the comprehension part, so that the two "easy wins" can make it into Python 3.5 (basically, I am accepting two-thirds of the PEP :-). There is some time yet until alpha 2. I would also like code reviewers (Benjamin?) to start reviewing the patch <http://bugs.python.org/issue2292>, taking into account that the comprehension part needs to be removed. -- --Guido van Rossum (python.org/~guido) [View Less]

7 17

PEP 638: Syntactic macros
by Mark Shannon Feb. 5, 2023

Feb. 5, 2023

Hi everyone, I've submitted my PEP on syntactic macros as PEP 638. https://www.python.org/dev/peps/pep-0638/ All comments and suggestions are welcome. Cheers, Mark

16 25

Switching to Discourse
by Petr Viktorin Jan. 26, 2023

Jan. 26, 2023

Hello, Currently development discussions are split between multiple communication channels, for example: - python-dev and discuss.python.org for design discussions, - GitHub Issues and Pull Requests for specific changes, - IRC, Discord and private chats for real-time discussions, - Topic-specific channels like typing-sig. While most of these serve different needs, there is too much overlap between python-dev and discuss.python.org. It seems that for most people, this situation is worse than … [View More]sticking to either one platform – even if we don't go with that person's favorite. The discuss.python.org experiment has been going on for quite a while, and while the platform is not without its issues, we consider it a success. The Core Development category is busier than python-dev. According to staff, discuss.python.org is much easier to moderate.. If you're following python-dev but not discuss.python.org, you're missing out. The Steering Council would like to switch from python-dev to discuss.python.org. Practically, this means: - Moving the required PEP announcements to discuss.python.org - Moving discuss.python.org up in the devguide communications page (https://devguide.python.org/communication/) - And that's it? I imagine that the mailing list will stay around for continuing past discussion threads and for announcements, eventually switching to auto-reject incoming messages with a pointer to discuss.python.org. To be clear, discuss.python.org allows editing posts, which is frankly handy for typos and clarifications. Editing alone should not be used for adding new info -- we should cultivate a culture of being friendly to mail users & notification watchers. This probably bears repeating in a few places. We're aware not everyone wants to use the discuss.python.org website, but there are some ways to avoid it: - For new PEPs, you can point your RSS client to https://www.python.org/dev/peps/peps.rss – it's not e-mail, but many email clients have RSS support. You can also watch the Steering Council issues on GitHub (https://github.com/python/steering-council/issues/) for important questions and discussions. - You can use discuss.python.org's “mailing list mode” (which subscribes you to all new posts), possibly with filtering and/or categorizing messages locally. However, we would like to know if this will pose an undue burden to anyone, if there are workflows or usage problems that we are not aware of. As mentioned, this is something the Steering Council thinks is a good idea, but we want to make sure we're aware of all the impact when we make the final decision. – Petr, on behalf of the Steering Council [View Less]

43 114

How about using modern C++ in development of CPython ?
by redradist＠gmail.com Oct. 19, 2022

Oct. 19, 2022

Hi all, What about of using modern C++ in developing CPython ? With C++ we can get the following benefits: 1) Readability - less code, most code is hidden by abstraction without losing performance 2) Maintainability - no code duplication in favor of using reusable classes 3) RAII - Resource Acquisition Is Initialization, predictable allocation and free resources ...

23 51

PEP 505 (None-aware operators) for Python 3.11
by Doug Swarin Sept. 21, 2022

Sept. 21, 2022

Hello, I've been following PEP 505 (https://www.python.org/dev/peps/pep-0505/) since it was first proposed for Python 3.8. It's been deferred for some time and I'm interested in seeing it in Python 3.11, but I know there were also a number of objections which resulted in it being deferred (including by one of the original authors, Mr. Dower). I did email both Mr. Dower and Mr. Haase and they graciously gave me their permission to bring it up on this list for discussion and hopefully final … [View More]

22 53

How To Get Started
by kiddkoding＠gmail.com July 28, 2022

July 28, 2022

New coding bootcamp graduate here looking actively for my first programming job. In the meantime, I want to start contributing to open source which brought me here. But after consulting the Python's Developer Guide, I'm still faced with some confusion and reluctance to get started. I tried looking at some of the current active issues and it has only caused more confusion. Any advice, tips, or other resources that can help get me started? Thanks in advance!

2 1

[RELEASE] The last 3.11 beta release (3.11.0b5) is now available
by Pablo Galindo Salgado July 26, 2022

July 26, 2022

Here we are. The universe. The vastness of spacetime. At the edge. The last frontier. The last beta*(conditions apply) for Python 3.11. We have defied the powerful gods of release blockers and we have won by using the required amount of ruse and subterfuge. https://www.python.org/downloads/release/python-3110b5/ ## :warning: PLEASE HELP US TO TEST THIS RELEASE :warning: Due to the modified release schedule and the stability concerns regarding the past beta releases, please, please, please, … [View More]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 of 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! ## This is a beta preview of Python 3.11 Python 3.11 is still in development. 3.11.0b5 is the last 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://github.com/python/cpython/issues/90908)-- 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.0rc1, currently scheduled for Monday, 2022-08-01. # 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://github.com/python/cpython/issues](https://github.com/python/cpython… . * [Help fund Python and its community](/psf/donations/). # And now for something completely different Schwarzschild wormholes, also known as Einstein–Rosen bridges (named after Albert Einstein and Nathan Rosen), are connections between areas of space that can be modelled as vacuum solutions to the Einstein field equations, and that are now understood to be intrinsic parts of the maximally extended version of the Schwarzschild metric describing an eternal black hole with no charge and no rotation. Here, "maximally extended" refers to the idea that spacetime should not have any "edges": it should be possible to continue this path arbitrarily far into the particle's future or past for any possible trajectory of a free-falling particle (following a geodesic in the spacetime). The Einstein–Rosen bridge was discovered by Ludwig Flamm in 1916, a few months after Schwarzschild published his solution, and was rediscovered by Albert Einstein and his colleague Nathan Rosen, who published their result in 1935. However, in 1962, John Archibald Wheeler and Robert W. Fuller published a paper showing that this type of wormhole is unstable if it connects two parts of the same universe and that it will pinch off too quickly for light (or any particle moving slower than light) that falls in from one exterior region to make it to the other exterior region. Although Schwarzschild wormholes are not traversable in both directions, their existence inspired Kip Thorne to imagine traversable wormholes created by holding the "throat" of a Schwarzschild wormhole open with exotic matter (material that has negative mass/energy). # Release hashes The BSD-style checksum hashes for the release artefacts are: SHA256 (python-3.11.0b5-amd64.exe) = 0cf9d582da862f2fe207fd54b81dfca110e8f04f4b05ab8c3228ce1ea060c7af SHA256 (python-3.11.0b5-arm64.exe) = a71efd9d3835d493d8207a30916ce3417af17295c02a9b0783dc740754f6e40b SHA256 (python-3.11.0b5-embed-amd64.zip) = 5584ddbd21f45ce74ce0512eeb1d817d15374b1b7a461d79f973f6dd48ab5d9e SHA256 (python-3.11.0b5-embed-arm64.zip) = 819924f10eb08ea6322b6040a2fb953137866bb1034cd4e8fe6e93c7c0b37e31 SHA256 (python-3.11.0b5-embed-win32.zip) = 18927604bcbe3c226be7864cde0c1f25ad35c6333d9d3125dfff8ca4fc872255 SHA256 (python-3.11.0b5.exe) = 382eb4c6dc1606bd3cf6f4bdeec8e1e7dab444c5aa23b86142d608a480d7c195 SHA256 (python-3.11.0b5-macos11.pkg) = cd8e6d98e79a4adcd376c486405a535b004cf9a58a71487a11bc424acd815012 SHA256 (Python-3.11.0b5.tar.xz) = 3810bd22f7dc34a99c2a2eb4b85264a4df4f05ef59c4e0ccc2ea82ee9c491698 SHA256 (Python-3.11.0b5.tgz) = 3f7d1a4ab0e64425f4ffd92d49de192ad2ee1c62bc52e3877e9f7b254c702e60 The hashes are also attached to this email. # 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 [View Less]

2 1

CACHE opcode in Python 3.11 bytecode
by Matthieu Dartiailh July 25, 2022

July 25, 2022

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", … [View More]

2 1

PEP 563 and Python 3.10.
by Thomas Wouters July 22, 2022

July 22, 2022

(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 … [View More]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! [View Less]

6 5

Do not harass other mailing list subscribers privately
by Brett Cannon July 20, 2022

July 20, 2022

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 … [View More]

2 1

compiling errors, SSL
by Kevin T July 20, 2022

July 20, 2022

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.&… [View More]nbsp; 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 [View Less]

2 1

Presenting PEP 692: Using TypedDict for more precise **kwargs typing
by Franek Magiera July 18, 2022

July 18, 2022

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 July 16, 2022

July 16, 2022

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 … [View More]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 [View Less]

7 10

Presenting PEP 695: Type Parameter Syntax
by Guido van Rossum July 16, 2022

July 16, 2022

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 … [View More]

9 8

New `python` Organization Repository Policy
by Petr Viktorin July 15, 2022

July 15, 2022

(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.… [View More] 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). [View Less]

3 2

Exceptions and tracebacks and frames, oh my!
by Yonatan Zunger July 14, 2022

July 14, 2022

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 … [View More]

2 1

Re: 3.11 enhanced error location - can it be smarter?
by John Belmonte July 13, 2022

July 13, 2022

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 … [View More]

2 1

Presenting PEP 692: Using TypedDict for more precise **kwargs typing
by Franek Magiera July 12, 2022

July 12, 2022

Hello, PEP 692 is posted. It proposes to use TypedDicts to type **kwargs that consist of different types. This feature has gained a lot of interest from the community (https://github.com/python/mypy/issues/4441). The PEP also proposes a grammar change and a new dunder __unpack__. Here is the link to the PEP itself - https://peps.python.org/pep-0692/ And the discussion on discuss.python.org - https://discuss.python.org/t/pep-692-using-typeddict-for-more-precise-kwarg… Please share your … [View More]

1 0

Structural pattern matching and mangling private names
by dw-git＠d-woods.co.uk July 12, 2022

July 12, 2022

For this code: class C: def f(self, x): match x: case D(__something=y): return y It appears that the name "__something" isn't mangled. Under most other circumstances I'd expect this to be mangled to "_C__something". Is this: * intentional, * accidental, but how that it's done it's the defined behaviour, * or a defect? It doesn't seem like it's explicitly tested for in test_patma.py either way. Thanks David

3 5

Question about code in test_email/test_message.py
by Sidney Markowitz July 7, 2022

July 7, 2022

I'm writing up a PR for an issue I created and adding a test to test/test_email/test_message.py In that file there is a variable named message_params that is initialized with about 15 different sets of test data, in class TestEmailMessageBase, but is never referenced again. I even grepped for the variable name in all test py files to confirm that it isn't somehow imported somewhere. Is there something about the test framework that uses that automatically? I'm hesitant to add any testing code … [View More]

2 1

Python 3.11 bytecode and exception table
by Matthieu Dartiailh July 5, 2022

July 5, 2022

Hi all, I am the current maintainer of bytecode (https://github.com/MatthieuDartiailh/bytecode) which is a library to perform assembly and disassembly of Python bytecode. The library was created by V. Stinner. I started looking in Python 3.11 support in bytecode, I read Objects/exception_handling_notes.txt and I have a couple of questions regarding the exception table: Currently bytecode exposes three level of abstractions: - the concrete level in which one deals with … [View More]instruction offset for jumps and explicit indexing into the known constants and names - the bytecode level which uses labels for jumps and allow non integer argument to instructions - the cfg level which provides basic blocks delineation over the bytecode level So my first idea was to directly expose the unpacked exception table (start, stop, target, stack_depth, last_i) at the concrete level and use pseudo-instruction and labels at the bytecode level. At this point of my reflections, I saw https://github.com/python/cpython/commit/c57aad777afc6c0b382981ee9e4bc94c03… about adding pseudo-instructionto dis output in 3.12 and though it would line up quite nicely. Reading through, I got curious about how SETUP_WITH handled popping one extra item from the stack so I went to look at dis results on a couple of small examples. I tried on 3.10 and 3.11b3 (for some reasons I cannot compile main at a391b74d on windows). I looked at simple things and got a bit surprised: Disassembling: deff(): try: a= 1 except: raise I get on 3.11: 1 0 RESUME 0 2 2 NOP 3 4 LOAD_CONST 1 (1) 6 STORE_FAST 0 (a) 8 LOAD_CONST 0 (None) 10 RETURN_VALUE >> 12 PUSH_EXC_INFO 4 14 POP_TOP 5 16 RAISE_VARARGS 0 >> 18 COPY 3 20 POP_EXCEPT 22 RERAISE 1 ExceptionTable: 4 to 6 -> 12 [0] 12 to 16 -> 18 [1] lasti On 3.10: 2 0 SETUP_FINALLY 5 (to 12) 3 2 LOAD_CONST 1 (1) 4 STORE_FAST 0 (a) 6 POP_BLOCK 8 LOAD_CONST 0 (None) 10 RETURN_VALUE 4 >> 12 POP_TOP 14 POP_TOP 16 POP_TOP 5 18 RAISE_VARARGS 0 This surprised me on two levels: - first I have never seen the RESUME opcode and it is currently not documented - my second surprise comes from the second entry in the exception table. At first I failed to see why it was needed but writing this I realize it corresponds to the explicit handling of exception propagation to the caller. Since I cannot compile 3.12 ATM I am wondering how this plays with pseudo-instruction: in particular are pseudo-instructions generated for all entries in the exception table ? My initial idea was to have a SETUP_FINALLY/SETUP_CLEANUP - POP_BLOCK pair for each line in the exception table and label for the jump target. But I realize it means we will have many such pairs than in 3.10. It is fine by me but I wondered what choice was made in 3.12 dis and if this approach made sense. Best regards Matthieu [View Less]

3 4

Announcing the Diátaxis Documentation Workshop
by Mariatta July 5, 2022

July 5, 2022

Diátaxis Documentation Workshop The Python documentation community <https://github.com/python/docs-community> will be hosting a free two-part workshop by Daniele Procida <https://vurt.org/>, the creator of the Diátaxis framework <https://diataxis.fr/>. Each session will be two hours; including an introduction, discussion/questions, and practical exercises in small groups; and will be hosted on Zoom. There’s an *optional* take-home exercise after the first session, which we’… [View More]ll review during the second. The second session builds upon the first, so we strongly prefer that you attend both sessions to fully benefit from it. However, we may be able to accommodate a limited number of people that can only make it to one. They will be hands-on, so to get the most out of your attendance, be ready to participate and interact with Daniele and your fellow attendees! While the primary focus of the workshop is on contributors to the Python documentation, they are open to anyone in the open source community interested in writing better documentation, as long as space allows. To attend the workshop, sign up using the registration form <https://forms.gle/xQSZJ2Yf4Jjd27wf6>, and we’ll confirm your attendance by August 1. We will try our best to fill any remaining slots on a rolling space-available basis. The presentation portion of the workshop will be recorded (though the interactive aspect won’t be). <https://discuss.python.org/t/announcing-the-diataxis-documentation-workshop…>Workshop Agenda Session 1: Introduction to Diátaxis Tuesday, August 16 2022, 16:00-18:00 UTC (12 - 2 PM US Eastern / 9 - 11 AM US Pacific) <https://www.timeanddate.com/worldclock/fixedtime.html?msg=Di%C3%A1taxis+Wor…> - The Diátaxis system and how it works - Using it for documentation in general - Applying it to the Python docs specifically Session 2: Getting Things Done Thursday, August 18 2022, 16:00-18:00 UTC (12 - 2 PM US Eastern / 9 - 11 AM US Pacific) <https://www.timeanddate.com/worldclock/fixedtime.html?msg=Di%C3%A1taxis+Wor…> - Authoring practices and approaches - Getting work started and keeping it going - Making life easy for ourselves <https://discuss.python.org/t/announcing-the-diataxis-documentation-workshop…>About Daniele Procida I’m a Director of Engineering at Canonical <https://canonical.com/>, where I work to transform documentation practice across 40-plus engineering teams. Ever since I’ve become involved in software in 2009, I’ve been involved in its documentation too. I found my way to software through Python and Django, so that’s where I’ve made most of my direct contributions: Django, pytest, django CMS and others. Through the international Python community, I’ve had the enormous pleasure of taking part in numerous events and initiatives. The most important one to me is the African Python movement: since 2015, I’ve attended multiple editions of PyCon Namibia, PyCon Ghana and PyCon Africa. In recent years, I’ve had the fortune of seeing the approaches I’ve developed in my work in documentation adopted much more widely across the software industry. I am always thrilled to have the opportunity to contribute back through documentation to the same software communities that have lifted me up in my own software journey. <https://discuss.python.org/t/announcing-the-diataxis-documentation-workshop…>Getting in Touch If you have questions or concerns about the workshop, please post in the Docs Community forum <https://discuss.python.org/c/documentation/26> on Discourse. For private communications, please get in touch with one of the organizers: Mariatta, Ned Batchelder, and C.A.M. Gerlach <https://discuss.python.org/t/announcing-the-diataxis-documentation-workshop…> Acknowledgement Thanks to Canonical for their support and generosity in making Daniele’s participation in this workshop series possible. [View Less]

1 0