Anyway, getting to address the two perceived issues:

* Sales of books = number of ignorant users
* Technical pub nights = number of users who don’t have lives or girlfriends

All I gather from this is that Pythonistas are smarter and more socially acceptable than their Ruby counterparts. Probably sexier too.

I can live with that.

Q: “I am a Python newbie, can you recommend a GUI framework for a quickie GUI app?”

A #1: “Tcl is best.”

A #2: “No, wxWindows.”

A #3: “PyGTK2 rocks.”

A #4: “PyQt rules, man!”

A #5: “There are > 5 (refs included), you should take a look around and judge for yourself.”

A #6: “It depends….”

Surely Mr/Mrs Newbie is well-qualified to judge Python GUI frameworks’ inherent qualities and has nothing better to do with his/her time. Say, what about using that old VB6 license after all?

While I appreciate choice, I feel _some_ guidance is useful too.

+1 to Ian Bicking’s comment about having a compelling story for new users.

If so, the Django community will hopefully respond as the Zope community did years ago – try to move towards the Python mainstream where possible, and innovate where it makes the framework special. The Django community might learn, like the Zope community did, that this is a challenge. It’s starting to pay off for us though.

The Zope community is on the long road of making it back to perceived relevance in the Python community (I claim it’s already relevant, it’s just not perceived as such). I believe Zope’s focus on component-driven development along with improvements in the Python infrastructure that makes it easier to distribute such components will eventually have an impact.

Anyway, if this happens to Django, they’ll have the benefits of their own fresh insights along with the lessons of the Zope community, just like Zope is learning from them now. If at least Zope blindness won’t get in the way then.

Check out Sean Kelly’s screencasts:

http://seankelly.tv/blog/blogentry.2006-07-09.2857417511

and define “maturity” in web frameworks

If you get past the complexity (big if for many people) Zope/Plone blows away everything out there. Drupal would be coming in second. Actually Drupal could be coming in third, cos there’s also Zope/CPS (lesser known than Plone), which is pretty good.

I gotta say, I think the Python web frameworks world is in rude health, and I think Adrian/Martijn are on the money with their observations. I’ve never been happier

On the “don’t get it” remark, you certainly haven’t accused others of not getting it, but rewind in this thread and we have some kind of example:

“”"
# Willem de Gier Says:
August 23rd, 2006 at 6:23 pm

Django isn’t even close to where Zope was 8 years ago.
“”"

Zope eight years ago (August 1998) was certainly a usable application development framework, albeit with DTML at the forefront and with things like ZClasses as the upcoming state of the art. However, the sentiment of the remark is that of condescension – those Django upstarts have a lot to learn – whereas Django development involves a different set of tradeoffs that may be no worse than Zope in many cases, and Zope could quite possibly be strengthened to cater to those who prefer Django in such cases.

The eight years ago remark is interesting since it was more or less at that point that I found myself reading the Zope mailing list as much or more than comp.lang.python. Web programming back then really was a big new thing, and Zope was the way to do it: reading the Zope list and immersing oneself in the “zen” (talk about “not getting it”, eh?) was supposedly the way to become a master of the art, and if you wanted to learn about Web development, people on comp.lang.python often sent you to the Zope list to learn more.

So, perhaps Django is like Zope eight years ago in the sense that it will one day find itself isolated from Python and in that community’s blindspot. Perhaps the recent pronouncement is GvR’s way of saying that he’d rather have the new “chosen path” be an integral part of the Python community and that all the discussion should take place in all the same places that normal Python discussion happens. Or perhaps it was just an ill-advised recommendation of some technology that will eventually lead to nothing.

Zope clearly does have a community of its own. What is the problem with that? Surely say, Django, has a community of its own as well?

Zope may be slightly different in that it attracted many people to Zope for Zope primarily as opposed to through Python, but that’s one of the things people say about Ruby on Rails too. Another difference for Zope is that it traditionally attracted many casual programmers and non-programmers to the system as well. I think that overall this enriched the Zope community, but it is indeed a unique challenge to deal with.

Zope’s community of course also clearly has large overlaps with the Python community. The Zope community believes much good can be learned from the wider Python community, and for *years* has been working on moving closer to the Python mainstream, lowering the fence for non-experts, mainly with the Zope 3 project. Significant work has been done to work with community standards like WSGI, and Zope 3 is, for instance, using Twisted. We’re moving on to embrace eggs now.

Whether the engagement of the Python community has succeeded fully can be debated, but clearly the awareness does exist and significant progress has been made. It’s a work in progress.

I don’t believe that criticisms of Zope have not been taken seriously, They might not have been taken seriously by some, but the community as a whole? Anyway, “just don’t get it” is of course not a good observation if you want to engage people as a community. I hope I haven’t been found to make such observations and I will try to discourage such attitudes if I am able to. Perhaps you can point me to one such recent interaction so I can keep an eye on this unfortunate tendency.

Please also note that the Zope community has a significant amount of existing codebase to move forward, and like everybody else, has limited developer volunteers, so even though criticism might be recognized, doing something about it often takes more time.

