(a2 + b2 = c2) = (e < | > P a P b P c) Beschreibt eine Disonanz in Genese. ---------- Weitergeleitete Nachricht ---------- Von: <python-list-requ...@python.org> Datum: 30.06.2012 23:09 Betreff: Python-list Digest, Vol 106, Issue 1 An: <python-list@python.org>
Send Python-list mailing list submissions to python-list@python.org To subscribe or unsubscribe via the World Wide Web, visit http://mail.python.org/mailman/listinfo/python-list or, via email, send a message with subject or body 'help' to python-list-requ...@python.org You can reach the person managing the list at python-list-ow...@python.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Python-list digest..." Today's Topics: 1. Re: code review (Alister) 2. Re: code review (Alister) 3. Re: code review (Thomas Jollans) 4. Re: code review (Alain Ketterlin) 5. Re: code review (Thomas Jollans) 6. Re: tiffany 0.6.1 released (Christian Heimes) 7. Re: code review (Terry Reedy) 8. Re: code review (Martin P. Hellwig) 9. Re: code review (Thomas Jollans) 10. Re: code review (Alain Ketterlin) ---------- Weitergeleitete Nachricht ---------- From: Alister <alister.w...@ntlworld.com> To: python-list@python.org Cc: Date: Sat, 30 Jun 2012 20:25:39 GMT Subject: Re: code review On Sat, 30 Jun 2012 12:29:31 +0200, Peter Otten wrote: > Alister wrote: > >> I think I may be on firmer grounds with the next few: >> >> isValidPassword can be simplified to >> >> def isValidPassword(password: >> count=len(password) >> return count>= mud.minpass and count<= mud.maxpass >> >> ( I used count to save finding the length of password twice although it >> probably makes no difference in this scenario) > > If you spell it > > def is_valid_password(password): > return mud.minpass <= len(password) <= mud.maxpass > > it is even easier to see that you are performing an interval check. I realise that was possible, that is brilliant! it is exactly how you would write it ass a mathematical definition. -- "The only real way to look younger is not to be born so soon." -- Charles Schulz, "Things I've Had to Learn Over and Over and Over" ---------- Weitergeleitete Nachricht ---------- From: Alister <alister.w...@ntlworld.com> To: python-list@python.org Cc: Date: Sat, 30 Jun 2012 20:30:45 GMT Subject: Re: code review On Sat, 30 Jun 2012 21:38:58 +0200, Thomas Jollans wrote: > On 06/30/2012 08:39 PM, Thomas 'PointedEars' Lahn wrote: >> Peter Otten wrote: >> >>> If you spell it >>> >>> def is_valid_password(password): >>> return mud.minpass <= len(password) <= mud.maxpass >>> >>> it is even easier to see that you are performing an interval check. >> >> This is probably a tautology around here, but *what* *a* *great* >> *programming* *language*. >> >> > Personally, I don't like this feature of the language. I find a ternary > operator that uses symbols that can also be binary operators confusing > and inconsistent with the way operators usually work/the way terms are > usually associated. > > It has the charm of being something you'd "naturally" write in the > context of non-programming mathematics, at the cost of being very odd > indeed in the context of programming in general and Python in > particular. Surely this fits perfectly with the lines 1 & 7 in the zen of python (import this) "Beautifull is better than ugly" and "Readability counts" I find that construct both beautiful and readable, if it cannot be used in the languages then that is their loss. -- Removing the straw that broke the camel's back does not necessarily allow the camel to walk again. ---------- Weitergeleitete Nachricht ---------- From: Thomas Jollans <t...@jollybox.de> To: python-list@python.org Cc: Date: Sat, 30 Jun 2012 22:50:43 +0200 Subject: Re: code review On 06/30/2012 10:30 PM, Alister wrote: > On Sat, 30 Jun 2012 21:38:58 +0200, Thomas Jollans wrote: > >> On 06/30/2012 08:39 PM, Thomas 'PointedEars' Lahn wrote: >>> Peter Otten wrote: >>> >>>> If you spell it >>>> >>>> def is_valid_password(password): >>>> return mud.minpass <= len(password) <= mud.maxpass >>>> >>>> it is even easier to see that you are performing an interval check. >>> >>> This is probably a tautology around here, but *what* *a* *great* >>> *programming* *language*. >>> >>> >> Personally, I don't like this feature of the language. I find a ternary >> operator that uses symbols that can also be binary operators confusing >> and inconsistent with the way operators usually work/the way terms are >> usually associated. >> >> It has the charm of being something you'd "naturally" write in the >> context of non-programming mathematics, at the cost of being very odd >> indeed in the context of programming in general and Python in >> particular. > > Surely this fits perfectly with the lines 1 & 7 in the zen of python > (import this) > "Beautifull is better than ugly" and "Readability counts" > > I find that construct both beautiful and readable, if it cannot be used > in the languages then that is their loss. Are we quoting the Zen now? Contra: In re usual operator rules: "Special cases aren't special enough to break the rules." Which of the two comparisons is done first anyway? "In the face of ambiguity, refuse the temptation to guess." Speaking of two comparisons, no "and"! "Explicit is better than implicit." Then again, pro: "Beautiful is better than ugly." "Readability counts." "[Although] practicality beats purity." I can see the appeal. It's quite elegant in and of itself. However, I find that in the context of the whole Python language, it's a bit of a glitch and reduces elegance. (I'm probably in the minority on this one) ---------- Weitergeleitete Nachricht ---------- From: Alain Ketterlin <al...@dpt-info.u-strasbg.fr> To: python-list@python.org Cc: Date: Sat, 30 Jun 2012 23:07:41 +0200 Subject: Re: code review Thomas Jollans <t...@jollybox.de> writes: >>>>> def is_valid_password(password): >>>>> return mud.minpass <= len(password) <= mud.maxpass > Which of the two comparisons is done first anyway? > "In the face of ambiguity, refuse the temptation to guess." There is no ambiguity. See the language reference: "Formally, if a, b, c, ..., y, z are expressions and op1, op2, ..., opN are comparison operators, then a op1 b op2 c ... y opN z is equivalent to a op1 b and b op2 c and ... y opN z, except that each expression is evaluated at most once." The last restriction (single evaluation of involved expressions) makes this a bit more than raw syntactic sugar. -- Alain. ---------- Weitergeleitete Nachricht ---------- From: Thomas Jollans <t...@jollybox.de> To: python-list@python.org Cc: Date: Sat, 30 Jun 2012 23:35:19 +0200 Subject: Re: code review On 06/30/2012 11:07 PM, Alain Ketterlin wrote: > Thomas Jollans <t...@jollybox.de> writes: > >>>>>> def is_valid_password(password): >>>>>> return mud.minpass <= len(password) <= mud.maxpass > >> Which of the two comparisons is done first anyway? >> "In the face of ambiguity, refuse the temptation to guess." > > There is no ambiguity. See the language reference: Of course it's technically clearly defined, but the syntax isn't explicit. To know what the order is (or whether there is an order!) one has to consult the language reference (which shouldn't be necessary), or make an educated guess, which would almost certainly be correct, but we're supposed to refuse the temptation to guess, right? > "Formally, if a, b, c, ..., y, z are expressions and op1, op2, ..., opN > are comparison operators, then a op1 b op2 c ... y opN z is equivalent > to a op1 b and b op2 c and ... y opN z, except that each expression is > evaluated at most once." > > The last restriction (single evaluation of involved expressions) makes > this a bit more than raw syntactic sugar. ---------- Weitergeleitete Nachricht ---------- From: Christian Heimes <li...@cheimes.de> To: python-list@python.org Cc: Date: Sat, 30 Jun 2012 23:35:31 +0200 Subject: Re: tiffany 0.6.1 released Am 30.06.2012 18:25, schrieb Paul Rubin: > Christian Tismer <tis...@stackless.com> writes: >> Tiffany stands for any tiff. The tiny module solves a large set of >> problems, has no dependencies and just works wherever Python works. >> Tiffany was developed in the course of the *DiDoCa* project and will >> always appear on PyPi. > > This sounds pretty neat. I didn't comment on it earlier because I > haven't tried it out, since I haven't had occasion to deal with tiff > files anytime recently. But I've had to process them for some projects > in the past, and tiffany would have been useful then. It's good to know > that it's out there. I've developed smc.freeimage exclusively to process large amounts of TIFF images. I estimate that we have processed more than twelve million unique TIFF images with about half a petabyte of data. The packages uses Cython to wrap FreeImage (containing libtiff, libpng, libjpeg, libraw and more) and LittleCMS2. The package is mostly fitted to our needs, a bit limited (e.g. no conversion of CMYK to RGB with color management) and doesn't follow recent best practices for Cython code, but it does it job well. I need to clean up the code base some day when more people get interested in the lib. Christian ---------- Weitergeleitete Nachricht ---------- From: Terry Reedy <tjre...@udel.edu> To: python-list@python.org Cc: Date: Sat, 30 Jun 2012 17:47:55 -0400 Subject: Re: code review On 6/30/2012 5:35 PM, Thomas Jollans wrote: > On 06/30/2012 11:07 PM, Alain Ketterlin wrote: > >> Thomas Jollans <t...@jollybox.de> writes: >> >> def is_valid_password(password): >>>>>>> return mud.minpass <= len(password) <= mud.maxpass >>>>>>> >>>>>> >> Which of the two comparisons is done first anyway? >>> "In the face of ambiguity, refuse the temptation to guess." >>> >> >> There is no ambiguity. See the language reference: >> > > Of course it's technically clearly defined, but the syntax isn't > explicit. To know what the order is (or whether there is an order!) one > has to consult the language reference (which shouldn't be necessary), or > make an educated guess, which would almost certainly be correct, but > we're supposed to refuse the temptation to guess, right? > Python pretty consistently evaluates expressions and equal precedence operators left to right. One really should learn that. No 'implementation defined' ambiguity. -- Terry Jan Reedy ---------- Weitergeleitete Nachricht ---------- From: "Martin P. Hellwig" <martin.hell...@gmail.com> To: python-list@python.org Cc: Date: Sat, 30 Jun 2012 14:48:16 -0700 (PDT) Subject: Re: code review On Saturday, 30 June 2012 21:30:45 UTC+1, Alister wrote: > On Sat, 30 Jun 2012 21:38:58 +0200, Thomas Jollans wrote: > > > On 06/30/2012 08:39 PM, Thomas 'PointedEars' Lahn wrote: > >> Peter Otten wrote: > >> > >>> If you spell it > >>> > >>> def is_valid_password(password): > >>> return mud.minpass <= len(password) <= mud.maxpass > >>> <cut> > Surely this fits perfectly with the lines 1 & 7 in the zen of python > (import this) > "Beautifull is better than ugly" and "Readability counts" > Agree, however I like to stress the "don't make me unnecessary read with care" rule. Meaning if I read that line, I have to read it carefully to make sure I understand what is happening, the following would not do that although syntax wise equal: def length_between_min_max(password): return(mud.minpass <= len(password) <= mud.maxpass) def is_valid_password(password): valid = True if not length_between_max_min(password): valid = False if some_other_test(password): valid = False return(valid) This I can read, typically I would not even read what the function length_beteen_max_min does as long as there is no bug in it because, it is perfectly english clear what the intention is. -- mph ---------- Weitergeleitete Nachricht ---------- From: Thomas Jollans <t...@jollybox.de> To: python-list@python.org Cc: Date: Sun, 01 Jul 2012 00:05:26 +0200 Subject: Re: code review On 06/30/2012 11:47 PM, Terry Reedy wrote: > On 6/30/2012 5:35 PM, Thomas Jollans wrote: >> On 06/30/2012 11:07 PM, Alain Ketterlin wrote: >>> Thomas Jollans <t...@jollybox.de> writes: >>> >>>>>>>> def is_valid_password(password): >>>>>>>> return mud.minpass <= len(password) <= mud.maxpass >>> >>>> Which of the two comparisons is done first anyway? >>>> "In the face of ambiguity, refuse the temptation to guess." >>> >>> There is no ambiguity. See the language reference: >> >> Of course it's technically clearly defined, but the syntax isn't >> explicit. To know what the order is (or whether there is an order!) one >> has to consult the language reference (which shouldn't be necessary), or >> make an educated guess, which would almost certainly be correct, but >> we're supposed to refuse the temptation to guess, right? > > Python pretty consistently evaluates expressions and equal precedence > operators left to right. Yes. My sole point, really, is that "normally", one would expect these two expressions to be equivalent: a < b < c (a < b) < c This is clearly not true. That's the inconsistency here with the rest of the language. As soon as you read it as a ternary operator, the two comparisons are logically simultaneous. Doing the left hand comparison first is clearly the intuitive thing to do, but it's still, strictly speaking, arbitrary. Intuitive, clearly defined, but arbitrary. The ternary conditional operator is a different beast because its sub-operators "if" and "else" aren't also binary operators, so it's obvious that it's parsed differently. > One really should learn that. No > 'implementation defined' ambiguity. ---------- Weitergeleitete Nachricht ---------- From: Alain Ketterlin <al...@dpt-info.u-strasbg.fr> To: python-list@python.org Cc: Date: Sun, 01 Jul 2012 01:03:14 +0200 Subject: Re: code review Thomas Jollans <t...@jollybox.de> writes: > On 06/30/2012 11:47 PM, Terry Reedy wrote: >>>>>>>>> def is_valid_password(password): >>>>>>>>> return mud.minpass <= len(password) <= mud.maxpass >>>> >>>>> Which of the two comparisons is done first anyway? >>>>> "In the face of ambiguity, refuse the temptation to guess." >>>> >>>> There is no ambiguity. See the language reference: >>> Of course it's technically clearly defined, but the syntax isn't >>> explicit. >> Python pretty consistently evaluates expressions and equal precedence >> operators left to right. > > Yes. My sole point, really, is that "normally", one would expect these > two expressions to be equivalent: > > a < b < c > (a < b) < c > > This is clearly not true. That's the inconsistency here with the rest of > the language. No, comparison operators are different from arithmetic operators in that they always evaluate to a boolean. There are only rare cases where it makes sense to compare comparisons. > As soon as you read it as a ternary operator, the two comparisons are > logically simultaneous. There is no ternary operator, you can chain as many as you want, using whatever operators: if a <= b < c > d >= e: ... Once you view this as a conjonction of conditions, you find back the semantics of "and": short-circuit, left to right evaluation. I find this consistent. -- Alain. -- http://mail.python.org/mailman/listinfo/python-list
-- http://mail.python.org/mailman/listinfo/python-list