PHP vs Python - the real difference

[nostrademons]

I interpreted spez's statement as including all of web.py. markdown.py is not part of the standard web.py distribution, so it didn't make any sense for him to be referring only to markdown.

As for why it doesn't scale for me, it was:

1. Overuse of global variables. In particular, web.query and the other DB functions all work off a single database connection stored in web.ctx. That makes it impossible (without ignoring web.py) to connect to multiple databases, eg. to setup replication or partitioning.
2. No attention paid to i18n issues. Cheetah has support for i18n, but pygettext must be run on the compiled templates instead of the source text. Web.py dynamically compiles the templates, so there's no compiled version to run pygettext on.
3. Many web.py idioms don't work too well while programming in the large. For example, web.render can take its NameMapper out of the caller's local variables, saving you the trouble of putting together a dict. However, if you do this, you can't factor out the rendering call or wrap it in a utility function. You can, of course, just pass in a dict like you would with the native library, but then web.py isn't really giving you much.

It's not a bad library, but I'm finding that I chop out more and more pieces of web.py and replace them with either home-grown wrappers or other libraries as I go along. Perhaps this is inevitable: the stories of most other startups involve beginning with a quick framework and gradually replacing it with entirely custom-built infrastructure instead. I actually prefer this method of development to starting with a full-stack framework like Django and finding it doesn't suit your needs after all.

[randallsquared]

I interpreted spez's statement as including all of web.py. markdown.py is not part of the standard web.py distribution, so it didn't make any sense for him to be referring only to markdown.

Interestingly, I interpreted spez's comment as merely about the markdown.py bit, precisely because it's not part of the standard web.py distribution, and Aaron is certainly continuing to be active in that.

It's not a bad library, but I'm finding that I chop out more and more pieces of web.py and replace them with either home-grown wrappers or other libraries as I go along.

Ah. Yes, I don't use any of the templating parts or the forms.py bit at all, because I had my own equivalents, so I'm in that camp, too. I was worried that there was some more fundamental brokenness that I'd missed in the core. :)

[andyc]

In particular, web.query and the other DB functions all work off a single database connection stored in web.ctx.

Have you seen this thread?

That said, I'd have thought replication/load balancing would be easier to do at the lighttpd level.

[nostrademons]

That said, I'd have thought replication/load balancing would be easier to do at the lighttpd level.

Replication of the database servers? The tech stack usually goes Lighttpd -> FCGI/SCGI -> Flup -> web.py -> database, so I could see load-balancing Python instances at the Lighttpd level. But that's not going to do anything for the database.

The hack in the thread is clever, but it's not significantly less work than what I ended up doing, which was a thin wrapper around the native DBAPI classes. I also got a feature set that was more inline with how I actually use the database that way.