[Python-ideas] namedtuple literals [Was: RE a new namedtuple]

[Chris Barker]

On Mon, Jul 24, 2017 at 6:31 AM, Steven D'Aprano <steve at 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 at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20170724/1d135977/attachment.html>