[Python-Dev] Enum -- last call for comments on 3.10 changes

2021-06-28 Thread Ethan Furman 
I have spoken with Pablo (3.10 RM), and he agrees that a change to Enum str() in 3.10 and another in 3.11 is less than 
ideal, so this new thread is to collect comments about Enum and it's str() and repr() and whether the changes take 
effect in 3.10, 3.11, or both.


TL;DR -- sorry, there isn't one.

History:

As Enum and IntEnum have started proliferating in the stdlib, some of those enumerations have changed the str() and 
repr() of their members -- for example, in 3.8 re.RegexFlag had its repr() and str() changed to be module.name 
(re.ASCII) for both instead of  () for the repr(); that change made sense 
because all the members are exported to re's global name space, and they are accessed as `re.ASCII` in existing code.


While a good change (in my opinion and with which I had nothing to do), we now have stdlib enumerations with differing 
str() and repr()s, which is a minor ding against recognizability and usability.



Current 3.10 Changes

In an effort to standardize the stdlib enums, a new decorator was added: global_enum().  It can be called manually (for 
example in re.RegexFlag), or automatically by Enum._convert_ (for example in ssl.VerifyFlags).


That changed was visually appealing, and I had users wanting that type of output for Enum in general, so after asking 
for feedback on python-dev and python-ideas (and receiving little) I changed the basic str() and repr() of Enum to:


- str(): NAME
- repr(): enum.NAME

While working on some other bugs/changes in Enum.__format__ and serialization in general, I have come to believe that 
IntEnum (and IntFlag) should be as near-perfect a drop-in replacement as possible for when they are used to replace 
existing integer constants (which I believe is their most important use-case).



Reverting 3.10 Changes
--
I have been increasingly unhappy with the general `Enum.__repr__` change, so while the stdlib global repr() change is 
staying, Enum, IntEnum, etc., is going back to .



Proposed 3.10 Change (for 3.10.0 beta 4)

In order to improve the drop-in replacement use-case for IntEnum and IntFlag, I would like to change the str() for those 
two to be simply the value of the member, as if it was still a plain integer and not part of an enumeration.  At that 
point the only obvious difference would be the repr(), which I think is the most important and useful change as that is 
what (should) show up in log files, the REPL, etc.


This would also make IntEnum and IntFlag consistent with StrEnum as, for other reasons, StrEnum member str()s are the 
values of the members rather than the names of the members.  Note also that this change would not affect user created 
enumerations that mixed in int on their own.



The Question

With all the changes currently happening to the str()s and repr()s of the various enums, what are the good reasons to 
not make this final change now, and instead have one more change in 3.11?



--
~Ethan~


Summary of Enum str()s and repr()s by category

|   | repr() | str() | format()
| stdlib global | re.ASCII   | re.ASCII  | 256
| Enum  |  | Color.RED | RED
| IntEnum   |  | 1 | 1
| int, Enum |  | Color.RED | 1 (will be RED in 3.12 due to 
back-compatibility
|   || constraints which should affect 
very few people as
|   || as they are probably using 
IntEnum instead of mixing
|   || in int themselves -- comments 
about this likelihood also
|   || appreciated)
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/ZMC67QA2JVQJSWSFWRS6IM6ZX4EK277G/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Enum -- last call for comments on 3.10 changes

2021-06-28 Thread Nick Coghlan 
On Mon, 28 Jun 2021, 6:02 pm Ethan Furman,  wrote:

> I have spoken with Pablo (3.10 RM), and he agrees that a change to Enum
> str() in 3.10 and another in 3.11 is less than
> ideal, so this new thread is to collect comments about Enum and it's str()
> and repr() and whether the changes take
> effect in 3.10, 3.11, or both.
>
> TL;DR -- sorry, there isn't one.
>

I'll have a go at one:

* Enum str() continuing as "module.NAME", while format() omits the module
* Enum repr() changing back to the historical behaviour, unless you opt in
to the new behaviour with the global enum decorator: definite +1 here
* Making str() consistent with format() and the non-Enum base class for
IntEnum et al (it is already consistent for StrEnum) rather than displaying
the symbolic name

I know I said in the other thread that the last change was problematic, but
I think you have a strong argument that the current behaviour breaks the
"drop in replacement" promise of those concrete types.

So my vote would be to revert both the repr() and str() changes on IntEnum
(et al) for 3.10, and then switch to the new str() approach for those
classes in 3.11.

Cheers,
Nick.


