[Pyrex] Pyrex idioms and optimizations?

Stefan Behnel stefan_ml at behnel.de
Tue Jul 24 18:29:35 CEST 2007


Sorry, I don't have a Google account, so I'll just continue the discussion on
the Pyrex list.

William Stein wrote:
> On 7/12/07, Stefan Behnel <> wrote:
>> Robert Bradshaw wrote:
>> > As part of the SAGE project, and due to the difficulty in getting
>> > some essential (to us) patches upstream, we have been keeping a
>> > separate branch of Pyrex named SageX. It's just Pyrex + (a bunch of
>> > patches)
>>
>> That reminds me: does that include the patches we use in lxml?
> 
> I don't think so, unless Robert included them.  I don't think I did.
> It would be great if you could check and see what the relation
> between SageX and lxml is.   You can easily download sagex here:
> 
>   http://www.sagemath.org/packages/standard/sagex-20070710.spkg

Hmm, one thing I don't like: if it's a ".tar.bz2", call it ".tar.bz2". That
keeps people from wondering, from searching the web and from having to adapt
their shell completion. I know, there's also .egg, but then, there's
easy_install, so you don't see it's a zip file.

BTW, where's the SageX source repository? I couldn't find any link.


> Just do "tar jxvf sagex-20070710.spkg" to get the result.  It's almost
> exactly like the Pyrex distribution, except it has our code too and it
> has a mercurial repository in it (an .hg directory), which has the entire
> change history.  Also, we (Robert) recently merged everything with
> the latest version of Pyrex.
> 
>> That's mainly the public C-API support
> 
> What is the public C-API support?

It basically generates a header file for a public API at the C level. Allows
you to interface between different C/Pyrex-modules without going through
Python. In Pyrex-modules using lxml.etree, you can do this:

  cimport etreepublic as cetree
  from lxml import etree

  # initialize C-API of lxml.etree
  cetree.import_etree(etree) # defined in the header file

and then:

  # call a C-function in lxml.etree
  ns, name = cetree.getNsTag("{ns}tag")

  # call a Python function in lxml.etree
  element  = etree.Element("mytag")

lxml.etree comes with a file "etreepublic.pxd" (as cimported above) that
defines that API. Public functions are declared "public" in the source, that's
all.


>> and some Python 2.5 fixes (Py_ssize_t). I'd love to
> 
> I remember making a number of Py_ssize_t fixes myself, which
> I sent to Greg for the official Pyrex (he accepted those patches).
> Are you Python 2.5 fixes not in the official version?  What are they?
> I use SageX only with Python 2.5, and as far as I can tell, it works
> very well with Python 2.5.

On 64-bit platforms?

I just grep-ed for "Py_ssize_t" in the official 0.9.5.1a sources and didn't
find anything. There were a lot of API changes that require the Py_ssize_t
type, so I can't imagine it works without having Py_ssize_t in the generator
somewhere.


>> have that in an at-least-semi-official Pyrex version so that we can stop
>> providing our own version. One fork should be enough.
> 
> Sure!  Actually, I think it is finally time to set up a completely
> official fork of Pyrex,
> with its own mailing list, web page, etc (we've given Greg E. enough
> time to
> response to us forking, and he hasn't, etc.).   It should have  a
> simple straightforward
> name that explains what the project does. SageX is the wrong name, since it
> should be something not a priori associated with SAGE.   For example, maybe
> it could just be called
> 
>     CompiledPython

What about "Pyreks" or "Pyfix"? Or maybe just "Pyrex2".

CompiledPython will do, though.


> What do you think?  Would you be willing in a helping out a little
> (e.g., by subscribing to the mailing list and providing some feedback)?

Too bad your mailing list is on Google. The "contract" you have to sign in
Mailman is a no-brainer. I'm not going to read through a contract with 20
sections + subsections + whatnot just to subscribe to a mailing list.

Stefan




More information about the Pyrex mailing list