A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from http://mail.python.org/pipermail/python-dev/2017-July/148619.html below:

[Python-Dev] Impact of Namedtuple on startup time

[Python-Dev] Impact of Namedtuple on startup time [Python-Dev] Impact of Namedtuple on startup timeTim Peters tim.peters at gmail.com
Mon Jul 17 17:24:17 EDT 2017
[Giampaolo Rodola' <g.rodola at gmail.com>]
> ....
> To be entirely honest, I'm not even sure why they need to be forcefully
> declared upfront in the first place, instead of just having a first-class
> function (builtin?) written in C:
>
> >>> ntuple(x=1, y=0)
> (x=1, y=0)
>
> ...or even a literal as in:
>
> >>> (x=1, y=0)
> (x=1, y=0)

How do you propose that the resulting object T know that T.x is 1. T.y
is 0, and T.z doesn't make sense?  Declaring a namedtuple up front
allows the _class_ to know that all of its instances map attribute "x"
to index 0 and attribute "y" to index 1.  The instances know nothing
about that on their own, and consume no more memory than a plain
tuple.  If your `ntuple()` returns an object implementing its own
mapping, it loses a primary advantage (0 memory overhead) of
namedtuples.
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4