Hacker Newsnew | comments | show | ask | jobs | submit login

This sounds like an incorrect compiler.



I disagree, because side effects in an assert would always be a code smell, but placing slow code in there is useful behavior. The line could have easily been:

assert EnsureUnique( obj )

Which runs through the program's data structures to ensure that nothing else matches a property of obj in some way.

Hacky, slow, but very useful to keep around if you have a constraint like that. But if you run it in release mode with production sized data sets, it'll slow to a crawl if you don't cut out the entire check.

-----


I wouldn't rely on assert code for this, better say "if dataset is huge don't check".

-----


When it optimizes out a statement that the spec explicitly says can be optimized out? A correct compiler is one that conforms to spec. You using a statement for something outside of its intended purpose makes the compiler incorrect?

-----


Sorry, I'm not deeply familiar with the Python spec. Outside of C or a lisp I would expect assert to behave more like a function which discards its arguments when disabled and less like a macro which stops evaluating its arguments when disabled. This expectation would obviously be incorrect in the case of Python, which is fairly explicit as to the meaning of assert[0]:

  if __debug__:
   if not expression: raise AssertionError
My mistake!

[0]: http://docs.python.org/2/reference/simple_stmts.html#the-ass...

-----


Agreed, a compiler should replace "assert(FOO)" with "FOO", and then remove "FOO" if it has no side effects, like any statement.

-----


This sounds nice in theory. In practice, the compiler cannot eliminate any log statements (writing to a log file is a side effect). Thus, the decision to not execute "FOO" as for example Java does when asserts are disabled, is the correct one.

-----


I think the GP is referring to when NDEBUG is defined.

-----




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: