91–100 of 124 posts
Cute, though the use of x to prepend to integer keys is potentially confusing with the convention of x as a hexadecimal indicator.
In my experience, this always seems like a cool idea until you use it with keys that an end-user can define. Then you get to watch your code blow up when they override some other function you've defined on the class.
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…
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…
Personally I'd prefer a helper functions like
deep_get(dict_, dotted_path[, default]) -> value
EDIT: To clarify a bit. An experienced Python developer should immediately recognize a call like `deep_get(value,'this.that.the_other')` as something project/framework specific and not built-in, while `value.this.that.the_other` is ambiguous.
How is that different from easydict? - https://pypi.python.org/pypi/easydict/
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…
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…
How is this different from addict? https://github.com/mewwts/addict
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…
NT = collections.namedtuple('NT', ['x', 'y'])
nt1 = NT(1, 2)
nt2 = NT(nt1, 'asdf')
assert nt2.x.y == 2
get_two = operator.attrgetter('x.y')
assert get_two(nt2) == 2
If you wrap the operator.attrgetter in a try/catch, you can force a default too: https://pastebin.com/bFxGr22E
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…
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…
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.
Earlier quoted context omitted.
Yep. Or keys with dots in their names, or keys actually named something like "__eq__" (strange but not impossible). The worst thing about abstractions is when they break. I can always figure out how to fix or extend ugly but straightforward code. I may not even know where the manual is when a fancy wrapper dumps a trace.
>I may not even know where the manual is when a fancy wrapper dumps a trace. I read somewhere that if it is written in self-documenting code, the problem and its solution will be obvious.
What counts as "self-documenting"?