5 ms·

does web.py have documentation and are you using webpy?

18 points by Keios 19y ago

chexov 19y ago
http://webpy.infogami.com/docs http://webpy.infogami.com/docs - documentation http://groups.google.com/group/webpy?lnk=oa http://groups.google.com/group/webpy?lnk=oa - Discussion Group We've built http://www.barcoderobot.com http://www.barcoderobot.com using it ...
irrelative 19y ago
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.
inklesspen 19y ago
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.
- timg 19y ago
  That security gaffe was in Markdown - a piece of junk that I've been pointing out flaws in for the past year.
  - inklesspen 19y ago
    That's not the security gaffe I'm talking about. http://groups.google.com/group/webpy/browse_frm/thread/2fcbcb60a99a1c79/ 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.
    - timg 19y ago
      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 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.
      - ralph 19y ago
        (*But* is *But*.)
      - inklesspen 19y ago
        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.
dhouston 19y ago
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.
- nostrademons 19y ago
  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.
rnc000 19y ago
no. switched to django
timg 19y ago
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?
nickb 19y ago
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.
nostrademons 19y ago
I'm using web.py. I really didn't want something like Django or even Pylons where it feels like you're programming to the framework and not to the language. In my experience (with other frameworks), this leads to a really quick 80%, and then you get really screwed over as you try to complete the remaining 20% and have to fight the framework all the way. 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.
- timg 19y ago
  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.
  - nickb 19y ago
    Everyone knows that ASM is the only true language for programmers.
  - danielha 19y ago
    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.
googvsfacebook 19y ago
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?
Keios 19y ago
Thanks folks for your thoughts..
benhoyt 19y ago
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/ 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/ http://groups.google.com/group/webpy/
dazzawazza 19y ago
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!
daltonlp 19y ago
I've been pretty happy with web.py for two web apps: http://www.colr.org http://www.colr.org http://www.daltonlp.com/blog_my 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.

18 points by Keios 19y ago

http://webpy.infogami.com/docs http://webpy.infogami.com/docs - documentation http://groups.google.com/group/webpy?lnk=oa http://groups.google.com/group/webpy?lnk=oa - Discussion Group We've built http://www.barcoderobot.com http://www.barcoderobot.com using it ...

irrelative 19y ago

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.

inklesspen 19y ago

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.

timg 19y ago
That security gaffe was in Markdown - a piece of junk that I've been pointing out flaws in for the past year.
- inklesspen 19y ago
  That's not the security gaffe I'm talking about. http://groups.google.com/group/webpy/browse_frm/thread/2fcbcb60a99a1c79/ 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.
  - timg 19y ago
    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 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.
    - ralph 19y ago
      (*But* is *But*.)
    - inklesspen 19y ago
      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.

dhouston 19y ago

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.

nostrademons 19y ago
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.

rnc000 19y ago

no. switched to django

timg 19y ago

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?

nickb 19y ago

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.

nostrademons 19y ago

I'm using web.py. I really didn't want something like Django or even Pylons where it feels like you're programming to the framework and not to the language. In my experience (with other frameworks), this leads to a really quick 80%, and then you get really screwed over as you try to complete the remaining 20% and have to fight the framework all the way. 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.

timg 19y ago
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.
- nickb 19y ago
  Everyone knows that ASM is the only true language for programmers.
- danielha 19y ago
  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.

googvsfacebook 19y ago

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?

Keios 19y ago

Thanks folks for your thoughts..

benhoyt 19y ago

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/ 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/ http://groups.google.com/group/webpy/

dazzawazza 19y ago

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!

daltonlp 19y ago

I've been pretty happy with web.py for two web apps: http://www.colr.org http://www.colr.org http://www.daltonlp.com/blog_my 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.