[Python-Dev] Re: Please be careful about changing PEPs post-submission to the SC

[Kyle Stanley]

FWIW that seems like a reasonable approach, at least to me.

On Thu, Nov 18, 2021, 5:29 PM Guido van Rossum  wrote:

> I know PEP 646 was one of these. In our defense, we *did* notify the SC
> that there was a pending issue (
> https://github.com/python/steering-council/issues/59#issuecomment-951728233),
> although at the time we didn't anticipate it to become such a contentious
> discussion between the PEP authors. (Though, while contentious, it's still
> a minor edge case in the PEP, and I don't think it would affect the SC's
> position which way we eventually end up going.)
>
> I'm guessing that the recommended approach in such a case is just to close
> the SC issue and reopen it once the PEP is updated?
>
> On Thu, Nov 18, 2021 at 12:04 PM Brett Cannon  wrote:
>
>> This is a personal plea (i.e. not coming from the SC at all), but in the
>> last month we have had PEPs changed twice post-submission to the SC. That's
>> a big time sink as we take multiple meetings to discuss a PEP and having
>> things change underneath us causes us to have to re-evaluate our
>> discussions (and I know I pretty much start thinking about PEPs once they
>> are submitted, whether we are actively discussing them or not and I'm
>> probably not the only SC member who does this).
>>
>> I know no one did this maliciously or anything, but since it's happened
>> twice now I just want to ask people be cognizant of this. Please reach out
>> to the SC if you want to make a change so we can discuss whether we think
>> it will help/hurt the PEP, etc. and we are also not taken off-guard by
>> things shifting (assume we don't monitor the commits and PRs to the peps
>> repo, so unless you explicitly say, "hold on", we won't realize discussions
>> are ongoing in a PR or anything). If that means withdrawing your PEP for
>> consideration for a while that's totally fine and it won't hurt your
>> chances of acceptance once you're at a stable state with your PEP.
>>
>> Once again, this is a personal ask and no one is mad at anyone. I'm just
>> asking people be very clear in communicating with us when they want to make
>> a change to a PEP or they have suddenly have an open issue they are still
>> discussing after they open an issue in the steering-council repo for us to
>> review a PEP and need us to stop considering their PEP for a while.
>> ___
>> 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/ZLC3H2XLEYJLFV3TRQ2EWRKRGZZ7DRMC/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
> --
> --Guido van Rossum (python.org/~guido)
> *Pronouns: he/him **(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/WJOTJ6V7XKRMDESEF3BD4DHOP4C3TRNK/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/44UCT4MC2NGSHSWBHOBSB363G3RPA5IW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Please be careful about changing PEPs post-submission to the SC

[Guido van Rossum]

I know PEP 646 was one of these. In our defense, we *did* notify the SC
that there was a pending issue (
https://github.com/python/steering-council/issues/59#issuecomment-951728233),
although at the time we didn't anticipate it to become such a contentious
discussion between the PEP authors. (Though, while contentious, it's still
a minor edge case in the PEP, and I don't think it would affect the SC's
position which way we eventually end up going.)

I'm guessing that the recommended approach in such a case is just to close
the SC issue and reopen it once the PEP is updated?

On Thu, Nov 18, 2021 at 12:04 PM Brett Cannon  wrote:

> This is a personal plea (i.e. not coming from the SC at all), but in the
> last month we have had PEPs changed twice post-submission to the SC. That's
> a big time sink as we take multiple meetings to discuss a PEP and having
> things change underneath us causes us to have to re-evaluate our
> discussions (and I know I pretty much start thinking about PEPs once they
> are submitted, whether we are actively discussing them or not and I'm
> probably not the only SC member who does this).
>
> I know no one did this maliciously or anything, but since it's happened
> twice now I just want to ask people be cognizant of this. Please reach out
> to the SC if you want to make a change so we can discuss whether we think
> it will help/hurt the PEP, etc. and we are also not taken off-guard by
> things shifting (assume we don't monitor the commits and PRs to the peps
> repo, so unless you explicitly say, "hold on", we won't realize discussions
> are ongoing in a PR or anything). If that means withdrawing your PEP for
> consideration for a while that's totally fine and it won't hurt your
> chances of acceptance once you're at a stable state with your PEP.
>
> Once again, this is a personal ask and no one is mad at anyone. I'm just
> asking people be very clear in communicating with us when they want to make
> a change to a PEP or they have suddenly have an open issue they are still
> discussing after they open an issue in the steering-council repo for us to
> review a PEP and need us to stop considering their PEP for a while.
> ___
> 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/ZLC3H2XLEYJLFV3TRQ2EWRKRGZZ7DRMC/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(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/WJOTJ6V7XKRMDESEF3BD4DHOP4C3TRNK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: SC Acceptance: PEP 646 -- Variadic Generics

[Matthew Rahtz via Python-Dev]

Hi Barry,

Absolutely fantastic - thank you for letting us know! As Guido says,
there's one final thing that we thought would be easy to resolve but has
actually turned out to be a little tricky. Happy to proceed as you think is
best here.

Matthew

On Wed, 17 Nov 2021 at 22:33, Guido van Rossum  wrote:

> Hi Barry,
>
> That's fantastic news!
>
> Somewhat embarrassingly, on typing-sig we're still discussing one or two
> final tweaks. In particular, the PEP as accepted forbids a certain
> construct (passing a tuple of indefinite length to a function using `*args:
> *Ts`) that after all we may actually want to allow. This would affect
> static type checkers only, there's no change in the grammar or runtime
> associated with lifting this restriction. See
> https://github.com/python/peps/pull/2125
>
> I presume the SC is okay with that?
>
> --Guido
>
> On Wed, Nov 17, 2021 at 2:15 PM Barry Warsaw  wrote:
>
>> Hello Mark, Matthew, Pradeep, Vincent, and Guido,
>>
>> The Python Steering Council discussed the latest version of PEP 646
>> (Variadic Generics) at our last meeting, and have unanimously decided to
>> accept the PEP.  Congratulations!
>>
>> We want to specifically mention that we appreciate the way you called out
>> the Python grammar changes required by the typing features you proposed.
>> As we’ve said before, the Steering Council strongly believes that the
>> typing language and the “general” Python programming language should remain
>> aligned, so the implications of syntax change proposed in the PEP for
>> typing needed to be addressed for non-typed Python as well.  The PEP
>> explains this change well, and does a good job of justifying the semantics
>> and usefulness of the change for non-type related purposes.
>>
>> Please feel free to change the PEP status to Accepted, and to merge your
>> changes to Python 3.11 at your convenience.
>>
>> With our appreciation,
>> -Barry (on behalf of the Python Steering Council)
>>
>>
>
> --
> --Guido van Rossum (python.org/~guido)
> *Pronouns: he/him **(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/2HNXWLHXRRJGP75SN2W7RHM2TIJVKWL6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Please be careful about changing PEPs post-submission to the SC

[Brett Cannon]

This is a personal plea (i.e. not coming from the SC at all), but in the
last month we have had PEPs changed twice post-submission to the SC. That's
a big time sink as we take multiple meetings to discuss a PEP and having
things change underneath us causes us to have to re-evaluate our
discussions (and I know I pretty much start thinking about PEPs once they
are submitted, whether we are actively discussing them or not and I'm
probably not the only SC member who does this).

I know no one did this maliciously or anything, but since it's happened
twice now I just want to ask people be cognizant of this. Please reach out
to the SC if you want to make a change so we can discuss whether we think
it will help/hurt the PEP, etc. and we are also not taken off-guard by
things shifting (assume we don't monitor the commits and PRs to the peps
repo, so unless you explicitly say, "hold on", we won't realize discussions
are ongoing in a PR or anything). If that means withdrawing your PEP for
consideration for a while that's totally fine and it won't hurt your
chances of acceptance once you're at a stable state with your PEP.

Once again, this is a personal ask and no one is mad at anyone. I'm just
asking people be very clear in communicating with us when they want to make
a change to a PEP or they have suddenly have an open issue they are still
discussing after they open an issue in the steering-council repo for us to
review a PEP and need us to stop considering their PEP for a while.
___
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/ZLC3H2XLEYJLFV3TRQ2EWRKRGZZ7DRMC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: SC Acceptance: PEP 646 -- Variadic Generics

[Brett Cannon]

I put the PEP back on our agenda to discuss this.

On Wed, Nov 17, 2021 at 2:40 PM Guido van Rossum  wrote:

> Hi Barry,
>
> That's fantastic news!
>
> Somewhat embarrassingly, on typing-sig we're still discussing one or two
> final tweaks. In particular, the PEP as accepted forbids a certain
> construct (passing a tuple of indefinite length to a function using `*args:
> *Ts`) that after all we may actually want to allow. This would affect
> static type checkers only, there's no change in the grammar or runtime
> associated with lifting this restriction. See
> https://github.com/python/peps/pull/2125
>
> I presume the SC is okay with that?
>
> --Guido
>
> On Wed, Nov 17, 2021 at 2:15 PM Barry Warsaw  wrote:
>
>> Hello Mark, Matthew, Pradeep, Vincent, and Guido,
>>
>> The Python Steering Council discussed the latest version of PEP 646
>> (Variadic Generics) at our last meeting, and have unanimously decided to
>> accept the PEP.  Congratulations!
>>
>> We want to specifically mention that we appreciate the way you called out
>> the Python grammar changes required by the typing features you proposed.
>> As we’ve said before, the Steering Council strongly believes that the
>> typing language and the “general” Python programming language should remain
>> aligned, so the implications of syntax change proposed in the PEP for
>> typing needed to be addressed for non-typed Python as well.  The PEP
>> explains this change well, and does a good job of justifying the semantics
>> and usefulness of the change for non-type related purposes.
>>
>> Please feel free to change the PEP status to Accepted, and to merge your
>> changes to Python 3.11 at your convenience.
>>
>> With our appreciation,
>> -Barry (on behalf of the Python Steering Council)
>>
>>
>
> --
> --Guido van Rossum (python.org/~guido)
> *Pronouns: he/him **(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/YBSS4FJ474TJ23XOUSFI5E6N7GAXB3T5/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/VRB3NJKZ4ZDKXY64EHCICVX4FMLB5BDV/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Petr Viktorin]

On Wed, Nov 17, 2021 at 12:49 AM Terry Reedy  wrote:
>
> 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.

Well, dir(), vars(), __dict__ and similar are already unpleasant --
ever since they started listing dunder methods, quite a long time ago.
But we could improve completion, docs and other cases that can filter the list.
How about adding a __deprecated__ attribute with a list of names that
tab completion should skip?

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

If they dedicated section is too distracting. they could be moved to a
subpage, reachable mainly by people searching for a particular name.
And the instructions on how to modernize code could be right next to
them.
___
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/7WRG54YN5LFFXDBUCCFRQYHRSEMLVIO5/
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 20:13, Brett Cannon wrote:



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
mailto:vstin...@python.org>
 > >> 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.


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


Yes, this thread is the first step :)



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.


I'm not looking for a contract, rather a best practice.
I think we should see Python's benign warts as nice gestures to the 
users: signs that we're letting them focus on issues that matter to 
them, rather than forcing them to join a quest for perfection.
If a wart turns out to be a tumor, we should be able to remove it after 
the 2 years of warnings (or less with an exception). That's fine as a 
contract. But I don't like "spring cleaning" -- removing everything the 
contract allows us to remove.


Ensuring more perfect code should be a job for linters, not the 
interpreter/stdlib.


___
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/NNKXTOSYXT2YH2FWZRFRMEFHYPN4BF66/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Victor Stinner]

Maybe once a function is deprecated in Python, pyupgrade should be
updated? I mean, more collaboration between Python core devs and the
pyupgrade development.

https://github.com/asottile/pyupgrade

Victor

On Thu, Nov 18, 2021 at 8:39 AM Jeremiah Paige  wrote:
>
> I’ve seen a few people in this thread proposing a new tool to automatically 
> update deprecations but I believe it already exists: pyupgrade. Looking over 
> its fixes once again, I don’t think it covers any of the original three 
> deprecations (maybe someone could open a PR?), but it does cover a lot 
> including failUnlessEqual and assertEquals.
>
> Regards,
> Jeremiah
> ___
> 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/PT2HDZSIXARGKVY4PDYMYYDLBVUI6LAO/
> Code of Conduct: http://python.org/psf/codeofconduct/



-- 
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/RXREPNDUAONRSHFMGR3NYG6FJFJHUJKF/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Eryk Sun]

On 11/13/21, Terry Reedy  wrote:
> On 11/13/2021 4:35 PM, pt...@austin.rr.com wrote:
>>
>> _퓟Ⅼ햠홲험ℋ풪Lᴰ푬핽﹏핷피헡 = 12
>>
>> def _픰ʰ퓸ʳ핥홚푛(픰, p푟픢fi햝핝횎푛, ｓᵤ푓헳헂푥헹ₑ횗):
>>
>>  ˢ헸ｉ헽 = 퐥ｅ혯(햘) - ｐr횎햋퐢x헅ᵉ퓷 - 풔홪ffｉ혅헹홚ₙ
>>
>>  if sｋi혱 > _퐏헟햠혊홴H핺Ｌ핯홀혙﹏L픈풩:
>>
>> 혴 = '%s[%d chars]%s' % (홨[:혱퐫핖푓핚ｘℓ풆핟], ₛ횔풊p, 퓼[퓁풆햓(횜) -
>> 홨횞풇fix홡ᵉ혯:])
>>
>>  return ₛ
>>
> * Does not at all work in CommandPrompt

It works for me when pasted into the REPL using the console in Windows
10. I pasted the code into a raw multiline string assignment and then
executed the string with exec(). The only issue is that most of the
pasted characters are displayed using the font's default glyph since
the console host doesn't have font fallback support. Even Windows
Terminal doesn't have font fallback support yet in the command-line
editing mode that Python's REPL uses. But Windows Terminal does
implement font fallback for normal output rendering, so if you assign
the pasted text to string `s`, then print(s) should display properly.

> even after supposedly changing to a utf-8 codepage with 'chcp 65000'.

Changing the console code page is unnecessary with Python 3.6+, which
uses the console's wide-character API. Also, even though it's
irrelevant for the REPL, UTF-8 is code page 65001. Code page 65000 is
UTF-7.
___
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/7FGNJ7TMASDOMQAS2LSSQAD2PPURT5W6/
Code of Conduct: http://python.org/psf/codeofconduct/