[Python-ideas] namedtuple literals [Was: RE a new namedtuple]
chris.barker at noaa.gov
Mon Jul 24 12:50:36 EDT 2017
On Mon, Jul 24, 2017 at 6:31 AM, Steven D'Aprano <steve at pearwood.info>
> > 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
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:
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()
Christopher Barker, Ph.D.
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 at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-ideas