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

https://news.ycombinator.com/item?id=25280

by Keios • 19 years ago

18 28 19 years ago

news.ycombinator.com

chexov• 19 years ago

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 ...

irrelative• 19 years 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.

inklesspen3• 19 years 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.

timg6• 19 years ago

That security gaffe was in Markdown - a piece of junk that I've been pointing out flaws in for the past year.

inklesspen3• 19 years ago

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.

dhouston3• 19 years 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.

nostrademons3• 19 years 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• 19 years ago

no.

switched to django

timg6• 19 years 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?

nickb2• 19 years 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.

nostrademons3• 19 years 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.

timg6• 19 years 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.

nickb2• 19 years ago

Everyone knows that ASM is the only true language for programmers.

danielha• 19 years 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.

dhouston3• 19 years ago

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.

dhouston3• 19 years ago

btw, cough, someone needs a <meta content="text/html; charset=UTF-8" http-equiv="content-type" /> (or equivalent) in their <head> section :)

timg6• 19 years ago

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.

nostrademons3• 19 years ago

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.

googvsfacebook• 19 years 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• 19 years ago

Thanks folks for your thoughts..

benhoyt• 19 years 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/

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/

dazzawazza• 19 years 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• 19 years ago

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.

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

Related Stories