Re: What really makes rails work comment 000

If people are serious about offering an easy way into Web development in Python, they will need to throw out as many of the caveats and the magical framework incantations as possible.

From my cursory look over Rails I see a lot of Magic and from the docs I see the phrase "Magic is not inherently a bad word". Egad! These people believe in Magic, savages!

But perhaps your point is to remove framework-specific incantations and boilerplate and if so, I agree with that.

Personally I think a Python version of Rails isn't possible because the Rails developers are willing to do something alien to Pythonista's, that is, break our "Explicit is better than Implicit" creed and create a domain-specific language for Web Applications.

Admittedly, the history of this kind of magick in Python isn't encouraging. Zope and it's Aquisition turned off a whole section of the Python community.

So I think the problem is philosophical. It hardly matters that Python isn't quite as good as Ruby for creating these domain-specific languages (and it isn't, we must admit it) because doing so runs contrary to the principles we as pythonistas hold dear.

Making something with as much utility as Rails would mean standing up and saying (gulp!) :

Comments:

"But perhaps your point is to remove framework-specific incantations and boilerplate and if so, I agree with that."

That was exactly my point. I've looked at a lot of frameworks over the years, but now if I see anything which imposes arbitrary behaviour, then I just hit the back button, and I think people get put off by seemingly arbitrary restrictions encoded in special ways. I'm trying not to be too controversial here, but if you look at various object publishing mechanisms, you see two things: that the developers assume that a rigid hierarchy is how everyone wants to design their applications; the various ways of telling the framework about exposed objects. Clearly, due to Python's introspection capabilities and the potential for security breaches (ask anyone who has written an object publisher about that) you need the special notation and it needn't be too intrusive (although Quixote's notation seems a bit contrived), but I can't help feeling that many people are thinking, "Hold on! I'm not sure if this even suits me."

It's a similar story with templating. Whilst some of the PSP solutions can be quite productive, if you don't believe it suits your application then the whole thing is going to be a turn off. It's interesting that the most actively developed PSP solution of them all, CherryPy, backed away from special template languages in release 2.0.

"Personally I think a Python version of Rails isn't possible because the Rails developers are willing to do something alien to Pythonista's, that is, break our "Explicit is better than Implicit" creed and create a domain-specific language for Web Applications."

Yes, and Ruby probably supports that quite well. But as you note...

"Admittedly, the history of this kind of magick in Python isn't encouraging. Zope and it's Aquisition turned off a whole section of the Python community."

...it may be the case that Rails eventually is to Ruby what Zope is to Python: something that lives alongside the creation which spawned it.

Why arguing about which of the two of the greatest products should come first?

To me, zope2.x seems harder to modeling/manage enterprise-sized application while 3 seems making routine-task a lot harder for a new-comer than how it can be done with 2.x's ZMI.
--Just like in Linux world, some prefer GUI while others value CLI.

Can't they co-exist and collaborate?

Wouldn't it be nice if the future zope3 combines the simplicity of configuring objects with zope2(through its ZMI) and having better capability of handling M/C/V with its current underlying framework?

P.S.
I am by no means an expert in either zope or python, so hope you guys don't mind, just trying to make a point here :)

To me, zope2.x seems harder to modeling/manage enterprise-sized application while 3 seems making routine-task a lot harder for a new-comer than how it can be done with 2.x's ZMI. --Just like in Linux world, some prefer GUI while others value CLI.

That was exactly my point. I've looked at a lot of frameworks over the years, but now if I see anything which imposes arbitrary behaviour, then I just hit the back button, and I think people get put off by seemingly arbitrary restrictions encoded in special ways. I'm trying not to be too controversial here, but if you look at various object publishing mechanisms, you see two things: that the developers assume that a rigid hierarchy is how everyone wants to design their applications; the various ways of telling the framework about exposed objects. Clearly, due to Python's introspection capabilities and the potential for security breaches (ask anyone who has written an object publisher about that) you need the special notation and it needn't be too intrusive (although Quixote's notation seems a bit contrived), but I can't help feeling that many people are thinking, "Hold on! I'm not sure if this even suits me."

Personally I think a Python version of Rails isn't possible because the Rails developers are willing to do something alien to Pythonista's, that is, break our "Explicit is better than Implicit" creed and create a domain-specific language for Web Applications.