On 20 July 2017 at 11:35, Alexander Belopolsky <alexander.belopolsky@gmail.com> wrote:
On Wed, Jul 19, 2017 at 9:08 PM, Guido van Rossum <guido@python.org> wrote:
The proposal in your email seems incomplete
The proposal does not say anything about type((x=1, y=2)). I assume it will be the same as the type currently returned by namedtuple(?, 'x y'), but will these types be cached? Will type((x=1, y=2)) is type((x=3, y=4)) be True?.
Right, this is one of the key challenges to be addressed, as is the question of memory consumption - while Giampaolo's write-up is good in terms of covering the runtime performance motivation, it misses that one of the key motivations of the namedtuple design is to ensure that the amortised memory overhead of namedtuple instances is *zero*, since the name/position mapping is stored on the type, and *not* on the individual instances.
From my point of view, I think the best available answers to those questions are:
- ntuple literals will retain the low memory overhead characteristics of collections.namedtuple - we will use a type caching strategy akin to string interning - ntuple types will be uniquely identified by their field names and order - if you really want to prime the type cache, just create a module level instance without storing it: (x=1, y=2) # Prime the ntuple type cache A question worth asking will be whether or not "collections.namedtuple" will implicitly participate in the use of the type cache, and I think the answer needs to be "No". The problem is twofold: 1. collections.namedtuple accepts an additional piece of info that won't be applicable for ntuple types: the *name* 2. collections.namedtuple has existed for years *without* implicit type caching, so adding it now would be a bit weird That means the idiomatic way of getting the type of an ntuple would be to create an instance and take the type of it: type((x=1, y=2)) The could still be the same kind of type as is created by collections.namedtuple, or else a slight variant that tailors repr() and pickling support based on the fact it's a kind of tuple literal. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia