[Cython] Standard include path

Robert Bradshaw robertwb at math.washington.edu
Wed Jul 23 09:26:23 CEST 2008


On Jul 20, 2008, at 9:27 AM, Stefan Behnel wrote:

> Hi,
>
> Dag Sverre Seljebotn wrote:
>> My test case has a call to malloc (tips to get around this are  
>> welcome
>> but I'd still like to have a look at include paths). So I'm  
>> cimporting
>> stdlib, meaning I have to export INCLUDE=Includes prior to running  
>> tests
>> (which I'd like to avoid as apparently no other tests relies on  
>> this?)
>>
>> There are two ways of going about this:
>> - Have runtests.py always include the Includes dir
>> - Have Cython itself always include the Includes dir (i.e. always
>> ../../Includes relative to Cython/Compiler/Main.py).
>>
>> I prefer the latter one; thoughts?
>
> I'm fine with the second one as long as it goes last on the include  
> path, so
> that people can override it.

Yep, I think this is a good idea too (in fact, it's what I  
envisioned  happening with that directory).

>> Also there's another import issue: For more sophisticated transforms,
>> I've (or Robert, can't remember) come up with a __cython__ namespace
>> which basically contains "any symbol the compiler might like to use".
>> For instance:
>>
>> TreeFragment(u"__cython__.PyObject_GetBuffer 
>> (<__cython__.PyObject*>TMP,
>> &BUFINFO, 0)")
>>
>> Eventually all the __Pyx-utils might be declared in this one too  
>> (though
>> I'm certainly not going to do it for the sake of it). Then the  
>> idea is
>> that __cython__ is *always* cimported (and available to the user  
>> as well).
>>
>> Any strong feelings against simply making this a __cython__.pxd in  
>> the
>> aforementioned standard include path? Note the consequences: The
>> compiler will be hard-wired to work with a certain pxd file.
>
> That's not an issue, most compilers come with some kind of external  
> files,
> such as header files or a standard or runtime library.
>
> But what it would really mean is that this __cython__.pxd would become
> available to users. Not sure that is a good idea.

Being available to the user comes with being able to use tree  
fragments in this way (unless we explicitly disallow it somehow).  
Seems reasonable to me. Should we use submodules of __cython__ rather  
than sticking everything we come up with in that single module?

>> The alternative is to create a cython-scope similar to builtin-scope
>> programatically (or stick everything that is needed in symtab.py  
>> directly).
>
> Personally, I would prefer a builtin scope that gets defined in a  
> module
> somewhere. Will that only be a plain .pxd or will there be any  
> additional
> generated code involved? If the latter, I'd certainly want to keep  
> it as part
> of the Cython compiler code.
>
> Stefan
> _______________________________________________
> Cython-dev mailing list
> Cython-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/cython-dev



More information about the Cython-dev mailing list