71–80 of 124 posts
Earlier quoted context omitted.
So then what are you supposed to deserialize nested data structures like JSON into? Dictionaries are the obvious "right" way, Python's annoying tooling aside.
Namedtuples or classes that represent the data, I'd suggest personally.
How is this different from addict? https://github.com/mewwts/addict
It works similarity to addict, but does have important distinctions and IMO seniority (was in my 'reusables' pypi project named 'Namespace' before addict existed. Just finally spun it into it's own project).
Biggest differences:
* Box will convert items added to the object after creation, addict does not
* addict only acts as a defaultdict, Box can act as either regular or a recursive defaultdict
* Box updates it’s __dir__ so that attributes (keys) are tab completed in stuff like IPython
* Box has a lot of other features, such as being able to auto convert with spaces to attributes, freezing the box, and built in JSON / YAML handling.
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, 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.
Earlier quoted context omitted.
Nope. It's called developer ergonomics.
No, it's called being terrible at your job. If you need to add complexity to your project just to save you some typing, you have no concept of what you're doing. It's like an accountant not understanding math.
I think this library has it's uses. I wouldn't use it uncritically but I wouldn't dismiss it either.
I've worked on codebases that use a similar thing, and I have yet to see one where this wasn't a mistake. Most of the time, this probably gives you exactly what you want, but then there are times where you discover bugs in production because data you assumed is your custom class is a plain old dict, and now you're raising AttributeError all over the place. Another wart is if you are unfortunate enough to have keys th…
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…
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.
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…
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 read somewhere that if it is written in self-documenting code, the problem and its solution will be obvious.