>
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/5WHRHS3DKJF44DY5MSRUD7YCHDOC5B5L/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Enum -- last call for comments on 3.10 changes

2021-06-28 Thread Nick Coghlan 
On Mon, 28 Jun 2021, 11:54 pm Nick Coghlan,  wrote:

> So my vote would be to revert both the repr() and str() changes on IntEnum
> (et al) for 3.10, and then switch to the new str() approach for those
> classes in 3.11.
>


Sorry, I missed including the requested rationale:

* if the str() change is postponed to 3.11, then existing code will upgrade
seamlessly to 3.10, and there is a full year for notification of the coming
change to filter out. The cost is another year of the "drop in replacement"
promise not being kept
* code that was already updated to cope with the module name disappearing
from str presumably still handles it being present for compatibility with
older versions, so shouldn't be hard to adapt to the prefix coming back

(My opinion would likely be different if we were earlier in the beta cycle).

Cheers,
Nick.


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

[Python-Dev] Re: Enum -- last call for comments on 3.10 changes

2021-06-28 Thread Ethan Furman 

On 6/28/21 6:54 AM, Nick Coghlan wrote:

> * Enum repr() changing back to the historical behaviour, unless you opt in to 
the
>   new behaviour with the global enum decorator: definite +1 here

Question for Nick: this behavior is currently in place for stdlib enumerations, and has been since beta 0; are you 
saying this change should also be put off to 3.11 ?


--
~Ethan~
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/AVNMYCH5PZ7CI6COY6NEZKSXO4VV56CA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Enum -- last call for comments on 3.10 changes

2021-06-28 Thread Jelle Zijlstra 
El lun, 28 jun 2021 a las 1:00, Ethan Furman ()
escribió:

> I have spoken with Pablo (3.10 RM), and he agrees that a change to Enum
> str() in 3.10 and another in 3.11 is less than
> ideal, so this new thread is to collect comments about Enum and it's str()
> and repr() and whether the changes take
> effect in 3.10, 3.11, or both.
>
> TL;DR -- sorry, there isn't one.
>
> History:
> 
> As Enum and IntEnum have started proliferating in the stdlib, some of
> those enumerations have changed the str() and
> repr() of their members -- for example, in 3.8 re.RegexFlag had its repr()
> and str() changed to be module.name
> (re.ASCII) for both instead of 
> () for the repr(); that change made sense
> because all the members are exported to re's global name space, and they
> are accessed as `re.ASCII` in existing code.
>
> While a good change (in my opinion and with which I had nothing to do), we
> now have stdlib enumerations with differing
> str() and repr()s, which is a minor ding against recognizability and
> usability.
>
>
> Current 3.10 Changes
> 
> In an effort to standardize the stdlib enums, a new decorator was added:
> global_enum().  It can be called manually (for
> example in re.RegexFlag), or automatically by Enum._convert_ (for example
> in ssl.VerifyFlags).
>
> That changed was visually appealing, and I had users wanting that type of
> output for Enum in general, so after asking
> for feedback on python-dev and python-ideas (and receiving little) I
> changed the basic str() and repr() of Enum to:
>
> - str(): NAME
> - repr(): enum.NAME
>
> While working on some other bugs/changes in Enum.__format__ and
> serialization in general, I have come to believe that
> IntEnum (and IntFlag) should be as near-perfect a drop-in replacement as
> possible for when they are used to replace
> existing integer constants (which I believe is their most important
> use-case).
>
>
> Reverting 3.10 Changes
> --
> I have been increasingly unhappy with the general `Enum.__repr__` change,
> so while the stdlib global repr() change is
> staying, Enum, IntEnum, etc., is going back to .
>
Great!

>
>
> Proposed 3.10 Change (for 3.10.0 beta 4)
> 
> In order to improve the drop-in replacement use-case for IntEnum and
> IntFlag, I would like to change the str() for those
> two to be simply the value of the member, as if it was still a plain
> integer and not part of an enumeration.  At that
> point the only obvious difference would be the repr(), which I think is
> the most important and useful change as that is
> what (should) show up in log files, the REPL, etc.
>
> This would also make IntEnum and IntFlag consistent with StrEnum as, for
> other reasons, StrEnum member str()s are the
> values of the members rather than the names of the members.  Note also
> that this change would not affect user created
> enumerations that mixed in int on their own.
>
>
> The Question
> 
> With all the changes currently happening to the str()s and repr()s of the
> various enums, what are the good reasons to
> not make this final change now, and instead have one more change in 3.11?
>

