[Python-ideas] Anonymous namedtuples

Joseph Martinot-Lagarde contrebasse at gmail.com
Tue Apr 19 07:31:51 EDT 2016


Chris Angelico <rosuav at ...> writes:

> 
> On Tue, Apr 19, 2016 at 7:49 PM, Joseph Martinot-Lagarde
> <contrebasse at ...> wrote:
> > I'd be happy to make a factory function for my personal use, but the order
> > of kwargs is not respected. To have an elegant syntax, it has to be a
> > construct of the language.
> 
> There have been proposals to have kwargs retain some order (either by
> having it actually be an OrderedDict, or by changing the native dict
> type to retain order under fairly restricted circumstances). With
> that, you could craft the factory function easily.

I saw some proposals but forgot about them, thanks for the reminder.

I'd prefer my proposal for two reasons:
- the syntax is nicer that a factory function
- it wouldn't be possible to add keyword arguments to __getitem__ without
breaking compatibility

Those issues are relatively minor, i'd be happy with a factory function

> That said, though: I don't often feel the yearning for quick
> namedtuples. A function that today returns a namedtuple of 'x' and 'y'
> can't in the future grow a 'z' without breaking any callers that
> unpack "x, y = func()", so extensible return objects have to forego
> unpacking (eg using a dict or SimpleNamespace).
My intention wasn't to allow extensible return objects, just easier access
to the return values.

> There *is* a use-case
> for this, but it's fairly narrow - you have to have enough names that
> you don't want to just unpack them everywhere, yet still have an
> order, AND the set of names has to be constant.
It's true that python already has some commodities in place. When I first
heard about namedtuples I was pretty excited, but when I tried in practice
they are not that easy to use, with lots of duplications (the name, and
possibly the field names) and a global declaration.

For all my use cases (not only function returns) I would completely replace
namedtuple by anonymouns namedtuple.



More information about the Python-ideas mailing list