HN user
INSERT ... ON CONFLICT has a problem with CHECK constraints. The constraint must be satisfied in the INSERT tuple even if the row already exists and UPDATE will be executed. I recently dealt with this at work and the resulting CTE query was very similar to MERGE, except MERGE has better syntax.
They don't utterly destroy performance, but there is some hit if you use UUID v4 random values due to database index scattering. That's why this new proposal exists. It adds new versions of UUID that are mostly incrementing in time, so that they group better.
It is a hash, but in the format of a UUID. This is useful if you are storing it in the database, since there is usually a dedicated data type for UUIDs. Also, you can mix UUID v4 and v5 IDs freely.
Extensions can register themselves with the Flask application object, so you can look there: current_app.extensions['whatever']. However, it is not specified what exactly this dictionary contains, so eg. SQLAlchemy puts a custom State class there. You can still get the extension object out of it, it's just that there is no common convention.
http://flask.pocoo.org/docs/0.12/api/#flask.Flask.extensions
https://github.com/mitsuhiko/flask-sqlalchemy/blob/master/fl...
The "documented information" you want is mentioned in the article. Guido links to a blog post by Jeremy Siek and a paper by Vitousek, Siek and Baker. Read the blog post, section "Why subtyping does not work".
http://wphomes.soic.indiana.edu/jsiek/what-is-gradual-typing...
http://wphomes.soic.indiana.edu/jsiek/files/2014/03/retic-py...
Points 1 and 2 are only valid because the Celery database backend implementation uses generic SQLAlchemy. Chances are, if you are using a relational database, it's PostgreSQL. And it does have an asynchronous notification system (LISTEN, NOTIFY), and this system allows you to specify which channel to listen/notify on.
With the psycopg2 module, you can use this mechanism together with select(), so your worker thread(s) don't have to poll at all. They even have an example in the documentation.
http://www.postgresql.org/docs/9.3/interactive/sql-notify.ht...
You are right that it does not look like what is usually called "tail call", ie. call to 'fact' is not the last evaluated expression. However, this doesn't mean that the compiler can't optimize it, provided that the last expression is simple enough. GCC can probably optimize arithmetic expressions. I have read somewhere (can't find it though) that Erlang bytecode compiler also optimizes prepending to a list and some other primitive operations. This means that in these cases you don't have to explicitly use accumulator variable because the compiler will create it for you.