Hacker News Reader

Hacker News

Comment by joshuamorton | Hacker News Reader

Parent Full thread

joshuamorton

What's wrong with the pep 484 syntax in your view?

View on HN

PEP484 and the current state of typings in Python:

- Imports everywhere. Even basic types (list, dict, set) have to be imported

- Basic types don't share the same casing as the actual types they represent (Set vs set, Dict vs dict, List vs list)

- Awful support for enums.

- Syntax is generally ugly. Typescript got everything right; it's intuitive, clear, and scales pretty well even for complex types. I'd be happy if they just copied typescript syntax.

- Types have a runtime impact.

> - Types have a runtime impact.

Do you mind expanding on this, and what could be done differently?

type annotations are actual objects instantiated at runtime, usually only done at module import for non-local annotations but done each function invocation for locals. this is nice for extensibility as it makes interacting with and extending the type system as easy as writing any other normal python but in older versions of python it was extraordinarily slow, particularly with generics (as they were previously implemented by creating new actual typeobjects each time they had arguments applied (to be usable as baseclasses) - this has been corrected in 3.7 with the addition of __mro_entries__). 3.8 is however making annotations evaluated on demand not eagerly pretty much removing all runtime performance impact.

In what sense does

    x: float = 1.0

instantiate?

List[Tuple[Tuple[str, int], Dict[str, str]]] creates a bunch of objects; if you're having a closure these are necessarily created each time the closure is invoked, by evaluating the entire "List[Tuple[Tuple[str, int], Dict[str, str]]]" expression.

Why can’t you close over that type instantied outside the closure?

Complicated closures are often more idiomatically as classes where the aggregate type would be a class member.

There are two cases to consider. One is where the closure is called multiple times. This is the "by necessity" case, because the enclosed definition is executable and Python must make believe that this definition is re-executed every time the function is called.

If you are just calling the enclosed function then of course this does not happen. Compare:

    def mytype():
        print("!")
        return dict()

    def closure():
        def enclosed(x: mytype()):
            pass
        return enclosed

    print("Calling the closure")
    for i in range(10):
        closure()
        
    print("Calling the enclosed")
    f = closure()
    for i in range(10):
        f(0)

Note that using closures is almost always faster in Python than classes, because accesses to enclosed variables are done through offsets instead of attribute lookup (this gap has been somewhat closed, but is still significant in some cases; arguably almost all of these cases indicate that you are using either the wrong language, or the wrong implementation). So adding overhead to closures can be a somewhat valid reason to avoid using these annotations.

Thank you, I've been eyeing typing in Python and appreciate your explanation.

Agree. One way to fix it would be to allow you to define the typing in a completely separate file. Right now you can define some of it in a separate file but not all of it. I keep the horrendous typing syntax out of my code by not using it.

Typing in a separate file defeats almost all the benefits of typing. Being able to read the code without also having to open a second source, the documentation. It's almost as bad as going back to stoneage c++ with header/source split up in separate files.

Reading and writing types should be fast, agile, easy and effortless. Only way to acheive that is having it as close the usage as possible

+1, also Union must be imported and can't be simply spelled |.

Althought now annotations don't have a runtime cost anymore since the y are lazily evaluated.

it's not all bad but doing generic types is annoying because you have to do

  from typing import TypeVar
  T = TypeVar('T')

in every module where you want to parametrize a type. (not sure how that works with 3.6+'s unevaluated annotations. that's what my linter thinks)

also callable types are really ugly... this:

  Callable[[Foo, Bar], Baz]

vs something like `(Foo, Bar) -> Baz` is just yuck

putting constraints on a type is pretty ugly too iirc, i think it looks something like

  F = TypeVar(bound=Foo)
  def bar(a: F, b: F) -> F: ...

hacking type annotations into the language's existing syntax is hard :(

I actually find this a feature.

If you have a function that takes `(Foo, Bar) -> Baz`, What you really have is a function that takes in a FoobarBazifier.

So name your function-interface:

    FoobarBazifier = Callable[[Foo, Bar], Baz]

    def my_func(cb: FoobarBazifier) -> Baz:
        ...

This is pythonic, in the same way that preferring named functions over lambdas (and therefore not having a single character lambda syntax) is pythonic. Its controversial and people dislike it, but it is nice.

It also has the side effect of letting you Subclass the interface if you want to (via NewType), so that if you have multiple functions that match the same signature but fulfill different interfaces, you can name the interfaces differently and use them in different places.

Java mostly enforces this because you have to define an explicit interface and class for your callbacks (or you did until java 8), this is essentially the same thing, but with 1 line of boilerplate instead of 25 across 3 files.

Reply on news.ycombinator.com