[Python-ideas] TypeHinting: From variable name to type
steve at pearwood.info
Mon Oct 22 19:02:05 EDT 2018
On Fri, Oct 19, 2018 at 01:14:39PM +0200, Anders Hovmöller wrote:
[I wrote this]
> > I've seen far too many variables called (let's say) "mylist" which
> > actually hold a dict or a tuple (or in one memorable case, a string!) to
> > unconditionally believe the name.
> This is an even stronger argument for the proposal I think. If IDEs
> and static analysis tools looked at stuff like this and assumed a type
> _and then found that this assumption is violated_, it would be a huge
That's an argument for *static type checking*, not necessarily an
argument for *this* specific proposal. Any method of checking types, be
it static typing, mandatory type declarations, type inference, stub
files, annotations, or anything else, would help in that situation.
This specific proposal assumes that when you have a single name, it
always (or at least, nearly always) means the same type, across an
entire package. Therefore it is safe to map the name *alone* to the
type, rather than annotate the variable (name in a specific context)
with the type.
Of course I get it that you only choose *selected* names to label with
this name2type mapping. I just don't think this happens often enough to
make it a language feature, or would be valuable enough when it does
happen, to make up for the disadvantages.
You're using a *project-wide global* declaration, distant from the
variable's context, possibly even in a completely different file from
where the variable is used. That's just about the worst possible way to
annotate a variable with a type.
But if some, or all, IDEs want to support this, I have no objections.
Just don't use it in any code I have to read :-)
> > If your IDE doesn't do type inference, get a better IDE *wink*
> Which IDE would this be? PyCharm doesn't do this in the general case.
> Not even close in the code base I work on.
I don't know whether PyCharm does type-inference, but it *claims* to,
and it does have a plugin which runs MyPy, and MyPy certainly does.
If PyCharm lacks this feature, have you checked out the competition
(e.g. Wing IDE, PyDev, Spyder)? Have you submitted a feature request? It
could integrate better with MyPy, or possibly even the new type-checking
tool from Facebook:
Jedi is another project which claims to implement type-inference and
only require hints as a fallback:
> >> And this mapping dict exists once per library.
> > Or more likely, doesn't exist at all.
> You seem to argue here, and generally, that the normal case for code
> bases is that you have no consistent naming. This seems strange to me.
The point of modules, and functions, is *encapsulation*. If I name a
variable "spam" in function 1, why *must* a similar variable use the
same name in function 2 let alone function 202, distant in another
module? That implies a level of coupling that makes me uncomfortable.
And probably an excess of generic names like "response" and too few
*specific* names like "client_response" and "server_response".
I am impressed by you and your team's attention to detail at requiring
consistent names across such a large code base. I don't know if it is a
good thing or a bad thing or just a thing, but I can admire the
discipline it requires. I am certainly not that meticulous.
But I'm also faintly horrified at how much pointless pretend-
productivity this book-keeping may (or not!) have involved. You know the
sort of time-wasting busy-work coders can get up to when they want to
look busy without actually thinking too hard:
- prettifying code layout and data structures;
- pointless PEP-8-ifying code, whether it needs it or not;
- obsessing about consistent names everywhere;
etc. I know this because I've wasted many hours doing all of these.
(I shouldn't *need* to say this, but I will anyway: I am making no
comment on *you and your team* specifically, as I don't know you. I'm
making a general observation about the tendency of many programmers,
myself included, to waste time in unproductive "refactoring" which
doesn't actually help code quality.)
I don't see "inconsistent" names in different functions or modules to be
a problem that needs to be avoided. Hence, I don't avoid it. I don't go
out of my way to use unique names, but nor do I try to impose a
In any case, we're still up against the fact that in 2018, the state of
the art in type checkers is that they ought to be able to do what a
human reader does and infer the type of your variables. It shouldn't
matter whether you call it "response" or "spam" or "zpaqxerag", if your
type-checker can't work out that
foo = HttpResponse(*args)
is a HttpResponse object, something has gone wrong somewhere. Adding yet
another way to annotate variables instead of improving type-inference
seems like a sub-optimal choice to me.
More information about the Python-ideas