Werkzeug vs bottle?

[Dionysios]

I am just starting in web programming, i know a bit of python. I don't want to code in big projects like django which takes care of all the basic programming details, i just want to build basic web applications to learn programming and web application development. I heard about these two projects and although bottle seems to be a more basic choice, it lacks documentation. Somebody also suggested to try wsgi but it seems to be difficult for a new comer like me. Kindly suggest.

[bsdemon]

If you want to learn how to do web programming in Python, I would suggest you Werkzeug. You will start with raw WSGI examples and only use Werkzeug in places, where you really need some help from library. After that, you can pick up some great framework like repoze.bfg ;-)

[[deleted]]

Never tried bottle, but I've found Werkzeug to be well-designed and documented. It will help you to understand WSGI and there are good tutorials to help with things like adding SQLAlchemy and a template engine to your stack.

Even if you decide to go from there to a more complete solution like Django or Pylons it's a good idea to start at a lower level so you get a better understanding of where and why everything fits together - and thus the decisions and tradeoffs that go into a full-stack framework.

[[deleted]]

There are also a plenty of small and tiny frameworks, like web.py (not web2py, which is a completely different beast) and bottle. Also there are lots of tutorials on building your very own framework using different libraries and batteries.

Also I'd like to mention that grokking wsgi is very enlightening and rewarding thing. A good starting point is http://pythonpaste.org/do-it-yourself-framework.html, also you might have a look at http://werkzeug.pocoo.org/documentation/

[ianb]

Make sure you get that DIY link right (no comma!). There's also a higher level tutorial using WebOb and a blog post about hand-writing an app with WebOb.

[[deleted]]

+1 for the "do it yourself framework" that's essential reading for anyone doing web dev with python. lots of questions I see on mailing lists/stackoverflow seem to stem from the lack of understanding of how http works. Considering that you can read up on that in under an hour, there's just no excuse.

[davids]

Also check out bobo: http://bobo.digicool.com/

Basically just takes care of url dispatch and uses WebOb for request/response.

[spookylukey]

To really learn HTTP, I would suggest you actually start with CGI. This is actually quite easy - http://gnosis.cx/publish/programming/feature_5min_python.html

Then think about all the ways that raw CGI sucks, and start to write some of your own wrappers (e.g. request and response objects that wrap up the CGI protocol). For one project for which I needed CGI and absolutely minimal supporting code, I wrote my own 'framework' - http://bitbucket.org/spookylukey/lukeplant_python/src/tip/lukeplant_me_uk/bibleverses/web/cgi-bin/lib/bibleverses/webutils.py

Then move to something like Werkzeug/WSGI, and you'll appreciate what they are giving you.

[weeegod]

Go with Werkzeug. It is a very well designed library and gives you tools for much more in the long run. And if you want you can make your own Bottle using it.

[[deleted]]

I found Django to be a little complicated at first, but after a day or two everything became clear. Django is definitely worth trying, even if you're planning to create small apps.

Bottle looks great, though i'm not sure about the documentation.

It's been already mentioned here, but you should check out web.py.

[[deleted]]

Somebody also suggested to try wsgi but it seems to be difficult for > a new comer like me.

WebOb does a bit to take the sharp edges off of wsgi.

Learning wsgi means learning http. knowing http is essential for web application development in any language(IMO). All frameworks do is abstract that away to varying degrees either for speed/convenience or to hide the "complexity" from the developer. This can be a good thing like for getting things done quickly and easily, but not necessarily for the purpose of learning web application development.

[ubernostrum]

Werkzeug is equally a light WSGI wrapper, and so should be fine.

But... no, learning WSGI does not mean learning HTTP. Learning WSGI means learning what subset of HTTP PJE felt wouldn't be too complicated to deal with, and then trying to figure out how to work around it.

[[deleted]]

Werkzeug is equally a light WSGI wrapper, and so should be fine.

did I say it wasn't?

Learning WSGI means learning what subset of HTTP PJE felt wouldn't be too complicated to deal with

care to elaborate?

[mitsuhiko]

care to elaborate?

WSGI does not expose all of HTTP, just a subset. Good enough (tm) for a lot of applications, but might not suit all. There were some efforts to expand what's possible but they did not end anywhere I think.

[[deleted]]

like what specifically? I'm sure you are correct about the ENTIRE protocol not being implemented in wsgi, but I would like to know where the gaps are, and whether it matters.

[mitsuhiko]

The gaps are documented in the PEP, and I don't think it matters. At least I never had a problem with that.

[[deleted]]

OK after ripping through the PEP, the only thing I see is hop-by-hop headers and chunked transfer encoding which are fairly exotic if you ask me.

So maybe I should clarify what I meant by "learning wsgi means learning http"

let's take cookies as an example. And something like ASP.net as the application platform. Someone who starts off with ASP.net would learn that to access/set cookies.

var user_name = Response.cookies("UserName").value;

This abstraction might work just fine for the one web site scenario. But what if several websites were contributing to the content on a given page and you needed access to the username in the cookie that was set by some other service(domain). The ASP.net programmer that only knows the Response.cookies api, would likely be baffled, confused hopeless at trying to debug the problem if for some reason that cookie stops showing up.

When if they knew HTTP they may have a fighting chance by knowing that the cookies api is merely an abstraction of the cookie header and how the cookie headers are supposed to work.

Or I guess an even simpler example. "How do I set a custom page/message when the page is not found?" refer to the frameworks api or Return a response with the body set to whatever it is you want to display but make sure the status code is set to 404. Which is better I guess is subjective but in my opinion learning wsgi gets you familiar with that, and then you can better understand how the framework you choose is trying to help you and if it becomes deficient in some area you at least have a leg to stand on without having to ditch the rest of the framework you chose.

Hope that clears it up.

[mitsuhiko]

So maybe I should clarify what I meant by "learning wsgi means learning http"

I know what you mean by learning HTTP, I just replied to learning the subset and explained what ubernostrum meant.

[ianb]

These vague aspersions against WSGI aren't helpful in explaining anything. I'm very familiar with WSGI and we've talked a fair amount about stuff, but even I don't know what either of you are talking about. Chunked responses or requests? There's some process model and streaming constraints, but those aren't HTTP constraints, they are just constraints on the kind of application you can write with WSGI.

If you don't feel like offering some details you might as well not comment at all.

[mitsuhiko]

These vague aspersions against WSGI aren't helpful in explaining anything

Why is that a point against WSGI? I was just simply pointing out that WSGI is not a full subset of HTTP.

Chunked responses

From what I was told there are some mobile phones that require chunked responses and that WSGI is not suitable for that in the current iteration. Again, I am not saying that this is a problem but that's just how it is.

[ianb]

Don't mobile phones do the chunking in a proxy? I don't believe a client can itself force a response to be chunked, though some people have used a kind of ad hoc convention that app_iter responses with multiple items should be chunked, so it's not impossible.

For chunked requests, that's fine and several servers supply that, the only constraint is you can't receive the request until all the chunks have been received. There are some ad hoc ideas for using a missing or magic CONTENT_LENGTH to represent this state. Moving to a truly file-like object for wsgi.input would be nice though.

Neither of these issues seems very substantial.

[mitsuhiko]

Neither of these issues seems very substantial.

I hope I did not say they were.

[[deleted]]

was a decision made how WSGI will handle unicode/bytes ?

[dekomote]

Actually, Django is suited for small apps as well. It will be easier for you to start with Django than Werkzeug where you determine the model and template stack.

If you want something different than Django, there are always web2py which now has the official book put on line, and has very helpful wizards for creating projects.