Asserts can be removed during bytecode optimization

[edumco]

From Codacy issues

assert is removed with compiling to optimised byte code (python -o producing *.pyo files). This caused various protections to be removed. The use of assert is also considered as general bad practice in OpenStack codebases.

Link to list all occurrences: https://app.codacy.com/manual/edumco/pyan/issues/index?bid=15369107

[edumco]

Github suggested this issue #18 as a similar bug. And it looks promissing because it only happens on runtime.

[Technologicat]

Thanks for the report!

As for #18, there's a bug somewhere in the algorithm that populates the graph. A helpful, minimal working example has been posted, so it shouldn't be too difficult to figure out what is happening there, once I have a couple of hours to dedicate to that. I suspect it's unrelated to the asserts - or if anything, we're missing an assert somewhere, to fail-fast the particular assumption violation that currently bubbles up until it causes a visible failure much later (likely far away from its original cause).

I've just been ~lazy~ away from Pyan for a while, so I haven't looked at it in detail yet, beside what I already wrote in the comments to #18.

As for asserts in general, I just happen to come from a different school. This is a multifaceted issue requiring an essay answer, so please bear with me. :)

IMHO, the assert cond construct itself is neither bad nor good - that depends on how it's used. (Unlike, say, unrestricted goto, which is inherently harmful, because it fundamentally makes it impossible to locally reason about control flow. As Nathaniel Smith has pointed out, goto has a parallel (pun not intended) in many popular concurrent programming schemes; his trio library is (AFAIK) one of the first attempts to build something that makes concurrent code easier to reason about - by eliminating unrestricted go, much like modern languages have eliminated unrestricted goto. What I mean by unrestricted is that there are still some restricted forms of goto, even in Python - break, continue, return and raise all transfer control, but only outward on the call stack.)

The assert cond construct is, fundamentally, merely convenient shorthand for the more verbose if not cond: raise AssertionError (in essence it's a very specific syntactic macro!). With readability equal (no golfing!), shorter code has fewer places for bugs to hide, and is faster to read (by humans), so the shorthand should be preferred over the longhand form. The shorthand also comes with the bonus of explicitly telling the compiler it is an assert, so the compiler knows to omit it from the bytecode output should the user request to do so.

(Code density concerns aside, it bears pointing out that shorter is better still only up to a point. As Paul Graham argues in On Lisp, there is a learning cost associated with each new construct. A shorthand, if a new construct is defined locally in a project, it should save at least several times the length of the longhand form (when amortized over the whole codebase), before defining the shorthand becomes an overall win. Here the learning cost is negligible, because assert is part of the base language, so anyone programming in Python is likely already aware of it.)

Codacy (new to me - thanks for the link, by the way!) correctly points out that asserts may end up removed from a production compile, implying that the code must be safe to run even if the asserts aren't there. Up to this point, I agree.

But I think asserts are still useful. I see their role as helping to catch violations of preconditions and postconditions at development time, as well as explicitly documenting such assumptions in a form that can be (optionally) machine-checked. Correct usage is to only assert on conditions that - in the absence of bugs - are always true. For things to which Murphy's law may apply at runtime (to paraphrase Peter Seibel), exceptions or another error handling mechanism (including conditions and restarts in Common Lisp, and the Either monad in Haskell) are the appropriate tools.

I think using asserts to enforce preconditions and postconditions is similar to using mypy for enforcing type safety. During development, certain safety checks are enabled, and in production, they are disabled, allowing the program to run a bit faster. This general pattern is very common - for example, Cython has compiler directives to disable bounds checking and wraparound (a.k.a. negative indexing) for array accesses.

Ideally, for checking preconditions and postconditions, I'd like a Turing-complete contract system, but... in a way, a general-purpose programming language itself already is one (the value of a specialized contract system being in the brevity and uniformity of notation). For most everyday uses, asserts at entry/exit points perform this job just fine.

Granted, there are (mathematical/logical) properties that are better captured in a static representation one meta-level higher, because the halting problem and its cousins make it impossible, in general, to dynamically check for things such as "is this sequence finite?". But in any sufficiently flexible language, it's just a design choice of which properties to encode in the concept of static type, versus which ones to dynamically verify at runtime.

Python actually already has something resembling this distinction - the language is fully duck-typed, but then there are things like the metaclasses in collections.abc, their generalization typing.Protocol, mypy... and indeed, classes themselves (even, with The Right Way to handle multiple inheritance!), if one chooses to subscribe to the (very un-ducklike) notion of nominative (as opposed to structural) typing. I suppose both kinds of typing are just tools, with different strengths and weaknesses.

(It's not the only such "mismatch" between how Python presents itself at the surface, and how it actually works or what can be done with it. Python is actually flexible enough to support syntactic macros, although they are not commonly used. Python's object model is actually prototype-based, just like JavaScript's, even though it attempts to look like a traditional class-based system (possibly to avoiding confusing those coming from C++ or Java?). In ES6, JS went the same route, too.)

Anyway, to return to the main topic of asserts, I think I understand where Codacy is coming from. Python advertises itself as a language for programmers of all skill levels, valuing clarity foremost. The assert construct is particularly easy to misuse, unless one is careful. It's a deceptively simple-looking advanced feature (I'd argue comments are, too...).

So to make a codebase easily approachable to the largest possible audience, it's safer if the code doesn't use asserts, so it's easier to resist the temptation to "follow the example" and add in some inadvertently incorrect ones when working on it.

If that is the reasoning behind the recommendation, my answer is more education for the general programming audience. I admit I don't know how well that scales. :)

Further thoughts welcome - including, and especially, opposing viewpoints.

[edumco]

I am incredibly happy with your answer, because it not only make me understand this issue more profoundly as it opens a whole new perspective on the language itself.

I never really understood (this deep) the use of assertions outside the tests.

Any tool we could use to enhance our code to me is a good thing and in this context appears to me that it is used exactly for that.

I'm a great fan of 'Codacy' and other code analyzers because they put questions on your head about the code you're producing, but it should never be used as bible. And this discussion (talk/conversation I'm no native english speaker) tackle so many things that i'm gonna need a few weeks to fully grasp all this richness.

You explain things very well! I think you should publish this conversation somewhere else.

Thank you a lot and a big hug from Brazil!

PS: I'm going to ignore this issues for this repo :)

[Technologicat]

Glad I could help. Yes, I might need a blog instead of using GitHub issue comments as such... :)

Here are some more ideas and/or pointers that may interest you, or indeed anyone who ends up here via Google:

• Regarding assert in tests, with Python supporting import hooks, the assert statement has become an obvious place to attach test frameworks.
  • pytest does this, so in your tests, you just write assert statements as usual. But instead of your tests stopping at the first error, pytest proceeds even if an assert fails, and gives you a nice report at the end.
  • I haven't looked at how they do it, but if I had to do it, I'd use import hooks to transform the AST of the module containing the test code, at import time. If this sounds a lot like syntactic macros, it's because it is. Macropy also transforms the AST at import time, but lets the user control what gets transformed into what. This can be used to build new language constructs.
  • Metaprogramming with syntactic macros is common in the Lisp family of programming languages, less so elsewhere. It's a powerful technique, but it does introduce its fair share of new technical difficulties. (Many of which you'll figure out, if you think through the logical implications of what the macro expander does: in the AST, it replaces the macro invocation by the equivalent expanded code. A macro is essentially just shorthand for some longhand piece of code; or more generally, a procedure that takes some high-level specification and generates that longhand code from it. Exercise: consequences of variable name conflicts between the macro expansion and the use site? Can macros be first-class objects?)
