“complex (whatever the next specifier is)”. Not really ‘whatever’. You can not have a ‘complex bool’ or ‘complex int’. What other types of complex are there besides complex double?
Sure, it is perfectly fine… Some Z<char> combinations will error out, just like any random character will error out. But I could have a Z<decimal> or a Zi dtype, just almost nobody uses it.
I would argue that Python should accept that the NumPy implementation as the canonical implementation since the ecosystem around that is a far more important user of it than Python itself.
That doesn’t mean Python can’t break with it of course! I just want it to be clear about the fact that it is breaking with the important prior implementation.
I think that recent (year ago) addition to the PEP clarify things:
Yeah, true… But in the discussion nobody noted the fact to the SC that it is incorrect to call these “unimplemented”. All of the additional format string specifiers are implemented by a vast ecosystem downstream. So there is a vital piece of information missing here.
Maybe I am missing this, but if this information was considered when merging that PR, then yes, I agree. But I guess I’ll ping @encukou on that.
Yeah, that would be great. I suggested: Buffer protocol and arbitrary (data) types - #13 by seberg (sorry that I lost track on this, for a while tried to rope in more people, but that effort petered out. I would be interested to restart it…).
(That said, I don’t think Zd fits the bill here as it is existing prior art and any extension needs to not use a single/multiple character pattern.)