does web.py have documentation and are you using webpy?
28 comments
you lost me with that last paragraph, to put it nicely.
your innovation as a startup will not be reinventing wheels -- building and debugging frameworks that, fortunately for you, others have put [tens of? hundreds of?] thousands of man hours into, solving seriously unsexy problems like browser incompatibilities, security nits and writing init scripts. i can't see how it's faster to tackle all of these things _and_ your application code than just, um, building your application code leveraging one of the very solid foundations that already exist.
while your competitors are solving problems that matter to your users, you'll be running around feverishly putting out fires when someone types an é into your application, or starts getting funny with strings involving apostrophes, semicolons and "drop table", or script tags in comments.
your innovation as a startup will not be reinventing wheels -- building and debugging frameworks that, fortunately for you, others have put [tens of? hundreds of?] thousands of man hours into, solving seriously unsexy problems like browser incompatibilities, security nits and writing init scripts. i can't see how it's faster to tackle all of these things _and_ your application code than just, um, building your application code leveraging one of the very solid foundations that already exist.
while your competitors are solving problems that matter to your users, you'll be running around feverishly putting out fires when someone types an é into your application, or starts getting funny with strings involving apostrophes, semicolons and "drop table", or script tags in comments.
Thing is - I don't see frameworks solving these problems. I see frameworks doing things like automating directory layouts, adding some magic to reduce typing, handling request dispatching, etc.
I see libraries solving these problems. I use Cheetah too, and am grateful for its #filter Websafe. I use Markdown - it has the same javascript: bug as Reddit, but at least I or someone else can submit a patch to Markdown and have it fix every site using Markdown and not just my own. I use the parameter replacement available within DBAPI to avoid SQL injection attacks.
I don't like software that tries to solve all my problems, because it inevitably mis-guesses and solves about 80% of them, making the remaining 20% pretty hard in the process. I like software that tries to solve one of my problems and solve it well, because then I can swap in the best solution for the job. Fortunately, the newer Python frameworks (Pylons?) are going down that road, but I didn't see much advantage in using Pylons over using DBAPI + Cheetah + Prototype + Web.py dispatching.
I see libraries solving these problems. I use Cheetah too, and am grateful for its #filter Websafe. I use Markdown - it has the same javascript: bug as Reddit, but at least I or someone else can submit a patch to Markdown and have it fix every site using Markdown and not just my own. I use the parameter replacement available within DBAPI to avoid SQL injection attacks.
I don't like software that tries to solve all my problems, because it inevitably mis-guesses and solves about 80% of them, making the remaining 20% pretty hard in the process. I like software that tries to solve one of my problems and solve it well, because then I can swap in the best solution for the job. Fortunately, the newer Python frameworks (Pylons?) are going down that road, but I didn't see much advantage in using Pylons over using DBAPI + Cheetah + Prototype + Web.py dispatching.
Can you explain to me how unsexy problems like browser incompatibilities (yes a major pain) lie anywhere within the scope of webpy? Those seem to lie within the scope of the templating system and js library that you choose.
A larger, more complex framework does present serious problems when you have to architecture everything in strange ways to meet scaling needs or otherwise.
Note how much the twitter guys were so scared by ROR's complexity that they resisted doing the most trivial modifications? I want to understand my framework "all the way down." This is much the same reason I use linux.
A larger, more complex framework does present serious problems when you have to architecture everything in strange ways to meet scaling needs or otherwise.
Note how much the twitter guys were so scared by ROR's complexity that they resisted doing the most trivial modifications? I want to understand my framework "all the way down." This is much the same reason I use linux.
Parent has important questions that should be addressed, or is this is just a django vs the world flamewar?
btw, cough, someone needs a <meta content="text/html; charset=UTF-8" http-equiv="content-type" /> (or equivalent) in their <head> section :)
Exactly. Webpy is for programmers, django for people who want to feel like programmers, but are really just walling themselves into pre-defined ultra-boring patterns.
And real computer scientists only program in machine code because everything else is a shortcut, right?
So you're saying that since web.py fails to provide a solution to common problems, it gives "real developers" the freedom to implement it themselves? Pesky frameworks like django only allow the same developers to jump straight to doing new things. Uh, that must be the pre-defined ultra-boring pattern.
So you're saying that since web.py fails to provide a solution to common problems, it gives "real developers" the freedom to implement it themselves? Pesky frameworks like django only allow the same developers to jump straight to doing new things. Uh, that must be the pre-defined ultra-boring pattern.
Correct. Simple frameworks that you then add more complex components to are better. Same for OS'.
Yes, correct on the second part also.
Yes, correct on the second part also.
Everyone knows that ASM is the only true language for programmers.
looks like web.py has some interesting ideas and useful data munging functions. but unless there's something i'm really missing, most normal web apps (that aren't completely trivial) are way better off using turbogears or django, which provide mature and usable components (templating, object-relational mapper/query building/db access, web/WSGI server). i've built a couple reasonably large web apps using turbogears and love it (although i use cheetah instead of kid) and django seems to be winning the python framework race.
not to sound overly harsh, but web.py seems like a big case of NIH. each of its pieces seem like v0.1s of more established counterparts. mature web frameworks are occasionally big and ugly _because_ they work around that random safari bug from 2002 or the flash 8 player's uploader non-RFC-compliant MIME-multipart requests and all the unicode encoding and DB integration nits, etc. the plumbing looks gross because the surface area of the problem they solve is gross.
and with the big frameworks, thankfully hordes of others have banged their heads against and solved these issues; with a "lighter" framework, or one of the 4328429 me-too python web frameworks from 2001-2004 that didn't really make the cut, you're volunteering to blunder into and track down all these problems yourself over the next year or two -- probably not the best use of your time or problem solving skills.
not to sound overly harsh, but web.py seems like a big case of NIH. each of its pieces seem like v0.1s of more established counterparts. mature web frameworks are occasionally big and ugly _because_ they work around that random safari bug from 2002 or the flash 8 player's uploader non-RFC-compliant MIME-multipart requests and all the unicode encoding and DB integration nits, etc. the plumbing looks gross because the surface area of the problem they solve is gross.
and with the big frameworks, thankfully hordes of others have banged their heads against and solved these issues; with a "lighter" framework, or one of the 4328429 me-too python web frameworks from 2001-2004 that didn't really make the cut, you're volunteering to blunder into and track down all these problems yourself over the next year or two -- probably not the best use of your time or problem solving skills.
There's value in using a v0.1. It hasn't had a chance to get large and complicated yet, so it's easier to learn and less likely to break.
Good third-party components should solve a problem with a large surface area and present an interface with a small surface area. I don't really see that with most frameworks: instead, they seem to solve a problem with a fairly small surface area and present an interface with a large surface area. Not really a great combination.
I'm all for libraries and standards, though. There's no way I could've built my app without Cheetah, PIL (despite installation headaches), Markdown, DBAPI, and WSGI. These solve the real hairy problems, yet provide a small, often trivial interface to learn.
Good third-party components should solve a problem with a large surface area and present an interface with a small surface area. I don't really see that with most frameworks: instead, they seem to solve a problem with a fairly small surface area and present an interface with a large surface area. Not really a great combination.
I'm all for libraries and standards, though. There's no way I could've built my app without Cheetah, PIL (despite installation headaches), Markdown, DBAPI, and WSGI. These solve the real hairy problems, yet provide a small, often trivial interface to learn.
A timely post ... we're just about to release a biggish site running on web.py. Check out our blog, which I just released today: http://blog.micropledge.com/
We like web.py for its minimalism. It means we did have to write a database layer for it, but we still feel it was better than using Django as we've got more control. This app's big enough that we want it to run the way we want it to -- web.py lets us do that. And when it doesn't, it's small enough to hack.
As for docs, web.py's size means that the limited docs it does have are pretty much enough. When they haven't quite been, we've found the web.py group pretty helpful: http://groups.google.com/group/webpy/
We like web.py for its minimalism. It means we did have to write a database layer for it, but we still feel it was better than using Django as we've got more control. This app's big enough that we want it to run the way we want it to -- web.py lets us do that. And when it doesn't, it's small enough to hack.
As for docs, web.py's size means that the limited docs it does have are pretty much enough. When they haven't quite been, we've found the web.py group pretty helpful: http://groups.google.com/group/webpy/
I'm currently working on a largish project using webpy (well, large for one person). In terms of getting started an barriers to entry, it's very easy to use and getting results is a breeze.
That being said, the documentation is a very large problem. When I run across issues and the documentation isn't there, it can be difficult to get a quick answer. There's a wiki of the documentation, but it has very few contributors.
I think the general problem is that the community is very split in terms of experience, with little intermediate discussion. The typical questions on the webpy board are either really basic ("how do i get started") or discussions about the project's direction. I don't think typical programmers are discouraged from participating, but there isn't enough "average" programming level discussion to make it feel like a community.
Just my 2 cents.
That being said, the documentation is a very large problem. When I run across issues and the documentation isn't there, it can be difficult to get a quick answer. There's a wiki of the documentation, but it has very few contributors.
I think the general problem is that the community is very split in terms of experience, with little intermediate discussion. The typical questions on the webpy board are either really basic ("how do i get started") or discussions about the project's direction. I don't think typical programmers are discouraged from participating, but there isn't enough "average" programming level discussion to make it feel like a community.
Just my 2 cents.
I wasted 2 weeks on web.py. Why a waste? No documentation and you outgrow it VERY quickly. As soon as you realize you need a feature (e.g. caching), you'll have to implement it yourself.
The sooner you switch over to Django, the better and easier your life will be.
The sooner you switch over to Django, the better and easier your life will be.
http://webpy.infogami.com/docs - documentation
http://groups.google.com/group/webpy?lnk=oa - Discussion Group
We've built http://www.barcoderobot.com using it ...
We've built http://www.barcoderobot.com using it ...
No, I'm not using web.py. I started out using it and switched to Pylons, because web.py was too simplistic for my needs, and because a nasty security gaffe Aaron made eliminated my trust in his ability to write secure code.
That security gaffe was in Markdown - a piece of junk that I've been pointing out flaws in for the past year.
That's not the security gaffe I'm talking about.
http://groups.google.com/group/webpy/browse_frm/thread/2fcbcb60a99a1c79/
Aaron's mistake is at post #4, my response is post #5.
Yeah, that's from a while ago. That's about when I stopped using web.py, too.
http://groups.google.com/group/webpy/browse_frm/thread/2fcbcb60a99a1c79/
Aaron's mistake is at post #4, my response is post #5.
Yeah, that's from a while ago. That's about when I stopped using web.py, too.
Yes, I understand your concern. For sure, aaron was on drugs when he mentioned this quick, non-secure fix -- even though the asker most definitely had very loose security requirements given that he was using nothing more than CGI.
\But\ from the beginning, everyone using webpy has seem to know flup sessions to be the recommended way of doing sessions:
http://webpy.org/track/wiki/SessionsWithFlup
Let's look at this another way though. If you really need security, then which is better: a simple, quickly verifiable codebase like webpy, or a massive, magical code base like django and turbogears? Do any frameworks make any guarentees of security?
I have seen several high profile sites within the last two years with major, obvious security problems. As hard as this is to believe, I no longer think that security is what will determine the success of most any web app -- at all. Unless you have special needs, feelings of security should not be your primary metric in evaluating a framework.
\But\ from the beginning, everyone using webpy has seem to know flup sessions to be the recommended way of doing sessions:
http://webpy.org/track/wiki/SessionsWithFlup
Let's look at this another way though. If you really need security, then which is better: a simple, quickly verifiable codebase like webpy, or a massive, magical code base like django and turbogears? Do any frameworks make any guarentees of security?
I have seen several high profile sites within the last two years with major, obvious security problems. As hard as this is to believe, I no longer think that security is what will determine the success of most any web app -- at all. Unless you have special needs, feelings of security should not be your primary metric in evaluating a framework.
Luckily I don't use a massive, magical code base like Django or TurboGears. I use Pylons, which is small enough that you can understand it all, large enough that you can actually do useful things with it, and written by some very smart people.
(*But* is *But*.)
I've been pretty happy with web.py for two web apps:
http://www.colr.org
http://www.daltonlp.com/blog_my
And a bunch of small one-off things.
I like it. It's not perfect - the templating system in particular is not as nice as what it aims to replace (cheetah & kid). Yet.
For all the complaining about NIH, web.py has done a pretty good job of playing nice with other layers in the web stack (fcgi/flup, cheetah/kid). The parts that are reinvented have been reinvented in quite different (and better) ways than other frameworks. i.e. Request dispatching and DB interaction.
http://www.colr.org
http://www.daltonlp.com/blog_my
And a bunch of small one-off things.
I like it. It's not perfect - the templating system in particular is not as nice as what it aims to replace (cheetah & kid). Yet.
For all the complaining about NIH, web.py has done a pretty good job of playing nice with other layers in the web stack (fcgi/flup, cheetah/kid). The parts that are reinvented have been reinvented in quite different (and better) ways than other frameworks. i.e. Request dispatching and DB interaction.
People seem to really dislike frameworks and I know they can be more trouble then they are worth at times but I really like TurboGears. It's python based, sits on top of CherryPy (webserver) and you can take as much or as little as you need. It has a great philosophy of pulling in all thats good from all over the python world and loosely coupling it together in to a framework. It's not perfect by an means but it's a lot better then inventing that wheel again!
No and Yes. I am thinking of releasing tons of code for it though as soon as I wrap up the large project I'm working on.
I highly recommend webpy.
edit: downvote?
I highly recommend webpy.
edit: downvote?
Thanks folks for your thoughts..
no.
switched to django
switched to django
It will be interesting to see if web.py jumps on the facebook apps bandwagon before its competitors Rails, Drupal or Cheetah. Is Aron the next Zuck?
I am finding that as my project evolves, I ditch progressively more pieces of web.py. I ignored the form processing library and custom template library from the start, because plain old web.input() and Cheetah are fine for my uses. I ditched the DB library after a month or so - a single global DB connection prevented us from unit testing, and will prevent us from replicating or sharding the database. I'll probably ditch web.py's interface to Cheetah in the near future in favor of precompiled templates (necessary for i18n), at which point I'll just be using the request dispatching features. May end up ditching those too eventually as we've got our own dispatcher on top of web.py, but for now it provides a useful substrate.
That's the main benefit to web.py: it lets you get up-and-running very quickly, with little extra code to weigh you down, so you can see your startup running and adjust from there. It's basically a prototyping tool.
IMHO, startups should not be using any framework. The whole point of a framework is to abstract away common usage patterns so you can benefit from what other projects have done before. The whole point of a startup is to do something new that hasn't been done before. Once a problem domain has been studied enough to build a useful framework, it's too commodified to make any money off of. After all, if it was easy for you to build, it'll be easy for a thousand other startups to build.