Mailman 3 April 2021 - Python-Dev

NamedTemporaryFile and context managers
by Ethan Furman 09 Apr '21

09 Apr '21

In issue14243 [1] there are two issues being tracked: - the difference in opening shared files between posix and Windows - the behavior of closing the underlying file in the middle of NamedTemporaryFile's context management I'd like to address and get feedback on the context management issue. ```python from tempfile import NamedTemporaryFile with NamedTemporaryFile() as fp: fp.write(b'some data') fp = open(fp.name()) data = fp.read() assert data == 'some_data' ``` Occasionally, it is desirable to close and reopen the temporary file in order to read the contents (there are OSes that cannot open a temp file for reading while it is still open for writing). This would look like: ```python from tempfile import NamedTemporaryFile with NamedTemporaryFile() as fp: fp.write(b'some data') fp.close() # Windows workaround fp.open() data = fp.read() assert data == 'some_data' ``` The problem is that, even though `fp.open()` is still inside the context manager, the `close()` call deletes the file [2]. To handle this scenario, my proposal is two-fold: 1) stop using the TEMPFILE OS attribute so the OS doesn't delete the file on close 2) add `.open()` to NamedTemporaryFile A possible side effect of (1) is that temp files may accumulate if the interpreter crashes, but given the file-management abilities in today's software that seems like a minor annoyance at most. The backwards compatibility issue of (1) is that the file is no longer deleted after a manual `close()` -- but why one would call close() and then stay inside the CM, outside of testing, I cannot fathom. [3] So, opinions on modifying NamedTemporaryFile to not delete on close() if inside a CM, and add open() ? -- ~Ethan~ [1] https://bugs.python.org/issue14243 [2] plus, the `.open()` doesn't yet exist [3] feel free to educate me :-)

7 7

Re: PEP 647 Accepted
by Federico Salerno 09 Apr '21

09 Apr '21

I vaguely remember reading some discussion about Annotated and, for what little it's worth, I disagree with the consensus. For now all that comes to mind is either stuffing the information in docstrings (which would be kind of an involution, seeing as that was the way for annotating type before type annotations), or changing the name of the type to something more obvious at a glance. Something like Typeguards["param", T], if arbitrary strings could be included, which would have to correspond to parameter names. This would give a few extra advantages: - Multiple parameters could be annotated per function if needed (e.g. def my_function(param1, param2) -> Typeguards["param1", T, "param2", U]). An alternative syntax could be Typeguards[["param1", T], ["param2", U]] - Functions with additional parameters that the function uses but which are not typeguarded could be used, and there would be no ambiguity as to which parameter is affected by the typeguard: def my_function(param1: Any, param2: bool) -> Typeguards["param1", T] Personally, I like the idea of functions that /happen/ to restrict the type of a variable without it necessarily being their only or primary goal; this would enable those. Possible alternative names: Ensures["param1", T], Ensure["param1", T], IsType["param1", T]. It's important to remember that jargon creates a potential hurdle to comprehension, so simpler language should, in my opinion, always be preferred. Side-note: | is being introduced for union types in type annotations. Could it be an idea to add a & as well, to signal side-effects of the function that do not interfere with the return value? A function could then have a signature like: - def my_function(param1, param2) -> bool & Typeguards["param1", T] - def my_function(param1) -> int & Typeguards[T] # Only one param, so "param1" is optional I realise it would make signatures (optionally!) longer and arguably uglier, but the latter is mostly a matter of personal taster and of getting used to, which is always there when new features are introduced. I remember := being controversial, but it grew on me over time. I hope there's at least something worth considering in the above ideas. On 07/04/2021 21:59, guido(a)python.org wrote: > But it isn't a "side effect". It is a distinct concept that is > important to the type checker. > > Note that in TypeScript this also doesn't look like a boolean -- it > uses a unique syntax that has to be learned: > > function isCustomer(partner: any): partner is Customer { > . . . > } > > Arguably the TS syntax is more easily intuited without looking it up, > but TS has a certain freedom in its syntactic design that we don't > have for Python: new *syntax* has to be added to the Python parser and > can't be backported, whereas new *types* (like `TypeGuard[T]`) can > easily be backported via typing_extensions.py. > > We have really tried, but we did not come up with anything better than > the current PEP. > > FWIW you might be interested in Annotated (PEP 593), which can be used > to indicate various attributes of a type annotation. Before you > suggest that we adopt that instead of PEP 647, we considered that, and > the consensus is that that's not what Annotated is for (it's intended > for conveying information to tools *other* than the type checker, for > example schema checkers etc.). > > -- > --Guido van Rossum (python.org/~guido <http://python.org/~guido>) > /Pronouns: he/him //(why is my pronoun here?)/ > <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-…>

1 0

