[Python-ideas] Add a dict with the attribute access capability

[Chris Barker]

On Wed, Nov 29, 2017 at 12:52 AM, Serhiy Storchaka <storchaka at gmail.com>
wrote:

> This is a dict subclass which allows to access items as attributes.
>
> d = plistlib.Dict()
> d['a'] = 1
> assert d.a == 1
> d.b = 2
> assert d['b'] == 2
>


> What do you think about reviving this type as general purpose type in
> collections or types


Am I I the only one that thinks this is a "Bad Idea"?

For me, it simply confuses even more the question of "is this code or is
this data?" -- which is a difficult enough design question in a dynamic
language.

And the couple of libraries I"ve worked with that do this I liked at first,
but grew to find problematic.

The key problem is that keys in dicts can be anything immutable, while
names have a lot more restrictions on them. And in a case like this, you
can't use a key that happens to be the same as an existing dict attribute
-- at least not in the same way.

In particular, I've struggled with the netCDF4 lib and Colander.

I've used netCDF4 more, so I'll talk about that:

netCDF4 is a Python wrapper around the netcdf scientific data file format.
netcdf has "variables" whiuch hold arrays of data, and attributes (for meta
data).

The netCDF4 python lib wraps a native netcdf4 variable with a python object
that python attributes (names) for each of the netcdf variable attributes.
Pretty nifty, really, you can do things like:

vel = dataset.variables['velocity']

print("velocity is in units of:", vel.units)

kinda cool, but in fact it gets harder to deal with in "real code" as
opposed to quicky scripts than if variables has a dict-like attribute:

print("velocity is in units of:", vel.atts['units'])

Why? because netcdf variables can have arbitrary attributes, so your code
tends to be hard-coded for specific data sets, and breaks fast if the data
files are not compliant.

That's what I mean by the difference between code and data -- the
attributes of a netcdf variable is data -- not code.

Granted, with Python, you can use try: except AttributeError, and setattr,
and all that to work with these attributes as though they are data, but
then you lose all the advantages of having them as attributes anyway. setattr
and the like shulud be used for when metaprogramign is called for - not for
everyday data manipulation.

Oh, and it's also uglier to get/set values in bulk (though the proposed
dict_with_attributes would present both APIs, so not as restrictive.)

You also have problems with keys that mirror actual attributes. So you use
the dict interface to deal with those -- but if you have to choose your
interface according to what the values of the data are -- you've got the
whole, it's not code, it's data! problem again.

Anyway -- those are my $0.02 -- from experience working with such things in
the real world, with real code, and real data....

-Chris

-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20171129/f56d0ca2/attachment.html>