Who is using web.py?

[Anand Chitipothu]

Hi,

I would like to know who is using web.py, what they like about it and what features they wish to have. If you are using web.py for any of your projects, please let me know.

Let me start with myself.

I use web.py for openlibrary.org. Its been running from quite some time and I usually don't add ton of new features except some minor changes once in a while.

My wishlist:

It is quite some time since I've built any new applications using web.py, but wish web.py had the following:

* nice documentation. it would be nice to have sphinx documentation for web.py

* a way to write web.py extensions so that it is easier to use third-party libraries along with web.py

What about you?

Anand

[Mark Roberts]

I've got three recent projects built with web.py - all of them API services.

My first project with web.py was a game analytics API server.  It was pretty functional, but it took some time to get it to deploy properly.  The first deployment lit web.py up as an nginx uwsgi application, but this appeared to fork for every request.  This played merry hell with the in application connection pooling I was doing with psycopg2.pool.  It took some time to figure out exactly what was going wrong, but once we did we redeployed with 80->8080 port forwarding to the built in web server, which I don't think was a particularly optimal solution.  Still, it was able to handle the data stream pretty well.  Better documentation about deployment options and some of the implications there would be pretty smashing.  Also, a better built in web server.

The second project was a log merging application for the QA department.  It allowed them to do some basic analytics testing and make sure that things went as they were supposed to with the above project.  It also ran via port forwarding and the native web server.  The company downsized from 50ish to the C levels shortly after this was finished, but the QA team thought it was the best thing since sliced bread.

The third project is an IAP verification service that I wrote is an IAP verification service (https://github.com/wizzat/iapservice) that is intended to be deployed via port forwarding and the built in web server.  To the best of my knowledge the IAP service isn't in production anywhere, even at the company I was working with while between jobs.  I haven't really been able to maintain it or expand it because my time has been gobbled up by a massive 4 hour commute at my new job.

I'm in the process of writing a new API service right now, but the stubbed out web framework is written with Tornado.  I wanted to broaden my horizons a bit, and the new asynchronous task stuff looked super snazzy.

-Mark

[Ole Trenner]

Hi Anand,

[tl;dr at the bottom]

first of all I'd like to thank you and all contributors for the efforts they're putting into web.py. It's one of my most favorite (if not THE most favorite) web frameworks/libraries, even across other programming languages.

I've been using it for small, uhm, web projects (go figure!), both frontend and api/service stuff. I've written a small content management system which is based on web.py. I guess web.py is somewhere to be found in every web related python project I've done in the last years.

The thing I love most about web.py is that as I'm starting a project it provides a basic skeleton or scaffolding. It contains all the tools and things needed to get the project started right away. Just import web and off you go.
And then, as the project is evolving and developing more specialized requirements, I can take out specific bits and pieces and replace them with more specialized solutions or dedicated libraries.
This 'evolving' approach feels very natural to me and web.py supports it much better than most 'all-in-one' solutions.

Another thing I love about web.py is that it is not dogmatic about the project structure. Sure, over the years I have converged towards a specific structure, but that structure is mostly influenced and shaped by deployment requirements and the hosting environment, not by some directory structure that is required by the framework. That kind of freedom is very nice and liberating.

When thinking about some sort of wishlist, I should probably go with the parts of web.py I end up replacing over time. The first thing to go would be the templating engine, followed by the form handling. To me, they feel somewhat clunky and unintuitive, so sometimes I don't even bother using them at all. The next thing would be the database layer, although it is surprisingly versatile.

Then there are some things that are completely missing, like asynchronous stuff or threading support, but they are very application specific and not needed every time.

Then there are some minor issues with the web.py api, for example the routing/url definition. This loooong flat list is just so unforgiving, especially if you want to adjust it programmatically. It'd be great if we had some more options for that (maybe a dict? nested lists? resolver classes?).

I guess it'd be a big improvement if the application class was structured a bit differently so that extending it by subclassing was easier (or at all possible, I'm looking at you, handle_class()).

On the other hand it is a good thing that the api of web.py has been so stable over the years.

It is also quite enjoyable to read the web.py source code. To me it has been an available and complete replacement of documentation. I'd even say, don't try and make a better documentation, just make it easier to read the source code.

tl;dr: web.py is great, please don't change the foundation, although it probably could use a slightly more flexible api and an improved, extension-friendly code structure.

Cheers,
Ole.

> --
> 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 webpy+un...@googlegroups.com.
> To post to this group, send email to we...@googlegroups.com.
> Visit this group at http://groups.google.com/group/webpy.
> For more options, visit https://groups.google.com/groups/opt_out.

--
Ole Trenner
<o...@jayotee.de>

