> Yeah maybe a complete web2py 2 rewrite. With nice and better coding...
I really REALLY hope not... web2py is already an incredibly useful web framework and is getting better each month with new features and bug fixes. IMO investing energy in a rewrite could split the community and would certainly set back the pace of development. And I also don't feel development is significantly constrained by backwards compatibility. Maintaining backwards compatibility is one of the core advantages of web2py that attracted me to it. Richard On Aug 5, 4:30 am, Pynthon <[email protected]> wrote: > Yeah maybe a complete web2py 2 rewrite. With nice and better coding... > Alex Fanjul has a point IMO. > > On 4 aug, 20:15, Iceberg <[email protected]> wrote: > > > Perhaps we will eventually have a web2py 2.0 in the way which Alex > > Fanjul suggests. > > > Meanwhile, we can take closer look into those "many times" of "due to > > backward compatibility" issue, and see what can be adjusted. We did > > that before at least for IS_STRONG. > > > This time, for example, the datetime.utcnow issue can be easily > > addressed by a request.utcnow, and keep request.now as is but > > obsolete. Oops, problem solved without breaking backward > > compatibility. > > > Regards, > > Iceberg > > > On Aug5, 1:55am, Alex Fanjul <[email protected]> wrote: > > > > Massimo, > > > Many times I have seen that, due to backward compatibility, we are > > > forcing to write "messy" code in web2py applitacations. > > > Evenmore some issues will never fix in the right way bacause of that... > > > Won't you consider/planning to do a breakpoint with a major version > > > web2py 2.0? and solve such things? > > > > Python did it with 3.0, isn't it? > > > > Only out of curiosity, sorry if it's reduplicate question, regards, > > > Alex F > > > > El 04/08/2009 9:04, mdipierro escribió: > > > > > Changing now into utcnow would break backward compatibility. > > > > > I do agree with you that othen people may want to use > > > > > Field(....,default=datetime.utcnow()) > > > > > instead of > > > > > Field(....,default=request.now) > > > > > I will add a comment about this in the book. > > > > > Massimo > > > > > On Aug 3, 3:22 am, Armin Ronacher<[email protected]> wrote: > > > > >> Hi, > > > > >>> True. but I would not call it a race condition. We timestamp > > > >>> everything with the time when a request arrives, not when it is > > > >>> processed, unless specified otherwise (datetime.now() instead of > > > >>> request.now) > > > > >> True. But that does not make it a better idea. Also, datetime.now() > > > >> should be consistently replaced with datetime.utcnow() because using > > > >> anythign else than UTC data internally is problematic for various > > > >> reasons. See the discussion on that topic in various i18n/l10n > > > >> libraries such as babel / pytz. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~----------~----~----~----~------~----~------~--~---
