Re: [Python-Dev] Type hints -- a mediocre programmer's reaction
lol @ the fact that the type hints are breaking github's syntax highlighter :) On 23 April 2015 at 14:44, Paul Sokolovsky pmis...@gmail.com wrote: Hello, On Thu, 23 Apr 2015 14:48:58 +0200 Wolfgang Langner tds333+py...@gmail.com wrote: Hello, On Thu, Apr 23, 2015 at 11:59 AM, Paul Sokolovsky pmis...@gmail.com wrote: Hello, On Thu, 23 Apr 2015 10:43:52 +0200 Wolfgang Langner tds333+py...@gmail.com wrote: [] Also ask why no one used type specifier, they are possible since Python 3.0 ? Because it is the wrong way for Python. That's an example of how perceptions differ. In my list, everyone(*) uses them - MyPy, MicroPython, etc. Even more should use them (any JIT module, which are many), but sit in the bushes, waiting for a kick, like PEP484 provides. (*) Everyone of those who needs them. Otherwise, let's throw out metaclasses - noone uses them. They are there to be used and won't go away. But for most Libraries out there no one used it. JIT (Numba), Cython and other compilers/tools doing optimization have their own syntax and needs. That's exactly what needs to change, and where this PEP helps, as was already pointed out: http://code.activestate.com/lists/python-dev/135659/ They need even more information like i32, i64, different floats and so on. That's poor excuse for not trying to be a good member of Python community (and work on standard type annotation syntax, instead of digging own hole). MyPy is really new and in development. And the docstring type spec way is still possible. Anything is possible. The talk is about what makes most of sense. Docstrings were always arbitrary string designated at human's consumption, how (ab)using them for type annotations is better than having clean language-grammar syntax? MicroPython uses one annotation for their inline assembler stuff not type hints. Here's how MicroPython uses type annotations: https://github.com/micropython/micropython/blob/master/tests/micropython/viper_ptr8_load.py For the library there are no type hints for function definitions. Remark: I use Metaclasses, seldom but if needed very useful. :-) -- bye by Wolfgang -- Best regards, Paul mailto:pmis...@gmail.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/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
Hey, I just wanted to say to everyone, thanks for being so patient and willing to engage with this discussion, despite my not having done my research and read the (substantial) prior discussion on the topic. Here it is (or at least, some of it!) for any other newcomers: https://mail.python.org/pipermail/python-list/2015-January/697202.html https://mail.python.org/pipermail/python-list/2015-January/697315.html https://github.com/ambv/typehinting/issues/55 I'm not sure any of it will radically change anyone's mind. Everyone (I think) agrees that type hints carry some cost in terms of legibility and simplicity of the language. Everyone agrees they have some benefits. The disagreement remains over whether it will be worth it, and whether stub files vs inline vs something-else would be the best place to hide them. Is let's wait and see an acceptable position? Probably the only real way to resolve the disagreement is to start seeing the type hints in use, and form opinions based on real-world practice. Some people will like them inline. Lots of people will use stub files, since they're the only way to maintain 2+3 compatibility, so it's my home that the community will standardise around that. Still other people will want to have another crack at using docstrings, but the standardisation on notation of types will still help them. And still other others will want no part in them, and will argue against them in their communities. Hopefully a best practice will evolve. And hopefully it'll be the stub file one, and then we really can deprecate function annotations in 3.6 ;-) On 21 April 2015 at 11:56, Rob Cliffe rob.cli...@btinternet.com wrote: On 21/04/2015 10:33, Cory Benfield wrote: On 21 April 2015 at 10:10, Chris Angelico ros...@gmail.com ros...@gmail.com wrote: At this point, you may want to just stop caring about the exact type. Part of the point of gradual typing is that you can short-cut a lot of this. And quite frankly, this isn't really helping anything. Just skip it and say that it's Union[Mapping, Iterable, None]. I think this is my problem with the proposal. This change doesn't catch any of the bugs anyone was going to hit (no-one is passing a callable to this parameter), and it doesn't catch any of the bugs someone might actually hit (getting the tuple elements in the wrong order, for example). At this point the type signature is worse than useless. Exactly. At this point putting the type signatures in seems to be a pointless exercise in masochism (for the author) and sadism (for the reader). The refreshing thing about Python is that it is a fantastic, *concise*, dynamically typed language, at the opposite end of the spectrum from C++ (ugh!). We have got used to the consequences (good and bad) of this: Duck typing, e.g. a function to sort numbers (sorry Tim Peters bad example) turns out to support any kind of object (e.g. strings) that supports comparison. Not to mention objects of some class that will be written in 5 years time. (Adding a type hint that restricted the argument to say a sequence of numbers turns out to be a mistake. And what is a number? Is Fraction? What about complex numbers, which can't be sorted? What if the function were written before the Decimal class?) Errors are often not caught until run time that would be caught at compile time in other languages (though static code checkers help). (Not much of a disadvantage because of Python's superb error diagnostics.) Python code typically says what it is doing, with the minimum of syntactic guff. (Well, apart from colons after if/while/try etc. :-) ) Which makes it easy to read. Now it seems as if this proposal wants to start turning Python in the C++ direction, encouraging adding ugly boilerplate code. (This may only be tangentially relevant, but I want to scream when I see some combination of public/private/protected/static/extern etc., most of which I don't understand.) Chris A makes the valid point (if I understand correctly) that Authors of libraries should make it as easy as possible to (i) know what object types can be passed to functions (ii) diagnose when the wrong type of object is passed Authors of apps are not under such obligation, they can basically do what they want. Well, (i) can be done with good documentation (docstrings etc.). (ii) can be done with appropriate runtime checks and good error messages. E.g. (Cory's example) I'm sure it is possible to test somehow if an object is file-like (if only by trying to access it like a file). Is thorough argument checking and provision of good diagnostics going to be easy for the library author? No. Is it going to be a lot of work to do thoroughly? Almost certainly yes. But what the hell, writing a production-quality library is not an exercise for newbies. It seems to me that type hints are
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
@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
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
[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
