Re: [Python-Dev] Type hints -- a mediocre programmer's reaction
On Mon, Apr 20, 2015 at 4:00 PM, Harry Percival harry.perci...@gmail.com wrote: @Lukasz: Of course you're right, ugly is a matter of perspective, and I'm sure I could grow to love them, and they might evolve into a more polished direction they start to read more transparently after a while. But I'm still worried about beginners, and I'm even worried about me. I like to be able to scan through some code and see the essence of it. I learned Java at school, and I got it figured out, but i'm glad I left it behind. Every so often I read a TDD book and the examples are all in java and it just feels like obfuscation -- public void static private String[] class blabla... so many keywords and types getting in the way of *what the code is actually doing*. That's what's so appealing about Python, it strips it down to just the basics. And, to me, type hints are always going to be some unnecessary chaff that gets in the way of my understanding -- not useless, not that they don't have a purpose or that we should remove them completely. But if there was a way of just hiding them, so that I don't have to think about them, as a beginner, or as a normal programmer, most of the time, in the 90% of cases where I don't need to see them, I shouldn't have to... that's why i'm so keen on this stub files idea. One thing I don't understand is this local variable inference thing -- can that not be made to work in stub files? On 20 April 2015 at 21:50, Harry Percival harry.perci...@gmail.com wrote: stub files are only used to type-check *users* of a module. If you want a module itself to be type-checked you have to use inline type hints is this a fundamental limitation, or just the current state of tooling? On 20 April 2015 at 21:48, Harry Percival harry.perci...@gmail.com wrote: I hate stub files. [...] in my opinion, [it] just about guarantees a maintenance burden that will fall by the side of the road. I'm not so pessimistic. It's not like documentation or docstrings or comments -- the whole point is that it should be very easy to have an automated check for whether your stubs are in sync with your source, because both are in code. Unlike docs or comments which can easily become out of date, because there's no automated process to tell you they need updating... I'm thinking of it as a thing your editor will warn you of. Like pyflakes warnings about unused variables co, I'm never happy until I've silenced them all in a file, and similarly, your editor will keep bugging you until you've got your stubs inline with your code... On 20 April 2015 at 20:37, Isaac Morland ijmor...@uwaterloo.ca wrote: On Mon, 20 Apr 2015, Paul Moore wrote: On 20 April 2015 at 19:41, Barry Warsaw ba...@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. How about header files? (ducks...) Isaac Morland CSCF Web Guru DC 2619, x36650 WWW Software Specialist ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/hjwp2%40cantab.net So I've generally stayed out of this but I feel there is some context that people are missing in general. First, allow me to provide some context: I maintain a /lot/ of Python code[1] and nearly all of it is designed to be compatible with Pythons 2.6, 2.7, 3.2, 3.3, 3.4 (and eventually 3.5) and sometimes 2.5 (depending on the project). If I want to improve a developer's experience with some of that code using Type Hints I will essentially have no way to do that unless I write the code with the annotations and ship versions with annotations stripped and other versions with annotations? That's a lot more overhead. If I could provide the annotations in stubs that means that only the people who care about using them will have to use them. Is it more overhead to manage twice the number of files? Yes. Do I feel it would be worth it to not overly complicate how these packages are released? Yes. Further, there are far more reasons to make stubs the baseline (in my opinion) the biggest reason of all is that people want to provide stubs for popular yet unmaintained libraries as third party
Re: [Python-Dev] Type hints -- a mediocre programmer's reaction
exactly. yay stub files! we all agree! everyone loves them! boo type annotations inline in python source. only some people love them. and even then, only after a while, and only tentatively... and some people fear them, mightily... On 20 April 2015 at 23:14, Łukasz Langa luk...@langa.pl wrote: On Apr 20, 2015, at 3:02 PM, Ian Cordasco graffatcolmin...@gmail.com wrote: I think while the authors are currently seeing stubs as a necessary *evil* they're missing points where they're a better backwards compatible solution for people who want to give users with capable IDEs the ability to use stub (or hint) files. We might have not chosen the wording that makes this obvious to you but we definitely did consider all of the points you’re referring to: https://www.python.org/dev/peps/pep-0484/#stub-files -- Best regards, Łukasz Langa WWW: http://lukasz.langa.pl/ Twitter: @llanga IRC: ambv on #python-dev -- -- Harry J.W. Percival -- Twitter: @hjwp Mobile: +44 (0) 78877 02511 Skype: harry.percival ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Type hints -- a mediocre programmer's reaction
So I guess the main difference is that type annotations in stub files wouldn't be available at runtime? Ie, they wouldn't magically appear in __annotations__ (unless the python interpreter itself started to evaluate stub files too) On 20 April 2015 at 22:02, Guido van Rossum gu...@python.org wrote: On Mon, Apr 20, 2015 at 1:50 PM, Harry Percival harry.perci...@gmail.com wrote: stub files are only used to type-check *users* of a module. If you want a module itself to be type-checked you have to use inline type hints is this a fundamental limitation, or just the current state of tooling? It's not fundamental, it's just more in line with the original purpose of stubs (to describe C extensions). -- --Guido van Rossum (python.org/~guido) -- -- Harry J.W. Percival -- Twitter: @hjwp Mobile: +44 (0) 78877 02511 Skype: harry.percival ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Type hints -- a mediocre programmer's reaction
I hate stub files. [...] in my opinion, [it] just about guarantees a maintenance burden that will fall by the side of the road. I'm not so pessimistic. It's not like documentation or docstrings or comments -- the whole point is that it should be very easy to have an automated check for whether your stubs are in sync with your source, because both are in code. Unlike docs or comments which can easily become out of date, because there's no automated process to tell you they need updating... I'm thinking of it as a thing your editor will warn you of. Like pyflakes warnings about unused variables co, I'm never happy until I've silenced them all in a file, and similarly, your editor will keep bugging you until you've got your stubs inline with your code... On 20 April 2015 at 20:37, Isaac Morland ijmor...@uwaterloo.ca wrote: On Mon, 20 Apr 2015, Paul Moore wrote: On 20 April 2015 at 19:41, Barry Warsaw ba...@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. How about header files? (ducks...) Isaac Morland CSCF Web Guru DC 2619, x36650 WWW Software Specialist ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/hjwp2%40cantab.net -- -- Harry J.W. Percival -- Twitter: @hjwp Mobile: +44 (0) 78877 02511 Skype: harry.percival ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Type hints -- a mediocre programmer's reaction
I wrote a longer response and then realized it didn't really add much to the discussion. So let me be short: type annotations do *not* appeal to me, and I am not looking forward to the cognitive overhead of dealing with them. Perhaps I will eventually grow to like them if the tools that use them really add value. You'll have to sell me on it, though. On Mon, 20 Apr 2015 12:35:33 -0700, luk...@langa.pl wrote: Stub files have many downsides, too, unfortunately: - we donât *want* to have them, but we *need* to have them (C extensions, third-party modules, Python 2, â¦) - they bring cognitive overhead of having to switch between two files - they require the author to repeat himself quite a lot - they might go out of date much easier than annotations in the function signature The whole point of type hints is for the linters/IDEs, so IMO it is perfectly reasonable to put the burden of making them useful onto the linters/IDEs. The UI for it can unify the two files into a single view...I know because way back in the dark ages I wrote a small editor-based IDE that did something very analogous on an IBM Mainframe, and it worked really well as a development environment. --David ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Type hints -- a mediocre programmer's reaction
Twelve years ago a wise man said to me I suggest that you also propose a new name for the resulting language I talked with many of you at PyCon about the costs of PEP 484. There are plenty of people who have done a fine job promoting the benefits. * It is not optional. Please stop saying that. The people promoting it would prefer that everyone use it. If it is approved it will be optional in the way that PEP8 is optional. If I'm reading your annotated code it is certainly /not/ optional that I understand the annotations. * Uploading stubs for other people's code is a terrible idea. Who do I contact when I update the interface to my library? The random Joe who helped by uploading annotations three months ago and then quit the internet? I don't even want to think about people maliciously adding stubs to PyPI. * The cognitive load is very high. The average function signature will double in length. This is not a small cost and telling me it is optional to pretend that every other word on the line doesn't exist is a farce. * Every company's style guide is about to get much longer. That in itself is an indicator that this is a MAJOR language change and not just some optional add-on. * People will screw it up. The same people who can't be trusted to program without type annotations are also going to be *writing* those type annotations. * Teaching python is about to get much less attractive. It will not be optional for teachers to say just pretend all this stuff over here doesn't exist * No new syntax is a lie. Or rather a red herring. There are lots of new things it will be required to know and just because the compiler doesn't have to change doesn't mean the language isn't undergoing a major change. If this wasn't in a PEP and it wasn't going to ship in the stdlib very few people would use it. If you told everyone they had to install a different python implementation they wouldn't. This is much worse than that - it is Python4 hidden away inside a PEP. There are many fine languages that have sophisticated type systems. And many bondage discipline languages that make you type things three times to make really really sure you meant to type that. If you find those other languages appealing I invite you to go use them instead. -Jack https://mail.python.org/pipermail/python-dev/2003-February/033291.html ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Type hints -- a mediocre programmer's reaction
On Mon, Apr 20, 2015 at 1:17 PM, Robert Collins robe...@robertcollins.net wrote: On 21 April 2015 at 08:10, Eric Snow ericsnowcurren...@gmail.com wrote: While it helps, this sort of best-practice is still unsettled (and apparently not obvious). In the short term it would make more sense to recommend using stub files for all the reason Harry enumerated. Once the best practices are nailed down through experience with stub files, then we can make recommendations regarding inline type hints. -eric Forgive my ignorance, but can stub files can't annotate variables within functions? E.g. AIUI if there is a stub file, it is used in the static analysis instead of the actual source. Likely I've got it modelled wrong in my head :) -Rob Correct, stub files are only used to type-check *users* of a module. If you want a module itself to be type-checked you have to use inline type hints. (Though it has been suggested to combine the hints from the stub with the implementation and use this to type-check the implementation, and some tool chains may actually implement this.) -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Type hints -- a mediocre programmer's reaction
@Lukasz: Of course you're right, ugly is a matter of perspective, and I'm sure I could grow to love them, and they might evolve into a more polished direction they start to read more transparently after a while. But I'm still worried about beginners, and I'm even worried about me. I like to be able to scan through some code and see the essence of it. I learned Java at school, and I got it figured out, but i'm glad I left it behind. Every so often I read a TDD book and the examples are all in java and it just feels like obfuscation -- public void static private String[] class blabla... so many keywords and types getting in the way of *what the code is actually doing*. That's what's so appealing about Python, it strips it down to just the basics. And, to me, type hints are always going to be some unnecessary chaff that gets in the way of my understanding -- not useless, not that they don't have a purpose or that we should remove them completely. But if there was a way of just hiding them, so that I don't have to think about them, as a beginner, or as a normal programmer, most of the time, in the 90% of cases where I don't need to see them, I shouldn't have to... that's why i'm so keen on this stub files idea. One thing I don't understand is this local variable inference thing -- can that not be made to work in stub files? On 20 April 2015 at 21:50, Harry Percival harry.perci...@gmail.com wrote: stub files are only used to type-check *users* of a module. If you want a module itself to be type-checked you have to use inline type hints is this a fundamental limitation, or just the current state of tooling? On 20 April 2015 at 21:48, Harry Percival harry.perci...@gmail.com wrote: I hate stub files. [...] in my opinion, [it] just about guarantees a maintenance burden that will fall by the side of the road. I'm not so pessimistic. It's not like documentation or docstrings or comments -- the whole point is that it should be very easy to have an automated check for whether your stubs are in sync with your source, because both are in code. Unlike docs or comments which can easily become out of date, because there's no automated process to tell you they need updating... I'm thinking of it as a thing your editor will warn you of. Like pyflakes warnings about unused variables co, I'm never happy until I've silenced them all in a file, and similarly, your editor will keep bugging you until you've got your stubs inline with your code... On 20 April 2015 at 20:37, Isaac Morland ijmor...@uwaterloo.ca wrote: On Mon, 20 Apr 2015, Paul Moore wrote: On 20 April 2015 at 19:41, Barry Warsaw ba...@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. How about header files? (ducks...) Isaac Morland CSCF Web Guru DC 2619, x36650 WWW Software Specialist ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/hjwp2%40cantab.net -- -- Harry J.W. Percival -- Twitter: @hjwp Mobile: +44 (0) 78877 02511 Skype: harry.percival -- -- Harry J.W. Percival -- Twitter: @hjwp Mobile: +44 (0) 78877 02511 Skype: harry.percival -- -- Harry J.W. Percival -- Twitter: @hjwp Mobile: +44 (0) 78877 02511 Skype: harry.percival ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Type hints -- a mediocre programmer's reaction
Only if you want Java users burning all written copies of the PEP... On Mon, Apr 20, 2015 at 2:37 PM, Isaac Morland ijmor...@uwaterloo.ca wrote: On Mon, 20 Apr 2015, Paul Moore wrote: On 20 April 2015 at 19:41, Barry Warsaw ba...@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. How about header files? (ducks...) Isaac Morland CSCF Web Guru DC 2619, x36650 WWW Software Specialist ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com -- Ryan [ERROR]: Your autotools build scripts are 200 lines longer than your program. Something’s wrong. http://kirbyfan64.github.io/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Type hints -- a mediocre programmer's reaction
+1 to this from me too. I'm afraid that means I'm -1 on the PEP. I didn't write this in my earlier email because I wasn't sure about it, but my gut reaction after reading Harry's email was if type annotations are used in the stdlib, I'll probably stop contributing. That doesn't mean that's *true*, but that's the first time I've ever had that thought, so it is probably worth sharing. Basically, it makes Python less fun to program in. That may be be an emotional reaction and irrational, but I think it matters. And yes, I write production Python code for a living, though granted not at Google or Facebook or Dropbox scale. On Mon, 20 Apr 2015 19:00:53 -0500, Ryan Gonzalez rym...@gmail.com wrote: Although I like the concept of type annotations and the PEP, I have to agree with this. If I saw these type annotations when learning Python (I'm self-taught), there's a 99% chance I would've freaked. It's the same issue as with teaching C++: it's wrong to say, Hey, I taught you the basics, but there's other stuff that's going to confuse you to a ridiculous extent when you read it. People can't ignore it. It'll become a normal part of Python programs. At least now you can say, I'm using the mypy type checker. Don't get me wrong; I like mypy. I helped with their documentation and am watching the GitHub repo. But this is dead-on. On Mon, Apr 20, 2015 at 6:41 PM, Jack Diederich jackd...@gmail.com wrote: Twelve years ago a wise man said to me I suggest that you also propose a new name for the resulting language I talked with many of you at PyCon about the costs of PEP 484. There are plenty of people who have done a fine job promoting the benefits. * It is not optional. Please stop saying that. The people promoting it would prefer that everyone use it. If it is approved it will be optional in the way that PEP8 is optional. If I'm reading your annotated code it is certainly /not/ optional that I understand the annotations. * Uploading stubs for other people's code is a terrible idea. Who do I contact when I update the interface to my library? The random Joe who helped by uploading annotations three months ago and then quit the internet? I don't even want to think about people maliciously adding stubs to PyPI. * The cognitive load is very high. The average function signature will double in length. This is not a small cost and telling me it is optional to pretend that every other word on the line doesn't exist is a farce. * Every company's style guide is about to get much longer. That in itself is an indicator that this is a MAJOR language change and not just some optional add-on. * People will screw it up. The same people who can't be trusted to program without type annotations are also going to be *writing* those type annotations. * Teaching python is about to get much less attractive. It will not be optional for teachers to say just pretend all this stuff over here doesn't exist * No new syntax is a lie. Or rather a red herring. There are lots of new things it will be required to know and just because the compiler doesn't have to change doesn't mean the language isn't undergoing a major change. If this wasn't in a PEP and it wasn't going to ship in the stdlib very few people would use it. If you told everyone they had to install a different python implementation they wouldn't. This is much worse than that - it is Python4 hidden away inside a PEP. There are many fine languages that have sophisticated type systems. And many bondage discipline languages that make you type things three times to make really really sure you meant to type that. If you find those other languages appealing I invite you to go use them instead. -Jack https://mail.python.org/pipermail/python-dev/2003-February/033291.html ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com -- Ryan [ERROR]: Your autotools build scripts are 200 lines longer than your program. Somethingâs wrong. http://kirbyfan64.github.io/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/rdmurray%40bitdance.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Type hints -- a mediocre programmer's reaction
On 20 Apr 2015 14:44, Barry Warsaw ba...@python.org wrote: On Apr 20, 2015, at 07:30 PM, Harry Percival 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. +1 Having stub files take precedence over inline annotations would also neatly deal with the annotation compatibility problem (you can use a stub file to annotate code using annotations for another purpose). Another point in favour of that approach: stub files could be evaluated holistically rather than statement at a time, permitting implicit forward references. Cheers, Nick. Cheers, -Barry ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Type hints -- a mediocre programmer's reaction
Sounds great right? Everybody will be happy! So let's nail it down! If I was in charge, here's what I'd do: * standardise the syntax for type hints in 3.5, as per PEP484 * but: recommend the use of stub files as the preferred place to store hints * and: deprecate function annotations in the core language * remove them from the core language altogether in 3.6 Personally, I'm not all that keen on the verbosity of the syntax; I'm sad that List[int] has to be how you spell things instead of just [int], but I'm sure there's reasons that can't work. That said, I hate stub files. I understand why they may be needed sometimes so accept them as a necessary evil, but that doesn't make them a goal to me. Stub files become optional headers which I'll have to keep in sync with the actual code -- which in my opinion, just about guarantees a maintenance burden that will fall by the side of the road. If I have to look at another file know or change the function arguments in the code I'm working on, that hurts readability, too. Will it take some getting used to, this syntax? Yes. At one point I thought comprehensions and ternary expressions were unreadable. I use them all the time now and find them very elegant. I'm doubtful I'll ever find type hints /elegant/, but I'm pretty sure they won't be ugly forever. Ugly has a lot to do with familiarity. It's also deeply subjective. But its an objective reality, imho, that having to maintain and sync up function definitions in *two different files* is a burden. And that is a burden I really don't want to deal with. --Stephen ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Type hints -- a mediocre programmer's reaction
stub files are only used to type-check *users* of a module. If you want a module itself to be type-checked you have to use inline type hints is this a fundamental limitation, or just the current state of tooling? On 20 April 2015 at 21:48, Harry Percival harry.perci...@gmail.com wrote: I hate stub files. [...] in my opinion, [it] just about guarantees a maintenance burden that will fall by the side of the road. I'm not so pessimistic. It's not like documentation or docstrings or comments -- the whole point is that it should be very easy to have an automated check for whether your stubs are in sync with your source, because both are in code. Unlike docs or comments which can easily become out of date, because there's no automated process to tell you they need updating... I'm thinking of it as a thing your editor will warn you of. Like pyflakes warnings about unused variables co, I'm never happy until I've silenced them all in a file, and similarly, your editor will keep bugging you until you've got your stubs inline with your code... On 20 April 2015 at 20:37, Isaac Morland ijmor...@uwaterloo.ca wrote: On Mon, 20 Apr 2015, Paul Moore wrote: On 20 April 2015 at 19:41, Barry Warsaw ba...@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. How about header files? (ducks...) Isaac Morland CSCF Web Guru DC 2619, x36650 WWW Software Specialist ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/hjwp2%40cantab.net -- -- Harry J.W. Percival -- Twitter: @hjwp Mobile: +44 (0) 78877 02511 Skype: harry.percival -- -- Harry J.W. Percival -- Twitter: @hjwp Mobile: +44 (0) 78877 02511 Skype: harry.percival ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Type hints -- a mediocre programmer's reaction
On 21 April 2015 at 10:02, Ian Cordasco graffatcolmin...@gmail.com wrote: So I've generally stayed out of this but I feel there is some context that people are missing in general. First, allow me to provide some context: I maintain a /lot/ of Python code[1] and nearly all of it is designed to be compatible with Pythons 2.6, 2.7, 3.2, 3.3, 3.4 (and eventually 3.5) and sometimes 2.5 (depending on the project). If I want to improve a developer's experience with some of that code using Type Hints I will essentially have no way to do that unless I write the code with the annotations and ship versions with annotations stripped and other versions with annotations? That's a lot more overhead. If I could provide the annotations in stubs that means that only the people who care about using them will have to use them. 2.5? I'm so sorry :). Being in approximately the same boat, I definitely want to be able to improve the developer experience. That said, with one key exception (str/bytes/unicode) Python code generally has the same type on all versions. Sure it might be imported from somewhere else, and you're restricted to the common subset of APIs, but the types in use don't vary per-python. So - as long as your *developers* can run mypy on 3.2+, they can benefit from type checking. mypy itself requires 3.2+ to run, but programs with type annotations should be able to run on all those python versions you mention. Now, what is the minimum barrier for entry? Nothing :) - at the moment every file can be analysed, and mypy ships with a bunch of stubs that describe the stdlib. So - you'll get some benefit immediately, where bad use of stdlib routines is happening. Constraining the types of functions gets you better errors (because you are expressing intent rather than what-might-happen which the inference has to work from otherwise. In particular, constraining the type of *inputs* can let bad callers be detected, rather than the engine assuming they are valid-until-a-contradiction-occurs. You can do that with stub files: put them in repo A, and add them to the MYPYPATH when working on repo B which calls the code in repo A. You can also add those stubs to repo B, but I wouldn't do that because then they will skew vs repo A. A further step up would be to annotate A in its code, rather than using stubs. That way, developers of repo A will be warned about bad uses of other repo A code. But - if you have stubs *or* annotations in-line in repo A, *everyone* changing repo A needs to care. Because if the code mismatches the stub, the folk that do care will now be unable to use repo A correctly - their type checker will complain about valid uses, and fail to complain about more invalid uses. I'm particularly interested in mypy for OpenStack because for some repos 10% of reported bugs are type mismatch errors which mypy may well have avoided. Is it more overhead to manage twice the number of files? Yes. Do I feel it would be worth it to not overly complicate how these packages are released? Yes. Further, there are far more reasons to make stubs the baseline (in my opinion) the biggest reason of all is that people want to provide stubs for popular yet unmaintained libraries as third party packages. Should everyone using PIL be using Pillow? Of course. Does that mean they'll migrate or be allowed to migrate? No. Should they be able to benefit from this? Yes the should. The only way for PIL users to be able to do that is if stub files can be packaged separately for PIL and distributed by someone else. stubs can certainly be packaged and distributed separately. That doesn't make the case that we should use stubs for projects that are opting in. I think while the authors are currently seeing stubs as a necessary *evil* they're missing points where they're a better backwards compatible solution for people who want to give users with capable IDEs the ability to use stub (or hint) files. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Type hints -- a mediocre programmer's reaction
On Mon, Apr 20, 2015 at 2:01 PM, Robert Collins robe...@robertcollins.net wrote: On 21 April 2015 at 08:50, Harry Percival harry.perci...@gmail.com wrote: stub files are only used to type-check *users* of a module. If you want a module itself to be type-checked you have to use inline type hints is this a fundamental limitation, or just the current state of tooling? AIUI its the fundamental design. Stubs don't annotate python code, they *are* annotated code themselves. They aren't merged with the observed code at all. Could they be? Possibly. I don't know how much work that would be. It's fundamental in the implementation of mypy. It doesn't have to be in the implementation of other type checkers (and IIRC the Google folks are planning to merge the two streams). However if you are using typing.get_type_hints(func) this is not intended to give you access to hints defined in stubs (it would require a huge amount of machinery to implement that right). -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Type hints -- a mediocre programmer's reaction
Although I like the concept of type annotations and the PEP, I have to agree with this. If I saw these type annotations when learning Python (I'm self-taught), there's a 99% chance I would've freaked. It's the same issue as with teaching C++: it's wrong to say, Hey, I taught you the basics, but there's other stuff that's going to confuse you to a ridiculous extent when you read it. People can't ignore it. It'll become a normal part of Python programs. At least now you can say, I'm using the mypy type checker. Don't get me wrong; I like mypy. I helped with their documentation and am watching the GitHub repo. But this is dead-on. On Mon, Apr 20, 2015 at 6:41 PM, Jack Diederich jackd...@gmail.com wrote: Twelve years ago a wise man said to me I suggest that you also propose a new name for the resulting language I talked with many of you at PyCon about the costs of PEP 484. There are plenty of people who have done a fine job promoting the benefits. * It is not optional. Please stop saying that. The people promoting it would prefer that everyone use it. If it is approved it will be optional in the way that PEP8 is optional. If I'm reading your annotated code it is certainly /not/ optional that I understand the annotations. * Uploading stubs for other people's code is a terrible idea. Who do I contact when I update the interface to my library? The random Joe who helped by uploading annotations three months ago and then quit the internet? I don't even want to think about people maliciously adding stubs to PyPI. * The cognitive load is very high. The average function signature will double in length. This is not a small cost and telling me it is optional to pretend that every other word on the line doesn't exist is a farce. * Every company's style guide is about to get much longer. That in itself is an indicator that this is a MAJOR language change and not just some optional add-on. * People will screw it up. The same people who can't be trusted to program without type annotations are also going to be *writing* those type annotations. * Teaching python is about to get much less attractive. It will not be optional for teachers to say just pretend all this stuff over here doesn't exist * No new syntax is a lie. Or rather a red herring. There are lots of new things it will be required to know and just because the compiler doesn't have to change doesn't mean the language isn't undergoing a major change. If this wasn't in a PEP and it wasn't going to ship in the stdlib very few people would use it. If you told everyone they had to install a different python implementation they wouldn't. This is much worse than that - it is Python4 hidden away inside a PEP. There are many fine languages that have sophisticated type systems. And many bondage discipline languages that make you type things three times to make really really sure you meant to type that. If you find those other languages appealing I invite you to go use them instead. -Jack https://mail.python.org/pipermail/python-dev/2003-February/033291.html ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com -- Ryan [ERROR]: Your autotools build scripts are 200 lines longer than your program. Something’s wrong. http://kirbyfan64.github.io/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Type hints -- a mediocre programmer's reaction
On Mon, Apr 20, 2015 at 1:15 PM, Robert Collins robe...@robertcollins.net wrote: On 21 April 2015 at 08:07, Guido van Rossum gu...@python.org wrote: The situation is possibly even bleaker (or happier, depending on your position :-) for inline type hints in 3rd party packages -- few package authors will be satisfied with supporting only Python 3.5 and later. True, you can support Python 3.2 and up by declaring the 3rd party typing package as a dependency (unless Python 3.5+ is detected), but I don't expect this to become a popular approach overnight. mypy has a codec for 2.x which strips type annotations - https://github.com/JukkaL/mypy/tree/master/mypy/codec - while you can't run mypy under 2.x, you can run it under 3.x to perform the analysis, and ones code still runs under 2.x. I know, it was my idea. :-) But I think stubs are usually better of you want to support PY2. The experience when the codec is not installed is really poor. Another route - the one I've been experimenting with as I get familiar with mypy - is to just use type comments exclusively. Function type comments currently break, but that seems like a fairly shallow bug to me, rather than something that shouldn't work. The advantage of that route is that editors which make comments appear in subtle colours, makes the type hints be unobtrusive without specific syntax colouring support. There are definitely some tooling issues around annotations (e.g. I've had to file at least one bug with pep8), but in cases like this the language must lead, and tooling will follow. The idea of using comments exclusively is interesting, although I think there are also some real downsides. (As an example: Jython is thinking of making some use of type hints for code generation, and they strongly prefer to have the hints in the AST, whereas comments don't show up in the AST at all.) -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Type hints -- a mediocre programmer's reaction
On 21 April 2015 at 08:50, Harry Percival harry.perci...@gmail.com wrote: stub files are only used to type-check *users* of a module. If you want a module itself to be type-checked you have to use inline type hints is this a fundamental limitation, or just the current state of tooling? AIUI its the fundamental design. Stubs don't annotate python code, they *are* annotated code themselves. They aren't merged with the observed code at all. Could they be? Possibly. I don't know how much work that would be. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Type hints -- a mediocre programmer's reaction
Chris Angelico ros...@gmail.com writes: On Tue, Apr 21, 2015 at 9:41 AM, Jack Diederich jackd...@gmail.com wrote: * It is not optional. Please stop saying that. The people promoting it would prefer that everyone use it. If it is approved it will be optional in the way that PEP8 is optional. If I'm reading your annotated code it is certainly /not/ optional that I understand the annotations. […] Maybe I'm completely misreading everything here […] I think you've misunderstood the complaint. When you're writing a library, it can be a great help to provide type annotations, because every application that uses your library can benefit. When you're writing an application, you can completely ignore them, but still get the benefit of everyone else's. Jack is not complaining only about *writing* code. He's complaining about the effect this will have on code that we all are expected to *read*. Programmers spend a great deal of time reading code written by other people. The costs of this proposal are only partly on the writers of the code; they are significantly borne by the people *reading* that code. For them, it is not optional. I have no fears for my own code. Are you afraid for yours? Jack, if I understand correctly, fears for the code that will be written by others in conformance with this proposal, that he will then have to read and understand. -- \ “The opposite of a correct statement is a false statement. But | `\ the opposite of a profound truth may well be another profound | _o__) truth.” —Niels Bohr | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Type hints -- a mediocre programmer's reaction
On Mon, Apr 20, 2015 at 12:51 PM, Nikolaus Rath nikol...@rath.org wrote: On Apr 20 2015, Harry Percival hj...@cantab.net wrote: My first reaction to type hints was yuck, and I'm sure I'm not the only one to think that. viz (from some pycon slides): def zipmap(f: Callable[[int, int], int], xx: List[int], yy: List[int]) - List[Tuple[int, int, int]]: arg. and imagine it with default arguments. This is indeed ugly as hell and I certainly would not want to see this in any Python file I'm working with. However, I always assumed that whatever tools consume these annotations are expected to be good enough at automatic type inference that something like this would never be necessary? In practice, I would hope that the above simplifies to def zipmap(f, xx: List[int], yy: List[int]): because (just picking a probably buggy random implementation) zz = [] # -- z must be List[A] for i in range(min(len(xx), len(yy))): x = xx[i] # -- x must be int y = xx[i] # -- y must be int z = f(x,y) # -- f must be Callable[(int,int], B] zz[i] = (x,y,z) # -- A must be Tuple[int,int,B] return zz # -- return value must be List[Tuple[int,int,B]] it doesn't catch that B = int, but I think that's acceptable. Is this not the case? Are we really expecting people to write stuff like the above? Jukka (mypy's author) believes that specifying full annotations will catch more bugs, and makes the error messages easier to understand -- in practice when you let the type inferencer run free it will often infer bizarre union types or other complex forms, and the errors may well appear in the wrong spot. This is a common issue with type inferencing, and anyone who has tried to learn Haskell (or C++ :-) has plenty of experience with such errors. The good news is that I don't actually expect people to have to write or even read stuff like the above; the example was quoted out of context. In code that the typical (mediocre :-) programmer writes, argument types won't be more complex than some built-in primitive type (e.g. int or str) or a List of primitive types, or perhaps a user-defined class or List of such. And you can always leave the annotation out if you find yourself fighting the type checker -- it will default to Any and the type checker will just shut up. That's the beauty of gradual typing (and it differs greatly from strict typing as seen in Haskell or C++). -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Type hints -- a mediocre programmer's reaction
On Mon, 20 Apr 2015, Paul Moore wrote: On 20 April 2015 at 19:41, Barry Warsaw ba...@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. How about header files? (ducks...) Isaac Morland CSCF Web Guru DC 2619, x36650 WWW Software Specialist ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Type hints -- a mediocre programmer's reaction
On Mon, Apr 20, 2015 at 1:50 PM, Harry Percival harry.perci...@gmail.com wrote: stub files are only used to type-check *users* of a module. If you want a module itself to be type-checked you have to use inline type hints is this a fundamental limitation, or just the current state of tooling? It's not fundamental, it's just more in line with the original purpose of stubs (to describe C extensions). -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Type hints -- a mediocre programmer's reaction
On Apr 20, 2015, at 3:02 PM, Ian Cordasco graffatcolmin...@gmail.com wrote: I think while the authors are currently seeing stubs as a necessary *evil* they're missing points where they're a better backwards compatible solution for people who want to give users with capable IDEs the ability to use stub (or hint) files. We might have not chosen the wording that makes this obvious to you but we definitely did consider all of the points you’re referring to: https://www.python.org/dev/peps/pep-0484/#stub-files -- Best regards, Łukasz Langa WWW: http://lukasz.langa.pl/ Twitter: @llanga IRC: ambv on #python-dev___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Type hints -- a mediocre programmer's reaction
On Tue, Apr 21, 2015 at 9:41 AM, Jack Diederich jackd...@gmail.com wrote: * It is not optional. Please stop saying that. The people promoting it would prefer that everyone use it. If it is approved it will be optional in the way that PEP8 is optional. If I'm reading your annotated code it is certainly /not/ optional that I understand the annotations. * The cognitive load is very high. The average function signature will double in length. This is not a small cost and telling me it is optional to pretend that every other word on the line doesn't exist is a farce. * Every company's style guide is about to get much longer. That in itself is an indicator that this is a MAJOR language change and not just some optional add-on. Maybe I'm completely misreading everything here, but I would have thought that there are two completely different use-cases here: 1) Library authors 2) Application authors When you're writing a library, it can be a great help to provide type annotations, because every application that uses your library can benefit. When you're writing an application, you can completely ignore them, but still get the benefit of everyone else's. Most company style guides are going to spend most of their time dealing with application code. Maybe you'd put a few type annotations on some of your internal library-like routines, but you certainly don't need to adorn every single function parameter and return value in code that's called only from elsewhere. Say you have an application framework like Flask - you're going to be writing a bunch of functions that you never call from your own code, but which get called by the framework. Annotating their return values is almost completely useless - you're not going to be checking Flask itself for type errors! And the benefit of annotating their parameters is constrained to the functions themselves, so you can take your pick whether or not you annotate any particular function. Type hints are on par with all those other structured function signature tidbits - formatted docstrings, autodoc comments, etc, etc, etc. Has any one of those become mandatory for all code? Nope. And possibly the best answer to anyone who tries to demand type hints for all code is TheDailyWTF, where you can find JavaDoc like this: http://thedailywtf.com/articles/If_At_First_You_Don_0x27_t_Succeed http://thedailywtf.com/articles/SelfDocumenting I have no fears for my own code. Are you afraid for yours? ChrisA ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Type hints -- a mediocre programmer's reaction
On Tue, Apr 21, 2015 at 10:52 AM, Ben Finney ben+pyt...@benfinney.id.au wrote: Chris Angelico ros...@gmail.com writes: On Tue, Apr 21, 2015 at 9:41 AM, Jack Diederich jackd...@gmail.com wrote: * It is not optional. Please stop saying that. The people promoting it would prefer that everyone use it. If it is approved it will be optional in the way that PEP8 is optional. If I'm reading your annotated code it is certainly /not/ optional that I understand the annotations. […] Maybe I'm completely misreading everything here […] I think you've misunderstood the complaint. When you're writing a library, it can be a great help to provide type annotations, because every application that uses your library can benefit. When you're writing an application, you can completely ignore them, but still get the benefit of everyone else's. Jack is not complaining only about *writing* code. He's complaining about the effect this will have on code that we all are expected to *read*. Ahh. Yes, that's a concern. When you go digging into that library to find out how it works, yes, you'd be face-to-face with their type annotations. I doubt the worst-case complex ones are going to come up all that often, though. Sure, you might declare that something returns a list of dictionaries mapping tuples of integers and strings to list of sets of atoms, but that's hardly common. (And chances are you can just declare that it returns List[Dict] and have done with it.) Maybe it'd be of value to have a quick code stripper that takes away all the annotations, plus any other junk/framing that you're not interested in, and gives you something you can browse in a text editor? It could take away all the Sphinx adornments from docstrings, any source control versioning markers, all that kind of thing. Then you could read through the code in a simpler form, while still having type annotations there for you if you need them. ChrisA ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Type hints -- a mediocre programmer's reaction
On Mon, Apr 20, 2015 at 11:34:51PM +0100, Harry Percival wrote: exactly. yay stub files! we all agree! everyone loves them! Not even close. -- Steve ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Type hints -- a mediocre programmer's reaction
On Mon, Apr 20, 2015 at 4:41 PM, Jack Diederich jackd...@gmail.com wrote: Twelve years ago a wise man said to me I suggest that you also propose a new name for the resulting language The barrage of FUD makes me feel like the woman who asked her doctor for a second opinion and was told you're ugly too. I talked with many of you at PyCon about the costs of PEP 484. There are plenty of people who have done a fine job promoting the benefits. So excuse me if I also defend the PEP against your attack. * It is not optional. Please stop saying that. The people promoting it would prefer that everyone use it. If it is approved it will be optional in the way that PEP8 is optional. If I'm reading your annotated code it is certainly /not/ optional that I understand the annotations. The PEP 8 analogy is actually great -- that PEP's style advice *is* optional and plenty of people ignore it happily. The benefits come out when you're sharing code but violations are no big deal. And as to requiring what the annotations mean: the CPython interpreter itself doesn't even use them when executing your code, so you can certainly pretend that the annotations aren't there and read the body of the function or the docstring instead. * Uploading stubs for other people's code is a terrible idea. Who do I contact when I update the interface to my library? The random Joe who helped by uploading annotations three months ago and then quit the internet? I don't even want to think about people maliciously adding stubs to PyPI. We're certainly not planning to let arbitrary people upload stubs for arbitrary code to PyPI that will automatically be used by the type checkers. (We can't stop people from publishing their stubs, just as you can't stop people from writing blog posts or stackoverflow answers with examples for your library.) The actual plan is to have a common repository of stubs (a prototype exists at https://github.com/JukkaL/typeshed) but we also plan some kind of submission review. I've proposed that when submitting stubs for a package you don't own, the typeshed owners ask the package owner what their position is, and we expect the answers to fall on the following spectrum: - I don't want stubs uploaded for my package - I'll write the stubs myself - I want to review all stubs that are uploaded for my package before they are accepted - Please go ahead and add stubs for my package and let me know when they're ready - Go ahead, I trust you This seems a reasonable due diligence policy that avoids the scenarios you're worried about. (Of course if you refuse stubs a black market for stubs might spring into existence. That sounds kind of exciting... :-) * The cognitive load is very high. The average function signature will double in length. This is not a small cost and telling me it is optional to pretend that every other word on the line doesn't exist is a farce. Have you never found yourself trying to read someone else's code and being stopped in your tracks because you couldn't find out what kind of argument was expected somewhere? I'm personally quite tired of seeing that an argument is a file and not knowing whether it's meant to be an IO stream or a filename (and was that bytes or unicode? :-). Or seeing something documented as creation time without knowing whether that's a datetime or a a POSIX timestamp (or maybe milliseconds or a string encoding a date). Etc., etc. And yes, you can put the info in docstrings or comments (though it won't be less verbose, and it will be more likely wrong). One way to see type hints is as a way to save on docstrings and comments by using a standard notation that ties type info to the argument without the need to repeat the argument name. Yes, you need to use your brain. But don't tell my that all the Python code you read or write is self-explanatory, because it isn't. * Every company's style guide is about to get much longer. That in itself is an indicator that this is a MAJOR language change and not just some optional add-on. Actually, standardization *reduces* the length of a company style guide, like PEP 8 did before. Would you rather have instructions for the specific linter your company uses, instead of the single phrase use type hints (PEP 484)? * People will screw it up. The same people who can't be trusted to program without type annotations are also going to be *writing* those type annotations. I don't follow this argument. So what? People will screw up anything you give them. introspection, metaclasses, import hooks, reduce(), you name it. * Teaching python is about to get much less attractive. It will not be optional for teachers to say just pretend all this stuff over here doesn't exist This argument is particularly weak. Teachers are actually *very* effective teaching only the parts of Python they need -- some start with just functions and variables. Others with just classes and methods. Few ever even teach operator
Re: [Python-Dev] Type hints -- a mediocre programmer's reaction
On Mon, Apr 20, 2015 at 07:30:39PM +0100, Harry Percival wrote: Hi all, tldr; type hints in python source are scary. Would reserving them for stub files be better? No no no, a thousand times no it would not! Please excuse my extreme reaction, but over on the python-list mailing list (comp.lang.python if you prefer Usenet) we already had this discussion back in January. Anyone wishing to read those conversations should start here: https://mail.python.org/pipermail/python-list/2015-January/697202.html https://mail.python.org/pipermail/python-list/2015-January/697315.html Be prepared for a long, long, long read. Nothing in your post hasn't already been discussed (except for your proposal to deprecate annotations altogether). So if you feel that I'm giving any of your ideas or concerns short-shrift, I'm not, it's just that I've already given them more time than I can afford. And now I get to do it all again, yay. (When reading those threads, please excuse my occasional snark towards Rick, he is a notorious troll on the list and sometimes I let myself be goaded into somewhat less than professional responses.) While I sympathise with your thought that it's scary, I think it is misguided and wrong. As a thought-experiment, let us say that we roll back the clock to 1993 or thereabouts, just as Python 1.0 (or so) was about to be released, and Guido proposed adding *default values* to function declarations [assuming they weren't there from the start]. If we were used to Python's clean syntax: def zipmap(f, xx, yy): the thought of having to deal with default values: def zipmap(f=None, xx=(), yy=()): might be scary. Especially since those defaults could be arbitrarily complex expressions. Twenty years on, what should we think about such fears? Type hinting or declarations are extremely common in programming languages, and I'm not just talking about older languages like C and Java. New languages, both dynamic and static, like Cobra, Julia, Haskell, Go, Boo, D, F#, Fantom, Kotlin, Rust and many more include optional or mandatory type declarations. You cannot be a programmer without expecting to deal with type hints/declarations somewhere. As soon as you read code written in other languages (and surely you do that, don't you? you practically cannot escape Java and C code on the internet) and in my opinion Python cannot be a modern language without them. I'm going to respond to your recommendation to use stub files in another post (replying to Barry Warsaw), here I will discuss your concerns first. My first reaction to type hints was yuck, and I'm sure I'm not the only one to think that. viz (from some pycon slides): def zipmap(f: Callable[[int, int], int], xx: List[int], yy: List[int]) - List[Tuple[int, int, int]]: arg. and imagine it with default arguments. You've picked a complex example and written it poorly. I'd say yuck too, but let's use something closer to PEP-8 formatting: def zipmap(f: Callable[[int, int], int], xx: List[int], yy: List[int] ) - List[Tuple[int, int, int]]: Not quite so bad with each parameter on its own line. It's actually quite readable, once you learn what the annotations mean. Like all new syntax, of course you need to learn it. But the type hints are just regular Python expressions. Of course, part of this reaction is just a knee-jerk reaction to the new and unfamiliar, and should be dismissed, entirely justifiably, as mere irrationality. But I'm sure sensible people agree that they do make our function definitions longer, more complex, and harder to read. Everything has a cost and all features, or lack of features, are a trade-off. Function definitions could be even shorter and simpler and easier to read if we didn't have default values. [...] I'm not so sure. My worry is that once type hinting gets standardised, then they will become a best practice, and there's a particular personality type out there that's going to start wanting to add type hints to every function they write. Similarly to mindlessly obeying PEP8 while ignoring its intentions, hobgoblin-of-little-minds style, I think we're very likely to see type hints appearing in a lot of python source, or a lot of pre-commit-hook checkers. Pretty soon it will be hard to find any open source library code that doesn't have type hints, or any project style guide that doesn't require them. I doubt that very much. I'm not a betting man, but if I were, I would put money on it. Firstly: libraries tend to be multi-version, and these days they are often hybrid Python 2 3 code. Since annotations are 3 only, libraries cannot use these type hints until they drop support for Python 2.7, which will surely be *no less* than five years away. Probably more like ten. So annotations everywhere are, at best, many years away. Secondly, more importantly, there are a lot of Python
Re: [Python-Dev] Type hints -- a mediocre programmer's reaction
On Mon, Apr 20, 2015 at 02:41:06PM -0400, Barry Warsaw wrote: On Apr 20, 2015, at 07:30 PM, Harry Percival 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. A very, very strong -1 to that. Stub files are a necessary evil. Except where absolutely necessary, they should be strongly discouraged. A quote from the Go FAQs: Dependency management is a big part of software development today but the “header files” of languages in the C tradition are antithetical to clean dependency analysis—and fast compilation. http://golang.org/doc/faq#What_is_the_purpose_of_the_project Things that go together should be together. A function parameter and its type information (if any) go together: the type is as much a part of the parameter declaration as the name and the default. Putting them together is the best situation: def func(n: Integer): ... and should strongly be prefered as best practice for when you choose to use type hinting at all. Alternatives are not as good. Second best is to put them close by, as in a decorator: @typing(n=Integer) # Don't Repeat Yourself violation def func(n): ... A distant third best is a docstring. Not only does it also violate DRY, but it also increases the likelyhood of errors: def func(n): Blah blah blah blah blah blah Arguments: m: Integer Keeping documentation and code in synch is hard, and such mistakes are not uncommon. Putting the type information in a stub file is an exponentially more distant fourth best, or to put it another way, *the worst* solution for where to put type hints. Not only do you Repeat Yourself with the name of the parameter, but also the name of the function (or method and class) AND module. The type information *isn't even in the same file*, which increases the chance of it being lost, forgotten, deleted, out of date, unmaintained, etc. -- Steve ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Type hints -- a mediocre programmer's reaction
On Mon, Apr 20, 2015 at 12:49 PM, Paul Moore p.f.mo...@gmail.com wrote: On 20 April 2015 at 20:35, Łukasz Langa luk...@langa.pl wrote: Since it was mentioned in a different e-mail in this thread: yes, the standard library is not getting any type annotations. When we decide to ship type hints with Python 3.6, they will be added as stubs. Why is this? Surely this is something where the stdlib should eat its own dogfood and include inline hints rather than stub files? Actually, eat your own dogfood is not one of the goals of the stdlib -- nor is it supposed to be an example of how to code. This is often misunderstood. The stdlib contains a lot of Python code, and you can learn a lot from it, but good coding habits aren't generally something you learn there -- the code is crusty (some of the oldest Python code in existence lives in the stdlib!), often has to bend over backwards to support backward compatibility, and is riddled with performance hacks. Based on some events in the distant past, there's actually an active ban against sweeping changes to the stdlib that attempt to modernize it or use new features -- because there is so much code in the stdlib, review of such sweeping (often near-mechanical) changes is inevitably less thorough than when a new feature is implemented, and even the best tests don't catch everything, so regressions in dark corners are often the result. The only place in the stdlib where I expect inline type hints to be used is in brand new modules introduced in 3.6 or later, and then only when the author believes inline type hints to be clearer than wordy docstrings. The situation is possibly even bleaker (or happier, depending on your position :-) for inline type hints in 3rd party packages -- few package authors will be satisfied with supporting only Python 3.5 and later. True, you can support Python 3.2 and up by declaring the 3rd party typing package as a dependency (unless Python 3.5+ is detected), but I don't expect this to become a popular approach overnight. So I think the rumors of Python's death are greatly exaggerated. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Type hints -- a mediocre programmer's reaction
On Mon, Apr 20, 2015 at 1:35 PM, Łukasz Langa luk...@langa.pl wrote: Yeah, so agreed, this is pretty busy. For such cases, reformatting makes it less confusing (see: Screenshot 1). While it helps, this sort of best-practice is still unsettled (and apparently not obvious). In the short term it would make more sense to recommend using stub files for all the reason Harry enumerated. Once the best practices are nailed down through experience with stub files, then we can make recommendations regarding inline type hints. -eric ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Type hints -- a mediocre programmer's reaction
On 21 April 2015 at 08:07, Guido van Rossum gu...@python.org wrote: The situation is possibly even bleaker (or happier, depending on your position :-) for inline type hints in 3rd party packages -- few package authors will be satisfied with supporting only Python 3.5 and later. True, you can support Python 3.2 and up by declaring the 3rd party typing package as a dependency (unless Python 3.5+ is detected), but I don't expect this to become a popular approach overnight. mypy has a codec for 2.x which strips type annotations - https://github.com/JukkaL/mypy/tree/master/mypy/codec - while you can't run mypy under 2.x, you can run it under 3.x to perform the analysis, and ones code still runs under 2.x. Another route - the one I've been experimenting with as I get familiar with mypy - is to just use type comments exclusively. Function type comments currently break, but that seems like a fairly shallow bug to me, rather than something that shouldn't work. The advantage of that route is that editors which make comments appear in subtle colours, makes the type hints be unobtrusive without specific syntax colouring support. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Type hints -- a mediocre programmer's reaction
On 21 April 2015 at 08:10, Eric Snow ericsnowcurren...@gmail.com wrote: While it helps, this sort of best-practice is still unsettled (and apparently not obvious). In the short term it would make more sense to recommend using stub files for all the reason Harry enumerated. Once the best practices are nailed down through experience with stub files, then we can make recommendations regarding inline type hints. -eric Forgive my ignorance, but can stub files can't annotate variables within functions? E.g. AIUI if there is a stub file, it is used in the static analysis instead of the actual source. Likely I've got it modelled wrong in my head :) -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Type hints -- a mediocre programmer's reaction
On Apr 20 2015, Harry Percival hj...@cantab.net wrote: My first reaction to type hints was yuck, and I'm sure I'm not the only one to think that. viz (from some pycon slides): def zipmap(f: Callable[[int, int], int], xx: List[int], yy: List[int]) - List[Tuple[int, int, int]]: arg. and imagine it with default arguments. This is indeed ugly as hell and I certainly would not want to see this in any Python file I'm working with. However, I always assumed that whatever tools consume these annotations are expected to be good enough at automatic type inference that something like this would never be necessary? In practice, I would hope that the above simplifies to def zipmap(f, xx: List[int], yy: List[int]): because (just picking a probably buggy random implementation) zz = [] # -- z must be List[A] for i in range(min(len(xx), len(yy))): x = xx[i] # -- x must be int y = xx[i] # -- y must be int z = f(x,y) # -- f must be Callable[(int,int], B] zz[i] = (x,y,z) # -- A must be Tuple[int,int,B] return zz # -- return value must be List[Tuple[int,int,B]] it doesn't catch that B = int, but I think that's acceptable. Is this not the case? Are we really expecting people to write stuff like the above? Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] [RELEASED] Python 3.5.0a4 is now available
On behalf of the Python development community and the Python 3.5 release team, I'm thrilled to announce the availability of Python 3.5.0a4. Python 3.5.0a4 is the fourth and alpha release of Python 3.5, which will be the next major release of Python. Python 3.5 is still under development, and is not yet complete. This is a preview release, and its use is not recommended for production settings. The next release of Python 3.5 will be 3.5.0b1, the first beta release. Python 3.5 will enter feature freeze at this time; no new features will be added to 3.5 after this point. Python 3.5.0b1 is scheduled to be released May 22, 2015. Three important notes for Windows users about Python 3.5.0a4: * If you have previously installed Python 3.5.0a1, you may need to manually uninstall it before installing Python 3.5.0a4 (issue23612). * If installing Python 3.5.0a4 as a non-privileged user, you may need to escalate to administrator privileges to install an update to your C runtime libraries. * There is now a third type of Windows installer for Python 3.5. In addition to the conventional installer and the web-based installer, Python 3.5 now has an embeddable installer designed to be run as part of a larger application's installer for apps using or extending Python. You can find Python 3.5.0a4 here: https://www.python.org/downloads/release/python-350a4/ Happy hacking, //arry/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Surely nullable is a reasonable name?
On Apr 19, 2015, at 01:19 AM, Larry Hastings wrote: We should rename types to accept. accept should takes a set of types; these types specify the types of Python objects the Clinic parameter should accept. For the funny pseudo-types needed in some Clinic declarations (buffer, robuffer, and rwbuffer), Clinic provides empty class declarations so these behave like types too. Having only followed the AC discussions tangentially, I have to say that the above suggestion and the given examples make a lot more intuitive sense to me. I had the same initial thought as Glenn regarding type annotations. It's fine that they're separate concepts, but it's also helpful that Larry's suggestion above seems to align them better. Cheers, -Barry ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Starting CPython development w/ Docker
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2015-04-20 15:52, Saul Shanabrook wrote: I started trying some CPythong development a week ago at PyCon and first got testing working using Docker on my mac. This had the advantage of not having to worry about installing and dependencies, and also let me test on different Python versions easily. If you are interested in trying it, I laid out all the steps here: http://www.saulshanabrook.com/cpython-dev-w-docker/ Good work! May I suggest that you add ccache and the --config-cache option to configure? Both speed up the build process a lot. For ccache you have to install the package and put /usr/lib64/ccache in front of PATH. Christian -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJVNRgSAAoJEIZoUkkhLbaJZF0IAJQHcVJvxCnWXjtnsgW7y4Rc sTccSCvBU6Qlwghnb8jn5+fMLGpgBpT1JQqvX8jdzXSkRyvFjPROdGTFom6qRm4F vrF2XAfA5lH2nwvtx1S8WsG6NaStGn/H1tfwZRujE5bxViuPpd3UXfYPJogSKWAZ OadnpnjdhS24EJ5GMnJe61KPZphBlNyTmSB60SXxu/Sk3AIVnM+RPKshvbsla1vg 3udBRgjP2LLSO6mzwIjfL8+blnpExkUTLiqHqpw9QX3i4ox4xkIozBj56KinfVvC lXHtMuK+dv34A43BffAX1ipEVd+HpCBYwhQEitievjidLXkoLcpAwsl/bSY7ToI= =JeXE -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Starting CPython development w/ Docker
I started trying some CPythong development a week ago at PyCon and first got testing working using Docker on my mac. This had the advantage of not having to worry about installing and dependencies, and also let me test on different Python versions easily. If you are interested in trying it, I laid out all the steps here: http://www.saulshanabrook.com/cpython-dev-w-docker/ Saul Shanabrook ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Starting CPython development w/ Docker
On Mon, Apr 20, 2015 at 10:44 AM Saul Shanabrook s.shanabr...@gmail.com wrote: I started trying some CPythong development a week ago at PyCon and first got testing working using Docker on my mac. This had the advantage of not having to worry about installing and dependencies, and also let me test on different Python versions easily. If you are interested in trying it, I laid out all the steps here: http://www.saulshanabrook.com/cpython-dev-w-docker/ Would you mind proposing this idea to core-mentors...@python.org and seeing if anyone else would benefit? If others do try it out and like then feel free to file an issue at bugs.python.org for devinabox to add your script. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Starting CPython development w/ Docker
On Mon, Apr 20, 2015 at 12:13 PM Carol Willing willi...@willingconsulting.com wrote: On 4/20/15 7:52 AM, Brett Cannon wrote: On Mon, Apr 20, 2015 at 10:44 AM Saul Shanabrook s.shanabr...@gmail.com wrote: I started trying some CPythong development a week ago at PyCon and first got testing working using Docker on my mac. This had the advantage of not having to worry about installing and dependencies, and also let me test on different Python versions easily. Saul, thanks for the steps, and I will be trying it out. Let me know if you have any questions at all, I am happy to help, even if they are just about getting docker setup. If you are interested in trying it, I laid out all the steps here: http://www.saulshanabrook.com/cpython-dev-w-docker/ Would you mind proposing this idea to core-mentors...@python.org and seeing if anyone else would benefit? If others do try it out and like then feel free to file an issue at bugs.python.org for devinabox to add your script. Please do share your good work with core-mentorship :) Brett, Up to date docker development containers (devinabox in the cloudy sky) would be helpful for new developers since there will be less questioning and uncertainty if the dev environment is set up correctly. I posted to core-mentorship and am happy to help get this workflow integrated anywhere, if it is useful. ___ Python-Dev mailing listPython-Dev@python.orghttps://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/willingc%40willingconsulting.com -- *Carol Willing* Developer | Willing Consulting https://willingconsulting.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Starting CPython development w/ Docker
On 4/20/15 7:52 AM, Brett Cannon wrote: On Mon, Apr 20, 2015 at 10:44 AM Saul Shanabrook s.shanabr...@gmail.com mailto:s.shanabr...@gmail.com wrote: I started trying some CPythong development a week ago at PyCon and first got testing working using Docker on my mac. This had the advantage of not having to worry about installing and dependencies, and also let me test on different Python versions easily. Saul, thanks for the steps, and I will be trying it out. If you are interested in trying it, I laid out all the steps here: http://www.saulshanabrook.com/cpython-dev-w-docker/ Would you mind proposing this idea to core-mentors...@python.org mailto:core-mentors...@python.org and seeing if anyone else would benefit? If others do try it out and like then feel free to file an issue at bugs.python.org http://bugs.python.org for devinabox to add your script. Please do share your good work with core-mentorship :) Brett, Up to date docker development containers (devinabox in the cloudy sky) would be helpful for new developers since there will be less questioning and uncertainty if the dev environment is set up correctly. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/willingc%40willingconsulting.com -- *Carol Willing* Developer | Willing Consulting https://willingconsulting.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Type hints -- a mediocre programmer's reaction
Hi all, tldr; type hints in python source are scary. Would reserving them for stub files be better? For people that don't know me (most of you I think), I don't have a long experience of programming (perhaps 5 years, barring a bit of messing about with BASIC in the 80s), I've never made any commits on cPython, and so I don't speak from a great height of experience. I am very much a mediocre programmer (TM). I wouldn't have felt it appropriate to email python-dev about this, except that one of the members encouraged me to do so -- perhaps they felt there hadn't been enough balance in discussions to date. Also, I've had enough positive reactions in person and on the twitters from people well-known in the Python community, to make me feel like maybe the issue is at least worth discussing... And I do have some experience with teaching Python to beginners, enough to worry about anything I think might make their lives more difficult. So, in outline: I think: - type hints are ugly - they make the language harder to understand - particularly for beginners - the defense that they're optional doesn't really work, for several reasons. - but maybe there's a way to keep them and their benefits, without incurring the above costs My first reaction to type hints was yuck, and I'm sure I'm not the only one to think that. viz (from some pycon slides): def zipmap(f: Callable[[int, int], int], xx: List[int], yy: List[int]) - List[Tuple[int, int, int]]: arg. and imagine it with default arguments. Of course, part of this reaction is just a knee-jerk reaction to the new and unfamiliar, and should be dismissed, entirely justifiably, as mere irrationality. But I'm sure sensible people agree that they do make our function definitions longer, more complex, and harder to read. No doubt this has occurred to everyone that's been working on them. There is a cost. But the benefits make it worthwhile. I don't want to spend too long debating the benefits -- Guido gave an outline of them at Pycon, and I know y'all wouldn't be doing all this work for no reason. All I will say is -- it sounds like the people that will benefit are Google and other Enterprise users, IDE vendors, and the people that will pay for it in sweat and confusion are beginners and John Q. Mediocre Programmer. But what I really want to dwell on are the costs. I've heard this argument that, because the type hints are optional, they're not something that beginners or the average user needs to worry about. Beginners won't need to learn them, and they'll probably never see them. And average users won't need them either, so they don't need to worry about them either. So the costs are minimal! I should relax. I'm not so sure. My worry is that once type hinting gets standardised, then they will become a best practice, and there's a particular personality type out there that's going to start wanting to add type hints to every function they write. Similarly to mindlessly obeying PEP8 while ignoring its intentions, hobgoblin-of-little-minds style, I think we're very likely to see type hints appearing in a lot of python source, or a lot of pre-commit-hook checkers. Pretty soon it will be hard to find any open source library code that doesn't have type hints, or any project style guide that doesn't require them. It may not even be an irrational, cargo-cult thing -- they really may be paying dividends. But it does mean we will all have to wade through a bunch of type hints before we can understand any function. Not the end of the world. The extra effort may even help us understand our functions better. But it's just that little bit uglier, just that little extra mental effort, just that little extra barrier that is going to mean some people, at the margin, just give up on learning programming, or switch to javascript, or whatever it'll be. Now I'm aware that throwing out type hints altogether is unlikely to be a popular proposal at this stage. So I'm casting around for an alternative. And it seems to me that stub files might be the answer. From what I understand, type hint files are files with the extension .pyi that provide stub versions of the functions in the matching .py files, but that contain the type hints, while the .py file doesn't. In fact they're likely to be a very popular approach anyway, since they allow type hints for codebases that need to work under both 2 and 3. That sounds like the best of both worlds to me. - .py files stay beautiful, concise, and easy to read. - beginners don't have to worry about wading through type definitions when they find themselves browsing someone else's source - type information is available to the linters and static file checkers, so we get all the benefits. Sounds great right? Everybody will be happy! So let's nail it down! If I was in charge, here's what I'd do: * standardise the syntax for type hints in 3.5, as per PEP484 * but: recommend the use of stub files as the
Re: [Python-Dev] Type hints -- a mediocre programmer's reaction
voice-from-audience burn the witch.. /voice-from-audience More seriously.. +1 to Harry voice. Adding type hints to function code is so ugly that that i'm breaking silence and i'm expressing it here before you, so: It's ugly Perhaps this question was asked a million times, but why not docstrings, which seems to be more elegant and natural place for that? I will not use it. Damn, if i had reputation this could be a threat. ;) On Mon, Apr 20, 2015 at 8:43 PM Barry Warsaw ba...@python.org wrote: On Apr 20, 2015, at 07:30 PM, Harry Percival 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. Cheers, -Barry ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/tymoteusz.jankowski%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Type hints -- a mediocre programmer's reaction
On Apr 20, 2015, at 07:30 PM, Harry Percival 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. Cheers, -Barry ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Type hints -- a mediocre programmer's reaction
On Mon, Apr 20, 2015 at 11:30 AM, Harry Percival hj...@cantab.net wrote: My first reaction to type hints was yuck, and I'm sure I'm not the only one to think that. viz (from some pycon slides): def zipmap(f: Callable[[int, int], int], xx: List[int], yy: List[int]) - List[Tuple[int, int, int]]: My opinion of type hints is: they are great inline, when they are simple. Cases like (I know its not a real-world case, but there are plenty of similarly simple functions): def add(a: int, b: int) - int: are fine. When you get more complicated examples, especially when they involve complex types (list, tuple, callable, etc). In such cases, it may make sense to predefine a type (I believe the typehints PEP supports some form of typedef - I think just a simple assignment) and use that instead of the full type name. This will generally make the function definition MUCH easier to read. That sounds like the best of both worlds to me. - .py files stay beautiful, concise, and easy to read. - beginners don't have to worry about wading through type definitions when they find themselves browsing someone else's source - type information is available to the linters and static file checkers, so we get all the benefits. Sounds great right? Everybody will be happy! So let's nail it down! If I was in charge, here's what I'd do: * standardise the syntax for type hints in 3.5, as per PEP484 * but: recommend the use of stub files as the preferred place to store hints * and: deprecate function annotations in the core language * remove them from the core language altogether in 3.6 The main drawback of using a stub file is that it is much more likely to end up out-of-date, and thus useless at best, than if the types are defined inline. The same issue applies to various alternative proposals such as having the typehints in decorators, but to a lesser degree. The same issue also applies to general comments as well. I would say there are a few major reasons to use stub files: 1) You cannot put the annotations in the source, probably either because the module is a C library, or you must support versions which do not support annotations. 2) You must use annotations for other purposes. 3) The annotations are particularly complicated, and you cannot provide nice names for the various types (likely, because the types are just very difficult to name, such as in the zipmap example, though that one might be easier in a more specific context). Outside of those specific reasons, I would vastly prefer any annotations to be included in the source, where they are much more likely to be updated, rather than in a separate file, where they will likely be forgotten. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Type hints -- a mediocre programmer's reaction
On 20 April 2015 at 19:41, Barry Warsaw ba...@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. Paul ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Type hints -- a mediocre programmer's reaction
On 04/20, Barry Warsaw wrote: On Apr 20, 2015, at 07:30 PM, Harry Percival 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. +1 -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Type hints -- a mediocre programmer's reaction
On Apr 20, 2015, at 11:30 AM, Harry Percival hj...@cantab.net wrote: I think: - type hints are ugly Making them work with the current Python syntax was a challenge. Granted, the end result is not perfect. It can be improved *if* type hints prove to be generally useful and popular. This might not happen. - they make the language harder to understand - particularly for beginners A counter-point to that would be that good APIs already expose this information but using informal languages in docstrings, pure comments or straight API documentation. This only standardizes the notation in a way that: - let’s those annotations be accessed at runtime - let’s the entire Python ecosystem learn to read them statically and use them for REPL, IDE completion and type checking - moves them to a place where it’s less likely that they become outdated def zipmap(f: Callable[[int, int], int], xx: List[int], yy: List[int]) - List[Tuple[int, int, int]]: Yeah, so agreed, this is pretty busy. For such cases, reformatting makes it less confusing (see: Screenshot 1). As already stated, you can also name the types, in which case they’re less busy. That’s a compomise, too, since they require indirection when reading. No doubt this has occurred to everyone that's been working on them. There is a cost. But the benefits make it worthwhile. Yes, they start to read more transparently after a while. It sounds like the people that will benefit are Google and other Enterprise users, IDE vendors, and the people that will pay for it in sweat and confusion are beginners and John Q. Mediocre Programmer. Any startup that at the beginning bangs out code as fast as possible - and eventually *becomes successful* - will be happy to be able to introduce gradual typing as a measure of improving quality. My worry is that once type hinting gets standardised, then they will become a best practice” For library authors and APIs, they might. There’s nothing alarming with that, as I said, for those use cases you already expect “type hints” in the form of docstrings, comments, API docs, tests, etc. there's a particular personality type out there that's going to start wanting to add type hints to every function they write. Similarly to mindlessly obeying PEP8 while ignoring its intentions, hobgoblin-of-little-minds style, I think we're very likely to see type hints appearing in a lot of python source, or a lot of pre-commit-hook checkers. Yes, this is going to happen sometimes. If you can’t fight a hobgoblin in your community/organization, you’ve got bigger problems than ugly hints. Ultimately, we can’t optimize for the lowest common denominator. Pretty soon it will be hard to find any open source library code that doesn't have type hints, or any project style guide that doesn't require them. Harry, you must be the biggest Python 3 supporter ever 3 More seriously, no, this is not going to happen fast. Sounds great right? Everybody will be happy! So let's nail it down! Stub files have many downsides, too, unfortunately: - we don’t *want* to have them, but we *need* to have them (C extensions, third-party modules, Python 2, …) - they bring cognitive overhead of having to switch between two files - they require the author to repeat himself quite a lot - they might go out of date much easier than annotations in the function signature - they can’t help with local variable inference Since it was mentioned in a different e-mail in this thread: yes, the standard library is not getting any type annotations. When we decide to ship type hints with Python 3.6, they will be added as stubs. As for the actual proposal: * standardise the syntax for type hints in 3.5, as per PEP484 * but: recommend the use of stub files as the preferred place to store hints * and: deprecate function annotations in the core language * remove them from the core language altogether in 3.6 That is still pretty radical. I’ll leave the final words to the other authors of PEP 484 but from my perspective it’s not type annotations that are ugly, it’s the stubs. The annotation syntax might be improved for future releases. Stubs - by design - will always be inferior because of the reasons stated above. -- Best regards, Łukasz Langa WWW: http://lukasz.langa.pl/ Twitter: @llanga IRC: ambv on #python-dev___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Type hints -- a mediocre programmer's reaction
On 20 April 2015 at 20:35, Łukasz Langa luk...@langa.pl wrote: Since it was mentioned in a different e-mail in this thread: yes, the standard library is not getting any type annotations. When we decide to ship type hints with Python 3.6, they will be added as stubs. Why is this? Surely this is something where the stdlib should eat its own dogfood and include inline hints rather than stub files? Paul ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Type hints -- a mediocre programmer's reaction
Just another peanut from the gallery: I pretty much agree with everything that harry said. My current response to type annotations is Yuck, that kills readability. I hope no code I ever have to read uses this.. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
