Eric V. Smith <e...@trueblade.com> added the comment:
Yes, my approach is to use the tokenizer to produce the parts of the f-string,
instead of treating it as a normal string and making a second pass to parse out
the pieces. I've been discussing this for a few years, and at last PyCon I
talked to many tool vendors (editors, type checkers, etc.) to gather opinions,
and no one was opposed. I've also had a few discussions since then, which were
also positive. So I think I'll try to move ahead on it.
I'm not sure this is the best place to discuss it, but let me give a little
example on why it's complicated.
Consider: f"x{y:.2f}z{a!s:10}b"
What type of token is ".2f", and how does the tokenizer recognize it? Or maybe
the token is ":.2f". It can be an arbitrary sequence of characters (with a few
restrictions, like no newlines), ending before a right brace. And there's the
issue of backslash escapes there.
And the f"{z = :20}" thing we added doesn't make this any easier, since
whitespace is significant after the "=" and before the ":", if it exists. And I
need the entire text of the expression, before it's parsed, to make it work. I
don't think that "unparsing" could ever be made to work in this case, or at
least not so as to be compatible with 3.8 and preserving whitespace.
I really haven't looked at what's involved in the implementation in any greater
depth: my first goal was (and will be) to get buy-off on the change, then to
look at implementation issues. PEP 536 has some discussion of this, but if I go
forward I would want to start from scratch (and reject PEP 536).
As far as the patch I was working on: the general problem is that you have to
"prime" the compiler with a line number and column to start on, instead of it
assuming line 1 column 1. Despite spending the better part of a week on it at
the core sprints 1.5 years ago, I never got it to work (although I did delete
and simplify a few functions, so it was a net win anyway). I wouldn't be
opposed to a patch to fix this.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue39564>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
