How many books have there been on Python web frameworks? None
Well, that's just not true. There's probably a dozen Zope books, two (?) on Zope 3, and a couple on Plone. And there's two general Python web programming books.
Even if every developer responsible for all the myriad Python Web frameworks came together behind one, that'd only match or slightly exceed the amount of development Rails has going on. We all know there's no chance of that, given some of the massive differences in personality between some of the developers and design paths chosen for the various Python web frameworks.
That's not true either. There's a large number of quiet Python web programmers out there. There's a large number of in-house frameworks... I think in-house frameworks might have as much share of Python programmers as the open/public frameworks. Well, not counting Zope, which is large as either group, and larger than Rails.
But I'm not saying we need to compete head-to-head with Rails. Still, we don't need to concede territory to them yet. They are not that big. I don't mind using Rails to put a little scare into Python developers to get our shit in order, but I think it's wrong to buy into Rails' hype too much.
Ah yes, good catch there. I completely forgot about Zope again, which is humorous for me as we're running a production Plone site here for a small business so I have several of those Plone and Zope books lying around.
I agree completely with the large amount of quiet programmers. When I used Mason extensively, while the user-base was very large there didn't seem to be much hype even though it was used extensively within several large companies. The Mason Wiki is also relatively small and bare compared with the Rails wiki. Very reflective of a large, but quiet developer community (They do talk quite a bit on the Mason mailing lists though).
So with Python Paste and other such systems, are we aiming to convert Zope developers/programmers to unite around a different web framework? They have such a time investment in the system, plus Zope 3 makes some nice advances, I'm not sure I see them ready to move off it to lend support to a different Python Web framework.
When you say "get our shit in order" what do you mean?
Very reflective of a large, but quiet developer community
I'd say this is a cultural problem, but not an insurmountable one. One aspect of Rails is that it excites people. Excitement has a lot to do with interpretation. Getting your job done well and on time is not exciting. But it could be exciting, if you phrase it differently; and that's what Rails has done. Sharing can be exciting, and experimentation and playfulness. Important things to think about.So with Python Paste and other such systems, are we aiming to convert Zope developers/programmers to unite around a different web framework?
No, I don't think it makes sense to focus on converting current Python web programmers. Paste isn't intended to convert anyone to a particular framework, as it isn't a framework and is intended to encompass several frameworks. Potentially any framework. Once Zope goes WSGI (which is in the works) it could run Zope too (though I suspect it won't attract that crowd as much, as they already have their own custom infrastructure to match Paste). I want to make the experience better for people who aren't doing Python web programming; both web programmers who aren't using Python, and Python programmers who aren't using the web.When you say "get our shit in order" what do you mean?
Being able to answer the question "so how do I do web programming in Python" easily. Being able to provide robust infrastructure. Being able to write documentation that is both complete and concise (which simply isn't possible if the underlying code doesn't allow for that). All the boring stupid stuff that needs to be done to make working apps, but isn't exciting.
Ok, I'm not sure how Paste will meet any of the goals you seem to desire. (This is assuming I'm understanding Paste correctly, as the comments on your blog have demonstrated its exceptionally difficult to explain Paste to other web developers, so how one could explain it to a new person....)
First, you want Paste to encompass other frameworks, however I'm not sure how thats possible. From several of the frameworks I've looked at, they work in such a different environment that I don't see how they can be modified to fit into Paste without destroying what makes them unique and valuable to their creators.
As one example, when I was reading over Paste, it seems to have its own Resolver in it, that then dispatches to Webware or a different framework. Myghty has a very powerful resolver methodology that we wouldn't want interrupted or pre-empted. I'm sure many other frameworks have a lot of parts to them that their developer doesn't want stepped on by some sort of "universal" meta-framework.
Being able to answer the question "so how do I do web programming in Python" easily
If we take Paste to what I see as your desired conclusion, ie, you download Paste, hit a command, and have an app ready to go with the framework of your choice (assuming there's a half dozen or two frameworks ppl have integrated). How does that make it easy? Sure, installing it was easy, but now what? How do you choose what framework to set your app to? How does that help documentation? There's still a dozen different frameworks, written by a dozen or more different people, documented by a dozen or more people, etc.
How easy would Rails be if once you had it installed, you had to choose from a dozen different framework paradigms?
As I'm working actively with Myghty and web development, I'd love to see it included in Paste. But why spend time developing that out if its easier and quicker to do what Paste provides myself?
For example, I'm currently writing up a little script, that when run lays out a basic directory template with some defaults setup for Myghty. It's fairly simple, and the directories it lays out are pretty conventional for a MVC webapp. With a single command, I can run the Myghty app standalone and play with it locally, however it also has a CGI, WSGI, and mod_python set of scripts allowing it to easily be used in any of those environments with no modification.
The module component I'm writing for use with this layout will be flexible enough to call methods (actions from the Rails-jargon world) based on URL if desired, or any other scheme. Myghty has a Path Translate function that works as an internal redirect of sorts, sort of like Rail's routing mechanism, I have Module Components? to handle mapping to controllers, and the Myghty template language to handle the view.
In the earlier Ruby post, some of the responses were wondering how Myghty is a framework vs template language, maybe that helps some?
Anyways, with one simple command, a small set of directories will be laid out, ready to run, with an easy to configure set of mapping rules to controllers and methods. It will also deal with a bunch of your complaints about Ruby's implicitness by relying more on Python's explicit nature (ie, you pass the arguments to templates rather than having them all copied, the URL can map to components and methods in whatever method desired, things aren't passed-by-name everywhere).
Add a dozen different frameworks, and its Paste, no?
Just wanted to clarify my prior comment as it might come off "flame-ish". My main intention was not to insult Paste or claim Myghty was the way. It was focused merely on realistic goals given the developers working on various projects.
As far as I know, Ian is the sole person working on SQLObject and FormEncode. I really really dig SQLObject and use it extensively, and I'm starting to use what I can from FormEncode to as its a really killer way to verify/coerce forms. Paste is yet another project that Ian's tackling. How many projects can you work on at once before some of them start lapsing?
The goal of my prior comment was, is Paste the solution? Will being able to easily install a dozen or two frameworks help a new web developer? How will the documentation be collected in one location and made uniform? Will Paste come with bundled frameworks, or will the framework maintainer be able to push framework updates down independently of Paste?
I'm sorry about the tone my other comment.
That's it. I'll shut up now. :)
As far as I know, Ian is the sole person working on SQLObject and FormEncode.
Actually, I've been lapsing on SQLObject work, but thankfully Oleg has been doing a good job maintaining it, and there's a group of people answering questions about it and submitting patches. So it's working out fine. There's been other significant contributions to FormEncode, and I'm hoping by keeping its scope very limited and clearly defined that it will also be able to exist on its own at some point, maybe even reach "maturity". And while Paste represents a particular vision of mine, I hope to bring other developers and visions into it; I know it's not easy getting an open source project to the point where it really is a collaborative project, but it's possible and something I think about quite a bit as I develop these things.
Paste is still a work in process, so its advantages aren't extreme. You can reimplement its functionality for your framework, and it wouldn't be that hard. It's also quite easy to use Paste with your framework, so I honestly don't know that it's easier to do things on your own, even if you factor in the getting-to-know-you time (at least if you are planning to support WSGI at all). Peter Hunt said it took him about 4 hours to convert Subway to Paste; I haven't seen the details of his code yet, but I think that includes some degree of integrating setup scripts and other pieces.As one example, when I was reading over Paste, it seems to have its own Resolver in it, that then dispatches to Webware or a different framework.
It is definitely not expected that all frameworks will share a resolver. paste.urlparser does file-based parsing as WSGI middleware, but you could implement other strategies as middleware, or just provide a single entry point and do it internally. That's how initial Quixote support will work -- it'll use their Publisher without modification, and maybe in the future that can become middleware. I think it's reasonable to expect framework support to start as a monolithic integration -- a single entry point and everything after is internal to the framework. Later pieces can be factored out, or replaced with existing Paste functionality. This is the way that WSGI middleware can make a framework melt away. But it's incremental, and I'm as dedicated to backward compatibility as you probably are, so the buy-in required is gentle.If we take Paste to what I see as your desired conclusion, ie, you download Paste, hit a command, and have an app ready to go with the framework of your choice (assuming there's a half dozen or two frameworks ppl have integrated). How does that make it easy?
That sounds easy to me. Really, I tried the framework comparison thing, and it was really hard because of installation. Not because I couldn't figure out the difference between the frameworks quickly. It doesn't mean there's no work to do for the framework authors, but they can focus on making their frameworks compelling instead of robust or easy to install.How easy would Rails be if once you had it installed, you had to choose from a dozen different framework paradigms?
Paste isn't Rails, at all. There's a couple ideas I'm taking, but only a couple. Like maybe two. They have very different scopes and purposes.[description of new Myghty features...] Add a dozen different frameworks, and its Paste, no?
Paste without the reuse, sharing, or community. I think that's a big difference.