31–40 of 99 posts
It's a nice idea, but i never like writing what amounts to a DSL in strings in my code (yes, that applies to in-code SQL as well, although that's often unavoidable). I prefer the `get_in()` method from Toolz: http://toolz.readthedocs.io/en/latest/api.html#toolz.dicttoo...
It's a nice idea, but i never like writing what amounts to a DSL in strings in my code (yes, that applies to in-code SQL as well, although that's often unavoidable). I prefer the `get_in()` method from Toolz: http://toolz.readthedocs.io/en/latest/api.html#toolz.dicttoo...
I feel the same way, although my instinct is generally to build a custom generator. Only costs a couple lines but is plain old python and quite explicit target = {'system': {'planets': [{'name': 'earth', 'moons': 1}, {'name': 'jupiter', 'moons': 69}]}} glom(target, {'moon_count': ('system.planets', ['moons'], sum)}) # vs def iter_moons(t): for planet in target['system']['planets']: yield planet['moons'] sum(iter_moon…
> "as simple and powerful as glom"
> "big things come in small packages"
> "small API with big functionality"
> "power is only surpassed by its intuitiveness"
> "simplicity is only surpassed by its utility"
> "shortest-named feature may be its most powerful"
For heaven's sake, give it a rest!
It's a big red flag about your priorities that when I go looking for a precise specification, I can't find answers to simple questions and instead end up wading through incessant marketing phrases. I tried, and I finally gave up halfway through the API doc. It might even be the case that glom is a good idea—but you're making it really hard to trust you as a source of objective information about it.
Show, don't tell. My advice to you: you'll generate more interest if you delete every congratulatory word on those pages and focus entirely on helping your readers understand what glom does instead of trying to sell it to them.
I can't say how they compare, but they have some overlapping features.
Does anyone know if something similar exists in Java/Scala land?
The writing style is just insufferable. Even the API documentation is littered with hyperbole and self-congratulation. We get it, you're proud of your work and extremely proud of yourself. > "as simple and powerful as glom" > "big things come in small packages" > "small API with big functionality" > "power is only surpassed by its intuitiveness" > "simplicity is only surpassed by its utility" > "shortest-named featur…
How I wish one could publish a dry document and expect people to read all the way to the bottom. I've published enough libraries to know that's not the case. glom's free software so it's all there, as "shown" as can be.
But referring you to the code wouldn't be very considerate either. Instead, here's this literate code version that I prepared in advance. Hopefully this will be of more help to you: http://glom.readthedocs.io/en/latest/faq.html#how-does-glom-...
Earlier quoted context omitted.
I feel the same way, although my instinct is generally to build a custom generator. Only costs a couple lines but is plain old python and quite explicit target = {'system': {'planets': [{'name': 'earth', 'moons': 1}, {'name': 'jupiter', 'moons': 69}]}} glom(target, {'moon_count': ('system.planets', ['moons'], sum)}) # vs def iter_moons(t): for planet in target['system']['planets']: yield planet['moons'] sum(iter_moon…
That's a great example! Mind if I use it? ;)
>>> sum([x['moons'] for x in target['system']['planets']])
It's a nice idea, but i never like writing what amounts to a DSL in strings in my code (yes, that applies to in-code SQL as well, although that's often unavoidable). I prefer the `get_in()` method from Toolz: http://toolz.readthedocs.io/en/latest/api.html#toolz.dicttoo...
I feel the same way, although my instinct is generally to build a custom generator. Only costs a couple lines but is plain old python and quite explicit target = {'system': {'planets': [{'name': 'earth', 'moons': 1}, {'name': 'jupiter', 'moons': 69}]}} glom(target, {'moon_count': ('system.planets', ['moons'], sum)}) # vs def iter_moons(t): for planet in target['system']['planets']: yield planet['moons'] sum(iter_moon…
sum(planet['moons'] for planet in target['system']['planets'])It's a nice idea, but i never like writing what amounts to a DSL in strings in my code (yes, that applies to in-code SQL as well, although that's often unavoidable). I prefer the `get_in()` method from Toolz: http://toolz.readthedocs.io/en/latest/api.html#toolz.dicttoo...
In addition to the string based lookup, it looks like there is an attempt at a pythonic approach:
from glom import T
spec = T['system']['planets'][-1].values()
glom(target, spec)
# ['jupiter', 69]
Here's what I would love to see:
from glom import nested
nested(target)['system']['planets'][-1].values()
nested(target).system.planets[-1].values()
--- edit: Ignore the above idea. I thought about this a bit more and the issue that your T object solves is that in my version:
nested(target)['system']
The T object is a good solution for this.