• Static analyzers are indeed a nice productivity booster.
  • I use flake8, which integrates into Spacemacs. It's a combination of pyflakes-style static analysis with PEP8 code style checking.
  • autopep8 is useful, too. Integrates into Spacemacs, too, so when I save a .py file, it gets PEP8 enforced automatically. :)
  • Both of these tools have configuration options, so you can choose which rules to enforce, and which ones to ignore. (Here's the big list of rules.) IMHO, some things in PEP8 are just silly - two blank lines after each function body wastes vertical space, if you have many short functions, like the functional programming style tends to produce.
  • If you're curious, my configs are on GitHub. The flake8 config file works with both flake8 and autopep8. (You probably already have them set up?)
• Some recommended readings, if you want to explore programming language design further:
  • Fear of Macros: Greg Hendershott's primer on understanding syntactic macros.
  • Structural insight, John Shutt's blog. He's the author of a Lisp dialect called Kernel. For a taste, see the essay on Abstractive power.
  • Stupid Python Ideas. For a taste, Hacking Python without hacking Python.
  • Lambda the Ultimate, a discussion forum on programming language design. Participants tend to be well-informed. For example, here's a thread on type systems.
  • Matthew Might's blog. His slogan is to understand is to implement. For example, You don't understand exceptions, but you should. See also Compiling to lambda-calculus: Turtles all the way down.
  • So also, to learn language design, take a page from him, and just build something. I recommend Racket as a particularly friendly, pythonic Lisp dialect that's specifically geared for experimenting with language ideas. It gives you all the infrastructure for free, so you can concentrate on the interesting parts.
    • The Racket Guide is friendly and a nice starting point.
    • See also Beautiful Racket, an online book by Matthew Butterick.
    • I tested Racket briefly myself; here are some code experiments.
    • True wizards implement things like this, this and this.
    • A simple infix math processor with precedence takes just a few lines. (Search the page for "more operators".)
  • If you want to experiment with language design in Python, consider Macropy (PyPI package macropy3).
    • Note the correct fork if you want the latest code.
    • The documentation is friendly, but having some experience with Common Lisp's defmacro or with Racket's syntax-parse helps here. Since the Lisp family is "the native habitat" of syntactic macros, learning the basics there first is simpler than learning them directly in Python.
    • Shameless plug: to ease agile development with macros in Python, see imacropy. If you want to make Python a language-develoment platform in the style of Racket, see pydialect.
• Design by contract (DbC) is not nearly as well-known as it, IMHO, should be. For me it was an eye-opener when I first heard about it years back.
  • In my experience, many programmers (and CS researchers) tend to focus on static types instead of the more general idea of contracts.
  • Many, but not all; at least Shutt is skeptical about types [1] [2]. Sam Tobin-Hochstadt, one of the Racket developers, says that viewing dynamic languages as having just one Any type is misleading (although it is a valid embedding that acts as a type-theoretical justification for dynamic languages); that's not how we reason, as developers, when writing software in dynamic languages.
  • I've collected some links to related readings here.
  • The very rudimentary static type system in low-level languages such as C is so useless it may give static type systems a bad name. Let's talk parametric polymorphism or Hindley-Milner, and then we're starting to have a system that actually helps.
  • Gradual typing is a related idea. Typed Racket has it, as well as Julia, and arguably Mypy (though in Mypy specifying types doesn't help performance; that's not in its design goals). Common Lisp has something similar (see DECLARE in Seibel's book).
• Final practical tip: Feeling adventurous? Want faster Python? Try PyPy. Nowadays it supports version 3.6 of the Python language, and runs even complicated libraries such as SciPy just fine...

---

EDIT: mention user-programmable infix operators for Racket, and CL's support for DECLARE. Mention imacropy and pydialect.