Python Extension Proposal 498: Literal String Formatting(python.org)
python.org
Python Extension Proposal 498: Literal String Formatting
https://www.python.org/dev/peps/pep-0498/
23 comments
> I am against it, because it allows arbitrary Python expressions inside format strings.
As well it should. Programming language features should be orthogonal as much as possible.
> It's too complicated and lets user have two different ways of doing things (not Pythonic) - one to calculate expression inside string and the other to calculate it outside (which should IMHO be preferred).
You must hate expression nesting, then. Look at all these ways of doing the same thing:
I feel dirty just for having written that.
As well it should. Programming language features should be orthogonal as much as possible.
> It's too complicated and lets user have two different ways of doing things (not Pythonic) - one to calculate expression inside string and the other to calculate it outside (which should IMHO be preferred).
You must hate expression nesting, then. Look at all these ways of doing the same thing:
x = a + b * (c - d)
e = c - d
x = a + b * e
f = b * (c - d)
x = a + f
e = c - d
f = b * e
x = a + f
I feel dirty just for having written that.
This is a straw man. If you want to evaluate expressions inside a long string, you can as easily write:
"The sum of a and b is " + (a+b) + "!"
This is completely analogous to your examples. The only disadvantage of this method is the extra quotes, but that's just syntax. You could think that having the literal string split is a disadvantage, but it really isn't - since in the proposal the string has to be literal anyway, so in either case it cannot be a variable.
In general, in what I would consider good language design (syntactic-wise), you either interpret expressions by default and then quote string literals (like most languages do), or you interpret literals by default and then quote expressions (this is the method regular expressions language, or templating languages, use). But you shouldn't do both, it's just a can of worms, especially for code highlighting tools (although in a language with Lisp-like design philosophy - which Python is not - why not, you can do it today with reader macros and whatnot).
"The sum of a and b is " + (a+b) + "!"
This is completely analogous to your examples. The only disadvantage of this method is the extra quotes, but that's just syntax. You could think that having the literal string split is a disadvantage, but it really isn't - since in the proposal the string has to be literal anyway, so in either case it cannot be a variable.
In general, in what I would consider good language design (syntactic-wise), you either interpret expressions by default and then quote string literals (like most languages do), or you interpret literals by default and then quote expressions (this is the method regular expressions language, or templating languages, use). But you shouldn't do both, it's just a can of worms, especially for code highlighting tools (although in a language with Lisp-like design philosophy - which Python is not - why not, you can do it today with reader macros and whatnot).
I'm curious if you've ever spent a lot of time using a language that has a solution similar to the proposal, for instance Ruby, or the newer JavaScript versions. All of the theoretical stuff about good syntax design and code highlighting cans of worms rings incredibly hollow to me in the face of how fundamentally nicer this sort of syntax is. It's the first thing I forget Python doesn't have after not using it for awhile, which I then go looking for, and once again find myself surprised at its absence. I also find the "un-Pythonic to have more than one way to do it" argument interesting, as there seem to be three approaches to string formatting in idiomatic use in Python (`.format`, `%`, and string concatenation), whereas in Ruby, the direct interpolation approach is used nearly exclusively.
You do lose type-checking capabilities by giving up format specifiers (which, for instance, Rust checks at compile-time), but Python can't take much advantage of that to begin with.
You do lose type-checking capabilities by giving up format specifiers (which, for instance, Rust checks at compile-time), but Python can't take much advantage of that to begin with.
For all the (little) work I have done with JS I used the same technique of string concatenation, and I don't really see an issue with writing "+ instead of { (respectively +" instead of }).
Ruby has a different philosophy than Python, was originally intended to be Perl replacement, and is more open to cryptic shortcuts like this.
While in Python, the presumably better format() syntax was a step to actually longer code, character-wise, than old C-style % interpolation. Python simply tries to be more explicit, because it is used in more domains than just text processing; similar arguments can be raised against Python's treatment of regular expressions.
Ruby has a different philosophy than Python, was originally intended to be Perl replacement, and is more open to cryptic shortcuts like this.
While in Python, the presumably better format() syntax was a step to actually longer code, character-wise, than old C-style % interpolation. Python simply tries to be more explicit, because it is used in more domains than just text processing; similar arguments can be raised against Python's treatment of regular expressions.
Ah, well, I guess all I can really say then is that it seems like you're knocking it before you've tried it. It's not any more or less cryptic or explicit than the alternatives, it's just a different, and quite convenient, way of expressing the same thing.
I agree. Regardless of the technical merits it's a much nicer experience with languages like Ruby. I like the idea of keeping cognitive overhead at a minimum by reducing the number of methods to accomplish something but at the end of the day practicality should win.
You're pushing it too far. Having one logical step per line is better for readability, clarity, and debugging-friendliness.
> Programming language features should be orthogonal as much as possible.
True, and that's why string building and string formatting should be two things.
By the way, I am not sure about how would this PEP should handle something like
> Programming language features should be orthogonal as much as possible.
True, and that's why string building and string formatting should be two things.
By the way, I am not sure about how would this PEP should handle something like
a = 'A1'
b = f'{a}'
a = 'A2'
s = f'{a}' + b
A2A1 would be my expectation, according to code equivalnce rules from the PEP.
as to your question, it shouldn't be. it's just syntax sugar.
as to your question, it shouldn't be. it's just syntax sugar.
> I am against it, because it allows arbitrary Python expressions inside format strings.
I was for this PEP until your post made this reality apparent. I'll take security over convenience.
I was for this PEP until your post made this reality apparent. I'll take security over convenience.
I will go further and say that I will even take readability over convenience.
This is a step in the reverse direction. Please don't do this. I am not sure why this is even considered. We already have ways to do this clearly. Let us not add another way to do this in a less readable way that is a lot more easier to write. That is a deadly combination.
Features in python are geared towards more readable code (I know about the stuff you can do with things like comprehensions, but hey I think their power justifies them enough). This will lead to people using this format due to initial convenience, but ends up regretting doing so.
Please remember that code is read more often than it is written. So a requiring a little verbosity if that can enhance readability even a little bit, is good. I hope these kinds of good things about python does not get removed.
I am coming from 9 years of experience with PHP. And I will say that this is not worth it. And this is actually one of the features I have come to like in Python now.
And that is not considering the implications of having expression evaluation inside strings...
This is a step in the reverse direction. Please don't do this. I am not sure why this is even considered. We already have ways to do this clearly. Let us not add another way to do this in a less readable way that is a lot more easier to write. That is a deadly combination.
Features in python are geared towards more readable code (I know about the stuff you can do with things like comprehensions, but hey I think their power justifies them enough). This will lead to people using this format due to initial convenience, but ends up regretting doing so.
Please remember that code is read more often than it is written. So a requiring a little verbosity if that can enhance readability even a little bit, is good. I hope these kinds of good things about python does not get removed.
I am coming from 9 years of experience with PHP. And I will say that this is not worth it. And this is actually one of the features I have come to like in Python now.
And that is not considering the implications of having expression evaluation inside strings...
Also coming from a php background, I'll 100% agree with this. I always cringe when I see strings formatted like this for pretty much the same reasons. It makes it painful to figure out what the hell a string is actually going to look like when you have a bunch of code embedded inside it
I actually think the proposal would be more readable because you don't have to think about what it means. Compare:
"{} of very long text here...".format(value)
f"{value} of very long text here..."
"{} of very long text here...".format(value)
f"{value} of very long text here..."
This is a simple example that does seem more readable (though it also would be if you explicitly added the value=value), but I think the concerns people have are about more complex examples, and the fact that readability is also impacted if allowing arbitrary code within strings themselves.
If you don't like using the empty {} (which seems fair enough), you can already use a couple of slightly more verbose but more explicit options:
If you don't like using the empty {} (which seems fair enough), you can already use a couple of slightly more verbose but more explicit options:
"{value} of very long text here...".format(**locals)
"{value} of very long text here...".format(value=value)
.format(locals()) is a hack; locals() isn't supported on some python implementations.
The documentation at https://docs.python.org/3/library/functions.html#locals doesn't indicate that locals is not part of the language - where is it documented that using it is a hack and that python implementations need not support it?
It is on PyPy and CPython. Which ones don't? And when they don't support it, how do they behave? Return an empty dict or give an error?
I thinks this is where our difference in comes from.
When we are reading code, we are not usually reading the strings contained within.
We are reading variables names, we are looking at where they are used, where they are assigned, stuff like that.
I very rarely look inside the strings when we are actually reading code. When reading code, strings are just black boxes where nothing can happen. So we can completely ignore them.
With this pep, that will change. And readability takes a big hit. Strings are no longer black boxes.
And actually you can get the " {value} if very long text" format right now using the format function, but it right now requires an explicit list/dictionary of variables.
This explicit list of variables really helps in the context of reading code. And forcing users to write down that explicit list of variables to use, is good.
When we are reading code, we are not usually reading the strings contained within.
We are reading variables names, we are looking at where they are used, where they are assigned, stuff like that.
I very rarely look inside the strings when we are actually reading code. When reading code, strings are just black boxes where nothing can happen. So we can completely ignore them.
With this pep, that will change. And readability takes a big hit. Strings are no longer black boxes.
And actually you can get the " {value} if very long text" format right now using the format function, but it right now requires an explicit list/dictionary of variables.
This explicit list of variables really helps in the context of reading code. And forcing users to write down that explicit list of variables to use, is good.
How do you know where the string ends? If your editor has syntax coloring and you look for the end of the string-color block, then the expressions inside the string will also have a different color and will pop right out. If you don't use syntax coloring you have to scan for " or ', and you'll learn to scan for { too.
>How do you know where the string ends?
I usually just go to the end of the line. or if that is not possible, I think I usually look at the next closest thing that obviously is not a string and scan backwards.
I mean, usually I didn't have to do anything consciously (or do a scan) to spot the end of a string.
I usually just go to the end of the line. or if that is not possible, I think I usually look at the next closest thing that obviously is not a string and scan backwards.
I mean, usually I didn't have to do anything consciously (or do a scan) to spot the end of a string.
When I'm reading code, I'm always reading string literals contained within it. Strings that aren't integral to the code should be external resources, and I'm not even convinced it's possible to black-box them at a below-conscious level; you can selectively actively ignore them, but that takes additional effort that is only generally a net win in particularly poorly structured code.)
Point taken!
You can have something like this today if you really want to :):
def f(s):
import sys
return s.format(**sys._getframe(1).f_locals)
a = 1
b = 2
f("{a} + {b}")imakesnowflakes made a good point below.
Also compare the readability of this:
"very long text {value} another long text".\ format(value=value)
vs.
f"very long text {value} another long text"
^ now you have to go and visually search through the whole string to see what is being used in there
Also compare the readability of this:
"very long text {value} another long text".\ format(value=value)
vs.
f"very long text {value} another long text"
^ now you have to go and visually search through the whole string to see what is being used in there
This isn't a bad point, but anecdotally, after using interpolated strings for many years, I've never come across this problem a single time.
Syntax highlighting will make the variables used in the string pop out. This is easier than scanning to the end of the line to find the format() call.
I don't think this is actually a security concern. The only place f-strings are evaluated is where they're directly included in the source; they can't be supplied by a user (unless you're using "eval," in which case the security concern applies with or without f-strings). As the PEP says:
"Because the f-strings are evaluated where the string appears in the source code, there is no additional expressiveness available with f-strings. There are also no additional security concerns: you could have also just written the same expression, not inside of an f-string."
"Because the f-strings are evaluated where the string appears in the source code, there is no additional expressiveness available with f-strings. There are also no additional security concerns: you could have also just written the same expression, not inside of an f-string."
Should have read the PEP in full. Thanks : )
This proposal doesn't affect security in any way. It's just syntactic sugar.
Instead of writing this:
Edit: Fixed small errors in the examples.
Instead of writing this:
'My name is ' + format(name) + ' my age next year is ' + format(age+1)
'My name is {name}, my age next year is {age}'.format(name=name, age=age+1)
f'My name is {name}, my age next year is {age=1}'
Edit: Fixed small errors in the examples.
First of all, I don't think you can do {age+1} in a string right now.
But you can use string placeholders when used with format function. That should take take of this use case. So no need to add another syntactic sugar to make it more convenient.
It is already as simple as possible. Let us not try to simplify it further.
I will be horrified and very worried about the direction that the language has taken if this pep gets accepted.
But you can use string placeholders when used with format function. That should take take of this use case. So no need to add another syntactic sugar to make it more convenient.
It is already as simple as possible. Let us not try to simplify it further.
I will be horrified and very worried about the direction that the language has taken if this pep gets accepted.
This perspective is so interesting to me. You say the version using `.format` is "as simple as possible", but the interpolated version seems clearly simpler to me, because it eliminates the redundancy in the placeholders. What's the disconnect here?
> but the interpolated version seems clearly simpler to me. What's the disconnect here?
The disconnect is this. An explicit list of variables to use for interpolation is not redundancy. Because the placeholders does not, by themselves, refer to anything. Placeholders are just holes and only have a meaning in the context of formatting functions. And even in them, they does not refer to a local variables, even when they share a common name. So when you use .format() function, you are actually saying, "here is a string with some named holes. Fill the hole named 'A' with the value from variable 'A', the hole named 'B' with the value from variable 'B'.
So hole 'A' and variable 'A' are different things even if they share the same name.
Now, the simplicity argument.
Every thing should be made as simple as possible. But not simpler. Why not? Because when you simplify further, you are paying a cost (often not apparent initially), some times in clarity, sometimes in correctness and so on. The pigeonhole principle.
In our case, we can further simplify the process by adding an implicit mapping from named placeholders to local variables. When you do so, you are adding something implicit. The costs of which might not be apparent at this point..
So this pep is strapping on something to the whole language, to slightly simplify this one use case. Which is why I said that it is trying to simplify it further than it is possible.
The disconnect is this. An explicit list of variables to use for interpolation is not redundancy. Because the placeholders does not, by themselves, refer to anything. Placeholders are just holes and only have a meaning in the context of formatting functions. And even in them, they does not refer to a local variables, even when they share a common name. So when you use .format() function, you are actually saying, "here is a string with some named holes. Fill the hole named 'A' with the value from variable 'A', the hole named 'B' with the value from variable 'B'.
So hole 'A' and variable 'A' are different things even if they share the same name.
Now, the simplicity argument.
Every thing should be made as simple as possible. But not simpler. Why not? Because when you simplify further, you are paying a cost (often not apparent initially), some times in clarity, sometimes in correctness and so on. The pigeonhole principle.
In our case, we can further simplify the process by adding an implicit mapping from named placeholders to local variables. When you do so, you are adding something implicit. The costs of which might not be apparent at this point..
So this pep is strapping on something to the whole language, to slightly simplify this one use case. Which is why I said that it is trying to simplify it further than it is possible.
edit: Deleted my response because this is a bikeshed. You prefer placeholders, I prefer interpolations, it's totally subjective and there's little point debating it!
You're right, you can't do {age+1} in a string right now. I just edited to fix it.
Note that these format strings must exist in the source code -- you can't read them from the user then execute it.
I'd submit the security concern is more that specifying a string interpolation format without first-class thought about how to encode interpolated strings is a terrible idea in 2015, and people need to really stop doing this. See http://www.jerf.org/iri/post/2942 and the example library I use to demonstrate the point, https://github.com/thejerf/strinterp .
Of course all current methods of string interpolation in Python have that problem too.
And typing that sentence really, really makes we want to link http://xkcd.com/927/ . I'm unconvinced adding a fourth choice at this very late date can fix anything.
Of course all current methods of string interpolation in Python have that problem too.
And typing that sentence really, really makes we want to link http://xkcd.com/927/ . I'm unconvinced adding a fourth choice at this very late date can fix anything.
disagree. it only allows Python expressions in the same context in which they are already allowed: in the code. it's not possible to create an f-string at runtime.
Security was not my primary concern, but even if the design can be made secure, it is still a concern (because bugs happen). In any case, you just stated another counter argument - it breaks orthogonality of the language (string being interpolated must be a literal), just to make one assignment not explicit.
Maybe it is popular in other languages - their call, but the fact is, it goes quite wildly against Python design philosophy.
I would also like to note that the are templating systems that let you evaluate arbitrary Python expressions. Perhaps these would be a better choice for users who feel need for this proposal.
Maybe it is popular in other languages - their call, but the fact is, it goes quite wildly against Python design philosophy.
I would also like to note that the are templating systems that let you evaluate arbitrary Python expressions. Perhaps these would be a better choice for users who feel need for this proposal.
i agree that there are multiple templating solutions, but i disagree that they fill the same niche. this is a language usability (UX even) thing, not a purity thing. the fact is people do '...'.format(locals()) for the same purpose (or '...' % locals()), which is strictly worse and may not even work on some python implementations. i also disagree that this feature goes against the zen of python: practicality beats purity, after all.
It's an industry std now, can't put it in a lib without extra syntax.
There should be one-- and preferably only one --obvious way to do it.
It would also render the previous ways obsolete. New-style formatting never took over completely from old-style because it wasn’t sufficiently compelling—`"%s %s" % (a, b)` versus `"{} {}".format(a, b)` doesn’t have a clear winner. But `f"{a} {b}"`? Clearly superior. With the exception of backwards compatibility matters (which will be a nuisance for far too long), there would really be no reason to keep using the old ways in most places. i18n/l10n would really be the only mainstream reason for using anything other than f-strings.
"It would also render the previous ways obsolete."
I don't think it would. If I understand this PEP correctly, the "format" method is significantly more dynamic. For instance, I don't think this new PEP would allow for cases where the template isn't stored directly in the program, or where the values to interpolate are not local variables. So you would still need to keep str.format around for those use cases.
I don't think it would. If I understand this PEP correctly, the "format" method is significantly more dynamic. For instance, I don't think this new PEP would allow for cases where the template isn't stored directly in the program, or where the values to interpolate are not local variables. So you would still need to keep str.format around for those use cases.
Your example isn't very compelling, but for longer strings with more complex formatting, I'd say .format() is pretty compelling. I find that in general
On top of that, there's a whole bunch of stuff you can do with .format() that just isn't possible with %.
'{x} blah blah blah {y}'.format(x=x, y=y)
'%s blah blah blah %s' % (x, y)
On top of that, there's a whole bunch of stuff you can do with .format() that just isn't possible with %.
Even .format() is quite redundant for the "standard" usage, as we had string interpolation using '%' with dicts for a long time.
'%s blah blah blah %s' % (x, y)
'{x} blah blah blah {y}'.format(x=x, y=y)
'%(x)s blah blah blah %(y)s'%{'y':y, 'x':x}Which clearly implies that the first three were insufficiently obvious. Or insufficiently Dutch.
Although practicality beats purity.it'd be the first one that's safe* in runtime.
*obligatory "not really, but in most cases" disclaimer
*obligatory "not really, but in most cases" disclaimer
I would be very happy to see some version of this accepted.
When it comes to native String interpolation Groovy has it, Scala has it, ES6 has it apparently; to a more limited extent Bash, PHP, Perl have it too of course.
I can't help feeling that other devs are now coming to Python expecting this kind of feature, and are disappointed to find three (harder, often less readable) ways to do it instead. Got to keep up with the Joneses, etc...
When it comes to native String interpolation Groovy has it, Scala has it, ES6 has it apparently; to a more limited extent Bash, PHP, Perl have it too of course.
I can't help feeling that other devs are now coming to Python expecting this kind of feature, and are disappointed to find three (harder, often less readable) ways to do it instead. Got to keep up with the Joneses, etc...
It doesn't mean this is a good feature to have - it allows objects within scope to now be directly included in a string, which isn't a secure thing to do.
Nonononono. Python does not need more string literal specifiers. For a language that avoid symbols and sigils like the plague, it already has an absurd amount of string literal syntax.
Why not make a strfmt library on pypi that provides a single fmt(s, args, kwargs) function and let people call that? Why the obsession with more builtins?
Why not make a strfmt library on pypi that provides a single fmt(s, args, kwargs) function and let people call that? Why the obsession with more builtins?
The first thing I thought of when I looked at the PEP was, "this is like a string version of register_globals=on".
A string literal whose value automatically changes with the code surrounding it sounds like a really bad idea.
I also noticed that the PEP uses str.format method as a strawman, ignoring the fact that % string interpolation is very popular and does not need replacing, which is at the core of this problem in the first place; Someone keeps trying to replace something that does not need replacing.
Furthermore, I can't help but think that this would eventually become a complete literal string DSL (if not one already) inside of Python.
I hope this PEP does not get accepted.
A string literal whose value automatically changes with the code surrounding it sounds like a really bad idea.
I also noticed that the PEP uses str.format method as a strawman, ignoring the fact that % string interpolation is very popular and does not need replacing, which is at the core of this problem in the first place; Someone keeps trying to replace something that does not need replacing.
Furthermore, I can't help but think that this would eventually become a complete literal string DSL (if not one already) inside of Python.
I hope this PEP does not get accepted.
> The first thing I thought of when I looked at the PEP was, "this is like a string version of register_globals=on", which is an unsettling thought to have about Python, my favorite language.
> The idea of having a string that is automatically dynamic and whose value is hardly predictable upon first glance, wholly dependent on the stability of the code surrounding it, sounds like an absolutely horrendous idea.
What?! It's not a dynamic string. It's a string concatenation expression with syntactic sugar.
This isn't PHP's register_globals. It's PHP's "{$n + 1}".
What this does, you can already do. "Foo " + bar + " baz" already exists. This is merely nicer syntax.
> The idea of having a string that is automatically dynamic and whose value is hardly predictable upon first glance, wholly dependent on the stability of the code surrounding it, sounds like an absolutely horrendous idea.
What?! It's not a dynamic string. It's a string concatenation expression with syntactic sugar.
This isn't PHP's register_globals. It's PHP's "{$n + 1}".
What this does, you can already do. "Foo " + bar + " baz" already exists. This is merely nicer syntax.
The difference is,
> "Foo " + bar + " baz"
is not a string literal, neither is one using format or % function. All of those things return dead strings. This pep is about creating a kind of 'live' string literal, which python does not have right now (or need IMHO). So this is not merely a nicer syntax.
> "Foo " + bar + " baz"
is not a string literal, neither is one using format or % function. All of those things return dead strings. This pep is about creating a kind of 'live' string literal, which python does not have right now (or need IMHO). So this is not merely a nicer syntax.
It is not live (unless I am mis-understanding what you mean by live) - it is evaluated once. That is to say:
def magic(a, b):
return f"{a} and {b}"
s = magic(4, 8)
print(s)
a, b = 3, 7
print(s)
It is live in the sense that you can take that string literal and put it in a different context and it will result in a different evaluation, possibly yielding different value for the string and possibly different side effects (after calls to evaluate expressions).
This is a massive improvement. I currently use .format(), sometimes with locals(), but f-strings would improve this massively.
Now if only they didn't require Python 3, so I could use them on the production systems I'm working on...
Now if only they didn't require Python 3, so I could use them on the production systems I'm working on...
I switch back and forth between format and %, and never use locals in the format. It's annoying, every time a string is written, to try to decide which way is better for this instance.
That said, is there a way to do ('%.3f' % x) with this?
f'{x:.3f}'
I am having some problems trying to understand the implementation. What would the AST from evaluating "f'{a+1}'" look like? Will there be a special AST node for f-strings, or will it be pre-structured into the AST?
If it's a special node, is it the responsibility of the byte code generator to parse the string? My belief is that it's part of the parser's job, so the AST will never contain an f-string.
What does a syntax error report look like? Or traceback? Will it be able to narrow down the part of the string which causes a problem?
Can f-strings include f-strings, like:
Support for arbitrary expressions inside of an f-string means that the following is allowed,
I am less happy accepting that a magic string can turn a function into a generator. Take for example this code from around line 438 of https://searchcode.com/codesearch/view/18830026/ :
EDIT: the PEP says that the expression are "parsed with the equivalent of ast.parse(expression, '<fstring>', 'eval')". That means that 'yield' is not allowed.
If it's a special node, is it the responsibility of the byte code generator to parse the string? My belief is that it's part of the parser's job, so the AST will never contain an f-string.
What does a syntax error report look like? Or traceback? Will it be able to narrow down the part of the string which causes a problem?
Can f-strings include f-strings, like:
f"{a + (f' and {b+1}')}"
Support for arbitrary expressions inside of an f-string means that the following is allowed,
def f(a, b):
return f"{yield a} = {b}"
print(f(1, 2))
I am less happy accepting that a magic string can turn a function into a generator. Take for example this code from around line 438 of https://searchcode.com/codesearch/view/18830026/ :
if attr=='yields' :
yield_unit = self._grab_attr_(obj,'yield_unit')
if yield_unit:
ret = '%s %s'%(ret,yield_unit) # FIXME: i18n?
return ret
ret = f'{ret} {yield_unit}' # FIXME: i18n?
ret = f'{ret} {yield unit}' # FIXME: i18n?
EDIT: the PEP says that the expression are "parsed with the equivalent of ast.parse(expression, '<fstring>', 'eval')". That means that 'yield' is not allowed.
Presumably it'd be handled similarly to how PHP handles {} and $ in strings. As soon as possible, you swap "{foo} {bar}" for (foo.__format__() + " " + bar.__format__())
It's not so simple. The full implementation has to do something like insert an AST into the right place, because {foo} can be an expression like f"{__import__('math').cos(len(s))}".
The Python tokenizer will pass an f-string to the AST builder, which has to pass the string to another tokenizer to generate the new AST. Because f-strings can contain f-strings, this process is recursive. The end result is a new AST that replaces the original f-string.
The Python tokenizer will pass an f-string to the AST builder, which has to pass the string to another tokenizer to generate the new AST. Because f-strings can contain f-strings, this process is recursive. The end result is a new AST that replaces the original f-string.
One of those things when you read it you wonder why it wasn't done that way in the first place.
Exactly when you need to apply this principle...
https://en.wikipedia.org/wiki/Wikipedia:Chesterton's_fence
>In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, “I don’t see the use of this; let us clear it away.” To which the more intelligent type of reformer will do well to answer: “If you don’t see the use of it, I certainly won’t let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it
https://en.wikipedia.org/wiki/Wikipedia:Chesterton's_fence
>In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, “I don’t see the use of this; let us clear it away.” To which the more intelligent type of reformer will do well to answer: “If you don’t see the use of it, I certainly won’t let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it
Well, now you talk about that the reform is wrong (the suggested one or the previous ones?) but I said that I agree with it. So it feels like between the post you are responding to and the Fence there are some arguments missing, right?
For those that want something close today, there's https://pypi.python.org/pypi/say
fmt("Hello, {name}! You have {len(msgs)} waiting.")
say looks nice, but it still suffers from exactly what this pep is trying to fix
>>> def test(x=1):return lambda:say.say("{x}")
>>> test()
NameError: name 'x' is not defined
I think you're right that Interpy and PEP 498 have a different, earlier binding strategy than say does. I've found the late / local binding of say() and fmt() convenient. Are there use cases where that earlier binding is valuable or critical?
Your example highlights the binding strategy, but more typical would be:
Your example highlights the binding strategy, but more typical would be:
>>> def test(x=1):
... return fmt("{x}")
...
>>> test()
'1'
>>> test(12)
'12'
>>> test('woobers')
'woobers'> * fmt("Hello, {name}! You have {len(msgs)} waiting.")*
Yikes!
Please don't tell me that's a function which peeks at the caller's lexical variables, at run time, by name?
I see "inspect.currentframe().f_back" hacks in the code, good grief.
Yikes!
Please don't tell me that's a function which peeks at the caller's lexical variables, at run time, by name?
I see "inspect.currentframe().f_back" hacks in the code, good grief.
Yes indeed. That's exactly how it works. Introspection.
Given a language that doesn't support templated strings inherently, how else would you provide that feature?
Though technically, `fmt` is not a function per se. It's an object with a `__call__` method. That doesn't improve the situation for you, does it?
Given a language that doesn't support templated strings inherently, how else would you provide that feature?
Though technically, `fmt` is not a function per se. It's an object with a `__call__` method. That doesn't improve the situation for you, does it?
There's an interesting competing PEP which allows for the way in which the expressions are interpolated into the string to be customized: https://www.python.org/dev/peps/pep-0501/
I couldn't get myself to read beyond this example
i"Substitute $names and ${expressions} at runtime"
C# 6.0 is also adding literal string formatting: http://www.codeproject.com/Articles/846566/What-s-new-in-Csh...
I hope this gets implemented. A year ago or so we had several customers wanting to custom format output filenames and directories in a desktop application and we settled for something which is almost exactly this, so the {identifier:format spec} idea, and ever since implementing it I wish any language had it as we found it really convenient and having no apparant disadvantages in comparision with printf-%-style in C or Python/streams in C++/{}-style in C#/Python
I don’t understand what you’re seeking. This is purely for string literals. If you’re taking a user input string like `"foo-{date}.{extension}"`, you could use `string.format(date=…, extension=…)`
Yes it's for literals only, just saying I like the inline style and readability and succinctness of it and wouldn't mind it being implemented in Python and other languages.
But this wouldn't solve your case because it could only be applied to strings that are in the source code. Your users don't have the ability to change those string. Instead, they want to provide a format string, which you fill in. That is already available, eg, via str.format(kwargs), where you control the kwargs and the user controls the str.
Yes, I know that as well. But this wasn't a Python application :] Maybe should have mentioned that earlier..
C# has it.
However, str.format() is not without its issues. Chief among them is its verbosity. For example, the text 'value' is repeated here:
>>> value = 4 * 20
>>> 'The value is {value}.'.format(value=value)
'The value is 80.'
>>> 'The value is {}.'.format(value)
'The value is 80.'
>>> f'The value is {value}.'
'The value is 80.'
>>> 'The value is '+value+'.'
'The value is 80.'
In regards to the title, PEP stands for "Python Enhancement Proposal", not "Python Extension Proposal"
You can even hack it into a string class if you don't mind using even more scary hacks like monkey patching built in classes.
def I(s):
import inspect
frame = inspect.currentframe()
caller_locals = frame.f_back.f_locals
return s.format(**caller_locals)
def main():
a = 12
b = 10
print I('A is {a} and B is {b}')
if __name__ == '__main__':
main()In TXR Lisp, from system prompt:
Oh, right: referencing splices and unquotes is possible from inside a quasistring:
# simple quasiliteral, denoted by backticks
$ txr -p '(let ((x "Bob")) `Hello, @{x -10}`)'
"Hello, Bob"
# word-quasiliteral (breaks into list on spaces)
# denoted by hash-backtick:
$ txr -p '#`@(+ 2 2) @(+ 1 2) a b c`'
("4" "3" "a" "b" "c")
# op-argument references in quasiliteral
# ret produces a function whose arguments depend
# on the uses of @1, @2. ... and @rest in the
# expression. The value of the expression is returned.
# These references can emanate from a quasistring:
$ txr -p "(mapcar (ret \`@1--@2--@rest\`) '(1 2 3) '(a b c) '(x y z)))"
("1--a--x" "2--b--y" "3--c--z")
# Very basic indexing, slicing and field adjustment:
$ txr -p '`foo @{(list 1 2 3) [0]} bar`'
"foo 1 bar"
$ txr -p '`foo @{(list 1 2 3) [2]} bar`'
"foo 3 bar"
$ txr -p '`foo @{(list 1 2 3) [1..:]} bar`'
"foo 2 3 bar"
$ txr -p '`foo @{(list 1 2 3) [1..:] 20} bar`'
"foo 2 3 bar"
$ txr -p '`foo @{(list 1 2 3) [1..:] -20} bar`'
"foo 2 3 bar"
Oh, right: referencing splices and unquotes is possible from inside a quasistring:
$ txr -p '(let ((a 42) (b (range 1 5)))
^(list `hey @,a @(list ,*b)`))'
(list (sys:quasi "hey "
@42 " " @(list 1 2 3 4 5)))
$ txr -p '(eval (let ((a 42) (b (range 1 5)))
^(list `hey @,a @(list ,*b)`)))'
("hey 42 1 2 3 4 5")
This looks like template strings in ES6 [1], which is really well done ! I look forward to using f-strings
[1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
[1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
This is a very handy feature of PHP and would be useful in Python. I think readability will be solved by syntax highlighting: expressions in an f-string would be highlighted like normal expressions, rather than like string content. This is what is already done for PHP.
I'm really happy to see this. I know it's petty, but this was the biggest reason I decided to focus on learning the ins and outs of Ruby instead of Python.
I understand the need for expressions-in-literal.
I really don't understand why the unnecessary extra "!rsa" modifiers are a good thing though.
I really don't understand why the unnecessary extra "!rsa" modifiers are a good thing though.
The fact they had to hack in a workaround so != works is a point against it. And they acknowledge you can use repr()/str()/ascii() directly.
They want to keep it for str.format() compatibility, but I'm unconvinced. It hurts readability, and is redundant (There should be one-- and preferably only one --obvious way to do it.)
They want to keep it for str.format() compatibility, but I'm unconvinced. It hurts readability, and is redundant (There should be one-- and preferably only one --obvious way to do it.)
I just use Tornado templates for doing this. I made a wrapper to make it a single function call. The syntax is very similar.
i like it ..a lot!
I think a better approach would be to just add special formatter operators (if they aren't already there) that would just call str() or repr() or ascii() to whatever is presented to them (and maybe take some optional arguments such as length or padding).