From: SourceForge.net <no...@so...> - 2006-12-22 14:24:32
|
Bugs item #1152612, was opened at 2005-02-26 22:17 Message generated for change (Comment added) made by leouserz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112867&aid=1152612&group_id=12867 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core Group: Deferred Status: Open Resolution: None Priority: 2 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: vars(obj) returns PyStringMap instead of DictType Initial Comment: When getting an object's __dict__, the type() of the dictionary object returns PyStringMap. This causes a problem because types.DictType does not match PyStringMap. Some existing Marshallers (in my case, xmlrpclib) expect an Instance's __dict__ to be a DictType when marshalling an Instance (such as an Exception). It looks like types.DictType should match org.python.core.PyStringMap. When getting the __dict__ of an Instance in CPython, it returns a type of DictType. -Steve leo...@nu... ---------------------------------------------------------------------- Comment By: leouser (leouserz) Date: 2006-12-22 14:24 Message: Logged In: YES user_id=1277399 Originator: NO its possible that this could be fixed by just ditching the PyStringMap used internally and switching over to PyDictionary. From experimenting with gutting PyStringMap and replacing its internal arrays and hashing with a HashMap, I was able to get an increase in performance. Given that the Dictionary appears remarkable similiar to that implementation---> forwarding to its Hashtable(yuck), there may not be a performance reason to stick with the PyStringMap(assuming that is the reason that there is a PyStringMap). leouser ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112867&aid=1152612&group_id=12867 |