[Pyrex] Pyrex at Pycon

[Greg Ewing]

> I don't think the point is that you would recompile pure Python code as 
> Pyrex. Rather you would do Pyrex programs like the one:

Okay, perhaps I should have said "through bridging or writing
Pyrex code that uses C data structures and operations". My
point was that someone expecting Pyrex to speed up their
Python code without doing any work on their part would be
disappointed.

> If you feel that Pyrex is an experiment and others want to use it in 
> production code (e.g. Chandler) would you mind if they took your 
> experiments and made a production-ready branch that had stable 
> interfaces, test cases, optimizations and public repositories of bugs, 
> patches and code.

They're quite welcome to do that!

> Which declarations do you think would defy automatic translation?

Preprocessor macros, mainly, because they're used for many different
purposes that need to be handled very differently, but it's not always
obvious which is which. Sometimes they're used to define constants
that should be translated as enums; sometimes they should be
translated into a function prototype, but there's no way to
automatically determine the signature; sometimes they're used to
control conditional compilation, and should be evaluated the way the C
preprocessor would; sometimes they're used to pull tricks that can't
be translated into Pyrex at all.

Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,	   | A citizen of NewZealandCorp, a	  |
Christchurch, New Zealand	   | wholly-owned subsidiary of USA Inc.  |
greg at cosc.canterbury.ac.nz	   +--------------------------------------+