Better fields access and allowing a new character at the start of identifiers

To note, at least per a strict reading of the “reserved identifiers” section of the language spec, all dunder identifiers are reserved for current or future use by the core interpreter, so it seems somewhat odd to actively recommend their use in third party code (though a sufficiently long and unique name is unlikely to get shadowed in practice):

__*__: System-defined names, informally known as “dunder” names. These names are defined by the interpreter and its implementation (including the standard library). Current system names are discussed in the Special method names section and elsewhere. More will likely be defined in future versions of Python. Any use of __*__ names, in any context, that does not follow explicitly documented use, is subject to breakage without warning.

1 Like

My point was (and I believe this was what Serhiy proposed) that a PEP could sanction a dunder like __fields__ for use by such libraries.

3 Likes

Hmm, not too long ago I thought about recommending use of __<library>_<name>__ by whoever owns library on PyPI, and only reserving dunders without internal underscores for Python itself. (With some grandfathering of course.)

__reduce_ex__, __getnewargs_ex__, __newobj_ex__, __suppress_context__, __length_hint__, __text_signature__, __init_subclass__, __mro_entries__, __class_getitem__, __set_name__, __post_init__, __match_args__, …

I am not really sure how __fields__ could be useful, but __replace__() (via a public function replace()) could be useful for sure. It is common to create a modified copy of an object, and if it is immutable we cannot just use copy() + modification of a copy.

1 Like

A fair number of data objects, both inside and outside of the stdlib, have fields – being able to get them in a standard way would be quite useful.

1 Like

By “grandfathering” I meant existing multi-word dunders would be unchanged (see Grandfather clause - Wikipedia). But also that we should reserve single-word dunders that others use (__version__, __author__, a few dozen from SQLAlchemy, etc.)
And if we need __len_ex__ in the future? We should talk to the len maintainer. If they’re already using it, Python needs a different name anyway.

But are they the same type of field object? Getting “some kind of collection of some kind of fields” doesn’t sound all that useful to me.

The __replaced__ idea does sound useful, though.

1 Like

Should it be a sequence of names, a mapping, or a sequence of some rich objects? How to represent types, text descriptions, default values of field? And what are you going to do with fileds besides just printing a list of names?

We’d need a PEP to iron out the details, but I imagine the typical return would be a list of names. Since the magic happens via a __dunder__, libraries could modify what their objects returned and it would be up to them to clearly communicate that to their users.

What do we do with dictionary keys besides just print them out?