[Python-ideas] recordclass: a mutable alternative to namedtuple

[Zaur Shibzukhov]

It is possible that this is recordclass 
<https://pypi.python.org/pypi/recordclass>  <wink>
A short example 
<http://nbviewer.ipython.org/urls/bitbucket.org/intellimath/recordclass/raw/default/examples/what_is_recordclass.ipynb> 
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... at python.org.br 
> <javascript:>> 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... at python.org <javascript:> 
> https://mail.python.org/mailman/listinfo/python-ideas 
> Code of Conduct: http://python.org/psf/codeofconduct/ 
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150401/91b3c7f7/attachment.html>