[Pyrex] Support for Python builtins in the Pyrex language?

[Stefan Behnel]

Hi,

Szabolcs Nagy wrote:
> On 4/19/06, Stefan Behnel <behnel_ml at gkec.informatik.tu-darmstadt.de> wrote:
>>
>> I'd like to see some support for common Python builtins in the Pyrex language.
>> There are a number of global functions that have a direct mapping to C-API
>> functions, mainly
>> int(o)               -> PyNumber_Int(o)
>> long(o)              -> PyNumber_Long(o)
>> float(o)             -> PyNumber_Float(o)
>
> i sense problems with these as in pyrex int means a c type
> probably py_int or int_obj is feasible

Ah, true. Still, the parser should be able to clearly separate the semantics
due to the use as a function. That makes it a matter of readability, then...


>> abs(o)               -> PyNumber_Absolute(o)
>
> what would happen if i write:
> cdef int i,j
> i = 5
> j = abs(i)
> will it convert between int and PyIntObject?

Sure, that would be just like any other C-callable function. The signature is

PyObject* PyNumber_Absolute(PyObject* o)

or, in Pyrex terms:

cdef extern object abs(object o)

That's what the Pyrex compiler would see. Handling the C-int->C-int case would
be an optimization rather than part of the required implementation. The docs
should make it clear what the signature of "abs" and the others is.

There is a similar issue hidden in hasattr, isinstance, etc. These return
C-ints, not Python bools, so their signature is

cdef extern int isinstance(object o, object c)

But AFAICT, the code generator can already handle that.


>> would be much cleaner IMHO if Pyrex did that internally. It could then even
>> choose to use the *String methods (like PyObject_HasAttrString) if the second
>> argument of has/get/setattr is known to be a char*.
>
> yes str(s) looks nicer than PyString_FromString(s)

Much nicer. Although that's not quite the case it was meant for. Pyrex already
converts between char* and Python strings quite nicely.

I'm actually using a function "char* _cstr(object s)" in my code that is
#defined as PyString_AS_STRING, i.e. it avoids the to-Python-string conversion
overhead for string objects. That would be nice, too. But that's not quite in
the scope of this enhancement proposal. That would rather be part of the
long-awaited extension to the Pyrex type system to include "str" and "list"
instead of a simple "object".


>> be of *very* rare occurrence. And there would be a substantial gain both in
>> speed and readability of the resulting code.
>
> does it really improve speed?
> it looks like syntactic sugar to me

Well, if you compare it to a straight explicit call to PyObject_Str(), then
there is no difference. If, however, you compare it to the lookup of the
global Python-function "str" and a subsequent Python-call to it, including the
tuple packing for the call arguments, then that's a huge difference.


>> If breaking code is to be avoided, you could imagine making this dependent on
>> something like "from __pyrex__ cimport str, hasattr, int" in the source files.
>
> that looks nice IMHO
> it would be great to have a separate module with pyrex helper functions

Yes, it looks pretty readable. It's questionable, however, if you want to
clutter your source files with a list of, say, twenty names of imported
builtin functions. And: are you sure you always remember to import the
function name when you happen to use it somewhere in the source files? Pyrex
will not give you an error if it generates inefficient Python call code to an
unknown function.

That's why I prefer having them real builtins.

Actually, Pyrex should already cleanly handle the case where function names
are overridden, so maybe this extension will not even break code. If current
code defines one of the above functions, it will simply shadow the predefined
builtin. You'd only have to take care when replacing the builtin name by the
actual Python-C-API function name.


>> Any comments on this?
>
> i'm not very deep into pyrex so ignore my comments if you are a pyrex wizard

:) I'm not, but I wouldn't ignore them anyway.

Thanks for your comments, it's always good to discuss these things and clear
up ambiguities.

Stefan