ANN: Pyrex 0.4.3

[Ram Bhamidipaty]

holger krekel <pyth at devel.trillke.net> writes:

> Ram Bhamidipaty wrote:
> > Skip Montanaro <skip at pobox.com> writes:
> > 
> > >     Bjorn> But surely in the context of Pyrex you could make assignment to
> > >     Bjorn> builtins illegal? (after all Pyrex isn't Python, it just looks
> > >     Bjorn> like it <wink>)
> > > 
> > > You'll have to ask Greg.  Even though Pyrex != Python, there is still a
> > > price to be paid for what might seem like useful incompatibilities between
> > > the two.
> > > 
> > 
> > 
> > Why not just check if the range() object is the one that would have
> > been returned by the builtin function? If the object is the normal
> > one then you know you can generate C code - and if its not the normal
> > one then you can stick to the curreny python behaviour... you get the
> > speed you want without introducing a new syntax.
> 
> Checking for the "correct" builtin could only happen at runtime but
> the C-stuff needs to be rendered at compile ("module creation") time.
> 


The check needs to be done at run-time only if it needs to be correct
all the time - given that this is a speed optimization it should be
possible to detect _some_ programs that do not overwrite this
particular builtin.

For example, in a given application, if no part of the application
gets the dictionary for builtins then it would be impossible for the
application to overwrite the behaviour of range. (Atleat I think this
is true.)

Even if the above is not exactly correct the general idea is sound. 
You need to do whole program analysis to automatically deduce the
program properties that would hold in order for your optimization to
be safe. There are a lot of papers on Java optimizations that do
exactly this sort of whole program checking.

-Ram