Chris Barker schrieb am 08.05.2015 um 18:01:
> On Fri, May 8, 2015 at 3:42 AM, Stefan Behnel wrote:
>> Not currently. In fact, PEP 484 is mostly uninteresting from the point of
>> view of a static compiler.
>
> This is pretty disappointing
Oh, absolutely.
> -- it seems to me there are two reasons for
> declaring types -- type safety, and performance.
>
> Personally, while type safety seems to make the "Enterprise" happy, I think
> it's next to worthless. I have yet to see even anectodal evidence that
> adding type checking to a dynamic language catches the may and deep bugs
> people seem to think it will.
>
> Performance on the other hand, is a serious issue with dynamic languages --
> at least in some case, hence my use of Cython. Maybe the future for this
> lies in type inference and/or JIT compilation, but in the meantime, we
> really do need static compilation.
But that's not included in PEP 484. As I said, the types that you can
specify via PEP 484 type hints are (mostly) not interesting for
optimisation purposes.
>> And if it's not obvious from the code,
>> then the declaration is entirely irrelevant in the first place.
>
> I'm not sure I follow that -- type inference is hard -- if it's not obvious
> from the code, surely type declarations help. -- well,maybe they only help
> static type checkers ;-)
Sure, but not for optimisation. If the code doesn't use the fact that a
variable contains an Iterable, then declaring it doesn't help. And if the
code makes use of that property by iterating over the object, then the
declaration is redundant because it's clear from the code that the variable
needs to be iterable. That's what I meant.
> Cython already used its own notation for type defijnitions, it could
> conceiveably use the PEP 484 syntax, butu intepret it in a differnt way,
> for isntance, the simiplest example from teh PEP:
>
> def greeting(name: str) -> str:
> return 'Hello ' + name
>
> This states that the expected type of the name argument is str .
> Analogically, the expected return type is str.
But those are not the semantics that PEP 484 defines. (And this is a
particularly bad example as typing text input is almost always a bad idea
in Cython.)
Sure, Cython could reinterpret them, but then it would fail to correctly
compile some user code. And users might not notice because most test suites
will not try to send a string subtype into an interface.
> In theory, it would be nice if people could write python code, using PEP
> 484 for its benefits to type checking and IDE completion, etc, and then run
> it through Cython for performance enhancement.
Well, you can already do something similar:
https://github.com/cython/cython/blob/master/tests/run/annotation_typing.pyx
But that was pre-PEP-484 and is now obsoleted by it - in the sense that
it's incompatible, as PEP 484 does not intend to allow interoperability
with other kinds of annotations.
Stefan