I agree with Rob... Backward compatibility have been one of the most important feature of web2py until now. I do understand that rewrite an app may be different burden depending of how big app is or how customize and integrate with web2py it could be... But I think bad code should be leave behind replace by new better one.
Of course we don't want to lost people in the transition but web2py will still function by the meantime some get it app ready for web2py+ Richard On Fri, Jan 15, 2016 at 11:34 AM, Rod Watkins <rwatk...@live.ca> wrote: > Hello everyone, > > I've been writing web apps with web2py for about 4-5 years and I've > watched the dev forum attentively, but have never spoken up before. But on > the future of web2py, I have formed a few opinions. > > I agree that options 2 is best. I especially like the idea of writing a > set of guides to help coders transition from web2py to web3py, especially > in cases of breaking changes. For example, if FORM will replace SQLFORM, a > breaking change, a guide explaining how to rewrite SQLFORM based code to > FORM based code would be welcomed by many I would guess. I certainly would > appreciate that. In fact, I'd be willing to help write such a guide. > > But... I don't want web3py to slavishly pursue backwards compatibility > purely for its own sake. Here's what I mean. The decision, if its made, to > adopt FORM in web3py is a good example. I agree that the SQLFORM is > irremediably flawed--I've struggled with creating a custom theme, for > example, and it was just harder than it should be. Any proper refactoring > would, I think, be so drastic as to make starting from scratch a better > option. So this change is motivated by fixing weaknesses in existing code. > But that is not the only reason a breaking change may be introduced. > Sometimes, perfectly good existing code has to be abandoned because it > cannot be made to function alongside newer code that is more important to > the future of the framework. I'd like to see web3py (web4py, ..., web*n*py) > adopt new technologies that may break backwards compatibility when those > are important enough. For example, websockets are very likely going to > become a big thing. I understand that websockets in web2py are supported > (by running a tornado server), but as websocket implementations mature, it > may force breaking changes on the framework if they are to be > well-supported. I wouldn't want a desire to maintain backwards > compatibility prevent web*3*py from being the best framework it can. And > I say this as someone who has a major investment in web2py. Quite simply, I > can deal with a breaking change (especially if there is a guide to help > explain how to rewrite my code) if it means I get a better framework. > > Thanks to you all for your fantastic work. > Rod Watkins > > > On Wednesday, 13 January 2016 21:35:36 UTC-8, Massimo Di Pierro wrote: >> >> It is another experiment. >> >> It is a rewrite of some of the web2py modules and supports 90% of the >> current web2py syntax at 2.5x the speed. It works. It it cleaner and should >> be easier to port to python 3 than current web2py. >> >> We are debating on web2py developers what to do: >> 1) backport some of the new modules to web2py (specifically the new Form >> class instead of SQLFORM) >> 2) try to reach a 99.9% compatibility and release it as new major version >> with guidelines for porting legacy apps >> 3) make some drastic changes in backward compatibility and release as a >> different framework (but change what? we like web2py as it is) >> >> For now I am working on 2 to see how far I can push the backward >> compatibility. But there are some functionalities I want remove or move in >> an optional module (from legacy_web2py import *). >> >> Feel free to share your opinion on web2py developers. >> >> Massimo >> >> >> On Wed, Jan 13, 2016 at 11:04 PM, kelson _ <kel...@shysecurity.com> >> wrote: >> >>> I was looking at your recent web3py commits and hoped you could provide >>> the web3py vision/intent (or point me towards it if I missed the >>> discussion). >>> >>> Thanks, >>> kelson >>> >> >> -- > Resources: > - http://web2py.com > - http://web2py.com/book (Documentation) > - http://github.com/web2py/web2py (Source code) > - https://code.google.com/p/web2py/issues/list (Report Issues) > --- > You received this message because you are subscribed to the Google Groups > "web2py-users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to web2py+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.