Typeguardīefore I leave, since we’re still thinking about types, I wanted to share this little package I discovered the other day: typeguard. I definitely will be exploring those as they seem really useful.Įven though this chapter got into the weeds of collections a little, I learned a lot and I’m already finding places in the ZenML codebase where all of this is being used. There are currently (as of Python 3.10.2) 25 different ABCs available to use. In the set example, we have to implement _contains_, _iter_ and _len_, and then the other set operations will automatically work. So for sets, we’d use and then implement whatever group of methods are required for that particular class. You have to provide your own storage if you need it. The big difference between the User* pattern of classes, there is no built-in storage for the abc classes. For sets we’ll have to use abstract base classes which are found in collections.abc. You’ll maybe have noticed that there isn’t a collections.UserSet in the list above. Of course, there is a slight performance cost to importing these collections, so it’s worth making sure this cost isn’t too high. You’ll run into fewer problems when you actually implement this. If you’re just making slight changes to the behaviour of collections, instead of subclassing dictionaries or lists or whatever, it’s better to override the methods of collections.UserDict, collections.UserString and/or collections.UserList. That looks and feels so much cleaner! Tweaking existing functionality with collections T = TypeVar( 'T') APIResponse = Union def get_weather_data(location: str) -> APIResponse: # … def get_financial_data(transaction: str) -> APIResponse: # …
See this example, adapted from one in the book: You can use TypedDict to define structures that specify the types of fields of your dictionary in a way that is easier to parse as a human reader than just using dict. Note that, as with a lot of what we’re talking about here, this is all information that’s useful for a type checker and isn’t something that is dynamically checked. TypedDict was introduced in Python 3.8 and allows you to communicate intent when it comes to the types that are being passed through your code. The first of our collection type helpers: TypedDict You might as well not bother with type annotations if you’re going to liberally be using Any. In Python we do have the typing.Any annotation, but it’s pretty clear - and the book emphasises this - that isn’t really useful in the vast majority of cases.
Python annotations code#
There are often situations where, for example, you have to handle the output of API calls or data that doesn’t derive from code that’s in yous control and then you’ll perhaps be dealing with a dictionary that contains all sorts of types. If you think about it, in the real world heterogenous types are pretty common occurrences. So it’s actually not quite true to say that a collection of homogenous types have to all be exactly the same type, but they must share common interfaces and ideally be handled using the same logic. Try adding a string to an integer in Python and see what happens. Even in the most trivial of examples (as with strings and integers being together), the interfaces for both are different. This is of importance given that the presence of multiple types in a single list is going to require you to handle the types differently. If this list contains multiple different types (a mix of strings and integers, e.g.) then we’d have to say it contained heterogenous types. For a Python list, we could say it had homogenous types if all the items were of the same type (strings, e.g.). This involves the difference between homogenous and heterogeneous types. We start with the context for why this is even something that requires a separate chapter to deal with. This chapter deals with the different ways you annotate your types when collections get involved.
Python annotations how to#
We saw how to apply type annotations when simple things like strings, integers and floats were involved. The fifth chapter of ‘Robust Python’ continues on from where we left off last time.
0 kommentar(er)
