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

David Mertz mertz at gnosis.cx
Thu Jul 20 01:12:55 EDT 2017

I'm concerned in the proposal about losing access to type information (i.e.
name) in this proposal.  For example, I might write some code like this now:

>>> from collections import namedtuple
>>> Car = namedtuple("Car", "cost hp weight")
>>> Motorcycle = namedtuple("Motorcycle", "cost hp weight")
>>> smart = Car(18_900, 89, 949)
>>> harley = Motorcyle(18_900, 89, 949)
>>> if smart==harley and type(smart)==type(harley):
...     print("These are identical vehicles")

The proposal to define this as:

>>> smart = (cost=18_900, hp=89, weight=949)
>>> harley = (cost=18_900, hp=89, weight=949)

Doesn't seem to leave any way to distinguish the objects of different types
that happen to have the same fields.  Comparing `
smart._fields==harley._fields` doesn't help here, nor does any type
constructed solely from the fields.

Yes, I know a Harley-Davidson only weighs about half as much as a SmartCar,
although the price and HP aren't far off.

I can think of a few syntax ideas for how we might mix in a "name" to the
`ntuple` objects, but I don't want to bikeshed.  I'd just like to have the
option of giving a name or class that isn't solely derived from the field

On Wed, Jul 19, 2017 at 9:06 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 20 July 2017 at 11:35, Alexander Belopolsky
> <alexander.belopolsky at gmail.com> wrote:
> > On Wed, Jul 19, 2017 at 9:08 PM, Guido van Rossum <guido at python.org>
> wrote:
> >> The proposal in your email seems incomplete
> >
> > The proposal does not say anything about type((x=1, y=2)).  I assume
> > it will be the same as the type currently returned by namedtuple(?, 'x
> > y'), but will these types be cached? Will type((x=1, y=2)) is
> > type((x=3, y=4)) be True?.
> Right, this is one of the key challenges to be addressed, as is the
> question of memory consumption - while Giampaolo's write-up is good in
> terms of covering the runtime performance motivation, it misses that
> one of the key motivations of the namedtuple design is to ensure that
> the amortised memory overhead of namedtuple instances is *zero*, since
> the name/position mapping is stored on the type, and *not* on the
> individual instances.
> From my point of view, I think the best available answers to those
> questions are:
> - ntuple literals will retain the low memory overhead characteristics
> of collections.namedtuple
> - we will use a type caching strategy akin to string interning
> - ntuple types will be uniquely identified by their field names and order
> - if you really want to prime the type cache, just create a module
> level instance without storing it:
>     (x=1, y=2) # Prime the ntuple type cache
> A question worth asking will be whether or not
> "collections.namedtuple" will implicitly participate in the use of the
> type cache, and I think the answer needs to be "No". The problem is
> twofold:
> 1. collections.namedtuple accepts an additional piece of info that
> won't be applicable for ntuple types: the *name*
> 2. collections.namedtuple has existed for years *without* implicit
> type caching, so adding it now would be a bit weird
> That means the idiomatic way of getting the type of an ntuple would be
> to create an instance and take the type of it:    type((x=1, y=2))
> The could still be the same kind of type as is created by
> collections.namedtuple, or else a slight variant that tailors repr()
> and pickling support based on the fact it's a kind of tuple literal.
> Cheers,
> Nick.
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/

Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20170719/52e6056f/attachment.html>

More information about the Python-ideas mailing list