Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

New Werkzeug and Flask Releases

lucumr.pocoo.org

Post reply on HN
Print view View original

41–50 of 59 posts

Re: New Werkzeug and Flask Releases

#41

Post by coldtea »

obviouslygreen wrote: post #36
Timothee wrote: post #31

Earlier quoted context omitted.

Twilio uses it to run their API. So, that must be very reliable. "Flask-RESTful was initially developed as an internal project at Twilio, built to power their public and internal APIs" http://flask-restful.readthedocs.org/en/latest/

While I'm not disagreeing on the quality of Flask, "x uses y, so y must be stable" is the same kind of argument as "Facebook runs on PHP, so PHP must be blazing fast." Yeah, there are large web companies using all sorts of tech, but what else they're using alongside it and how they've adapted it to their needs make this sort of commentary questionable at best. It's definitely nice to see other responses here that are…

>While I'm not disagreeing on the quality of Flask, "x uses y, so y must be stable" is the same kind of argument as "Facebook runs on PHP, so PHP must be blazing fast."

No, the argument is the same: "Facebook runs on PHP, so PHP must be stable".

Which makes sense. A base technology that holds up with half a billion users, I would call production ready.

As for fast, if you look at the most comprehensive benchmarks, PHP is more or less on par with Ruby/Python for raw speed of simple page serving, but when multiple DB connections are used in a page (which is the most common case for dynamic pages), it leaps far ahead, and reaches Servlet and Go levels of reqs/sec.

Re: New Werkzeug and Flask Releases

#42

Post by irahul »

coldtea wrote: post #39
habitue wrote: post #20

Earlier quoted context omitted.

Right, he's implying that the implementation is not as complete, or is incorrect because the problem space is more complex than that.

He is implying with not any evidence, aka FUD.

He is implying with the evidence that werkzeug which he wrote is much bigger than bottle owing to complexities of wsgi/http, and bottle's smaller size means either the implementation is incomplete or the implementation is too clever or both.

Re: New Werkzeug and Flask Releases

#43

Post by irahul »

cstuder wrote: post #33

So we're a PHP shop thinking about moving to Python. With this release, can we immediately start using version 3? The Flask page still recommends holding back... ( http://flask.pocoo.org/docs/python3/ )

> With this release, can we immediately start using version 3?

You should stick with 2.7 As mentioned in your linked blog post, porting Flask to Python 3 wasn't the issue. The issue is the other libraries which you will use to build your web application which aren't on Python 3 yet. You can try to build a unified code base(runs on both 2.7 and 3) http://lucumr.pocoo.org/2013/5/21/porting-to-python-3-redux/

Re: New Werkzeug and Flask Releases

#44

Post by corford »

cstuder wrote: post #33

So we're a PHP shop thinking about moving to Python. With this release, can we immediately start using version 3? The Flask page still recommends holding back... ( http://flask.pocoo.org/docs/python3/ )

Like irahul has said, the issue is the Flask extension ecosystem and documentation lag rather than Flask itself. Which basically means YMMV depending on what you need to get done :)

