
Flask 0.11 Released - welder
http://flask.pocoo.org/docs/0.11/changelog/#version-0-11
======
gedrap
One tip if you are about to write your first large (well, larger than 500
lines of code) Flask application: check some example applications for ideas of
separation/architecture and some popular modules.

The minimalist nature of Flask, not forcing you to do things in one way and
one way only, gives lots of power, but also lots of chances to mess it up and
end up with a totally unmaintainable crap. Great power comes with great
responsibility. Personally, I quite liked
[https://github.com/mattupstate/overholt](https://github.com/mattupstate/overholt)
(although some dependencies are out dated!). Also, having some starting point
with the boilerplate code already in place helps you to prototype faster, etc.

Speaking of modules, the Flask modules ecosystem is pretty great and
familiarizing yourself with it might save plenty of time you'd spend on re-
implementing them. Some popular modules that are worth mentioning:

1) Flask-assets [https://flask-
assets.readthedocs.io/en/latest/](https://flask-
assets.readthedocs.io/en/latest/) allows to easily integrate processing of the
assets (JS minification, SASS compilation, etc) into your development
pipeline;

2) Flask-login [https://github.com/maxcountryman/flask-
login](https://github.com/maxcountryman/flask-login) simple users management
(roles, authentication, etc.);

3) Flask-SQLAlchemy [http://flask-sqlalchemy.pocoo.org/2.1/](http://flask-
sqlalchemy.pocoo.org/2.1/) simple integration with SQLAlchemy

4) Flask-Script [https://flask-
script.readthedocs.io/en/latest/](https://flask-
script.readthedocs.io/en/latest/) makes it easy to write command line tools
which run in the context of Flask application (e.g. some cron jobs).

~~~
doomrobo
I've used some example architectures in the past while making a relatively
small but very detail-oriented Flask app. I found that testing was a nightmare
because my errors were only triggered on runtime. So I ended up having to
manually test each code path in order to make sure I didn't have something as
simple as a type error in my code. Static analysis helped a bit, but it's not
as rigorous as a proper type system. Do you have any advice for this
situation? It turned me off of web development in Python almost entirely.

~~~
kerkeslager
Are you unit testing?

~~~
doomrobo
I wasn't, but I guess this is the only solution. The biggest reason I didn't
unit test was that most of my functions were dependent on a significant amount
of internal state. I suppose I should have spent more time coming up with mock
models to use during unit tests. Also separating functionality would have made
things easier.

~~~
kerkeslager
It sounds like you were doing two things that don't really work well in Python
+ framework environments in my experience:

1\. Depending on internal state: I've always had a harder time working with
state, regardless of language. I usually try to structure my code so that most
of my business logic is encoded in functions that have inputs and outputs and
don't modify any state. Only the toplevel functions modify the state, and they
do so by applying database queries or updates that were generated
functionally. This also can often drastically simplify or even eliminate your
mocks.

2\. Not unit testing. Without static types, it's pretty necessary to unit
test. Think of it as that you test whether the types are correct by trying to
use them in a trivial case. This is a double edged sword: on the one hand,
unit tests give you more than static types: a type checker can tell you if the
two things you're adding aren't numbers, but it can't tell you that you're
adding _the wrong numbers_. The flipside is that nothing will tell you if you
didn't test something, or didn't test it correctly.

I don't know if you'll have opportunity to try it again, but maybe next time
try a test-driven development (TDD) approach where you define your function's
interface (inputs and outputs) write failing tests that test those inputs and
outputs, and then implement to make those tests pass. I don't encourage
dogmatic TDD, but it can be a good starting point. Once you get a good feel
for what kinds of interfaces are testable and where tests are helpful, you can
scale back your testing a bit and test more pragmatically as needed.

------
ThePhysicist
They should really name it Flask 1.0 at this point, as it's a very mature
library and lots of people (including me) use it in production settings. In my
humble opinion, the 0.11 version number tends to shy people away from the
library as it conveys the impression that it's still heavily evolving or not
well-tested, which is not the case.

In any case: Congrats :)

~~~
w4
When I decided to learn web dev (coming from a native background), the lack of
updates to Flask was more of a concern than the 0.11 version number.
Everything I read online said that Flask was rock solid, so getting stuck with
an abandoned framework in production was my main concern.

Glad to see Flask's development is back on track, and under formal management!

~~~
Marazan
Flask development has never not been on track, there have been plenty of
commits and bug fixes in the last 3 years, theyve just never made a official
release until now.

~~~
w4
I'm aware, but a web framework going 3 years without a release renders the
distinction between "no releases" and "no development" more or less
meaningless from an end user's point of view.

