On Mon, Jul 24, 2017 at 6:31 AM, Steven D'Aprano <steve@pearwood.info> wrote:
I'm not sure why everybody have such a grip on the type.
When we use regular tuples, noone care, it's all tuples, no matter what.
Some people care.
This is one of the serious disadvantages of ordinary tuples as a record/struct type. There's no way to distinguish between (let's say) rectangular coordinates (1, 2) and polar coordinates (1, 2), or between (name, age) and (movie_title, score). They're all just 2-tuples.
sure -- but Python is dynamically typed, and we all like to talk abou tit as duck typing -- so asking: Is this a "rect_coord" or a "polar_coord" object isn't only unnecessary, it's considered non-pythonic. 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. 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. 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. 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. If we can have an object that is: immutable indexable like a tuple has named attributes is lightweight and efficient 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. 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). I disagree: in my opinion, the whole point is to make namedtuple faster,
so that Python's startup time isn't affected so badly. Creating new syntax for a new type of tuple is scope-creep.
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. Even if we had that new syntax, the problem of namedtuple slowing down
Python startup would remain. People can't use this new syntax until they have dropped support for everything before 3.7, which might take many years. But a fast namedtuple will give them benefit immediately their users upgrade to 3.7.
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() -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov