PEP0238 lament

David Bolen db3l at fitlinxx.com
Fri Jul 27 20:12:20 EDT 2001


"Bill Anderson" <anderson at hp.com> writes:

> I strongly favor the // operator for the new behaviour. It just make smuch
> more sense that the new stuff goes with new stuff, and old stuff stays
> the same.  Furthermore, code breakage is kept to ... none.
> 
> Hmm code breakage vs no code breakage. If there was no possibility of
> making a change to get the behaviour, I could support a code-breakage.
> But in this case we _have_ a way, a fairly trivial way, of getting the
> int/int=float behaviour *without code breakage*.

For anyone who's been following the threads, it's probably clear that
I'm biased towards the compatibility argument, but it's also only fair
to point out that part of the crux of the problem is that it's not
just a debate over code breakage versus no code breakage, and thus the
answer is not that simple.

At the very least it's a debate over code breakage with better long
term characteristics for a language operator versus no code breakage
with continued ambiguous long term characteristics in a language
operator.  The fact that the operator in question (/) just happens to
be the intuitive one that all new users will want to use for division
adds to the equation.

I think the most recent versions of the PEP do a reasonable job of
highlighting this.

> BTW, how much extra memory does it take (if any) to store 1.0 over 1?

Depends on the precise format, but currently Python uses a C "long" to
store an integer (32 bits or 4 bytes on most current platforms), and a
C "double" to store a floating point value (generally 8 bytes I believe).

So 4 bytes more per value.  It's not actually twice the memory overall
since each object has a fixed header (generally 16 bytes), so it's
really more like a 20% growth.

--
-- David
-- 
/-----------------------------------------------------------------------\
 \               David Bolen            \   E-mail: db3l at fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
\-----------------------------------------------------------------------/



More information about the Python-list mailing list