Mailman 3 June 2022 - Python-Dev

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." Pretend we have a function like this: def test_func(param: Optional[str]) -> None: ... The argument param is typed as Optional[str] meaning Union[str, None] or str | None. Optional here if we follow the definition above, basically means it can be str but not required or obligated to be that type. See the problem with the naming? This is a function where param can be None or str, not just it can be str but not obligated. Some interpretations may think optional means left to one's choice as well. The docs even have to clarify the use of Optional with typing because of this confusion. I believe this has been proposed before (not sure) but something like Nullable or Noneable (not sure about naming) would make much more sense in the context of typing. def test_func(param: Noneable[str]) -> None: ... It also would work and still make sense if there is a default value for the argument: def test_func(param: Noneable[str] = None) -> None: ... def test_func(param: Noneable[str] = "hello world") -> None: ...

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 unpickleable items from the record in-place. It seems like SocketHandler should do the same thing. Thoughts?

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/issue47258 #47256: re: limit the maximum capturing group to 1,073,741,823, reduce https://bugs.python.org/issue47256 #47253: LOAD_GLOBAL instruction with wrong source position https://bugs.python.org/issue47253 #47252: socket.makefile documentation is missing data regarding the 'b https://bugs.python.org/issue47252 #47251: Merge BINARY_SUBSCR_LIST_INT with BINARY_SUBSCR_LIST_TUPLE https://bugs.python.org/issue47251 #47244: email.utils.formataddr does not respect double spaces https://bugs.python.org/issue47244 #47242: Annoying white bar in IDLE (line 457 in sidebar.py) https://bugs.python.org/issue47242 #47241: [C API] Move the PyCodeObject structure to the internal C API https://bugs.python.org/issue47241 #47238: Python threading.Event().wait() depends on the system time https://bugs.python.org/issue47238 #47236: Document types.CodeType.replace() changes about co_exceptionta https://bugs.python.org/issue47236 #47228: Document that naïve datetime objects represent local time https://bugs.python.org/issue47228 #47222: subprocess.Popen() should allow capturing output and sending i https://bugs.python.org/issue47222 #47219: asyncio with two interpreter instances https://bugs.python.org/issue47219 #47218: adding name to lzmafile https://bugs.python.org/issue47218 #47217: adding name to BZ2File https://bugs.python.org/issue47217 Most recent 15 issues waiting for review (15) ============================================= #47256: re: limit the maximum capturing group to 1,073,741,823, reduce https://bugs.python.org/issue47256 #47255: Many broken :meth: roles in the docs https://bugs.python.org/issue47255 #47254: enhanced dir? https://bugs.python.org/issue47254 #47251: Merge BINARY_SUBSCR_LIST_INT with BINARY_SUBSCR_LIST_TUPLE https://bugs.python.org/issue47251 #47243: Duplicate entry in 'Objects/unicodetype_db.h' https://bugs.python.org/issue47243 #47233: show_caches option affects code positions reported by dis.get_ https://bugs.python.org/issue47233 #47222: subprocess.Popen() should allow capturing output and sending i https://bugs.python.org/issue47222 #47218: adding name to lzmafile https://bugs.python.org/issue47218 #47217: adding name to BZ2File https://bugs.python.org/issue47217 #47216: adding mtime option to gzip open() https://bugs.python.org/issue47216 #47215: Add "unstable" frame stack api https://bugs.python.org/issue47215 #47208: Support libffi implementations that cannot support invocations https://bugs.python.org/issue47208 #47205: posix.sched_{get|set}affinity(-1) no longer returns ProcessLoo https://bugs.python.org/issue47205 #47200: Add ZipInfo.mode property https://bugs.python.org/issue47200 #47199: multiprocessing: micro-optimize Connection.send_bytes() method https://bugs.python.org/issue47199

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 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>

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 release management team. If you have some time to investigate, that will help a lot! Please, add me as a reviewer to any PR that needs to be merged to address these issues. Thanks for your help! Regards from sunny London, Pablo Galindo Salgado

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/library/asyncio-task.html#asyncio.gather) but I did not find anything. Thanks for your help. Yves

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>", line 1, in <module> # >_pickle.PicklingError: Can't pickle <function A.b at 0x7fd1d50d8bf8>: # >it's not the same object as __main__.A.b ``` The last call compains that global symbol "A.b" is not the same object as `A.b.__func__`. Everything would work if the `__func__` objects had the suffix ".__func__" in their qualname. Actually setting the qualname of the `__func__` object makes it picklable, but then the bound method object is unpicklable, as it inherits the name from the `__func__`. It would be good if they were separate. This is an attempt at emulating the desired behavior: ``` from pickle import dumps class A: pass def c(cls): pass A.c = lambda: c(A) A.c.__qualname__ = "A.c" A.c.__name__ = "c" A.c.__self__ = A A.c.__func__ = c A.c.__func__.__qualname__ = "A.c.__func__" print(A.c) # <function A.c at 0x7f83ceabcbf8> print(A.c.__func__) # <function A.c.__func__ at 0x7f83ceabcb70> dumps(A.c) # works dumps(A.c.__func__) # works ``` Can we make the `__func__` objects picklable this way? haael

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/issue47258 #47256: re: limit the maximum capturing group to 1,073,741,823, reduce https://bugs.python.org/issue47256 #47253: LOAD_GLOBAL instruction with wrong source position https://bugs.python.org/issue47253 #47252: socket.makefile documentation is missing data regarding the 'b https://bugs.python.org/issue47252 #47251: Merge BINARY_SUBSCR_LIST_INT with BINARY_SUBSCR_LIST_TUPLE https://bugs.python.org/issue47251 #47244: email.utils.formataddr does not respect double spaces https://bugs.python.org/issue47244 #47242: Annoying white bar in IDLE (line 457 in sidebar.py) https://bugs.python.org/issue47242 #47241: [C API] Move the PyCodeObject structure to the internal C API https://bugs.python.org/issue47241 #47238: Python threading.Event().wait() depends on the system time https://bugs.python.org/issue47238 #47236: Document types.CodeType.replace() changes about co_exceptionta https://bugs.python.org/issue47236 #47228: Document that naïve datetime objects represent local time https://bugs.python.org/issue47228 #47222: subprocess.Popen() should allow capturing output and sending i https://bugs.python.org/issue47222 #47219: asyncio with two interpreter instances https://bugs.python.org/issue47219 #47218: adding name to lzmafile https://bugs.python.org/issue47218 #47217: adding name to BZ2File https://bugs.python.org/issue47217 Most recent 15 issues waiting for review (15) ============================================= #47256: re: limit the maximum capturing group to 1,073,741,823, reduce https://bugs.python.org/issue47256 #47255: Many broken :meth: roles in the docs https://bugs.python.org/issue47255 #47254: enhanced dir? https://bugs.python.org/issue47254 #47251: Merge BINARY_SUBSCR_LIST_INT with BINARY_SUBSCR_LIST_TUPLE https://bugs.python.org/issue47251 #47243: Duplicate entry in 'Objects/unicodetype_db.h' https://bugs.python.org/issue47243 #47233: show_caches option affects code positions reported by dis.get_ https://bugs.python.org/issue47233 #47222: subprocess.Popen() should allow capturing output and sending i https://bugs.python.org/issue47222 #47218: adding name to lzmafile https://bugs.python.org/issue47218 #47217: adding name to BZ2File https://bugs.python.org/issue47217 #47216: adding mtime option to gzip open() https://bugs.python.org/issue47216 #47215: Add "unstable" frame stack api https://bugs.python.org/issue47215 #47208: Support libffi implementations that cannot support invocations https://bugs.python.org/issue47208 #47205: posix.sched_{get|set}affinity(-1) no longer returns ProcessLoo https://bugs.python.org/issue47205 #47200: Add ZipInfo.mode property https://bugs.python.org/issue47200 #47199: multiprocessing: micro-optimize Connection.send_bytes() method https://bugs.python.org/issue47199

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 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

2 1