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
names.
On Wed, Jul 19, 2017 at 9:06 PM, Nick Coghlan <ncogh...@gmail.com> wrote:
> On 20 July 2017 at 11:35, Alexander Belopolsky
> <alexander.belopol...@gmail.com> wrote:
> > On Wed, Jul 19, 2017 at 9:08 PM, Guido van Rossum <gu...@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 | ncogh...@gmail.com | Brisbane, Australia
> _______________________________________________
> Python-ideas mailing list
> Python-ideas@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.
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
