PEP 484 evolution
I have a few different things I'd like to add to PEP 484. Should I start this here or on pyrhon-dev? The hope is to get these into 3.5.2. When is that going out? --Guido (mobile)
On 3/18/2016 1:32 PM, Guido van Rossum wrote:
I have a few different things I'd like to add to PEP 484. Should I start this here or on pyrhon-dev?
I would say that it depends on whether the ideas need to be kicked around a bit or whether you think they are in final form.
The hope is to get these into 3.5.2. When is that going out?
Last I knew, it was scheduled for next May, but https://www.python.org/dev/peps/pep-0478/ does not say anything. -- Terry Jan Reedy
It's a mix. The list of things I definitely want to get to is now here: https://github.com/python/typing/milestones/3.5.2 On Fri, Mar 18, 2016 at 11:57 AM, Terry Reedy <tjreedy@udel.edu> wrote:
-- --Guido van Rossum (python.org/~guido)
On Friday, March 18, 2016 at 2:11:00 PM UTC-5, Guido van Rossum wrote:
It's a mix.
IMHO, I'd venture to say that any proposal that is *NOT* already explicitly scheduled for implementation, or any parts thereof that "you consider debatable", should be discussed here. Python-dev seems more appropriate for things that are either "already in the language", or "will be in the language no matter what anyone says or does otherwise".
So please read my list of issues and see where you stand yourself on them. https://github.com/python/typing/milestones/3.5.2 On Fri, Mar 18, 2016 at 12:46 PM, Rick Johnson <rantingrickjohnson@gmail.com> wrote:
-- --Guido van Rossum (python.org/~guido)
On Friday, March 18, 2016 at 2:51:26 PM UTC-5, Guido van Rossum wrote:
So please read my list of issues and see where you stand yourself on them.
Are you kidding? I'd be delighted to offer my opinion! It's what i, *DO*! I'm not sure what kind of "time frame" you're expecting here, but you'll have to allow me a "reasonable" amount of time to (1) read over your list, (2) catch up on the history of the "type hints proposal", and (3) compose a thoughtful response -- I've never been the type that likes to rush to judgement, or shoot from hip, especially, regarding something as important as introducing a new feature that could negativity affect readability. Also, i must admit that, outside of a few discussions on Pyhton-list, I have not followed the "type hints evolution" as closely as, well, perhaps i should have. In fact, to tell you the truth, (psst: this is just between you and me!) i kinda thought it would be punted around for awhile, and then return to obscurity... But since this proposal seems to be moving "full steam ahead", and i consider myself to be an integral part of this fine community, then, as a member, it is my *DUTY* to be wise of these things. Please stand by...
@Everyone: Okay i'm completely confused as to were we are in the "type hints" evolution. It seems to have taken all sorts of random twists and turns -- will someone please explain? (see examples below) @Guido: i've skimmed PEP484, and i've read your handful of "issues", but i need to know *EXACTLY* what a type hint declaration will look like *BEFORE* i can offer my opinion on these matters. At this point, i'm not overly concerned about the dirty details of how type hints will be implemented "under the hood", my first concern is, to understand what *onerous* this feature will be placing on the programmer, and, what *damage* it will could cause to the "general readability" of Python source code. In other words -- i need to decide if this is a good idea or not. In pep484, the declaration seems to be firmly coupled/interleaved with the source code: def greeting(name: str) -> str: return 'Hello ' + name Oh my. But if so, i would hardly call this "a hint". Are we going to introduce `->` as a method for defining the return type of a function, and special-case `:` for binding types to symbols in sigs? But the rabbit hole goes deeper... After reading PEP484, i'm looking over your list of issues, and i see you using "magic comments" like this: def whatever( arg1, # type: int arg2, # type: int arg3, # type: int arg4, # type: str arg5, # type: str arg6, # type: str ): # type: (...) -> float # this is not a type comment (note that "..." above is literal) return (arg1 + arg2 + arg3 + float(arg4) + float(arg5) + float(arg6)) So which is it? The former? The latter? Or both? PS: As i await your response, I'm praying to the FSM that type hints will be implemented as the latter, and *NOT* the former. And i'm *SO* fearful of the thought of the former, that i'm *literally* shaking as i write this response-- *PLEASE* tell me it's the latter.
-- Ryan [ERROR]: Your autotools build scripts are 200 lines longer than your program. Something’s wrong. http://kirbyfan64.github.io/ On Mar 18, 2016 5:51 PM, "Rick Johnson" <rantingrickjohnson@gmail.com> wrote:
Neither! Python 3 type hints are just function annotations. It's the job of a type checker/linter (like mypy) to actually decipher the annotations as types. Adding/removing type hints won't have a runtime effect on your program.
I think the latter is for Python 2.
PEP 484 already was passed using the former syntax...so you might be a little late saying that...
On Friday, March 18, 2016 at 5:59:42 PM UTC-5, Ryan Gonzalez wrote:
Thanks for explaining -- i now understand what's going on here... So even though type-hints are "interleaved within the code", at run-time, they have no meaning, and are simply ignored as if they were comments -- it's my worst nightmare come true -- starting with Python 3.5, the readability of Python source will never be the same again. And while i understand that type-hints are optional, once they placed in the code, it is impossible not to be forced to read them.
I think the latter [code example you provided] is for Python 2.
Hmm, being that Guido said his "list of issues" was relevant only to 3.5.2, that would not make sense to me. But perhaps i'm missing something again???
On 03/18/2016 03:51 PM, Rick Johnson wrote: [snippety snip snip] For those who have not yet encountered "Ranting Rick Johnson": he is a troll from Python List; please do not waste your time with him. -- ~Ethan~
On 18 March 2016 at 22:51, Rick Johnson <rantingrickjohnson@gmail.com> wrote:
You do realise that PEP 484 was implemented in Python 3.5, don't you? See https://docs.python.org/3/library/typing.html The question here is around some additions (which I don't understand too well, not being a user of type hints) that Guido is looking to add in 3.5.2. Paul
On Friday, March 18, 2016 at 6:08:23 PM UTC-5, Paul Moore wrote:
You do realize that PEP 484 was implemented in Python 3.5, don't you?
I do now, and to say that i am shocked would be an understatement -- no, this is clinical depression, plain and simple...
Yes, i'm fully aware of the scope of what he was requesting opinions *FOR*.... but for me to comment on his "list of issues" without first bringing myself up to speed with the "evolution", would be both naive and disingenuous. @Guido. At this point ,i don't know if i can offer any opinions on your list, because i'm fundamentally opposed to the way type-hints have been implemented. Granted, i'm not opposed to Python having type-hints, or even at some time in the future, supporting "optional typing", i'm just opposed to the way in which they were implemented -- magic comments would have been more Pythonic, at least IMHO. This type- hints thing has fundamentally transformed what Python *IS*. No longer can it market itself as a language who promotes readability, or is "executable pseudo code". Why do we always feel that we have to make the same mistakes that everyone else has made? Can't we do better? Can't we evolve without violating our fundamental philosophy? This is a very sad for me.
On Fri, Mar 18, 2016 at 03:51:36PM -0700, Rick Johnson wrote:
Rick, PEP 484 has been discussed and discussed and discussed here, and on Python-Dev. To avoid boring everyone else to death, I suggest you raise your initial questions on the python-list mailing list (comp.lang.python newsgroup). If you raise them there, I promise I'll answer. (I think other c.l.p regulars ChrisA and Terry are also familiar enough with PEP 484 to answer your questions.) Then, once you have a better grasp of the background, you can come back here with any questions about Guido's newer proposals. Consider that just a suggestion for the sake of keeping discussion here focused on the newest parts of the PEP, rather than going over old ground. -- Steve
On Saturday, March 19, 2016 at 8:27:33 AM UTC-5, Steven D'Aprano wrote:
My last two responses should have cleared that up...
Well thanks for offering to help, and at some point i may start a thread over there, or on my blog, but if i do it now, in the state of shock that i'm in, it will be an expletive laced tirade of epic proportions. I'm far too emotional at this time to maintain even a *MODICUM* of civility in an unmoderated forum, and as time goes on, i'm only going to become more angry if a proper audience is not offered for this grievance.
I don't understand why this group is not the appropriate place to discuss matters concerning Python. Even a discussion that revolves around the subjects of "is type- hints a good idea", or "could we implement type-hints without violating our fundamental philosophy" seems highly appropriate here, and if we move over to Python-list (as you request), we will loose the valuable input of Guido, because he does not participate on that list in any form. @Guido I beseech you to at *MINIMUM* reconsider this implementation. Put it on hold for a short time. It is not too late to prevent catastrophe. I assure you, we can add type-hints, and even optional typing, without violating Python's fundamental philosophy. But once this feature propagates, in its currently form, you can't just press the "undo button". We cannot allow Python to became another "cookie cutter language". We must ask ourselves, "What is it that makes Python *DIFFERENT*"? "What is it that makes Python *SPECIAL*? If you composed a list, starting with the most important features that make Python special, ask yourself -- were would "type-hints" be on that list? Would it even be *ON* the list? I believe type hints is a welcomed addition to "Python's evolution", but not in any form that will undermine the attributes that make Python so special. At *LEAST* entertain a new discussion. A new discussion that invites *ALL* members to participate, regardless of "status" That's all i'm asking... And if the implementation goes ahead "as is", at least those who object, will get the audience they deserve, and will be content knowing that they did everything in their power to prevent catastrophe.
On Sun, Mar 20, 2016 at 1:28 AM, Rick Johnson <rantingrickjohnson@gmail.com> wrote:
What, you mean the form that was released in Python 3.5 on Dec 6th 2015 after *extensive* discussion on every Python-related mailing list, newsgroup, subreddit, blog, and blue-faced baboon? Yeah. Can't just press the undo button now. Or are you talking about the way that annotations were added to the language in Python 3.0, released in 2008? If this enhancement to an already-existing feature is what finally makes you go and take your ranting to some other language, fine. Goodbye. Otherwise, take it to python-list and, in concurrence with Steven's pledge, I will answer any questions/concerns raised in good faith. ChrisA
On Saturday, March 19, 2016 at 9:37:22 AM UTC-5, Chris Angelico wrote: On Sun, Mar 20, 2016 at 1:28 AM, Rick Johnson
I'm talking specifically about the propagation of "type-hint annotations" within source code in the wild. Conceivably, Python could add a million unique annotations to the language, but no harm is done to readability *UNTIL* the annotations are utilized by Python source code in the wild. My argument is that these "type-hint annotations" have not *YET* propagated -- at least not to any critical mass -- and therefore, we still have time to prevent this ship from crashing on the rocks.
Chris, i know you'd be happier if i was not a member of this community. And you've made that point clear on multiple occasions.
What purpose, other than emotional release, will that serve? I could achieve the same by yelling at a wall.
On Sat, 19 Mar 2016 at 08:09 Rick Johnson <rantingrickjohnson@gmail.com> wrote:
I think that's a bit dramatic. As others have pointed out, this has already been discussed quite extensively and decided upon. The community has not had enough time to make an informed opinion on this topic to ask that it be removed.
The offers seemed reasonable, so throwing them back in their faces doesn't really seem to help anything. Based on Chris' reaction there seems to be some history from somewhere else that is spilling over here. I'm going to remind everyone -- not just Rick because he's new here but also those who have reacted harshly to Rick being here -- that this list falls under the PSF Code of Conduct and it will be enforced.
On 19/03/2016 19:42, Brett Cannon wrote:
As all ready pointed out rr is a well known troll from the main Python mailing list. Unless he talks about tkinter/IDLE you can usually treat his posts with several tons of salt. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence
On Saturday, March 19, 2016 at 2:43:01 PM UTC-5, Brett Cannon wrote:
Hi Brett, I'm wondering what your last sentence is implying. Could you elaborate please? Here are my two interpretations: (1) The community is actively discussing the issues i have raised in this thread, but will need more time to decide if my fears are indeed valid... or (2) The community is only testing type-hints in the wild, and may decide, at a later date, to remove them if the roll out does not go as expected...
The offers seemed reasonable, so throwing them back in their faces doesn't really seem to help anything.
Yes, i will admit that the *offers* they provided where "reasonable". But i have dealt with Steven and Chris and Mark for many years, and i can tell you from experience, that once we move this discussion over to Python-list (which is unmoderated), the hospitality and decency will quickly evaporate into the ether. I prefer for this not to descend into a flame war, and would like to engage in a civil discourse. I have strong reservations against this "type- hints feature", at least in its current form, and i know i'm not the only person who does.
On Sat, 19 Mar 2016 at 17:57 Rick Johnson <rantingrickjohnson@gmail.com> wrote:
The latter. Python 3.5.0 only came out this past September so it has not even been a year yet. Plus things like this take multiple years to work their way into people's development processes so any talk of removing something that would break backwards-compatibility is very premature.
That's fine, but I have dealt with them for years as well and find them rather reasonable individuals.
You're allowed to have reservations, but the point is the debate on type hints in regards as to whether they should exist or not is over and done with as the decision to have them has already been made as shown by them existing in a release of Python. Drudging the topic up here serves no purpose as they will not be removed and so debating it is just a waste of time. It would be better to discuss how to improve them as Guido is doing as that will be productive.
On Sat, Mar 19, 2016 at 07:28:54AM -0700, Rick Johnson wrote:
I don't understand why this group is not the appropriate place to discuss matters concerning Python.
It is appropriate to discuss matters concerning Python. It is not appropriate to dig up matters that were settled months or years ago. Type annotations have been available in Python 3 for seven or eight years, MyPy has been around for long enough to prove that the concept of type-hinting is workable, and the typing module has been approved and released. This is not something which is a spur of the moment decision, even if it is new to you.
Take a deep breath and calm down. The type-hints are completely optional and nobody will be forced to use them. -- Steve
On Sat, Mar 19, 2016 at 11:46 AM, Steven D'Aprano <steve@pearwood.info> wrote:
Take a deep breath and calm down. The type-hints are completely optional and nobody will be forced to use them.
I don't think it's fair for you to tell me to: "calm down because this won't effect you". What evidence are you basing that theory on? Type-hits will effect everyone. Telling me to calm down is like: blowing up and damn, and then telling the peasants to "clam down" because their houses, and more troubling, their entire village was destroyed as a result of actions that were "beyond their control". You, and a few others supporters, keep claiming that "type- hints" are optional -- but while they may be optional to *write*, they are *not* optional to *read*. Furthermore, once source code is written that includes this "interleaved syntax", the readability of the code will become *permanently* damaged. Observe the following: # SIMPLE EXAMPLE WITHOUT TYPE HINTS: def greeting(name): return 'Hello, {}'.format(name) # SIMPLE EXAMPLE WITH TYPE HINTS: def greeting(name: str) -> str: return 'Hello, {}'.format(name) I couldn't just ignore the ": str" and the "-> str" even if i wanted to, no more than i could ignore braces -- if python gave us the option of defining blocks with braces. No, it's there *forever*, mucking up the readability of the code. And if that example seems too simplistic, then feast your eyes on this "abortion of readability": def greeting(names: Union[List[str], Dict[int, List[str]]]) -> Union[ List[str], Dict[int, List[str]]]: fmt = 'Hello, {}' if isinstance(names, dict): return [(k, fmt.format(', '.join(v))) for k, v in names.items()] else: return fmt.format(', '.join(names)) When faced with code like that, my first reaction is to go running back into the loving arms of Java -- why would i use Python? When Java offers *REAL* static typing; is compiled; runs *EVERYWHERE*; executes far more quickly; and is not suffering from an identity crisis. ============================================================ BUT THERE IS STILL HOPE... ============================================================ I assure you, we can introduce a "type-hint-spec" that won't destroy the readability of Python source code -- by moving the spec *OUTSIDE* of sigs... Consider this: def greeting(name): # typehint: greeting(name:str) -> str return 'Hello, {}'.format(name) ...or even this: @typehint: greeting(name:str) -> str def greeting(name): return 'Hello, {}'.format(name) ...or by using stub files (but i understand why people hate them, because of the "syncing issues" involved.) ...any of which, are a more Pythonic way to evolve. and for sequence members, or other "member types", creating new objects that enforce "explicit typing", along the lines of array.array(type), is far more pythonic that introducing *line noise* to force *all* objects to submit to this type- hint nightmare. >>> import array >>> a1 = array.array >>> a1 = array.array('i') >>> a1.append(10) >>> a1.append('10') Traceback (most recent call last): File "<pyshell#4>", line 1, in <module> a1.append('10') TypeError: an integer is required You don't need type-hints where type can be *enforced*. ============================================================ WHAT DO WE CONSIDER IMPORTANT? ============================================================ *READABILITY* is the most cited reason for choosing Python, followed closely behind by: rapid development and the freedom of dynamic typing -- take away any of those, and what's the point anymore? What's next, braces? How deep does this "philosophical perversion" go? I can sum up this "supposed feature" in one sentence... type-hints (as implemented) shackles a programmer with *ALL* of the syntactical onerous that any statically typed language would demand, except, without offering any benefits of *REAL* type-checking -- rr Should a "feature", that is marketed as a "hint", shackle the programmer with the same onerous that the *REAL* feature would? Consider the following observation of type-hints: You have to write the hint *YOURSELF*, then, you have to process the hint *YOURSELF* -- python does nothing but ignore your "type-hint syntax". So it's like: "Hey Python, i'll pay you two dollars if you'll allow me to write this nasty type-hint syntax"... So, python takes the two dollars, silently ignores the nasty syntax, and then charges every reader a "readability fee"... SOMETHING IS SOOOOO WRONG HERE! Contrary to popular belief, "type-hints" is not "feature", no, it's a *FUNDAMENTAL TRANSFORMATION* of Python into a completely different language! One that makes the same old mistakes that every other language has made. "Welcome to mediocrity, leave your expectations at the door" If you think the people who love Python, because of it's readability, are going to take this "type-hints absurdity" lying down, well, then, you and "your supporters" are in for a rude awakening! Whether intentional or not, type-hints will effect *EVERY* Python programmer at some point in the future -- even those that wish to avoid it. And since Python has already suffered a terrible blow from the release of Python3000, this "type-hints feature", if implemented "as is", looks to be the final "nail in it's coffin". But we can prevent this if we do something *NOW*. I implore each and every member to ask themselves the following questions: (1) What is the "essence of Python", that makes it such an attractive language to use? (2) If you had to compose a short list of the best attributes of Python -- would type-hints be on that list? If so, explain... (3) How do you justify the irreversible damage to Python's readability, that will be caused by this current implementation of type-hints -- surely you're not taking the position that: "no damage will be caused". (4) What is *SO* important about type-hints that it over- rides our fundamental philosophy?
On 3/19/2016 4:14 PM, Rick Johnson wrote:
Just to be sure you know, one of the options is to put type-hints in a separate stub file, so only those concerned will ever see them. In particular, type hints for the stdlib will have to be kept separate.
def greeting(names: Union[List[str], Dict[int, List[str]]]) -> Union[ List[str], Dict[int, List[str]]]:
I agree that the extra overloading makes this hard to read by obscuring the essential parts. Anything like the above should be in private code or stub files. -- Terry Jan Reedy
On Saturday, March 19, 2016 at 5:43:12 PM UTC-5, Terry Reedy wrote:
Yes, I was aware of the "stubfile option", and had stubfiles been the *ONLY* option, i would have thrown my support behind this type-hints thing 110%! Just think of it... Stub files would offload *ALL* the onerous on the *SINGLE* programmer who wanted to employ them, and would not force *ANY* reader to read them -- unless of course, the reader *WANTED* to. This would have been wonderful! It would have been great! It would have been [Insert your happy word here]! But alas, this is not what we have implemented.
In particular, type hints for the stdlib will have to be kept separate.
That's a wonderful start. Now, if we can *ONLY* convince the powers that be, to make it mandatory everywhere!
Agreed. But unless the convention is forced, we will see code like this everywhere. Terry, you're closer to these folks than i am. You've *GOT* to try and convince them that this "interleaved typehints" thing is going to be a disaster -- see if you can gather some "off the record" support. If stubfiles were mandatory: (1) Almost all of the work, that has been invested so far by Python-dev, will *NOT* be for nothing. (2) Typehints will *NOT* go away. (3) We can save readability *AND* keep type-hints. (win-win) If we can convince them to make stubfiles mandatory, then we will prevent the propagation of "interleaved type-hint" code in the wild. Then, we can redesign the type-hint-spec as a magic comment -- instead of the current "interleaved dead code" implementation. This is really the only way out of this mess. We cannot dump type-hints, because too many folks are counting on them.
On Sun, Mar 20, 2016 at 12:34 PM, Rick Johnson <rantingrickjohnson@gmail.com> wrote:
Stub files have *never* been the only option, for the same reason that external documentation is not a replacement for docstrings. Keeping information near the code it's connected to gives it a FAR better chance of staying current than having it out-of-line does. Stub files are supported for those times when it's impossible or inadvisable to use inline annotations (eg for Py2 compatibility - the comments are ugly compared to the proper annotations), but the preferred way to provide type hints is to use the PEP 3107 annotation syntax. ChrisA
On 3/19/2016 21:58, Chris Angelico wrote:
I don't exactly see how stub files would be any different than tests in this regard. Unless I am totally misunderstanding something, the type hints only exist to make static analysis by tools (presumably in a test suite) easier. Why would a failing static analysis check go unnoticed and not the a test? Why is there no argument to integrate the test suite into the module under test, by the same logic? When documentation does not get updated to reflect the reality of the code, a test run does not fail, a task does not turn red in CI, tools don't return non-zero. If you care about type-hints, keeping hints in stub files, and not updating those stubs, breaks things. Why muck up the code for people who don't care about type hints?
On Sun, Mar 20, 2016 at 1:21 PM, Alexander Walters <tritium-list@sdamon.com> wrote:
There are - look at things like doctest. However, tests tend to be much longer-winded than type hints - even the most verbose of type hints - so the cost of keeping them inline is far higher. The benefits are similar, though. ChrisA
On Sun, Mar 20, 2016 at 01:29:36PM +1100, Chris Angelico wrote:
In my experience, for every line of code I write, I will end up with ten lines of tests. Keeping *all* my tests in the same file as the code being tested would completely overwhelm the actual code. Nevertheless, it is appropriate to include some tests in place with the code: - doc tests, as Chris mentions above; - some applications may include a short "self-test" that the user can run from the command line to verify that it is working; - we might consider assertions as a kind of run time internal consistency test; - some languages have support for integrating tests in your code. For example, Eiffel makes extensive use of Design By Contract for testing, with "require", "ensure" and "invariant" keywords. https://archive.eiffel.com/doc/online/eiffel50/intro/language/invitation-07.... Rust allows you to mark a function as test code by annotating it with the "test" attribute. http://static.rust-lang.org/doc/master/book/testing.html D can integrate the function and its unit test in the same piece of code: http://dlang.org/spec/unittest.html Cobra includes both contracts and in-place unit tests: http://cobra-language.com/docs/quality/ -- Steve
On Mar 19, 2016, at 18:34, Rick Johnson <rantingrickjohnson@gmail.com> wrote:
That would definitely turn me off the feature. In practice, I've found that, at least for me, the largest benefit of PEP 484 has come from documenting interfaces. There are a reasonable fraction of cases where a name and type for each parameter is enough to understand the use of a function, but a name alone isn't. Of course there are other cases where the types get in the way--so I just don't specify them there. This shouldn't be too surprising--ML, Haskell, etc. users have long known that sometimes it aids readability to explicitly declare a type even when the inference engine makes it unnecessary. Why should it be any different when dynamic typing always makes it unnecessary? Anyway, if stub files were the only way to specify types, PEP 484 would probably still be useful for some people, as in Dropbox's project, but it would be a lot less interesting to me.
On 20 March 2016 at 06:14, Rick Johnson <rantingrickjohnson@gmail.com> wrote:
The fact we've been down this road before, especially with the introduction of ABCs (much of the fearful rhetoric around PEP 484 bears a striking similarity to that around PEP 3119 nigh on a decade ago). If the Python community were going to go overboard with explicit type hints, we'd already see a large proportion of projects running pylint with very strict configuration settings, or using the existing typechecking tools like Google's pytypedecl. However, that's precisely what we *don't* see - instead we see folks using those capabilities responsibly, adopting them when the complexity of their project or organisational structure calls for it, and omitting them otherwise. (And many of the folks that don't have the relevant problems remain puzzled as to why these tools that help improve maintainability for large projects and large teams exist in the first place) The fear response of "other people are going to overuse these, which means *I'm* going to have to read a lot of code containing them, which means programming in Python is going to become less fun" is perfectly understandable, but isn't really backed up by the community's collective behavioural history. (Monkeypatching, multiple inheritance and metaclasses are other capabilities that fall into a similar category - really powerful, and when you need them, you're grateful they're there, but best avoided when you don't have a genuine need for them) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
I tried to be calm about asking the tone to be turned down on this topic, but I feel like I wasn't listened to, so consider this your *official warning, Rick*: *stop the bombastic, insulting tone or you will be banned*. It is not considerate or respectful to call type hints an "abortion of readability" and claim we are suffering from "an identity crisis" thanks to this "philosophical perversion" brought on by this "type-hint nightmare". Plenty of people on this list had a thorough, cordial discussion on this topic long before you joined it and you do not have the right to come here and suddenly start disparaging their hard work (not to mention those people who aren't on this list who also participated in the discussion and eventual implementation). If type hints upset you that much you are welcome to not use Python anymore and "go running back into the loving arms of Java" if you prefer. I'm also asking everyone to consider this discussion of removing type hints dead, so please be respectful of other people's time and don't reply to this thread. On Sat, 19 Mar 2016 at 13:15 Rick Johnson <rantingrickjohnson@gmail.com> wrote:
On Sunday, March 20, 2016 at 12:37:48 PM UTC-5, Brett Cannon wrote:
Hello Brett (and all Group Members), Since it had become obvious to me, that the emotions surrounding this subject-matter present a high probability of turning toxic, I had made the decision to drop this thread last night -- there is no need for me to continually beat this dead horse, the community has made its decision. At this time, i want to thank everyone who participated, especially those who offered constructive replies. Also, I want everyone to know that my objections to type-hints are not exclusively based on emotion, no, I am still convinced that type-hints (as implemented) has the potential to undermine the very essence of what makes Python unique among all other languages -- but that's just my opinion, feel free to ignore if you don't agree. Out of respect for those who have so graciously volunteered their time to implement this feature, i pledge that i will not express my reservations regarding type-hints in this group *EVER* again. However, i will be composing a thoughtful and exhaustive dissent (regarding type-hints) and posting it publicly very soon. If anyone shares my reservations of type-hints (as implemented), please do not reply here, instead, contact me via email, so that we may discuss these matters privately. And as always, any discussions with me are 100% confidential. Thanks all And Happy Pythoning!
On Sun, 20 Mar 2016 at 13:35 Rick Johnson <rantingrickjohnson@gmail.com> wrote:
Thank you for recognizing that your emotions were getting the better of you. But please do realize, Rick, that the warning does stand and it is not relegated to just this discussion thread, so please take the time in the future to think through your emails to this list before you send them as I would prefer to not have to ban you (or anyone else for that matter; banning people is a bit stressful for me as I don't exactly enjoy that responsibility, but I will deal with the stress if I feel anyone causes people to dread reading emails from this list due to their behaviour). -Brett
On 3/18/2016 3:09 PM, Guido van Rossum wrote:
It's a mix. The list of things I definitely want to get to is now here: https://github.com/python/typing/milestones/3.5.2
#2: backport aab2c59 to python2/typing.py I believe you are referring to a back-compatibility module on PyPI. If so, this is out-of-scope for python-ideas. The only connection with 3.5.2 is that 2.7.12 should come out about the same time. #3, #1: many parameters require long comment signature? These are a question and possible solution for the type comments intended for 2.7 (though allowed, I believe, in 3.5 and earlier with the back-compatibility module). The issue: some functions have so many parameters that a type comment will not fit on one line. A proposal discussed here before is multiline type comments. The alternate solution is to allow '...' as an abbreviation. My very slight objection is that this will mean that the type comment no longer matches the function signature above. The counter-argument is that duplicating a long parameter type list, especially when one only cares about typing the return type, is obnoxious. I presume this proposal is based on problems with real code. + something. I do not understand, in #3, "Would it be valid to annotate just a few argument [and use ... also, I presume]? and "Yes". What would it look like? Is that part of #1? #4 Ambiguity of "Z = Dict[T, int]". I don't understand enough to understand the 2nd interpretation, so 'pass'. Ambiguity is bad, though. #5 A proposal to allow 'Type[T]'? Where "T = TypeVar['T']"? Just unpostponed from last May. #6 "What does it mean to inherit from a generic type without specifying type parameters?" I am not clear on what patch is being proposed. This seems to still be in ideas stage. #7 Allow @overload in implementation as well as stub files. You originally rejected this, then reopened in January with discussion here and pydev. Is more discussion needed? Final votes on pydev? -- Terry Jan Reedy
On Fri, 18 Mar 2016 at 11:57 Terry Reedy <tjreedy@udel.edu> wrote:
That's basically the rule of them I take. Basically I view python-ideas as the place to start the question of "is this a good idea or is it bonkers?" Once you know that answer you either take to python-dev or drop it. And as a core dev you can use your own judgment as to whether you need the extra step of discussing it here first and instead bypass this list.
Since 3.5.1 came out in December I would expect either at or after PyCon US. Larry is RM so he's the only one that really knows.
On 3/18/2016 1:32 PM, Guido van Rossum wrote:
I have a few different things I'd like to add to PEP 484. Should I start this here or on pyrhon-dev?
I would say that it depends on whether the ideas need to be kicked around a bit or whether you think they are in final form.
The hope is to get these into 3.5.2. When is that going out?
Last I knew, it was scheduled for next May, but https://www.python.org/dev/peps/pep-0478/ does not say anything. -- Terry Jan Reedy
It's a mix. The list of things I definitely want to get to is now here: https://github.com/python/typing/milestones/3.5.2 On Fri, Mar 18, 2016 at 11:57 AM, Terry Reedy <tjreedy@udel.edu> wrote:
-- --Guido van Rossum (python.org/~guido)
On Friday, March 18, 2016 at 2:11:00 PM UTC-5, Guido van Rossum wrote:
It's a mix.
IMHO, I'd venture to say that any proposal that is *NOT* already explicitly scheduled for implementation, or any parts thereof that "you consider debatable", should be discussed here. Python-dev seems more appropriate for things that are either "already in the language", or "will be in the language no matter what anyone says or does otherwise".
So please read my list of issues and see where you stand yourself on them. https://github.com/python/typing/milestones/3.5.2 On Fri, Mar 18, 2016 at 12:46 PM, Rick Johnson <rantingrickjohnson@gmail.com> wrote:
-- --Guido van Rossum (python.org/~guido)
On Friday, March 18, 2016 at 2:51:26 PM UTC-5, Guido van Rossum wrote:
So please read my list of issues and see where you stand yourself on them.
Are you kidding? I'd be delighted to offer my opinion! It's what i, *DO*! I'm not sure what kind of "time frame" you're expecting here, but you'll have to allow me a "reasonable" amount of time to (1) read over your list, (2) catch up on the history of the "type hints proposal", and (3) compose a thoughtful response -- I've never been the type that likes to rush to judgement, or shoot from hip, especially, regarding something as important as introducing a new feature that could negativity affect readability. Also, i must admit that, outside of a few discussions on Pyhton-list, I have not followed the "type hints evolution" as closely as, well, perhaps i should have. In fact, to tell you the truth, (psst: this is just between you and me!) i kinda thought it would be punted around for awhile, and then return to obscurity... But since this proposal seems to be moving "full steam ahead", and i consider myself to be an integral part of this fine community, then, as a member, it is my *DUTY* to be wise of these things. Please stand by...
@Everyone: Okay i'm completely confused as to were we are in the "type hints" evolution. It seems to have taken all sorts of random twists and turns -- will someone please explain? (see examples below) @Guido: i've skimmed PEP484, and i've read your handful of "issues", but i need to know *EXACTLY* what a type hint declaration will look like *BEFORE* i can offer my opinion on these matters. At this point, i'm not overly concerned about the dirty details of how type hints will be implemented "under the hood", my first concern is, to understand what *onerous* this feature will be placing on the programmer, and, what *damage* it will could cause to the "general readability" of Python source code. In other words -- i need to decide if this is a good idea or not. In pep484, the declaration seems to be firmly coupled/interleaved with the source code: def greeting(name: str) -> str: return 'Hello ' + name Oh my. But if so, i would hardly call this "a hint". Are we going to introduce `->` as a method for defining the return type of a function, and special-case `:` for binding types to symbols in sigs? But the rabbit hole goes deeper... After reading PEP484, i'm looking over your list of issues, and i see you using "magic comments" like this: def whatever( arg1, # type: int arg2, # type: int arg3, # type: int arg4, # type: str arg5, # type: str arg6, # type: str ): # type: (...) -> float # this is not a type comment (note that "..." above is literal) return (arg1 + arg2 + arg3 + float(arg4) + float(arg5) + float(arg6)) So which is it? The former? The latter? Or both? PS: As i await your response, I'm praying to the FSM that type hints will be implemented as the latter, and *NOT* the former. And i'm *SO* fearful of the thought of the former, that i'm *literally* shaking as i write this response-- *PLEASE* tell me it's the latter.
-- Ryan [ERROR]: Your autotools build scripts are 200 lines longer than your program. Something’s wrong. http://kirbyfan64.github.io/ On Mar 18, 2016 5:51 PM, "Rick Johnson" <rantingrickjohnson@gmail.com> wrote:
Neither! Python 3 type hints are just function annotations. It's the job of a type checker/linter (like mypy) to actually decipher the annotations as types. Adding/removing type hints won't have a runtime effect on your program.
I think the latter is for Python 2.
PEP 484 already was passed using the former syntax...so you might be a little late saying that...
On Friday, March 18, 2016 at 5:59:42 PM UTC-5, Ryan Gonzalez wrote:
Thanks for explaining -- i now understand what's going on here... So even though type-hints are "interleaved within the code", at run-time, they have no meaning, and are simply ignored as if they were comments -- it's my worst nightmare come true -- starting with Python 3.5, the readability of Python source will never be the same again. And while i understand that type-hints are optional, once they placed in the code, it is impossible not to be forced to read them.
I think the latter [code example you provided] is for Python 2.
Hmm, being that Guido said his "list of issues" was relevant only to 3.5.2, that would not make sense to me. But perhaps i'm missing something again???
On 03/18/2016 03:51 PM, Rick Johnson wrote: [snippety snip snip] For those who have not yet encountered "Ranting Rick Johnson": he is a troll from Python List; please do not waste your time with him. -- ~Ethan~
On 18 March 2016 at 22:51, Rick Johnson <rantingrickjohnson@gmail.com> wrote:
You do realise that PEP 484 was implemented in Python 3.5, don't you? See https://docs.python.org/3/library/typing.html The question here is around some additions (which I don't understand too well, not being a user of type hints) that Guido is looking to add in 3.5.2. Paul
On Friday, March 18, 2016 at 6:08:23 PM UTC-5, Paul Moore wrote:
You do realize that PEP 484 was implemented in Python 3.5, don't you?
I do now, and to say that i am shocked would be an understatement -- no, this is clinical depression, plain and simple...
Yes, i'm fully aware of the scope of what he was requesting opinions *FOR*.... but for me to comment on his "list of issues" without first bringing myself up to speed with the "evolution", would be both naive and disingenuous. @Guido. At this point ,i don't know if i can offer any opinions on your list, because i'm fundamentally opposed to the way type-hints have been implemented. Granted, i'm not opposed to Python having type-hints, or even at some time in the future, supporting "optional typing", i'm just opposed to the way in which they were implemented -- magic comments would have been more Pythonic, at least IMHO. This type- hints thing has fundamentally transformed what Python *IS*. No longer can it market itself as a language who promotes readability, or is "executable pseudo code". Why do we always feel that we have to make the same mistakes that everyone else has made? Can't we do better? Can't we evolve without violating our fundamental philosophy? This is a very sad for me.
On Fri, Mar 18, 2016 at 03:51:36PM -0700, Rick Johnson wrote:
Rick, PEP 484 has been discussed and discussed and discussed here, and on Python-Dev. To avoid boring everyone else to death, I suggest you raise your initial questions on the python-list mailing list (comp.lang.python newsgroup). If you raise them there, I promise I'll answer. (I think other c.l.p regulars ChrisA and Terry are also familiar enough with PEP 484 to answer your questions.) Then, once you have a better grasp of the background, you can come back here with any questions about Guido's newer proposals. Consider that just a suggestion for the sake of keeping discussion here focused on the newest parts of the PEP, rather than going over old ground. -- Steve
On Saturday, March 19, 2016 at 8:27:33 AM UTC-5, Steven D'Aprano wrote:
My last two responses should have cleared that up...
Well thanks for offering to help, and at some point i may start a thread over there, or on my blog, but if i do it now, in the state of shock that i'm in, it will be an expletive laced tirade of epic proportions. I'm far too emotional at this time to maintain even a *MODICUM* of civility in an unmoderated forum, and as time goes on, i'm only going to become more angry if a proper audience is not offered for this grievance.
I don't understand why this group is not the appropriate place to discuss matters concerning Python. Even a discussion that revolves around the subjects of "is type- hints a good idea", or "could we implement type-hints without violating our fundamental philosophy" seems highly appropriate here, and if we move over to Python-list (as you request), we will loose the valuable input of Guido, because he does not participate on that list in any form. @Guido I beseech you to at *MINIMUM* reconsider this implementation. Put it on hold for a short time. It is not too late to prevent catastrophe. I assure you, we can add type-hints, and even optional typing, without violating Python's fundamental philosophy. But once this feature propagates, in its currently form, you can't just press the "undo button". We cannot allow Python to became another "cookie cutter language". We must ask ourselves, "What is it that makes Python *DIFFERENT*"? "What is it that makes Python *SPECIAL*? If you composed a list, starting with the most important features that make Python special, ask yourself -- were would "type-hints" be on that list? Would it even be *ON* the list? I believe type hints is a welcomed addition to "Python's evolution", but not in any form that will undermine the attributes that make Python so special. At *LEAST* entertain a new discussion. A new discussion that invites *ALL* members to participate, regardless of "status" That's all i'm asking... And if the implementation goes ahead "as is", at least those who object, will get the audience they deserve, and will be content knowing that they did everything in their power to prevent catastrophe.
On Sun, Mar 20, 2016 at 1:28 AM, Rick Johnson <rantingrickjohnson@gmail.com> wrote:
What, you mean the form that was released in Python 3.5 on Dec 6th 2015 after *extensive* discussion on every Python-related mailing list, newsgroup, subreddit, blog, and blue-faced baboon? Yeah. Can't just press the undo button now. Or are you talking about the way that annotations were added to the language in Python 3.0, released in 2008? If this enhancement to an already-existing feature is what finally makes you go and take your ranting to some other language, fine. Goodbye. Otherwise, take it to python-list and, in concurrence with Steven's pledge, I will answer any questions/concerns raised in good faith. ChrisA
On Saturday, March 19, 2016 at 9:37:22 AM UTC-5, Chris Angelico wrote: On Sun, Mar 20, 2016 at 1:28 AM, Rick Johnson
I'm talking specifically about the propagation of "type-hint annotations" within source code in the wild. Conceivably, Python could add a million unique annotations to the language, but no harm is done to readability *UNTIL* the annotations are utilized by Python source code in the wild. My argument is that these "type-hint annotations" have not *YET* propagated -- at least not to any critical mass -- and therefore, we still have time to prevent this ship from crashing on the rocks.
Chris, i know you'd be happier if i was not a member of this community. And you've made that point clear on multiple occasions.
What purpose, other than emotional release, will that serve? I could achieve the same by yelling at a wall.
On Sat, 19 Mar 2016 at 08:09 Rick Johnson <rantingrickjohnson@gmail.com> wrote:
I think that's a bit dramatic. As others have pointed out, this has already been discussed quite extensively and decided upon. The community has not had enough time to make an informed opinion on this topic to ask that it be removed.
The offers seemed reasonable, so throwing them back in their faces doesn't really seem to help anything. Based on Chris' reaction there seems to be some history from somewhere else that is spilling over here. I'm going to remind everyone -- not just Rick because he's new here but also those who have reacted harshly to Rick being here -- that this list falls under the PSF Code of Conduct and it will be enforced.
On 19/03/2016 19:42, Brett Cannon wrote:
As all ready pointed out rr is a well known troll from the main Python mailing list. Unless he talks about tkinter/IDLE you can usually treat his posts with several tons of salt. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence
On Saturday, March 19, 2016 at 2:43:01 PM UTC-5, Brett Cannon wrote:
Hi Brett, I'm wondering what your last sentence is implying. Could you elaborate please? Here are my two interpretations: (1) The community is actively discussing the issues i have raised in this thread, but will need more time to decide if my fears are indeed valid... or (2) The community is only testing type-hints in the wild, and may decide, at a later date, to remove them if the roll out does not go as expected...
The offers seemed reasonable, so throwing them back in their faces doesn't really seem to help anything.
Yes, i will admit that the *offers* they provided where "reasonable". But i have dealt with Steven and Chris and Mark for many years, and i can tell you from experience, that once we move this discussion over to Python-list (which is unmoderated), the hospitality and decency will quickly evaporate into the ether. I prefer for this not to descend into a flame war, and would like to engage in a civil discourse. I have strong reservations against this "type- hints feature", at least in its current form, and i know i'm not the only person who does.
On Sat, 19 Mar 2016 at 17:57 Rick Johnson <rantingrickjohnson@gmail.com> wrote:
The latter. Python 3.5.0 only came out this past September so it has not even been a year yet. Plus things like this take multiple years to work their way into people's development processes so any talk of removing something that would break backwards-compatibility is very premature.
That's fine, but I have dealt with them for years as well and find them rather reasonable individuals.
You're allowed to have reservations, but the point is the debate on type hints in regards as to whether they should exist or not is over and done with as the decision to have them has already been made as shown by them existing in a release of Python. Drudging the topic up here serves no purpose as they will not be removed and so debating it is just a waste of time. It would be better to discuss how to improve them as Guido is doing as that will be productive.
On Sat, Mar 19, 2016 at 07:28:54AM -0700, Rick Johnson wrote:
I don't understand why this group is not the appropriate place to discuss matters concerning Python.
It is appropriate to discuss matters concerning Python. It is not appropriate to dig up matters that were settled months or years ago. Type annotations have been available in Python 3 for seven or eight years, MyPy has been around for long enough to prove that the concept of type-hinting is workable, and the typing module has been approved and released. This is not something which is a spur of the moment decision, even if it is new to you.
Take a deep breath and calm down. The type-hints are completely optional and nobody will be forced to use them. -- Steve
On Sat, Mar 19, 2016 at 11:46 AM, Steven D'Aprano <steve@pearwood.info> wrote:
Take a deep breath and calm down. The type-hints are completely optional and nobody will be forced to use them.
I don't think it's fair for you to tell me to: "calm down because this won't effect you". What evidence are you basing that theory on? Type-hits will effect everyone. Telling me to calm down is like: blowing up and damn, and then telling the peasants to "clam down" because their houses, and more troubling, their entire village was destroyed as a result of actions that were "beyond their control". You, and a few others supporters, keep claiming that "type- hints" are optional -- but while they may be optional to *write*, they are *not* optional to *read*. Furthermore, once source code is written that includes this "interleaved syntax", the readability of the code will become *permanently* damaged. Observe the following: # SIMPLE EXAMPLE WITHOUT TYPE HINTS: def greeting(name): return 'Hello, {}'.format(name) # SIMPLE EXAMPLE WITH TYPE HINTS: def greeting(name: str) -> str: return 'Hello, {}'.format(name) I couldn't just ignore the ": str" and the "-> str" even if i wanted to, no more than i could ignore braces -- if python gave us the option of defining blocks with braces. No, it's there *forever*, mucking up the readability of the code. And if that example seems too simplistic, then feast your eyes on this "abortion of readability": def greeting(names: Union[List[str], Dict[int, List[str]]]) -> Union[ List[str], Dict[int, List[str]]]: fmt = 'Hello, {}' if isinstance(names, dict): return [(k, fmt.format(', '.join(v))) for k, v in names.items()] else: return fmt.format(', '.join(names)) When faced with code like that, my first reaction is to go running back into the loving arms of Java -- why would i use Python? When Java offers *REAL* static typing; is compiled; runs *EVERYWHERE*; executes far more quickly; and is not suffering from an identity crisis. ============================================================ BUT THERE IS STILL HOPE... ============================================================ I assure you, we can introduce a "type-hint-spec" that won't destroy the readability of Python source code -- by moving the spec *OUTSIDE* of sigs... Consider this: def greeting(name): # typehint: greeting(name:str) -> str return 'Hello, {}'.format(name) ...or even this: @typehint: greeting(name:str) -> str def greeting(name): return 'Hello, {}'.format(name) ...or by using stub files (but i understand why people hate them, because of the "syncing issues" involved.) ...any of which, are a more Pythonic way to evolve. and for sequence members, or other "member types", creating new objects that enforce "explicit typing", along the lines of array.array(type), is far more pythonic that introducing *line noise* to force *all* objects to submit to this type- hint nightmare. >>> import array >>> a1 = array.array >>> a1 = array.array('i') >>> a1.append(10) >>> a1.append('10') Traceback (most recent call last): File "<pyshell#4>", line 1, in <module> a1.append('10') TypeError: an integer is required You don't need type-hints where type can be *enforced*. ============================================================ WHAT DO WE CONSIDER IMPORTANT? ============================================================ *READABILITY* is the most cited reason for choosing Python, followed closely behind by: rapid development and the freedom of dynamic typing -- take away any of those, and what's the point anymore? What's next, braces? How deep does this "philosophical perversion" go? I can sum up this "supposed feature" in one sentence... type-hints (as implemented) shackles a programmer with *ALL* of the syntactical onerous that any statically typed language would demand, except, without offering any benefits of *REAL* type-checking -- rr Should a "feature", that is marketed as a "hint", shackle the programmer with the same onerous that the *REAL* feature would? Consider the following observation of type-hints: You have to write the hint *YOURSELF*, then, you have to process the hint *YOURSELF* -- python does nothing but ignore your "type-hint syntax". So it's like: "Hey Python, i'll pay you two dollars if you'll allow me to write this nasty type-hint syntax"... So, python takes the two dollars, silently ignores the nasty syntax, and then charges every reader a "readability fee"... SOMETHING IS SOOOOO WRONG HERE! Contrary to popular belief, "type-hints" is not "feature", no, it's a *FUNDAMENTAL TRANSFORMATION* of Python into a completely different language! One that makes the same old mistakes that every other language has made. "Welcome to mediocrity, leave your expectations at the door" If you think the people who love Python, because of it's readability, are going to take this "type-hints absurdity" lying down, well, then, you and "your supporters" are in for a rude awakening! Whether intentional or not, type-hints will effect *EVERY* Python programmer at some point in the future -- even those that wish to avoid it. And since Python has already suffered a terrible blow from the release of Python3000, this "type-hints feature", if implemented "as is", looks to be the final "nail in it's coffin". But we can prevent this if we do something *NOW*. I implore each and every member to ask themselves the following questions: (1) What is the "essence of Python", that makes it such an attractive language to use? (2) If you had to compose a short list of the best attributes of Python -- would type-hints be on that list? If so, explain... (3) How do you justify the irreversible damage to Python's readability, that will be caused by this current implementation of type-hints -- surely you're not taking the position that: "no damage will be caused". (4) What is *SO* important about type-hints that it over- rides our fundamental philosophy?
On 3/19/2016 4:14 PM, Rick Johnson wrote:
Just to be sure you know, one of the options is to put type-hints in a separate stub file, so only those concerned will ever see them. In particular, type hints for the stdlib will have to be kept separate.
def greeting(names: Union[List[str], Dict[int, List[str]]]) -> Union[ List[str], Dict[int, List[str]]]:
I agree that the extra overloading makes this hard to read by obscuring the essential parts. Anything like the above should be in private code or stub files. -- Terry Jan Reedy
On Saturday, March 19, 2016 at 5:43:12 PM UTC-5, Terry Reedy wrote:
Yes, I was aware of the "stubfile option", and had stubfiles been the *ONLY* option, i would have thrown my support behind this type-hints thing 110%! Just think of it... Stub files would offload *ALL* the onerous on the *SINGLE* programmer who wanted to employ them, and would not force *ANY* reader to read them -- unless of course, the reader *WANTED* to. This would have been wonderful! It would have been great! It would have been [Insert your happy word here]! But alas, this is not what we have implemented.
In particular, type hints for the stdlib will have to be kept separate.
That's a wonderful start. Now, if we can *ONLY* convince the powers that be, to make it mandatory everywhere!
Agreed. But unless the convention is forced, we will see code like this everywhere. Terry, you're closer to these folks than i am. You've *GOT* to try and convince them that this "interleaved typehints" thing is going to be a disaster -- see if you can gather some "off the record" support. If stubfiles were mandatory: (1) Almost all of the work, that has been invested so far by Python-dev, will *NOT* be for nothing. (2) Typehints will *NOT* go away. (3) We can save readability *AND* keep type-hints. (win-win) If we can convince them to make stubfiles mandatory, then we will prevent the propagation of "interleaved type-hint" code in the wild. Then, we can redesign the type-hint-spec as a magic comment -- instead of the current "interleaved dead code" implementation. This is really the only way out of this mess. We cannot dump type-hints, because too many folks are counting on them.
On Sun, Mar 20, 2016 at 12:34 PM, Rick Johnson <rantingrickjohnson@gmail.com> wrote:
Stub files have *never* been the only option, for the same reason that external documentation is not a replacement for docstrings. Keeping information near the code it's connected to gives it a FAR better chance of staying current than having it out-of-line does. Stub files are supported for those times when it's impossible or inadvisable to use inline annotations (eg for Py2 compatibility - the comments are ugly compared to the proper annotations), but the preferred way to provide type hints is to use the PEP 3107 annotation syntax. ChrisA
On 3/19/2016 21:58, Chris Angelico wrote:
I don't exactly see how stub files would be any different than tests in this regard. Unless I am totally misunderstanding something, the type hints only exist to make static analysis by tools (presumably in a test suite) easier. Why would a failing static analysis check go unnoticed and not the a test? Why is there no argument to integrate the test suite into the module under test, by the same logic? When documentation does not get updated to reflect the reality of the code, a test run does not fail, a task does not turn red in CI, tools don't return non-zero. If you care about type-hints, keeping hints in stub files, and not updating those stubs, breaks things. Why muck up the code for people who don't care about type hints?
On Sun, Mar 20, 2016 at 1:21 PM, Alexander Walters <tritium-list@sdamon.com> wrote:
There are - look at things like doctest. However, tests tend to be much longer-winded than type hints - even the most verbose of type hints - so the cost of keeping them inline is far higher. The benefits are similar, though. ChrisA
On Sun, Mar 20, 2016 at 01:29:36PM +1100, Chris Angelico wrote:
In my experience, for every line of code I write, I will end up with ten lines of tests. Keeping *all* my tests in the same file as the code being tested would completely overwhelm the actual code. Nevertheless, it is appropriate to include some tests in place with the code: - doc tests, as Chris mentions above; - some applications may include a short "self-test" that the user can run from the command line to verify that it is working; - we might consider assertions as a kind of run time internal consistency test; - some languages have support for integrating tests in your code. For example, Eiffel makes extensive use of Design By Contract for testing, with "require", "ensure" and "invariant" keywords. https://archive.eiffel.com/doc/online/eiffel50/intro/language/invitation-07.... Rust allows you to mark a function as test code by annotating it with the "test" attribute. http://static.rust-lang.org/doc/master/book/testing.html D can integrate the function and its unit test in the same piece of code: http://dlang.org/spec/unittest.html Cobra includes both contracts and in-place unit tests: http://cobra-language.com/docs/quality/ -- Steve
On Mar 19, 2016, at 18:34, Rick Johnson <rantingrickjohnson@gmail.com> wrote:
That would definitely turn me off the feature. In practice, I've found that, at least for me, the largest benefit of PEP 484 has come from documenting interfaces. There are a reasonable fraction of cases where a name and type for each parameter is enough to understand the use of a function, but a name alone isn't. Of course there are other cases where the types get in the way--so I just don't specify them there. This shouldn't be too surprising--ML, Haskell, etc. users have long known that sometimes it aids readability to explicitly declare a type even when the inference engine makes it unnecessary. Why should it be any different when dynamic typing always makes it unnecessary? Anyway, if stub files were the only way to specify types, PEP 484 would probably still be useful for some people, as in Dropbox's project, but it would be a lot less interesting to me.
On 20 March 2016 at 06:14, Rick Johnson <rantingrickjohnson@gmail.com> wrote:
The fact we've been down this road before, especially with the introduction of ABCs (much of the fearful rhetoric around PEP 484 bears a striking similarity to that around PEP 3119 nigh on a decade ago). If the Python community were going to go overboard with explicit type hints, we'd already see a large proportion of projects running pylint with very strict configuration settings, or using the existing typechecking tools like Google's pytypedecl. However, that's precisely what we *don't* see - instead we see folks using those capabilities responsibly, adopting them when the complexity of their project or organisational structure calls for it, and omitting them otherwise. (And many of the folks that don't have the relevant problems remain puzzled as to why these tools that help improve maintainability for large projects and large teams exist in the first place) The fear response of "other people are going to overuse these, which means *I'm* going to have to read a lot of code containing them, which means programming in Python is going to become less fun" is perfectly understandable, but isn't really backed up by the community's collective behavioural history. (Monkeypatching, multiple inheritance and metaclasses are other capabilities that fall into a similar category - really powerful, and when you need them, you're grateful they're there, but best avoided when you don't have a genuine need for them) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
I tried to be calm about asking the tone to be turned down on this topic, but I feel like I wasn't listened to, so consider this your *official warning, Rick*: *stop the bombastic, insulting tone or you will be banned*. It is not considerate or respectful to call type hints an "abortion of readability" and claim we are suffering from "an identity crisis" thanks to this "philosophical perversion" brought on by this "type-hint nightmare". Plenty of people on this list had a thorough, cordial discussion on this topic long before you joined it and you do not have the right to come here and suddenly start disparaging their hard work (not to mention those people who aren't on this list who also participated in the discussion and eventual implementation). If type hints upset you that much you are welcome to not use Python anymore and "go running back into the loving arms of Java" if you prefer. I'm also asking everyone to consider this discussion of removing type hints dead, so please be respectful of other people's time and don't reply to this thread. On Sat, 19 Mar 2016 at 13:15 Rick Johnson <rantingrickjohnson@gmail.com> wrote:
On Sunday, March 20, 2016 at 12:37:48 PM UTC-5, Brett Cannon wrote:
Hello Brett (and all Group Members), Since it had become obvious to me, that the emotions surrounding this subject-matter present a high probability of turning toxic, I had made the decision to drop this thread last night -- there is no need for me to continually beat this dead horse, the community has made its decision. At this time, i want to thank everyone who participated, especially those who offered constructive replies. Also, I want everyone to know that my objections to type-hints are not exclusively based on emotion, no, I am still convinced that type-hints (as implemented) has the potential to undermine the very essence of what makes Python unique among all other languages -- but that's just my opinion, feel free to ignore if you don't agree. Out of respect for those who have so graciously volunteered their time to implement this feature, i pledge that i will not express my reservations regarding type-hints in this group *EVER* again. However, i will be composing a thoughtful and exhaustive dissent (regarding type-hints) and posting it publicly very soon. If anyone shares my reservations of type-hints (as implemented), please do not reply here, instead, contact me via email, so that we may discuss these matters privately. And as always, any discussions with me are 100% confidential. Thanks all And Happy Pythoning!
On Sun, 20 Mar 2016 at 13:35 Rick Johnson <rantingrickjohnson@gmail.com> wrote:
Thank you for recognizing that your emotions were getting the better of you. But please do realize, Rick, that the warning does stand and it is not relegated to just this discussion thread, so please take the time in the future to think through your emails to this list before you send them as I would prefer to not have to ban you (or anyone else for that matter; banning people is a bit stressful for me as I don't exactly enjoy that responsibility, but I will deal with the stress if I feel anyone causes people to dread reading emails from this list due to their behaviour). -Brett
On 3/18/2016 3:09 PM, Guido van Rossum wrote:
It's a mix. The list of things I definitely want to get to is now here: https://github.com/python/typing/milestones/3.5.2
#2: backport aab2c59 to python2/typing.py I believe you are referring to a back-compatibility module on PyPI. If so, this is out-of-scope for python-ideas. The only connection with 3.5.2 is that 2.7.12 should come out about the same time. #3, #1: many parameters require long comment signature? These are a question and possible solution for the type comments intended for 2.7 (though allowed, I believe, in 3.5 and earlier with the back-compatibility module). The issue: some functions have so many parameters that a type comment will not fit on one line. A proposal discussed here before is multiline type comments. The alternate solution is to allow '...' as an abbreviation. My very slight objection is that this will mean that the type comment no longer matches the function signature above. The counter-argument is that duplicating a long parameter type list, especially when one only cares about typing the return type, is obnoxious. I presume this proposal is based on problems with real code. + something. I do not understand, in #3, "Would it be valid to annotate just a few argument [and use ... also, I presume]? and "Yes". What would it look like? Is that part of #1? #4 Ambiguity of "Z = Dict[T, int]". I don't understand enough to understand the 2nd interpretation, so 'pass'. Ambiguity is bad, though. #5 A proposal to allow 'Type[T]'? Where "T = TypeVar['T']"? Just unpostponed from last May. #6 "What does it mean to inherit from a generic type without specifying type parameters?" I am not clear on what patch is being proposed. This seems to still be in ideas stage. #7 Allow @overload in implementation as well as stub files. You originally rejected this, then reopened in January with discussion here and pydev. Is more discussion needed? Final votes on pydev? -- Terry Jan Reedy
On Fri, 18 Mar 2016 at 11:57 Terry Reedy <tjreedy@udel.edu> wrote:
That's basically the rule of them I take. Basically I view python-ideas as the place to start the question of "is this a good idea or is it bonkers?" Once you know that answer you either take to python-dev or drop it. And as a core dev you can use your own judgment as to whether you need the extra step of discussing it here first and instead bypass this list.
Since 3.5.1 came out in December I would expect either at or after PyCon US. Larry is RM so he's the only one that really knows.
participants (14)
-
Alexander Walters -
Andrew Barnert -
Brett Cannon -
Chris Angelico -
Ethan Furman -
Guido van Rossum -
Guido van Rossum -
Mark Lawrence -
Nick Coghlan -
Paul Moore -
Rick Johnson -
Ryan Gonzalez -
Steven D'Aprano -
Terry Reedy