On 11/29/2021 5:56 PM, Barry Warsaw wrote:
> On Nov 25, 2021, at 13:41, Christopher Barker <pythonchb@gmail.com> wrote:
>> What is their role? Up to today, I have treated them as an advanced feature, useful for "complex codebases". But there are any number of examples springing up on the internet, to the point where many students now think they are "best practice", if not actually required.
> This is an important observation. As much as I’m in the "type annotations are good” crowd now, I still think they should always be optional. Python’s use is so broad these days, I for one don’t want to have to add annotations to every bit of Python I write.
Maybe it should be reiterated with whatever decision comes forth that
>>> def muladd(x, y, z):
... return x * (y+z)
...
>>> muladd(3.1459, 87.33, 2.7e2)
1124.124447
>>> muladd(3, 5, 7)
36
>>> from fractions import Fraction as Fr
>>> muladd(Fr(22, 7), 87, Fr(2714, 100))
Fraction(62777, 175)
>>> muladd(3, 'hel', 'lo ')
'hello hello hello '
and other duck-typed code will always be legal, idiomatic, and even
expected as good practice for beginner, informal, exploratory, and
similar python code.
Why would it need to be reiterated? Are there really people who believe that such code would become invalid? AFAIK *everybody* here agrees that this should stay valid. So who would we be reiterating it for?
(Yes, several static type checkers have options that cause the checker to complain about unannotated code. But that's not the default behavior and running a static checker is a choice, like running a linter. Three-space indents or capitalized function names are never going to be disallowed either, even though PEP 8 says that's not how you ought to code.)