[Python-ideas] Briefer string format

[Andrew Barnert]

On Jul 19, 2015, at 22:43, Nick Coghlan <ncoghlan at gmail.com> wrote:
> 
>> 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.

I suppose what I meant by explicit is things like using [] instead of () for macro calls and quick lambda definitions, s[""] for string interpolation, etc. Once you get used to it, it's usually obvious at a glance where code is using MacroPy.

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

I think you want to be able to hook the tokenizer here as well. If you want f"..." of !f"...", that's hard to do at the tree level or the text level; you'd have to do something like f("...") or "f..." instead. But at the token level, it should be trivial. (Well, the second one may not be _quite_ trivial, because I believe there are some cases where you get a !f error instead of a ! error and an f name; I'd have to check.) I'm pretty sure I could turn my user literal suffix hack into an f-prefix hack in 15 minutes or so. (Obviously it would be nicer if it were doable in a more robust way, and using a framework rather than rewriting all the boilerplate. But my point is that, even without any support at all, it's still not that hard.)

I think you could also use token transformations to do a lot of useful shell-type expressions without quoting, although not full shell syntax; you'd have to play around with the limitations to see if they're worth the benefit of not needing to quote the whole thing.

But as I said before, the real test would be trying to build the framework mentioned parenthetically above and see where it gets annoying and what could change between 3.5 and 3.6 to unannoyingize the code.