[issue35712] Make NotImplemented unusable in boolean context

Alex Waygood added the comment: Thanks, Serhiy, that makes sense. I'll consider raising this elsewhere, as you suggest. -- ___ Python tracker ___

[issue35712] Make NotImplemented unusable in boolean context

Serhiy Storchaka added the comment: Interesting, it is because object().__eq__(object()) returns NotImplemented instead of False. object.__eq__ could return False if arguments have same type (or in some other cases). I think it would not break anything, and it would fix your case. But I am

[issue35712] Make NotImplemented unusable in boolean context

Alex Waygood added the comment: Thanks, Vedran. I read https://bugs.python.org/issue35712#msg349303 before adding my message, but am not quite clear why my snippet is the same situation. `next(filter((2).__eq__, 'text'))` surely returns 't' because `(2).__eq__('t')` returns `NotImplemented`

[issue35712] Make NotImplemented unusable in boolean context

Vedran Čačić added the comment: Please see the message https://bugs.python.org/issue35712#msg349303. Filtering with those dunder sesqui-dispatch methods really is a bug magnet. -- ___ Python tracker

[issue35712] Make NotImplemented unusable in boolean context

Alex Waygood added the comment: The following code now leads to a `DeprecationWarning`, but I am unclear why it should. ``` >>> from enum import Enum >>> >>> class CardColour(Enum): ... """Enumeration of the two colours in a pack of cards.""" ... ... BLACK = 'black' ... RED = 'r

[issue35712] Make NotImplemented unusable in boolean context

Change by Guido van Rossum : -- nosy: -gvanrossum ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://ma

[issue35712] Make NotImplemented unusable in boolean context

Serhiy Storchaka added the comment: I am sad that such code (as well as my former code in total_ordering) no longer works, but this is just a clever trick, and the code can be written in less clever but more explicit way. On other hand, the warning helps to catch common mistakes like not

[issue35712] Make NotImplemented unusable in boolean context

Raymond Hettinger added the comment: > I assume you've been recommending this? Not really, but it does come up and I've seen it in customer code more than once. I do show people this: >>> data = [10.5, 3.27, float('Nan'), 56.1] >>> list(filter(isfinite, data)) [10.5, 3.27, 56.1]

[issue35712] Make NotImplemented unusable in boolean context

Guido van Rossum added the comment: That's off topic for this issue -- you can go to python-ideas to propose that. -- ___ Python tracker ___ __

[issue35712] Make NotImplemented unusable in boolean context

Vedran Čačić added the comment: ... as it probably should: look at https://bugs.python.org/msg349303 Yes, filtering comprehensions are a frequently used niche, and too long in the "official" parlance. I seem to recall that [x in mylist if x is not None] (instead of triple-x version) was

[issue35712] Make NotImplemented unusable in boolean context

Guido van Rossum added the comment: > list(filter(None.__ne__, L)) I assume you've been recommending this? To me it looks obfuscated. People should just use a comprehension, e.g. [x for x in L if x is not None] -- ___ Python tracker

[issue35712] Make NotImplemented unusable in boolean context

Raymond Hettinger added the comment: One of the idioms for removing None no longer works: >>> L = [0, 23, 234, 89, None, 0, 35, 9] >>> list(filter(None.__ne__, L)) Warning (from warnings module): File "", line 1 DeprecationWarning: NotImplemented should not be used in a boolean context [0, 2

[issue35712] Make NotImplemented unusable in boolean context

Ethan Furman added the comment: Hmm. Okay, I'm happy with just raising a TypeError in NotImplemented.__bool__. -- ___ Python tracker ___ _

[issue35712] Make NotImplemented unusable in boolean context

Serhiy Storchaka added the comment: > How is -1 interpreted? Does it become a TypeError? It is interpreted as error. It requires an exception be set. If you return -1 without setting an exception you will usually get a SystemError or crash. Oh, and this may happen during executing other cod

[issue35712] Make NotImplemented unusable in boolean context

Ethan Furman added the comment: Serhiy: -- > First, it is impossible. nb_bool and PyObject_IsTrue() can return > only three value: 1 for true, 0 for false, and -1 for error. Huh. How is -1 interpreted? Does it become a TypeError? > It is not possible to represent NotImplemented without

[issue35712] Make NotImplemented unusable in boolean context

Serhiy Storchaka added the comment: No. First, it is impossible. nb_bool and PyObject_IsTrue() can return only three value: 1 for true, 0 for false, and -1 for error. It is not possible to represent NotImplemented without breaking all extensions. Currently if not a: b() els

[issue35712] Make NotImplemented unusable in boolean context

Ethan Furman added the comment: I know I'm late to the party, but if bool(NotImplemented) returned `NotImplemented` wouldn't that solve the problem? def __ge__(self, other): return not self.__lt__(other) then if __lt__ returns then __gt__ returns NotImplemented

[issue35712] Make NotImplemented unusable in boolean context

Change by Serhiy Storchaka : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue35712] Make NotImplemented unusable in boolean context

Serhiy Storchaka added the comment: New changeset 469325c30e147680543b2f5118b83fd95055a499 by MojoVampire in branch 'master': bpo-35712: Make using NotImplemented in a boolean context issue a deprecation warning (GH-13195) https://github.com/python/cpython/commit/469325c30e147680543b2f5118b8

[issue35712] Make NotImplemented unusable in boolean context

Vedran Čačić added the comment: Another reason why current behavior is confusing: what do you think filter(2 .__eq__, 'text') should yield? :-o (Yes, I know this isn't the right way to do it, but (element for element in 'text' if element == 2) is twice longer.:) -- nosy: +v

[issue35712] Make NotImplemented unusable in boolean context

Serhiy Storchaka added the comment: I do not have a strong opinion, so I suggest to not mention neither TypeError, nor RuntimeWarning. After some time of using a DeprecationWarning we can have have some information about whether there is a code which can't be fixed if bool(NotImplemented) wi

[issue35712] Make NotImplemented unusable in boolean context

Josh Rosenberg added the comment: In the docs for my PR, I mention using NotImplemented in a boolean context is deprecated, raising DeprecationWarning, and will raise TypeError in a future version of Python. Serhiy has suggested the end state might be RuntimeWarning instead of TypeError. I'm

[issue35712] Make NotImplemented unusable in boolean context

Josh Rosenberg added the comment: Moving to 3.9 target, per Serhiy's request. PR has been rebased against master, including updating the What's New info to be in the 3.9 version, not 3.8. -- versions: +Python 3.9 -Python 3.8 ___ Python tracker

[issue35712] Make NotImplemented unusable in boolean context

Josh Rosenberg added the comment: I've submitted a PR for this. I did discover a use case for boolean evaluation while doing this in the functools.total_ordering helpers. While it's legitimate, it *looks* wrong (the code looks like it didn't consider the possibility of NotImplemented even th

[issue35712] Make NotImplemented unusable in boolean context

Change by Josh Rosenberg : -- keywords: +patch pull_requests: +13106 stage: test needed -> patch review ___ Python tracker ___ ___ P

[issue35712] Make NotImplemented unusable in boolean context

Terry J. Reedy added the comment: I consider it a nice feature of Python that all builtin objects, and, AFAIK (and Josh, apparently), all stdlib class instances, have a boolean value. (I am aware of numpy's element-wise behavior.) I hate to give this up. This is part of Python's general a

[issue35712] Make NotImplemented unusable in boolean context

Guido van Rossum added the comment: I agree. On Thu, Jan 10, 2019 at 11:24 PM Serhiy Storchaka wrote: > > Serhiy Storchaka added the comment: > > This is a common mistake. Even the default implementation of object.__ne__ > had a bug, fixed only 4 years ago in issue21408. There were several

[issue35712] Make NotImplemented unusable in boolean context

Serhiy Storchaka added the comment: This is a common mistake. Even the default implementation of object.__ne__ had a bug, fixed only 4 years ago in issue21408. There were several errors in stdlib. I am sure there is a lot of occurrences of this errors in a third party code. So I like this i

[issue35712] Make NotImplemented unusable in boolean context

Steven D'Aprano added the comment: > the canonical __ne__ delegation to __eq__ for any class should be implemented > as something like I disagree that your code snippet is the canonical way to write __ne__. I'd write it like this: def __ne__(self, other): return not (self == oth

[issue35712] Make NotImplemented unusable in boolean context

Karthikeyan Singaravelan added the comment: Seems related issue22978 -- nosy: +xtreak ___ Python tracker ___ ___ Python-bugs-list m

[issue35712] Make NotImplemented unusable in boolean context

New submission from Josh Rosenberg : I don't really expect this to go anywhere until Python 4 (*maybe* 3.9 after a deprecation period), but it seems like it would have been a good idea to make NotImplementedType's __bool__ explicitly raise a TypeError (rather than leaving it unset, so NotImpl