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 terry.reedy
Recipients Carl.Friedrich.Bolz, Trundle, arigo, daniel.urban, eric.araujo, meador.inge, ncoghlan, terry.reedy
Date 2011-03-14.17:43:37
SpamBayes Score 1.5452431e-05
Marked as misclassified No
Message-id <1300124617.88.0.728976408437.issue11477@psf.upfronthosting.co.za>
In-reply-to
Content
It seems to me that the underlying (design) flaw is having duplicate slots in the C type structure*.  I presume that having two different functions in num-add and seq-add (concat) (I know, not quite the proper names), etc, is an error. I also assume that changing the structure is out, whether frozen in the ABI or not, as disabling every extention type.

But could we change how the slots are handled? For instance, when class is created, if nun-add is absent and seq-add is present, copy seq-add to num-add and thereafter only use num-add and treat seq-add as a dummy left for back compatibility.  In other words, merge the duplicate slots in their effect, so there is a proper 1-1 relationship between syntax operators and methods, as there is for Python-coded classes.

*I am guessing that this was for convenience -- making a number? fill in num slots; making a sequence? fill in seq slots. Or perhaps Guido once had some idea of possibly separating the operators/functions at the Python level. Does not matter at present.
History
Date User Action Args
2011-03-14 17:43:37terry.reedysetrecipients: + terry.reedy, arigo, ncoghlan, Carl.Friedrich.Bolz, eric.araujo, Trundle, meador.inge, daniel.urban
2011-03-14 17:43:37terry.reedysetmessageid: <1300124617.88.0.728976408437.issue11477@psf.upfronthosting.co.za>
2011-03-14 17:43:37terry.reedylinkissue11477 messages
2011-03-14 17:43:37terry.reedycreate