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

[Pradeep Kumar Srinivasan]

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 
`Self` to represent the type of the `self` parameter, similar to the `this` 
type in TypeScript and the `Self` type in Rust. We have implementations for 
mypy and pyright. The PEP does not affect CPython directly except for the 
addition of one special form (Self) to typing.py [2]. 

Since we have reached consensus on the PEP in typing-sig [3], we wanted to get 
your comments and suggestions before submitting to the Steering Council.

Thanks,
Pradeep Kumar Srinivasan
James Hilton-Balfe

[1]: https://www.python.org/dev/peps/pep-0673/
[2]: Adding `Self` to typing_extensions.py: 
https://github.com/python/typing/pull/933
[3]: See the comments from typing-sig members on the Google doc: 
https://docs.google.com/document/d/1ujuSMXDmSIOJpiZyV7mvBEC8P-y55AgSzXcvhrZciuI/edit?usp=sharing
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/G4F3ZMCJRWWRSF7O34Z7RPYQQK7QPGB6/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Kyle Stanley]

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, rather than 2 versions for all. Module
removal certainly takes more effort to adjust in code vs simple function
name change with 1:1 replacement.

-- 
--Kyle R. Stanley, Python Core Developer (what is a core dev?
)
*Pronouns: they/them **(why is my pronoun here?*

)
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/F52UKISVFFGBNCL2AZ4XVX2KL35O6ZNH/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Stephen J. Turnbull]

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 Japanese
phonetic input to get most symbols ("sekibun" = integral, "siguma" =
sigma), and I don't use calligraphic R for the real line, I use
\newcommand{\R}{{\cal R}}, except on a physical whiteboard, where I
use blackboard bold (go figure that one out!)  So to my mind the
letter-like block in Unicode is a failed experiemnt.

Jim J. Jewett writes:

 > When I was a math student, these were clearly different symbols,
 > with much less relation to each other than a mere case difference.

Arguable.  The letter-like symbols block has script (cursive),
blackboard bold, and Fraktur versions of R.  I've seen all of them as
well as plain Roman, bold, italic and bold italic facts used to denote
the real line, and I've personally used most of them for that purpose
depending on availability of fonts and input methods and medium (ie,
computer text vs. hand-written).  I've also seen several of them used
for reaction functions or spaces thereof in game theory (although
blackboard bold and Fraktur seem to be used uniquely for the real
line).  Clearly the common denominator is the uppercase latin letter
"R", and the glyph being recognizably "R" is necessary and sufficient
to each of those purposes.  The story for uppercase sigma as sum is
somewhat similar: sum is by far not the only use of that letter,
although I don't know of any other operator symbol for sum over a set
or series (outside of programming languages, which I think we can
discount).

I agree that we should consider math to be a separate language, but it
doesn't have a consistent script independent of the origins of the
symbols.  Even today none of my engineering and economics students can
type any symbols except those in the JIS repertoire, which they type
by original name ("siguma", "ramuda", "arefu", "yajirushi" == arrow,
etc, "sekibun" == integration does bring up the integral sign in at
least some modern input methods, but it doesn't have a script name,
while "kasann" == addition does not bring up sigma, although "siguma"
does, and "essu" brings up sigma -- but only in "ASCII emoji" strings,
go figure).  I have seen students use fullwidth R for the real line,
though, but distinguishing that is a deprecated compatibility feature
of Unicode (and of Japanese practice -- even in very formal university
documents such as grade reports for a final doctoral examination I've
seen numbers and names containing mixed half-width and full-width
ASCII).

So I think "letter-like" was a reasonable idea (I'm pretty sure this
block goes back to the '90s but I'm too lazy to check), but it hasn't
turned out well, and I doubt it ever will.

 > So by the Unicode consortium's goals, they are independent
 > characters that should each be defined.  I admit that isn't ideal
 > for most use cases outside of math,

