"in" for dicts (was: Python 2.1 function attributes)

[Nathaniel Gray]

Tim Peters wrote:
> > (I sure hope we're not doing it just to save a few keystrokes every
> > now and then!)
> 
> No.  I don't even believe that was mentioned.  Most people seem to think
> that these uses of "in" for dicts are *obvious*, and that has been
> mentioned -- often.  Some have also mentioned that "x in dict" will be
> faster than "dict.has_key(x)", and ditto for iteration (in which latter case
> it may also save an unbounded amount of additional storage).  The latter has
> been a FAQ for years:
> 
>     http://www.python.org/cgi-bin/faqw.py?req=show&file=faq06.012.htp

Hmmm...  It's always disturbing to hear a construct described as
"obvious" in a feature debate.  It often means "obvious in the context
of the program I wrote yesterday," or "obvious if you follow my coding
style."  A minor shift in perspective can quickly render an "obvious"
feature misleading, as T. Wouters' anecdotal evidence suggests.

Interesting.  I can see how "for key in dict" is faster than "for key in
dict.keys()", but why is "if key in dict" faster than "if
dict.has_key(key)"?  

> > "It's not a big dog.  Perhaps if we clipped it's ears and taught it to
> > meow it could pass for a cat!"
> 
> Oh, now I'm getting confused!  Is a dict the dog or the cat?  Is a list the
> other one?  And what are the ears?  Is meowing iteration?  In that case
> we're taking the cat out of the dungeon and removing the cruel muzzle from
> its cute little kitty mouth, while giving the doghouse a fresh coat of
> paint.

Well why didn't you just say so in the first place?  In that case I
withdraw my complaint and I'll submit a foolproof "for x in dict" patch
to SourceForge forthwith!  ;^)

> > And yes, I dislike list.pop() too.  ;^)
> 
> Really?  Or did you intend to say you dislike dict.pop() (which would fit
> better with the animal analogies <wink>).

Nope.  I've got no beef with dict.pop() (isn't it popitem or some such?)
-- it's obvious <wink> to me why that's useful.  list.pop(), on the
other hand, troubles me because it encourages the programmer to use a
list in place of a stack.  Trouble is, the list can do things the stack
can't, and this opens up a mess of potential problems when the guy who
maintains the code isn't the guy who wrote it.  Java makes the same mess
by subclassing Stack from Vector!  (A Stack "is a" Vector?!)

I guess I just don't understand why Python needs to open up this can of
worms with "x = list.pop()" when it already has "x = list[-1]; del
list[-1];".  Is there some subtlety I'm missing?  Performance
considerations?  Thread safety?  Atomic Pop?  (Great name for a band
:^)  Educate me.

> > Lest I come off as too much of a grumpy Gus, I should add that I really
> > like most of the new stuff in Python 2.1a1, particularly xreadlines.
> 
> Figures -- that's the one Guido likes least.  He dislikes xrange too.  He
> was forced into xreadlines by timing considerations (we couldn't match its
> performance cleanly, not with finite effort).  The only reason to like
> xreadlines is speed (which is reason enough!) -- but in that case you should
> like both flavors of "x in dict" too, and for the same reason.

I like xreadlines because it makes the most simple idiom the same as the
most efficient idiom.  True, the name is unfortunate, mostly because it
begs an explanation when you introduce it to a newbie.  In a language
like Python, though, the easy way should be the best way for
ultra-common tasks, and vice-versa.  With the frequency that Python
programmers want to iterate over the lines of text files we ought to
expect that plain old readline should be doing buffering cartwheels and
breathing magical platform-dependent fire to get us those lines
post-haste!  :^)

Yeah, I know.  Submit a patch.  The bloody noosphere won't homestead
itself...

> > I'll  be first in line to upgrade when 2.1 stabilizes, even if "in dict"
> > survives.
> 
> Hey, CVS is open for business!  The only way a new release stablilizes is
> via people *using* it.  

No can do.  The only reason I'm able to play with Python at all right
now is because 1.52 comes preinstalled on RH.  I'm doing a one-term
rotation with a research group where I'm the only one who's even _heard_
of Python.  It's a bit of a "don't ask, don't tell" kind of situation.

Big bummer:  when the end of the term comes I'll have to port all my
code to C.  I can already feel my productivity slipping away...

Anybody know of a good C implementation of dictionaries?  (Other than
Python's, that is :^)

-n8

-- 
_.~'^`~._.~'^`~._.~'^`~._.~'^`~._.~'^`~._
             Nathaniel Gray
   California Institute of Technology
     Computation and Neural Systems
_.~'^`~._.~'^`~._.~'^`~._.~'^`~._.~'^`~._