[Aydın ŞEN]

Hi Anand,

I used weby+sqlalchemy in my project (www.tatilsefasi.com) which is about outgoing tour packages. Users send request about tours and sales consultants sell it by manuel. There is no online payment option because providers doesn't support online sale for outgoing tour packages. Next step is online hotel booking. I ll integrate(xml) with some providers.

2013/10/28 Ole Trenner <o...@jayotee.de>

--
Aydın Şen

[Steven Brown]

On 10/27/2013 06:12 PM, Anand Chitipothu wrote:

Hi,

I would like to know who is using web.py, what they like about it and what features they wish to have. If you are using web.py for any of your projects, please let me know.

I am using web.py to make a webapp to track stuff that members in a club I belong to do to benefit the club.  Once you take into account members, their chapters, and the people that verify things, and many other things, it's more complicated than you might think!

Let me start with myself.

I use web.py for openlibrary.org. Its been running from quite some time and I usually don't add ton of new features except some minor changes once in a while.

My wishlist:

It is quite some time since I've built any new applications using web.py, but wish web.py had the following:

* nice documentation. it would be nice to have sphinx documentation for web.py

Oh please, dear God in Heaven yes.  Admittedly I may be spoiled by the general python and C/C++ documentation, but web.py documentation is sorely lacking.  It is plenty adequate to getting someone started; that's actually something I really like.  But when you need to look up a syntax, it just....well, sucks, if I'm being honest.  Maybe I'm approaching it wrong, and I'm still learning, but usually when I am having trouble matching up different parts of my code, I am sticking in lots of "print type(...)" statements to see what exactly I'm working with.  I would much rather be able to just look that stuff up.  And in general, just more fleshed-out documentation would be an amazing help; not to mention it would make it easier for me to sell others on it!

* a way to write web.py extensions so that it is easier to use third-party libraries along with web.py

What about you?

Ole mentioned a better forms library, and I heartily agree.  Templator has been pretty straightforward for me, but I'm not doing anything especially complicated with it.  One small feature I would love to have, so much so that I implemented it myself, is a bit more flexibility on options in select elements.  I use a JS library that updates a select's options when you select from another one (so that you can eg select make of car, and the next select gets populated with all models of that make).

Those are the big things, but other than that, I absolutely love the simplicity and low overhead in this framework!  It's my first that I have really dived in to use, after being terrified by the seeming-to-a-beginner opacity of Django.  Great work overall, let's make Aaron proud!

[Shannon Cruey]

We use web.py to provide five features in our application suite - three user interfaces and two REST APIs.  Combined, these applications are over 50k lines of code.  Our open source component is http://cato.cloudsidekick.com

