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."
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
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.
Python-ideas mailing list
Code of Conduct: http://python.org/psf/codeofconduct/