Hacker News .hnnew | past | comments | ask | show | jobs | submitlogin

I've found that I had to gradually replace large parts of web.py as my webapp evolved. For instance:

I had to drop the built-in DB library once I needed to connect to multiple databases. Global DB connections = bad. I suspect that if I'd kept using it, I would've had problems with transactions too.

I had to replace some of the request dispatching when I wanted to add code that triggers on every request (eg. logging, transactions, custom session management, "who's online?", traffic analytics).

I had to drop the Cheetah integration to add internationalization support - Cheetah supports the _ function, but only in precompiled templates.

I had to drop Cheetah entirely as the templates got a little more complicated and I wanted to factor some bits out. Web.py patches the Cheetah #include directive to do what you'd expect: include a file at compile-time (which is the same as runtime under web.py). With precompiled templates, however, it includes it at runtime, which means the included file can't have any #defs. Big pain.

It's not a bad framework to start out with, but you will end up needing to ditch nearly all of it by the time you've handled everything a typical webapp needs. If I were to do it over again, I'd probably start with Pylons. I'd consider Django, but I'm not sure you can swap out Django components the way you can with Pylons.



I use Python-Pylons/JS and Schevo for the backend. I have some experience with Django. Pylons is much better for serious programming - Django is better if you want to make a run of th e mill app like a blog. Using Pylons is like working with Lego bricks - stuff is swappable easily - not so with Django.


Yes, that's what I need and pretty much what webpy feels like to me.

If I were to switch to anything else, I'd probably try plyons first.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: