On Oct 17, 2019, at 01:35, Steve Jorgensen firstname.lastname@example.org wrote:
Along with this idea, maybe `namedtuple` should became a type (not just a callable as it is now) for classes produced by calling `namedtuple()`. The `namedtuple` type could in turn inherit from `tuple` and from `Record` (or `Struct` or whatever name is decided for that).
If it’s the type of the classes, then it’s a metaclass. And it definitely shouldn’t inherit from tuple or Record; that’s mixing up the levels (like making the list type be a Sequence instead of making list objects be Sequences).
If it’s the type of the objects, then each namedtuple is no longer its own type, which defeats the purpose of many uses of namedtuple. Also, it would be a very weird class where instantiating the class doesn’t give you an instance, but instead something that has to be called again to get an instance. If there were an exceptionally good reason for that, “very weird” might be acceptable, but I don’t think “making all namedtuple instances detectable as instances of Record” qualifies.
Also, you could get what you want without changing namedtuple from a function: just register the class before returning it (or add it as a base up top) and you’re done.
In fact. If there were a Record ABC, you could trivially do this yourself:
def recordtuple(*args, **kw): cls = collections.namedtuple(*args, **kw) collections.abc.Record.register(cls) return cls
But meanwhile, you still haven’t given any reason why Record would be useful. What exactly is it supposed to mean? When would you want to check it? What would you do with an object only if you know it’s a Record?
This isn’t like checking for a POD type in C++ or a struct type in Swift, because none of the important things that tells you even make sense in Python.