Re:Glom – Restructured Data for Python
by typon on Wednesday May 09, 2018 @05:20PM
(#17034195)
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)
[ Parent
| on HN ]
Re:Glom – Restructured Data for Python
by joshuamorton on Wednesday May 09, 2018 @09:05PM
(#17035705)
The issue isn't dsls, it's string dsls. Doing it within the language can provide stronger garauntees.
As a simple example, you get some syntax checking.
Precisely. Until my autocomplete, syntax highlighting, and linting engines recognize it, I'll pass.
I think y'all might be getting a bit up in arms about a non-issue. Seasoned glommers (and experienced Pythonists), will almost always be using T: http://glom.readthedocs.io/en/latest/api.html#object-oriente...
While mentioned in the post, it's not front-and-center because that's the sort of Python superpower that can look scary to less-experienced devs.
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?