~~~
zeckalpha
Or it means the APIs are stable, and the feature set is sufficiently limited
to avoid bloat.

~~~
prokaktus
And new releases could be 0.10.2, 0.10.3, ..., with fixes included! And I'm ok
with that from user point of view. But Flask package stuck with 0.10.1.

Glad to see 0.11!

------
scrollaway
This is a big deal. For those unfamiliar with Flask, it's a great library but
has been sitting on 0.10 for three years now.

Blog post about it:
[https://www.palletsprojects.com/blog/flask-011-released/](https://www.palletsprojects.com/blog/flask-011-released/)

~~~
gedrap
Why is it a big deal?

It's been sitting for three years because it was just working and given it's
minimal nature, there were not many things that should be changed. So not much
point to make a release.

~~~
rattray
For one thing, it means contributors' work sat there for up to three years –
not something that would make me want to contribute.

For another, any bugfixes/improvements that had been requested by the
community were inaccessible on a release branch, even after they were
committed – this sounds extremely frustrating.

Most libraries out there are "just working" – doesn't mean they can't ship
improvements, and most do – typically no more irregularly than every 6mo.

~~~
gkya
Sometimes sth. is done and no immediate improvements are needed. Furthermore,
the repo is out there.

~~~
wpietri
>Sometimes sth. is done and no immediate improvements are needed.

That's a very weird thing to say in response to somebody saying, "improvements
were needed and made but not released".

> Furthermore, the repo is out there.

Now that's just ridiculous. If somebody wants to not have releases, that's
fine. E.g., rbenv plugins just seem to be "pull latest from git". But if
somebody is going to have releases, then it's absurd to say: "Hey, if you want
this to actually work, don't use the release that all the docs tell you to
use; instead build the thing we have explicitly not given to you."

Having releases: good. Not ever having releases: good. Having them but not
using them: worst of both worlds.

~~~
gkya
A release is a logical point in a software projects history. Sometimes you
have a bunch of stuff on the head waiting a release, but that point is not
reached yet. The maturity of the features are not well tested, the API is not
fixed, etc. Now IDK this specific case of Flask, but there is no one single
release cadence that fits all, nor do the releases need be periodic.

~~~
wpietri
Yes, I think the problem here is that you're opining without understanding the
specific case, a case that the rest of us are talking about.

The general discussion of release philosophy could be interesting. If you
would like to talk about that, you should start a new topic, or at the very
least make it clear you're changing the topic. When you reply to somebody's
specific statements with sweeping generalities, as you did here, it looks like
contradiction.

------
codegeek
Love Flask. I don't do it anymore for other reasons but flask is what got me
started with web frameworks that are minimal but powerful. What I love about
flask is that it does not do too much magic like django even though this is
not meant to demean django of course. It makes me think and make some choices.
Since the core is minimal, you still have to learn a few things to really
understand how to put together a decent web app or an API but I really feel
that is the strength of flask.

My belief is that when you are learning, start with a minimal framework so
that not everything is already done for you a.k.a magic. That will make you
think and make some choices. Sure it may be amateur choices in the beginning
but you will become a better developer. So if you want to learn python for
web, go with Flask.

~~~
chucksmash
"What I love about flask is that it does not do too much magic like django"

So having used both, I'd nitpick you on this assertion.

    
    
        from flask import request
    

to get at the individual request objects is sooooo much more magical than

    
    
        def my_view(request):
    

(IMO)

Nevertheless, it's a good framework!

~~~
Svenstaro
I agree on that. The magical globals are also my biggest problem with flask.
Other than that, it's a very solid framework that obviously has had lots of
thought go into it.

~~~
m_mueller
I think this is just a design choice to avoid confusion between request /
session parameters in the view functions versus path parameters.

It's quite nice that you can just do

@route("/<post_id>")

def my_view(post_id):

    
    
       ....
    

never having to register anything and just decorating your functions with
these path decorators gets you started really really fast. That's how a flask
hello world is just 6 LOC and `python ./my_server.py`.

------
johnwheeler
I just released my first Flask extension called Flask-Ask for developing
Amazon Echo skills [https://github.com/johnwheeler/flask-
ask](https://github.com/johnwheeler/flask-ask)

Flask is a fantastic, minimal framework, and Mitsuhiko did so much to help new
developers integrate into the ecosystem he created. For example, I was able to
use his documentation templates [https://johnwheeler.org/flask-
ask/](https://johnwheeler.org/flask-ask/), and he had multiple versions for
small and large projects. When you dive in it's pretty amazing what they've
accomplished over the last 5 years.

------
rcarmo
This is nice to see. I don't use anything but
[http://bottlepy.org](http://bottlepy.org) these days because I find the
decorator approach to be more elegant, but I do have a few Flask-based tools I
adopted, and (for instance) patching them to serialize datetimes was a pain.

~~~
jaxondu
Switch to use Bottle for rest API as Flask has dependencies such as Jinja2
that I don't need.

~~~
noinsight
There's also the Falcon framework that claims to be faster and is meant for
REST APIs.

[http://falconframework.org/](http://falconframework.org/)

~~~
bizzleDawg
Falcon is great for making API's! I've used it on a few production sites. The
main downside is the lack of middlewares for common tasks (e.g. jwt decoding)
but you gain in other areas such as being able to use class inheritance to
abstract out utility stuff in an elegant way.

~~~
bigethan
Take a look at Hug - it's built on Falcon and adds all the API niceties :-)
[https://github.com/timothycrosley/hug](https://github.com/timothycrosley/hug)

------
level09
Someone might find this project helpful:

[https://github.com/level09/enferno](https://github.com/level09/enferno)

This is a Flask based framework designed with best practices in mind, it comes
with many nice preconfigured modules and modern features:

* Gulp integration (sass, minify etc ..)

* Fully configured flask security out of the box (register/login/reset etc ..)

* Cache, Blueprints, Mysql/Nosql, Mail, Background tasks, ORM etc ..

* Debug toolbar

* Command line (Flask script) to help you control your app

* A deployment script that fully configures your server in minutes (Ubuntu):

[https://github.com/level09/enferno-
ansible](https://github.com/level09/enferno-ansible)

edit: I'll get this project upgraded to 0.11 to integrate the nice new
features, any recommendations/notes are welcome.

------
agumonkey
Tests ported to py.test. I never got a full understanding on which python unit
test lib I should use ..maybe that's a hint.

ps: well thanks for the hints below guys.

~~~
scrollaway
I would highly recommend pytest. It's very simple, very pythonic.

Here is for example my Hearthstone simulator, with ~600 pytest-compatible
tests:
[https://github.com/jleclanche/fireplace/tree/master/tests](https://github.com/jleclanche/fireplace/tree/master/tests)

It's just plain asserts. You run it with `py.test`. Nothing simpler.

~~~
thristian
Man, I never understood the love for py.test.

People say "it's Pythonic, you just use asserts", but asserts aren't Pythonic.
For one, asserts are removed when you run Python with "-O", so, uh, good luck
running your test suite in that configuration. Secondly, crawling up the stack
to inspect the bytecode to figure out what condition was actually asserted so
you can print a nice error... that's the _opposite_ of Pythonic.

Sure, the unittest module in the standard library is a bit Java-ish, but it's
much less magic, and I feel like keeping per-test state in a class that gets
instantiated multiple times is more Pythonic than having everything be top-
level functions.

And of course unittest is in the standard library, which means that most apps
and libraries are going to use it, most people are going to be familiar with
it, so your app or library will be more approachable to co-workers and/or
contributors if it's tested the same way. Heck, a lot of Python frameworks
have their own test helpers built on top of unittest (hello, Twisted and
Django!) so you don't get to choose anyway.

You _could_ write Python code with three-tab indents, but you should use
4-spaces like everybody else. You _could_ write your own custom packaging and
dependency management system, but you should use setuptools like everybody
else. You _could_ any number of custom test harnesses, but you should use
unittest like everybody else.

~~~
orf
> For one, asserts are removed when you run Python with "-O", so, uh, good
> luck running your test suite in that configuration

Which is not something anyone has ever wanted.

> Sure, the unittest module in the standard library is a bit Java-ish, but
> it's much less magic, and I feel like keeping per-test state in a class that
> gets instantiated multiple times is more Pythonic than having everything be
> top-level functions.

It's really really unpythonic. It looks horrible and leads to messy tests.
With pytest you get dependency injection via fixtures which cuts down on so
much repetitive initialisation code.

We've got both kinds of tests in our codebase, and the pytest ones are a lot
nicer to write and refactor.

~~~
291289812
"Unpythonic" must be something positive. Whenever someone uses that word, I
like the code or the application in question.

"Pythonic" seems to mean using magic until an application works in 99% of the
cases, satisfies some superficial criteria of readability to those intimately
familiar with it and is utterly un-debuggable for those who aren't.

~~~
orf
> Whenever someone uses that word, I like the code or the application in
> question.

Then either they are not describing something unpythonic or you can't
visualize how better the code would look if it was pythonic.

> "Pythonic" seems to mean using magic until an application works in 99% of
> the cases, satisfies some superficial criteria of readability to those
> intimately familiar with it and is utterly un-debuggable for those who
> aren't.

Not at all, it's usually exactly the opposite. Open a python shell and type
"import this", if Python code satisfies a large enough number of those then
it's Pythonic.

The first six pretty much sum it up:

> Beautiful is better than ugly.

> Explicit is better than implicit.

> Simple is better than complex.

> Complex is better than complicated.

> Flat is better than nested.

> Sparse is better than dense.

Words to live by. They all help improve debugging and readability.

~~~
9912121qwq
Hardly anyone writes code like that in the Python world. It's all about
features and gross hacks.

------
bsaul
Didn't expect a new flask release because i had the feeling the author moved
to rust development. did anything change recently ?

~~~
nzjrs
I think you were mistaken.

~~~
AtlasLion
I remember him saying that on a podcast. maybe talk python to me.

------
calypso
I used Flask a few years ago to write a rather large api server (20k lines)
for a video sharing app. I learned that they give you a lot of control but it
can get messy quickly if you're not careful about properly architecting first.

I ended up getting the Flask Cookbook from O'reilly which helped me understand
how to structure a Flask App.

I also recommend Flask-SQLAlchemy as it made writing and manipulating MySQL
queries really straightforward.

------
Brainix
Who's got two thumbs and has already deployed Flask 0.11 to production? This
guy.

------
StevePerkins
I know that version numbers don't necessarily mean anything. Wine took 15
years to get to 1.0, while Chrome and Firefox increment major version numbers
every few weeks. But it still seems odd to have a major web framework at 0.11
after six years.

~~~
JustSomeNobody
If it is working like it is supposed to, I don't see what the problem is.

~~~
michaelmior
No real problem. But I think many can have an subconscious bias that any
software at 0.x is unstable. This is how semver[0] treats 0.x releases and it
was a common convention long before that.

[0] [http://semver.org/](http://semver.org/)

~~~
reidrac
Each project may have a different versioning scheme and that's just fine. Not
everyone follows "semver" (although it sounds sensible to me).

~~~
michaelmior
Sure. Nothing wrong with whatever (sensible) versioning scheme a project
decides to use. But I think version numbers do bias the perceived stability.
If I had never heard of Flask and I saw that version 0.11 was released after
three years of no new releases, my gut reaction would probably not be overly
positive. That said, Flask is indeed a great piece of software :)

------
idm
I wanted to mention Flask-Diamond in this thread because it can be used to
scaffold large applications quickly, sortof like Django.

[http://flask-diamond.org](http://flask-diamond.org)

One reason you might use Flask-Diamond instead of Django is because you might
not need everything Django provides, so you want to remove libraries one at a
time. Or, perhaps, you want to upgrade libraries one at a time. I've found
it's easier to start with a full-blown Flask app, then remove things, rather
than starting with a barebones app that I add to.

------
aregsarkissian
Are there any plans to integrate the flask-failsafe functionality into flask
proper so that flask reloads automatically after a syntax error is corrected
and the file saved?

~~~
nathancahill
I believe the Flask development server does that already?

~~~
ju-st
No, the dev server can only handle runtime exceptions

------
kayman
I love flask. web.py used to be my "go-to". But as its development has not
been as active, I moved over to Flask for the community.

When I know I need an admin and lots of built in items out of the box, I
choose Django.

But a quick prototype, always start with Flask.

------
zxcvcxz
Are there any high traffic web pages using Flask? I'm interested but when I
look at job listings it's really rare I see anything for flask compared to
React/Angular/RoR.

If I was a python dev it seems like it might be worth learning but since I'm a
web dev and already know a few frameworks I'm struggling to find a reason to
teach my self flask.

Does Flask have any advantage over something like Angular?

~~~
brbsix
Not sure what kind of traffic they get, but httpbin.org uses it. Also this one
site named Pinterest.

~~~
keshab
I am sorry, but it seems that Pinterest is written using Django.

[https://www.djangoproject.com/start/overview/](https://www.djangoproject.com/start/overview/)

~~~
tomnipotent
Moved off Django to Flask.

[https://www.quora.com/What-challenges-has-Pinterest-
encounte...](https://www.quora.com/What-challenges-has-Pinterest-encountered-
with-Flask)

~~~
dempseye
That page does not support the statement that they moved off Django to Flask.

~~~
lrem
But it supports that they do use Flask.

> Presently, the API does over 12 billion requests per day, all in Flask.

Wow, that is 138kqps. Not something that would strike me as your typical
Python workload.

~~~
nly
Whacking great big CDNs in front of your infra will do that.

~~~
lrem
What exactly a CDN can do to increase the qps throughput of your backend? I
thought it's used to reduce it...

------
ZLeviathan
moving too slow...

