On Sat, Sep 5, 2015 at 2:10 AM, haypo s <victor.stin...@gmail.com> wrote:
> 2015-09-05 5:01 GMT+02:00 Guido van Rossum <gu...@python.org>:
> > And I'm ready to accept it. I'll wait until Tuesday night (Monday's a
> > holiday in the US) in case anything unforeseen comes up, but this is
> really
> > the Last Call for this PEP.
>
> Would it be possible to specify a subset of the Python language
> allowed in f-string? For example, __import__ or lambda should not be
> used in a f-string. I'm not convinced that a loop or
> list/dict/set-comprehension is a good idea neither.
>
We already went over this. You might as well argue that __import__ or
lambda should not be used as arguments to print(). It's an expression, and
it must allow exactly everything that is allowed in other places where
expressions are allowed.
Of course you don't *have* to write those things in f-string
interpolations. But that's just a style guide; the language should not try
to second-guess the user.
> I would prefer to keep as much code as possible *outside* f-string because:
> - text editor knows well how to color it
> - static analyzers know how to analyze it
> - it encourage developers to indent and comment their code correctly,
> whereas f-string has more restrictons on indentation
Really, we already went over most of this. You can put whitespace (even
newlines) exactly where they are allowed in other expressions, as long as
they don't terminate the string. You probably shouldn't do any of those
things regularly, but there are lots of other things you that you can do in
Python that you shouldn't.
>
> (is it possible to indent and comment code inside a f-string?)
>
Now that's an interesting question. I think the answer must be No, because
we don't want to deal with ambiguities like whether a closing curly bracket
or string quote should be ignored inside such comments. The processing of
f-strings described by the PEP uses several phases:
- find the end of the string (the final quote[s]) using the same algorithm
used for all string literals
- expand \ escapes (e.g. \uXXXX)
- look for single {, then scan ahead to a matching } -- this skips matching
() [] {}
- look for optional !a,!r,!s and !<spec> inside each {...} pair
- take what's left, enclose it in (), parse as expression
The presence of comments would impede several of these stages.
> For example, for me it's a common practice to write a complex
> list-comprehension on two lines for readability:
>
> newlist = [very_complex_expression(item)
> for item in oldlist]
> # sorry, it's hard to indent correctly in a mail client, especially Gmail
>
The list comprehension across two lines without the comment would be fine
in a triple-quoted f-string (or perhaps even in a single-quoted f-string if
you put a \ before the line break).
> Well, I'm not convinced that we need a larger subset than what is
> allowed currently in str.format(), simple expressions like: obj.attr,
> obj[index], etc.
>
The PEP explains why actually.
> I recall horrible examples in the previous mail threads showing how
> much complex code you can put inside f-string.
>
Yes, that was a very poorly thought out argument. All of Python should be
condemned if you took it seriously.
> Even the following example from the PEP seems too complex to me:
> print(f"Usage: {sys.argv[0]} [{'|'.join('--'+opt for opt in
> valid_opts)}]", file=sys.stderr)
>
> Oh, first I read [...] as a list-comprehension :-p But it's part of
> the output string, not of the Python code...
>
> I prefer to build the second parameter outside the f-string:
> opts = '|'.join('--'+opt for opt in valid_opts)
> print(f"Usage: {sys.argv[0]} [{opts}]", file=sys.stderr)
>
The same criticism can be made for the original version (using .format()),
which was lifted from real code.
> f-string with complex code remembers me PHP where it was possible to
> mix PHP and HTML. I have bad memories such... code? template? (I don't
> know how to cal them). Text editors and me were unable to identify
> quickly the beginning and end of the code. We have a similar issue
> with Python unit test embedding Python code to run subprocesses. My
> text editor vim is unable to identify if the current code is the
> outter code or the code embedded in a long triple-quoted string
> (especially when you open the file at the embedded code).
>
Yeah, tools will need to be updated. There are several other languages
(e.g. Ruby) that allow arbitrary expressions in strings and at least some
editors have no problem with them, even vim.
> Maybe we should start with a simple f-string, play with it during one
> cycle (Python 3.6), and then discuss again if it's necessary to extend
> the allowed Python expresions inside f-string?
>
> If you really want to allow *any* Python inside a f-string, can you
> please at least explain in the PEP why you consider that it's a good
> thing?
>
Sigh. We've gone over this on python-ideas. Your objection is not new.
> IMHO the main advantage of allowing expressions inside f-string is
> that it adds something really new compared to the current str.format()
> method. Without it, f-string are less interesting.
>
--
--Guido van Rossum (python.org/~guido)
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
