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.
How to give the IDE this knowledge?
One solution is the do typehinting everywhe
> On 19 Oct 2018, at 09:18, 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.
>
> How to give
That would be a feature in my "python dialect" future library. Taking one
valid python program and producing another python program :
def f(request):
return HttpResponse('ok')
→
def f(request: HttpRequest):
return HttpResponse('ok')
The dialect options would include "all top functions in
Am 19.10.18 um 10:22 schrieb Robert Vanden Eynde:
That would be a feature in my "python dialect" future library. Taking one valid python program and producing another
python program :
def f(request):
return HttpResponse('ok')
→
def f(request: HttpRequest):
return HttpResponse('ok')
Th
On Fri, 19 Oct 2018 at 08:19, Thomas Güttler
wrote:
> [...]
> This makes the type mapping available for all files in this directory (or
> sub-directories).
> What do you think?
>
I don't think this should be a language feature. _Maybe_ it can be some
kind of an agreed format between IDEs.
But in
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
> On 19 Oct 2018, at 12:15, Steven D'Aprano 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
Related:
https://github.com/python/mypy/issues/2103
- Elazar
On Fri, Oct 19, 2018 at 2:15 PM Anders Hovmöller
wrote:
>
>
> > On 19 Oct 2018, at 12:15, Steven D'Aprano wrote:
> >
> > On Fri, Oct 19, 2018 at 09:18:02AM +0200, Thomas Güttler wrote:
> >
> >> Imaging you are developing in the djang
Am 19.10.18 um 12:15 schrieb Steven D'Aprano:
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.HttpReques
On Fri, Oct 19, 2018 at 3:18 AM Thomas Güttler
wrote:
> Now my idea: Per module and/or per file type hinting from variable name.
> Maybe a magic docstring in the __init__.py file:
> variable-name-mapping:
> {
> request: django.http.HttpRequest,
> }
>
In general, I like this idea; but reall
On 2018-10-21 10:44, David Mertz wrote:
> On Fri, Oct 19, 2018 at 3:18 AM Thomas Güttler
> mailto:guettl...@thomas-guettler.de>>
> wrote:
>
> Now my idea: Per module and/or per file type hinting from variable
> name.
> Maybe a magic docstring in the __init__.py file:
> variable-na
On Sat, Oct 20, 2018 at 07:53:18PM +0200, Thomas Güttler Lists wrote:
>
> Am 19.10.18 um 12:15 schrieb Steven D'Aprano:
> >>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 infe
> But the critical point here is that we should not add a language feature
> to make up for the limitations of a single IDE. If the free version of
> PyCharm is underpowered, perhaps you ought to try the paid version, or
> another IDE, or submit a feature request to PyCharm, *before* turning t
On Mon, Oct 22, 2018 at 02:35:40PM +0200, Anders Hovmöller wrote:
>
> > But the critical point here is that we should not add a language feature
> > to make up for the limitations of a single IDE. If the free version of
> > PyCharm is underpowered, perhaps you ought to try the paid version, or
On 10/22/18 9:04 AM, Steven D'Aprano wrote:
My IDE is Unix. (Technically, Linux.)
+1
Or just google https://duckduckgo.com/?q=unix+as+an+ide
Thank you for not verbing DuckDuckGo! :-)
... (I use an actual GUI editor, not
Vim or Emacs) ...
[ ... must ... resist ... holy war ... ]
Dan
_
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
I'll just simply reply here that Mypy on our entire code base just silently
outputs nothing. Nothing at all. I tried to look at the code to find out why
and maybe implement the name checking feature discussed here and was terrified
by the Byzantine complexity of the code base. I gave up.
From
Am 19.10.18 um 11:42 schrieb Ivan Levkivskyi:
On Fri, 19 Oct 2018 at 08:19, Thomas Güttler mailto:guettl...@thomas-guettler.de>> wrote:
[...]
This makes the type mapping available for all files in this directory (or
sub-directories).
What do you think?
I don't think this should
Am 21.10.18 um 16:44 schrieb David Mertz:
On Fri, Oct 19, 2018 at 3:18 AM Thomas Güttler mailto:guettl...@thomas-guettler.de>> wrote:
Now my idea: Per module and/or per file type hinting from variable name.
Maybe a magic docstring in the __init__.py file:
variable-name-mapping:
>> This is certainly not something that requires language support. It can
>> easily be purely a convention, as long as different IDEs, linters, type
>> checkers, etc. agree on what the convention is. Maybe at some point in the
>> future, if the convention becomes adopted, there might be some
20 matches
Mail list logo
