I am "mentoring" a python dev on HN and far and away the most important thing I think he can do is not learn a framework till the underlying WSGI process is firmly embedded in his brain
I used to think getting a site up and running in ten minutes meant something bu I tend to believe it is usually teaching bad habits or allowin untrue mental models to develop
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.
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.
Flexibility and scalability - those are the two takeaways from this.
I've always found django (for example I'm not specifically down on django) to be quick to get up and running but to lead you gently down a path that ends with a very high brick wall.
Pyramid on the other hand is so flexible that pretty much any part of the framework can be swapped out for something else and you can abstract the important parts of your app into a mini-framework for yourself. An example of this: The code I have <100 lines of code in a file called rest_traversal.py that maps SQLAlchemy mapped tables to urls like:
/db/Model -> all instances of Model
/db/Model/1 -> model 1
/db/Model/1/relationship -> all members of model 1's relationship
I'm currently using Pyramid to build the real time front end to an algorithmic trading system and it's been the perfect balance for me.
Not disagreeing with you here, but is it the case that (most) people build on Django expecting it to scale very well later on? I've not built any Django apps that have seen the light of day, but I've always had the impression that once you have something up and running and are now, hopefully, getting some revenue that transitioning to something more scalable would be much less painful. Reason being, the vision was clarified under Django through a number of (hopefully) quick tweaks here and there.
Or does your experience say otherwise? If one were to build something that would need to be immediately scalable, don't even think of Django and head towards something like Pyramid and Flask?
No! Django scales well and scalability is not a very good reason to switch away from Django. Plenty of high volume sites are powered by it, most famously Disqus.
The great thing about pyramid that this code might not really indicate if you're not familiar with it, is that you can attach instances of these traversal classes anywhere in your tree and the views will still do the right thing. Likewise, using the model_is predicate lets you override the default json renderer for specific classes if you need to.
Hey guys, thanks for checking out our post on Pyramid. We really do like the flexibility it offers over Django. We are also coming out with a follow up blog post from the IndyPy web shootout next week that will also have the videos of the 4 presentations on Pyramid, Bottle, Django, and Flask. I'll link to it on HN then.
At Six Feet Up we love Python and spend most of our time building enterprise & higher ed CMS and intranet solutions along with Pyramid or Sencha apps. We are also really interested in understanding how others are using Python in startups and the enterprise.
I used to think getting a site up and running in ten minutes meant something bu I tend to believe it is usually teaching bad habits or allowin untrue mental models to develop
Dammit we need developer education. !:-)