Flask 0.11 Released
flask.pocoo.org
flask.pocoo.org
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 (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/ 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 simple users management (roles, authentication, etc.);
3) Flask-SQLAlchemy http://flask-sqlalchemy.pocoo.org/2.1/ simple integration with SQLAlchemy
4) Flask-Script 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).
I'd love a re-write of http://web2py.com that conforms to pythonista expectations.
It's the flexibility versus batteries included tradeoff, and I don't think it's a negative that Flask doesn't ship most of that. You could probably somewhat get there with a number of third party additions (gedrap mentioned some) but you might as well use Django if you find yourself needing that stuff baked in.
https://github.com/GoogleCloudPlatform/appengine-python-flas...
This got me going with Flask. It's not quite everything you asked for but it lays a foundation upon which to build and explore the different features you've listed. And App Engine's free tier provides a nice platform for prototyping and simplifies deployment.
cookiecutter https://github.com/sloria/cookiecutter-flask.git
Flask-Assets makes you list every static file in a giant config, aka registering your assets in bundles. There is no need for that mess.
That said, you shouldn't have to manually test anything—that's what automated tests are for. With regard to testing Flask applications specifically, there is a guide[0] in the docs that covers everything you need to get started.
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.
In any case: Congrats :)
Glad to see Flask's development is back on track, and under formal management!
Glad to see 0.11!
https://github.com/pallets/flask/issues?q=is%3Aopen+is%3Aiss...
Blog post about it: https://www.palletsprojects.com/blog/flask-011-released/
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.
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.
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.
pip install git+https://github.com/pallets/flask.git
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.
All the new features/fixes, contributions finally being released, the increase in development activity, it's all bullshit, people only care about the digits.
Sigh. You're projecting.
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.
So having used both, I'd nitpick you on this assertion.
from flask import request
def my_view(request):
Nevertheless, it's a good framework!
It's quite nice that you can just do
@route("/<post_id>")
def my_view(post_id):
....
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/, 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.
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
edit: I'll get this project upgraded to 0.11 to integrate the nice new features, any recommendations/notes are welcome.
ps: well thanks for the hints below guys.
Here is for example my Hearthstone simulator, with ~600 pytest-compatible tests: https://github.com/jleclanche/fireplace/tree/master/tests
It's just plain asserts. You run it with `py.test`. Nothing simpler.
For those who don't know fixtures are a type of dependency injection. You just make a function (e.g game) in a file called conftest.py, and wrap it with a '@pytest.fixture'. Then any tests you write that have an argument named 'game' will have the result of the 'game' function passed as a value.
So 'game' could return 'prepare_game()', and other fixtures can do the same with their arguments to build more complex fixtures. I find it saves a load of initialization code being repeated.
[0] http://stackoverflow.com/a/11837973
[1] https://robots.thoughtbot.com/lets-not#will-our-mystery-gues...
I should definitely use fixtures - been meaning to! It's why I love pytest, you don't need to go deep into it to make a high quality test suite.
My plan was to get rid of the "game = prepare_game(...)" line that's present on every single test, and have the game be passed as an argument to the tests which AIUI pytest supports.
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.
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.
"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.
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.
In fact, a lot of the arguments still apply. "urllib3 is in the stdlib, why use requests?". I can get behind that argument in specific cases, too - I have a library which uses urllib3 because it only ever needs to GET from a couple of URLs and introducing an extra dependency just for that is a hassle.
But here's the thing about tests. You want them to be clear, you want them to be easy, painless and even fun to write. pytest achieves that. unittest doesn't. If you're serious about testing, unittest will harm your project.
no one ever does this
Yes Pytest is black magic(I tried and failed to understand it for my own dark purposes). But it lets you get context without violating repeating yourself over and over.
That's almost entirely all python -O actually does. The only other thing it does is set __debug__ to 0. There's essentially no real value in running code with the -O flag.
Both are best of breed, and complementary, IMHO.
While looking at nose, I ran across this: https://nose.readthedocs.io/en/latest/
> Note to Users: Nose has been in maintenance mode for the past several years and will likely cease without a new person/team to take over maintainership. New projects should consider using Nose2, py.test, or just plain unittest/unittest2.
That made me not want to investigate nose any further, and I decided I had to just decide and move on, and chose unittest. The suggestion to use unittest in the Note helped make that easier.
Maybe next time I'll use pytest, but I think the issue in the Note will dissuade me from using nose unless it's resolved.
As such, you need pytest, nose or unittest + ddt|nose-parameterized.
https://talkpython.fm/episodes/show/13/flask-web-framework-a...
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.
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.
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.
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?
There are two main features of Flask for me, over something like RoR: it's Python (my preference over Ruby); and it's a very light framework with a ton of modules, compared to my perception that RoR is pretty big and heavy and opinionated.
YMV, I only do this stuff in my evenings so I'm not terribly familiar with it all.
https://www.quora.com/What-challenges-has-Pinterest-encounte...
> 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.
I don't know if it still is, but when I was at Mozilla the service that every instance of Firefox around the world hits to do the version/extension-compatibility checks was backed by Django, and was at something like 15k req/s served. Firefox has gained some market share in the four-ish years since I got that number, so probably larger now.
https://www.quora.com/What-is-the-technology-stack-behind-Pi...
> They started with Django but moved out of Django and currently use 'home grown framework on top of Flask'.
I don’t know what you’d consider high traffic, but we have used and continue to use Flask in production for a variety of systems. Those include:
- providing the back ends for relatively large and complicated single-page applications;
- implementing more traditional web sites, with very little JS on the front end, which use Flask to do almost all of the routing and rendering; and
- implementing dedicated HTTP-based APIs for integration with third party services.
Flask is an excellent tool, and that is not a description I use for very much in the software world. It provides widely useful functionality, it has a tidy design and a reliable implementation, it’s well documented, and it imposes few overheads or unnecessary dependencies. If you’re purely a front-end dev then that functionality isn’t what you need and neither is Flask. If you’re interested in the back end as well, you could do a lot worse than to learn Flask.
Angular = Front end
Bizarre you are comparing them. Suggests you have not used either.
I have no idea where you are looking for jobs but where I am demand for Flask and Django are booming and there is a shortage of them.
You should be comparing it to micro web frameworks like Nodejs' Express, Ruby's Sinatra, PHP's Slim, Java's Spark, etc.
Uber uses Flask & Nginx for part of their site.
The 2012 Obama campaign team (who really shook up the use of internet & tech in campaigning) used Flask too.
Mailgun uses Flask for their API (reported). Stack is verified here, but no details given: http://stackshare.io/mailgun/mailgun
That's because Flask is simple. You advertise RoR when you want somebody who doesn't need to spend a lot of time learning Rails. But nobody needs to spend a lot of time learning Flask.
That's also a drawback of Flask, in that you have to build or add more to get the same higher-level expressiveness of something like Rails. But if what the project needs is a relatively low-level web framework, it's a fine, easy-to-learn choice.