[Python-Dev] RFC on PEP 673: Self Type

This PEP [1] introduces a simple and intuitive way to annotate methods and classmethods that return an instance of their class. Such methods and classmethods occur quite frequently, but the existing way to annotate them correctly is quite arcane and error-prone. The PEP introduces a special type

[Python-Dev] Re: Remove asyncore, asynchat and smtpd modules

I think it would be fine to wait just one release, until 3.12. Makes no substantial maintenance difference and maybe easier for users with more advanced notice, especially for module removal. I also wonder if maybe we should scale delay between dep -> removal based on maintenance burden estimate,

[Python-Dev] Re: Preventing Unicode-related gotchas (Was: pre-PEP: Unicode Security Considerations for Python)

Executive summary: I guess the bottom line is that I'm sympathetic to both the NFC and NFKC positions. I think that wetware is such that people will go to the trouble of picking out a letter-like symbol from a palette rarely, and in my environment that's not going to happen at all because I use J

[Python-Dev] Re: Preventing Unicode-related gotchas (Was: pre-PEP: Unicode Security Considerations for Python)

Steven D'Aprano wrote: > I think > that many editors in common use don't support bidirectional text, or at > least the ones I use don't seem to support it fully or correctly. ... > But, if there is a concrete threat beyond "it looks weird", that it > another issue. Based on the original post (a

[Python-Dev] Re: Preventing Unicode-related gotchas (Was: pre-PEP: Unicode Security Considerations for Python)

Stephen J. Turnbull wrote: > Christopher Barker writes: > > For example, in writing math we often use different scripts to mean > > different things (e.g. TeX's Blackboard Bold). So if I were to use > > some of the Unicode Mathematical Alphanumeric Symbols, I wouldn't > > want them to get normali

[Python-Dev] Re: Preventing Unicode-related gotchas (Was: pre-PEP: Unicode Security Considerations for Python)

Compatibility variants can look different, but they can also look identical. Allowing any non-ASCII characters was worrisome because of the security implications of confusables. Squashing compatibility characters seemed the more conservative choice at the time. Stestagg's example: е = lam

[Python-Dev] Re: Do we need to remove everything that's deprecated?

On 11/16/2021 7:43 AM, Petr Viktorin wrote: On 16. 11. 21 1:11, Brett Cannon wrote: I think the key point with that approach is if you wanted to maximize your support across supported versions, this would mean there wouldn't be transition code except when the SC approves of a shorter depreca

[Python-Dev] Re: Remove asyncore, asynchat and smtpd modules

I created https://github.com/python/steering-council/issues/86 to ask for a SC exception. Victor On Tue, Nov 16, 2021 at 8:11 PM Brett Cannon wrote: > > > > On Tue, Nov 16, 2021 at 3:05 AM Petr Viktorin wrote: >> >> On 12. 11. 21 13:09, Victor Stinner wrote: >> >>> It was decided to start depre

[Python-Dev] Re: Do we need to remove everything that's deprecated?

On Tue, Nov 16, 2021 at 4:46 AM Petr Viktorin wrote: > On 16. 11. 21 1:11, Brett Cannon wrote: > > > > > > On Sun, Nov 14, 2021 at 3:01 PM Victor Stinner > > wrote: > > > > On Sun, Nov 14, 2021 at 6:34 PM Eric V. Smith > > wrote: >

[Python-Dev] Re: portable venv

On Tue, Nov 16, 2021 at 8:08 AM Tamás Ozsváth wrote: > Hi All, > I tried to compose a protable virtualEnvironment using Python. I aready > found a solution which already works but still not stable. > So by creating venv in conventional way, I additionally copy the Python > executable and related

[Python-Dev] Re: Remove asyncore, asynchat and smtpd modules

On Tue, Nov 16, 2021 at 3:05 AM Petr Viktorin wrote: > On 12. 11. 21 13:09, Victor Stinner wrote: > >>> It was decided to start deprecating the asyncore, asynchat and smtpd > >>> modules in Python 3.6 released in 2016, 5 years ago. Python 3.10 emits > >>> DeprecationWarning. > >> > >> Wait, only

[Python-Dev] Re: Do we need to remove everything that's deprecated?

Maybe we can provide those deprecated things, but it need people add them manually and dynamically. By this, python can partially support other version python by provided minimum set instead of create a virtual evironment. For example, a big project use "SafeConfigParser" in it, to not change co

[Python-Dev] portable venv

Hi All, I tried to compose a protable virtualEnvironment using Python. I aready found a solution which already works but still not stable. So by creating venv in conventional way, I additionally copy the Python executable and related dlls, zip file, ._pth file to the root of venv folder. The weak

[Python-Dev] Re: Do we need to remove everything that's deprecated?

On 16. 11. 21 1:11, Brett Cannon wrote: On Sun, Nov 14, 2021 at 3:01 PM Victor Stinner > wrote: On Sun, Nov 14, 2021 at 6:34 PM Eric V. Smith mailto:e...@trueblade.com>> wrote: > On second thought, I guess the existing policy already does this. Maybe

[Python-Dev] Re: Remove asyncore, asynchat and smtpd modules

On 12. 11. 21 13:09, Victor Stinner wrote: It was decided to start deprecating the asyncore, asynchat and smtpd modules in Python 3.6 released in 2016, 5 years ago. Python 3.10 emits DeprecationWarning. Wait, only Python 3.10? According to the policy, the warning should be there for *at least*