Just to make myself less confused, the behavior of str(Color.RED) (where
Color is an IntEnum) is:
- 3.9 and below: "Color.RED"
- Current 3.10 branch: "RED"
- Proposed change: "256"

I agree that we shouldn't change the behavior in 3.10 and again in 3.11,
and also that the proposed behavior is the best long-term option.

If it's too late for completely new behavior in 3.10, we could instead
revert 3.10 to use the 3.9 behavior and make the change only in 3.11.


>
>
> --
> ~Ethan~
>
>
> Summary of Enum str()s and repr()s by category
>
> |   | repr() | str() | format()
>
Somewhat unrelatedly, I don't like that str() and format() may return
different results for enums; I think enums are the only type I commonly
encounter for which this is the case. If possible, any change we make
should move us closer to having both return the same result.


> | stdlib global | re.ASCII   | re.ASCII  | 256
> | Enum  |  | Color.RED | RED
> | IntEnum   |  | 1 | 1
> | int, Enum |  | Color.RED | 1 (will be RED in 3.12 due
> to back-compatibility
> |   || constraints which should
> affect very few people as
> |   || as they are probably using
> IntEnum instead of mixing
> |   || in int themselves --
> comments about this likelihood also
> |   || appreciated)
>
It does happen sometimes:
https://grep.app/search?q=%28int%2C%20Enum%29&case=true&filter[lang][0]=Python
.

> ___
> Python-Dev mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-dev.python.

[Python-Dev] [RELEASE] Python 3.9.6, 3.8.11, 3.7.11, and 3.6.14 are now available

2021-06-28 Thread Łukasz Langa 
Python 3.9.6

Get it here: https://www.python.org/downloads/release/python-396/ 

Python 3.9.6 is the newest major stable release of the Python programming 
language, and it contains many new features and optimizations. There’s been 146 
commits since 3.9.5 which is a similar amount compared to 3.8 at the same stage 
of the release cycle. See the change log 
 for details.

On macOS, we encourage you to use the universal2 binary installer variant 
whenever possible. The legacy 10.9+ Intel-only variant will not be provided for 
Python 3.10 and the universal2 variant will become the default download for 
future 3.9.x releases. You may need to upgrade third-party components, like 
pip, to later versions once they are released. You may experience differences 
in behavior in IDLE and other Tk-based applications due to using the newer 
version of Tk. As always, if you encounter problems when using this installer 
variant, please check https://bugs.python.org  for 
existing reports and for opening new issues.

The next Python 3.9 maintenance release will be 3.9.7, currently scheduled for 
2021-08-30.

The First Security-Only Release of Python 3.8

Get it here: https://www.python.org/downloads/release/python-3811/ 

Security content in this release contains three fixes. There’s also two fixes 
for 3.8.10 regressions. Take a look at the change log 
 for details.

According to the release calendar specified in PEP 569 
, Python 3.8 is now in security 
fixes only stage of its life cycle: 3.8 branch only accepts security fixes and 
releases of those are made irregularly in source-only form until October 2024. 
Python 3.8 isn’t receiving regular bugfixes anymore, and binary installers are 
no longer provided for it. Python 3.8.10 was the last full bugfix release of 
Python 3.8 with binary installers.

Security releases of 3.7.11 and 3.6.14

Get them here:
https://www.python.org/downloads/release/python-3711/ 

https://www.python.org/downloads/release/python-3614/ 

Security content in those releases contains five fixes each. Check out the 
relevant change logs for 3.7.11 
 and 3.6.14 
 for details.

Similarly to 3.8, Python 3.7 and 3.6 are now in security fixes only stage of 
their life cycle. Python 3.7 will be providing them until June 2023 while 
Python 3.6 ends its life in December 2021.

We hope you enjoy the new releases

Your friendly release team,
Ned Deily @nad 
Steve Dower @steve.dower 
Łukasz Langa @ambv 


signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/BXMRNZMXEJFXLZZ7SNMIS72R7CIUZQDZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] PEP 657 Accepted - Include Fine Grained Error Locations in Tracebacks

2021-06-28 Thread Barry Warsaw 
I’m happy to announce that PEP 657 (Include Fine Grained Error Locations in 
Tracebacks) has been unanimously accepted for Python 3.11 by the Python 
Steering Council.

Congratulations Pablo, Batuhan, and Ammar!

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



signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/3WDJNOW2SPTPCKUGLG2ANBWZZEYTT6F6/
Code of Conduct: http://python.org/psf/codeofconduct/