Le 21/04/2015 15:50, Paul Sokolovsky a écrit : > Hello, > > On Tue, 21 Apr 2015 15:08:27 +0200 > Antoine Pitrou <solip...@pitrou.net> wrote: > > [] > >> Because the user might not run the type checker, obviously. To quote >> you: """When we say that type checking is optional, we mean it.""" >> >> You can't at the same time point out that type checking has no >> power or control over runtime behaviour, and then claim that type >> checking makes runtime behaviour (for example, ability to accept or >> reject certain types) saner. It is a trivial contradiction. > > I suspected there's either short-sightedness, or just a word play for > for a purpose of word play. > > Type annotation are NOT introduced for the purpose of static type > checking.
I was replying to Steven's message. Did you read it? > Runtime type checking (run as via "make test", not > as "production") is much more interesting to catch errors. Obviously you're giving the word "runtime" a different meaning than I do. The type checker isn't supposed to actually execute the user's functions (it's not that it's forbidden, simply that it's not how it will work in all likelihood): therefore, it doesn't have any handle on what *actually* happens at runtime, vs. what is declared in the typing declarations. But if by "runtime" you mean any action that happens *out-of-band* during development (such as running pip or a syntax-checking linter), then sure, fine :-) > Even more interesting usage is to allow ahead-of-time, and thus > unbloated, optimization. There're bunch of JITters and AOTters for > Python language, each of which uses own syntax (via decorators, etc.) > to annotate functions. As a developer of one of those tools, I've already said that I find it unlikely for the PEP to be useful for that purpose. The issue is that the vocabulary created in the PEP is not extensible enough. Note I'm not saying it's impossible. I'm just skeptical that in its current form it will help us. And apparently none of our "competitors" seems very enthusiastic either (feel free to prove me wrong: I might have missed something :-)). > Having language-specified type annotations > allows for portable syntax for such optimized code. Only if the annotations allow expressing the subtleties required by the specific optimizer. For example, "Float" is too vague for Numba: we would like to know if that is meant to be a single- or double-precision float. > Don't block the language if you're stuck > with an unimaginative implementation, there's much more to Python than > that. The Python language doesn't really have anything to do with that. It's just an additional library with a set of conventions. Which is also why a PEP wouldn't be required to make it alive, it's just there to make it an official standard. Regards Antoine. _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
