This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author Jim.Jewett
Recipients Jim.Jewett, Mark.Shannon, benjamin.peterson, giampaolo.rodola, gregory.p.smith, jcea, jcon, pitrou, pjenvey, rhettinger, terry.reedy, vstinner
Date 2012-03-09.17:30:27
SpamBayes Score 4.26382e-07
Marked as misclassified No
Message-id <CA+OGgf73F0yzvAOiH3eazonJZ1mfN4ROK+vxtnP7bqqH4sOjXA@mail.gmail.com>
In-reply-to <1331313200.46.0.179234515795.issue13903@psf.upfronthosting.co.za>
Content
On Fri, Mar 9, 2012 at 12:13 PM, Jim Jewett

> So to get beneath 2/3 without lots of reallocation
> probably requires knowing when the key set is likely
> to be complete, and that is indeed more complex than
> the current changes.  (That said, you have left code
> in for immutable keys, so there may be cases where
> this isn't so hard after all.)

On second thought, avoiding reallocation doesn't have
to be perfect -- just good enough to work on average.

For a *normal* class, the keyset won't change after
the first instance has completed its __init__.

Which of course again leads to autoslots and a
normally NULL extra_dict.  And having done that,
it makes sense to combine the (normal) instance
dict with the type dict to simplify the lookup chain,
but ... that is probably too aggressive for the 3.3
schedule.  One silver lining to your patch plus hash
randomization is that that 3.4 should have a
pretty free hand with regards to internal details.
History
Date User Action Args
2012-03-09 17:30:28Jim.Jewettsetrecipients: + Jim.Jewett, rhettinger, terry.reedy, gregory.p.smith, jcea, pitrou, vstinner, giampaolo.rodola, pjenvey, benjamin.peterson, Mark.Shannon, jcon
2012-03-09 17:30:28Jim.Jewettlinkissue13903 messages
2012-03-09 17:30:27Jim.Jewettcreate