If you are writing most of your own code and not using Flask extensions then you could well be fine (unless, like the linked post says, you discover a few months down the line you _do_ need a couple of extensions and they haven't been ported yet!).

Also worth pointing out that lots of other great python libraries now fully support python3 so you can get a lot done with just Flask on its own and those e.g. requests, redis-py, psycopg2, pytz.

Re: New Werkzeug and Flask Releases

#45

Post by reinhardt »

bjourne wrote: post #6

Flask is about the most beautiful Python code you can write. Check out any other Python framework and they may have a decent api, but on the inside it is messy and confusing. Reading Flask source code on the other hand is a joy. There's no crazy stuff and few convoluted pieces + lots of comments so it is really easy to hack something if you must. Any Python coder who wants to improve their game definitely should stud…

> There's no crazy stuff and few convoluted pieces

I dunno, I've recently started getting into it and "convoluted" is one word that has occurred to me more than once. Handlers vs signals, application and request context, context locals, local proxies, etc.. Probably there's a good reason for all these and the docs make a decent attempt to lay them out but overall my unscientific first impression is that it's not exactly a pinnacle of simplicity.

Re: New Werkzeug and Flask Releases

#46

Post by the_mitsuhiko »

reinhardt wrote: post #45
bjourne wrote: post #6

Flask is about the most beautiful Python code you can write. Check out any other Python framework and they may have a decent api, but on the inside it is messy and confusing. Reading Flask source code on the other hand is a joy. There's no crazy stuff and few convoluted pieces + lots of comments so it is really easy to hack something if you must. Any Python coder who wants to improve their game definitely should stud…

> There's no crazy stuff and few convoluted pieces I dunno, I've recently started getting into it and "convoluted" is one word that has occurred to me more than once. Handlers vs signals, application and request context, context locals, local proxies, etc.. Probably there's a good reason for all these and the docs make a decent attempt to lay them out but overall my unscientific first impression is that it's not exac…

> application and request context, context locals, local proxies

Those are just different names for the same thing. Maybe the docs are a bit too in-your-face with the contexts but I rather expose people to it early to avoid issues down the line.

Django for instance does not have equivalents for application and request contexts and the end result is that people often write thread unsafe code and you can only have one application per Python interpreter. Flask does not have those restrictions. You can have as many Flask applications living side by side. And that is possible because of the contexts.

Re: New Werkzeug and Flask Releases

#47

Post by sirclueless »

the_mitsuhiko wrote: post #46
reinhardt wrote: post #45

Earlier quoted context omitted.

> There's no crazy stuff and few convoluted pieces I dunno, I've recently started getting into it and "convoluted" is one word that has occurred to me more than once. Handlers vs signals, application and request context, context locals, local proxies, etc.. Probably there's a good reason for all these and the docs make a decent attempt to lay them out but overall my unscientific first impression is that it's not exac…

> application and request context, context locals, local proxies Those are just different names for the same thing. Maybe the docs are a bit too in-your-face with the contexts but I rather expose people to it early to avoid issues down the line. Django for instance does not have equivalents for application and request contexts and the end result is that people often write thread unsafe code and you can only have one…

There is a difference. Having a request or application context that encapsulates state is one thing, an architectural decision that simplifies multi-tenancy and makes many uses of Flask more performant. These are "simple", in that they are an obvious and easily-explained solution to a technical problem that exists by necessity.

Global proxies to local state are another beast entirely. They are "easy" in that they remove the need to pass application and request objects through every called function, but they are not "simple" -- they rely on intimate details and peculiarities of Python's module and import system, and its capacity for thread-local state, not to mention Python's robust context unwinding features in the case of exceptions. Overuse of context-proxies leads to the same software engineering challenges as overuse of globals, in that it becomes difficult to reason about the calling semantics of functions which rely on context state being present, or mutate context state through proxies. For example, in order to test a view function, you will at a minimum need to set up an application context, but also need to set up any custom context your app relies on. It's not always obvious how to do this, leading to documentation [1] that I notice has already been confusing people on the mailing list.

So I wouldn't conflate the two mechanisms. Application- and request-local context is a pre-requisite for multi-tenant applications and a conceptual simplification. Module-level proxies are a cute trick that makes programmers' lives easier, but undoubtedly creates more convoluted semantics and internal operation.

[1]: http://flask.pocoo.org/docs/testing/#faking-resources-and-co...

Re: New Werkzeug and Flask Releases

#48

Post by coldtea »

irahul wrote: post #42
coldtea wrote: post #39

Earlier quoted context omitted.

He is implying with not any evidence, aka FUD.

He is implying with the evidence that werkzeug which he wrote is much bigger than bottle owing to complexities of wsgi/http, and bottle's smaller size means either the implementation is incomplete or the implementation is too clever or both.

Still no evidence in your comment.

Repeating his "I had to make X big to support all of wsgi/http so anyone who made a similar framework but much smaller has made it incomplete or too succint and clever in a bad way" is not evidence.

You say:

>bottle's smaller size means either the implementation is incomplete or the implementation is too clever or both.

That's a statement of fact (actually a dichotomy of facts). What's the evidence to support these are the only two possible options?

The mere fact that Armin had to make Werkzeug bigger "owing to complexities of wsgi/http" is not proof.

To take it as proof is to assume his coding (and understanding of wsgi/http) as the golden standard by which the Bottle developer should be measured.

Who said this is the case? For one, it took him a year after Bottle to support Python 3, so he might not be that focused, anyway.

My problem is that, the way he and you say it, "incomplete" implies broken or lacking, whereas "too clever" implies fancy tricky code that's too succinct for it's own good.

How about the third option that he needlessly convoluted Werkzeug to work around wsgi/http edge cases that no one really faces, whereas Bottle has been pragmatic about it?

Or the fourth option, that Werkzeug is needlessly verbose, whereas Bottle is not "too clever" but just as clever as needed?

Re: New Werkzeug and Flask Releases

#49

Post by jessaustin »

coldtea wrote: post #48
irahul wrote: post #42

Earlier quoted context omitted.

He is implying with the evidence that werkzeug which he wrote is much bigger than bottle owing to complexities of wsgi/http, and bottle's smaller size means either the implementation is incomplete or the implementation is too clever or both.

Still no evidence in your comment. Repeating his "I had to make X big to support all of wsgi/http so anyone who made a similar framework but much smaller has made it incomplete or too succint and clever in a bad way" is not evidence. You say: > bottle's smaller size means either the implementation is incomplete or the implementation is too clever or both. That's a statement of fact (actually a dichotomy of facts). Wh…

It would have taken less effort just to try out both frameworks, and then you wouldn't need anyone else's "evidence".

Re: New Werkzeug and Flask Releases

#50

Post by aptwebapps »

schleppy_oc wrote: post #22
aptwebapps wrote: post #21

Earlier quoted context omitted.

I doubt he or she was aware it was 3500 lines long. While not the same as 15000, it isn't all that far off.

I am pretty certain that he, the_mitsuhiko (aka. Armin Ronacher), being the main developer behind Werkzeug and Flask knows exactly how long bottle.py is.

Yeah, I did't know who he was and I took it as a drive-by comment. I somehow missed the "I know I'm biased ..." bit unless he edited the post after I replied.
Post reply on HN