It is possible that this is recordclass  <wink>
A short example to illustrate that fact.

суббота, 28 марта 2015 г., 16:37:40 UTC+3 пользователь Steven D'Aprano написал:

On Fri, Mar 27, 2015 at 04:13:46PM -0700, Andrew Barnert wrote:
> On Mar 27, 2015, at 06:22, Joao S. O. Bueno <jsb...@python.org.br> wrote:
[...]
> > The Python equivalent of a C Struct.
>
> But a C struct is not a subtype of, or substitutable for, a C array.
> It's not indexable. And the same is true with the equivalents in other
> languages. In fact, the dichotomy between struct--heterogeneous
> collection of fixed named fields--and array--homogeneous collection of
> indexed fields--goes back way before C. So, if you want the equivalent
> of a C struct, there's no reason to make it an iterable in Python.

Joao said "The Python equivalent of a C struct", not "a C struct".
Python is not C, and Python data types are not limited to what C does.
Python strings aren't limited to C null-delimited strings, and Python
ints aren't limited to what C ints can do.

I think the original thread was quite explicit about what is wanted:
something like a mutable equivalent to namedtuple. Namedtuples are used
in Python where C would use a struct, or Pascal a record, except that
namedtuples (being tuples) are immutable. I think it's quite reasonable
to want a mutable version.

Effectively, namedtuple is just a convenience function for wrapping up a
bunch of nice-to-have but not essential functionality around an
immutable struct. Python got by with unnamed tuples for over a decade,
so it's not like we *have* to have namedtuples. But having got them,
would we go back to using regular tuples as a struct? Hell no. Having
named fields is so much better.



> And a class already is the Python of a C struct, it's just that it can
> do _more_ than a C struct.

This is why it is unfair to insist that a Python equivalent of a C
struct be limited to what C structs do.


> > Just that.
> > An easy to create class, with named fields,
>
> Which is easy to do: just create a class, and create its fields in the
> __init__ method (or, in some cases, it's acceptable to use class
> attributes as "default values" for instance attributes).

If this is so easy, why we have namedtuple *and* SimpleNamespace
in the standard library. Are they both mistakes?

SimpleNamespace is especially interesting. The docs say:

"However, for a structured record type use namedtuple() instead."

https://docs.python.org/3/library/types.html#types.SimpleNamespace


which is great if you want an *immutable* structured record type, but
not if you want a mutable one.

Which brings us back to where this thread started: a request for a
mutable version of namedtuple. That's trickier than namedtuple, because
we don't have a mutable version of a tuple to inherit from. Lists won't
do the job, because they have a whole lot of functionality that are
inappropriate, e.g. sort, reverse, pop methods.

That makes it harder to create a mutable structured record type, not
simpler.

Think about the functional requirements:

- it should be semantically a struct, not a list or array;

- with a fixed set of named fields;

- fields should be ordered: a record with fields foo and bar is not the
same as a record with fields bar and foo;

- accessing fields by index would be a Nice To Have, but not essential;

- but iteration is essential, for sequence unpacking;

- values in the fields must be mutable;

- it should support equality, but not hashing (since it is mutable);

- it must have a nice repr and/or str;

- being mutable, it may directly or indirectly contain a reference to
itself (e.g. x.field = x) so it needs to deal with that correctly;

- support for pickle;

- like namedtuple, it may benefit from a handful of methods such as
'_asdict', '_fields', '_make', '_replace' or similar.


Does this sound easy to write? Well, sure, in the big picture, it's
hardly a 100,000 line application. But it's not a trivial class.



--
Steve
_______________________________________________
Python-ideas mailing list
Python...@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/