Mailman 3 June 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

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

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

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

[Release] Python 3.11.0b4 is still blocked
by Pablo Galindo Salgado July 4, 2022

July 4, 2022

Hi everyone, A small update since the last communication from the release team regarding the status of Python 3.11.0b4. Unfortunately, even if we have fixed most of the original release blockers and 4 more that appear during this week, we still have a bunch of release blockers to deal with. One of them has been reported today. I would like to release the next beta next week if everything looks good, but there are also some items that need discussion:. https://github.com/python/cpython/… [View More]

3 5

Confusing naming of Optional type should be changed
by nverich07＠gmail.com June 30, 2022

June 30, 2022

I am aware this is clarified in the Python documentation for the typing module but I and others have thought the naming of Optional is still quite confusing by itself. "Note that this is not the same concept as an optional argument, which is one that has a default. An optional argument with a default does not require the Optional qualifier on its type annotation just because it is optional." - typing.Optional docs Google defines optional as this, "available to be chosen but not obligatory." … [View More]

2 2

Re: Python Software Foundation Board of Directors Election 2022
by Tim Peters June 26, 2022

June 26, 2022

Heads up! I found my PSF Board voting info in my gmail spam folder today; looks like it was mailed out this morning.

2 1

Making SocketHandler safe for use with non-pickleable objects
by roy＠panix.com June 20, 2022

June 20, 2022

I've been working on a bug in django where if you configure a logging.handlers.SocketHandler in the django logging config, it gets a TypeError because it tries to log a HttpRequest object, which can't be pickled. I'm slowly coming to the conclusion that this isn't a django bug, and the right fix is to make SocketHandler (and DatagramHandler) be able to deal with this internally. QueueHandler already does this, or at least the documentation says it does: prepare(record) ... removes … [View More]

1 0

Summary of Python tracker Issues
by Python tracker June 18, 2022

June 18, 2022

ACTIVITY SUMMARY (2022-06-10 - 2022-06-17) Python tracker at https://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open 7146 ( +0) closed 51841 ( +0) total 58987 ( +0) Open issues with patches: 2890 Most recent 15 issues with no replies (15) ========================================== #47258: Python 3.10 hang at exit in drop_gil() (due to resource warnin https://bugs.python.org/… [View More]

3 2

Re: [Python-Help] Unable to bootstrap Python 3 install
by Dave Blanchard June 17, 2022

June 17, 2022

Thanks for your reply Matt. Here's what's happening. This is a very old problem reported ages ago which has never been fixed. If I set the target arch to i686 (on an x86_64 build system) Python will cross-compile and bootstrap just fine. But if the host and build triple are the same, then the problem will occur. Python seems to be ASSuming that if the build and host triple match (in this case, both being 'x86_64-linux-gnu') therefore the host and build libraries are binary-compatible--which is … [View More]NOT actually the case when one is cross-compiling to a different libc, for example. Actually it's kind of brain dead how this is implemented. Some prior discussions/years-old bug reports: https://bugs.python.org/issue39399 https://bugs.python.org/issue22724 https://bugs.gentoo.org/705970 In those links, various hacks are attempted with various degrees of success, but then Xavier de Gaye reworked the build system, apparently fixing the problem with this pull request in Dec. 2019: https://github.com/python/cpython/pull/17420 Unfortunately he became annoyed in the comments, seemingly mostly due to the lack of interest from Python to actually do anything about this problem, and cancelled his pull request. His fix was never implemented, and Python cross-compiling remains broken to this day. I downloaded his patches, made a minor fix or two, and merged them all together into the one patch attached to this email. When applied to both my build system and target Python, this problem seems to be resolved, for me at least. I'll know more later tonight as I get further into the distro build process. It's surprising to hear that cross-compiling Python would be any kind of "unusual" thing, considering this is something that *always* has to be done any time one is bootstrapping anything on a new or different system. It surprises me further to see that Python actually requires the *minor* version number to be the same for bootstrapping, also. So not only is Python 3 essentially a different language from Python 2, each point release is different and incompatible also. Amazing. I guess this shouldn't be surprising, after all of the other questionable design decisions this project has made over the years. I probably also shouldn't be surprised to see such an incredibly important bug going unfixed after all this time. It's Python--by far the #1 biggest annoyance and pain in the ass out of the 1,000+ packages on my distro, ranking just above CUPS and Texlive. Dave On Mon, 13 Jun 2022 16:12:26 -0500 (CDT) Matthew Dixon Cowles <matt(a)mondoinfo.com> wrote: > Dear Dave, > > > Hello, I'm trying to cross compile a new version of my Linux system > > with some upgraded packages, including a new Glibc. > > I've never had to do that and I am beginning to suspect, from the > lack of replies here better than this one, that nobody else here has > had to either. > > > I've hit a major snag with Python 3.7 (also tried 3.9 with same > > result) which makes it through the compile OK, but then bombs when > > running ensurepip at the end. > > If it were me, I'd set --with-ensurepip to no, declare victory, and > run ensurepip on the target machine. > > I haven't been able to find any very good evidence, but I wouldn't be > surprised if the option to turn ensurepip off is there to help out > with cross-compiling. For example, here it's being turned off for > compiling to web assembly: > > https://t.ly/_ZE3 > > (alternatively: > > https://github.com/python/cpython/commit/ > 9deb83468c56c7484645e6e3a6d0183cd6a0afd7 > > ) > > which looks to me a lot like what you're doing. > > What seems to be happening is that in Lib/esurepip/__init__.py is > calling run_module() in Lib/runpy.py and that's calling > _run_module_code() which is getting the new, but wrong libraries. > > I suspect that it's possible to hack that to do what you want, but as > far as a moderately close look tells me, it's not written with > cross-compiling in mind. If I had to do make it work, I'd break out > into the debugger and fiddle around on a mostly trial-and-error basis. > > Even then, I'd have a hacked version of ensurepip/__init__.py and/or > runpy.py, which I'd want to replace with the originals in the end. > > I'm pretty sure that running ensurepip on the target would be easier. > > If that's not useful to you, let us know what you think and I'll try > to think some more. > > Regards, > Matt > -- Dave Blanchard <dave(a)killthe.net> [View Less]

6 8

IMPORTANT: Python 3.11.0b4 is blocked
by Pablo Galindo Salgado June 15, 2022

June 15, 2022

Hi everyone, Today we are supposed to release Python3.11.0b4 but unfortunately, we have a bunch of release blockers: https://github.com/python/cpython/issues?q=is%3Aissue+is%3Aopen+label%3Arel… Please, if you are involved in the above issues check if they are resolved or if they are not released blockers. If they are not release blockers or you think we should defer them, please comment on why on the issue. Also, please, notice that the final decision to defer or not a blocker is made by the … [View More]

1 0

Behavior of `asyncio.gather` when one of submitted tasks raises a `KeyboardInterrupt`.
by Yves Duprat June 14, 2022

June 14, 2022

Hi, regarding this [issue93122](https://github.com/python/cpython/issues/93122), I am wondering what is the normal behavior of `asyncio.gather` when one of the submitted tasks raises a `KeyboardInterrupt` exception ? -- regardless of the value of the `return_exception` parameter. It seems that this primitive does not behave the same way with `KeyboardInterrupt` and `ZeroDivisionError` exceptions. But may be it is normal ? I have searched in the documentation [here](https://docs.python.org/3/… [View More]

2 5

Method __func__ objects are unpicklable
by haael June 10, 2022

June 10, 2022

During some sophisticated pickling I noticed that method `__func__` objects are unpicklable, because they share the name with the bound method object itself. ``` from pickle import dumps class A: @classmethod def b(cls): pass print(A.b) # <bound method A.b of <class '__main__.A'>> print(A.b.__func__) # <function A.b at 0x7f5574570bf8> dumps(A.b) # works dumps(A.b.__func__) # breaks # >Traceback (most recent call last): # > File "<stdin>", … [View More]

3 2

Summary of Python tracker Issues
by Python tracker June 10, 2022

June 10, 2022

ACTIVITY SUMMARY (2022-06-03 - 2022-06-10) Python tracker at https://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open 7146 ( +0) closed 51841 ( +0) total 58987 ( +0) Open issues with patches: 2890 Most recent 15 issues with no replies (15) ========================================== #47258: Python 3.10 hang at exit in drop_gil() (due to resource warnin https://bugs.python.org/… [View More]

1 0

[RELEASE] Python 3.10.5 is available
by Pablo Galindo Salgado June 7, 2022

June 7, 2022

The latest bugfix drop for Python 3.10 is here: Python 3.10.5. This release packs more than 230 bugfixes and docs changes, so you surely want to update :) You can get it here: https://www.python.org/downloads/release/python-3105/ ## This is the fourth maintenance release of Python 3.10 Python 3.10.5 is the newest major release of the Python programming language, and it contains many new features and optimizations. # Major new features of the 3.10 series, compared to 3.9 Among the new major … [View More]new features and changes so far: * [PEP 623](https://www.python.org/dev/peps/pep-0623/) -- Deprecate and prepare for the removal of the wstr member in PyUnicodeObject. * [PEP 604](https://www.python.org/dev/peps/pep-0604/) -- Allow writing union types as X | Y * [PEP 612](https://www.python.org/dev/peps/pep-0612/) -- Parameter Specification Variables * [PEP 626](https://www.python.org/dev/peps/pep-0626/) -- Precise line numbers for debugging and other tools. * [PEP 618 ](https://www.python.org/dev/peps/pep-0618/) -- Add Optional Length-Checking To zip. * [bpo-12782](https://bugs.python.org/issue12782): Parenthesized context managers are now officially allowed. * [PEP 632 ](https://www.python.org/dev/peps/pep-0632/) -- Deprecate distutils module. * [PEP 613 ](https://www.python.org/dev/peps/pep-0613/) -- Explicit Type Aliases * [PEP 634 ](https://www.python.org/dev/peps/pep-0634/) -- Structural Pattern Matching: Specification * [PEP 635 ](https://www.python.org/dev/peps/pep-0635/) -- Structural Pattern Matching: Motivation and Rationale * [PEP 636 ](https://www.python.org/dev/peps/pep-0636/) -- Structural Pattern Matching: Tutorial * [PEP 644 ](https://www.python.org/dev/peps/pep-0644/) -- Require OpenSSL 1.1.1 or newer * [PEP 624 ](https://www.python.org/dev/peps/pep-0624/) -- Remove Py_UNICODE encoder APIs * [PEP 597 ](https://www.python.org/dev/peps/pep-0597/) -- Add optional EncodingWarning [bpo-38605](https://bugs.python.org/issue38605): `from __future__ import annotations` ([PEP 563](https://www.python.org/dev/peps/pep-0563/)) used to be on this list in previous pre-releases but it has been postponed to Python 3.11 due to some compatibility concerns. You can read the Steering Council communication about it [here]( https://mail.python.org/archives/list/python-dev@python.org/thread/CLVXXPQ2…) to learn more. # More resources * [Changelog](https://docs.python.org/3.10/whatsnew/changelog.html#changelog ) * [Online Documentation](https://docs.python.org/3.10/) * [PEP 619](https://www.python.org/dev/peps/pep-0619/), 3.10 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 Strange quarks are the third lightest quarks, which are subatomic particles that are so small, they are believed to be the fundamental particles, and not further divisible. Like down quarks, strange quarks have a charge of -1/3. Like all fermions (which are particles that can not exist in the same place at the same time), strange quarks have a spin of 1/2. What makes strange quarks different from down quarks–apart from having 25 times the mass of down quarks–is that they have something that scientists call "strangeness." Strangeness is basically a resistance to decay against strong force and electromagnetism. This means that any particle that contains a strange quark can not decay due to strong force (or electromagnetism), but instead with the much slower weak force. It was believed that this was a 'strange' method of decay, which is why the scientists gave the particles that name. # 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/ 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

Deadlock when interrupting interpreter initialisation with ptrace?
by Gabriele June 6, 2022

June 6, 2022

Hi there I hope you don't mind me sharing my experience with testing the austinp variant of Austin with Python >=2.7,<3.11. The austinp variant is a variant of Austin (https://github.com/P403n1x87/austin) for Linux that uses ptrace to seize and interrupt/continue threads to capture native stack traces using libunwind. During testing, I have discovered that there are good chances of causing what looks like a deadlock in Python if the seizing and interrupting of threads happen very early … [View More]

4 5

Almost accepting PEP 681 – Data Class Transforms
by Petr Viktorin June 6, 2022

June 6, 2022

Hello, As an initial implementation that will be improved in the future, the specification in PEP 681 is fine. Feel free to add the decorator to Python 3.11 at your convenience. However, the PEP includes several worrying recommendations like: - we recommend that the maintainers of attrs move away from the legacy semantics and adopt auto_attribs behaviors by default. - We chose not to support this feature and recommend that attrs users avoid converters. - Attrs users should use the … [View More]

6 7

Looking for volunteers to maintain the multiprocessing and concurrent.futures modules
by Victor Stinner June 6, 2022

June 6, 2022

Hi, On buildbots, it's common that we get at least one multiprocessing test failure per week. While I just reported a new one, I wanted to add a "expert-multiprocessing" label, but it didn't exist. I just created the label :-) https://github.com/python/cpython/labels/expert-multiprocessing I added the label manually to 240 issues! Oh, they are many open issues about multiprocessing and concurrent.futures modules. Documentation issues, feature requests, but also a long list of real bugs ("… [View More]

1 0

Summary of Python tracker Issues
by Python tracker June 3, 2022

June 3, 2022

ACTIVITY SUMMARY (2022-05-27 - 2022-06-03) Python tracker at https://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open 7146 ( +0) closed 51841 ( +0) total 58987 ( +0) Open issues with patches: 2890 Most recent 15 issues with no replies (15) ========================================== #47258: Python 3.10 hang at exit in drop_gil() (due to resource warnin https://bugs.python.org/… [View More]

1 0

[RELEASE] The second Python 3.11 beta (3.11.0b2) is available
by Pablo Galindo Salgado June 3, 2022

June 3, 2022

Does anyone want bug fixes? Because we have 164 new commits fixing different things, from code to documentation. If you have reported some issue after 3.11.0b1, you should check if is fixed and if not, make sure you tell us so we can take a look. We still have two more betas to go so help us to make sure we don't miss anything so everything is ready for the final release!! https://www.python.org/downloads/release/python-3110b2/ ## This is a beta preview of Python 3.11 Python 3.11 is still … [View More]in development. 3.11.0b2 is the second of four 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 to have no ABI changes after beta 4 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 Many new features for Python 3.11 are still being planned and written. Among the new major new features and changes so far: * [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 673](https://www.python.org/dev/peps/pep-0673/) -- Self Type * [PEP 646](https://www.python.org/dev/peps/pep-0646/)-- Variadic Generics * [PEP 680](https://www.python.org/dev/peps/pep-0680/)-- tomllib: Support for Parsing TOML in the Standard Library * [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 * [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. * <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.0b3, currently scheduled for Thursday, 2022-06-16. # 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 time is the time required for light to travel a distance of 1 Planck length in a vacuum, which is a time interval of approximately `5.39*10^(−44)` s. No current physical theory can describe timescales shorter than the Planck time, such as the earliest events after the Big Bang, and it is conjectured that the structure of time breaks down on intervals comparable to the Planck time. While there is currently no known way to measure time intervals on the scale of the Planck time, researchers in 2020 found that the accuracy of an atomic clock is constrained by quantum effects on the order of the Planck time, and for the most precise atomic clocks thus far they calculated that such effects have been ruled out to around `10^−33` s, or 10 orders of magnitude above the Planck scale. # 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/ Regards from sunny London, Pablo Galindo Salgado [View Less]

4 11