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

61–70 of 99 posts

Re: Glom – Restructured Data for Python

#61

Post by skosch »

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…

Thank you for glom, and don't let those comments get you down.

Personally speaking – my heuristic is that maintainers who put effort into marketing copy (even if it's awkwardly exaggerated) are the kind of people who really want their users to enjoy the project, and that often predicts a low-friction experience. Keep doing what you're doing!

Re: Glom – Restructured Data for Python

#62

Post by agf »

It seems to me like the advantage to focus on here is the improved error / `None` handling, which will speed debugging and make handling expected edge cases easier. I've seen a lot of inexperienced developers tripped up entirely by this kind of data access, and seen plenty of experienced developers waste time debugging it because of the exact error cases the announcement references.

The `T` object, which the article describes as its most powerful, can be a useful pattern in some situations, but it's worth pointing out it isn't new or unique to this project.

The author says in another thread here that he first started working on the "stuff leading up to glom" in 2013. One older example, which is virtually identical though less complete, is this Stack Overflow answer I posted in 2012: https://stackoverflow.com/a/9920723/500584

I'd seen the general pattern even before that post, if not the Pythonic syntax. I don't think that it's much of an improvement over defining a `lambda`, so again I would say the thing to focus on is the improved debugability and the simpler, dot-notation-as-generic-attribute-or-item-accessor syntax. I think `T` is largely a distraction, or should be reserved for advanced users.

Re: Glom – Restructured Data for Python

#64

Post by jkaptur »

typon wrote: post #31
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...

Why is writing DSLs strictly worse than writing complicated transformations built on top of the limited constructs provided by the language itself? (You said never )

They’re pretty comparable when the strings are constants. The fun begins when the string is dynamically created.

Re: Glom – Restructured Data for Python

#65

Post by mhashemi »

jkaptur wrote: post #64
typon wrote: post #31

Earlier quoted context omitted.

Why is writing DSLs strictly worse than writing complicated transformations built on top of the limited constructs provided by the language itself? (You said never )

They’re pretty comparable when the strings are constants. The fun begins when the string is dynamically created.

I wouldn't recommend dynamically generating strings. Strings are just a shorthand for Path objects, use Path instead: http://glom.readthedocs.io/en/latest/api.html#specifier-type...

Re: Glom – Restructured Data for Python

#66

Post by derefr »

My favourite approach to this so far, that I would like other libraries to copy, is Elixir’s Access protocol, which gives you e.g.:

    foo = %{key: [[1, 2], [3, 4], [5, 6]]}

    path = [:key, Access.all, Access.at(0)]

    get_in foo, path
    # => [1, 3, 5]

    update_in foo, path, &(&1 * 10)
    # => %{key: [[10, 2], [30, 4], [50, 6]]}

    foo
    |> put_in([:key, Access.all], “foo”)
    |> put_in([:new_key], “bar”)
    # => %{key: [“foo”, “foo”, “foo”], new_key: “bar”}
That third form is essentially the equivalent of building up a complex object through a series of mutations—but entirely functional.

Re: Glom – Restructured Data for Python

#67

Post by cscotti »

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…

Dude, this looks really nice! I use nested stuff like that all the time - nested layers of flat data ;) - and glom (+T) do seem super appropriate and nice!

Re: Glom – Restructured Data for Python

#68

Post by genidoi »

mlevental wrote: post #53
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…

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/

Re: Glom – Restructured Data for Python

#69

Post by mlevental »

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/

>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 have marketing.

Re: Glom – Restructured Data for Python

#70

Post by jkaptur »

mhashemi wrote: post #65
jkaptur wrote: post #64

Earlier quoted context omitted.

They’re pretty comparable when the strings are constants. The fun begins when the string is dynamically created.

I wouldn't recommend dynamically generating strings. Strings are just a shorthand for Path objects, use Path instead: http://glom.readthedocs.io/en/latest/api.html#specifier-type...

I definitely wouldn't recommend it either. Sorry not to be clear.

In my experience, it's almost impossible to dissuade people from generating strings if the API affords it. We can't even stop people from generating SQL by concatenation!

Musing: does Python have a way (Mypy?) to declare that a method can accept only constant expressions?

Post reply on HN