Mario Figueiredo wrote: > In article <54c980cd$0$12981$c3e8da3$54964...@news.astraweb.com>, > steve+comp.lang.pyt...@pearwood.info says... >> >> Ian, that's obvious. Just open your eyes: >> >> Scala >> def addInt( a:Int, b:Int ) : Int >> >> Python >> def addInt( a:int, b:int ) -> int: >> >> >> They're COMPLETELY different. In Scala they are *type declarations*, not >> annotations. We're talking about annotations, not declarations. They're >> as different as cheese and a very slightly different cheese. Do try to >> keep up. >> >> *wink* > > The sarcasm is unnecessary. They are different yes. Are you on purpose > confusing the syntax of a feature with its meaning? Because while you > have a very similar syntax between Julia, Scala and Python. Their > meanings are very different.
No they aren't. Their primary meaning is to declare the type used by the parameter. > I think it is obvious to anyone that if a feature like type annotations > are meant to be EVALUATED AT RUNTIME (and I myself gave you another > example of Julia), it makes every sense for that feature to be a part of > the programming language syntax. I could never argue against Julia or > Scala type annotations on that basis. The syntax is an integral part of > the executable code. Ah, you mean just like Python, where annotations are evaluated at runtime, just like Julia: py> def spam(n:int)-> getattr(sys, 'version'): ... return "spam"*n ... py> spam.__annotations__ {'n': <class 'int'>, 'return': '3.3.0rc3 (default, Sep 27 2012, 18:44:58) \n[GCC 4.1.2 20080704 (Red Hat 4.1.2-52)]'} Python has had annotations for over five years. They are evaluated at runtime. They will continue to be evaluated at runtime. One of the benefits of this system is that people may write *runtime* type-checkers that use the same annotations that the lexical analysis tools will use. It is possible that you aren't following the meaning of this. The idea behind PEP 484 is that Python will standardise on a single expected syntax for type-hints, so that all of the following tools can agree on a set of basic rules for interpreting the annotations: - lexical type-checkers (those that operate on only the source code, with no runtime information) - alternate Python compilers, like MyPy, which perform compile-time type checking - IDEs and text editors, which may use lexical type info available in the source code to flag errors and offer auto-completion - stand-alone tools such as correctness provers - documentation generators - runtime type-checkers - runtime introspection tools and more. One of the rules is that the *standard* type-hints have to be simple enough that a purely lexical tool like an IDE or editor can understand it without needing to run arbitrary code. But the annotations themselves can be arbitrarily complex Python expressions. Its just that then the tools expecting type-hints won't be able to process those annotations from the source code alone. Runtime introspection tools will not care, because they don't see the expression, they only see the result of evaluating that expression. > But when a feature is not meant for runtime evaluation, why should it > clutter your executable code? Make me understand your reasoning? Perhaps you should ask the designers of Pascal, Go, Scheme, C, D, F# and all those dozens and hundreds of other languages. They have a feature which is not evaluated at runtime -- the type declarations -- and they put it in the source code. And why shouldn't they? Type declarations are source code! > Your list of programming languages is just plain wrong. To my knowledge > (there's a few languages there I don't know and never used), none of > those languages implement anything like Python. Not so. > Type annotations in > python are entirely ignored by the interpreter except to make them > available to external libraries. That is incorrect. Perhaps you are confusing by the fact that the Python interpreter doesn't give any meaning to annotations? It still evaluates them at runtime, and stores the result in the function object. -- Steven -- https://mail.python.org/mailman/listinfo/python-list