Hi,
Dag Sverre Seljebotn wrote:
> The original proposal did not say anything about how to declare a
> variable. It does a) say something about how to declare/use a type,
> anywhere a type might be needed, b) use the current syntax for the
> examples, because using a non-current syntax for examples would be silly
Sure.
> 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.
> On the other hand, if the hypothetical CEP103 gets accepted instead
> which says "screw Python syntax" and makes it
>
> i: int
>
> also inside functions, then a consequence of my proposal is that it is
> legal to also say
>
> v: cpp.vector(int)
>
> inside functions.
I hope it won't be that syntax either, as a ':' already has a very important
meaning in Python: it starts a block.
for i: int in range(100): print i
I don't want that to become reality. I understand that it makes sense to use
it in signatures, as it doesn't have a special meaning there. But it does have
a very clear meaning in code.
> See how they are orthogonal, to use Robert's phrase?
> I'm sorry if the proposal was unclear about this.
I wasn't arguing about the proposal itself. I said that prefixes and a
function call like syntax look decorator-like, so they match the current way
declarations work in the Python language.
But I was suggesting that there is currently an asymmetry between how we can
declare types in interfaces (i.e. function signatures) and inside code
fragments. Pyrex has that already, as you don't need a cdef in signatures, but
it doesn't get any better with PEP 3107. So the only advantage that a
Python-like signature gives us is that it would be valid Python code if used
in signatures. The more important place where type declarations are used (i.e.
inside the code), is not impacted.
Stefan
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
