Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Type hints cheat sheet (Python 3)

mypy.readthedocs.io

Post reply on HN
Print view View original

11–19 of 19 posts

Re: Type hints cheat sheet (Python 3)

#11

Post by noobiemcfoob »

IgorPartola wrote: post #10

So maybe this is because of the type of projects I work on, or maybe my use of the language, but type errors are really rare in my code and show up almost instantly. The main source of them is data from external APIs where a None was returned where an object was expected. Second biggest source is when parsing XML and a None results from some node not having the expected children. I feel like type checking would give…

I can't answer what you're missing as I'm missing it too. Type annotations have seemed to me as useful documentation. If they're strictly enforced, it might make it easier for a new coder to interface with unfamiliar code...but if it was designed well in the first place, duck typing should handle it and raise exceptions as appropriate.

Re: Type hints cheat sheet (Python 3)

#12

Post by noobiemcfoob »

Rotareti wrote: post #6

I've been using mypy for a while now and I love it! I added mypy type annotations to a bunch of old projects and it found some bugs no one was aware of right away. I love the support I get from mypy within the editor. It works flawlessly on my Linux machine with VSCode. It's quite good at inferring types as well. In most cases it's enough to annotate function parameters and return types. Mypy warns you in case it can…

Can you elaborate on the hidden bugs annotating old projects revealed?

Re: Type hints cheat sheet (Python 3)

#13

Post by kungtotte »

IgorPartola wrote: post #10

So maybe this is because of the type of projects I work on, or maybe my use of the language, but type errors are really rare in my code and show up almost instantly. The main source of them is data from external APIs where a None was returned where an object was expected. Second biggest source is when parsing XML and a None results from some node not having the expected children. I feel like type checking would give…

Type hints are more about proving correctness and catching errors early. If your code expects ints and all of a sudden it gets floats there is probably something wrong somewhere else, and the type checker tells you about it since Python would probably just chug along with floats instead of ints.

Re: Type hints cheat sheet (Python 3)

#15

Post by lou1306 »

singularity2001 wrote: post #14

what's the difference between list and List, dict and Dict and Mapping?

List, Dict can be enriched with the type of objects they contain: e.g. List[int] or Dict[str, str].

Mapping is a type hint for any object that implements the __getitem__ magic method (i.e. you can do `foo[bar]`).

Re: Type hints cheat sheet (Python 3)

#16

Post by ubernostrum »

singularity2001 wrote: post #14

what's the difference between list and List, dict and Dict and Mapping?

Suppose you want to indicate that a particular variable is a list of int. You might write "list[int]" to indicate that. But try that in a Python interpreter and you'll get an error -- "list[int]" attempts to subscript the list class object, which doesn't work.

So typing.List exists to be a subscriptable object you can use when annotating, and "typing.List[int]" works. Same for the other names.

Re: Type hints cheat sheet (Python 3)

#17

Post by singularity2001 »

ubernostrum wrote: post #16
singularity2001 wrote: post #14

what's the difference between list and List, dict and Dict and Mapping?

Suppose you want to indicate that a particular variable is a list of int. You might write "list[int]" to indicate that. But try that in a Python interpreter and you'll get an error -- "list[int]" attempts to subscript the list class object, which doesn't work. So typing.List exists to be a subscriptable object you can use when annotating, and "typing.List[int]" works. Same for the other names.

Thanks, I tried, and indeed:

list[int] TypeError: 'type' object has no attribute '__getitem__'

couldn't they just implement __getitem__ on the existing list class instead of creating semantic duplication?

Re: Type hints cheat sheet (Python 3)

#18

Post by ubernostrum »

singularity2001 wrote: post #17
ubernostrum wrote: post #16

Earlier quoted context omitted.

Suppose you want to indicate that a particular variable is a list of int. You might write "list[int]" to indicate that. But try that in a Python interpreter and you'll get an error -- "list[int]" attempts to subscript the list class object, which doesn't work. So typing.List exists to be a subscriptable object you can use when annotating, and "typing.List[int]" works. Same for the other names.

Thanks, I tried, and indeed: list[int] TypeError: 'type' object has no attribute '__getitem__' couldn't they just implement __getitem__ on the existing list class instead of creating semantic duplication?

The exact error you're going to get in a modern Python is:

    TypeError: 'type' object is not subscriptable
That's because "list" refers to the class object, which is not an instance of list; it's an instance of type. Implementing __getitem__ on list (which is already implemented!) will not help. Try it yourself:

    class MyClass:
        def __getitem__(self, key):
            return f"You asked for {key}"
Now try "MyClass[int]". You'll get the same error: "TypeError: 'type' object is not subscriptable". Class objects in Python are instances of type, so __getitem__ would have to be implemented on type in order to make this work. Which would in turn make it work on any type in Python, not just those which are supposed to represent collections/mappings.

The typing module's solution of sentinel objects to stand in for collection/mapping types, supporting subscripting for annotating the types of contents, is probably a better solution.

Re: Type hints cheat sheet (Python 3)

#19

Post by singularity2001 »

ubernostrum wrote: post #18
singularity2001 wrote: post #17

Earlier quoted context omitted.

Thanks, I tried, and indeed: list[int] TypeError: 'type' object has no attribute '__getitem__' couldn't they just implement __getitem__ on the existing list class instead of creating semantic duplication?

The exact error you're going to get in a modern Python is: TypeError: 'type' object is not subscriptable That's because "list" refers to the class object, which is not an instance of list; it's an instance of type. Implementing __getitem__ on list (which is already implemented!) will not help. Try it yourself: class MyClass: def __getitem__(self, key): return f"You asked for {key}" Now try "MyClass[int]". You'll get…

Understood. They could just allow __getitem__ on types to avoid semantic duplications.
Post reply on HN