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

[Guido van Rossum]

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] SC Acceptance: PEP 646 -- Variadic Generics

[Barry Warsaw]

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)

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

[Python-Dev] The current state of typing PEPs

[Barry Warsaw]

Does PEP 563 or 649 satisfy static and dynamic typing needs?

In the interest of full transparency, we want to let the Python community know 
that the Steering Council continues to discuss PEP 563 (Postponed Evaluation of 
Annotations) and PEP 649 (Deferred Evaluation Of Annotations Using 
Descriptors).  We have concluded that we lack enough detailed information to 
make a decision in favor of either PEP.  As we see it, adopting either PEP 563 
or PEP 649 as the default would be insufficient. They will not fully resolve 
the existing problems these PEPs intend to fix, will break some existing code, 
and likely don’t address all the use cases and requirements across the static 
and dynamic typing constituents.  We are also uncertain as to the best 
migration path from the current state of affairs.

Defer decision on PEP 563 and 649 in 3.11

As such, at this time, the only reasonable path forward that the SC sees is to 
defer the decision in Python 3.11 again, essentially keeping the 3.10 status 
quo.  We know that this is far from ideal, but it’s also the safest path since 
we can’t clearly make the situation better, and we don’t have confidence that 
either PEP solves the problems once and for all.  Pragmatically, we don’t want 
to make the situation worse, and we really don’t want to find ourselves back 
here again in a couple of releases because we overlooked an important 
requirement for a set of users.

Calling for help from static and dynamic typing users

This is also a call to you, the folks who both care deeply about typing in 
Python, and have a solid understanding of the subject matter (or willingness to 
learn) to help us!  There are use cases we don’t know about, and unclear 
requirements from both the static and dynamic typing users.  We need help in 
defining those requirements clearly, in uncovering the use cases we’re not 
aware of, and most importantly, being an interface to typing enthusiasts to 
help build consensus with either of the proposed PEPs, or some other solution 
that doesn’t yet have a PEP (such as suggestions made by Łukasz in his blog 
post here: https://lukasz.langa.pl/61df599c-d9d8-4938-868b-36b67fdb4448/).

Volunteer to be a typing PEP shepherd

We’re looking for someone(s) who can be neutral as to the solution, 
knowledgeable enough to understand all sides of the problem, willing to serve 
as not quite a PEP author, not a PEP Delegate, but more than a PEP shepherd. If 
you are that person, please let us know!

Cheers,
-Barry (on behalf of the Python Steering Council)

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

[Python-Dev] SC Rejection: PEP 663 -- Standardizing Enum str(), repr(), and format() behaviors

[Barry Warsaw]

Hello Ethan,

The Steering Council has been discussing PEP 663 (Improving and Standardizing 
Enum str(), repr(), and format() behaviors), for the last few weeks.  We want 
to thank you for your work on this PEP and your continued work on enums in the 
standard library.

Upon further consideration, we have decided to reject this PEP, although we do 
agree with the need to change IntEnum’s str() or format(); see below.

Several reasons are leading the SC to its conclusion.  The first is that enums 
in the stdlib are already highly complex, and consistency is our top priority 
over time.  Having predictable and stable strs and reprs across Python versions 
is more important than the consistency among the various enum and non-enum 
types that the PEP proposes.  The PEP rightly states that “[b]ackwards 
compatibility of stringified objects is not guaranteed across major Python 
versions, and there will be backwards compatibility breaks where software uses 
the repr(), str(), and format() output of enums in tests, documentation, data 
structures, and/or code generation”. Yet, we don’t believe that this provides a 
blanket license to break such backward compatibility.  In this particular case, 
we believe the rationale given in the PEP is not sufficient justification for 
breaking this compatibility. Indeed, we have already seen cases of users 
impacted in different ways by this change, which led us into our previous 
decision to require a PEP for the changes.

Second, we find the PEP’s distinction between global and normal enum values to 
be highly confusing.  It makes predicting the results more difficult, since the 
results will differ for the same object depending on where the name it is bound 
to is defined, and how it is accessed.  To us, this makes understanding what 
object you are looking at much less clear. There are also not enough precedents 
for objects that modify their string representation based on where the name is 
bound.

Lastly, we’re concerned that all of these changes taken together leave us with 
a much more complicated enum implementation that is harder to maintain and 
understand. This may also make it more difficult for other Python 
implementations that do not have the same flexibility as CPython to do the 
necessary computations to distinguish between global / normal enumerations.

We understand that the rejection of this PEP means that some use cases may be 
more difficult to implement for users who need them, but we think that for the 
average user of enums, the current behavior is more predictable and 
comprehensible.  We also recognize that backing these changes out for 3.11 will 
be a non-trivial amount of work given the other changes to enum so far.  We 
want to find a way to help make that work easier for you.

One aspect of the PEP we do agree with is the alignment of IntEnum’s str() and 
format(). It is confusing that they give different results, and that is worth 
the small compatibility breakage to fix.   We are uncertain whether it’s better 
to change str to be more like format or vice versa.  Our recommendation is to 
take this discussion to python-dev and see if consensus on this topic can be 
reached.

On a related note, the SC has considered and approves your request for the 
backward compatibility exemption in 
https://github.com/python/steering-council/issues/80

Respectfully,
-Barry (on behalf of the Python Steering Council)


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

[Python-Dev] Re: The current state of typing PEPs

[Terry Reedy]

On 11/17/2021 5:47 PM, Barry Warsaw wrote:

Does PEP 563 or 649 satisfy static and dynamic typing needs?

In the interest of full transparency, we want to let the Python community know 
that the Steering Council continues to discuss PEP 563 (Postponed Evaluation of 
Annotations) and PEP 649 (Deferred Evaluation Of Annotations Using 
Descriptors).  We have concluded that we lack enough detailed information to 
make a decision in favor of either PEP.  As we see it, adopting either PEP 563 
or PEP 649 as the default would be insufficient. They will not fully resolve 
the existing problems these PEPs intend to fix, will break some existing code, 
and likely don’t address all the use cases and requirements across the static 
and dynamic typing constituents.  We are also uncertain as to the best 
migration path from the current state of affairs.

Defer decision on PEP 563 and 649 in 3.11

As such, at this time, the only reasonable path forward that the SC sees is to 
defer the decision in Python 3.11 again, essentially keeping the 3.10 status 
quo.  We know that this is far from ideal, but it’s also the safest path since 
we can’t clearly make the situation better, and we don’t have confidence that 
either PEP solves the problems once and for all.  Pragmatically, we don’t want 
to make the situation worse, and we really don’t want to find ourselves back 
here again in a couple of releases because we overlooked an important 
requirement for a set of users.


"In the face of ambiguity, refuse the temptation to guess."

I appreciate the carefully articulated reasoning being given with these 
PEP decisions.


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

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

[Jeremiah Paige]

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/