On Mar 10, 2008, at 4:48 PM, Dag Sverre Seljebotn wrote:
>> Ideally, I'd like some syntax that could be run as valid Python (no
>> syntax or name errors) but declare a specific variable to be a type,
>> which is more powerful than using assignment + type inference (for
>> example, one could add several python ints to a and it would do the
>> right thing).
>
> Overloading += and + would help, but I know that's not the point :-)
>
> Perhaps then a variant on the SAGE approach with vars("x") or similar?
> Using a string for the variable name makes it more natural for Python
> users since they know x is not declared yet, and you can already do
> locals()["x"] which is almost as "wierd". So
>
> typed("x", cython.types.int, "s,w", cython.types.ptr
> (cython.types.char))
> w = "ok"
> x = "compiler error"
I agree with the wierdness here, and I'm not sure it even works
sage: def foo(): locals()['x'] = 3; print x, locals()['x']
....:
sage: foo()
> If consistency is important then even
>
> @cython(args=("x", cython.types.int), ret=cython.types.int, except=-1)
> def foo(x):
> typed("sq", cython.types.int)
> square = x*x
> return sq
>
> But it might be too verbose.
IMHO, yes, this is getting way to verbose, but it could be accepted
(though the P3K ways is preferred). Perhaps there could be a locals
dict that is passed in as well, i.e.
@cython(arg_types={"x": cython.types.int}, local_types={"square",
cython.types.int}, return_type=cython.types.int, except=-1)
def foo(x):
square = x*x
return square
> Similar example not typing, for comparison:
>
> def bar(x: cython.types.int):
> assert fullycompiled # True if no object references made in block
> and
> sub-blocks
> sq = x * x
> assert native(sq) # Always True because of fully-compiled, but...
> return sq
>
> Doesn't seem to be anything wrong with combining both and let the user
> pick (guess that is the meaning of "type inference" - but I see the
> issues
> clearer now, guess I'm lagging behind a bit).
>
> Still - if there are two modes of operations:
> 1) Don't type variables but use inference heavily
> 2) Explicitly typed variable names
>
> then perhaps it isn't critical that 2) has a valid Python syntax if
> 1) has
> it?
(1) can be done on pure Python code, but without any types to start
with it is fairly limited. I think specifying types in function
declarations can go a long way to make it powerful though. I think
there should be a valid way to do (2) as well, but it might not be as
nice.
> (Can always add some candy to current syntax, like allowing "for int i
> in range(..." and make the "cdef" keyword optional).
Even removing the cdef keyword doesn't make it valid Python (and its
presence makes parsing so much easier), so I don't see much of a gain
there.
- Robert
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
