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

Glom – Restructured Data for Python

sedimental.org

Post reply on HN
Print view View original

71–80 of 99 posts

Re: Glom – Restructured Data for Python

#71

Post by Too »

jeremiahwv wrote: post #40
nerdponx wrote: post #22

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 agree, I don't like the magic string approach (even if it is mostly just dot-notation attribute lookup). However, there is some good stuff here, and nested data lookup when value existence is unknown is a pain point for me. 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', 6…

I prefer your nested() version. I don't see why your final example would be ambiguous either, if it always returns a defaulting dict which you always have to extract with .values() there is no ambiguity. This is similar to how Javas Optional work. The problem could be that the type checker isn't good enough and writing code like if nested(target)['system'] == "lazer" could pass the type checker.

Re: Glom – Restructured Data for Python

#72

Post by genidoi »

mlevental wrote: post #69
genidoi wrote: post #68

Earlier quoted context omitted.

if the condescending tone of the top comment is ignored it becomes valuable feedback. good libraries/api's (free or otherwise) do not need to use marketing buzzwords to sell themselves when a clear demonstration of the functionality is usually more than enough. see the python requests library documentation for a good example http://docs.python-requests.org/en/master/

>if the condescending tone of the top comment is ignored it becomes valuable feedback. good libraries/api's (free or otherwise) do not need to use marketing buzzwords to sell themselves when a clear demonstration of the functionality is usually more than enough. this fallacy is called affirming the consequent. yes good libraries might not need marketing but that does not say anything about whether good libraries can…

its anyone's best guess whether apis/libraries with documentation that have buzzword-y marketing get more usage than those that entirely market themselves based on functionality.

Re: Glom – Restructured Data for Python

#73

Post by emidln »

jeremiahwv wrote: post #40
nerdponx wrote: post #22

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 agree, I don't like the magic string approach (even if it is mostly just dot-notation attribute lookup). However, there is some good stuff here, and nested data lookup when value existence is unknown is a pain point for me. 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', 6…

Objects are overkill. Use an iterable of getitem lookups. They compose easily and don’t have much overhead (cpu or cognitive). From the library I use at work, inspired by clojure.core/get-in, it would look like this:

    def get_in(obj, lookup, default=None):
        """ Walk obj via __getitem__ for each lookup,
        returning the final value of the lookup or     default.
        """
        tmp = obj
        for l in lookup:
            try:
                tmp = tmp[l]
            except (KeyError, IndexError, TypeError):
                return default
        return tmp


    data = {“foo”: {“bar”: [“spam”, “eggs”]}}
    # find eggs
    get_in(data, [“foo”, “bar”, 1])
By using __getitem__ you naturally work with anything in the python ecosystem.

Re: Glom – Restructured Data for Python

#74

Post by some_account »

mhashemi wrote: post #36
zestyping wrote: post #33

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…

Hey Ka-Ping! Maybe I did get carried away :) 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 wi…

Looks like a nice package. I will try it in my next project. The upcoming features sounded interesting. Keep up the good work!

Re: Glom – Restructured Data for Python

#75

Post by mhashemi »

genidoi wrote: post #68
mlevental wrote: post #53

Earlier quoted context omitted.

you know what's actually insufferable? taking pot shots at someone giving you something for free. either say thank you or move on. it's like yelling at your mom for making you breakfast in the morning: downright unseemly.

if the condescending tone of the top comment is ignored it becomes valuable feedback. good libraries/api's (free or otherwise) do not need to use marketing buzzwords to sell themselves when a clear demonstration of the functionality is usually more than enough. see the python requests library documentation for a good example http://docs.python-requests.org/en/master/

Did you seriously just recommend Requests, a project which uses "Non-GMO", "organic", and "grass-fed" to describe itself on the very page you linked, as a good example of not using buzzwords?

Come on. kreitz holds the title of Python marketspeak tycoon for a reason. :P

Re: Glom – Restructured Data for Python

#76

Post by Corristowolf »

Can anyone explain the benefit of glom instead of pandas dataframes? For data manipulation pandas is superior in everyway to any library out there. The only thing i think glom would be useful is json parsing as was shown. Sorry if I sound a bit too harsh. I'm looking at it from a data science pov.

Re: Glom – Restructured Data for Python

#77

Post by poooogles »

mhashemi wrote: post #75
genidoi wrote: post #68

Earlier quoted context omitted.

if the condescending tone of the top comment is ignored it becomes valuable feedback. good libraries/api's (free or otherwise) do not need to use marketing buzzwords to sell themselves when a clear demonstration of the functionality is usually more than enough. see the python requests library documentation for a good example http://docs.python-requests.org/en/master/

Did you seriously just recommend Requests, a project which uses "Non-GMO", "organic", and "grass-fed" to describe itself on the very page you linked, as a good example of not using buzzwords? Come on. kreitz holds the title of Python marketspeak tycoon for a reason. :P

You forgot the line that's the biggest offender of all, "... for Humans".

Re: Glom – Restructured Data for Python

#78

Post by elbear »

genidoi wrote: post #72
mlevental wrote: post #69

Earlier quoted context omitted.

>if the condescending tone of the top comment is ignored it becomes valuable feedback. good libraries/api's (free or otherwise) do not need to use marketing buzzwords to sell themselves when a clear demonstration of the functionality is usually more than enough. this fallacy is called affirming the consequent. yes good libraries might not need marketing but that does not say anything about whether good libraries can…

its anyone's best guess whether apis/libraries with documentation that have buzzword-y marketing get more usage than those that entirely market themselves based on functionality.

Think of buzzwords as familiar faces for the readers. Sure, you can overdo it and make a buzzword soup, but a few buzzword can give the reader a quick idea of the product.

Re: Glom – Restructured Data for Python

#80

Post by brylie »

mhashemi wrote: post #36
zestyping wrote: post #33

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…

Hey Ka-Ping! Maybe I did get carried away :) 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 wi…

My only concern is that the documentation renders poorly on mobile. So I couldn't read the right half of the page.
Post reply on HN