[Python-ideas] TypeHinting: From variable name to type
elazarg at gmail.com
Fri Oct 19 09:32:34 EDT 2018
On Fri, Oct 19, 2018 at 2:15 PM Anders Hovmöller <boxed at killingar.net>
> > On 19 Oct 2018, at 12:15, Steven D'Aprano <steve at pearwood.info> wrote:
> > On Fri, Oct 19, 2018 at 09:18:02AM +0200, Thomas Güttler wrote:
> >> Imaging you are developing in the django context.
> >> Everytime you use a variable named "request" or "response" your human
> >> knows that this is a subclass of django.http.HttpRequest and
> >> django.http.HttpResponse.
> > Not *my* human brain.
> > 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 win!
> >> How to give the IDE this knowledge?
> >> One solution is the do typehinting everywhere the veriable gets used.
> > You shouldn't need to. Your IDE or type-checker should be able to do
> > type-inference and infer the type. You only need to add a hint if it
> > cannot infer the type.
> > 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.
> >> 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. Can I ask
> what type of code and how big code bases you work on? To me it seems we
> have radically different perspectives, and we'll continue talking past each
> other if we don't explain those perspectives to each other.
> I'll go first: I work on a code base that:
> - is ~240k dry lines
> - is ~15 years old
> - it a web app with just one production install
> - has very good consistent naming, for example:
> - the "request" example above exists over 6000 times in the code base
> and all of them are HttpRequestBase-derived (or in a few cases a mock that
> pretends to be that).
> - the word "party" exists over 11 thousand times, all of them are an
> instance of the Party django model
> Being able to tell PyCharm to assume the type of these and flag obvious
> violations would be great.
> >> If you are developing in the requests http lib, then
> >> there is a different mapping. Then "response" means
> >> type requests.Response.
> > What if you are using *both* django and requests in the same module? You
> > could have both of these:
> > response = something_returning_requests_Response()
> > response = something_returning_django_HttpResponse()
> > in the one module.
> Then you'd use the normal typing annotations to override the default.
> / Anders
> Python-ideas mailing list
> Python-ideas at python.org
> Code of Conduct: http://python.org/psf/codeofconduct/
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-ideas