<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Jul 24, 2017 at 6:31 AM, Steven D'Aprano <span dir="ltr"><<a href="mailto:steve@pearwood.info" target="_blank">steve@pearwood.info</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">> I'm not sure why everybody have such a grip on the type.<br>
><br>
> When we use regular tuples, noone care, it's all tuples, no matter what.<br>
<br>
</span>Some people care.<br>
<br>
This is one of the serious disadvantages of ordinary tuples as a<br>
record/struct type. There's no way to distinguish between (let's say)<br>
rectangular coordinates (1, 2) and polar coordinates (1, 2), or between<br>
(name, age) and (movie_title, score). They're all just 2-tuples.<br></blockquote><div><br></div><div><br></div><div>sure -- but Python is dynamically typed, and we all like to talk abou tit as duck typing -- so asking:</div><div><br></div><div>Is this a "rect_coord" or a "polar_coord" object isn't only unnecessary, it's considered non-pythonic. </div><div><br></div><div>Bad example, actually, as a rect_coord would likely have names like 'x' and 'y', while a polar_coord would have "r' and 'theta' -- showing why having a named-tuple-like structure is helpful, even without types.</div><div><br></div><div>So back to the example before of "Motorcycle" vs "Car" -- if they have the same attributes, then who cares which it is? If there is different functionality tied to each one, then that's what classes and sub-classing are for.</div><div><br></div><div>I think the entire point of this proposed object is that it be as lightweight as possible -- it's just a data storage object -- if you want to switch functionality on type, then use subclasses.</div><div><br></div><div>As has been said, NameTupule is partly the way it is because it was desired to be a drop-in replacement for a regular tuple, and need to be reasonably implemented in pure python.</div><div><br></div><div>If we can have an object that is:</div><div><br></div><div>immutable</div><div>indexable like a tuple</div><div>has named attributes</div><div>is lightweight and efficient<br></div><div><br></div><div>I think that would be very useful, and would take the place of NamedTuple for most use-cases, while being both more pythonic and more efficient.</div><div><br></div><div>Whether it gets a literal or a simple constructor makes little difference, though if it got a literal, it would likely end up seeing much wider use (kind of like the set literal).</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I disagree: in my opinion, the whole point is to make namedtuple faster,<br>
so that Python's startup time isn't affected so badly. Creating new<br>
syntax for a new type of tuple is scope-creep.<br></blockquote><div><br></div><div>I think making it easier to access and use is a worthwhile goal, too. If we are re-thinking this, a littel scope creep is OK. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Even if we had that new syntax, the problem of namedtuple slowing down<br>
Python startup would remain. People can't use this new syntax until they<br>
have dropped support for everything before 3.7, which might take many<br>
years. But a fast namedtuple will give them benefit immediately their<br>
users upgrade to 3.7.<br></blockquote><div><br></div><div>These aren't mutually exclusive, if 3.7 has collection.NamedTuple wrap the new object. IIUC, the idea of chached types would mean that objects _would_ be a Type, even if that wasn't usually exposed -- so it could be exposed in the case where it was constructed from a collections.NamedTuple()</div><div><br></div><div>-CHB</div><div><br></div></div>-- <br><div class="gmail_signature"><br>Christopher Barker, Ph.D.<br>Oceanographer<br><br>Emergency Response Division<br>NOAA/NOS/OR&R (206) 526-6959 voice<br>7600 Sand Point Way NE (206) 526-6329 fax<br>Seattle, WA 98115 (206) 526-6317 main reception<br><br><a href="mailto:Chris.Barker@noaa.gov" target="_blank">Chris.Barker@noaa.gov</a></div>
</div></div>