ANN: Pyrex 0.4.3

[François Pinard]

[holger krekel]
> Ram Bhamidipaty wrote:
> > Skip Montanaro <skip at pobox.com> writes:

> > Why not just check if the range() object is the one that would have
> > been returned by the builtin function?  [...]

> Checking for the "correct" builtin could only happen at runtime [...]
> But anyway, the whole 'for-loop-for-numbers' seems like a minor
> optimization and i wouldn't introduce new syntax for it.    

I've been using Pyrex for the last few weeks with a lot of enthusiasm.
Instead of writing `for VAR in range(SUCH-AND-SUCH)', until now, I always
used `while' constructs with explicit updating of the control variable, and
preceded by explicit initialisation of course.  Despite tinily cumbersome
to write, such loops never made me unhappy so far.

There are pros and cons to a new construct, as many noticed already.
If Pyrex offers me a `for from' construct, I guess I'll use it.  But I would
have preferred to write Pyrex the same as I write Python on this matter.

Maybe Pyrex should have some generic way to declare that one or more
built-in, enumerated by name maybe, have dependably kept their default
assignment and meaning.  That could be useful in a flurry of circumstances
for Pyrex to optimise such built-ins when used over `cdef'-ed arguments.
`len' is a first and evident candidate: it would alleviate the frequent
need to declare `strlen' anymore, for one thing.  There might be a lot
of other built-ins that Pyrex could also progressively choose to know.
If such a mechanism existed, then `range' would be only one case among
many possible others, and Pyrex could optimise the `for VAR in range()'
construct especially, without the need of any `from for' construct.

-- 
François Pinard   http://www.iro.umontreal.ca/~pinard