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 _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
