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

[Dag Sverre Seljebotn]

Robert Bradshaw wrote:
> On Oct 2, 2008, at 2:45 PM, Lisandro Dalcin wrote:
> 
>> On Thu, Oct 2, 2008 at 5:58 PM, Dag Sverre Seljebotn
>> <dagss at student.matnat.uio.no> wrote:
>>> My five cents: I'm -1 on making emulating later Python versions in
>>> earlier ones in most cases, and definitely this one. We are  
>>> developing
>>> Cython for the present and future, and Python 2.3 is starting to  
>>> belong
>>> to the past.
>> Me to, -1 on this...
> 
> Some stuff (for example buffers, the with statement, and the b"byte  
> string" syntax) I believe are worth backporting. Python 2.3 will  
> continue to be a target for us (at least) as long as it is a target  
> for NumPy.

BTW: This changed a few days ago, when 1.2.0 was released: "Please note 
that NumPy 1.2.0 requires Python 2.4 or greater."

(I'm still +1 on Py2.3 compatability, just noting it.)

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

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.

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

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) and it would fix the issue 
with accessing Py3-builtins for free, but I don't care very much.

> 
> Letting set be defined no matter what violates this principle. Thus  
> if they have a Python 2.3 toolchain, they can (too easily) produce  
> code that they cannot use. Furthermore, the error will be some  
> obscure (to most people at least) message in the C compile. Much  
> better to raise an error during the Cython run. That way if Cython  
> succeeds, the C compile will succeed and the module will work (modulo  
> any bugs of course).

You can guard against typing "zpi", but not (currently at least) against 
typing "os.path.exitst". I guess I tend to think of those as about the 
same thing -- i.e. accessing a builtin is just making use of the 
__builtin__ run-time module, it is just that we hacked some of them for 
speed purposes (as we in future may be able to do with os.path.exists 
too through the use of inline code in pxd files).

That was the opposing view. But I see that this is non-trivial, and as I 
said this is not an important matter to me, so I might as well end this 
mail with agreeing with you that what you present is the best course of 
action for now :-)

-- 
Dag Sverre