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<armin.ronac...@active-4.com> 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. >> >> >>> True but I believe we never do that in web2py. It is also true that >>> nothing prevent the user from doing it but the same would be true with >>> other frameworks. >>> >> You're not doing it, a user might be doing that by accident or because >> he things it should work. This problem does not exist in other >> frameworks because besides web2py I don't know a single one that does >> this sort of execfile() + namespace thing or uses any other kind of >> throwaway modules. As soon as a single reference leaks from the >> execfile()'d namespace you're in big troubles and due to the open >> nature of Python this could happen very, very fast. >> >> >>> Yes but because all relevant application code is executed within a >>> context and there are no references outside the context to stuff >>> inside the context, when a request is completed, the context is >>> deleted and everything should be garbage collected. >>> >> That depends on two things. First not having a reference leaked, >> which could happen with abstract base classes and other stuff that >> uses registries or steals non-weak references. Also and more >> importantly, the file descriptor limit is very low and the majority of >> Python implementations will only collect that on the GC run (always, >> no matter where references are). Say you're opening three files per >> request and you have more than 100 requests/sec you could lose all >> file descriptors that are available before the GC even thought about >> running. >> >> Regards, >> Armin >> > > > > -- Alejandro Fanjul Fdez. alex.fan...@gmail.com www.mhproject.org --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~----------~----~----~----~------~----~------~--~---
