> 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/
