Mailman 3 February 2021 - Python-Dev

Understanding "is not safe" in typeobject.c
by Phil Thompson 03 Feb '21

03 Feb '21

Hi, I'm trying to understand the purpose of the check in tp_new_wrapper() of typeobject.c that results in the "is not safe" exception. I have the following class hierarchy... B -> A -> object ...where B and A are implemented in C. Class A has an implementation of tp_new which does a few context-specific checks before calling PyBaseObject_Type.tp_new() directly to actually create the object. This works fine. However I want to allow class B to be used with a Python mixin. A's tp_new() then has to do something similar to super().__new__(). I have tried to implement this by locating the type object after A in B's MRO, getting it's '__new__' attribute and calling it (using PyObject_Call()) with B passed as the only argument. However I then get the "is not safe" exception, specifically... TypeError: object.__new__(B) is not safe, use B.__new__() I take the same approach for __init__() and that works fine. If I comment out the check in tp_new_wrapper() then everything works fine. So, am I doing something unsafe? If so, what? Or, is the check at fault in not allowing the case of a C extension type with its own tp_new? Thanks, Phil

4 12

PEP 563: get_type_hints should use closure when available
by Caleb Donovick 03 Feb '21

03 Feb '21

The discussion around PEP 649 got me thinking about what I believe is the largest downside to PEP 563: the inability to evaluate annotations created with closures. While this is in general unavoidable, if the type is ever referenced in an annotated function (including as an annotation) it should be resolvable via `__closure__`. For example: ``` from __future__ import annotations import typing def gen(T): def f(x: T): y: T = ... return f f = gen(int) nonlocal_vars = { var : cell.cell_contents for var, cell in zip(f.__code__.co_freevars, f.__closure__) } assert typing.get_type_hints(f, localns=nonlocal_vars) == {'x': int} ``` I would just open a PR to have `get_type_hints` attempt to resolve closure variables by default. However, this would require an update to PEP 563 and I don't know what the protocol is there. - Caleb Donovick

3 4

Upcoming 3.7.10 and 3.6.13 Security Releases
by Ned Deily 03 Feb '21

03 Feb '21

We are planning to produce the next security-fix rollup releases for Python 3.7.x and 3.6.x on 2021-01-15. The most recent releases for these versions were on 2020-08-17. There has not been a lot of activity for either branch since then. Core developers: if you know of any additional security issues that should be addressed in these releases, please mark the relevant bpo issues as "release blocker" and, if possible, submit PRs for review prior to the end of 2021-01-14 AOE. Thanks! -- Ned Deily nad(a)python.org -- []

5 6

Python 3.10.0a5 is now available
by Pablo Galindo Salgado 03 Feb '21

03 Feb '21

Well, this one took a bit more time due to some surprise last time reference leaks and release blockers to fix, but now Python 3.10.0a5 it’s here. Will this be the first release announcement of the 3.10 series without copy-paste typos? Go get it here: https://www.python.org/downloads/release/python-3100a5/ *Major new features of the 3.10 series, compared to 3.9* Python 3.10 is still in development. This release, 3.10.0a5 is the fifth of seven planned alpha releases. Alpha releases are intended to make it easier to test the current state of new features and bug fixes and to test the release process. During the alpha phase, features may be added up until the start of the beta phase (2021-05-03) and, if necessary, may be modified or deleted up until the release candidate phase (2021-10-04). Please keep in mind that this is a preview release and its use is not recommended for production environments. Many new features for Python 3.10 are still being planned and written. Among the new major new features and changes so far: - PEP 623 <https://www.python.org/dev/peps/pep-0623/> – Remove wstr from Unicode - 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. - bpo-38605 <https://bugs.python.org/issue38605>: from __future__ import annotations (PEP 563 <https://www.python.org/dev/peps/pep-0563/>) is now the default. - 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. - (Hey, fellow core developer, if a feature you find important is missing from this list, let Pablo know <pablogsal(a)python.org>.) The next pre-release of Python 3.10 will be 3.10.0a6, currently scheduled for 2021-03-01. And now for something completely different The Chandrasekhar limit is the maximum mass of a stable white dwarf star. White dwarfs resist gravitational collapse primarily through electron degeneracy pressure, compared to main sequence stars, which resist collapse through thermal pressure. The Chandrasekhar limit is the mass above which electron degeneracy pressure in the star’s core is insufficient to balance the star’s own gravitational self-attraction. Consequently, a white dwarf with a mass greater than the limit is subject to further gravitational collapse, evolving into a different type of stellar remnant, such as a neutron star or black hole. Those with masses up to the limit remain stable as white dwarfs. The currently accepted value of the Chandrasekhar limit is about 1.4 M☉ (2.765×1030 kg). So we can be safe knowing that our sun is not going to become a black hole! Regards from cloudy London, Pablo Galindo Salgado

1 0

Constructing expected_opinfo_* lists in test_dis.py
by Skip Montanaro 02 Feb '21

02 Feb '21

I'm still messing around with my register VM stuff (off-and-on). I'm trying to adjust to some changes made a while ago, particularly (but probably not exclusively) after RERAISE acquired an argument. As a result, at least the expected_opinfo_jumpy list changed in a substantial way. I can manually work my way through it, but it sorta seems like someone might have used a script to translate the output of dis.dis(jumpy) into this list. Am I mistaken about this? Thx, Skip

3 5

[ Release ] Python 3.10a5 and release blockers
by Pablo Galindo Salgado 01 Feb '21

01 Feb '21

Hi everyone, I am prepared to start the release process for Python 3.10 a5 but there are several issues marked as release blockers that affect 3.10: * https://bugs.python.org/issue38302 * https://bugs.python.org/issue42634 * https://bugs.python.org/issue41490 * https://bugs.python.org/issue42967 * https://bugs.python.org/issue42899 Although release blockers mainly apply to important releases, there are two are security issues and some of the rest involve changes in bytecode or the tracing machinery, so I would prefer if these issues are addressed before making a new release as many maintainers are waiting for the next alpha to test again the bugs that they reported. Please, if you are involved in any of these issues try to see if is possible to address them or if you think is ok to release the alpha without a fix, please, drop me an email stating so. Thanks, Regards from cloudy London, Pablo Galindo Salgado

2 1

Why aren't we allowing the use of C11?
by Mark Shannon 01 Feb '21

01 Feb '21

Hi everyone, PEP 7 says that C code should conform to C89 with a subset of C99 allowed. It's 2021 and all the major compilers support C11 (ignoring the optional parts). C11 has support for thread locals, static asserts, and anonymous structs and unions. All useful features. Is there a good reason not to start using C11 now? Cheers, Mark.

14 17