Related: https://github.com/python/mypy/issues/2103
- Elazar On Fri, Oct 19, 2018 at 2:15 PM Anders Hovmöller <bo...@killingar.net> wrote: > > > > On 19 Oct 2018, at 12:15, Steven D'Aprano <st...@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 > brains > >> 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@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
