for / while else doesn't make sense

[Steven D'Aprano]

On Mon, 23 May 2016 01:52 am, Jon Ribbens wrote:

> On 2016-05-22, Steven D'Aprano <steve at pearwood.info> wrote:

>> How is this any better though? Complicated or not, people want to divide
>> 1 by 2 and get 0.5. That is the functional requirement. Furthermore, they
>> want to use the ordinary division symbol / rather than having to import
>> some library or call a function.
> 
> That's a circular argument. You're defining the result as the
> requirement and then saying that proves the result is necessary.
> Clearly, people managed when 1/2 returned 0, and continue to do so
> today in Python 2 and other languages.

I'm not defining the result. 4000+ years of mathematics defines the result.

If you get up off your chair and wander around and ask people other than C
programmers "What's one divide by two?", I am confident that virtually zero
percent will answer "zero".

People only managed when 1/2 returned 0 by *working around the problem*, and
yes, it is a problem. They work around it by explicitly casting values to
float (which, if carelessly done, just introduces new problems), or by
using "from __future__ import division".


>> Having 1/2 return 0 (as Python 2 does by default) doesn't make the
>> language any less complicated. It doesn't avoid the complexity of
>> floats, it merely breaks the principle of least surprise,
> 
> No, it *adheres* to the principle of least surprise. Floats appearing
> out of nowhere is surprising. Python 2's behaviour adhered to the
> principle, and Python 3's breaks it.

The float isn't appearing out of nowhere. It appears because you're
performing a division.

When you call `len("hello world")`, are you shocked that an int appears out
of nowhere? Of course not. That's what len() does.

Why should you be shocked that division returns a fractional quantity?
That's what division does! Divide a cake into two pieces, and you have two
half cakes, not no cake.


>>> That's a trap for those people though - it lulls them into thinking
>>> that they understand what's going on, when in fact they don't,
>>> because they don't understand floats, because almost nobody
>>> understands floats. So they don't understand their program, and
>>> - even worse - they don't know that they don't understand it.
>>
>> And how does forcing them to write 1.0/2 solve that?
> 
> Because it forces them to consciously address the fact that they are
> asking for, and getting, floats, and that floats are not something
> the language is willingly to silently foist upon them.

It does no such thing. Have you met any programmers? It forces them to add
an extraneous .0 to the end of their value, and give it no further thought
until somebody reports a bug that Fraction calculations are silently
coerced to floats, and that Decimal calculations raise an exception. And
then they close the bug report "Will not fix" because it's too hard.

>>> Programming languages should do what they are told, and very little
>>> more.
>>
>> Okay, now I'm confused. How is 1/2 returning 0.5 the language not doing
>> what you've told it to do?
> 
> I didn't ask for floats, I got floats. That's how.

You performed a division. What did you expect, a dict?


>>> They should not wander off on surprising jaunts of their own
>>> invention out of the control of the programmer. It should be possible
>>> to know and understand the language, or at least the subset of it
>>> that you are likely to need for your everyday purposes. Floats are
>>> generally not understood, so they shouldn't be suddenly turning up
>>> un-called for.
>>
>> How are they uncalled for?
> 
> By... not being called for? I must admit I don't entirely understand
> your question.

You performed a division. By definition, this involves returning a
fractional amount, or at least the possibility of returning a fractional
amount. To say that it is "uncalled for" to receive a fractional amount is,
frankly, bizarre.



-- 
Steven