[Pyrex] Pyrex idioms and optimizations?

[Stefan Behnel]

Hi,

Robert Bradshaw wrote:
> On Jul 24, 2007, at 11:19 PM, Stefan Behnel wrote:
>> William Stein wrote:
>>> On 7/24/07, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
>>>> William Stein wrote:
>>>>> However, there is legal Pyrex code that won't compile in SageX (since
>>>>> we think it shouldn't be legal), and of course vice versa.
>>>> Is this because you think it shouldn't be legal in
>>>> Pyrex generally, or because it conflicts with some
>>>> Sage-specific feature?
>>>
>>> A year ago I didn't know whether SageX would do anything
>>> at all that would be SAGE-specific, but so far after a year
>>> there is nothing in SageX that is SAGE-specific.
>>>
>>> Something that is valid in Pyrex but we think should not
>>> be valid is the following:
>>>
>>> # This is a complete file:
>>> ################
>>>
>>> def foo(a,b):
>>>    print a + b + c
>>>
>>> ################
>>>
>>> In Pyrex it compiles fine.  In SageX it gives an error
>>> message that c is not defined.  This avoids countless
>>> runtime errors.
>>
>> But this is different from
>>
>>   c = 10
>>
>>   def foo(a,b):
>>       print a + b + c
>>
>> right? Or do you require the "global" statement in that case?
> 
> That code will compile fine, no global declaration. (Hence the "this is
> a complete file" remark above.)

Ok.


>> I think my
>> example is definitely a valid use of Pyrex. How do you do that anyway?
>> Do you
>> check the __builtins__ at compile time? That would be the wrong thing
>> to do.
> 
> Yes, that is what we do. The only issue is when one runs pyrex with a
> different version of python than one intends to use the extension
> classes. The __builtins__ package is fairly stable, and in the worst
> case you get a NameError at runtime that you would have gotten otherwise
> when you run it on a different python. (It is an option that can be
> turned off). For us this has saved way more headaches than it has caused.

Well, it did change each time between Python 2.3, 2.4 and 2.5. So generating a
C file that works on all three platforms will not always work. This means
people will need cython if they want to build a distribution version. I'd
rather not require them too. A C compiler and distutils should be enough.

Also, in Python the runtime environment can look very different from the build
environment. While this is not a very common case, it's not that rare either.


> Also, the only GCC-specific code we have introduced (that I can think
> of) is branch-prediction hints which can also be turned off with a
> setting in Options.py.

You should rather turn them off automatically (#ifdef) in the C file if GCC is
not used. That way, you could still provide a single C file that compiles on
different systems.

Stefan