4 ms·

I never quite understood why the division of integers resulting in integers was a problem. I get that for people with no knowledge of programming whatsoever it

by ajford 9y ago

I never quite understood why the division of integers resulting in integers was a problem. I get that for people with no knowledge of programming whatsoever it can be confusing, but it's standard behavior in nearly every typed language. In C/C++, you divide an Int and you get an Int. If you want floating point division, you divide by a float. Problem Solved. Almost EVERYTHING else could have been done with slow migration, or simply documenting the odd or quirky behavior. Iterator variable leaking is just a result of poor programming. Raw_input vs input could have been solved by slowly deprecating input. Or just left as is. xrange is the same story. It all seems like someone just decided to throw their hands up in a fit, throw their toys on the ground, and make a new Python. I enthusiastically jumped at Python 3 in the begining, then ran into problems, and crawled back to my 2.7 and decided I could let others fight the stupid cult war that was coming over 2 vs 3. I'd rather use a tool that works than change all my code over someone's idea that newer is better.

cyphar 9y ago
> I never quite understood why the division of integers resulting in integers was a problem [...] but it's standard behavior in nearly every typed language. And hence why it's a problem in Python. If you have a function like def foo(a, b): return a / b What are the types of a and b? You don't know. Sure, you could check with isinstance, but now you've broken the illusion of duck typing. The argument is that Python should just do "the right thing". Just because 3/4==0 in most languages doesn't justify repeating that mistake. Not to mention that float(a)/float(b) -- aside from being incorrect in the general case -- is ugly as hell. > Iterator variable leaking is just a result of poor programming. I think it's a language bug. Why? Imagine if you could do this in C: for (int a = 1; i <= 3; a++) foo(a); printf("%d\n", a); People would think this is clearly a language bug because it breaks the scoping semantics (not to mention common sense). Now, you could argue that Python supports this sort of nonsense so it's "fine": # a is not defined if something: a = 1 else: a = 2 print(a) But the reason that works is because otherwise Python would need to have JS-like "var" syntax to declare a variable. Personally I think that'd be better, but the for-loop situation is different. > raw_input vs input could have been solved by slowly deprecating input. Or just left as is. xrange is the same story. And this is how PHP ended up having three different string escaping functions for SQL statements. The first one (escape_string) was broken, so they added real_escape_string, and then they needed to handle connection-specific quirks so they added mysqli_real_escape_string. Some people still use escape_string even though it's broken -- and the language devs cannot fix it because "that would break users".

by ajford 9y ago

cyphar 9y ago

> I never quite understood why the division of integers resulting in integers was a problem [...] but it's standard behavior in nearly every typed language. And hence why it's a problem in Python. If you have a function like def foo(a, b): return a / b What are the types of a and b? You don't know. Sure, you could check with isinstance, but now you've broken the illusion of duck typing. The argument is that Python should just do "the right thing". Just because 3/4==0 in most languages doesn't justify repeating that mistake. Not to mention that float(a)/float(b) -- aside from being incorrect in the general case -- is ugly as hell. > Iterator variable leaking is just a result of poor programming. I think it's a language bug. Why? Imagine if you could do this in C: for (int a = 1; i <= 3; a++) foo(a); printf("%d\n", a); People would think this is clearly a language bug because it breaks the scoping semantics (not to mention common sense). Now, you could argue that Python supports this sort of nonsense so it's "fine": # a is not defined if something: a = 1 else: a = 2 print(a) But the reason that works is because otherwise Python would need to have JS-like "var" syntax to declare a variable. Personally I think that'd be better, but the for-loop situation is different. > raw_input vs input could have been solved by slowly deprecating input. Or just left as is. xrange is the same story. And this is how PHP ended up having three different string escaping functions for SQL statements. The first one (escape_string) was broken, so they added real_escape_string, and then they needed to handle connection-specific quirks so they added mysqli_real_escape_string. Some people still use escape_string even though it's broken -- and the language devs cannot fix it because "that would break users".