Re: Definitive documentation on newstyle classes? (WAS: Pickling and inheritance are making me hurt)
Colin: > It seems to me that __new__ should probably be deprecated for mutable > classes. Certainly not! It is useful for mutable classes too. One just must be careful. Michele Simionato -- http://mail.python.org/mailman/listinfo/python-list
Re: Definitive documentation on newstyle classes? (WAS: Pickling and inheritance are making me hurt)
Michele Simionato wrote: It would be good to have a clear exposition of the pros and cons of __new__ usage. It is there mostly because __init__ would not work on immutable types. OTOH, you probably do not want to use __new__ on mutable types (once I was caught by this trap, google for "overriding list.__new__" if you are interested). Michele Simionato Thanks. The use of __new__ for immutable classes is described in: http://www.python.org/2.2.3/descrintro.html This distinction hadn't registered with me before. The Martelli bible doesn't bring this out. It seems to me that __new__ should probably be deprecated for mutable classes. Colin W. -- http://mail.python.org/mailman/listinfo/python-list
Re: Definitive documentation on newstyle classes? (WAS: Pickling and inheritance are making me hurt)
> It would be good to have a clear exposition of the pros and cons of > __new__ usage. It is there mostly because __init__ would not work on immutable types. OTOH, you probably do not want to use __new__ on mutable types (once I was caught by this trap, google for "overriding list.__new__" if you are interested). Michele Simionato -- http://mail.python.org/mailman/listinfo/python-list
Re: Definitive documentation on newstyle classes? (WAS: Pickling and inheritance are making me hurt)
Brian van den Broek wrote: Daniel Bickett said unto the world upon 2005-02-05 19:46: I was reading the "Pickling and inheritance are making me hurt" thread, and the latest suggestion (as of this posting) was to do with the __setstate__ and __getstate__ methods. They caught my attention because I hadn't encountered them before, and it reminded me that in the past I've never been able to very good, definitive documentation on newstyle classes. Googling for it gives little python tutorials on various sites, and even searching this newsgroup returns very specific questions, as a rule. Alas, the question: Does there exist a page that enumerates all of the features of the newstyle classes, and explains what they all do? If so, can anyone provide me with such a link? Thanks :-) Hi Daniel, it doesn't yet answer the "definitive" part, but <http://www.python.org/moin/NewClassVsClassicClass> is worth a look. Best, Brian vdB Yes, that's the best I've come across. But a clearer overall view, tied in to the Language Reference, would be very helpful. It would be good to have a clear exposition of the pros and cons of __new__ usage. Colin W. -- http://mail.python.org/mailman/listinfo/python-list
Re: Pickling and inheritance are making me hurt
[Kirk Strauser] > I have a module that defines a Search class and a SearchResult class. Try posting a minimal self-contained code sample that fails. > I use these classes by writing other modules that subclass both of them as > needed to interface with particular search engines. > > My problem is that Search defines a method (called automatically by __del__) > to save its results between invocations: > >def _saveresults(self): >self._oldresults = self._results >file = open(self._storefile(), 'w') >pickle.dump(self._oldresults, file) >file.close() > > The problem I'm having is the the pickle.dump call is failing whenever the > objects in "self.data" are instances of derivatives of SearchResult rather > than instances of SearchResult itself (which is pretty much always the > case): > >Exception pickle.PicklingError: 0xb7f7ad6c> in 0xb7ec954c>> ignored > > Now, if I overload _saveresults inside a subclass of Search, then it works. > It seems like the problem is that _saveresults is only looking inside the > same namespace as Search (where it's originally defined), even if it's > actually been inherited by another class in a different module. Is there a > way around this? Not enough relevant information to say. __del__ looks irrelevant here, apart from that you happen to be pickling while __del__ is executing. Try pickling an instance of a subclass of Search directly to see what happens. There are many reasons for why PicklingError may get raised. It's certainly true that any function in Python (method or not) executes with the globals of the module in which it's defined. While you mentioned that as a possible issue, it seemed to come out of the blue (didn't seem to follow from anything said before it). -- http://mail.python.org/mailman/listinfo/python-list
Re: Definitive documentation on newstyle classes? (WAS: Pickling and inheritance are making me hurt)
Bruno Desthuilliers wrote: > Well, the fact is that __[get|set]state__() have nothing to do with new > style classes, but with the Pickle protocol: > http://www.python.org/doc/2.3.4/lib/pickle-inst.html Thank you for pointing that out, but all the same ;) -- Daniel Bickett dbickett at gmail.com http://heureusement.org/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Definitive documentation on newstyle classes? (WAS: Pickling and inheritance are making me hurt)
Daniel Bickett said unto the world upon 2005-02-05 19:46: I was reading the "Pickling and inheritance are making me hurt" thread, and the latest suggestion (as of this posting) was to do with the __setstate__ and __getstate__ methods. They caught my attention because I hadn't encountered them before, and it reminded me that in the past I've never been able to very good, definitive documentation on newstyle classes. Googling for it gives little python tutorials on various sites, and even searching this newsgroup returns very specific questions, as a rule. Alas, the question: Does there exist a page that enumerates all of the features of the newstyle classes, and explains what they all do? If so, can anyone provide me with such a link? Thanks :-) Hi Daniel, it doesn't yet answer the "definitive" part, but <http://www.python.org/moin/NewClassVsClassicClass> is worth a look. Best, Brian vdB -- http://mail.python.org/mailman/listinfo/python-list
Re: Definitive documentation on newstyle classes? (WAS: Pickling and inheritance are making me hurt)
Daniel Bickett a écrit : I was reading the "Pickling and inheritance are making me hurt" thread, and the latest suggestion (as of this posting) was to do with the __setstate__ and __getstate__ methods. They caught my attention because I hadn't encountered them before, and it reminded me that in the past I've never been able to very good, definitive documentation on newstyle classes. Well, the fact is that __[get|set]state__() have nothing to do with new style classes, but with the Pickle protocol: http://www.python.org/doc/2.3.4/lib/pickle-inst.html (snip) Bruno -- http://mail.python.org/mailman/listinfo/python-list
Definitive documentation on newstyle classes? (WAS: Pickling and inheritance are making me hurt)
I was reading the "Pickling and inheritance are making me hurt" thread, and the latest suggestion (as of this posting) was to do with the __setstate__ and __getstate__ methods. They caught my attention because I hadn't encountered them before, and it reminded me that in the past I've never been able to very good, definitive documentation on newstyle classes. Googling for it gives little python tutorials on various sites, and even searching this newsgroup returns very specific questions, as a rule. Alas, the question: Does there exist a page that enumerates all of the features of the newstyle classes, and explains what they all do? If so, can anyone provide me with such a link? Thanks :-) -- Daniel Bickett dbickett at gmail.com http://heureusement.org/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Pickling and inheritance are making me hurt
Kirk Strauser <[EMAIL PROTECTED]> writes: > I have a module that defines a Search class and a SearchResult class. I use > these classes by writing other modules that subclass both of them as needed > to interface with particular search engines. > > My problem is that Search defines a method (called automatically by __del__) ^^^ Don't Do That. __del__ methods are bad. They mess up cyclic garbage collection, IIRC. ISTR other problems with them, too... [...] > Exception pickle.PicklingError: 0xb7f7ad6c> in 0xb7ec954c>> ignored [...] ...yeah, there's one: thanks for reminding me ;-) You may want to read up on __getstate__ and __setstate__, BTW. John -- http://mail.python.org/mailman/listinfo/python-list
Re: Pickling and inheritance are making me hurt
On Dé hAoine, Feabh 4, 2005, at 15:48 America/Chicago, Kirk Strauser wrote: I have a module that defines a Search class and a SearchResult class. I use these classes by writing other modules that subclass both of them as needed to interface with particular search engines. My problem is that Search defines a method (called automatically by __del__) to save its results between invocations: def _saveresults(self): self._oldresults = self._results file = open(self._storefile(), 'w') pickle.dump(self._oldresults, file) file.close() The problem I'm having is the the pickle.dump call is failing whenever the objects in "self.data" are instances of derivatives of SearchResult rather than instances of SearchResult itself (which is pretty much always the case): Exception pickle.PicklingError: 0xb7f7ad6c> in 0xb7ec954c>> ignored Now, if I overload _saveresults inside a subclass of Search, then it works. It seems like the problem is that _saveresults is only looking inside the same namespace as Search (where it's originally defined), even if it's actually been inherited by another class in a different module. Is there a way around this? It's hard to tell exactly what's going on. I have only suggestions what you could try to verify. There was a thread a few days ago, where it was concluded that garbage collecting happens in alphabetical order. Can't remember which one it was. You could temporarily rename self._result to self.z_result to check that. Here's a gotcha that I had in a similar context. Well, it's logical but somehow unexpected. If you do for example s = Search() s = Search() the calling sequence for the constructor and destructor is __init__() __init__() __del__() Maybe this interferes with pickling your first instance? Hope this helps debugging, Christian -- http://mail.python.org/mailman/listinfo/python-list
Pickling and inheritance are making me hurt
I have a module that defines a Search class and a SearchResult class. I use these classes by writing other modules that subclass both of them as needed to interface with particular search engines. My problem is that Search defines a method (called automatically by __del__) to save its results between invocations: def _saveresults(self): self._oldresults = self._results file = open(self._storefile(), 'w') pickle.dump(self._oldresults, file) file.close() The problem I'm having is the the pickle.dump call is failing whenever the objects in "self.data" are instances of derivatives of SearchResult rather than instances of SearchResult itself (which is pretty much always the case): Exception pickle.PicklingError: in > ignored Now, if I overload _saveresults inside a subclass of Search, then it works. It seems like the problem is that _saveresults is only looking inside the same namespace as Search (where it's originally defined), even if it's actually been inherited by another class in a different module. Is there a way around this? -- Kirk Strauser -- http://mail.python.org/mailman/listinfo/python-list
