Hacker News Reader

Comment by blowski | Hacker News Reader

It's not an anomaly, but it can be a surprise for people who don't understand what it does. For example, they use asserts for validation and then the validation doesn't work in production. It's absolutely right the way it works, but it's still a gotcha for the audience this blog post is aimed at.

View on HN

>It's not an anomaly, but it can be a surprise for people who don't understand what it does.

That's almost a tautology though.

The point is that they think they understand it, because most of Python behaves the same in development and production. You see this function called 'assert', it gives the right error at the right time, and all is good. Then you push it to production and it stops throwing errors. Eventually, you read the manual and it tells you that this specific function is ignored in production. This is a surprise because, say, print doesn't behave like that.

That only happens if you have different production and development environment settings though -- in which case you should expect the different results.

In this particular case, you compiled your code with "-O", so it's not the "same code" used in production, but code compiled with a different flag. Shouldn't they check what the flag does?

The developer may be deploying code to a server they didn't configure.

I agree with the way it's done in Python, as it's consistent with most other languages. But the blog post is right to point out to inexperienced developers that the way assert behaves might give them a surprise.

> but it's still a gotcha for the audience this blog post is aimed at.

Would be nice if they had a pointer to the reason, however.

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 that the assert mechanism is designed purely for testing purposes, as is done in C++. Programmers must use other means for ensuring data consistency."

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

>See: http://stackoverflow.com/a/4777156/459543

Or just do "python -h":

-O : optimize generated bytecode slightly; also PYTHONOPTIMIZE=x -OO : remove doc-strings in addition to the -O optimizations

Same on both Py 2 and 3.

I assume that almost nobody uses -O in production.

Probably the same folks who don't test their code probably also remove their assertions in production.

So far as I've ever read, literally all -O does is strip asserts and docstrings. It doesn't really optimise anything.

Reply on news.ycombinator.com