<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 29, 2017 at 12:52 AM, Serhiy Storchaka <span dir="ltr"><<a href="mailto:storchaka@gmail.com" target="_blank">storchaka@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">This is a dict subclass which allows to access items as attributes.<br>
<br>
d = plistlib.Dict()<br>
d['a'] = 1<br>
assert d.a == 1<br>
d.b = 2<br>
assert d['b'] == 2<br></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">What do you think about reviving this type as general purpose type in collections or types</blockquote><div><br></div><div>Am I I the only one that thinks this is a "Bad Idea"?</div><div><br></div><div>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.</div><div><br></div><div>And the couple of libraries I"ve worked with that do this I liked at first, but grew to find problematic.</div><div><br></div><div>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.</div><div><br></div><div>In particular, I've struggled with the netCDF4 lib and Colander.<br></div><div><br></div><div>I've used netCDF4 more, so I'll talk about that:</div><div><br></div><div>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).</div><div><br></div><div>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:</div><div><br></div><div><font face="monospace, monospace">vel = dataset.variables['velocity']</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">print("velocity is in units of:", vel.units)</font></div><div><br></div><div>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:</div><div><br></div><div><font face="monospace, monospace">print("velocity is in units of:", vel.atts['units'])</font><br></div><div><br></div><div>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.</div><div><br></div><div>That's what I mean by the difference between code and data -- the attributes of a netcdf variable is data -- not code.</div><div><br></div><div>Granted, with Python, you can use <font face="monospace, monospace">try: except AttributeError</font>, and<font face="monospace, monospace"> setattr</font>, 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. <font face="monospace, monospace">setattr </font>and the like shulud be used for when metaprogramign is called for - not for everyday data manipulation.</div><div><br></div><div>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.)</div><div><br></div><div>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.</div><div><br></div><div>Anyway -- those are my $0.02 -- from experience working with such things in the real world, with real code, and real data....</div><div><br></div><div>-Chris</div>
<div><br></div><div>-- <br></div></div><div class="gmail_signature"><br>Christopher Barker, Ph.D.<br>Oceanographer<br><br>Emergency Response Division<br>NOAA/NOS/OR&R (206) 526-6959 voice<br>7600 Sand Point Way NE (206) 526-6329 fax<br>Seattle, WA 98115 (206) 526-6317 main reception<br><br><a href="mailto:Chris.Barker@noaa.gov" target="_blank">Chris.Barker@noaa.gov</a></div>
</div></div>