Author ncoghlan
Recipients Carl.Friedrich.Bolz, Trundle, alex, benjamin.peterson, daniel.urban, eric.araujo, eric.snow, meador.inge, ncoghlan, rhettinger, terry.reedy
Date 2012-04-21.12:46:40
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1335012401.06.0.614827034022.issue11477@psf.upfronthosting.co.za>
In-reply-to
Content
And, back on topic...

I've been pondering this problem and the approach I adopted in my branch and decided it's the *wrong* way to go about it. It takes an already complex piece of code and makes it even more complicated.

A completely different approach that I'm considering is to instead make types defined in C behave more like their counterparts defined in Python. The reason sequences implemented in Python don't have this problem is because their nb_add and nb_mul slots get filled in with functions that call up into the Python __[ri]add__ and __[ri]mul__ implementations.

So my thought is that, when the type construction machinery is filling in the type slots, we could actually do something similar at the C level: define a standard _PySequenceAsNumber variable and add a pointer to that in to the tp_as_number slot. The nb_add and nb_mul slots in this structure would reference functions that delegated the relevant operations to sq_concat and sq_repeat.

I haven't actually tried this approach, so there may be practical issues with it that haven't occurred to me as yet, but it's definitely appealing as it has the potential to *simplify* the dispatch code in abstract.c instead of making it even more complicated.
History
Date User Action Args
2012-04-21 12:46:41ncoghlansetrecipients: + ncoghlan, rhettinger, terry.reedy, Carl.Friedrich.Bolz, benjamin.peterson, eric.araujo, alex, Trundle, meador.inge, daniel.urban, eric.snow
2012-04-21 12:46:41ncoghlansetmessageid: <1335012401.06.0.614827034022.issue11477@psf.upfronthosting.co.za>
2012-04-21 12:46:40ncoghlanlinkissue11477 messages
2012-04-21 12:46:40ncoghlancreate