On Sat., 13 Jun. 2020, 2:51 am Barry Warsaw, <ba...@python.org> wrote:
> On Jun 12, 2020, at 04:21, Eric Wieser <wieser.eric+nu...@gmail.com> > wrote: > > > It seems to me there are at least three stances that could be taken here: > > > > * Specifying both is considered invalid: python should consider emitting > a warning in `Type_READY` if both are filled. > > * Specifying both is considered an implementation detail specific to > CPython: the [C API docs for the type slots][2] should indicate this > > * Specifying both is explicitly allowed and considered a language > feature. `__concat__` should be added as a slot_wrapper around `sq_concat` > to allow the language feature to be accessed without writing C extensions. > > If you can define the behavior at the C layer and not at the Python layer, > then I think almost by definition it’s an implementation detail of > CPython. Whether that’s intentional or not would help determine whether > this should be demoted to a bug with an emitted warning, or promoted to a > full-on feature supported in the language. > The one part that has already sort of leaked through to the language level is that only "nb_add" fully supports operand coercion. https://bugs.python.org/issue11477 covers some of the oddities that arise when implementing *only* sq_concat. I've mostly given up on ever fixing that, as I'm not sure we can do it without breaking the workarounds that people have in place for the oddities in the status quo (there were enough other projects relying on the existing semantics that the PyPy devs found it necessary to mimic CPython's implementation quirks in this regard). That said, adding an sq_concat that raises a "don't do that" exception to an existing type that already implements nb_add sounds fine to me - from the Python level everything except operator.concat would encounter the nb_add slot first, so the exception should only trip up genuinely problematic code. Cheers, Nick. > Cheers, > -Barry > > _______________________________________________ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/DO5J63K3ACFCV63SRD6QAHT6PAIMLNKR/ > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/VFYEMJH5PXKVI72G33DHTSUW3CLWWFPN/ Code of Conduct: http://python.org/psf/codeofconduct/
