Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Box: Python dictionaries with recursive dot notation access

github.com

Post reply on HN
Print view View original

111–120 of 124 posts

Re: Box: Python dictionaries with recursive dot notation access

#111

Post by deathanatos »

lesingerouge wrote: post #77
jerf wrote: post #58

I think every Python programmer implements this at some point. I think the real reason not to do this is one that as of this writing still hasn't been mentioned yet, which is that when using dot notation, your key names have to fit the Python grammar for identifiers, so you can't have a key "the thing" with a space, or anything else that isn't a Python identifier. So you can't just say "I can access this dictionary w…

Also dot means attribute means less speed.

That's a huge micro-optimization. For a trivial example of a class having the attributes "a", "b" and "c", and a dict of the same,

    In [4]: %timeit d['b']  # dict
    10000000 loops, best of 3: 42.7 ns per loop

    In [6]: %timeit f.b  # class using __slots__
    The slowest run took 30.10 times longer than the fastest. This could mean that an intermediate result is being cached.
    10000000 loops, best of 3: 44 ns per loop

    In [9]: %timeit b.b  # class using __dict__
    10000000 loops, best of 3: 48.1 ns per loop
You're talking <6ns per access; except in the very exceptional case where you know you need this, in Python of all languages, it's an over optimization. The maintainability of having the stupid-simple class vastly outweighs the speed.

Re: Box: Python dictionaries with recursive dot notation access

#112

Post by aidos »

user5994461 wrote: post #85
aidos wrote: post #74

Earlier quoted context omitted.

Agreed. This is not the sort of code you want to be dealing with in a few years time. Also, I seldom find that string based dicts are what I need. One of the best things about Python is being able to use virtually anything as a key.

> One of the best things about Python is being able to use virtually anything as a key. I find that to be the thing one of the worst thing ever made into a programming language. You are facing a program/API/library and you can have absolutely no clue of what it will give or expect without extensive reverse engineering.

Wait, you choose what to put in the dict. I like being able to map from, say, db objects to internal representations. Why wouldn't you want that?!

Re: Box: Python dictionaries with recursive dot notation access

#113

Post by mythrwy »

an_hn_reader wrote: post #19

I like using NamedTuple for dot notation access, it's a good middle ground between dicts and custom classes. Pandas must use something similar under the hood to provide dot notation access to columns. I wish h5py did the same for hdf5 objects. In py3, I find myself needing to type list(X.items()) and then list(X['Y'].items()) and so on when I'm exploring a new dataset... fairly awkward for interactive use.

Thumbs up for namedtuple. It is a good middle ground.

Re: Box: Python dictionaries with recursive dot notation access

#114

Post by nerdponx »

smoe wrote: post #93
cjhanks wrote: post #86

Earlier quoted context omitted.

There are quite a few nay-votes here, so I'll give a yay vote. In the past I have had to deal with very complex configuration systems; several thousands of lines of XML which were supposed to direct many applications. And writing: value['this']['that']['the_other'] vs value.this.that.the_other Really starts to matter for code legibility. Of course if you change your XML configs your Python will break - but it would l…

I see the value in the latter for code legibility. My gripe with it is, when I'm new to a project that uses a dict implementation like that: how do I know what happens if for example `that` is missing? Does it raise AttributeError, KeyError or just return None? Personally I'd prefer a helper functions like deep_get(dict_, dotted_path[, default]) -> value You stil have to check the docs/source what exactly happens, bu…

You can use `get` from the `toolz` package:

    toolz.get(value, ['this', 'that', 'the_other']
There's also a Cython implementation called `cytoolz`.

Re: Box: Python dictionaries with recursive dot notation access

#115

Post by yeukhon »

crdoconnor wrote: post #35
yeukhon wrote: post #21

Earlier quoted context omitted.

Because it saves me a lot of chars. foo['name']['attr1']['attr2']['morefuckingattr'] vs foo.name.atr1.attr2.morefuckingattr More of a personal preference.

True, but it saves a relatively small number of chars (~12) and does so at the same time as: A) Giving off a signal that you're dealing with an object rather than a dict. B) Making it cumbersome to swap out some of those selectors with variables. C) Making it difficult to deal with the attribute not being there (with a dict you can say .get("attr2", {}) and it returns a default.

I understand. I have another motivation which is getting JSON and wanting a OOP object to mainpluate with. Take AWS' boto3 response. Well documented but the nested response structure gives me a chill and I wish there's a direct object out of the JSON. I instead had to write my own class for the conversion. If I could mainpluate dict like mainpluatig attribute in a class then I could just write my function's contract "input is a response object from X APi" instead of "dict of this form."

Quite annoying and I know some people considered what I wish is a bad practice.

Re: Box: Python dictionaries with recursive dot notation access

#116

Post by [deleted] »

crdoconnor wrote: post #35
yeukhon wrote: post #21

Earlier quoted context omitted.

Because it saves me a lot of chars. foo['name']['attr1']['attr2']['morefuckingattr'] vs foo.name.atr1.attr2.morefuckingattr More of a personal preference.

True, but it saves a relatively small number of chars (~12) and does so at the same time as: A) Giving off a signal that you're dealing with an object rather than a dict. B) Making it cumbersome to swap out some of those selectors with variables. C) Making it difficult to deal with the attribute not being there (with a dict you can say .get("attr2", {}) and it returns a default.

[deleted]

Re: Box: Python dictionaries with recursive dot notation access

#117

Post by dllthomas »

aidos wrote: post #112
user5994461 wrote: post #85

Earlier quoted context omitted.

> One of the best things about Python is being able to use virtually anything as a key. I find that to be the thing one of the worst thing ever made into a programming language. You are facing a program/API/library and you can have absolutely no clue of what it will give or expect without extensive reverse engineering.

Wait, you choose what to put in the dict. I like being able to map from, say, db objects to internal representations. Why wouldn't you want that?!

The concern is facing something that expects a map, and not knowing how to correctly populate it.

Re: Box: Python dictionaries with recursive dot notation access

#118

Post by xapata »

Retra wrote: post #109
xapata wrote: post #100

Earlier quoted context omitted.

Was that sarcasm? What counts as "self-documenting"?

Undocumented code is self-documenting. Because it only ever does exactly what is written, it must be intended to do exactly what it does.

Ah, Dr. Pangloss.

Re: Box: Python dictionaries with recursive dot notation access

#119

Post by [deleted] »

deathanatos wrote: post #111
lesingerouge wrote: post #77

Earlier quoted context omitted.

Also dot means attribute means less speed.

That's a huge micro-optimization. For a trivial example of a class having the attributes "a", "b" and "c", and a dict of the same, In [4]: %timeit d['b'] # dict 10000000 loops, best of 3: 42.7 ns per loop In [6]: %timeit f.b # class using __slots__ The slowest run took 30.10 times longer than the fastest. This could mean that an intermediate result is being cached. 10000000 loops, best of 3: 44 ns per loop In [9]: %t…

[deleted]
Post reply on HN