Finally, the web-track at the EuroPython conference in 2006 was organized by Paul Everitt and Godefroid Chapelle, both prominent Zope community members; we didn’t have a specific Zope track anymore. It was a clear recognition by Zope community members that the Python web landscape had changed, and the tracks were integrated this year as a response. We might’ve missed the boat on that in 2005, but before then, I am not sure whether a web track might’ve worked. That said, another factor is that quite a lot of the attention shifted to Plone, which has conferences of its own, so the EuroPython conference’s role changed.

So, Zope has a community of its own with meetings of its own. That’s the point I was trying to make in my original post – that it happens for Python-based web frameworks. And Zope has a problem integrating with the larger Python community – my point of this post is that yes, this is true, and that we aware of it, and that having a separate community is not necessarily a *bad* thing, but that we are actively working on improving its negative sides.

Anyway, you’re right, all this contributes to a credibility problem. It’s a difficult problem to address, as it seems to have resulted in significant Zope blindness in the wider Python community. I can see where our track record contributed to that, but on the other hand I believe a lot of value and honest effort by the Zope community is being ignored by the Python community because of this blindness.

It’s clear that Zope is considered to have a community of its own, and the EuroPython track organisation of previous years merely confirms that people on both sides of the fence realise this. Zope experts seem to have no problems in “jumping the fence” and applying Python solutions within the Zope architecture, but Zope non-practitioners look at the height of the fence and question Zope’s relevance. One observation I see occasionally is that such people “just don’t get it”, despite there having been plenty of valid criticisms of Zope over the years, and to not take those criticisms seriously just adds to that credibility problem, good marketing or otherwise.

Zope.

Zope has had gatherings since 2000 or thereabouts. I’ve listed the gatherings I actually attended as an eye-witness:

* IPC in 2000, Zope track

* IPC in 2001, Zope track

* european zope meeting at linuxtag in Germany, 2000

* zope track at linux conference in Amsterdam, 2001.

* 2 zope bbqs (actually 2 day conferences) in Berlin, in 2001 and 2002

* EuroPython 2002, 2003, 2004, 2005. 2006 had a
more general web track to recognize the newcomers, but all the ones before had big Zope tracks, and attracted at least one third if not more of attendees..

* Plone conference 2005 and 2006 in Vienna.

* numerous Zope sprints.

That’s about 10 gatherings, not including the sprints. Including gatherings I wasn’t at, I think that makes for 15 to 20 major Zope gatherings (at least one full track lasting at least 1 days, though mostly more) in the last 6 years or so. There have been at least that many sprints – many more, I suspect.

As you know, there are quite a few books out about Zope as well, though admittedly many of them are not that current. That happens when you’ve been doing cutting-edge web development in Python for the last 7 years that Zope has been open sourced.

Anyway, it’s clear Zope needs to drastically improve its marketing, a major lesson we’ve been too slow to learn. We’re learning it.

I’ve talked to you about Zope several times in this context, and yet you keep forgetting about it – I’m getting a bit worried, are you all right?

I entirely agree, i wasnt proposing its something “Adrian should be doing !” With SQLAlchemy i am constantly walking the line between “yes, SA would like this feature/no, SA’s current developers cant take it on”, such as the ActiveMapper and Migrate packages which I’ve basically “outsourced” as things i dont need myself, but have obvious value to others.

However, I have had to take a lot of steps with SA to insure that its fully open to extensibility, including its general layout as well as various hooks (and with Myghty as well). I know the point of Django is to bring the best experience to its users, and I *totally* understand the idea of its in-house roots; ive written several (now very obsolete) frameworks where i had to invent everything. But when such a framework comes out in the open, has been around a while, and has been as successful as Django, theres a next level that needs to be considered.

So, if someone came to you with Django’s ORM built entirely on SA, which then magically knew how to do three more things that the existing ORM could not, or a template plugin that nicely integrated Kid/Markup templates as well as that of Django’s (in fact I like Markup quite a bit…), it might require some rearrangement/decoupling of Django’s internals to make it possible (from what you said in your last sentence it seems like you are considering that already). Django could also pursue the direction of rearrangement/decoupling of internals beforehand to make it easier for such projects to happen in the first place (and maybe thats starting to happen too). Also, while i know it has introduced some WSGI support, it can take hard and honest looks at extremely modular WSGI frameworks like Pylons and see what can be adopted there…since a *lot* of people have put a lot of work into WSGI and its a really good thing (GVR-approved!).

This is all based on the idea that Guido truly wants there to be just “one” framework. If that is the case, then he’s really asking us to all gather behind it. If he wants us to stop
introducing competing approaches and just pick this one, then it necessitates that this idea become prominent within the developmental direction of Django – that it graduate from its roots as a very successful “in-house get the job done” application into a much more broadly-scoped and organically-growable system. While that may seem overwhelming, if the whole of the Python community were behind it, the resources are definitely available…but only if the Django project puts out a strong and consistent message that this is what it really wants. Compared to an in-house and homegrown background, this is a major change of mindset for such a framework.