On Mon, Jul 24, 2017 at 6:31 AM, Steven D'Aprano <st...@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.bar...@noaa.gov
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