Help to Resolve issues with Pull request 25220
by anthony.flury 08 Apr '21

08 Apr '21

All, Can someone better than me (i.e anyone) help me resolve the issues with Pull Request 25220. I followed the dev guide, but I assume that between me taking my fork of the cpython repository, and building my pull request, another pull request was merged into master. It also appears that the Documentation build is failing with an rst reference tag error on part of the document I never changed. I am finding it difficult to drive github to understand how to resolve the conflict (i.e how to retain both sets of changes) - so any help would be appreciated. Regards, -- Anthony Flury *Moble*: +44 07743 282707 *Home*: +44 (0)1206 391294 *email*: anthony.flury(a)btinternet.com <mailto:anthony.flury@btinternet.com>

4 3

When we remove 'U' mode of open()?
by Inada Naoki 08 Apr '21

08 Apr '21

'U' mode was removed once and resurrected. https://bugs.python.org/issue39674 As far as I can see, it is postponed to Python 3.10. Am I right? Can we remove 'U' mode in Python 3.10? Regards, -- Inada Naoki <songofacandy(a)gmail.com>

6 9

How to attract developer attention to issue tracker items?
by pjfarley3＠earthlink.net 08 Apr '21

08 Apr '21

Hi developers, What should / shouldn't I do to attract any python developer response to issue tracker items? I am unsure of the proper procedure to follow so I am asking here first. I have filed two issues on the python issue tracker for python curses issues: 1. # 43715, a documentation update request (suggested additional documentation file uploaded) 2. # 43716, a possible ABI issue for the curses.pair_number() function return value in a Windows environment With respect to the documentation issue, I would appreciate any review of whether the suggested documentation addition that I uploaded as a text file is acceptable as-is or whether further refinement or correction is needed. In the case of the possible ABI issue I am uncertain whether the issue is in the python interface code or in the underlying curses implementation library (windows-curses V2.2.0 using PDCurses). I would appreciate it if anyone knowledgeable of the python curses interfacing code could advise me whether I need to pursue the issue with the third party library provider or with the python development team. At the moment all that I know is that the "workaround" that I discovered corrects the issue under Windows but is not necessary under linux / ncurses (in my testing I used Ubuntu 20.04 WSL2 to confirm that fact). TIA for your patience with my ignorance of the proper procedures and channels. My environment: Windows 10 Pro 64 (latest version) Python 3.8.9 (tags/v3.8.9:a743f81, Apr 6 2021, 14:02:34) [MSC v.1928 64 bit (AMD64)] Windows-curses V2.2.0 Peter --

2 2

Request for comments on final version of PEP 653 (Precise Semantics for Pattern Matching)
by Mark Shannon 07 Apr '21

07 Apr '21

Hi everyone, As the 3.10 beta is not so far away, I've cut down PEP 653 down to the minimum needed for 3.10. The extensions will have to wait for 3.11. The essence of the PEP is now that: 1. The semantics of pattern matching, although basically unchanged, are more precisely defined. 2. The __match_kind__ special attribute will be used to determine which patterns to match, rather than relying on the collections.abc module. Everything else has been removed or deferred. The PEP now has only the slightest changes to semantics, which should be undetectable in normal use. For those corner cases where there is a difference, it is to make pattern matching more robust. E.g. With PEP 653, pattern matching will work in the collections.abc module. With PEP 634 it does not. As always, all thoughts and comments are welcome. Cheers, Mark.

14 54

Call for attention: pip’s migration path from distutils to sysconfig is narrowing
by Tzu-ping Chung 07 Apr '21

07 Apr '21

Cross-posted from https://discuss.python.org/t/8111 on Brett’s suggestion. A while ago, I proposed pip’s migration plan from distutils to sysconfig[1], in preparation of distuitls’s deprecation and planned removal in Python 3.12. When working on the implementation, however, I realised sysconfig currently lacks important abstractions that pip needs to correctly interface with downstream Python redistributors and alternative Python implementations. I raised the issue in b.p.o.43312[2] and provided a pull request[3], but failed to progress things forward. With only one alpha window left[4], time is running out for the change to make it into 3.10. If this has to wait for 3.11, pip will be left with only one year to perform the migration away from distutils and detect possible backward incompatibilities, which, since Python packaging tends to have a very long tail of users on older Python versions, would make the distutils removal extremely disruptive. I wish this does not sound like I’m pressuring people to accept my patch; that is not my intention at all. I do, however, very strongly feel pip’s inability to remove distutils dependence is not taken seriously enough, and will be very problematic if the status quo continues. Either something is done for sysconfig in Python 3.10, or distutils’s removal must be delayed indefinitely until pip is able to replace its distutils usages with stdlib replacements. Otherwise, 3.12 users will not be able to use pip. [1]: https://github.com/pypa/pip/issues/9617 [2]: https://bugs.python.org/issue43312 [3]: https://github.com/python/cpython/pull/24644 [4]: https://discuss.python.org/t/8107 -- Tzu-ping Chung (@uranusjr) uranusjr(a)gmail.com https://uranusjr.com

1 0

NOTE: Python 3.9.3 contains an unintentional ABI incompatibility leading to crashes on 32-bit systems
by Łukasz Langa 06 Apr '21

06 Apr '21

The memory layout of PyThreadState was unintentionally changed in the recent 3.9.3 bugfix release. This leads to crashes on 32-bit systems when importing binary extensions compiled for Python 3.9.0 - 3.9.2. This is a regression. We will be releasing a hotfix 3.9.4 around 24 hours from now to address this issue and restore ABI compatibility with C extensions built for Python 3.9.0 - 3.9.2. Details: https://bugs.python.org/issue43710 - Ł

9 15

PEP 652 Accepted -- Maintaining the Stable ABI
by Pablo Galindo Salgado 06 Apr '21

06 Apr '21

Hi Petr, Thank you for submitting PEP 652 (Maintaining the Stable ABI). After evaluating the situation and discussing the PEP, the Steering Council is happy with the PEP and hereby accepts it. The Steering council thinks that this is a great step forward in order to have a clear definition of what goes into the Stable ABI and what guarantees the Python core team offers regarding the stable ABI while offering at the same time a plan to improve the maintenance and stability of the stable ABI. We would also like to see some improvements in the official documentation (not only on the devguide) regarding this topic and what guarantees do we offer (currently we only have a small section about this in https://docs.python.org/3/c-api/stable.html but there is a lot of information and clarifications in the PEP that we would like to be also in the documentation). Congratulations, Petr! With thanks from the whole Python Steering Council, Pablo Galindo Salgado

2 1

[RELEASE] The last Python 3.10 alpha (3.10.0a7) is available - Prepare for beta freeze
by Pablo Galindo Salgado 06 Apr '21

06 Apr '21

Brrrrr..... do you feel that? That's the chill of *beta freeze* coming closer. Meanwhile, your friendly CPython release team doesn’t rest even on holidays and we have prepared a shiny new release for you: Python 3.10.0a7. **************************************************** Dear fellow core developer: This alpha is the last release before feature freeze (2021-05-03), so make sure that all new features and PEPs are landed in the master branch before we release the first beta. Please, be specially mindfully to check the CI and the buildbots, maybe even using the test-with-buildbots label in GitHub before merging so the release team don’t need to fix a bunch of reference leaks or platform-specific problems on the first beta release. **************************************************** *Go get the new alpha here:* https://www.python.org/downloads/release/python-3100a7/ *Python 3.10.0a7*Release Date: April 5, 2021 This is an early developer preview of Python 3.10 *Major new features of the 3.10 series, compared to 3.9* Python 3.10 is still in development. This release, 3.10.0a7 is the last 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 – Deprecate and prepare for the removal of the wstr member in PyUnicodeObject. PEP 604 – Allow writing union types as X | Y PEP 612 – Parameter Specification Variables PEP 626 – Precise line numbers for debugging and other tools. bpo-38605: from __future__ import annotations (PEP 563) is now the default. PEP 618 – Add Optional Length-Checking To zip. bpo-12782: Parenthesized context managers are now officially allowed. PEP 632 – Deprecate distutils module. PEP 613 – Explicit Type Aliases PEP 634 – Structural Pattern Matching: Specification PEP 635 – Structural Pattern Matching: Motivation and Rationale PEP 636 – Structural Pattern Matching: Tutorial PEP 644 – Require OpenSSL 1.1.1 or newer PEP 624 – Remove Py_UNICODE encoder APIs PEP 597 – Add optional EncodingWarning (Hey, fellow core developer, if a feature you find important is missing from this list, let Pablo know.) The next pre-release of Python 3.10 will be 3.10.0b1 ( the first beta release and feature freeze ), currently scheduled for Monday, 2021-05-03. *And now for something completely different* In physics, the twin paradox is a thought experiment in special relativity involving identical twins, one of whom makes a journey into space in a high-speed rocket and returns home to find that the twin who remained on Earth has aged more. This result appears puzzling because each twin sees the other twin as moving, and so, as a consequence of an incorrect and naive application of time dilation and the principle of relativity, each should paradoxically find the other to have aged less. However, this scenario can be resolved by realising that the travelling twin is undergoing acceleration, which makes him a non-inertial observer. In both views, there is no symmetry between the spacetime paths of the twins. Therefore, the twin paradox is not a paradox in the sense of a logical contradiction. Your friendly release team, Pablo Galindo Salgado @pablogsal Ned Deily @nad Steve Dower @steve.dower

1 0