Flask 0.9 codename Campari released today(github.com)
github.com
Flask 0.9 codename Campari released today
https://github.com/mitsuhiko/flask/blob/master/CHANGES
10 comments
I'm guessing that this section of the docs http://flask.pocoo.org/docs/advanced_foreword/#the-status-of... will get updated once the status changes.
Yep, I read that, and was e.g. wondering whether the upcoming 3.3 did anything to address the issues alluded to there.
Basically, it's a developing situation and it's not economical to change that text for every inch things move, but I'd love to hear what's in flight right now in this less formal context.
Basically, it's a developing situation and it's not economical to change that text for every inch things move, but I'd love to hear what's in flight right now in this less formal context.
This very section is that worries me.
Nobody ever bothered updating it, not when the relevant WSGI spec came out, and not when Python 3.3 announced the byte str changes that would help.
If even Django and Pyramid can have a 3 roadmap --and even implementation--, surely Flask could too.
Seems like they just dont bother, so they put it in the backburner. Which is mighty fine, its a volunteer project after all, but I find said document misinforming, to say the least.
Nobody ever bothered updating it, not when the relevant WSGI spec came out, and not when Python 3.3 announced the byte str changes that would help.
If even Django and Pyramid can have a 3 roadmap --and even implementation--, surely Flask could too.
Seems like they just dont bother, so they put it in the backburner. Which is mighty fine, its a volunteer project after all, but I find said document misinforming, to say the least.
FYI, the author of Flask was the same person who proposed and published the PEP on the byte str changes.
[deleted]
Python 2 is starting to smell very "legacy" and stuff that isn't moving to Python 3 is starting to look less relevant.
Considering that some of the most common libraries aren't on Python 3, I'd hardly call Python 2 "legacy".
Until the libraries you need at least support Python 3, it's not worth even starting to move across.
Until the libraries you need at least support Python 3, it's not worth even starting to move across.
That's an old wives tale that is getting older by the day. People like to roll that excuse out not to move to Python 3 and it may have been true in the past but there are now enough libraries available to get most stuff done in Python3. It is true that the laggards are starting to look like the are living in the past. Python3 was released 3.5 years ago and is getting a real head of steam. Projects that don't move over will eventually get replaced entirely by projects that have either moved to, or been created onl for, Python3. This old "the libraries aren't available for Python3" story is a legacy story too and just sounds like an excuse.
The most-used web framework not supporting Python 3 is just an old wives' tale?
https://www.djangoproject.com/weblog/2012/mar/13/py3k/
Even in 1.5, Django's Python 3 support will be "experimental". This, quite simply, takes Python 3 off the table for the foreseeable future.
The major Linux distributions (Ubuntu, Fedora) aren't aiming for full Python 3 support until 2014 which. The core Python team themselves aren't expecting Python 3 usage to take off until 2014 either.
In real-world usage, we can't all just drop all the libraries we're using and switch over to another because "it's new".
https://www.djangoproject.com/weblog/2012/mar/13/py3k/
Even in 1.5, Django's Python 3 support will be "experimental". This, quite simply, takes Python 3 off the table for the foreseeable future.
The major Linux distributions (Ubuntu, Fedora) aren't aiming for full Python 3 support until 2014 which. The core Python team themselves aren't expecting Python 3 usage to take off until 2014 either.
In real-world usage, we can't all just drop all the libraries we're using and switch over to another because "it's new".
Exactly my point. Projects that don't make the transition risk being perceived as legacy and irrelevant. There is real opportunity here for new solutions that embrace the new rather than stoically stay in the old.
What is your point exactly?
Can you provide a single solid reason to upgrade to Python 3 beyond "it's new"? In the real world, the advantages of using Python 3 must outweigh the negatives before I can justify upgrading our systems to it. Currently, all I can see is a minimum of 1 year of downtime while I either:
1) Wait for Django 1.5, and deal with all the bugs resulting from the upgrade, or 2) Move our entire code base out of Django into something else, and deal with all the bugs from, effectively, moving to an untested system.
Can you provide a single solid reason to upgrade to Python 3 beyond "it's new"? In the real world, the advantages of using Python 3 must outweigh the negatives before I can justify upgrading our systems to it. Currently, all I can see is a minimum of 1 year of downtime while I either:
1) Wait for Django 1.5, and deal with all the bugs resulting from the upgrade, or 2) Move our entire code base out of Django into something else, and deal with all the bugs from, effectively, moving to an untested system.
While Flask started as a joke I am happy to see it evolve! For me it's by far the most focused and polished framework for Python!
One of the nicest things about Flask, for me, is there isn't any boilerplate. Unlike django, I don't need a script to produce a bunch of boilerplate code for me, just to create an app. I can type out some code, and run it. There isn't a "required" set of files.
? web.py? Tornado? Any microframework?
Yeah, I'm sure some other microframeworks do it too.
[deleted]
Clearly you haven't tried Pyramid yet ;-)
I have, Flask is better. Pylons and Pyramid aren't that great.
> Pylons and Pyramid aren't that great.
interesting! what don't you like about Pyramid? you're aware it is not a continuation of the Pylons codebase, right?
interesting! what don't you like about Pyramid? you're aware it is not a continuation of the Pylons codebase, right?
Actually, as a Flask fan and long-time Djangonaut, I'd like to know what you find so good about Pyramid—where does it shine?
No, I don't. I and most people still don't understand what Pylon/Pyramid is and their page that tries to explain it does nothing but make the problem worse.
They belong to the same family of interchangeable parts, seemingly used by people who haven't used a web framework that doesn't begin with the letters Dj.
Ok, fair enough, do you have any argument on what "flask does better" than pyramid? Because as far as i can tell, pyramid does more and better out-of-the-box - like extensible permission system.
I would really love to know what IS better in flask, especially since Pyramid oficially supports Py3 and PyPy, and that also seems to be a big thing to me.
I would really love to know what IS better in flask, especially since Pyramid oficially supports Py3 and PyPy, and that also seems to be a big thing to me.
The CHANGELOG is ReST-formatted for Sphinx; might as well view it the way it is meant to be viewed:
http://flask.pocoo.org/docs/changelog/#version-0-9
http://flask.pocoo.org/docs/changelog/#version-0-9
Curious how Flask compares to Bottle, in terms of features, "developer velocity", performance?
More features (such as the included Jinja2 templating system), similar developer velocity (built on the same principals and concepts), probably similar performance, since both rely on external http(s) servers to handle the heavy lifting.
The main advantage bottle holds over flask is that it's a single file that you can import, instead of a package. Makes it very portable.
The main advantage bottle holds over flask is that it's a single file that you can import, instead of a package. Makes it very portable.
As someone who is not a web developer, but has a need to create a few internal apps, portable sounds like simple - exactly what I need.
My desire: (1) grab data, (2) render chart / graph, (3) display in browser
Without needs like session management, concurrency, etc., Bottle "sounds" easier, which is mostly based on the 1 file import thing, and why I was looking at Bottle last time I did not get this project rolling.
My desire: (1) grab data, (2) render chart / graph, (3) display in browser
Without needs like session management, concurrency, etc., Bottle "sounds" easier, which is mostly based on the 1 file import thing, and why I was looking at Bottle last time I did not get this project rolling.
You can do the "1 file thing" with either. It's enforced in Bottle but not in Flask. I've used both and would recommend going with a Flask(web-framework)/SQLAlchemy(database or part that "grabs data") combo that sends JSON to a javascript chart/graph library.
You should be able to find a number of Flask/Backbone demos on github. Checking out a few of those would be a good place to start, even though you'll probably be scrapping backbone and just using a javascript charting library instead.
You should be able to find a number of Flask/Backbone demos on github. Checking out a few of those would be a good place to start, even though you'll probably be scrapping backbone and just using a javascript charting library instead.
> You can do the "1 file thing" with either.
The GP was referring to bottle.py being one file and one import, not about the ability to have the whole app in one file.
The GP was referring to bottle.py being one file and one import, not about the ability to have the whole app in one file.
I use Flask routinely for exactly what you've described. The 'blueprint' approach to modularity keeps things dead simple.
Based on your description here, you would do well to use either one. Just based of my experience, I'd go with Bottle, and when/if you hit the limit of its functionality, you can pretty much seamlessly convert between the two.
Flask is great, and offers you so much more flexibility, but there's just something about the simplicity of Bottle that draws me back to it whenever I need to make a simple web app.
Flask is great, and offers you so much more flexibility, but there's just something about the simplicity of Bottle that draws me back to it whenever I need to make a simple web app.
I had looked at Bottle for a similar reason some time ago. Looking into using Bottle and Highcharts for a first experiment. Maybe Google Charts as well.
How is that any easier than just using a virtualenv for anything but the most simple of scripts with zero other dependencies?
Given that the parent was asking for nearly exactly that (a simple script with few/if any other dependencies), a virtualenv would not be easier.
A virtualenv would certainly be proof against future environment changes, perhaps, but it would probably be more effort than necessary for simple forms.
A virtualenv would certainly be proof against future environment changes, perhaps, but it would probably be more effort than necessary for simple forms.
virtualenv . --no-site-packages; source bin/activate; pip install flask
Three commands. Even less if you use virtualenvwrapper.
Plus, you are insane if you don't use virtualenvs for development anyway.
Three commands. Even less if you use virtualenvwrapper.
Plus, you are insane if you don't use virtualenvs for development anyway.
Pretty sure they meant Campari, though choosing to put that in a flask is kind of weird.
For Europython i wanted something that goes with italy :)
For the curious, http://en.wikipedia.org/wiki/Campari
You'd need to put a generous amount of soda water in that flask.
You'd need to put a generous amount of soda water in that flask.
Very nice. Almost painless upgrade here; had to make one change to my custom create_url_adapter to adjust for the possibility of request being None, but that was a minor change and documented to boot. Flask rocks.
> - The :func:`flask.url_for` function now can generate anchors to the generated links.
Should clean up my templates a bit! Nice little change.
Should clean up my templates a bit! Nice little change.
Clearly this means 1.0 is around the corner. Any specific features, changes etc, that needs to be worked on, for 1.0?
I don’t see why 1.0 should necessarily follow 0.9. The whole point of having a dot in there is that we can make a 0.10.
That said, maybe 1.0 is around the corner. But I have not seen much more indication of that than after 0.7 or 0.8.
That said, maybe 1.0 is around the corner. But I have not seen much more indication of that than after 0.7 or 0.8.
3 cheers for Flask. I like how simple yet powerful this framework is. So far, I am loving it. Pretty soon looking to bootstrap one of my ideas using this framework.
Edit: Why the downvote? I'm just fishing for anybody having newer info than what's on the website out of genuine interest and because HN tends to be a place where people would know; it's not meant as a troll.