[Python-ideas] Briefer string format

[Nick Coghlan]

On 20 July 2015 at 15:18, Andrew Barnert <abarnert at yahoo.com> wrote:
> On Jul 19, 2015, at 21:58, Nick Coghlan <ncoghlan at gmail.com> wrote:
>>
>>> On 20 July 2015 at 14:46, Steve Dower <Steve.Dower at microsoft.com> wrote:
>>> So, macros basically? The real ones, not #define.
>>>
>>> What's wrong with special casing text strings (a little bit more than they
>>> already have been)?
>>
>> I've wished for a cleaner shell command invocation syntax many more
>> times than I've wished for easier string formatting, but I *have*
>> wished for both. Talking to the scientific Python folks, they've often
>> wished for a cleaner syntax to create deferred expressions with the
>> full power of Python's statement level syntax.
>>
>> Explicitly named macros could deliver all three of those, without the
>> downsides of implicit globally installed macros that are
>> indistinguishable from regular syntax.
>
> MacroPy already gives you macros that are explicitly imported, and explicitly marked on use, and nicely readable. And it already works, with no changes to Python, and it includes a ton of little features that you'd never want to add to core Python.

I see nothing explicit about https://pypi.python.org/pypi/MacroPy or
the examples at https://github.com/lihaoyi/macropy#macropy, as it
looks just like normal Python code to me, with no indication that
compile time modifications are taking place.

That's not MacroPy's fault - it *can't* readily be explicit the way I
would want it to be if it's going to reuse the existing AST compiler
to do the heavy lifting.

However, I agree the MacroPy approach to tree transformations could be
a good backend concept. I'd previously wondered how you'd go about
embedding third party syntax like shell expressions or format strings,
but eventually realised that combining an AST transformation syntax
with string quoting works just fine there.

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia