We use web.py a little differently than most, so hopefully my thoughts aren't too far afield.
I'll echo Anand in a few areas: simplicity is a strength and documentation is a weakness. Regarding Sessions - we require sessions for authentication and access control. I've had no issues with sessions, apart from the very rare glitch using shelf storage in the file system. Templating - I'm an Ajax purist, and therefore have little use for the server doing a ton of work building pages to deliver all at once. Templating has been ugly since it's invention, because mixing languages and syntax in an single source file is always hard to read and parse. My app delivers bare bones html/css/js and then the pages use ajax and javascript to construct the pages. Web.py is awesome for this, as it's very light and fast, and adding new ajax endpoints is extremely simple. I had originally used templating solely for a "master page" concept (common menu and footer), but ended up rolling my own version of that due to the aforementioned challenges with the templator. Javascript is unparalleled in its ability to build rich client interactions, and can be quite effectively obfuscated if needed, and offloads a lot of processing to the client allowing smaller (aka cheaper) servers. Forms - as mentioned above, I belive the traditional form post round trip is slowly dying. It's a piece of cake to build a form then submit it with an ajax post, and deal Python 3 - I agree it's necessary, especially to keep web.py alive. Were I starting a brand new project today, I'd skip web.py due to this shortcoming, so we're missing out on tons of new projects and dying a slow death. I'd suggest a fork, then a slash and burn back to the core of web.py. Same simple foundation, with critical features included (db and sessions), and a well defined plugin framework for adding things like the aforementioned beaker, jinja, etc. It'd probably be easy enough to make the fork Py2.7+, as dropping Py2.6 and older gets rid of a huge chunk of the blockers for 3.0 compatibility. It's hard to shore up the documentation of an older, full featured project. Forking and stripping it down makes new documentation much easier, especially when that documentation comes in the form of downloadable, working prototypes as mentioned. I posted one last year, I can dust off and contribute the pure Ajax examples. On Mon, Mar 16, 2015 at 9:58 AM, Primoz Anzur <[email protected]> wrote: > I agree... > Python 3 support should be a #1 thingy since that version is out for what? > Almost 7 years now? But... wasn't this already started a few times but was > dropped multiple times due to unknown reasons? > > Also, I'd like to echo the templating module needs some correcting as > well... Forced indentation *can* cause trouble, especially with more > complex templates. > Maybe something like > $for item in x: > <here be HTML> > $endfor > > Mayhaps? > ~P > > On Mon, Mar 16, 2015 at 2:25 PM, James Tyra <[email protected]> wrote: > >> 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. >> > > -- > 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.
