Op 19-09-17 om 11:22 schreef Steven D'Aprano: > On Tue, 19 Sep 2017 09:10:04 +0200, Antoon Pardon wrote: > >> Op 18-09-17 om 15:47 schreef Paul Moore: >>> On 18 September 2017 at 14:30, Antoon Pardon <antoon.par...@vub.be> >>> wrote: >>>> Well that you reduce an object to a boolean value is not obvious to >>>> begin with. A TypeError because you are treating a non-boolean as a >>>> boolean would have been more obvious to me. >>> More obvious, possibly - that's essentially a matter of what people are >>> used to, and a measure of personal opinion. >>> >>> More useful? Unlikely. The practical examples I've seen of languages >>> like Python that implicitly convert non-boolean values to boolean, and >>> languages that don't (and raise an error if a non-boolean is supplied >>> to an if statement) suggest to me that implicit conversion is highly >>> useful. I certainly use it in my code (although in my view it's >>> perfectly "obvious", so I may use constructs that you would find >>> non-obvious). >> I don't find it really usefull. How useful is it that you can type if a: >> instead of if a != 0: ? > How useful is duck-typing? > > How useful is it to type: > > if a or b or c: ... > > instead of: > > if a.condition() or predicate(b) or c.somecondition(): ...
IMO not very much, in real life code, the latter code would probably much more clear than the former. > Objects already know how to convert themselves to strings, to generate a > repr, how to convert themselves to an iterator (if possible), etc. We > don't hesitate to duck-type any of these things and expect objects to > manage their own conversions. I am not so sure about strings. Otherwise there would be no need for all those formatting possibilities, that python provides. That the object knows how to convert itself to a string, doesn't mean it is the string that is useful to the user. > Except for bools, where people freak out and are convinced the world will > end if you just ask an object "are you true or false?". > > Perhaps just a *tiny* exaggeration *wink* On the other hand, python is very eager to convert objects to a bool. For strings and iterators you are expected to write a dunder method. If you think it makes no sense to see specific instances as true or false, you have to explicitly write a __bool__ that raises an exception. I think it would have been a better choice that a TypeError would have been raised if __bool__ wasn't defined. >> I have yet to encounter a situation where I >> thought: Yes I want to execute this piece of code when a value is Falsy >> and an other piece when that same value is Truthy. > But that's exactly what you've done with "if a != 0". You *literally* > executed code according to the truthiness of a. Only you did it with more > typing. But I was talking about how I *think* about those things. That after implementating these thoughts in python, python will cast all those things in the various concepts of truthy, doesn't contradict that was/is not how I approach(ed) the problems to be solved. -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list
