If the type is a data, it probably belongs to the inside of the tuple: smart = (type="Car", cost=18_900, hp=89, weight=949) harley = (type="Motorcycle", cost=18_900, hp=89, weight=949) both_vehicles = (type(smart) == type(harley)) # True - type+cost+hp+weight on both sides same_vehicles = (smart == harley) # False - cost, hp and weight are identical, but not type Le 20/07/17 à 07:12, David Mertz a écrit :
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 <ncoghlan@gmail.com <mailto:ncoghlan@gmail.com>> wrote:
On 20 July 2017 at 11:35, Alexander Belopolsky <alexander.belopolsky@gmail.com <mailto:alexander.belopolsky@gmail.com>> wrote: > On Wed, Jul 19, 2017 at 9:08 PM, Guido van Rossum <guido@python.org <mailto:guido@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@gmail.com <mailto:ncoghlan@gmail.com> | Brisbane, Australia _______________________________________________ Python-ideas mailing list Python-ideas@python.org <mailto:Python-ideas@python.org> https://mail.python.org/mailman/listinfo/python-ideas <https://mail.python.org/mailman/listinfo/python-ideas> Code of Conduct: http://python.org/psf/codeofconduct/ <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/