[Pyrex] Pyrex idioms and optimizations?

[William Stein]

On 7/24/07, Stefan Behnel <stefan_ml at behnel.de> wrote:
> > 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.

Currently SageX is a package that is part of the SAGE distribution:
    http://www.sagemath.org/.

For an official fork of Pyrex, we will set up a complete new project page,
mailing list, documentation, etc.  The above, is really just the packaged
version of a very heavily patched version of Pyrex for the SAGE distribution.
A .spkg file is not just a .tar.bz2 -- it's a very specially formatted .tar.bz2
meant for use by a certain package manager.  The above instructions were
just so that you could quickly try out our heavily patched version of Pyrex,
which has list comprehensions, many different optimizations, etc.

> >> 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:

Ahh, that's very nice.   Implementing something like this has been on our
todo list for a long time.  Great work.  Where do we download this from
again?

>   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.

Excellent -- very useful.

> >> 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?

Yes.

> 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.

That's depressing.   I guess what really happened is that Greg told me he
would include it, but maybe he didn't.  In SageX Py_ssize_t is definitely
fully supported on 64-bit.

> >> 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".

We thought of some of these names.  I'm worried that Pyrex2 might just be
annoying to Greg, since it basically says our project is the next version of
Pyrex or something.  Pyreks is tempting, but I think it is only fair to Pyrex
to choose a genuinely different name than "Pyrex".  I'm not sure what
the motivation for "Pyfix" is.     My viewpoint might completely change if
Greg were to comment on all this.

> 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.

So your answer is: "no, I will not help out or join the mailing list if it is
hosted by Google, but I would if it were Mailman"?  Note that we
haven't even setup a mailing list yet,
and would certainly consider not using Google to host it.  I only suggest
Google because I've used their list system for a while now and it is
much cleaner and easy to use compared to any other list management
system I've used.

William