a clean way to define dictionary

Alexander Schmolck a.schmolck at gmx.net
Fri Jun 20 02:04:54 CEST 2003

mis6 at pitt.edu (Michele Simionato) writes:

> Alexander Schmolck <a.schmolck at gmx.net> wrote in message news:<yfswufi6j86.fsf at black132.ex.ac.uk>...
> > mis6 at pitt.edu (Michele Simionato) writes:
> > 
> > Well, your timings are not all that meaningful because your code does nothing
> > and you only instance creation and not item access (which obviously also needs
> > to be overridden with python code). 
> This was on purpose, 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.

> > What are your results for instance creation with this class? Maybe 2.3 is
> > noticeably faster?
> > 
> > 
> > 'as
> I should perform a series of tests; anyway, some simple experiment 
> with attribute access gives me a slowdown of ~14 times. Quite a lot.

Yep, 14 times slowdown is a high price to pay for this feature.

> However, my point was that you can bypass the Python 2.3 change in the 
> dictionary constructor signature by overriding __new__ and *not* changing
> __getattr__. In this way, you don't have a performance problem.

(Again, do you mean __getitem__?) Sorry, I don't follow, could you expand (but
at least now I begin to see why you might be mainly interested in "pure"
subclassing overhead)?

> 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).


More information about the Python-list mailing list