Back in early 2016 there was an idea submitted[1] by Joseph Martinot-Lagarde in
regard to anonymous namedtuples. The crux of the submission was the idea of
instantiating a namedtuple using only Python's generic tuple syntax plus
keyword arguments. At the time, the major rebuttal against this ide
The proposal doesn't work well with type hints: atuple(a=1, b=2) and
atuple(a="a", b="b") generates the same type.
Also, the automatic creation of a new type on-demand can lead to
uncontrollable memory growth.
On Thu, Mar 24, 2022 at 6:15 PM wrote:
> Back in early 2016 there was an idea submitt
Well you have the values as they're passed in; just (optionally?) include the
type in the signature if you want type differentiation
>>> def anamedtuple(**kwargs):
... signature = " ".join([f"{k}: {type(v)}" for k, v in kwargs.items()])
... _type = anamedtuple.__dict__.get(signatu
On 3/23/2022 5:03 PM, [email protected] wrote:
Back in early 2016 there was an idea submitted[1] by Joseph Martinot-Lagarde in
regard to anonymous namedtuples. The crux of the submission was the idea of
instantiating a namedtuple using only Python's generic tuple syntax plus
keyword arg
On Thu, Mar 24, 2022 at 4:44 PM Eric V. Smith wrote:
> I don't think this is justifiable as built-in behavior. Just rename your
> function "t", then you can write t(x=12, y=16).
If nothing else, a good way to prototype it and see if folks like it. I
agree that there may be little reason to make
On 2022-03-24 10:43, Andrew Svetlov wrote:
The proposal doesn't work well with type hints: atuple(a=1, b=2) and
atuple(a="a", b="b") generates the same type.
I'm neither here nor there on the original proposal, but I just want to
push back against this reasoning. Type hints are an entirely o
