What does HackerNews think of typeshed?

Collection of library stubs for Python, with static types

Language: Python

#31 in Python
#4 in TypeScript
https://github.com/python/typeshed is Python's equivalent of DefinitelyTyped. I'm not 100% sure why it's not more of a popular thing the way DefinitelyTyped is; I think there might, to some extent, be different attitudes around the appropriateness of having third-party typings for packages, when the actual maintainer of the package isn't interested in providing first-party ones.
https://github.com/python/typeshed also provides community maintained stub packages for packages that are lacking upstream type hints
I wonder if that's a mypy issue or more that the typeshed types are bugged, since type shed versions also get shipped (used to?) with new type checker versions.

https://github.com/python/typeshed

> In contrast, Java uses all the types to perform type-checking, making them ascriptions.

Javac uses them to perform type checking, prior to runtime. Exactly the same way that mypy uses them to perform type checking prior to runtime.

> The reason I disagreed with this is because in statically typed languages you're not relying on annotations for anything. Keep in mind that we've established that annotations are specifically artifacts in the code that the language itself doesn't care about, because when the language does care they are called ascriptions. Annotations are supplied by the programmer by desire, not by necessity of the language proper.

But Scala's annotations are used for type checking. Much as python's are if you enable mypy.

> But you cannot release a Java library that doesn't have all its types specified in some manner. Because the Java language requires the types to be present, meaning they aren't annotations like they are in Python.

Of course you can. You can write a functional java library that specifies that all functions take `Object`. Your argument comes down to that syntactically, java requires you stick something in the place-where-type-declarations-go, while python does not.

This ultimately doesn't have any impact on the strictness of the type checking done, because you can stick useless annotations (Any, Object) in the syntactic spot in either case. The semantics are the same.

Ultimately, your argument comes down to "I trust that more third party libraries will have useful types in Java than in python", but that isn't implicit to the type system, it's because the type ecosystem has been around longer.

Which, like, sure. But to say that python doesn't have static typing is silly. Nearly all the python I write is statically typed.

> In Python the language, types are just annotations which are completely ignored, and this is not the case in statically typed languages.

This is a uselessly semantic argument. Much as if you choose to not typecheck your python, you can choose to write essentially untyped java using Object and casts. Are you really certain that no library you depend on does that, or uses reflection to access dynamic and non-statically-verifiable features?

The safety you get from any static analysis tool, whether a type system or a linter or whatever, relies on your dependencies not trying to subvert the tool (or doing so correctly).

This is essentially the argument about rust's Unsafe. You, or any of your dependencies, is free to subvert the borrow checker and do "unsafe" things.

You either have to trust that they are doing so responsibly, or manually verify the correctness of their unsafe code. Having to opt-in to unsafe access is, indeed, an advantage since it makes static analysis of how much "unsafety" there is easy (much as it's easier to find non-static things in vanilla Java than in python), but you can (and some do!) use static analysis to enforce type annotations in python throughout the entire code base.

> so it's an extra burden on the libraries' developers.

It's exactly the same burden as they would have in Java. So I'm not clear on what the point is. Worth noting though, that mypy supports stub files, so you can annotate a third party api yourself (https://github.com/python/typeshed, https://github.com/google/pytype/tree/master/pytype/pytd/std...), so even this claim is ultimately untrue.

You can do both. Python allows for external .pyi files, for situations where you can't modify the underlying library (for example: it's written in C). There are tons of them: https://github.com/python/typeshed, but you can still add types to new code inline.
You can gradually annotate these packages locally for your project with [1], and then contribute it to [2].

Automatic stub generation may also be helpful [3]

[1] https://github.com/python/mypy/wiki/Creating-Stubs-For-Pytho...

[2] https://github.com/python/typeshed

[3] https://mypy.readthedocs.io/en/stable/stubgen.html

Python's type annotation syntax is mostly similar to TypeScript.

Each method is independent unless the class is a Generic[T].

You can define a recursive type by quoting the nested reference.

You can define a JSON type with recursive types.

You can create stubs. Some are in typeshed.[1]

Mypy recently added protocols to simplify defining callable types.

Python has always been slow to add new syntax. I think that's a good thing overall.

[1] https://github.com/python/typeshed/

Typeshed[1] identifies the types of all builtins for all current (2.7+) versions of python.

[1] https://github.com/python/typeshed/

Yes! Pyre adopts types from the typing module, and relies on typeshed[1] to infer types for standard library functions.

[1]: https://github.com/python/typeshed

Unfortunately, MyPy doesn't work well with libraries or third party packages and treats external objects as `ANY` type. You can work around this with stubs but it's not fun writing type annotations for third party objects / functions. typeshed exists for the standard library and various popular third party libraries[1] to solve this very problem.

[1] https://github.com/python/typeshed

Strict use of type annotations has to be a team decision, yes. Checking for them can be integrated into a CI build, though.

The typing spec provides for supplementary "stub files" that can be provided for third-party dependencies without their own annotations. The typeshed project provides these for a fair and quickly increasing number of common dependencies, and is plugged into pycharm and mypy by default: https://github.com/python/typeshed

Re: "Dependent Types"

In Python, PyContracts supports runtime type-checking and value constraints/assertions (as @contract decorators, annotations, and docstrings).

https://andreacensi.github.io/contracts/

Unfortunately, there's yet no unifying syntax between PyContracts and the newer python type annotations which MyPy checks at compile-type.

https://github.com/python/typeshed

What does it mean for types to be "a first class member of" a programming language?