5 ms·

Well, that isn't really fair: there are lots of people out there that would appreciate this layer of abstraction over a general approach... I wouldn't hire them

by fixxer 10y ago

Well, that isn't really fair: there are lots of people out there that would appreciate this layer of abstraction over a general approach... I wouldn't hire them to be software engineers or data sci, but they exist.

OJFord 10y ago
I've discussed wishing this existed before (without having seen this library) - I would love it to be in Python as essentially the same thing is present in other language's standard libraries, but no, I would never depend on a third-party library for this. There are occasions when it's a much nicer idea than the `re` hoops we need to jump through instead though; I wonder if PEP498 f-strings [0] mightn't be laying the groundwork for this to exist. In Python 3.6 it will be possible to do: knights_say = 'Ni!' dialogue = f""" ARTHUR: Knights of Ni, we are but simple travelers who seek the enchanter who lives beyond these woods. HEAD KNIGHT: {knights_say} """ Perhaps future Python will enable `parse`-like: dialogue = """ ARTHUR: Knights of Ni, we are but simple travelers who seek the enchanter who lives beyond these woods. HEAD KNIGHT: Ni! """ dialogue.<some_future_method>(f'KNIGHT: {knights_say}') print(f'Knights have been known to say {knights_say!r}.') # "Knights have been known to say 'Ni!'." is printed Or perhaps I'm dreaming. [0]: https://www.python.org/dev/peps/pep-0498/#abstract https://www.python.org/dev/peps/pep-0498/#abstract
- abecedarius 10y ago
  ES6's template strings can do something similar: https://github.com/erights/quasiParserGenerator https://github.com/erights/quasiParserGenerator I was disappointed when Python added its f-strings instead.
  - OJFord 10y ago
    > I was disappointed when > Python added its > f-strings instead. What's the difference, other than syntax? (I've only a basic familiarity with JS.)
    - abecedarius 10y ago
      In ES6 (and earlier, in E) you can write variable_name`string with ${expression} in it`, where the value of variable_name must be a function. The function gets called with an array of the substrings between the ${expression} parts, plus the values of the expressions. The function can return anything, including a non-string value. (So e.g. you might define dom so that dom`<p>Hello world` returns a new DOM node.) If you write just `string with ${e}` then there's a default for the variable_name part which does simple interpolation, like Python's f-strings. So it's a powerful way of embedding other languages in the host language, where f-strings are not. The quasiParserGenerator library I linked to shows some of the potential.
- carapace 10y ago
  Those f-strings are awful: "embed expressions inside string literals"!? What kind of a maniac does that!?
  - OJFord 10y ago
    My initial reaction was similar, though slightly tempered. However, at least for me, once you try to think about what it is that you're actually objecting to, there's nothing left when it's a language-feature and supported by your tooling. With that support, why's it worse than `'{}'.format(expr)`?
    - carapace 10y ago
      > "when it's a language-feature and supported by your tooling" But those are two different things, and the former drives the latter, of necessity. We (humans, the core devs, draw your circle, it wasn't God nor aliens) chose to add this BS to the standard language. Now, everyone who wants to make tools that work with python have to be written to deal with this additional syntax-within-a-syntax. How does it look in the grammar? Pretty? Your linters, your type analyzers, your documentation tools, and whatever else, all have to be (re)written to deal with this. For what? What is the huge pain point with putting your expressions in the call to format() or even in the "logic" code? Mixing source code and string literals is just stupid. It's one more example of how Python 3 is drawing the stupid away from Python 2. As a 2 syntax partisan, I'm sad to see 3 degenerate, but at least 2 is still off the "innovators'" radar.
      - OJFord 10y ago
        > those are two different things, and the former drives > the latter, of necessity Absolutely, I wasn't suggesting they were the same - I joined them with 'and'. > tools that work with python have to be written to deal > with this additional syntax-within-a-syntax That's the point though, it's not "syntax-within-a-syntax", any more than is, say, a `lambda` - it's just "the [new] syntax".
        10y ago

by fixxer 10y ago

OJFord 10y ago

I've discussed wishing this existed before (without having seen this library) - I would love it to be in Python as essentially the same thing is present in other language's standard libraries, but no, I would never depend on a third-party library for this. There are occasions when it's a much nicer idea than the `re` hoops we need to jump through instead though; I wonder if PEP498 f-strings [0] mightn't be laying the groundwork for this to exist. In Python 3.6 it will be possible to do: knights_say = 'Ni!' dialogue = f""" ARTHUR: Knights of Ni, we are but simple travelers who seek the enchanter who lives beyond these woods. HEAD KNIGHT: {knights_say} """ Perhaps future Python will enable `parse`-like: dialogue = """ ARTHUR: Knights of Ni, we are but simple travelers who seek the enchanter who lives beyond these woods. HEAD KNIGHT: Ni! """ dialogue.<some_future_method>(f'KNIGHT: {knights_say}') print(f'Knights have been known to say {knights_say!r}.') # "Knights have been known to say 'Ni!'." is printed Or perhaps I'm dreaming. [0]: https://www.python.org/dev/peps/pep-0498/#abstract https://www.python.org/dev/peps/pep-0498/#abstract

abecedarius 10y ago
ES6's template strings can do something similar: https://github.com/erights/quasiParserGenerator https://github.com/erights/quasiParserGenerator I was disappointed when Python added its f-strings instead.
- OJFord 10y ago
  > I was disappointed when > Python added its > f-strings instead. What's the difference, other than syntax? (I've only a basic familiarity with JS.)
  - abecedarius 10y ago
    In ES6 (and earlier, in E) you can write variable_name`string with ${expression} in it`, where the value of variable_name must be a function. The function gets called with an array of the substrings between the ${expression} parts, plus the values of the expressions. The function can return anything, including a non-string value. (So e.g. you might define dom so that dom`<p>Hello world` returns a new DOM node.) If you write just `string with ${e}` then there's a default for the variable_name part which does simple interpolation, like Python's f-strings. So it's a powerful way of embedding other languages in the host language, where f-strings are not. The quasiParserGenerator library I linked to shows some of the potential.
carapace 10y ago
Those f-strings are awful: "embed expressions inside string literals"!? What kind of a maniac does that!?
- OJFord 10y ago
  My initial reaction was similar, though slightly tempered. However, at least for me, once you try to think about what it is that you're actually objecting to, there's nothing left when it's a language-feature and supported by your tooling. With that support, why's it worse than `'{}'.format(expr)`?
  - carapace 10y ago
    > "when it's a language-feature and supported by your tooling" But those are two different things, and the former drives the latter, of necessity. We (humans, the core devs, draw your circle, it wasn't God nor aliens) chose to add this BS to the standard language. Now, everyone who wants to make tools that work with python have to be written to deal with this additional syntax-within-a-syntax. How does it look in the grammar? Pretty? Your linters, your type analyzers, your documentation tools, and whatever else, all have to be (re)written to deal with this. For what? What is the huge pain point with putting your expressions in the call to format() or even in the "logic" code? Mixing source code and string literals is just stupid. It's one more example of how Python 3 is drawing the stupid away from Python 2. As a 2 syntax partisan, I'm sad to see 3 degenerate, but at least 2 is still off the "innovators'" radar.
    - OJFord 10y ago
      > those are two different things, and the former drives > the latter, of necessity Absolutely, I wasn't suggesting they were the same - I joined them with 'and'. > tools that work with python have to be written to deal > with this additional syntax-within-a-syntax That's the point though, it's not "syntax-within-a-syntax", any more than is, say, a `lambda` - it's just "the [new] syntax".
      - 10y ago