Python, type hints, and feeling like they create a different language
At this point I've only written a few, relatively small programs with type hints. At times when doing this, I've wound up feeling that I was writing programs in a language that wasn't quite exactly Python (but obviously was closely related to it). What was idiomatic in one language was non-idiomatic in the other, and I wanted to write code differently. This feeling of difference is one reason I've kept going back and forth over whether I should use type hints (well, in personal programs).
Looking back, I suspect that this is partly a product of a style where I tried to use typing.NewType a lot. As I found out, this may not really be what I want to do. Using type aliases (or just structural descriptions of the types) seems like it's going to be easier, since it's mostly just a matter of marking up things. I also suspect that this feeling that typed Python is a somewhat different language from plain Python is a product of my lack of experience with typed Python (which I can fix by doing more with types in my own code, perhaps revising existing programs to add type annotations).
However, I suspect some of this feeling of difference is that you
(I) want to structure 'typed' Python code differently than untyped
code. In untyped Python, duck typing is fine, including things
like returning None
or some meaningful type, and you can to a
certain extent pass things around without caring what type they
are. In this sort of situation, typed Python has pushed me toward
narrowing the types involved in my code (although typing.Optional can
help here). Sometimes this is a good thing; at other times, I wind
up using '0.0' to mean 'this float value is not set' when in untyped
Python I would use 'None' (because propagating the type difference
of the second way through the code is too annoying). Or to put it
another way, typed Python feels less casual, and there are good and
bad aspects to this.
Unfortunately, one significant source of Python code that I work on is effectively off limits for type hints, and that's the Python code I write for work. For that code, I need to stick to the subset of Python that my co-workers know and can readily understand, and that subset doesn't include Python's type hints. I could try to teach my co-workers about type hints, but my view is that if I'm wrestling with whether it's worth it, my co-workers will be even less receptive to the idea of trying to learn and remember them (especially when they look at my Python code only infrequently). If we were constantly working with medium to large Python programs where type hints were valuable for documenting things and avoiding irritating errors it would be one thing, but as it is our programs are small and we can go months between touching any Python code. I care about Python type hints and have active exposure to them, and even I have to refresh my memory on them from time to time.
(Perhaps some day type hints will be pervasive enough in third party Python code and code examples that my co-workers will absorb and remember them through osmosis, but that day isn't today.)
|
|