You are correct. There ar no problems using trunk (and future web2py versions) if classes have no __del__ method.
On Feb 1, 5:00 pm, Anthony <abasta...@gmail.com> wrote: > On Tuesday, February 1, 2011 3:16:12 PM UTC-5, Massimo Di Pierro wrote: > > In web2py you cannot store instances of objects into session. While > > Armin makes it tool like this is a web2py problem this is more complex > > and general than that. In Python if you pickle and object that is > > instance of a class defined in /path1/mymodule.py and then you > > unpickle on a different installation where the class is defined in / > > path2/mymodule.py you may run into problems. Because web2py does not > > require installation (it is a feature) and has hot plug and play of > > apps (another feature) we cannot pickle instances (the price we pay > > for those features). To me it is worth it. > > Is this limitation documented anywhere? > > > I agree with Armin that in the case of exec (and web2py uses exec), > > the self references are created whether you want them or not. That > > means one should not define classes in Models and Controllers. I have > > issued that warning already to our users and, I have never seen this > > being a problem in practice. > > My understanding is that with the recent fix (using gc), we can include > classes in models and controllers, as long as they don't have a __del__ > method > (https://groups.google.com/forum/#!msg/web2py/zE1cGK2x288/R6fTdEQjNOoJ). Is > that right? That should be documented as well. > > > Nothing in life is perfect and every design decision has a tradeoff. > > A quote from Armin's post: > > "Because one of the things we all have to keep in mind: if a Python > developer starts his journeys in the twisted world of wrongly executed > Python modules they will be very confused when they continue their travels > in another Python environment. And having different semantics in different > frameworks/modules/libraries is very hurtful for Python as a runtime and > language." > > He (and Jacob, and others) seems to be very concerned about following > conventions. Of course, that's reasonable, as conventions can be very > helpful, but there's always going to be some tension be convention and > innovation. The above quote implies dire consequences if a few libraries and > frameworks happen to buck this particular convention, but is there actual > evidence of significant developer confusion or other supposed harm to > Python? If we extend this logic, Python itself probably shouldn't exist > because it violates conventions established by C and other earlier languages > and might confuse developers as they move between environments. > > Anyway, it's interesting that Armin didn't find arguments about the > importance of convention so compelling when it came to creating an > alternative to the Standard Library logging > module:http://plumberjack.blogspot.com/2010/09/python-logging-functionality-... > > Anthony
