Hacker News Reader

Comment by gr3yh47 | Hacker News Reader

This is a horrible idea.

of any language, python could be a poster-child for duck typing done right.

python is also elegant and very easy to read.

this is pythonic -

    def foo(a, b, c):
        pass

this is ugly/trash -

    def foo(a, b: int, c: str) -> str:
        pass

if this goes down and eventually leads to static typing i will have even less reason to consider using python 3.

View on HN

I think I could get over that, but the idea of putting this hinting in comments is troubling for me:

    x = {}    # type: Dict[str, str]

I mean, it's very human-readable so it makes sense as a comment. It's optional, so not every declaration will have it. Still, something about the interpreter reading my comments is off-putting.

Yeah, that gives me the heebie jeebies. Fair enough if you want to use magic comments for an entirely third-party system like MyPy, but using them for a built-in language feature feels wrong.

Besides, how necessary is it? Presumably those constrained types can be instantiated:

    x = Dict[str, str]()

The constrained type's __new__ would be annotated appropriately, and return an ordinary dict. It's a bit less "pure" in that this is no longer strictly an annotation, but I'd much prefer that bit of impurity than magic comments.

Agreed. It seems like a simple typo e.g.

    x = {}  # tyep: Dict[str, str]

is a recipe for spending 6 hours wondering why you've got integers in your string-only dict.

(Assuming the interpreter ignores anything not matching `# type:`

Truly terrifying: I had to read your comment four times before I could find the typo.

Yeah, something like

    x: dict<str, str> = {}

would be nicer, I think.

Some advantages of type hinting:

- Editors and IDEs can use them to provide better autocompletion for you. That way you can discover how to use APIs while you write code without having to look at the docs all the time.

- Static analysers can tell you when you're making trivial errors just after you type them.

- They provide a form self documentation. In practice, most medium to large Python projects already add type signature information in the form of docstrings, using thing like '@param'. This is better because it's more uniform.

This is not against duck typing, you can use Abstract Base Classes to define an interface for some behaviour and match objects that provide that behaviour even if they don't belong to any specified type hierarchy.

Finally, this is completely optional. You can keep coding without types for your small scripts or private functions, while using type information for the APIs of big libraries.

- The interpreter/VM can use them to optimize some code to very fast equivalents or some data structures to very compact equivalents.

sounds like Cython. Are any such optimizations planned for 3.5 (or beyond)?

Not that I'm aware of. This type hinting is currently planned for analysis, not for efficiency.

On the other hand, this could be used for some nice "duck type checking".

Rather than the classic interface pattern, where the passed object must be a subclass of a certain type, these annotations could be used inversely to that. Something like:

   duckclass foo:
       def x(): pass
       def y(a: int) -> str: pass
       n: int

   def bar(it: foo) -> boolean: 
       ...

Where other classes don't need to explicitly inherit from foo, but rather, a checker can raise a warning where you are passing something that doesn't have an integer attribute (or getter function) called n, and the x and y functions. This allows some nice analysis, while still allowing good duck typing.

There are ways to do this without special keyworks too... that was just a quick first example. (maybe something like:)

   class foo:
      def x(): pass
      def y(a: int) -> str: pass
      n: int

   def bar(it: duck_as(foo)) ->str: pass

and so on.

You can have this today by inserting an explicit decorator that validates annotated arguments. You can even skip the decorators by dynamically wrapping callables with the validator.

What's so ugly/trash about that?

It looks quite simple/elegant. Plus what they're added is meant to be used by static analysis tools and IDEs, not actually for validating things at runtime.

What's the point if you don't actually validate with the validation hints you've added?

It's mostly a performance related choice.

Having these checks available for development does allow you full confidence in the type safety if the entire call stack has type annotations. If you're using some code that doesn't have these annotations, you might catch problems during development, or might not. But that's just the old familiar situation, and it allows you to iterate quickly while choosing which parts are more critical.

Note that this is analogous to the design choice made by Typescript, while the designers of Atscript chose to extend Typescript with runtime assertions as well.

Nonstatic typing brings down productivity very noticeably whenever I use it on anything beyond a small script. It introduces a large category of errors to make that static typing prevents; static typing makes the program more cohesive, structured, rigorous, and predictable. The only compelling reason for taking it away is laziness that'll hurt you in the long run, or if the problem/script is very small or trivial.

Who modded that down? He has a good point. This is a bad idea. In particular, "Python's static type-checking would be optional - programs can still be run even if the static checker has complaints." is a really bad idea. It means the type annotations can't be used for optimizations. Or we'll have code that only runs with optimization turned off, or on some compilers.

What if: