tag:blogger.com,1999:blog-9266717.post3464233689147799477..comments2023-05-22T10:01:23.167-03:00Comments on Only Python: Type hinting in Python: focus on readabilityAndré Robergehttp://www.blogger.com/profile/08131391818998844540noreply@blogger.comBlogger15125tag:blogger.com,1999:blog-9266717.post-50755316998823125502016-08-26T11:43:06.724-03:002016-08-26T11:43:06.724-03:00You are absolutely right. PEP484 was a bad idea, a...You are absolutely right. PEP484 was a bad idea, and it attracts all the wrong people (e.g. Java folks who seem to think it's a good practice to type-hint _every_ single argument on _every_ method), then complain about the runtime not asserting the types and raising exceptions. Take this one step further and we will not only have less readable programs but also another incompatible Python version. IMO PEP484 is just another good reason not to engage with Python 3...miraculixxhttps://www.blogger.com/profile/14786798776197260447noreply@blogger.comtag:blogger.com,1999:blog-9266717.post-20539169208105181332016-02-27T11:46:27.530-04:002016-02-27T11:46:27.530-04:00I like the syntax also but why use a new keyword? ...I like the syntax also but why use a new keyword? May be use something like :<br />def foo (a, b):<br />as:<br /> a:int<br /> b:float<br /> return:float<br />Anonymoushttps://www.blogger.com/profile/17189270286578268039noreply@blogger.comtag:blogger.com,1999:blog-9266717.post-19353731343332800502015-02-02T06:07:13.284-04:002015-02-02T06:07:13.284-04:00I like the syntax, but I am unsure... is it compat...I like the syntax, but I am unsure... is it compatible with the python parser fundamentals?Stefano Borinihttps://www.blogger.com/profile/04360872907775395809noreply@blogger.comtag:blogger.com,1999:blog-9266717.post-86757696319553574172015-02-01T18:08:19.246-04:002015-02-01T18:08:19.246-04:00I've only ever used vim or PyCharm as editors ...I've only ever used vim or PyCharm as editors and I'm fairly certain each of them could be programmed to handle it. As for purely indent-based folders, I believe this would still work and would be syntactically identical:<br /><br />def retry(callback, timeout, retries=None)<br />........where <br />............callback is Callable[AnyArgs, Any[int, None]], <br />............timeout is Any[int, None], <br />............retries is in [int, None],<br />............return is None:<br />....passBenjaminhttps://www.blogger.com/profile/11979252184749589064noreply@blogger.comtag:blogger.com,1999:blog-9266717.post-67494494010933743142015-02-01T16:17:35.472-04:002015-02-01T16:17:35.472-04:00@Benjamin:
I like your version; in some ways, it ...@Benjamin:<br /><br />I like your version; in some ways, it is cleaner than mine. The one relatively minor drawback is that, with your version, it becomes impossible for code-folding (which is driven by indentation in all editors I have used) to be used to hide the type declaration.André Robergehttps://www.blogger.com/profile/08131391818998844540noreply@blogger.comtag:blogger.com,1999:blog-9266717.post-16072630272672805482015-02-01T06:15:57.487-04:002015-02-01T06:15:57.487-04:00Please pardon the spam, but I thought of more refi...Please pardon the spam, but I thought of more refinement when I was composing the following message to python-dev:<br /><br />The proposed syntax is abominable. It's the opposite of readable.<br /><br />The function annotation syntax is ugly, but potentially useful for things like documentation. While it may very well have been created with the idea of type-checking, actually using it for such quickly turns into an unreadable morass of information that is far more difficult for human brains to parse, which makes this usage the antithesis of pythonic.<br /><br />I much prefer the idea of a 'where' keyword to denote typing, as discussed [here], but I think a refinement of their idea would prove even better:<br /><br />def retry(callback, timeout, retries=None) where <br />........callback is Callable[AnyArgs, Any[int, None]], <br />........timeout is Any[int, None], <br />........retries is in [int, None], # 'is in' construct is more readable, dunno about complexity<br />........return is None:<br />....pass<br /><br />def greeting(name) where name is str, return is str:<br />....return 'Hello ' + name<br /><br />x, y = [], [] where x, y is List[Employee], List[Manager]<br /><br />To me, this orders of magnitude more readable than the proposed nonsense.<br /><br />PS. Obviously the 8-space indent above would only a convention, not requirement.Benjaminhttps://www.blogger.com/profile/11979252184749589064noreply@blogger.comtag:blogger.com,1999:blog-9266717.post-52071428034526641352015-02-01T05:37:14.589-04:002015-02-01T05:37:14.589-04:00I wholly agree that the proposed syntax is abomina...I wholly agree that the proposed syntax is abominable. It's the opposite of readable. I do really like the idea of a 'where' keyword to denote typing, but I think a slight refinement of your idea would prove even better:<br /><br />def retry(callback, timeout, retries=None) where <br />........callback: Callable[AnyArgs, Any[int, None]], <br />........timeout: Any[int, None], <br />........retries: Any[int, None],<br />........return None:<br />....pass<br /><br />def greeting(name) where name: str, return str:<br />....return 'Hello ' + name<br /><br />x = [] where x: List[Employee]<br /><br />To me, this orders of magnitude more readable than the proposed nonsense.<br /><br />PS. Note the 8-space indent above would only a convention, not requirement.Benjaminhttps://www.blogger.com/profile/11979252184749589064noreply@blogger.comtag:blogger.com,1999:blog-9266717.post-78103228228875514652015-01-30T22:25:02.822-04:002015-01-30T22:25:02.822-04:00@Jose: I agree that the where block does not (in p...@Jose: I agree that the where block does not (in principle) need to be overindented; however, it was required by my editor so that I could use code-folding to hide it.<br /><br />As to the exact way the types are declared: I figured that I should use the same as in the PEP since the point was to illustrate that the code could be made more readable if the type information was put in a code block rather than mixed in with the function arguments.André Robergehttps://www.blogger.com/profile/08131391818998844540noreply@blogger.comtag:blogger.com,1999:blog-9266717.post-59978557337516176312015-01-30T22:21:34.542-04:002015-01-30T22:21:34.542-04:00I like it. Just one thing, where: doesn't need...I like it. Just one thing, where: doesn't need to be over-indented. It could be a simple block keyword/instruction.<br /><br />Another thing I would like to see is a more coherent way of indicating types, like Any(list(str), int) or function(float, float, float). Anonymoushttps://www.blogger.com/profile/15730779978022115418noreply@blogger.comtag:blogger.com,1999:blog-9266717.post-46491246378129390262015-01-30T19:42:45.946-04:002015-01-30T19:42:45.946-04:00I have two very, very small problems with this pro...I have two very, very small problems with this proposal. Mind you, I am far from a Python expert.<br /><br />Python is coded in blocks to make it easy to differentiate one block from another, and it works just fine. There is no need nest the type definitions two levels further from the rest of the function. It breaks current syntax for no good reason.<br /><br />I also don't like that with this syntax, type definitions go from being expressions into statements. I feel as though as a Python statement should do something to affect the running program. I don't see a good workaround to that though, and your proposal is far superior to the proposed PEP.Zim the Foxhttps://www.blogger.com/profile/00380237996966208326noreply@blogger.comtag:blogger.com,1999:blog-9266717.post-46530872159579072422015-01-30T15:39:47.703-04:002015-01-30T15:39:47.703-04:00I am not sure what the original proposal is but fo...I am not sure what the original proposal is but for somebody like me who codes in other languages as well, why can't we have a syntax like below:<br /><br />def foo(str: x) -> str:<br /><br />why the following is proposed:<br /><br />def foo(x: str) -> str:<br /><br />To me the first syntax makes more sense.Anonymoushttps://www.blogger.com/profile/08218557138141770089noreply@blogger.comtag:blogger.com,1999:blog-9266717.post-54369677876036789612015-01-30T12:32:23.484-04:002015-01-30T12:32:23.484-04:00+1, it's kind of like decorators and bolts ont...+1, it's kind of like decorators and bolts onto the language instead of trying to change it. Along the wins, pylint can be easily extended to parse this, and the errors won't all have the same line numbers.Adam Sahhttps://www.blogger.com/profile/16436979948144941515noreply@blogger.comtag:blogger.com,1999:blog-9266717.post-84244548257708370272015-01-30T05:00:09.274-04:002015-01-30T05:00:09.274-04:00In the examples your proposal looks better than th...In the examples your proposal looks better than the mypy style.<br /><br />Still, if you add a sphinx docstring, both seems to add redundancy.<br /><br />I guess I would prefer a clean signature with a sensible annotation in the docstring.<br /><br />Cheers, and thanks for sharing.claudio canepahttps://www.blogger.com/profile/07607460284839405974noreply@blogger.comtag:blogger.com,1999:blog-9266717.post-80970497182379916712015-01-29T19:54:15.916-04:002015-01-29T19:54:15.916-04:00Thank you.Thank you.André Robergehttps://www.blogger.com/profile/08131391818998844540noreply@blogger.comtag:blogger.com,1999:blog-9266717.post-28324943113132743892015-01-29T19:49:32.177-04:002015-01-29T19:49:32.177-04:00Your proposal seems so much more pythonic than the...Your proposal seems so much more pythonic than the PEP proposals. The stuff they are showing looks like someone is trying to remake python in the image of go or c.dweldenhttps://www.blogger.com/profile/12641765782723140213noreply@blogger.com