On Wed, Jul 26, 2017 at 11:58:44AM +1200, Greg Ewing wrote:
If we're going to have such a type, I suggest making it a pure named-fields object without any tuple aspects. In which case "ntuple" wouldn't be the right name for it, and something like "record" or "struct" would be better.
Guido's time machine strikes again. from types import SimpleNamespace By the way: records and structs define their fields in a particular order too. namedtuple does quite well at modelling records and structs in other languages.
Also, building a whole type object for each combination of fields seems like overkill to me. Why not have just one type of object with an attribute referencing a name-to-slot mapping?
You mean one globally shared mapping for all ntuples? So given: spam = ntuple(name="fred", age=99) eggs = ntuple(model=2, colour="green") we would have spam.colour == 99, and eggs.name == 2. Personally, I think this whole proposal for implicitly deriving type information from the way we instantiate a tuple is a bad idea. I don't see this becoming anything other than a frustrating and annoying source of subtle, hard to diagnose bugs. -- Steve