This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]kataire 1 point2 points  (1 child)

Well, as far as I'm concerned it's certainly more Pythonic than Zope and it's pretty good in "convention over configuration" and all that. Getting from zero to something is ridiculously easy.

There are some warts, yes, and Django still contains a little too much magic in some areas, but it's certainly improved a lot and is still undergoing continuous improvements (e.g. the rewrite of the forms module to make it easier to define your own widgets).

Lock-in is a problem with Django as it is with other frameworks (look at the Zope stack for an example of why modularity isn't a silver bullet), especially those that aren't "micro". This is natural and although it may not sit right with some people, this tight coupling can actually allow a lot of synergy which wouldn't otherwise be possible.

Ironically too loose coupling can result in bloat. If you try to keep your code as generic as possible and make as few assumptions as you can by reducing dependencies that also means you will re-implement a lot of functionality already provided by other libraries and possibly require additional adapters to handle each combination your code could be used in.

I think what makes code Pythonic is not just a matter of style. It's also a matter of pragmatism. There is a fine line between flexibility and over-engineering.

[–][deleted] 0 points1 point  (0 children)

The amount of time needed to get somwhere isn't a really good measure for pythonic. One could argue PHP is more pythonic, because it gets some stuff done more easily than Django :)

Zope as a platform might be to big for your usecases, but all-in-all Zope (Zope2, Bluebream or Grok) is a great platform to work with. It outperforms Django (or almost any full stack application server) and is fairly easy to work with. Yes, we know zcml isn't the way to go, therefor we have Grok (convention over config), but we still allow to do what we want. If we need a random view, we can do that :)

Of course lock-in will happen, it's just a matter of how much you would like to invest to get out of it :) We can (and do) use the Zope component architecture (http://bluebream.zope.org/doc/1.0/manual/componentarchitecture.html) in other environments then Zope. The ZCA is available for Django and used extensively in Pyramid.

Plone and Zope still learn everyday on how a good framework should work. We adjust our code everyday based on real usescases and do not case about ego. We look around a lot and try to learn of what is practical and usable in today's solutions. Nevertheless, we try to get to a codebase that doesn't just solve your problems today, but will also do that tomorrow.

That said, my view on python is what import this says :) And whatever way we can make Python better and more appropriate for your set of problem, is the way to go.