Re: [Python-ideas] Non-boolean return from __contains__
Let me see if I understand this: False in [False] Returns True now but would return False with your change. --- Bruce (via android) On Jul 25, 2010 11:15 AM, "Alex Gaynor" <alex.gaynor@gmail.com> wrote: Recently I've been wondering why __contains__ casts all of it's returns to be boolean values. Specifically I'd like to propose that __contains__'s return values be passed directly back as the result of the `in` operation. As a result I'd further propose the introduction of __not_contains__, which is the `not in` operator. The primary usecase for this is something like an expression recorder. For example in SQLAlchemy one can do: User.id == 3, but not User.id in SQLList([1, 2, 3]), because it returns a bool always. __not_contains__ is needed to be the analog of this, as it cannot be merely be a negation of __contains__ when it's returning a non-bool result. There should be no backwards compatibility issues to making __contains__ return non-bools, unless there is code like: x = y in foo assert type(x) is bool However, for __not_contains__ I'd propose the default implementation be: def __not_contains__(self, val): x = val in self if type(x) is not bool: raise TypeError("%s returned a non-boolean value from __contains__ and didn't provide an implementation of __not_contains__") return not x This is not perfect (and it's at odds with the fact that __ne__ doesn't return not self == other), but it seems to allow both the desired flexibility and backwards compatibility. I'm not sure if this is something that'd be covered by the language moratorium, but if not I can try putting together a patch for this. Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Voltaire "The people's good is the highest law." -- Cicero "Code can always be simpler than you think, but never as simple as you want" -- Me _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
On Mon, Jul 26, 2010 at 7:20 AM, Bruce Leban <bruce@leapyear.org> wrote:
No, that would be unaffected, since builtin containers would retain their current semantics. Raymond's objections apply though - using syntax rather than a method makes the language noticeably more complicated for minimal gain. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Sun, Jul 25, 2010 at 5:20 PM, Bruce Leban <bruce@leapyear.org> wrote:
Bigtime. Official side-effects are neat for hacks but bad for maintainable code. You don't know pain until another developer complains that you refactored user.is_admin() to no longer return the user's object (for the record that happened in perl, but it could in python too). Boolean test operations should return bools for the same reason that in-place operations should return None. -Jack
On 25 July 2010 22:32, Jack Diederich <jackdied@gmail.com> wrote:
Most of them don't and this can be useful. Why should __contains__ enforce it when other boolean operations don't? Inconsistency is also bad.
for the same reason that in-place operations should return None.
What do you mean by "in-place operations should return None"? For mutable objects __iadd__ and friends should return self. For immutable ones they return the new value. Probably I misunderstand what you mean. Michael
On Sun, Jul 25, 2010 at 10:36:34PM +0100, Michael Foord wrote:
in-place operations should return None.
What do you mean by "in-place operations should return None"?
list.sort() sorts in place and returns None. Oleg. -- Oleg Broytman http://phd.pp.ru/ phd@phd.pp.ru Programmers don't die, they just GOSUB without RETURN.
On 25 July 2010 22:59, Oleg Broytman <phd@phd.pp.ru> wrote:
Ah thanks, although I don't think this is analogous at all. Michael
On Mon, Jul 26, 2010 at 7:20 AM, Bruce Leban <bruce@leapyear.org> wrote:
No, that would be unaffected, since builtin containers would retain their current semantics. Raymond's objections apply though - using syntax rather than a method makes the language noticeably more complicated for minimal gain. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Sun, Jul 25, 2010 at 5:20 PM, Bruce Leban <bruce@leapyear.org> wrote:
Bigtime. Official side-effects are neat for hacks but bad for maintainable code. You don't know pain until another developer complains that you refactored user.is_admin() to no longer return the user's object (for the record that happened in perl, but it could in python too). Boolean test operations should return bools for the same reason that in-place operations should return None. -Jack
On 25 July 2010 22:32, Jack Diederich <jackdied@gmail.com> wrote:
Most of them don't and this can be useful. Why should __contains__ enforce it when other boolean operations don't? Inconsistency is also bad.
for the same reason that in-place operations should return None.
What do you mean by "in-place operations should return None"? For mutable objects __iadd__ and friends should return self. For immutable ones they return the new value. Probably I misunderstand what you mean. Michael
On Sun, Jul 25, 2010 at 10:36:34PM +0100, Michael Foord wrote:
in-place operations should return None.
What do you mean by "in-place operations should return None"?
list.sort() sorts in place and returns None. Oleg. -- Oleg Broytman http://phd.pp.ru/ phd@phd.pp.ru Programmers don't die, they just GOSUB without RETURN.
On 25 July 2010 22:59, Oleg Broytman <phd@phd.pp.ru> wrote:
Ah thanks, although I don't think this is analogous at all. Michael
participants (5)
-
Bruce Leban -
Jack Diederich -
Michael Foord -
Nick Coghlan -
Oleg Broytman