I don't think it even makes sense *inside* of math for the letter-like
symbols.  The nature of math means that any "R" will be grabbed for
something whose name starts with "r" as soon as that's convenient.
Something like the integral sign (which is a stretched "S" for "sum"),
OK -- although category theory uses that for "ends" which still don't
look anything like integrals even if you turn them inside out, rotate
90 degrees, and paint them blue.

 > > It's also a UX problem.  At slightly higher layer in the stack, I'm
 > > used to using Japanese input methods to input sigma and pi which
 > > produce characters in the Greek block, and at least the upper case
 > > forms that denote sum and product have separate characters in the math
 > > operators block.
 > 
 > I think that is mostly a backwards compatibility problem; XeTeX
 > itself had to worry about compatibility with TeX (which preceded
 > Unicode) and with the fonts actually available and then with
 > earlier versions of XeTeX.

IMO, the analogy fails because the backward compatibility issue for
Unicode is in the wetware, not in the software.

Steve

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/YTIIFIF75RMWP5J3GCSXWVXSUP5SX7AA/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Jim J. Jewett]

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 (and how it looked in my web browser, after various 
automated reformattings, it seems that one of the failure modes that buggy 
editors have is that 

stuff can be part of the code, even though it looks like part of a comment, or 
vice versa

This problem might be limited to only some of the bidi controls, and there 
might even be a workaround specific to # ... but it is an issue.  I do not 
currently have an opinion on how important of an issue it is, or how adequate 
the workarounds are.

-jJ
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/ECO4R655UGPCVFFVAOQZ3DUZVHQY75BX/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Jim J. Jewett]

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

Agreed, for careful writers.  But Stephen's answer about people using the wrong 
one and expecting it to work means that normalization is probably the lesser of 
evils for most people, and the ones who don't want it normalized are more 
likely to be able to specify custom processing when it is important enough.  
(The compatibility characters aren't normalized in strings, largely because 
that should still be possible.)

> In fact, I think adding these symbols to Unicode was a bad idea; they
> should be handled at a higher level in the linguistic stack (by
> semantic markup).

When I was a math student, these were clearly different symbols, with much less 
relation to each other than a mere case difference. 
 So by the Unicode consortium's goals, they are independent characters that 
should each be defined.  I admit that isn't ideal for most use cases outside of 
math, but ... supporting those other cases is what compatibility normalization 
is for. 

> It's also a UX problem.  At slightly higher layer in the stack, I'm
> used to using Japanese input methods to input sigma and pi which
> produce characters in the Greek block, and at least the upper case
> forms that denote sum and product have separate characters in the math
> operators block.  I understand why people who literally write
> mathematics in Greek might want those not normalized, but I sure am
> going to keep using "Greek sigma", not "math sigma"!  The probability
> that I'm going to have a Greek uppercase sigma in my papers is nil,
> the probability of a summation symbol near unity.  But the summation
> symbol is not easily available, I have to scroll through all the
> preceding Unicode blocks to find Mathematical Operators.  So I am
> perfectly happy with uppercase Greek sigma for that role (as is
> XeTeX!!)

I think that is mostly a backwards compatibility problem; XeTeX itself had to 
worry about compatibility with TeX (which preceded Unicode) and with the fonts 
actually available and then with earlier versions of XeTeX.

-jJ
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/JNFLAQUKNCWCJSMBNJZGHVD5ZELOTU6G/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Jim J. Jewett]

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:
е = lambda е, e: е if е > e else e
shows it wasn't perfect, but adding more invisible differences does have risks, 
even beyond the backwards incompatibility and the problem with (hopefully rare, 
but are we sure?) editors that don't distinguish between them in the way a 
programming language would prefer.

