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

61–70 of 124 posts

Re: Box: Python dictionaries with recursive dot notation access

#61

Post by omginternets »

thesmallestcat wrote: post #7

A single class that: * De/serializes JSON and YAML * De/mangles, de/encodes keys * Provides automatic, expensive hashcode * Blacklists/transforms a bunch of likely keys because they conflict with reserved words * Overlays attrs (__box_heritage) * All in pretty complex code that obfuscates what you're really doing (especially to a maintainer) For the ability to avoid importing json/PyYAML and use clear key lookups? Th…

>It's the sort of library that you discover your inherited codebase is using, and just say, "fuckfuckfuck...", because it implies that the author cares more about pushing round pegs into square holes than writing the freaking application code

Ugh, this really hits home.

I just started a new day-job where I'm essentially being asked to un-fuck a python codebase. Your statement neatly captures my feelings when I discovered the presence of hacked-together singleton classes littered throughout the thing.

Good luck unit-testing that...

Re: Box: Python dictionaries with recursive dot notation access

#62

Post by zimablue »

safek wrote: post #55

I never understood why Python differentiates between key access and attribute access. Dig down one layer, and they're the same thing anyway: a.b is just a.__dict__['b']. For all its faults, JavaScript has some pretty sensible defaults. Accessing a missing key returns what is basically its equivalent of nil. Extra parameters to function calls are simply ignored. Unsupplied parameters default to nil.

I can think of a couple of reasons: safety, attr access by . means you knew what you wanted at write-time, so it's reasonable to assume that you're gonna want to know if it doesn't exist, and not just want to roll the dice on passing a null along. language concision, it seems counterintuitive but attrs vs items gives you two options for one class: . access and [] access, which it's very reasonable give different results, so your default mode of writing classes has a "I think this should be here/nondynamic" mode of access and a 'wonder if this is here'/dynamic mode of access. I think that there are benefits to that. If you don't eventually do some dynamic attribute access I think you throw away an advantage of dynamic languages, but it's nice to me that there's this by default soft line between less and more dynamic code

Re: Box: Python dictionaries with recursive dot notation access

#63

Post by omginternets »

johnwheeler wrote: post #41
felipellrocha wrote: post #34

Earlier quoted context omitted.

Saving chars is often a poor reason to design a language feature.

Nope. It's called developer ergonomics.

Developer ergonomics does not (always) mean "preventing effort".

If that were true, there would be no type systems.

Re: Box: Python dictionaries with recursive dot notation access

#64

Post by chris_griffith »

tjpaudio wrote: post #2

How is the performance on this for very large dictionaries vs. standard python dictionary lookups?

Just finished my article that includes speed comparisons. http://www.codecalamity.com/python-box-3-the-reddit-release/...

Basically it's faster on standard soft creation as it converts on lookup. (And most use cases don't call for referencing every single key)

Re: Box: Python dictionaries with recursive dot notation access

#65

Post by nas »

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…

If you use something like this, future maintainers are going to hate you.

Re: Box: Python dictionaries with recursive dot notation access

#66

Post by chris_griffith »

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…

Author here: I totally agree with the fact it has shortcomings and definitely isn't aimed to replace everyone's dict everywhere.

I actually created the first iteration of this around 3 years ago, aimed primarily for sysadmins and others who use the console more than actual developing. As I find it extremely convenient to tab complete keys and a lot less typing.

From there it has obviously evolved to try and fit more peoples needs, and I use it regularly in my projects.

Re: Box: Python dictionaries with recursive dot notation access

#67

Post by strunz »

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…

Yep. Last time I tried one of these I had a dict that had keys that conflicted with the dictionary keywords, like "items" or "keys" or "values", so I wound up functions back instead of data.

Re: Box: Python dictionaries with recursive dot notation access

#68

Post by chris_griffith »

ericfrederich wrote: post #52

I got excited by the heading thinking that there was a change to the language and we could refer to the dictionary itself in dictionary comprehension. Just yesterday I commented that if generators could refer to themselves in generator comprehension (recursion) I could express some algorithm as a single expression. http://stackoverflow.com/a/41617394/180464 ... anyway, this just turns out to be what looks like an "ad…

Something like that would be handy. Just to clarify the addict mention.

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 defaultdict

* Box updates it’s __dir__ so that attributes (keys) are tab completed in stuff like IPython

* Box repr clearly shows it is an object

Re: Box: Python dictionaries with recursive dot notation access

#69

Post by makecheck »

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…

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.

Re: Box: Python dictionaries with recursive dot notation access

#70

Post by keeganpoppen »

deathanatos wrote: post #32

This feels a lot like Bunch, and a lot of private reimplementations I've seen elsewhere. I dislike these structures. Yes, Python lets you pull this trick. Everything, yes, can be represented as a dict, a list, or one of the primitive str/int/etc. types. But I find it's a lot clearer in the long run (and even in the short run), if you have a collection of heterogenous attributes, to define a class for them. Leave dict…

thanks for the rec on attrs-- cool stuff!
Post reply on HN