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 > <javascript:>> 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.