(I also used it for a smallish Flexible API project that I can't seem to find the time to keep active. https://github.com/shannoncruey/FlexAPI)

Original versions of our tools were written on Windows in ASP.NET (C#).  When adding support for unix platforms, we originally tried Mono, but decided quickly a refactor to Python was the best approach.  We selected web.py because it was incredibly lightweight and easy to use, especially since we were fairly new to Python at the time.  Other frameworks have high learning curves, and assume you'll build applications from scratch in their metaphor, which we had neither the time nor desire to do.

With the help of web.py and a C# to Python conversion tool we wrote, we moved the entire application from C# to Python in less than two months.

Converted from C#, we had already solved several problems so we did not use web.py database access at all.  We use the templator, but it's only purpose was to support the "Master Page" concept from ASP.  (The applications are 100% client side script + Ajax, so templating wasn't needed.)

We use Sessions (using shelf - files caused pickle errors for some reason).  Our application talks to MongoDB, SQL Server, Oracle and MySql.

We have hundreds of "endpoints" in our API, but my 'urls' list only has a few entries - I use code to look at the path and decide which internal function to call.

I love web.py because the core is solid and doesn't force me into any particular design.  Aside from eventual Python 3 support, I hope there are no material changes to the core.  In fact, for my part the database and templating could be removed and turned in to add-ons.  Connecting to a database, or building a form directly in HTML is such standard fare these days, in my opinion it's best to just build forms natively and manipulate them client side.  (Of course, as I said above I'm tilted in that regard, as I think client side script + Ajax has served us very well.

Documentation is my only complaint.  What paltry bit is out there is confusing, and some of it still applies to older versions.  If the documentation was moved to a wiki, I'm sure this entire group would contribute.  We've solved problems with Session, global exception handling, setting Content-Type, requiring auth on only certain pages, web.input versus web.data, the list goes on, all without documentation.  Make a wiki.  If you build it, they will come. :-)

Awesome tool!

NSC

[W. Martin Borgert]

On 2013-10-27 15:12, Anand Chitipothu wrote:
> I would like to know who is using web.py, what they like about it and what
> features they wish to have. If you are using web.py for any of your
> projects, please let me know.

I'm using web.py mainly for a web UI on an embedded system, that
is cherrypy, forms, session (in-memory), but neither db nor
templates.

Given the memory and CPU constraints of the system, most people
would probably go for a C based framework, but Python in general
and web.py in particular are much easier to work with.

> My wishlist:

1. The less changes, the better! web.py is nice as it is.
2. Documentation needs true love.
3. Keep the code clean, small, readable.
4. I agree with (some of) your suggestions from 2013-05-16:
Python 3, 3rd party tool support, corrections for forms, and
sessions.

Cheers

[Christopher Mahan]

I am using web.py at bank of america for making tools available to my team (40 ppl) from my computer through we interface. I use only the dispatcher, no templates, db, or form handler. It's been 3 years with no unplanned downtime. I integrate with graphviz for dynamic diagrams, and connect to mssql server through pyodbc.

Chris Mahan
chris...@gmail.com
(818) 671-1709

[Jeffrey Zellman]

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

[Dragan Espenschied]

Dear Anand,

I am using webpy to teach art and design students web development. It is great
because there is hardly any "magic", you just write python classes and the
template language is also python. The simplicity is definitely great. I
especially found that the database abstraction layer is easy for the students to
understand. Deployment on the server is easy, we use cgi or fastcgid if a
project becomes popular.

Not so nice is boilerplate code for session initialization during debugging
mode. This should just be built-in. The documentation is kinda awful
http://webpy.org/docs/0.3/api is just truncated after "class Template(self,
text, filename='" ... luckily there is hardly anything to learn apart from
python itself.

I found out there is a problem with sending email encoded in UTF8.

Apart from that this is a great tool. Students built good stuff with it.


I used webpy for a rather complex art project here:
http://1x-upon.com/
It would have never been possible to do all the required "wrong" stuff so easily
with more advanced frameworks.

For different internal research projects, I am always using webpy.



Anand, thanks for keeping this nice software alive :)


Bests,
Dragan

Am 27.10.2013 23:12, schrieb Anand Chitipothu:
> Hi,
>
> I would like to know who is using web.py, what they like about it and what
> features they wish to have. If you are using web.py for any of your projects,
> please let me know.
>
> Let me start with myself.
>

> I use web.py for openlibrary.org <http://openlibrary.org>. Its been running from

> quite some time and I usually don't add ton of new features except some minor
> changes once in a while.
>
> My wishlist:
>
> It is quite some time since I've built any new applications using web.py, but
> wish web.py had the following:
>
> * nice documentation. it would be nice to have sphinx documentation for web.py
> * a way to write web.py extensions so that it is easier to use third-party
> libraries along with web.py
>
> What about you?
>
> Anand
>

> --
> 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 webpy+un...@googlegroups.com.
> To post to this group, send email to we...@googlegroups.com.
> Visit this group at http://groups.google.com/group/webpy.
> For more options, visit https://groups.google.com/groups/opt_out.

--
http://1x-upon.com/~despens/ >NEW!<
http://noobz.cc/
http://contemporary-home-computing.org/1tb/

[Tae Sandoval Murgan]

Hi there:

I'm developing a big web application with web.py which I hope will be
released soon. I did choose web.py over the popular Django because
it's minimalist and flexible. I really like it, but of course it could
be a lot better without change it in a radical way:

* We all agree that the documentation must be improved, maybe
rewritten. Currently I'm not sure if I'm using web.py in the
correct/most efficient way. For example, it took as a couple of hours
to discover how and way use sub-applications to structure our project.
* Yesterday I was looking some Python ORMs and I found a couple really
minimalist, one of them even lets you write plain SQL queries instead
of depending on Python objects. Maybe, MAYBE, the database.py module
could be dropped and replaced with a better documentation and put our
efforts on others aspects. I like minimalist, I like the UNIX way to
do things. We have the same discussion about the email module months
ago: way not to depend on the native Python module?
* I haven't tried another template systems, so currently I love
Templetor, specially because it is just Python so it isn't necessary
to learn specific stuff, although I'd change the $ with something more
block-wise, like <!--$ $--> (in that way it won't raise exception in
HTML editors/validators).
* In my free time I'm working on a new form.py module which is
compatible with all the new HTML5 attributes. The idea is to declare
the inputs and its validators in Python and just in Python while
currently we should manually declare the forms in the HTML to use
stuff like type="number" or max="30".
* Python 3 support.

I want to collaborate with the project, but first I should finish the
stuff that I'm programming right now.