I think (but won't swear) that there were also several problematic characters 
that really should have been treated as (at most) glyph variants, but ... 
weren't.  If I Recall Correctly, the largest number were Arabic presentation 
forms, but there were also a few characters that were in Unicode only to 
support round-trip conversion with a legacy charset, even if that charset had 
been declared buggy.  In at least a few of these cases, it seemed likely that a 
beginning user would expect them to be equivalent.

-jJ
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/GNT3AG2SCVLMCJAZXSTIWFKKAYG25E7O/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Terry Reedy]

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 
deprecation. So a project would simply rely on the deprecated approach 
until they started work towards Python 3.13, at which point they drop 
support for the deprecated approach and cleanly switch over to the new 
approach as all versions of Python at that point will support the new 
approach as well.


That sounds like a reasonable minimum for minor cleanups -- breakage 
that doesn't block improvements.


The current 'two years' minimum (and SC exceptions) is, IMO, appropriate 
for changes that do block improvements -- e.g. if removing old Unicode 
APIs allows reorganizing the internals to get a x% speedup, it should be 
removed after the 2-years of warnings (*if* the speedup is also made in 
that version -- otherwise the removal can be postponed).
Even better if there's some alternate API for the affected use cases 
which works on all supported Python versions.


I agree that the yearly releases make 2 releases with warnings a bit 
short.  Remove when a distributed replacement works in all supported 
releases seems pretty sensible.



And then there are truly trivial removals like the "failUnless" or 
"SafeConfigParser" aliases. I don't see a good reason to remove those -- 
they could stay deprecated forever.


This part I do not agree with.  In 3.10, there are 15 fail* and assert* 
aliases with a messy overlap pattern.

https://docs.python.org/3/library/unittest.html#deprecated-aliases
This is 15 unneeded names that appear in the doc, the index, vars(), 
dir(), TestCase.__dict__ listings, completion lists, etc.


If not used, there is no need to keep them.  If kept 'forever', they 
will be used, making unittest code harder to read.


There was a recent proposal to add permanent _ aliases for all stdlib 
camelCase names: assert_equal, assert_true, etc.  After Guido gave a 
strong No, the proposal was reduced to doing so for logging and unittest 
only.  If permanent aliases are blessed as normal, the proposal will 
recur and it would be harder to say no.


I expect that there would be disagreements as to what is trivial enough.

The only danger that API posed to 
users is that it might be removed in the future (and that will break 
their code), or that they'll get a warning or a linter nag.


Python is nearly 30 years old.  I am really glad it is not burdened with 
30 years of old names.  I expect someone reading this may write some 
version of Python 50 years from now.  I would not want they to have to 
read about names deprecated 60 years before such a time.



--
Terry Jan Reedy

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/AI2PHOUVL5KVSSHBN4MYEOGPSIWWL5M4/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Victor Stinner]

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 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* two
>> >> releases. (That's a minimum, for removing entire modules it might make
>> >> sense to give people even more time.)
>> >
>> > The PEP 387 says "Similarly a feature cannot be removed without notice
>> > between any two consecutive releases."
>> >
>> > It is the case here. The 3 modules are marked as deprecated for 4
>> > releases in the documentation: Python 3.6, 3.7, 3.9 and 3.10. Example:
>> > https://docs.python.org/3.6/library/asyncore.html
>>
>> PEP 387 also contains a detailed process for making incompatible
>> changes, which calls for warnings to appear in at least two releases.
>>
>> Do you think the process section can be ignored? We should remove it
>> from the PEP if that's the case.
>
>
> I don't think it should be ignored and the modules got yanked prematurely. A 
> request can be made to the SC, though, to expedite the removal with only one 
> release raising an exception.



