Send Python-ideas mailing list submissions to
python-ideas@python.org
To subscribe or unsubscribe via the World Wide Web, visit
https://mail.python.org/mailman/listinfo/python-ideas
or, via email, send a message with subject or body 'help' to
python-ideas-request@python.org
You can reach the person managing the list at
python-ideas-owner@python.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Python-ideas digest..."
Today's Topics:
1. TypeHinting: From variable name to type (Thomas G?ttler)
2. Re: TypeHinting: From variable name to type (Anders Hovm?ller)
3. Re: TypeHinting: From variable name to type (Robert Vanden Eynde)
4. Re: TypeHinting: From variable name to type (Thomas G?ttler)
5. Re: TypeHinting: From variable name to type (Ivan Levkivskyi)
----------------------------------------------------------------------
Message: 1
Date: Fri, 19 Oct 2018 09:18:02 +0200
From: Thomas G?ttler <guettliml@thomas-guettler.de>
To: python-ideas@python.org
Subject: [Python-ideas] TypeHinting: From variable name to type
Message-ID: <2d9d1825-2619-e4a0-1b19-6a614666816a@thomas-guettler.de>
Content-Type: text/plain; charset=utf-8; format=flowed
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 everywhere the veriable gets used.
But why does the human brain not need this?
Because it is intelligent?
I would not call this intelligence. There is a simple
dictionary in the brain of the developer, which maps:
variable-name --> Type
And this mapping dict exists once per library.
If you are developing in the requests http lib, then
there is a different mapping. Then "response" means
type requests.Response.
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,
...
}
"""
This makes the type mapping available for all files in this directory (or sub-directories).
What do you think?
Disclaimer: For reasons I don't want to explain in detail, I am not allowed to
do implement things like this. This is just an idea. I would feel proud and thankfull
if someone likes it that much, that he implements it.
--
Thomas Guettler http://www.thomas-guettler.de/
I am looking for feedback: https://github.com/guettli/programming-guidelines
------------------------------
Message: 2
Date: Fri, 19 Oct 2018 09:29:38 +0200
From: Anders Hovm?ller <boxed@killingar.net>
To: Thomas G?ttler <guettliml@thomas-guettler.de>
Cc: python-ideas@python.org
Subject: Re: [Python-ideas] TypeHinting: From variable name to type
Message-ID: <3A295990-52A3-4347-865E-096E9126C6C7@killingar.net>
Content-Type: text/plain; charset=utf-8
> On 19 Oct 2018, at 09:18, Thomas G?ttler <guettliml@thomas-guettler.de> 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 the IDE this knowledge?
>
> One solution is the do typehinting everywhere the veriable gets used.
>
> But why does the human brain not need this?
>
> Because it is intelligent?
>
> I would not call this intelligence. There is a simple
> dictionary in the brain of the developer, which maps:
>
> variable-name --> Type
>
> And this mapping dict exists once per library.
>
> If you are developing in the requests http lib, then
> there is a different mapping. Then "response" means
> type requests.Response.
>
>
> 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,
> ...
> }
> """
>
> This makes the type mapping available for all files in this directory (or sub-directories).
>
> What do you think?
I tried to implement this in mypy quite recently actually, but gave up for various reasons.
I am very much +1 on this. This would be a huge boon to preexisting code bases.
/ Anders
------------------------------
Message: 3
Date: Fri, 19 Oct 2018 10:22:08 +0200
From: Robert Vanden Eynde <robertve92@gmail.com>
To: Thomas G?ttler <guettliml@thomas-guettler.de>
Cc: python-ideas <python-ideas@python.org>
Subject: Re: [Python-ideas] TypeHinting: From variable name to type
Message-ID:
<CA+msPNkhxXxCWkB4f_YbeR3oJQLNBWLGzvsOfouW+BQ7nonFyA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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 this module" for
example, and parameters about the naming convention (explicit list of
conversion or rules to create the mapping).
Le ven. 19 oct. 2018 ? 09:18, Thomas G?ttler <guettliml@thomas-guettler.de>
a ?crit :
> 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 everywhere the veriable gets used.
>
> But why does the human brain not need this?
>
> Because it is intelligent?
>
> I would not call this intelligence. There is a simple
> dictionary in the brain of the developer, which maps:
>
> variable-name --> Type
>
> And this mapping dict exists once per library.
>
> If you are developing in the requests http lib, then
> there is a different mapping. Then "response" means
> type requests.Response.
>
>
> 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,
> ...
> }
> """
>
> This makes the type mapping available for all files in this directory (or
> sub-directories).
>
> What do you think?
>
>
>
>
> Disclaimer: For reasons I don't want to explain in detail, I am not
> allowed to
> do implement things like this. This is just an idea. I would feel proud
> and thankfull
> if someone likes it that much, that he implements it.
>
>
>
>
> --
> Thomas Guettler http://www.thomas-guettler.de/
> I am looking for feedback:
> https://github.com/guettli/programming-guidelines
> _______________________________________________
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20181019/cdfa7215/attachment-0001.html>
------------------------------
Message: 4
Date: Fri, 19 Oct 2018 11:30:53 +0200
From: Thomas G?ttler <guettliml@thomas-guettler.de>
To: Robert Vanden Eynde <robertve92@gmail.com>
Cc: python-ideas <python-ideas@python.org>
Subject: Re: [Python-ideas] TypeHinting: From variable name to type
Message-ID: <0c2edac3-36de-723f-2571-a782fa118965@thomas-guettler.de>
Content-Type: text/plain; charset=utf-8; format=flowed
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')
>
> The dialect options would include "all top functions in this module" for example, and parameters about the naming
> convention (explicit list of conversion or rules to create the mapping).
I think creating source code from source code is most of the time not the best solution.
Except you call the result not "source code" but "binary executable code". [1]
I think it would be great if this could work for local variables (which are not in the arg/kwargs of the method), too:
Example:
def foo():
response = get_response_from_paradise()
If `get_response_from_paradise()` has not spec for the return type, then it would be great to guess
the return type from the general "wisdom".
Regards,
Thomas
[1]: https://github.com/guettli/programming-guidelines/blob/master/README.rst#source-code-generation-is-a-stupid-idea
--
Thomas Guettler http://www.thomas-guettler.de/
I am looking for feedback: https://github.com/guettli/programming-guidelines
------------------------------
Message: 5
Date: Fri, 19 Oct 2018 10:42:04 +0100
From: Ivan Levkivskyi <levkivskyi@gmail.com>
To: guettliml@thomas-guettler.de
Cc: python-ideas <python-ideas@python.org>
Subject: Re: [Python-ideas] TypeHinting: From variable name to type
Message-ID:
<CAOMjWk=sSJZXpnGkniidD1WMY=LNM7vJCNLQq-j4t7h8Oz0T6Q@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
On Fri, 19 Oct 2018 at 08:19, Thomas G?ttler <guettliml@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 be a language feature. _Maybe_ it can be some
kind of an agreed format between IDEs.
But in any case I would first discuss this on PyCharm and VScode
(IntelliSense?) trackers.
Also I don't think it is a good fit for mypy (and probably other type
checkers, but better ask pytype and pyre devs).
I would rather expect that IDEs auto-add annotations using some guided
heuristics, and then type checkers can verify them.
--
Ivan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20181019/5cdb785c/attachment.html>
------------------------------
Subject: Digest Footer
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
------------------------------
End of Python-ideas Digest, Vol 143, Issue 73
*********************************************