tag:blogger.com,1999:blog-9266717.post110548009358563306..comments2023-05-22T10:01:23.167-03:00Comments on Only Python: Teaching an old Python keyword new tricksAndré Robergehttp://www.blogger.com/profile/08131391818998844540noreply@blogger.comBlogger12125tag:blogger.com,1999:blog-9266717.post-1105667627231423982005-01-13T21:53:00.000-04:002005-01-13T21:53:00.000-04:00To Anonymous who wrote:
What's really missing in p...To Anonymous who wrote:<br />What's really missing in python today?<br /><br />01 def gcd(a, b):<br />02 ____'''Returns the Greatest Common Divisor,<br />03 ____implementing Euclid's algorithm.<br />04 ____Input arguments must be integers;<br />05 ____return value is an integer.'''<br />06 ____assert isinstance(a, types.IntType)<br />07 ____assert isinstance(b, types.IntType)<br />====<br />This series of 3 posts was prompted by Guido van Rossum's musings about adding optional static typing and related features, with a proposed syntax that many people, including myself, found "non-pythonic". Of course, the simple example I used can be done, as you've shown explictly, with python's actual syntax. However, the features suggested by GvR require some fundamental change. I was just trying to contribute in my own way by suggesting a "more pythonic" syntax that could act as a bridge between Python as it is today and how it could become with static typing, interfaces, etc. <br />By all means, if you can show how GvR's suggestions could be implemented "nicely" using today's Python, I am sure that many people would be interested. (Let me emphasized that I do NOT write this to be sarcastic.) I am trying to generate a constructive "debate" with all those interested.André Robergehttps://www.blogger.com/profile/08131391818998844540noreply@blogger.comtag:blogger.com,1999:blog-9266717.post-1105650660908496792005-01-13T17:11:00.000-04:002005-01-13T17:11:00.000-04:00What's really missing in python today?
01 def gcd...What's really missing in python today?<br /><br />01 def gcd(a, b):<br />02 ____'''Returns the Greatest Common Divisor,<br />03 ____implementing Euclid's algorithm.<br />04 ____Input arguments must be integers;<br />05 ____return value is an integer.'''<br />06 ____assert isinstance(a, types.IntType)<br />07 ____assert isinstance(b, types.IntType)<br />08 ____while a:<br />09 ________a, b = b%a, a<br />10 ____assert isinstance(b, types.IntType)<br />11 ____return b<br /><br />That keeps the return value assertion close to the return statement, where it belongs. If you want some explanatory text in the exception object then raise one explicitly as in:<br /><br />06 ____if not (isinstance(a, types.IntType) 07 _______and isinstance(b, types.IntType)):<br />08 ________raise TypeError("GCD applies to pairs of integers.")<br /><br />or <br /><br />10 ____if not isinstance(b, types.IntType)"<br />11 ________raise TypeError("GCD was supposed to produce an integer.")<br /><br />Already, I tend to liberally sprinkle my code with assert statements, often simply as a reminder to myself but also as a form of test-driven development or design by contract (I write the assertions first, then fill in the program logic).Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-9266717.post-1105560459967701372005-01-12T16:07:00.000-04:002005-01-12T16:07:00.000-04:00which way?
assert:
....a:int or raise "must be a ...which way?<br /><br />assert:<br />....a:int or raise "must be a number"<br />....((a > 0 and b < 5) or a < -2) or raise "some business logic description"<br /><br />or ?<br /><br />assert:<br />....a:int<br />....(a > 0 and b < 5) or a < -2<br />except TypeError:<br />....raise "must be a number"<br />except AssertionError:<br />....raise "some business logic description"Gheorghehttps://www.blogger.com/profile/16345214304445028131noreply@blogger.comtag:blogger.com,1999:blog-9266717.post-1105559554821902942005-01-12T15:52:00.000-04:002005-01-12T15:52:00.000-04:00regarding error description maybe:
isinstance(a, i...regarding error description maybe:<br />isinstance(a, int) or raise "Must be a number"<br />a: int or raise "Must be a number"<br />a<0 or raise "Must be less the zero"<br />But then will this look ugly ?:<br />((a>0 and b<5) or a < -2) or raise "whatever business logic description"Gheorghehttps://www.blogger.com/profile/16345214304445028131noreply@blogger.comtag:blogger.com,1999:blog-9266717.post-1105548651569790432005-01-12T12:50:00.000-04:002005-01-12T12:50:00.000-04:00I don't like the way that your syntax requires a d...I don't like the way that your syntax requires a double set of indentation though I can see how it arises from the need to specify a name for the return value. I would find this easier to read (with dots to represent the indentation as the spaces seem to be stripped out :-/):<br /><br />assert:<br />....isinstance(a, int)<br />....isinstance(b, int)<br />....a != b # or whatever<br />assert return c:<br />....isinstance(c, int)<br />....c != 0<br /><br />But I'm still not sure that I like it!Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-9266717.post-1105547781628233862005-01-12T12:36:00.000-04:002005-01-12T12:36:00.000-04:00I *very* much like the "isinstance(a, int)" form o...I *very* much like the "isinstance(a, int)" form of this. It is, I feel, *far* more pythonic in nature: very explicit, and when read aloud does not require any innate knowledge of the language. It does what it says.<br /><br />It is also probably wordy enough to encourage people to *not* use static typing, which *should* be one of the design goals. There are few cases where static typing is required, ergo it should be less easy to do than leaving things dynamic.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-9266717.post-1105535073263084982005-01-12T09:04:00.000-04:002005-01-12T09:04:00.000-04:00Sorry but I'm only another (anonymous french) Alex...Sorry but I'm only another (anonymous french) Alex even quite new to the python language.<br />AlexAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-9266717.post-1105531488448656452005-01-12T08:04:00.000-04:002005-01-12T08:04:00.000-04:00Alex? By tone and content of the previos comment I...Alex? By tone and content of the previos comment I have the nagging suspicion this might be Alex Martelli speaking... In this case, use your power and draw <br />Guido's attention to this well-balanced syntax proposal, Alex!Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-9266717.post-1105524440076231032005-01-12T06:07:00.000-04:002005-01-12T06:07:00.000-04:00Interesting how having a more pythonic syntax make...Interesting how having a more pythonic syntax makes the static typing looks more optionnal, more acceptable and opens towards a different design perspective.<br />AlexAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-9266717.post-1105522755465050422005-01-12T05:39:00.000-04:002005-01-12T05:39:00.000-04:00Regarding where an error message might go, could e...Regarding where an error message might go, could each line of the assertion block not have an optional error message separated by a comma, similar to what the existing assert statement does?Hamishhttps://www.blogger.com/profile/12600278259291466393noreply@blogger.comtag:blogger.com,1999:blog-9266717.post-1105483680345324212005-01-11T18:48:00.000-04:002005-01-11T18:48:00.000-04:00Hmmm to be honest, I didn't think about error mess...Hmmm to be honest, I didn't think about error messages. Good point... perhaps one needs an additional keyword (like "where") after all.. I'll have to think about that one!André Robergehttps://www.blogger.com/profile/08131391818998844540noreply@blogger.comtag:blogger.com,1999:blog-9266717.post-1105482833388310972005-01-11T18:33:00.000-04:002005-01-11T18:33:00.000-04:00I like the block syntax, but where does the error ...I like the block syntax, but where does the error message go? Sometimes that's not necessary, but for a lot of contract issues it's not entirely clear why the restriction exists without an explanation, and it's nice to suggest proper usage.Ian Bickinghttps://www.blogger.com/profile/10921115783730718101noreply@blogger.com