When possible, I use web.py for my web development needs. This includes 
JSON apis, small tools, and full fledged web applications. Some web app 
examples include a billable work tracker that syncs with Google calendar (
https://github.com/jzellman/keras), tools to interface with existing legacy 
databases, and an accounting/inventory management system. In the past I've 
built large applications in Java (Struts & Spring) and Ruby on Rails. With 
Java and Ruby web apps, I have a hard time remembering things due to the 
frameworks being so large and nested. I have to keep the documentation open 
at all times and constantly refer to Google University. Going against the 
grain in these frameworks yields a lot of time in the bowels of the code 
base trying to monkey patch this or monkey patch that. I currently 
maintain/work on a couple Java and Ruby web applications, and after working 
on them, I long for Python and web.py. Here is what I like:

* Python - Such a simple language, yet very powerful. Easy to read.
* Web.py's flat design / small code base - Makes understanding the code and 
keeping the framework concepts in my head easy.
* Web.py's readability - Again, it makes understanding the code and what's 
going on a breeze.
* web.db - For most things, I find ORMs add yet another layer of 
abstraction. Rather than try and mask the db from you, web.py tries to make 
it easier to work with. 
* web.browser - This makes testing web requests nice.
* webpy.org - The site's code examples and cookbook are nice.
* stability - The codebase hasn't changed a lot over the years which makes 
it a breeze to start new projects and maintain old ones.

My wishlist:

* stability/small footprint - Keep the code small and tight. Adding 
features means maintaining those features and also keeping them in your 
head/understanding them. Any new feature/addition should be worth the 
technical over head. (Not sure how this should be determined though :)). 
* web.py documentation - The code is very easy to read, but Sphinx 
documentation would be nice. The docs on the web.py site are currently 
broken (see my pull request I made a few days ago to fix this: 
https://github.com/webpy/webpy/pull/254).
* web.form - In some of my projects I tend to monkey patch rendering of 
inputs. Without making the web.form code base larger or harder to 
understand, it would be nice to be able to customize the rendering of form 
fields.
* Lots of open issues on Github - Some issues contain patches for fixes, 
others add new features, and others are questions about potential 
bugs/issues. It would be nice to clean that up a bit, patch the things that 
are worth patching, close the things that are not, verify the bugs/issues. 
I know this is a lot of work and very hard to determine what is good for 
web.py and what is better as a custom patch/extension. I'm definitely 
willing to help with this.
* Cookbook - The cookbook contains concepts that I tend to use a lot with 
web apps: sessions, csrf prevention, http auth, etc. Adding these to web.py 
would go against my first point (stability/small footprint). But maybe they 
belong in a separate repository (webpy-cookbook) that way the code samples 
can be versioned with web.py? Maybe not and moving to sphinx documentation 
will make these tied to the version of web.py?

Thanks and lemme know if you need any help with anything!

Jeff


-- 
You received this message because you are subscribed to the Google Groups 
"web.py" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/webpy.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to