[Python-Dev] Type hints -- a mediocre programmer's reaction (original) (raw)
Chris Withers chris at withers.org
Tue Apr 21 08:50:34 CEST 2015
- Previous message (by thread): [Python-Dev] Type hints -- a mediocre programmer's reaction
- Next message (by thread): [Python-Dev] Type hints -- a mediocre programmer's reaction
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 20/04/2015 20:09, Paul Moore wrote:
On 20 April 2015 at 19:41, Barry Warsaw <barry at python.org> wrote:
tldr; type hints in python source are scary. Would reserving them for stub files be better? I think so. I think PEP 8 should require stub files for stdlib modules and strongly encourage them for 3rd party code. Agreed. I have many of the same concerns as Harry, but I wouldn't have expressed them quite as well. I'm not too worried about actually removing annotations from the core language, but I agree that we should create a strong culture of "type hints go in stub files" to keep source files readable and clean. On that note, I'm not sure "stub" files is a particularly good name. Maybe "type files" would be better? Something that emphasises that they are the correct place to put type hints, not a workaround. Or we could just be honest and admit that we're choosing to add header files to Python.
It's a shame, as it's more complexity, and it's being inflicted on those who might be writing a library for the first time, or those becoming core committers for the first time, or those just trying to "do the right thing".
Currently, the burden is a heavier one (type inference, rather than reading it from a file) but borne by people best placed to handle it (authors of IDEs, type checking software, etc).
Chris
- Previous message (by thread): [Python-Dev] Type hints -- a mediocre programmer's reaction
- Next message (by thread): [Python-Dev] Type hints -- a mediocre programmer's reaction
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]