Just want to clarify. When you are speaking of backward compatibility we are only interested in one way street. From web2py -> web3py and not the other way around.
On Friday, January 15, 2016 at 12:13:52 PM UTC-5, Richard wrote: > > 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 <rwat...@live.ca > <javascript:>> 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+un...@googlegroups.com <javascript:>. >> 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.
