(I take the liberty to top-post when I'm on cellular...) I like Robert's proposal, but with a twist: It is NOT a declaration, but an automatically inferred variable and a cast. So if foo() returns a Python int (object), then you can not write
a = cython.types.int a = foo() but have to write a = cython.types.int(foo()) The former example is very confusing to Pythoners, while the second is very consistent: Some *classes*/types have compile-time optimizations when they are operated on (whether numpy.ndarray or cython.types.int), but variable semantic actually follow Python's. We compile actions on *types* to C, not actions on variables. Declaring types on arguments are then simply a short-hand for "always run argument through the given factory/type constructor", and can be implemented for Python types as well, so def foo(a : unicode): would make sure int and str params are converted to unicode. I believe this to be very in the spirit of rest of Python, and that it wouldn't be that much more verbose. The cost is lack of compiler warnings - but one share that with the rest of Python, and I believe we type for speed, not design? Perhaps easy type asserts can then be used in addition if one wants to check that the code is compiled efficiently... Dag Sverre Dag Sverre Seljebotn -----Original Message----- From: Robert Bradshaw <[EMAIL PROTECTED]> Date: Monday, Mar 10, 2008 9:30 pm Subject: Re: [Cython] Prototype for parametrized types To: Cc: Dag Sverre Seljebotn <[EMAIL PROTECTED]>, [email protected] Stefan Behnel <[EMAIL PROTECTED]> CC: Dag Sverre Seljebotn <[EMAIL PROTECTED]>, [EMAIL PROTECTED]: Stefan Behnel <[EMAIL PROTECTED]> On Mar 10, 2008, at 11:44 AM, Stefan Behnel wrote: > >> Hi, > >> Robert Bradshaw wrote: >> On Mar 10, 2008, at 12:10 AM, Stefan Behnel wrote: >>> Dag Sverre Seljebotn wrote: >>>> We all agree that decorating variables in real Python is a real >>>> problem, >>>> but this proposal doesn't change anything for better or worse >>>> considering that. What this proposal says is that, given a >>>> hyopthetical >>>> CEP102 that proposes the following syntax for declaring types of >>>> in-function variables: >>>> >>>> i = typed(int) >>>> >>>> then a consequence of my proposal is that it is legal to also say >>>> >>>> v = typed(cpp.vector(int)) >>> >>> I hope it won't be that syntax, as this is what an assignment from a >>> function >>> call looks like, this is not a declaration. Declarative syntax >>> should >>> not be >>> easily confused with syntax that results in real code doing >>> something. >> >> My suggestion would be something of the form >> >> i = cython.types.int >> v = cython.types.cpp.vector(int) >> >> This would also have the right feel to it if type inference is done >> (though in the this case, assignment to i of a non-int would not >> change >> the type of i). > >> I'm still not convinced that assignment is a good way of dealing > with type > declarations. > >> Wouldn't something like this work as well: > >> def dostuff(a : int, b : str): > type(c, char*) > c = b > >> or > >> def dostuff(a : int, b : str): > assert type(c, char*) > c = b > >> or maybe > >> def dostuff(a : int, b : str): > cython.assert_type(c, char*) > c = b > >> This /would/ be valid Python syntax as long as you use only plain > Python > types. And it's definitely more intuitive than an assignment. > >Perhaps. This would give you a runtime error in python though. > >> Alternatively, I could imagine typing values at the first > assignment. So, what > about this: > >> def dostuff(a : int, b : str): > c = cython.assigntype(char*, b) > >> Again, plain Python if you stick to Python types. But this time, it > really > *is* an assignment. > >Looking at stuff like this makes me realize how nice the cdef keyword >really is... > >- Robert > > _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
