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

[Stefan Behnel]

Hi,

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

isinstance(o,c)      -> PyObject_IsInstance(o,c)
issubclass(c,csuper) -> PyObject_IsSubclass(c,csuper)
hasattr(o,a)         -> PyObject_HasAttr(o,a)
getattr(o,a)         -> PyObject_GetAttr(o,a)
setattr(o,a)         -> PyObject_SetAttr(o,a)
callable(o)          -> PyCallable_Check(o)
hash(o)              -> PyObject_Hash(o)
type(o)              -> PyObject_Type(o)
repr(o)              -> PyObject_Repr(o)
str(o)               -> PyObject_Str(o)
unicode(o)           -> PyObject_Unicode(o)
len(o)               -> PyObject_Size(o)
iter(o)              -> PyObject_GetIter(o)
dir(o)               -> PyObject_Dir(o)

tuple(o)             -> PySequence_Tuple(o)
list(o)              -> PySequence_List(o)

int(o)               -> PyNumber_Int(o)
long(o)              -> PyNumber_Long(o)
float(o)             -> PyNumber_Float(o)
abs(o)               -> PyNumber_Absolute(o)
divmod(o1,o2)        -> PyNumber_Divmod(o1,o2)
pow(o1,o2,o3=None)   -> PyNumber_Pow(o1,o2,o3)

and maybe some others. I'm currently #defining some of them in an external
header file to avoid the lookup and Python call overhead for them, but it
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*.

I know, this may break some code and removes the possibility to override
builtins before loading a module. However, I expect both of those problems to
be of *very* rare occurrence. And there would be a substantial gain both in
speed and readability of the resulting code.

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.

Any comments on this?

Stefan