On Feb 28, 10:00 am, Paul Rubin <http://[EMAIL PROTECTED]> wrote: > More examples: > > x = 1 > y = len(s) + x > > => ok, decides that x is an int > > x = 1 > y = x + 3.0 > > => ok, decides that x is a float > > x = 1 > y = x + 3.0 > z = len(s) + x > > => forbidden, x cannot be an int and float at the same time. > > > I am so glad you're not the designer of Python. > > This is how Haskell works and I don't notice much complaints about it.
Ok, that means the line "y = x + 3.0" have a side effect of "x = float(x)"? I think I would say that is an implicit behavior. On Feb 28, 11:22 pm, "D'Arcy J.M. Cain" <[EMAIL PROTECTED]> wrote: > > You people can't tell the difference between "obvious" and "learned > > conventions that came about because in limitations in the hardware at > > the time". Nobody would have come up with a silly rule like "x op y > > must always have the same type as x and y" if computer hardware had > > been up to the task when these languages were created. > > What makes you say they weren't? Calculating machines that handled > floating point are older than Python by far. > But much younger than the first programming language (if it could be called as a language) that set the convention of int op int should result in int 'cause our hardware can't handle floats. On Feb 29, 6:15 am, Paul Rubin <http://[EMAIL PROTECTED]> wrote: > Can you name an example of a calculating machine that both: > 2) says 1/2 = 0.5 ? Any pocket calculator to scientific calculator. Except perhaps my calculator which is fraction scientific calculator where it stores 1/2 as rational and have another division operator for 1/2 == 0.5 -- http://mail.python.org/mailman/listinfo/python-list
