Like I mentioned, you don't lose dynamic typing with type hinting. It ‘unpythonic’ and an anti-pattern of dynamically typed languages Maybe some concrete examples would help us explore this further. I'm not sure I'm seeing the problems you are perceiving. Generics in Python's type-hinting also don't bind you in the same way as statically-typed languages. Type hints give you tools to verify that the previous maintainer was not lying tools like mypy, which are enabled largely by type hints for example, help with this. I think, inherently, consumers of an API, to some degree, almost always depend on the type(s) returned, if anything of substance is ever returned from the API. I'm not sure how I see this is true, if even possible. You building in an inherent fault in the separation of concerns of your APIs
#Python annotations software#
Many software engineers have been using type checkers in their toolkit for a long time and it's not because they don't know what they're doing.
#Python annotations code#
On the contrary, type hints super-power the maintainability of code and become more important the larger a code base grows. Your lying to the next guy who maintains your code, I disagree that it is not "pythonic" or that it is an anti-pattern of dynamically typed languages. It just feels like it is to developers who should really be using a statically typed language that better reflects their coding philosophy. At the cost of overall conciseness and readability of the code. Yes, you have in type hints one standard way to DOCUMENT values in an API. More so because it doesn’t actually deliver the mechanics, but just apes them. That is lost and discarded by type hints in a way that I can only describe as vulgar. There is an aesthetic at work that matters far more than the mechanics. Like a compromise so that developers who don’t really buy into the language can work in companies that do.įundamentally, the value of Python being dynamically typed and duck type oriented is to eliminate or at least minimize the ceremony and clutter of less expressive languages like Java. Yea, mypy is great, but it’s not worth moving the goal post on what is ‘pythonic’. I hope they remove this mess in Python 4. This would have allowed function and class headers to include this documentation in a way that references names, but does not pollute class and function signatures. If toolchain hints were so important, it should have been implemented as a macro language onto F-strings. Tool chain metadata does not belong in the language syntax. Including typing semantics is hugely corrosive to the design of Python, even as a hint to inform the tool chain. It means that all typing assumptions, if any, are part of the code base. Introduction to Programming with Python (from Microsoft Virtual Academy).
0 kommentar(er)
