[Pyrex] Pyrex idioms and optimizations?

[Stefan Behnel]

Hi,

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

The SVN repository is here:

Pyrex:
http://codespeak.net/svn/lxml/pyrex/

Current lxml:
http://codespeak.net/svn/lxml/trunk/

A checkout of lxml (or the source .tgz) will also get you Pyrex, BTW.

The relevant files showing how it's used in lxml:

The .pxd defining the public API of the etree module:
http://codespeak.net/svn/lxml/trunk/src/lxml/etreepublic.pxd

etree actually implements (or wraps) its public functions in a .pxi, just to
make them more maintainable:
http://codespeak.net/svn/lxml/trunk/src/lxml/public-api.pxi

And an exemplary module that uses the C-API:
http://codespeak.net/svn/lxml/trunk/src/lxml/pyclasslookup.pyx


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

Did you write the SageX patches yourself? (just to make sure we are not just
talking about my own patches that I sent to the Pyrex list more than a year ago).

http://comments.gmane.org/gmane.comp.python.pyrex/1767

I think I also read somewhere that SageX did something about function
signatures of C-implemented Python functions. Does it have a way to make them
visible for tools like epydoc? I've been looking for something like that for a
while now.


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

Sort of. I'm not sure I can handle a second OSS project currently besides my
employment and lxml (where I'm the primary maintainer).

But at least I can offer to help get my patches ready for inclusion and make
SageX build lxml.


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

I love the bloggy view of Gmane, but I hate how it always jumps back to plain
single message mode when you run a search...

Anyway, there are enough places that get you a decent web site, code
repository and mailing list out there. You might even consider coming to
codespeak.net, where PyPy and lxml are hosted.

http://codespeak.net/

Not the most feature rich place in the world, but nice people who support it.

Stefan