Fwd: Python-list Digest, Vol 106, Issue 1
Fabian Doerfler
rappeli82 at googlemail.com
Sun Jul 1 08:41:56 EDT 2012
(a2 + b2 = c2) = (e < | > P a P b P c)
Beschreibt eine Disonanz in Genese.
---------- Weitergeleitete Nachricht ----------
Von: <python-list-request at python.org>
Datum: 30.06.2012 23:09
Betreff: Python-list Digest, Vol 106, Issue 1
An: <python-list at python.org>
Send Python-list mailing list submissions to
python-list at 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-request at python.org
You can reach the person managing the list at
python-list-owner at 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.ware at ntlworld.com>
To: python-list at 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.ware at ntlworld.com>
To: python-list at 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 at jollybox.de>
To: python-list at 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 <alain at dpt-info.u-strasbg.fr>
To: python-list at python.org
Cc:
Date: Sat, 30 Jun 2012 23:07:41 +0200
Subject: Re: code review
Thomas Jollans <t at 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 at jollybox.de>
To: python-list at 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 at 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 <lists at cheimes.de>
To: python-list at 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 <tismer at 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 <tjreedy at udel.edu>
To: python-list at 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 at 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.hellwig at gmail.com>
To: python-list at 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 at jollybox.de>
To: python-list at 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 at 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 <alain at dpt-info.u-strasbg.fr>
To: python-list at python.org
Cc:
Date: Sun, 01 Jul 2012 01:03:14 +0200
Subject: Re: code review
Thomas Jollans <t at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20120701/b0538066/attachment.html>
More information about the Python-list
mailing list