PEP0238 lament

[Bill Anderson]

In article <WV177.36940$Cy.4447774 at news1.rdc1.az.home.com>, "Tim Hochberg"
<tim.hochberg at ieee.org> wrote:
...
> 
> Consider two functions: the number of pillars on a bridge and electrical
> impedance per unit length:
> 
> def pillars_per_bridge(bridge_length, pillar_sep):
>    return bridge_length / pillar_sep
> 
> def impedance_per_length(impedance, length):
>    return return impedance / length
> 
> In the first case I _always_ want to do floor-division. In the second I
> always want to do float-division. To get these to work now I need to do
> something like:
> 
> def pillars_per_bridge(bridge_length, pillar_sep):
>    return int(bridge_length) / int(pillar_sep)
> 
> def impedance_per_length(impedance, length):
>    return (1.0*return impedance) / length
> 
> Which is not too horrible, but it is extra cruft. So let me turn your
> question around. Can you give an example where you want the type of
> division (float vs floor) to change depending on the type of input (int,
> float, complex)? I can't, although I suspect there must be some. I also
> suspect they're very rare.

What about this:

 def pillars_per_bridge(bridge_length, pillar_sep):
    return int(bridge_length) / int(pillar_sep)
 
 def impedance_per_length(impedance, length):
    return (return impedance) // length

It can even be 'tought' with a memory trick.
/ returns an integer when given integers. // says you want the leftovers,
so you have a "leftover '/'" ;) Or, you could express it as // meaning you
want more precision, take your pick.  Another way of expressing
int/int=int is to consider 3/2=1 as "1 with a remainder of 2, drop the
remainder". I see this behaviour in my old math textbooks, and in today's
math teaching of my son. I distinctly recall seeing "Ignore the
remainder: ...". So it is not that far of a stretch.

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*.

How about this:

 Someone put up a PEP that puts .. in as int//int=float, the change gets
into 2.2. Then, those who need/want (or would that be need//want? ;)
integer division to coerce to float, can have it, and those who want/need
int/int=int can still keep it.

We have here, an excellent opportunity to satisify both parties, and we
are squandering.

In the end, we have to ask ourselves, "What is the point"?

Easier to teach is insufficient. I do not mean to impugne those who have
difficulty teaching int/int=int, but it certianly can be tought, you use
simply frame it differently. Additionally, I agree thag changing a
language in a way that interferes long-term users of said language, to
ostensibly make it easier to teach to non-users in likewise insufficient
reasoning. it is far easier to each new people a new way, than it is to
teach peoplpe well versed to change their ways.

Is the point, perhaps, to avoid explicit casting? int//int=float gets us
that. It acheives it with the minimum amount of effort, and does so with
only a single keystroke.

Let us put aside the religious differences about whether or not int
divided by int should return a float or an int. In the end, that is
essentially irrelevant, as we have the means to provide a simple,
non-code-breaking change to provide people with both. And, we get to do
so wihtout passing judgement as to whether or not int/int should be a
float or an int. In addition, I get do change float(a)/b  to a//b. :)

Bill

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