I've been using web.py on personal and work projects for the past 3 years or so now. It is my favorite framework and the reason I continue to use python for web projects.
I think keeping the simplicity should be the #1 priority. It's a very easy framework to quickly start using. I think Python 3 support should be #1 on the list, this is something that almost every other framework has and is keeping web.py back in my opinion. After that I think it is more open up for debate. I would just like to say that lots of the issues Anand brought up don't need to be solved by adding code to web.py. Session for example, there is a great python library called Beaker that handles sessions and is pretty well regarded (https://beaker.readthedocs.org/en/latest/). The same as with the template module, I think the argument could be made to simply depreciate the current template module (keep in for backwards compatibility) and make jinja2 the default. Also as a data point, I'm using the current web.py code with Gevent monkey patched in and it works perfectly, so while some type of built in async, greenlet, gevent support could be put into the core, it is not 100% necessary at the moment. I know others commented on this, but my vote would be to fork web.py and start the python3 support. As a fork we can move forward with less concern for backwards compatibility (while still having the goal of being compatible, we don't have to if there is a good reason). A fork will require less work overall as well. But I'm open to whatever and ready to help as soon as a plan is in place. -James On Sun, Mar 15, 2015 at 2:06 PM, Anand Chitipothu <[email protected]> wrote: > Hi, > > Before we discuss about the roadmap, I would like to hear from all of you > about what are the things that you like, don't like and hate about web.py. > Please also add your wish list of features. > > I hope that'll give us change to think and plan a better roadmap. > > Let me start with myself. > > GOOD > > * The best part of web.py it its simplicity. There are not many layers of > abstractions and it is very easy to understand how things work behind the > scene. > * The db module > * simple URL dispatching > > NOT SO GOOD > * The template module - i think using indentation to identify blocks was a > bad idea. I had trouble with it lot many times. > > BAD > > * There are not many third-party libraries to use with web.py. I would > like to see more such libraries. > * documentation - we need more documentation. > > UGLY > * forms - the forms library is not as elegant as it should be. Declaring > an object and calling to to create a copy is an ugly hack. > * sessions - sessions got into web.py as part of google summer of code and > I was never happy with its quality. Some one tried to do some improvements, > but think it shouldn't have come to web.py at all. > * development & releases - I've been very bad at maintaining and handling > the releases in time. Hope I'll get better at it and expecting more people > to contribute. > > WISH LIST > * Python 3 support > * can we do asyncio with web.py? > > 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 [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/d/optout. > -- 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/d/optout.