-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/VQQPBASN5WHC4GEX7HLVWF26H6CMSNYV/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Brett Cannon]

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:
> >  > On second thought, I guess the existing policy already does this.
> > Maybe
> >  > we should make it more than 2 versions for deprecations? I've
> written
> >  > libraries where I support 4 or 5 released versions. Although
> maybe I
> >  > should just trim that back.
> >
> > If I understood correctly, the problem is more for how long is the
> new
> > way available?
> >
> >
> > I think Eric was suggesting more along the lines of PEP 387 saying that
> > deprecations should last as long as there is a supported version of
> > Python that *lacks* the deprecation. So for something that's deprecated
> > in 3.10, we wouldn't remove it until 3.10 is the oldest Python version
> > we support. That would be October 2025 when Python 3.9 reaches EOL and
> > Python 3.13 comes out as at that point you could safely rely on the
> > non-deprecated solution across all supported Python versions (or if you
> > want a full year of overlap, October 2026 and Python 3.14).
> >
> > 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 deprecation.
> > So a project would simply rely on the deprecated approach until they
> > started work towards Python 3.13, at which point they drop support for
> > the deprecated approach and cleanly switch over to the new approach as
> > all versions of Python at that point will support the new approach as
> well.
>
> That sounds like a reasonable minimum for minor cleanups -- breakage
> that doesn't block improvements.
>

> The current 'two years' minimum (and SC exceptions) is, IMO, appropriate
> for changes that do block improvements -- e.g. if removing old Unicode
> APIs allows reorganizing the internals to get a x% speedup, it should be
> removed after the 2-years of warnings (*if* the speedup is also made in
> that version -- otherwise the removal can be postponed).
> Even better if there's some alternate API for the affected use cases
> which works on all supported Python versions.
>

If enough people come forward supporting this idea then you could propose
to the SC that PEP 387 get updated with this guidance.

-Brett


>
>
>
> And then there are truly trivial removals like the "failUnless" or
> "SafeConfigParser" aliases. I don't see a good reason to remove those --
> they could stay deprecated forever. The only danger that API posed to
> users is that it might be removed in the future (and that will break
> their code), or that they'll get a warning or a linter nag.
>

If deprecations ever become permanent, then there will have to be a
cleaning of the stdlib first before we lock the team into this level of
support contract.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/D47IPVKOFREETNKNDWDDJY5NWBGQAN66/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: portable venv

[Brett Cannon]

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 dlls, zip file, ._pth file to the root of venv
> folder.
> The weak point of this solution is the pyvenv.cfg file and the value of
> the home variable!
> It can accept both absolute or relative paths, it is fine and good as it
> is. Using this solution (copiing Python executable and other files) and
> changing home path to .\venv(as relative) I am able to fetch packages by
> using pip install.
> But not all the packages! Eg pyinstaller changes the scope of calling
> Python.exe thatswhy not possible to fetch it. (Not found:
> .\venv\python.exe)
>
> I assume during parsing of home path inside pyenv.cfg by converting it to
> absolute path(if a relative path was given) behind the scene, I and anybody
> else would have a fully functionally portable virtualenv solution!
>

Do note that virtual environments do not work the same on all platforms.
For instance, on OSs that support symlinks (by default), the venv is not
self-contained by copying binaries in order to make their creation faster.
Virtual environments are also specifically designed and meant to be cheap
and disposable rather than relocatable/reusable in multiple situations.

If you want to make moving environments easier, then I would look at PEP
582: https://www.python.org/dev/peps/pep-0582/ .
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/G2GDWBMH6VPSJFPJOG7CAGIBPCVFUHSH/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Brett Cannon]

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 3.10?
> >> According to the policy, the warning should be there for *at least* two
> >> releases. (That's a minimum, for removing entire modules it might make
> >> sense to give people even more time.)
> >
> > The PEP 387 says "Similarly a feature cannot be removed without notice
> > between any two consecutive releases."
> >
> > It is the case here. The 3 modules are marked as deprecated for 4
> > releases in the documentation: Python 3.6, 3.7, 3.9 and 3.10. Example:
> > https://docs.python.org/3.6/library/asyncore.html
>
> PEP 387 also contains a detailed process for making incompatible
> changes, which calls for warnings to appear in at least two releases.
>
> Do you think the process section can be ignored? We should remove it
> from the PEP if that's the case.
>

I don't think it should be ignored and the modules got yanked prematurely.
A request can be made to the SC, though, to expedite the removal with only
one release raising an exception.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/WRYNHCXYNBV2CMF6UUB6BLOSVN24HHOI/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[zhouwenbonwpu]

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 code and 
change it with new python, it can provide oldname in a .xml file(or other 
file), than new python can Make corresponding modifications dynamically when 
project runs.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/6BARO4O42DRK4STZWZLMNYP4APE3VYWA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] portable venv

[Tamás Ozsváth]

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 point of this solution is the pyvenv.cfg file and the value of the 
home variable!
It can accept both absolute or relative paths, it is fine and good as it is. 
Using this solution (copiing Python executable and other files) and changing 
home path to .\venv(as relative) I am able to fetch packages by using pip 
install.
But not all the packages! Eg pyinstaller changes the scope of calling 
Python.exe thatswhy not possible to fetch it. (Not found:  .\venv\python.exe)
 
I assume during parsing of home path inside pyenv.cfg by converting it to 
absolute path(if a relative path was given) behind the scene, I and anybody 
else would have a fully functionally portable virtualenv solution!
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/3ODJAFXANFOTC5JB7TWEW45U46JHYI5U/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Petr Viktorin]

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
 > we should make it more than 2 versions for deprecations? I've written
 > libraries where I support 4 or 5 released versions. Although maybe I
 > should just trim that back.

If I understood correctly, the problem is more for how long is the new
way available?


I think Eric was suggesting more along the lines of PEP 387 saying that 
deprecations should last as long as there is a supported version of 
Python that *lacks* the deprecation. So for something that's deprecated 
in 3.10, we wouldn't remove it until 3.10 is the oldest Python version 
we support. That would be October 2025 when Python 3.9 reaches EOL and 
Python 3.13 comes out as at that point you could safely rely on the 
non-deprecated solution across all supported Python versions (or if you 
want a full year of overlap, October 2026 and Python 3.14).


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 deprecation. 
So a project would simply rely on the deprecated approach until they 
started work towards Python 3.13, at which point they drop support for 
the deprecated approach and cleanly switch over to the new approach as 
all versions of Python at that point will support the new approach as well.


That sounds like a reasonable minimum for minor cleanups -- breakage 
that doesn't block improvements.


The current 'two years' minimum (and SC exceptions) is, IMO, appropriate 
for changes that do block improvements -- e.g. if removing old Unicode 
APIs allows reorganizing the internals to get a x% speedup, it should be 
removed after the 2-years of warnings (*if* the speedup is also made in 
that version -- otherwise the removal can be postponed).
Even better if there's some alternate API for the affected use cases 
which works on all supported Python versions.




And then there are truly trivial removals like the "failUnless" or 
"SafeConfigParser" aliases. I don't see a good reason to remove those -- 
they could stay deprecated forever. The only danger that API posed to 
users is that it might be removed in the future (and that will break 
their code), or that they'll get a warning or a linter nag.



___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/THXWZ53X53I6GGLIDHO5T3Q4ZKALVGCP/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Petr Viktorin]

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* two
releases. (That's a minimum, for removing entire modules it might make
sense to give people even more time.)


The PEP 387 says "Similarly a feature cannot be removed without notice
between any two consecutive releases."

It is the case here. The 3 modules are marked as deprecated for 4
releases in the documentation: Python 3.6, 3.7, 3.9 and 3.10. Example:
https://docs.python.org/3.6/library/asyncore.html


PEP 387 also contains a detailed process for making incompatible 
changes, which calls for warnings to appear in at least two releases.


Do you think the process section can be ignored? We should remove it 
from the PEP if that's the case.


___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/KF34VL46ZAX6FWEFMXKZASPKF65USOZT/
Code of Conduct: http://python.org/psf/codeofconduct/