[Python-ideas] Optional static typing -- the crossroads

[Guido van Rossum]

On Fri, Aug 15, 2014 at 9:25 AM, Dennis Brakhane <brakhane at googlemail.com>
wrote:

> On 15.08.2014 16:38, Steven D'Aprano wrote:
> > How do you know the linter will complain?
> Because a file object is not a list of strings, which is what word_count
> incorrectly declares it needs. (it actually requires a iterable of
> things that can be split()ed and doesn't return a Dict[str, int] but a
> Dict[return_type_of_split(), int])
>
> > So why do you consider it a "must" to be able to override functions
> > that report type errors at compile time?
>
> The difference  in that latter case is that the code runs perfectly fine
> and correctly. It's just that the linter implies you've done something bad.
>
> Using isinstance checks is kinda frowned upon, using type annotations
> will be probably considered to be totally acceptable practise (if not,
> what's the point of this proposal). It's much harder to argue with the
> original author that it's a bug in the latter case. Furthermore, the
> author might not want to loose the type requirement, because he doesn't
> want to guarantee those semantics, for example. If I'm willing to take
> that risk (and have a test case in my code) why shouldn't I be allowed
> to silence those errors in a simple way that doesn't require casting at
> every method call?
>
> To me, one of the things that sets Python apart from other languages is
> the fact that code will and can be used in a way the original author
> might not have thought of.
>
> Giving the original author of methods the means to dictate what types
> are acceptable and not with no clean and simple way of overriding it
> just feels Java-esque to me. (Again, isinstance checks are considered a
> bad practise, but I doubt declaring too restrictive types will be)
>
> I do not want to be forced to litter my code with casts, making it ugly
> and feel bad about what seems to me a reasonable method call.
>
>
> > But for what it's worth, as this proposal has repeatedly said, the
> > linter is optional. If you don't believe the linter, *just run the
> > code* in Python like you have always done before.
> As already said, I might be forced to run it because of company policy.
> I might contribute to a library that uses mypy.
>
> I don't have a big problem with complying with strange code style
> requirements enforced by a linter ("in this project, all variables must
> begin with foobar and end with a number"), that's just naming.
>
> I do have a problem when a linter will de facto enforce rules like "all
> code must only call  methods in the way the original author thought of",
> as this might lead to more ugly code because of workarounds/casts.
>

This attitude will not help you when interviewing at such a company. Did it
occur to you that there might actually be a good reason for the lint rule,
and that you, as a new hire, might not yet be aware of that reason?

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140815/6b1833ac/attachment.html>