Python-list digest, Vol 1 #12210 - 15 msgs

[Terry Hancock]

> > From: Skip Montanaro [mailto:skip at pobox.com] 
> >     Matthias> What's the reason of introducing a new language
> construct
> >     Matthias> instead of transforming the old one into a pure C loop
> >     Matthias> wherever possible?

This was my reaction at first, too.

> > Because Python is highly dynamic:
> > 
> >     >>> def myrange(x,y=None,z=None):
> >     ...   return [4.0]
> >     ... 
> >     >>> import __builtin__
> >     >>> __builtin__.range = myrange
> >     >>> for i in range(12):
> >     ...   print i
> >     ... 
> >     4.0
> > 
> > When compiling, you can't assume anything about the input 
> > parameters or return value of range().  You need a new 
> > construct which says, "this is how to enumerate the integers 
> > between x and y."
> 
> But surely in the context of Pyrex you could make assignment to builtins
> illegal? (after all Pyrex isn't Python, it just looks like it <wink>)

This makes sense to me too. Is there actually anything
to be gained by overloading range() like this? It just
looks like an extremely wicked thing to do to anyone
trying to understand the code -- surely in any real
situation, you'd just use a new function in the loop
besides range(), right?  (Counterexamples?)

Of course, if it's really nasty to implement, I can
see the new syntax as a reasonable compromise, but
you wouldn't really want to see it get out of hand.
Also, who am I to tell Greg Ewing how his language
ought to work. ;-D

Cheers,
Terry

-- 
------------------------------------------------------
Terry Hancock
hancock at anansispaceworks.com       
Anansi Spaceworks                 
http://www.anansispaceworks.com 
P.O. Box 60583                     
Pasadena, CA 91116-6583
------------------------------------------------------