On Monday, June 18, 2018 at 6:43:36 AM UTC-5, Steven D'Aprano wrote: > The programmer can ignore [type-hints], just as they can > ignore any other form of documentation.
Type-hints, as implemented, break all the rules of conventional documentation. In any programming language i have ever seen, formal documentation elements such as documentation strings and comments do not _interleave_ themselves with executable code, no, they are forced to isolate themselves on entire lines, or, the tail ends of lines. For instance, i have never seem a dynamic programming language that did anything like the following: def foo(): for k<k is a string>,v<v is a integer> in d<d is a dict>: print<that is a built-in>(k, v) Have you??? Maybe i'm crazy, but i would prefer to have my _documentation_ and executable-code separated from one another. def foo(): # Iterate over the keys of d # k: string # v: integer # d: dict (duh!) for k,v in d: print(k, v) # That was builtin! > Nobody is stopping you from writing: > > result = function(the_string=42.5) Steven, that's an example of "self-documenting names" not "documentation". I'm sorry, but you are terribly confused if you cannot understand the non-subtle difference between these two concepts. > [we do it] Just to annoy you. You're also terribly confused if you believe i'm the only person in this community who is opposed to the current implementation of type-hints. Remember, i'm not advocating that type-hints be removed completely (the train has left the station). I'm only requesting that one of the following be done to _alleviate_ the burden of their poorly executed implementation: (1) Re-implement type-hints as a comment. (2) Provide a tool that will remove type-hints from scripts error free. Is that _really_ too much to ask? -- https://mail.python.org/mailman/listinfo/python-list