On 4/20/21 2:11 PM, MRAB wrote:
> On 2021-04-20 20:42, Ethan Furman wrote:
>> The deprecation period will give that user, and others like them, time to
add their own Enum base classes with the
>> `__format__` method they desire.
>
> Couldn't the format accept 'd' if they want an int, i.e. f"{Col
20.04.21 17:56, Ethan Furman пише:
> urllib.urlencode currently uses `str()` on its non-bytes objects before
> encoding the result. This causes a compatibility break when integer
> module constants are converted to IntEnum, as `str(IntEnum.MEMBER)` no
> longer returns the integer representation; h
20.04.21 22:01, Guido van Rossum пише:
> So to be clear, that one user wants f"{Color.RED}" to return "1" and not
> " Color.RED" (or something like that).
The user should write f"{int(Color.RED)}" or f"{Color.RED.value}".
I have also an idea to support of additional conversion characters, so
the
On 2021-04-20 20:42, Ethan Furman wrote:
On 4/20/21 12:01 PM, Guido van Rossum wrote:
> On Tue, Apr 20, 2021 at 11:12 AM Ethan Furman wrote:
>> Moving forward, I'm not sure having format() and str() ever be different
>> is a good idea, especially since users who need, for example, Color.RE
On 4/20/21 12:01 PM, Guido van Rossum wrote:
> On Tue, Apr 20, 2021 at 11:12 AM Ethan Furman wrote:
>> Moving forward, I'm not sure having format() and str() ever be different
>> is a good idea, especially since users who need, for example, Color.RED
>> to be '1' can simply add a `__str__ = int._
On Tue, Apr 20, 2021 at 11:12 AM Ethan Furman wrote:
> On 4/20/21 8:46 AM, Guido van Rossum wrote:
>
> > I'd guess it is totally up to the object, since str() calls `__str__`
> and format() calls `__format__`. Of course this
> > now begs the question whether those enums should perhaps change thei
It has always bugged me that for Enums mixed in with int or str (a common
pattern in my code), `f"{MyEnum.X}"` is not the same as `str(MyEnum.X)`.
I'd be happy to see it changed!
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send a
On 4/20/21 8:46 AM, Guido van Rossum wrote:
I'd guess it is totally up to the object, since str() calls `__str__` and format() calls `__format__`. Of course this
now begs the question whether those enums should perhaps change their `__format__` to match their `__str__`...?
When Enum was design
On 4/20/2021 11:13 AM, Eric V. Smith wrote:
On 4/20/2021 10:56 AM, Ethan Furman wrote:
urllib.urlencode currently uses `str()` on its non-bytes objects
before encoding the result. This causes a compatibility break when
integer module constants are converted to IntEnum, as
`str(IntEnum.MEMBER
On 4/20/2021 10:56 AM, Ethan Furman wrote:
urllib.urlencode currently uses `str()` on its non-bytes objects
before encoding the result. This causes a compatibility break when
integer module constants are converted to IntEnum, as
`str(IntEnum.MEMBER)` no longer returns the integer representatio
I'd guess it is totally up to the object, since str() calls `__str__` and
format() calls `__format__`. Of course this now begs the question whether
those enums should perhaps change their `__format__` to match their
`__str__`...? But that would not suit your purpose. Then again, how would
one get t
11 matches
Mail list logo
