5 ms·

I'm excited; this looks better than Pyre. It being in Typescript is ironically enough a pretty big deal. I think they're clearly writing this for vscode, right

I'm excited; this looks better than Pyre. It being in Typescript is ironically enough a pretty big deal. I think they're clearly writing this for vscode, right? I hope they are at least. Having spent the last decade and half writing Python code, I have completely stopped enjoying writing Python code (even typed Python) because of how good TypeScript and the VSCode typescript experience is. It doesn't even sort of compare. At this point I just want pretty much the same thing that happened to JS to happen to Python: For MS to make a Python superset with good type hinting (not the atrocious pep484 syntax) which compiles down to Python. … and wasm. Which compiles down to Python and wasm.

joshuamorton 8y ago
What's wrong with the pep 484 syntax in your view?
- uryga 8y ago
  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 :(
  - joshuamorton 8y ago
    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.
- scrollaway 8y ago
  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.
  - throwawaymath 8y ago
    > - Types have a runtime impact. Do you mind expanding on this, and what could be done differently?
    - wrmsr 8y ago
      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.
      - marmaduke 8y ago
        In what sense does x: float = 1.0 instantiate?
        blattimwind 8y ago
        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.
wrmsr 8y ago
import typing as ta -> ta.List...
hobs 8y ago
Yeah, I think it is for VS Code and Azure Data Studio and I think the tooling team likes it - * https://github.com/Microsoft/vscode-postgresql https://github.com/Microsoft/vscode-postgresql * https://github.com/dbcli/mssql-cli https://github.com/dbcli/mssql-cli

joshuamorton 8y ago

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

uryga 8y ago
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 :(
- joshuamorton 8y ago
  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.
scrollaway 8y ago
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.
- throwawaymath 8y ago
  > - Types have a runtime impact. Do you mind expanding on this, and what could be done differently?
  - wrmsr 8y ago
    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.
    - marmaduke 8y ago
      In what sense does x: float = 1.0 instantiate?
      - blattimwind 8y ago
        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.

wrmsr 8y ago

import typing as ta -> ta.List...

hobs 8y ago

Yeah, I think it is for VS Code and Azure Data Studio and I think the tooling team likes it - * https://github.com/Microsoft/vscode-postgresql https://github.com/Microsoft/vscode-postgresql * https://github.com/dbcli/mssql-cli https://github.com/dbcli/mssql-cli