Diez B. Roggisch wrote:
Am 25.02.10 18:08, schrieb Robert:
After (intended/controlled) reload or similar action on a module/class
the pickle/cPickle.dump raises errors like
pickle.PicklingError: Can't pickle <class 'somemodule.SomeClass'>: it's
not the same object as somemodule.SomeClass
Cause in pickle.py (and cPickle) is a line
"if klass is not obj:"
Shouldn't it be enough to have "if klass.__name__ != obj.__name__:"
there?
No. This would alias classes of same name, but living in different modules.
So at least you need to compare these, too. I'm not sure if there aren't
at that point of comparison the module is already identical
("klass = getattr(mod, name)")
even more corner-cases. Python's import-mechanism can sometimes be
rather foot-shoot-prone.
still don't see a real reason against the mere module+name
comparison. same issues as during pickle.load. Just the class
object is renewed (intentionally)
If there are things with nested classes etc, the programmer will
have to rethink things on a different level: design errors. a
subject for pychecker/pylint - not for breaking pickle .dump ... ?
=> a bug report/feature request?
Classes can change face anyway during pickled state, why should a
over-pedantic reaction break things here during runtime?
(So far I'd need to walk the object tree in all facets and save against
inf loops like pickle himself and re-class things .. )
If anything it's a feature - and I doubt it's really needed. Because
reloading pickles with intermittend reload-module-operations is to rare
a case to be really supported IMHO.
well, reloading is the thing which I do most in coding practice :-)
For me its a basic thing like cell proliferation in biology.
In my projects particularly with GUI or with python based http
serving, I typically support good live module reloadabily even
actively by some extra little "reload support code" (which fixes
up the .__class__ etc of living Windows tree, main objects,
servers ... plus a ´xisinstance´ in very few locations) - at least
I do this for the frequently changing core modules/classes.
This way I feel a edit-run cycle >2x faster when the project is
getting bigger and bigger, or when developing things out
interactively. Code is exchanged frequently while living objects
stay for long ... works well in practice.
Reentering into the same (complex) app state for evolving those
thousands of small thing (where a full parallel test coverage
doesn't work out) is a major dev time consuming factor in bigger
projects - in C, Java projects and even with other dynamic languages.
Dynamic classes are a main reason why I use Python (adopted from
Lisp long time ago; is that reload thing here possible with Ruby too?)
I typically need just 1 full app reboot on 20..50 edit-run-cycles
I guess. And just few unit test runs per release. Even for
Cython/pyximport things I added support for this reload
edit-run-cycle, because I cannot imagine to dev without this.
Just standard pickle issues stood in the way. And this patch (and
a failover from cPickle to pickle) did well so far.
Do yourself a favor, write a unit-test that tests the desired behavior
that makes you alter your code & then reload. This makes the problem go
away, and you have a more stable development through having more tests :)
this is a comfortable quasi religious theory raised often and
easily here and there - impracticable and very slow on that fine
grained code evolution level however. an interesting issue.
I do unit tests for getting stability on a much higher level
where/when things and functionality are quite wired.
Generally after having compared I cannot confirm that "write
always tests before development" ideologies pay off in practice.
"Reload > pychecker/pylint > tests" works most effectively with
Python in my opinion.
And for GUI-development the difference is max.
(min for math algorithms which are well away from data structures/OO)
Another issue regarding tests IMHO is, that one should not waste
the "validation power" of unit tests too easily for permanent low
level evolution purposes because its a little like bacteria
becoming resistent against antibiotics: Code becoming 'fit'
against artificial tests, but not against real word.
For example in late stage NASA tests of rockets and like, there is
a validation rule, that when those tests do not go through green,
there is not just a fix of the (one) cause - screwing until it
works. the whole thing is at stake.
And the whole test scheme has to be rethought too. ideally,
whenever such a late test brakes, it requires that a completely
new higher test has to be invented (in addition) ... until there
is a minimal set of "fresh green lights" which were red only
during there own tests, but never red regarding the real test run.
A rule that unit tests are used only near a release or a milestone
is healthy in that sense I think.
(And a quick edit-(real)run-interact cycle is good for speed)
Robert
--
http://mail.python.org/mailman/listinfo/python-list
