Message2909
Was there a reason only dicts of the same type were comparable before? It's something that appeared before my time, so I'm not sure what the reasoning is behind the current behavior, but I doubt it's a random choice. What's the behavior in CPython? Returning null from __eq__ or -2 from __cmp__, the bevhavior before the patch, indicates it isn't implemented for that type. If that's the case, the __eq__ or __cmp__ from the other type is called, so this could be implemented in PyDefaultdict instead without modifying PyDictionary.
Similarly, what's the thinking behind removing the getArray call on PyTuple in PyException. It's another thing that has existed forever, so I don't know its provenance, but it seems like some pretty specific behavior, and the change is quite different. Is there no code that uses the existing tuple behavior? Why is the change needed?
In PyDefaultDict, I wouldn't expose the default_factory as public since you have getter and setter methods for it. Just make it private so all access is known to go through one place.
Why does the __missing__ implementation use eval to call the factory? default_factory.__call__() should have the same effect, and I'm not even sure what would happen if the factory method weren't available in the current scope. Also, seeing because written out as "bcoz" makes me shudder :)
There isn't a __copy__ method on PyObject, so there's no need to add it to PyDefaultDict. Your exposing it as copy in the template should be enough.
I'll save looking at deque for later. |
|
Date |
User |
Action |
Args |
2008-02-20 17:18:50 | admin | link | issue1804242 messages |
2008-02-20 17:18:50 | admin | create | |
|