<div dir="ltr">I'm concerned in the proposal about losing access to type information (i.e. name) in this proposal. For example, I might write some code like this now:<br><br><font face="monospace, monospace">>>> from collections import namedtuple</font><div><font face="monospace, monospace">>>> Car = namedtuple("Car", "cost hp weight")</font></div><div><font face="monospace, monospace">>>> Motorcycle = namedtuple("Motorcycle", "cost hp weight")</font></div><div><font face="monospace, monospace">>>> smart = Car(18_900, 89, 949)</font></div><div><font face="monospace, monospace">>>> harley = Motorcyle(18_900, 89, 949)</font></div><div><font face="monospace, monospace">>>> if smart==harley and type(smart)==type(harley):</font></div><div><font face="monospace, monospace">... print("These are identical vehicles")</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="arial, helvetica, sans-serif">The proposal to define this as:<br><br></font><font face="monospace, monospace">>>> smart = (cost=18_900, hp=89, weight=949)</font></div><div><font face="monospace, monospace">>>> </font><span style="font-family:monospace,monospace">harley = (cost=18_900, hp=89, weight=949)</span></div><div><font face="monospace, monospace"><br></font></div><div><font face="arial, helvetica, sans-serif">Doesn't seem to leave any way to distinguish the objects of different types that happen to have the same fields. Comparing `</font><font face="monospace, monospace">smart._fields==harley._fields</font><font face="arial, helvetica, sans-serif">` doesn't help here, nor does any type constructed solely from the fields.</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">Yes, I know a Harley-Davidson only weighs about half as much as a SmartCar, although the price and HP aren't far off.</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">I can think of a few syntax ideas for how we might mix in a "name" to the `ntuple` objects, but I don't want to bikeshed. I'd just like to have the option of giving a name or class that isn't solely derived from the field names.</font></div><div><font face="monospace, monospace"><br></font></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 19, 2017 at 9:06 PM, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 20 July 2017 at 11:35, Alexander Belopolsky<br>
<span class=""><<a href="mailto:alexander.belopolsky@gmail.com">alexander.belopolsky@gmail.<wbr>com</a>> wrote:<br>
> On Wed, Jul 19, 2017 at 9:08 PM, Guido van Rossum <<a href="mailto:guido@python.org">guido@python.org</a>> wrote:<br>
>> The proposal in your email seems incomplete<br>
><br>
> The proposal does not say anything about type((x=1, y=2)). I assume<br>
> it will be the same as the type currently returned by namedtuple(?, 'x<br>
> y'), but will these types be cached? Will type((x=1, y=2)) is<br>
> type((x=3, y=4)) be True?.<br>
<br>
</span>Right, this is one of the key challenges to be addressed, as is the<br>
question of memory consumption - while Giampaolo's write-up is good in<br>
terms of covering the runtime performance motivation, it misses that<br>
one of the key motivations of the namedtuple design is to ensure that<br>
the amortised memory overhead of namedtuple instances is *zero*, since<br>
the name/position mapping is stored on the type, and *not* on the<br>
individual instances.<br>
<br>
>From my point of view, I think the best available answers to those<br>
questions are:<br>
<br>
- ntuple literals will retain the low memory overhead characteristics<br>
of collections.namedtuple<br>
- we will use a type caching strategy akin to string interning<br>
- ntuple types will be uniquely identified by their field names and order<br>
- if you really want to prime the type cache, just create a module<br>
level instance without storing it:<br>
<br>
(x=1, y=2) # Prime the ntuple type cache<br>
<br>
A question worth asking will be whether or not<br>
"collections.namedtuple" will implicitly participate in the use of the<br>
type cache, and I think the answer needs to be "No". The problem is<br>
twofold:<br>
<br>
1. collections.namedtuple accepts an additional piece of info that<br>
won't be applicable for ntuple types: the *name*<br>
2. collections.namedtuple has existed for years *without* implicit<br>
type caching, so adding it now would be a bit weird<br>
<br>
That means the idiomatic way of getting the type of an ntuple would be<br>
to create an instance and take the type of it: type((x=1, y=2))<br>
<br>
The could still be the same kind of type as is created by<br>
collections.namedtuple, or else a slight variant that tailors repr()<br>
and pickling support based on the fact it's a kind of tuple literal.<br>
<br>
Cheers,<br>
Nick.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Nick Coghlan | <a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a> | Brisbane, Australia<br>
</font></span><div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">http://python.org/psf/<wbr>codeofconduct/</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Keeping medicines from the bloodstreams of the sick; food <br>from the bellies of the hungry; books from the hands of the <br>uneducated; technology from the underdeveloped; and putting <br>advocates of freedom in prisons. Intellectual property is<br>to the 21st century what the slave trade was to the 16th.<br></div>
</div>