[Pyrex] Pyrex idioms and optimizations?

[Chris Mellon]

On 7/25/07, Robert Bradshaw <robertwb at math.washington.edu> wrote:
>
> On Jul 25, 2007, at 12:36 PM, Stefan Behnel wrote:
>
> >>> 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.
>
> If the python source is compatible with all of 2.3, 2.4, and 2.5,
> then the resulting C file will work on all three versions as well. Of
> course, this is an option that can be disabled if one never intends
> to run it on the building platform (and wants to use features not
> available in the build environment).
>
> I can't promise we didn't do anything else that was 2.5 only, but I
> can't think of any off the top of my head.
>
> >> 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.
>
> Yes... There are two macros that I define and I never got around to
> defining them trivially for non-gcc with an ifdef. There might be
> other issues too, as I've only been developing in the context of GCC
> this last year.
>

This was the GCC specific code that I was referring to. I "fixed" it
by just manually pasting in the trivial macros to my generated files,
I didn't notice the options.py. Autodetection is better, of course.

Work is busy right now and it's hard to make time to fix something
that isn't broken  (stock pyrex is meeting our needs at the moment)
but when I can I will try to track down the cause of the access
violation from the cython code generation.