So many people chiming in with their dismissive comments and superior Python knowledge. The article is excellent and should be required reading for Python devs. Having it in one place is valuable resource.
A bite of Python
71–80 of 168 posts
Re: A bite of Python
#72The point the article makes on comparing floating point values and the floating point type is true, but it's not because of any rounding error. It's because the comparison operators are defined for every value. That is, "True https://docs.python.org/3.0/whatsnew/3.0.html#ordering-compa... ). This is also not a case of Python doing something useful, like with '"foo"*2'. The result of the comparison is defined, but it'…
> The point the article makes on comparing floating point values and the floating point type is true, but it's not because of any rounding error. Do you mean this example? (it's the only one I can find about floating point comparison) > 2.2 * 3.0 == 3.3 * 2.0 It's definitely due to accuracy error. (rather than type comparison) How would you explain it otherwise?
There is another snippet near that section which evaluates the following.
>>> float > float('infinity')
TrueRe: A bite of Python
#73Re: A bite of Python
#74One Python gotcha that has bitten people in my company a lot: fun_call('string1', 'string2' 'string3') That is, missing commas and subsequent string concatenations can lead to nasty errors. I wish Python didn't nick this from C and would have just enforced the use of + to concat over-length strings, if they need to be split to multiple lines.
I love Python, but I have to agree on this one.
I mean, this one is solvable by not using magic constants. Pretty easy to avoid. Can also lint it.
Re: A bite of Python
#75On the float behavior: I really wish Python 3 had the sense to do what Perl 6 did and interpret all literals with decimal points (except those that use scientific notation) as Fractions instead of floats. That would solve all these floating-point errors without requiring significant modification of code, plus Python 3 would be the perfect time to do it because they're already throwing out backwards compatibility because of the str/bytes thing.
Re: A bite of Python
#76Earlier quoted context omitted.
Unless the article was updated after your comment: the reason is right there in the article: "However, Python does not produce any instructions for assert statements when compiling source code into optimized byte code (e.g. python -O). That silently removes whatever protection against malformed data that the programmer wired into their code leaving the application open to attacks. The root cause of this weakness is t…
I would argue that one should never use '-O' it also strips doc strings from running code. Not really an `optimization` but they had do something right? One couldn't run __unoptimized__ in production could they?
> I would argue that one should never use '-O' it also strips doc strings from running code.
Python `-OO` strips docstrings, `-O` basically only disables assertions. See: http://stackoverflow.com/a/4777156/459543
Re: A bite of Python
#77The point the article makes on comparing floating point values and the floating point type is true, but it's not because of any rounding error. It's because the comparison operators are defined for every value. That is, "True https://docs.python.org/3.0/whatsnew/3.0.html#ordering-compa... ). This is also not a case of Python doing something useful, like with '"foo"*2'. The result of the comparison is defined, but it'…
> The point the article makes on comparing floating point values and the floating point type is true, but it's not because of any rounding error. Do you mean this example? (it's the only one I can find about floating point comparison) > 2.2 * 3.0 == 3.3 * 2.0 It's definitely due to accuracy error. (rather than type comparison) How would you explain it otherwise?
This really makes me wish they made the decision for Python 3 to auto-convert these literals to Fraction objects like Perl 6 does.
Basically, autoconvert the above to this (and make Fraction a builtin instead of in the standard library, of course):
>>> Fraction('2.2') * Fraction('3.0') == Fraction('3.3') * Fraction('2.0')
TrueRe: A bite of Python
#78The behavior of 'assert' is not an anomaly. It comes from 'design by contract.' Assert is primarily meant to be documentation of constraints in code and secondarily a way of catching errors during development. "Contract conditions should never be violated during execution of a bug-free program. Contracts are therefore typically only checked in debug mode during software development. Later at release, the contract che…
That is certainly one approach, and the article agrees.
> The root cause of this weakness is that the assert mechanism is designed purely for testing purposes, as is done in C++.
However, C and C++ are perhaps unique in how much undefined behavior is possible and in how simple it is to create. Inserting into a vector while iterating through it, for instance. Or an uninitialized pointer.
That's why many C++ experts believe in runtime assertions in production. Crashing the application with a core dump is generally preferable to trashing memory, corrupting your database, or launching the missiles.
Re: A bite of Python
#79Earlier quoted context omitted.
I love Python, but I have to agree on this one.
I mean, this one is solvable by not using magic constants. Pretty easy to avoid. Can also lint it.
I don't get what you're saying. How is it possible to write code without string literals?
subprocess.check_call([
"/usr/bin/env",
"echo"
"hello world"
])Re: A bite of Python
#80"Reusable integers" is a real fail - it violates the principle of least surprise and introduces a nasty inconsistency - all integers should logically be (refer to) the same integer object, not just the first 100. Assert is a statement, not an expression, so do not use it as an expression. One should never compare floats. This is taught in any freshman CS course. The limitation is due to the standard encoding of float…
If your code relies on two integers having the same object ID, I daresay you may be doing something wrong.