proposed language change to int/int==float (was: PEP0238 lament)

[Tim Peters]

[Tim, still trying to recover from an avalanche of email]
> It would [be] much easier to take advantage of 754 by simulating fp
> entirely in software, avoiding the platform HW and C fp facilities
> entirely.

[Bengt Richter]
> I sort of expected you to say that, but don't you find that sad?

Sure, but I'm too old to get depressed over being sad <wink>.  It's about 16
years since 754 became a std, and language support for it still reeks.  It's
also sad that so few FPU vendors thought to support the non-mandatory
double-extended format, and a tragedy that C compilers on Pentium chips
(where HW does support it) exploit double-extended in such unpredictable
ways that double-extended is in practice much more a source of subtle bugs
than the wonderful safety net it was *intended* to be.  Also sad that
significant HW support for decimal fp is still limited to calculators, and
that few CPUs expose HW random-number generators, and that even fewer offer
significant support for multiprecision GCD calculation, and ... there's
*plenty* to be sad about, Bengt -- don't blow it all on one thing <wink>.

> BTW, I couldn't find where it officially says a sequence
> expression's elements are evaluated guaranteed left to right. E.g.,
> if I write
>     [foo(), bar(), baz()]
> can I depend on global side effects of foo() to be available to
> bar(), and of bar() to baz() in strict sequence?  The sequences
> are at the top of the precedence table, but what of the elements?
> Just want to make sure ;-)

Yes, you're safe.  It's not in the ref man, but left-to-right was Guido's
intent, and he's promised it in public more than once.  BTW, it's almost
always a terrible idea to deliberately rely on side-effect order; the rule
has greater value in reducing the number of ways in which "conforming"
Python implementations (incl. CPython across releases!) can vary in what
they produce.

AFAIK, there's only one place CPython blows this, and, last time I asked,
Guido considered it a bug (but nobody has cared enough to fix it):

>>> counter = 0
>>> def i():
...     global counter
...     counter += 1
...     return counter
...
>>> {i(): i()}
{2: 1}
>>> {i(): i(), i(): i()}
{4: 3, 6: 5}
>>>

This is specific to dict constructors:  key:value *pairs* are evaluated left
to right, but within a single key:value pair, the value gets evaluated
first.  Hmm.  It's about time that got a bug report!  So here one is:

<http://sf.net/tracker/index.php?func=detail&aid=448679&
 group_id=5470&atid=105470>

of-course-fixing-it-may-break-somebody's-code-ly y'rs  - tim