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 <[email protected]
<mailto:[email protected]>> wrote:
On 20 July 2017 at 11:35, Alexander Belopolsky
<[email protected]
<mailto:[email protected]>> wrote:
> On Wed, Jul 19, 2017 at 9:08 PM, Guido van Rossum
<[email protected] <mailto:[email protected]>> 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 | [email protected] <mailto:[email protected]>
| Brisbane, Australia
_______________________________________________
Python-ideas mailing list
[email protected] <mailto:[email protected]>
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
[email protected]
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________
Python-ideas mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
