On 2/10/11 7:34 PM, alex23 wrote:
> rantingrick wrote:
>> 1. When has 2 bytecode instructions EVER out weighed a solid
>> readability feature's incorporation into Python?
>
> The original point was whether or not the code is identical, which
> Terry showed it was not.
Rick does not understand wh
On Tue, 2011-02-08 at 21:52 -0800, Nanderson wrote:
> def num_digits(n):
> count = 0
> while n:
> count = count + 1
> n = n / 10
> return count
>
> This is a function that basically says how many digits are in a
> number. For example,
> >>>print num_digits(44)
> 2
> >>
rantingrick wrote:
> 1. When has 2 bytecode instructions EVER out weighed a solid
> readability feature's incorporation into Python?
The original point was whether or not the code is identical, which
Terry showed it was not.
> The load constant should only happen once. The
> COMPARE_OP could be
On Thu, 10 Feb 2011 12:01:57 -0500, Terry Reedy wrote:
> On 2/10/2011 11:52 AM, Ethan Furman wrote:
>> Jason Swails wrote:
>
>
>>> How is "while n != 0:" any worse?
>
> 1. It is redundant, just like 'if bool_value is not False:'. Python
> programmers should understand the null value idiom.
I f
On Thu, Feb 10, 2011 at 12:01 PM, Terry Reedy wrote:
> On 2/10/2011 11:52 AM, Ethan Furman wrote:
>
> Jason Swails wrote:
>>
>
>
> How is "while n != 0:" any worse?
>>>
>>
> 1. It is redundant, just like 'if bool_value is not False:'.
> Python programmers should understand the null value idiom.
On Feb 10, 11:01 am, Terry Reedy wrote:
> On 2/10/2011 11:52 AM, Ethan Furman wrote:
>
> > Jason Swails wrote:
> >> How is "while n != 0:" any worse?
>
> 1. It is redundant, just like 'if bool_value is not False:'.
> Python programmers should understand the null value idiom.
>
> 2. It does 2 compa
On 2/10/2011 11:52 AM, Ethan Furman wrote:
Jason Swails wrote:
How is "while n != 0:" any worse?
1. It is redundant, just like 'if bool_value is not False:'.
Python programmers should understand the null value idiom.
2. It does 2 comparisons, 1 unneeded, instead of 1. For CPython,
it adds
Jason Swails wrote:
On Wed, Feb 9, 2011 at 8:16 PM, Ethan Furman wrote:
while n: is plenty readable. n is either something or nothing, and
something evaluates to True, nothing to False.
Sure it's readable. But then you have to make sure that the loop will
eventually take n down to 0.
On Thu, Feb 10, 2011 at 3:31 AM, Benjamin Kaplan
wrote:
>
> > On Wed, Feb 9, 2011 at 5:34 PM, MRAB wrote:
>
> >>> Or typecast to an int if you want to neglect decimals before converting
> >>> to a string, etc.
> >>>
> >> [snip]
> >> Python doesn't have typecasting. :-)
> >
> > Because these basic
On Thu, Feb 10, 2011 at 12:03 AM, Jason Swails wrote:
>
>
> On Wed, Feb 9, 2011 at 5:34 PM, MRAB wrote:
>>
>> On 09/02/2011 21:42, Jason Swails wrote:
>>>
>>> You've gotten several good explanations, mainly saying that 0 -> False
>>> and not 0 -> True, which is why the while loop exits. You've a
On 2/9/2011 6:00 PM, Rikishi42 wrote:
numeric types.
I would have defined the flaw to be use of '/' for the integer division.
Guido agreed, and hence changed it (after much contentious discussion!).
--
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
On Wed, 09 Feb 2011 22:53:27 -0800, drygal wrote:
> I guess it needs:
>
> def num_digits(n):
>return len(str(n)) -1
I don't think so.
>>> num_digits(9)
0
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
On 9 Lut, 06:29, Michael Hrivnak wrote:
> Your function only works if n is an integer. Example:
>
> >>> num_digits(234)
> 3
> >>> num_digits(23.4)
>
> 325
>
> When doing integer division, python will throw away the remainder and
> return an int. Using your example of n==44, 44/10 == 4 and 4/10 =
On Wed, Feb 9, 2011 at 8:16 PM, Ethan Furman wrote:
> Jason Swails wrote:
>
>> However, as surprising as this may be I'm actually with RR on this one
>> (for a little) -- for code readability's sake, you should make your
>> conditional more readable (i.e. don't depend on the fact that the iterati
On Wed, Feb 9, 2011 at 5:34 PM, MRAB wrote:
> On 09/02/2011 21:42, Jason Swails wrote:
>
>> You've gotten several good explanations, mainly saying that 0 -> False
>> and not 0 -> True, which is why the while loop exits. You've also
>> gotten advice about how to make your method more robust (i.e.
Jason Swails wrote:
However, as surprising as this may be I'm actually with RR on this one
(for a little) -- for code readability's sake, you should make your
conditional more readable (i.e. don't depend on the fact that the
iterations will take your test value down to 0 which conveniently in
rantingrick wrote:
> Well, the only way to reply is to paraphrase an anecdotes my mother
> would tell me often as a young lad...
>
> Mother: "Just because other language developers choose to jump off the
> cliffs of implicit-ey should we jump also?"
You think of yourself as a _language developer_
Uh oh, I think we found RR's evil twin: another python to the modern day
visionary.
>Example 1 is not explicit enough. Too much guessing is required by the
>reader!
if list is empty, bla. if not, bla. it's not all that hard, and there's
no guessing that needs to take place, honest.
--
http://m
On Wed, 2011-02-09 at 06:51 -0800, rantingrick wrote:
> On Feb 9, 1:08 am, Paul Rudin wrote:
> > Nanderson writes:
> > > loop would be infinite. I get what is happening in the function, and I
> > > understand why this would work, but for some reason it's confusing me
> > > as to how it is exitin
On Thu, 10 Feb 2011 00:00:48 +0100, Rikishi42 wrote:
> I would have defined the flaw to be use of '/' for the integer division.
Well, it was a long time ago, when it seemed like a good idea.
Now, Python has // for integer division.
--
Steven
--
http://mail.python.org/mailman/listinfo/python
On Feb 9, 5:00 pm, Rikishi42 wrote:
[...]
> Using 0 as false and any other value as true is hardly unique to python. Lots
> of languages have been doing this long before Python even existed.
Well, the only way to reply is to paraphrase an anecdotes my mother
would tell me often as a young lad..
On 2011-02-09, rantingrick wrote:
> On Feb 9, 1:08�am, Paul Rudin wrote:
>> Nanderson writes:
>> > loop would be infinite. I get what is happening in the function, and I
>> > understand why this would work, but for some reason it's confusing me
>> > as to how it is exiting the loop after a certa
On 2011-02-09, Michael Hrivnak wrote:
> Your function only works if n is an integer. Example:
>
num_digits(234)
> 3
num_digits(23.4)
> 325
>
> When doing integer division, python will throw away the remainder and
> return an int. Using your example of n==44, 44/10 == 4 and 4/10 == 0
>
On 09/02/2011 21:42, Jason Swails wrote:
You've gotten several good explanations, mainly saying that 0 -> False
and not 0 -> True, which is why the while loop exits. You've also
gotten advice about how to make your method more robust (i.e. force
integer division).
However, as surprising as this
You've gotten several good explanations, mainly saying that 0 -> False and
not 0 -> True, which is why the while loop exits. You've also gotten advice
about how to make your method more robust (i.e. force integer division).
However, as surprising as this may be I'm actually with RR on this one (f
On Feb 9, 1:08 am, Paul Rudin wrote:
> Nanderson writes:
> > loop would be infinite. I get what is happening in the function, and I
> > understand why this would work, but for some reason it's confusing me
> > as to how it is exiting the loop after a certain number of times. Help
> > is appreciat
On 2/9/2011 9:27 AM, RJB wrote:
On Feb 8, 11:08 pm, Paul Rudin wrote:
It works because 0 tests false and because integer division yields
integers... eventually you'll get something like 1/10 giving 0.
It's not necessarily a good thing to rely on. For example if you try it
after "from __future
On 09/02/2011 14:27, RJB wrote:
What operator should I use if I want integer division?
Ada and Pascal used "div" if I recall rightly.
The operator for integer division is //
--
http://mail.python.org/mailman/listinfo/python-list
On Feb 8, 11:08 pm, Paul Rudin wrote:
> It works because 0 tests false and because integer division yields
> integers... eventually you'll get something like 1/10 giving 0.
>
> It's not necessarily a good thing to rely on. For example if you try it
> after "from __future__ import division" - or i
Nanderson writes:
> loop would be infinite. I get what is happening in the function, and I
> understand why this would work, but for some reason it's confusing me
> as to how it is exiting the loop after a certain number of times. Help
> is appreciated, thanks.
It works because 0 tests false an
On Feb 8, 10:29 pm, Michael Hrivnak wrote:
> Your function only works if n is an integer. Example:
>
> >>> num_digits(234)
> 3
> >>> num_digits(23.4)
>
> 325
>
> When doing integer division, python will throw away the remainder and
> return an int. Using your example of n==44, 44/10 == 4 and 4/1
Your function only works if n is an integer. Example:
>>> num_digits(234)
3
>>> num_digits(23.4)
325
When doing integer division, python will throw away the remainder and
return an int. Using your example of n==44, 44/10 == 4 and 4/10 == 0
Before each iteration of the while loop, the given exp
32 matches
Mail list logo
