a clean way to define dictionary
mis6 at pitt.edu
Fri Jun 20 15:52:06 CEST 2003
Alexander Schmolck <a.schmolck at gmx.net> wrote in message news:<yfsof0t7gwp.fsf at black132.ex.ac.uk>...
> mis6 at pitt.edu (Michele Simionato) writes:
> I wanted to measure the slowdown due to "pure"
> > subclassing, i.e. without doing anything to __getattr__ and __setattr__.
> Do you maybe mean __getitem__/__setitem__? I'm not sure why you are interested
> in the "pure" subclassing overhead, this doesn't seem a particularly
> meaningful quantity in the context of comparing it to the price to pay for no
> built-in dict(foo='bar') sugar.
> > Of course, if you override __getattr__, there is an issue, but the
> > issue would be the same with Python 2.2.
> > I am curious to test the difference between Python 2.2 and 2.3;
> > I will look at the instance creation time too, but this is less
> > important than the access time, since typically I create a dictionary
> > only once.
> Indeed (which is why having to write your own syntactic sugar one-liner
> wouldn't even be a performance problem).
Sorry for the typo, of course I meant __setitem__/__getitem__.
I am saying that a workaround for the change of the constructor signature
is to subclass dict and to override the constructor. There is
not a big penalty and you seems to agree (your last sentence).
Overriding __getitem__ gives a big penalty, that's true, but this has
nothing to do with the change of the constructor in Python 2.3, right ?
I do not understand where the source of the confusion is (if any).
More information about the Python-list