Why do you feel knowledge of WSGI is critical? (I can think of a few reasons why it's a very good idea to know what's going on roughly, but I wouldn't put it as strongly as you have, and I'm curious to know your reasons.)

Not the OP, but my thoughts on it. When I came to my current company, I had no web dev knowledge, I was able to survive by just using the setup my then-CTO (hey yummyfajitas!!) had done. I learnt django and picked up python , but if you asked me why were we using gunicorn and what purpose did nginx serve I would have been blank.(I know I possibly appear very stupid saying this)

After reading about it from a couple of places and writing a blog about it[1], I finally understood my entire infrastructure. While it hasnt served any practical knowledge yet, I feel much more confident about my ability to handle any error or optimizations in that area.

That being said, if I had started reading about WSGI as soon as I started , I most probably would have been lost. I think while getting a website up in 15 minutes gives a sense of accomplishment to someone getting started, it might make sense to make them aware of the underlying technologies beneath the stack once they are comfortable with the framework.

[1]http://siddharthsarda.tumblr.com/post/41369795330/analyzing-...

It's kind of that frameworks are still the silos wsgi was supposed to solve. Look at flask - it started off as little more than the code examples in PEP333 ! Then people went great ! And it was great. Except that it had let's say OpenId added to the framework.

Now in my opinion the right place to do authorisation is earlier in the wsgi chain - using say repoze.who.

But now someone coming along sees the framework can do this and instead of learning how to chain wsgi apps they just take Armins excellent skeleton code and hey presto Flask starts to bloat.

This is not a complaint about Flask per se (I think Armin is doing a Stirling job promoting a smaller way) but it is about a chain that was supposed to mean we could pick best of breed middleware and yet we are still in which framework is best debates

It should never be how to learn pyramid / flask / django in one day but should be how to deploy a micro-service and chain it in front of authentication middleware and hey presto a working API. Stuff your templates.

> it started off as little more than the code examples in PEP333 !

Flask had less than 1000 lines when it begun, but werkzeug is much bigger than that.

> Except that it had let's say OpenId added to the framework.

Is that supposed to be a hypothetical example? Because Flask framework doesn't have openid added to it. Flask extensions for it exist, just the way it should. The users can write whatever extensions they want - that shouldn't concern framework developer or other users.

> Now in my opinion the right place to do authorisation is earlier in the wsgi chain - using say repoze.who.

I don't know what repoze is. But if you want to insert a wsgi middleware, you can easily do it in flask.

> But now someone coming along sees the framework can do this

The framework doesn't do auth.

> they just take Armins excellent skeleton code

I don't know which snippet you are talking about, but I believe that's about how to use Flask-OpenId extension.

> but it is about a chain that was supposed to mean we could pick best of breed middleware and yet we are still in which framework is best debates

Flask-openid is a wsgi chain. Flask app object is a wsgi object, and openid extension wraps it. Also, my concern would be ease of integration and extensiblity, not what level it works at.

Depending on what the parent calls deep knowledge of WSGI, I also find the idea a bit strange.

I don't have much knowledge of WSGI internals, apart that it passes urls in one direction and responses in the other. I suppose when I hit performances bottlenecks, it might be worth it to dive into the details, but I'm not there yet.

Knowing what is going on at a higher level, the role of the reverse proxy, the app server, the database, and who talks to who is important, but most frameworks (with, maybe, the exception of Rails) don't really abstract that away from you so much.

Interesting approach. I first learned Flask, built a small project with it, then later took the time to get familiar with wsgi. I don't feel that I missed out. My first project didn't use any middleware, but was easy to understand and maintain. Later projects made use of them when appropriate.

How long have you been mentoring that dev and how does he/she feel about this bottom-up take to understanding WSGI development?

Not long. Taking it with a pinch of salt. He has built simple Flask apps anyway so thats good.

I think there is easily a place for getting something running quickly with Flask. But going to a growing codebase with flask or any frameworks with understanding the underlying mechanisms and options is pretty silly.

So I think get that out of the way early.

FWIW I have actually written a literate testing tool so I can actually write notes and code examples - https://github.com/mikadosoftware/doctest2 ... doclit It may be useful for this kind of thing.