[Cython] cython doesn't compile cdef'd variables of type set?

[Robert Bradshaw]

On Oct 3, 2008, at 3:18 AM, Dag Sverre Seljebotn wrote:

> Dag Sverre Seljebotn wrote:
>> Robert Bradshaw wrote:
>>> Let X <= Y. If you run Cython with Python X, then it should compile
>>> against and run under Python Y. However, if you run Cython with
>>> Python Y, it may not compile against or run under Python X  
>>> (depending
>>> on if you have used features introduced after X). Without  
>>> backporting
>>> every new feature back to 2.3, this is the best we can hope to do.
>>
>> I don't follow the logic here.

Sorry I wasn't very clear, thanks for splitting things up more below.

>> Please bear with me, this is important: One consequence is that  
>> there is
>> currently no way to get access to Py3-only builtins from pyx files
>> without using getattr (like "memoryview", unless it was added to
>> Python2.6 last minute, I didn't fetch the release yet. But even if it
>> was, I don't think there's any rule that all new Python 3.x builtins
>> will be backported to 2.x?).
>>
>> In my mind there's three different Python versions involved:
>>
>> - A: The version of Python the user targets in the pyx file (when it
>> comes to library and builtins; keeping the language part out of  
>> this).
>> - B: The version of Python that imports the compiled module. The user
>> just has to make sure that this matches A in a reasonable fashion  
>> (the
>> rules are non-trivial and not a simple >= or <=, as Py3 removes
>> builtins, but Python lays these down for us).
>> - C: The version that runs Cython.
>>
>> This discussion was about A and B -- that Cython won't allow users to
>> code for Py2.4 and run under Py2.3.
>>
>> You seem to be talking about C, which is something different. Cython
>> just transforms code and could run on any Turing-machine, there's no
>> natural reason it has to be connected with A or B.

Theoretically, C is orthogonal. However, for a given user, it is  
likely that there is strong correlation between all of A, B, and C.

>> We do currently require C >= B (which means that any Py3-only  
>> builtins
>> are plain unavailable).

No, we require that C >= A. Often C = B, and obviously B >= A, so  
this is reasonable.

>> In my opinion, ideally C should be orthogonal to A and B because that
>> seems to be less complicated from a release and bugfinding  
>> perspective
>> (one less version to worry about in the mix)

On the other hand, violating C < A results in a nice cython-compile  
error, whereas violating B < A is either a (perhaps not easily hit)  
runtime error or a c-compile error. Which would you rather debug?  
It's also reassuring to say "if it compiles under C, it runs under C 
+" because A is often implicit rather than explicit.

>> and it would fix the issue
>> with accessing Py3-builtins for free, but I don't care very much.

Is this because Cython doesn't run under Py3? (I thought it did.) Or  
is there something I'm not seeing here?

> To be more concrete, the problems you mention could be fixed with a
> simple compiler flag (or directive) to Cython: --target- 
> platform=3.0 or
> similar, to control the builtins. But, "there's no lack of good  
> ideas".

I think inspecting __builtins__ at runtime is a more elegant (and  
safe) approach than manually keeping lists for every version. A  
possible exception is the builtins that disappeared in Py3, in which  
case I would lean towards "forwardporting" them by importing from the  
right place, as they are still there somewhere).

- Robert