
On 27 May 2012 20:35, Eric V. Smith <eric@trueblade.com> wrote:
On 5/27/2012 3:31 PM, Calvin Spealman wrote:
On Sun, May 27, 2012 at 1:58 PM, T.B. <bauertomer@gmail.com> wrote:
On 2012-05-27 19:08, Sven Marnach wrote:
Calvin Spealman schrieb am Sun, 27. May 2012, um 09:42:26 -0400:
- record - flexobject - attrobject - attrdict - nameddict - namedobject
Since the proposed type is basically an `object` allowing attributes, another option would be `attrobject`.
Adding an `__iter__()` method, as proposed earlier in this thread, seems unnecessary; you can simply iterate over `vars(x)` for an `attrobject` instance `x`.
What about an `__iter__()` method that works like `dict.items()`? Then you can do a round trip with ns = attrobject(**d) and d = dict(ns) allowing you to quickly convert between attribute-based and item-based access in either direction.
Is this whole class really necessary? As said before, this type is implemented numerous times: * empty class (included in the Python Tutorial) [1] * argparse.Namespace [2] * multiprocessing.managers.Namespace [3] * bunch (PyPI) that inherits from dict, instead of wrapping __dict__ [4] * many more...
All of the re-implementations of essentially the same thing is exactly why a standard version is constantly suggested.
That said, it is so simple that it easily has many variants, because it is only the base of the different ideas all these things implement.
A test of the concept would be: could the uses of the similar classes in the standard library be replaced with the proposed new implementation?
Eric.
_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas