[Python-Dev] Re: Roundup to GitHub Issues migration

2021-06-23 Thread Paul Moore 
On Wed, 23 Jun 2021 at 01:21, Brett Cannon  wrote:
> Regardless, there are no plans to halt what was decided when we accepted PEP 
> 581. Most of the concerns which have been brought up in this thread were 
> already expressed back then (the account merge one I didn't remember, hence 
> why I replied).

I don't have a strong opinion regarding the use of github accounts,
but just to note, this thread was about the open issue in PEP 588, not
about PEP 581 -
https://www.python.org/dev/peps/pep-0588/#a-github-account-should-not-be-a-requirement.

PEP 588 has not been accepted, so it's not necessarily relevant to the
actual migration plan here, but I do think it's reasonable to ask for
some clarification. Either PEP 588 should be rejectected, noting that
the actual implementation plan is being maintained differently, or it
should be updated as an ongoing document as the planning process goes
ahead. I suspect the update on this particular open question might
well be "the problem was considered, and ultimately it was concluded
that requiring a github account was not a showstopper". That may not
please some people (I don't personally care) but that's fine - not
everything has to be unanimous, as long as the SC approves.

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

[Python-Dev] Re: Roundup to GitHub Issues migration

2021-06-23 Thread Antoine Pitrou 
On Tue, 22 Jun 2021 19:49:12 -0400
Ned Deily  wrote:
> 
> I think this points out a problem with our current bug system and one that it 
> would be good to try to resolve in migrating to a new system: that is, the 
> ambiguity of the "version" metadata in an issue. Today, that list of versions 
> is used in at least three different ways: 1. to document in what Python 
> versions the issue is present; 2. to document in what Python versions the 
> issue should be fixed, 3. to document in what versions the issue was fixed. 
> In many, probably most, cases, the "version" field of a particular issue is 
> used in both ways. When the issue is opened, the version is often set to the 
> versions affected. Then at various stages in its lifecycle, the issue's 
> version field will generally be changed to (possibly) reflect the candidate 
> versions for potential fixes (based on current
>   policy) and later (possibly) to the versions for which a fix was actually 
> merged. The various sets  of versions are useful information for different 
> purposes. It would be good to try to find a way 
>  to retain both, i.e. something like "affected versions", "targeted 
> versions", and "fixed versions". In any case, resolving the current ambiguity 
> would be good and could also save triage and housekeeping work.

+1. "Affected versions" and "fixed versions" at least seem necessary.
This is also what exists on e.g. the Apache JIRA tracker.

Regards

Antoine.


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

[Python-Dev] Re: Roundup to GitHub Issues migration

2021-06-23 Thread Barry Warsaw 
On Jun 22, 2021, at 15:52, Brett Cannon  wrote:
> 
> One thing I will remind people is I personally have led the work to move this 
> project from:
>   • SourceForge to our own infrastructure
>   • Mercurial to git
>   • Our own infrastructure to GitHub for code management
> So if GitHub were to do something we don't like we can always move platforms 
> again.

While I personally don’t think it will ever be necessary, one out would be a 
GitLab instance we stand up ourselves.  It doesn’t look to be too hard to 
migrate from GitHub to GitLab:

https://docs.gitlab.com/ee/user/project/import/github.html

Of course, that would still be infrastructure we’d have to run (unless we used 
gitlab.com, but then some people might still object), and that migration would 
also have to deal with Roundup issues if we don’t complete that migration.

-Barry



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

[Python-Dev] Re: Roundup to GitHub Issues migration

2021-06-23 Thread Barry Warsaw 
On Jun 23, 2021, at 03:21, Paul Moore  wrote:

> PEP 588 has not been accepted, so it's not necessarily relevant to the
> actual migration plan here, but I do think it's reasonable to ask for
> some clarification. Either PEP 588 should be rejectected, noting that
> the actual implementation plan is being maintained differently, or it
> should be updated as an ongoing document as the planning process goes
> ahead. I suspect the update on this particular open question might
> well be "the problem was considered, and ultimately it was concluded
> that requiring a github account was not a showstopper". That may not
> please some people (I don't personally care) but that's fine - not
> everything has to be unanimous, as long as the SC approves.

Mariatta is the author of PEP 588 and I’m the delegate.  Given how old that PEP 
is and the fact that Ezio is managing the project elsewhere, I think rejection 
is appropriate.  However if we do that I think the PEP should at least be 
updated with references to Ezio’s project, with some verbiage added as to why 
these changes are being made.

What do you think, Mariatta?

-Barry



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

[Python-Dev] Re: Roundup to GitHub Issues migration

2021-06-23 Thread Mariatta 
My understanding is that Ezio is/will be working on updating PEP 588.
Last I heard from Ezio is that he would be co-author of PEP 588 and he
would be updating it/rewrite it to better match the current migration plan.

I will check with Ezio and the gh-migration group on the status.

Thanks.

On Wed, Jun 23, 2021 at 10:33 AM Barry Warsaw  wrote:

>
>
> Mariatta is the author of PEP 588 and I’m the delegate.  Given how old
> that PEP is and the fact that Ezio is managing the project elsewhere, I
> think rejection is appropriate.  However if we do that I think the PEP
> should at least be updated with references to Ezio’s project, with some
> verbiage added as to why these changes are being made.
>
> What do you think, Mariatta?
>
> -Barry
>
>
___
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/YXXQEYTZIOG3DLDMQTNVWXI7EYS6MXY6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [python-committers] Roundup to GitHub Issues migration

2021-06-23 Thread Inada Naoki 
FWIW, GitHub announced new powerful Issues today.
https://github.com/features/issues

It may fill some gap between GitHub Issues and Roundup.

Regards,
-- 
Inada Naoki  
___
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/IVTIRU4X6PXAAMUKFJU3IJB35BAR4A67/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Towards removing asynchat, asyncore and smtpd from the stdlib

2021-06-23 Thread Irit Katriel via Python-Dev 
The asynchat [1] and asyncore [2] libraries have been deprecated since 3.6
in favor of asyncio [3].  In addition, smtpd [4], which depends on asynchat
and  asyncore, is deprecated in favor of aiosmtpd [5].

The documentation for each of these libraries mentions that it is
deprecated and refers to the suggested replacement. However, they do not
yet emit DeprecationWarnings at import, so people may be using them without
being aware that they are no longer maintained (there are a few dozen open
issues on bpo, some of them reporting bugs).

The next step is to add deprecation warnings, so that we can eventually
delete them. There is also the issue that some of the stdlib tests are
still using these libraries, but this does not need to block removing them
from the stdlib because we can move them to test.support until those tests
are rewritten.

Note that nobody needs to stop using these libraries if they don't want to
migrate to the suggested alternatives - the modules are pure python and
anyone can include a copy in their own codebase and continue using it in a
legacy application (or even continue maintaining it if they want).

Barry and I are working on a patch to add deprecation warnings in 3.10 when
one of these are imported [6]. Let us know if you have any comments on this
plan.

[1] https://docs.python.org/3/library/asynchat.html
[2] https://docs.python.org/3/library/asyncore.html
[3] https://docs.python.org/3/library/asyncio.html
[4] https://docs.python.org/3/library/smtpd.html
[5] https://aiosmtpd.readthedocs.io/en/latest/
[6] https://github.com/python/cpython/pull/26882
___
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/EN7X7OM63PE2FKVYGVGQE44YKBVDICSU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Towards removing asynchat, asyncore and smtpd from the stdlib

2021-06-23 Thread Miro Hrončok 

On 23. 06. 21 23:49, Irit Katriel via Python-Dev wrote:


Barry and I are working on a patch to add deprecation warnings in 3.10 when one 
of these are imported [6]. Let us know if you have any comments on this plan.


With my Fedora Python maintainer hat on, I am not particularly happy about this.

DeprecationWarnings have a tendency to break tests. I assumed Python 3.10.0b1 
to be the last release that intentionally breaks things that worked with Python 
3.9.


It's not a strong opinion and if there is a consensus that adding new 
DeprecationWarnings is not considered "new feature" or "breaking change", I 
won't fight it, but it feels wrong.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok

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

[Python-Dev] Re: Towards removing asynchat, asyncore and smtpd from the stdlib

2021-06-23 Thread Senthil Kumaran 
On Wed, Jun 23, 2021 at 10:49:04PM +0100, Irit Katriel via Python-Dev wrote:

> The next step is to add deprecation warnings, so that we can eventually delete
> them. There is also the issue that some of the stdlib tests are still using
> these libraries, but this does not need to block removing them from the stdlib
> because we can move them to test.support until those tests are rewritten.

This is a very good idea. I also read in another discussion that
offering these as pip installable external packages could be considered,
either by the core-dev or by community, just in case there is a reliance
on these packages in production code and the developers don't want those
the break and aren't ready to upgrade or migrate.

Thank you,
Senthil
___
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/AXWLKUFE7RGRNWPBWC3GYMXYDWDRK3LE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Towards removing asynchat, asyncore and smtpd from the stdlib

2021-06-23 Thread Barry Warsaw 
Miro, what tests (outside of Python itself) do you think may break, and do you 
have a way to check that?

-Barry

On Wed, Jun 23, 2021, at 17:15, Miro Hrončok wrote:
> On 23. 06. 21 23:49, Irit Katriel via Python-Dev wrote:
> > 
> > Barry and I are working on a patch to add deprecation warnings in 3.10 when 
> > one 
> > of these are imported [6]. Let us know if you have any comments on this 
> > plan.
> 
> With my Fedora Python maintainer hat on, I am not particularly happy about 
> this.
> 
> DeprecationWarnings have a tendency to break tests. I assumed Python 3.10.0b1 
> to be the last release that intentionally breaks things that worked with 
> Python 
> 3.9.
> 
> It's not a strong opinion and if there is a consensus that adding new 
> DeprecationWarnings is not considered "new feature" or "breaking change", I 
> won't fight it, but it feels wrong.
> 
> -- 
> Miro Hrončok
> -- 
> Phone: +420777974800
> IRC: mhroncok
> 
> ___
> 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/PIXK73MXIO7X6P7MDFBSTKTRDR2BWBMH/
> Code of Conduct: http://python.org/psf/codeofconduct/
> 
___
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/SI4Z777QAUYQF3P7TOZBBUGQNGZUXBAT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Towards removing asynchat, asyncore and smtpd from the stdlib

2021-06-23 Thread Miro Hrončok 

On 24. 06. 21 0:35, Barry Warsaw wrote:
Miro, what tests (outside of Python itself) do you think may break, and do you 
have a way to check that?


Any tests that import from asynchat, asyncore or smtpd (in the tests or in the 
tested code, even transitively trough other projects) if DeprecationWarnings 
are treated as errors by default -- many projects do this in tests (which is a 
very good way to get alerted of such deprecations when they happen) or even in 
setup.py (which I found rather weird).


Some examples of such failures with different new DeprecationWarnings from the 
recent Python 3.10 pre-releases testing (mostly fixed now):


- jinja2, subprocess-tee, sqlalchemy and more failed to build with Python 3.10:
  DeprecationWarning: There is no current event loop (treated as error)

- colcon-ros, ruamel-yaml, flake8 and more failed to build with Python 3.10:
  DeprecationWarning: The distutils package deprecated and slated for removal 
in Python 3.12 (got it via setuptools usage, treated as error)


- cherrypy failed to build with Python 3.10: pytest exited with no clear error 
message [1]



Yes, we have a way to check all Fedora's Python packages by reusing our Python 
3.10 pre-releases test-rebuild-everything mechanism, but it takes a few days to 
finish the builds and analyze the failures. Test failures caused by 
DeprecationWarnings are sometimes not obvious, e.g. not recognizable directly 
from the logs -- especially if they obscure some output that's checked for 
equality or line count (and all you get in the log is AssertionError: 20 != 
21), or when they exit entire pytest session without any error message 
(arguably, that does not happen that often [1]).


When such problems are found, it takes some time to report the problem to 
upstreams, fix the problem or workaround it (e.g. by filtering or ignoring the 
warning, which is not always trivial, especially when it propagates trough 
subprocess [2]).



At this point of the release cycle, I'd rather recognize, triage and report 
regressions.



[1] https://github.com/cherrypy/cherrypy/issues/1914#issuecomment-848780246
[2] https://github.com/pytest-dev/pytest/pull/8664


-Barry

On Wed, Jun 23, 2021, at 17:15, Miro Hrončok wrote:

On 23. 06. 21 23:49, Irit Katriel via Python-Dev wrote:
>
> Barry and I are working on a patch to add deprecation warnings in 3.10 when 
one

> of these are imported [6]. Let us know if you have any comments on this plan.

With my Fedora Python maintainer hat on, I am not particularly happy about this.

DeprecationWarnings have a tendency to break tests. I assumed Python 3.10.0b1
to be the last release that intentionally breaks things that worked with Python
3.9.

It's not a strong opinion and if there is a consensus that adding new
DeprecationWarnings is not considered "new feature" or "breaking change", I
won't fight it, but it feels wrong.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok

___
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/PIXK73MXIO7X6P7MDFBSTKTRDR2BWBMH/ 

Code of Conduct: http://python.org/psf/codeofconduct/ 






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



--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok

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

[Python-Dev] Re: [python-committers] Re: Roundup to GitHub Issues migration

2021-06-23 Thread Terry Reedy 

On 6/23/2021 4:28 PM, Inada Naoki wrote:

FWIW, GitHub announced new powerful Issues today.
https://github.com/features/issues

It may fill some gap between GitHub Issues and Roundup.


I signed up for the beta waiting list so I could experiment with it. 
Someone else would have to sign up 'Python'.


Terry

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

[Python-Dev] Re: [python-committers] Re: Roundup to GitHub Issues migration

2021-06-23 Thread Mariatta 
FWIW, GitHub announced new powerful Issues today.
> https://github.com/features/issues
>

I have asked GitHub to enable it for the Python org.



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

[Python-Dev] IntEnum, IntFlag, and the stdlib

2021-06-23 Thread Ethan Furman 

TL;DR  I am considering changing IntEnum and IntFlag's `__str__` to be 
`int.__str__`

IntEnum and IntFlag are becoming more common in the stdlib.  They currently 
show up in

* http
* re
* signal
* ssl
* socket

to name just a few.

3.10 already has some changes to the str() and repr() of enums in general:

HTTPStatus ->  OK  and  HTTPStatus.OK  instead of HTTPStatus.OK and 



Enum's that are taking the place of global constants have the repr() further 
modified:

RegexFlag -> ASCII  and  re.ASCII  instead of RegexFlag.ASCII and 



When Enum was first created we also modified the default JSON encoder to be able to encode int- and float-based 
enumerations; however, with the continued rise of Python in the world a user stumbled upon a stdlib encoder that we 
missed: `urllib.parse.urlencode()` (as seen in issue 33025 [1]).


IIRC enum.IntEnum (and later enum.IntFlag) were introduced so they could be drop-in replacements for existing integer 
constants.  At the time I didn't fully appreciate how those constants were used in code with regards to str() -- which 
is to say, changing the str() output can be a breaking change, even inside the stdlib.


What I would like to do for the enum module is make any supplied mixed-in enums 
a little more vanilla:

* str() is the mixed-in `__str__`, not the Enum `__str__`
* format() is the mixed-in `__format__`, not the Enum `__format__` (this is the 
current effective behavior already)

Other benefits, particularly repr(), would remain.  Note that a mixed enum created by a user would have the normal Enum 
`__str__` and `__format__`.



Summary:  mixed enums provided in the enum module should maintain the mixed 
data types `__str__` and `__format__`.

Thoughts?

--
~Ethan~



[1] https://bugs.python.org/issue33025
___
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/HE36QRXPPQNHGQKYZM3ZTG42EQQRHAIX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: IntEnum, IntFlag, and the stdlib

2021-06-23 Thread Jelle Zijlstra 
El mié, 23 jun 2021 a las 19:54, Ethan Furman ()
escribió:

> TL;DR  I am considering changing IntEnum and IntFlag's `__str__` to be
> `int.__str__`
>
> IntEnum and IntFlag are becoming more common in the stdlib.  They
> currently show up in
>
> * http
> * re
> * signal
> * ssl
> * socket
>
> to name just a few.
>
> 3.10 already has some changes to the str() and repr() of enums in general:
>
> HTTPStatus ->  OK  and  HTTPStatus.OK  instead of HTTPStatus.OK and
> 
>
>
> Enum's that are taking the place of global constants have the repr()
> further modified:
>
> RegexFlag -> ASCII  and  re.ASCII  instead of RegexFlag.ASCII and
> 
>
>
> When Enum was first created we also modified the default JSON encoder to
> be able to encode int- and float-based
> enumerations; however, with the continued rise of Python in the world a
> user stumbled upon a stdlib encoder that we
> missed: `urllib.parse.urlencode()` (as seen in issue 33025 [1]).
>
> IIRC enum.IntEnum (and later enum.IntFlag) were introduced so they could
> be drop-in replacements for existing integer
> constants.  At the time I didn't fully appreciate how those constants were
> used in code with regards to str() -- which
> is to say, changing the str() output can be a breaking change, even inside
> the stdlib.
>
> What I would like to do for the enum module is make any supplied mixed-in
> enums a little more vanilla:
>
> * str() is the mixed-in `__str__`, not the Enum `__str__`
> * format() is the mixed-in `__format__`, not the Enum `__format__` (this
> is the current effective behavior already)
>
> Other benefits, particularly repr(), would remain.  Note that a mixed enum
> created by a user would have the normal Enum
> `__str__` and `__format__`.
>
>
> Summary:  mixed enums provided in the enum module should maintain the
> mixed data types `__str__` and `__format__`.
>
> Thoughts?
>

This seems like it's going to be a backwards incompatible change that may
turn out to be fairly disruptive for the codebase I have to maintain. We
use IntEnum heavily and any change in behavior is likely to require
migration work. I'm already pretty worried about the other enum changes in
3.10.


>
> --
> ~Ethan~
>
>
>
> [1] https://bugs.python.org/issue33025
> ___
> 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/HE36QRXPPQNHGQKYZM3ZTG42EQQRHAIX/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/ZIUN5MTAS75QI2UFSIN5YO6SVIY3AXNY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: IntEnum, IntFlag, and the stdlib

2021-06-23 Thread Guido van Rossum 
Oh, it's definitely too late for 3.10.

On Wed, Jun 23, 2021 at 8:16 PM Jelle Zijlstra 
wrote:

>
>
> El mié, 23 jun 2021 a las 19:54, Ethan Furman ()
> escribió:
>
>> TL;DR  I am considering changing IntEnum and IntFlag's `__str__` to be
>> `int.__str__`
>>
>> IntEnum and IntFlag are becoming more common in the stdlib.  They
>> currently show up in
>>
>> * http
>> * re
>> * signal
>> * ssl
>> * socket
>>
>> to name just a few.
>>
>> 3.10 already has some changes to the str() and repr() of enums in general:
>>
>> HTTPStatus ->  OK  and  HTTPStatus.OK  instead of HTTPStatus.OK and
>> 
>>
>>
>> Enum's that are taking the place of global constants have the repr()
>> further modified:
>>
>> RegexFlag -> ASCII  and  re.ASCII  instead of RegexFlag.ASCII and
>> 
>>
>>
>> When Enum was first created we also modified the default JSON encoder to
>> be able to encode int- and float-based
>> enumerations; however, with the continued rise of Python in the world a
>> user stumbled upon a stdlib encoder that we
>> missed: `urllib.parse.urlencode()` (as seen in issue 33025 [1]).
>>
>> IIRC enum.IntEnum (and later enum.IntFlag) were introduced so they could
>> be drop-in replacements for existing integer
>> constants.  At the time I didn't fully appreciate how those constants
>> were used in code with regards to str() -- which
>> is to say, changing the str() output can be a breaking change, even
>> inside the stdlib.
>>
>> What I would like to do for the enum module is make any supplied mixed-in
>> enums a little more vanilla:
>>
>> * str() is the mixed-in `__str__`, not the Enum `__str__`
>> * format() is the mixed-in `__format__`, not the Enum `__format__` (this
>> is the current effective behavior already)
>>
>> Other benefits, particularly repr(), would remain.  Note that a mixed
>> enum created by a user would have the normal Enum
>> `__str__` and `__format__`.
>>
>>
>> Summary:  mixed enums provided in the enum module should maintain the
>> mixed data types `__str__` and `__format__`.
>>
>> Thoughts?
>>
>
> This seems like it's going to be a backwards incompatible change that may
> turn out to be fairly disruptive for the codebase I have to maintain. We
> use IntEnum heavily and any change in behavior is likely to require
> migration work. I'm already pretty worried about the other enum changes in
> 3.10.
>
>
>>
>> --
>> ~Ethan~
>>
>>
>>
>> [1] https://bugs.python.org/issue33025
>> ___
>> 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/HE36QRXPPQNHGQKYZM3ZTG42EQQRHAIX/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
> ___
> 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/ZIUN5MTAS75QI2UFSIN5YO6SVIY3AXNY/
> 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 -- [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/WXRTAWKIMSGX7GNIK3XCWU7BGB3QXRVL/
Code of Conduct: http://python.org/psf/codeofconduct/