Ethan reached out to me for clarification and it turns out the work for
updating to the 3.10 changes actually isn't too bad for our codebase. On a
quick test, I did see several failures as a result of the change to str()
and repr() for enum members. For example, the repr() of a compound data
struct
On Mon, 28 Jun 2021, 12:44 am Nick Coghlan, wrote:
>
> For the other proposal, I think you're stuck from a backwards
> compatibility point of view - the default needs to be the current
> behaviour, with some way to opt out of using the symbolic str
> representation.
>
Although, looking at that p
On Thu, 24 Jun 2021, 12:58 pm Ethan Furman, wrote:
> 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
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
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 na
