On Oct 4, 2008, at 5:45 AM, Dag Sverre Seljebotn wrote: > Robert wrote: > >> I polished off some more of the pure python mode stuff tonight. I >> just pushed it to cython-devel. Now you can do stuff like: >> > > Excellent! I have some comments to the syntax of course :-)
Thanks. Input is good. > Do you see this as the way forward for all new Cython code, or just > when one has interpreter compatability requirements? I suppose Sage > will want to stay consistent with the current code, while for NumPy/ > numerics one could for instance rewrite the tutorial etc. to this > syntax. It probably is more cumbersome for daily usage though... Both, but primarily for interpreter compatibility. Stuff like SymPy is my main target for things like this, and it will facilitate even easier migration. It will also be useful for bootstrapping the Cython compiler. The current syntax certainly is less cumbersome when dealing with a lot of c-ish code, and I don't anticipate existing codebases to be changing (not Sage at least, we've got more interesting things to work on...). >>> import cython # you need a single file to be in your path to use >> it in pure Python mode, provided (and installed) with Cython >> >>> @cython.locals(x=int, y=cython.p_int) >> def foo(x): >> y = cython.cast(cython.p_int, x) >> print x + cython.sizeof(y) + cython.sizeof(cython.p_int) >> if cython.compiled: >> print "the compiler was run >> else: >> print "just being interpreted" >> >>> x = cython.declare(int) >> xx = cython.declare(cython.p_int) >> xx = cython.address(x) > > Can you also do something like > > from cython import cast > > ? It doesn't work for directives but I consider that a bug... No, it doesn't yet, but it will. I see an easy way to implement that. > As for syntax, I have a problem with the assignment style, i.e. I'd > rather see: > > cython.declare(x=cython.int) > > because it seems more magical, and so one isn't surprised by stuff > like this: > > x = cython.declare(cython.int) > x = "hello" # illegal? Huh? I could certainly see supporting that form as well. The advantage of the x = cython.declare(...) syntax is that it is a declaration in the interpreter as well, so you can do stuff like x = cython.declare(some_struct) init_struct(x) Another thing that might be good to support is x = cython.declare(cython.int, 3) > On the brainstorming side, I was wondering if perhaps both casting > and declaration could be done via constructor: > > x = cython.int(3) > > It has the same problem as your cython.declare though so I won't > support that at this stage (but with inference it could work). Hmm... I suppose currently when A is a (cython defined) cdef class, A (3) *always* returns an A, but this may not be the case in the future. Or would it only work for primitive types? I could certainly see this working more naturally once type inference is up and running (and the need for most declarations would hopefully go away). > Another alternative: > > with cython.locals(..): ... > > The thing is, "with" sets up a natural scope block, This is actually a disadvantage, as neither Cython nor Python have the idea of scope blocks (only locals and globals). > and so it could be possible to declare variables e.g. inside a for > loop with such a construct. A bit verbose though. > >> >>> MyStruct = cython.struct(x=int, y=int, data=cython.pp_double) >> >>> a = cython.declare(MyStruct) >> a.x = 5 >> >>> T = cython.typedef(MyStruct) >> b = cython.declare(cython.pointer(T)) >> b[0].x = 4 > > Nice that all of this is working! > > Brainstorming again: > > I feel that this alternative to typedefs may not be too much work, > just mentioning it: > > cdef class A: pass > B = A # both symbol ass. and typedef > > @cython.locals(x=B) # type.. > def f(): > x = B() # module var > > i.e. B = A be both a variable assignment *and* a typedef. This > would only be for top-level module assignments, so > > if True: > C = A > @cython.locals(x=C) #illegal! > def f(): > x = C() # legal > > furthermore, > > myint = cython.int > > would only trigger a typedef as int is not a variable at runtime. The assignment-on-typedef seems a bit too magical for me... especially once we support all types as first-level objects (which I hope we do). This would also make x = A ... x = B fail for "mysterious" reasons when one of A or B are defined to be types. Note that I tried to make it such that every place typing information is used, a type is required. > Take it for what it is (a brainstorming); if the assignment style > is changed to statement style for cython.declare and cython.typedef > I'm 100 percent happy, and quite happy for all of this even if it > stays like now. Brainstorming is good, thanks for the feedback. - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
