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 benjamin.peterson
Recipients Trundle, benjamin.peterson, daniel.urban, eric.araujo, ncoghlan, pitrou, rhettinger
Date 2011-04-06.14:01:34
SpamBayes Score 2.3644584e-07
Marked as misclassified No
Message-id <BANLkTi=2MHF0=7e-1+ktjGuz91aND9odVA@mail.gmail.com>
In-reply-to <1302096267.53.0.491295632503.issue10977@psf.upfronthosting.co.za>
Content
2011/4/6 Nick Coghlan <report@bugs.python.org>:
>
> Nick Coghlan <ncoghlan@gmail.com> added the comment:
>
> "should" is a wonderful word when it comes to external APIs.
>
> We currently have a couple of problems:
>
> 1. The concrete APIs will fail noisily if given an instance of something that isn't a list, but may fail *silently* if given a subclass that adds additional state that needs to be kept in sync.
>
> 2. We don't have a standard "fast path with fallback" idiom for containers, so any code that wants to support arbitrary sequences has to either accept the performance penalty, or code the fast path at every point it gets used.
>
> Changing the concrete APIs to be more defensive and fall back to the abstract APIs if their assumptions are violated would be a win on both of those fronts.

Why not add fast paths to the generic functions if that's what you're
concerned about?

It's unexpected for the user of the functions and breaks years of
tradition. What if someone calls PyList_Append on a custom type that
doesn't do as they expect and then PyList_GET_ITEM?

It seems like asking for subtle bugs to me. The only correct way to is
change code that uses these type specific apis to use the generic
ones.
History
Date User Action Args
2011-04-06 14:01:34benjamin.petersonsetrecipients: + benjamin.peterson, rhettinger, ncoghlan, pitrou, eric.araujo, Trundle, daniel.urban
2011-04-06 14:01:34benjamin.petersonlinkissue10977 messages
2011-04-06 14:01:34benjamin.petersoncreate