Re: Changing the Division Operator -- PEP 238, rev 1.12
Bruce writes -
I think you are missing something... If you were designing a control system for the `toys', and needed to expose a user level programming interface; would you be more likely to choose languages C+S or language P (which can do both jobs) [C+S == P, of course].
Unless CP4E is done as a "semantic game" with a larger language, language P will never exist.
Or else I am expressing myself badly and you are missing something of my point. Let's take one little such toy. A calculator. One that does undisguised Python numerics - 3/4 = 0, 3.0/4 = .75. But let's give them 2 different names. One is called the Python Calculator and the other the Python Numeric Type Calculator. One is sadly broken and the other works perfectly - but they are exactly the same little toy. If you see my wonderfully made little point. ART
But let's give them 2 different names. One is called the Python Calculator and the other the Python Numeric Type Calculator.
One is sadly broken and the other works perfectly - but they are exactly the same little toy.
If you see my wonderfully made little point.
ART
But then, programming with variables, the type of which may not be readily known to the reader, is not the same thing as raw entry of numbers into a calculator. Just looking at raw numbers is to all together miss the point of adding a // key to this calculator (and saving / from doing double-duty depending on the type of inputs we feed it). Kirby
Note, same answers except for type: 2 + 2 = 4 2.0 + 2.0 = 4.0 2L + 2L = 4L 2 * 2 = 4 2.0 * 2.0 = 4.0 2L * 2L = 4L 2**2L = 4L 2.0**2L = 4.0 2.0**2 = 4.0 etc.
4L == 4 == 4.0 # check for equality 1
2 - 1 = 1 2.0 - 1.0 = 1.0 2L - 1L = 1L
1L == 1 == 1.0 # check for equality 1
But... 1L/2L = 0L 1/2 = 0 1.0/2.0 = 0.5 ... division is special. The other primitive ops return essentially the same answer (as demonstrated by ==), regardless of type. But not /. / is different. Does it have to be? 1L/2L = 0.5 1/2 = 0.5 1.0/2.0 = 0.5 But what if we want the divmod(a,b)[0] integer behavior? 1L//2L = 0L 1//2 = 0 1.0//2.0 = 0 Now, if we see var3 = var1/var2 in code, we know var3 is a float. We know this even if we don't know for sure what var1 and var2 are. This isn't so important with + - * and ** because the float and non-float answers are essentially the same (baring overflow when long oes beyond the range of int or float), but with /, the answers are currently very different depending on argument types. Such gross differences in behavior would be better handled by two different operators, such that code readibility is not sacrificed to a primitive operator's low-level, tricky polymorphism (you can still redefine / if you want to, using __div__ and __rdiv__ -- you'll also be able to override // -- then it's up to you to make clear to your readers what you're up to). Kirby
participants (2)
-
Arthur Siegel -
Kirby Urner