On Tue, Oct 06, 2020 at 09:30:06AM -0700, aleksiy123 wrote:

Currently there are a few Protocols https://docs.python.org/3/library/typing.html#protocols defined in the typing module. One that I recently felt like was missing was a typing annotation for classes with a __str__() method defined. Seems like a fairly straightforward implementation.

Why do you care specifically about the `__str__` dunder? Calling str() is one of those protocols that should always succeed, whether the argument defines `__str__`, `__repr__`, or inherits from object. Ignoring the possibility of bugs or deliberate raising, I can't think of any object that doesn't support the str() protocol. Have I missed anything? -- Steve

On Tue, Oct 6, 2020 at 6:50 PM Ricky Teachey wrote:

On Tue, Oct 6, 2020 at 9:35 PM Steven D'Aprano wrote:

...

On Tue, Oct 06, 2020 at 09:30:06AM -0700, aleksiy123 wrote:

...

Currently there are a few Protocols https://docs.python.org/3/library/typing.html#protocols defined in the typing module. One that I recently felt like was missing was a typing annotation for classes with a __str__() method defined. Seems like a fairly straightforward implementation.

Why do you care specifically about the `__str__` dunder? Calling str()

...

is one of those protocols that should always succeed, whether the argument defines `__str__`, `__repr__`, or inherits from object.

Ignoring the possibility of bugs or deliberate raising, I can't think of any object that doesn't support the str() protocol. Have I missed anything?

I was also finding this desire a little puzzling (and thought it might just be my inexperience).

And since both `type` and `object` have a __str__ method*, it seems like the only way any object could NOT support the str() protocol would be to write a __str__ method and deliberately bust it. Right? Is there even a way to create a python object that does not have `__str__` in the MRO?

Seeing as that is the case, and seeing as how the protocol system can't look inside your __str__ method to find out whether it is busted at type checking time, isn't `Any` all you'll ever need to type-hint the __str__ protocol?

* and upon checking in fact it is the same __str__ method

There's somewhat a precedent -- though it's a questionable one (Luciano discovered this). It shows how tricky these things are though. There's a `typing.SupportsFoat` protocol that checks for the presence of a `__float__` method, and a `typing.SupportsComplex` protocol that checks for `__complex__`. Ironically, complex numbers have a `__float__` method that always fails, and floats don't have a `__complex__` method but complex(x) succeeds if x is a float... -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...

On Wed, Oct 7, 2020, 3:43 AM Serhiy Storchaka wrote:

07.10.20 06:04, Guido van Rossum пише:

...

Ironically, complex numbers have a `__float__` method that always fails, and floats don't have a `__complex__` method but complex(x) succeeds if x is a float...

I wonder why not remove complex.__float__ (and complex.__int__, complex.__floordiv__, etc)?

I wonder the same thing myself and I bet it gets complicated fast. I was trying to use the numbers module to type hint any number including both floats and decimal.Decimal the other evening. It doesn't work... type checkers don't know Decimal is a Number. Finally I discovered the correct current solution is just Union[Decimal, float] or Union[Decimal, float, Real] if you want to include other real numbers like fractions.Fraction. St first I was really annoyed but from what I was able to gather after some reading Monday evening, this is a known problem that is getting worked on and is because the abcs in the current numbers module are somewhat unusable for type hinting and need to be replaced/updated to make Number and friends into protocols. And I came away grateful there are smart people people working on this to make things better, rather than annoyed. I'll be interested to see what is come up with as a solution in 3.10.

07.10.20 18:43, Guido van Rossum пише:

Usability in a different context. ```

...

...

...

z = 1j float(z) Traceback (most recent call last):   File "<stdin>", line 1, in <module> TypeError: can't convert complex to float float(object()) Traceback (most recent call last):   File "<stdin>", line 1, in <module> TypeError: float() argument must be a string or a number, not 'object'

If float(z) gave the second error message it would be rather confusing,
since z is a number. I guess the alternative would be to explicitly
check for complex in float() when producing the error message. (Or
phrase it as "real number", which actually might work.)

It is easy to fix. The trend is that functions which accept several different types of arguments should mention them all in a type error message instead of just the last one (e.g. "must be string, got 'complex'" while real numbers are accepted too). See https://bugs.python.org/issue41974.

I'm not sure what to do about Decimal though. I suspect we will end up making changes to both the numbers and decimal modules.

What are problems with Decimal?