A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2000-February/002000.html below:

[Python-Dev] __contains__ hook

[Python-Dev] __contains__ hookMoshe Zadka Moshe Zadka <mzadka@geocities.com>
Thu, 3 Feb 2000 18:38:04 +0200 (IST)
<meta-comment>
I like to be personally CC'ed on mails here,
and I assume arbitrarily everyone else is like me. 
If you don't want to be CC'ed, please mention it
personally.
</meta-comment>

On Thu, 3 Feb 2000, Guido van Rossum wrote:

> >  > which uses the above slot after testing the tp_flag setting.
> >  > Python instances, lists, tuples should then support this new
> >  > slot. We could even sneak in support for dictionaries once we
> >  > decide whether semantics whould be 
> > 
> >   Bait!
> 
> Yuck.  The same argument for disallowing 'x in dict' applies to the C
> API.  There's already PyMapping_HasKey().

I totally agree with Guido -- for me, the whole point of this hack is
to avoid people asking for 'in' in dicts: this way we can code a class
'set' (as I've demonstrated), and have rational semantics to 'in' which
is just as efficient as 'dict.has_key'. 

I'm not quite sure where we want to put the C API version of __contains__
- I'd add a tp_as_set, but the only method seems to be 'in', so it seems
like a waste of valuable real-estate before we are driven into
non-backwards-compatability. I think I should at least ask permission from
the owner before I move over there, trampling everything in my way<wink>

What does everyone think about that?

--
Moshe Zadka <mzadka@geocities.com>. 
INTERNET: Learn what you know.
Share what you don't.




RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4