ACTIVITY SUMMARY (2011-12-16 - 2011-12-23)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open3168 ( -7)
closed 22272 (+52)
total 25440 (+45)
Open issues wit
Martin v. Löwis wrote:
If I'm wrong and its easy to implement then please do.
Ok, so I take it that you are not interested in the idea. No problem.
Its just that I don't think it would yield results commensurate with the
effort.
Also I think its worth keeping the initial version as simple as
> Consider taking a parsed MiniDOM tree as a benchmark. It contains so
> many instances of just a couple of different classes that it just has to
> make a huge difference if each of those instances is even just a bit
> smaller. It should also make a clear difference for plain Python
> ElementTree.
> If I'm wrong and its easy to implement then please do.
Ok, so I take it that you are not interested in the idea. No problem.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscri
Mark Shannon, 23.12.2011 12:21:
Martin v. Löwis wrote:
- it would be useful to have a specialized representation for
all-keys-are-strings. In that case, me_hash could be dropped
from the representation. You would get savings compared to
the status quo even in the non-shared case.
It might trick
Martin v. Löwis wrote:
- it would be useful to have a specialized representation for
all-keys-are-strings. In that case, me_hash could be dropped
from the representation. You would get savings compared to
the status quo even in the non-shared case.
It might tricky switching key tables and
>> - it would be useful to have a specialized representation for
>> all-keys-are-strings. In that case, me_hash could be dropped
>> from the representation. You would get savings compared to
>> the status quo even in the non-shared case.
> It might tricky switching key tables and I dont think
Martin v. Löwis wrote:
The current dict implementation is getting pretty old,
isn't it time we had a new one (for xmas)?
I like the approach, and I think something should be done indeed.
If you don't contribute your approach, I'd like to drop at least
ma_smalltable for 3.3.
A number of things
Am 22.12.2011 19:15, schrieb Maciej Fijalkowski:
>> - I wonder whether the shared keys could be computed at compile
>> time, considering all attribute names that get assigned for
>> self. The compiler could list those in the code object, and
>> class creation could iterate over all methods (taki