On Wed, Mar 31, 2010 at 1:36 AM, Robert Bradshaw <[email protected]> wrote: > > There's also Py3 scope binding rules for list comprehensions, > exception blocks, etc. >
Thanks. I added these to my list. >> 2. Pure Python mode with py3 features >> I agree that we need to support tuple as annotation for a convention >> to be compatible with others. Besides function annotation, I'm also >> thinking to make use of decorators. As decorators now supported for >> classes, we could have @cdef @cpdef as decorator. This is a possible >> solution for get rid of .pxd files (ticket #112). A demo: >> >> import cython >> @cython.cdef >> class Foo: >> �[email protected] >> def bar(self, x: cython.int) -> cython.p_char: >> ... >> >> Also, one could always use "from cython import *" to make the code >> more concise. > > That's an interesting idea, but how would one resolve > > from cython import * > from X import * > > ? > > Also cython.int != __builtin__.int is important. Perhaps this would > just be disallowed... > Yes this should be discouraged, as in normal Python coding standard. But it is allowed by Python, so we should allow it too. A user who did "from cython import *" should always aware of the potential name conflict. At least, if the code running in Python, then cython.int == __builtin__.int, right? (That's what I read from Shadow.py) I think it is good to keep cython.int==__builtin__.int, and cython.double==cython.float==__builtin__.float, maybe also cython.p_char==__builtin__.bytearray, etc. Then we can always drop in a type checker when the code is running in Python, instead of report type error after running the compiled code. Thanks! -- Haoyu BAI School of Computing, National University of Singapore. _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
