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

[Brice PARENT]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20170720/a678b388/attachment-0001.html>