Re: [Python-ideas] Draft PEP on string interpolation
On 24 August 2015 at 23:04, Mike Miller <python-dev@mgmiller.net> wrote:
Well, can you use an example that isn't misleading in its security implications? Specifically, I assumed from your use of os.system that you were proposing that the stdlib function (specifically in this case, a function that we've been trying to deprecate in favour of more secure alternatives for years) be updated to understand e-strings.
Remember Nick Coghlan's statement that the "easy way should be the right way"? That's what this is trying to accomplish.
But the right way is not to use os.system, so I don't *want* it to be easy. If you have a better example than running shell commands, please explain. (If your example is running full-blown shell syntax, rather than single commands, please give a more complicated example and we can let the debate explode into one about portability of shell constructs - but os.system to run a single command with a set of arguments is *wrong* and subprocess.Popen was created to replace it with a cross-platform, secure by default, solution).
Then I'm strongly against this. As I've stated on a number of occasions, to me the crucial main use of any variation on this proposal is print(f"Iteration {n}: Duration {end-start}") If your e-string proposal works for this (via some consequence of implicitly calling str()) then it may still be on the cards - but the need for explicit str() calls in pathlib is a source of frustration there, so I'd like to be 100% sure that your proposal doesn't result in a need for explicit str() calls anywhere before accepting that e-strings can replace f-strings. By the way, the terminology in this thread (e-strings, f-strings, i-strings...) is dreadful. We need names that capture the essential differences (I've already proposed "format strings" for f-strings). Naming is important! Paul
On 08/25/2015 01:29 AM, Paul Moore wrote:
Ok, a few hours before someone complained to Nick that he was using subprocess.call as an example when it didn't completely apply. So I moved to the other alternative example that could be helped, os.system. I have no particular love for it, and am not recommending it. It was just one function out of many that needs input to be escaped as far as I was concerned. I didn't forsee that that the function would be focused on to the point of the derailing the idea. I suppose I'll try again if you'll bear with me.
In my original message (of this sub-thread) this is one of the main paragraphs:
Also if you check the example script at the bitbucket url, you'll see it is the case, though I've not yet implemented every case. -Mike
First of all, please accept my apologies for anything that's already been explained that I've missed. This thread is huge and confusing, and honestly I don't have the time to do much more than skim it. I'm certainly commenting without doing all the research - I'm trying to avoid gross errors, but how well I succeed I can't say. On 25 August 2015 at 19:02, Mike Miller <python-ideas@mgmiller.net> wrote:
I understand your point about "one function of many". Ignoring its flaws for a moment, I understand that os.system is an easily understood one of the many. What I'm not clear about is whether under your proposal, os.system would need to be *changed* to accept e-strings, or whether it would work as it stands. Having just read through your PEP, I'm not sure I'm any the wiser. I think what you're saying is that x = 12 foo(e'number = {x}') will be translated *at compile time* to x = 12 foo(''.join(['number = ', str(x)])) But that seems to leave no way for anything to "safely quote" x. And there's no obvious way foo can influence the quoting if it *doesn't* need rewriting to know about e-strings. So you seem to be saying that e-strings will only be "safely quoted" if the function using them knows to do so. Which leads back to the question of how a user can *know* that an e-string will be safe or not when used with a particular function. That's not making the right way easy, it's giving function writers a new way to make the right thing easy - but only if they target Python versions with e-strings only, or they offer two options, one for e-strings and one for old-style strings. That's likely to make it *harder* for the end user to chose the safe option. I'm sure I'm missing something fundamental in the above, because that's so far away from offering the benefits you're suggesting. But I can't work out what.
I didn't forsee that that the function would be focused on to the point of the derailing the idea. I suppose I'll try again if you'll bear with me.
Sorry. Maybe a better idea would be to show how someone would need to write a safe os.system. If you're saying "you can just use os.system unchanged from the current version", then see above - I don't understand how.
Please explain "renders itself". What "rendering" is done when it's passed as an argument to a function (e.g. os.system)? Put this another way, what is type(e'foo {x}')? If it's not str, then at least some code (notably os.system in your example, as it wants "safe quoting") using e-strings will need to know about them. If it *is* str, then I'm baffled, as above.
Also if you check the example script at the bitbucket url, you'll see it is the case, though I've not yet implemented every case.
Sorry, I couldn't work out what bitbucket URL you meant. If you meant your PEP, there's a lot of code samples in there, but I'm not clear which bit you mean :-( Paul
On 08/25/2015 01:29 AM, Paul Moore wrote:
Agreed, I have said the same in the context of the written PEPs, however in informal conversation, I think f,i, and e, are convenient short-hand for the various ideas. In my PEP draft you'll see no mention of -strings. -Mike
On 08/25/2015 01:29 AM, Paul Moore wrote:
Ok, a few hours before someone complained to Nick that he was using subprocess.call as an example when it didn't completely apply. So I moved to the other alternative example that could be helped, os.system. I have no particular love for it, and am not recommending it. It was just one function out of many that needs input to be escaped as far as I was concerned. I didn't forsee that that the function would be focused on to the point of the derailing the idea. I suppose I'll try again if you'll bear with me.
In my original message (of this sub-thread) this is one of the main paragraphs:
Also if you check the example script at the bitbucket url, you'll see it is the case, though I've not yet implemented every case. -Mike
First of all, please accept my apologies for anything that's already been explained that I've missed. This thread is huge and confusing, and honestly I don't have the time to do much more than skim it. I'm certainly commenting without doing all the research - I'm trying to avoid gross errors, but how well I succeed I can't say. On 25 August 2015 at 19:02, Mike Miller <python-ideas@mgmiller.net> wrote:
I understand your point about "one function of many". Ignoring its flaws for a moment, I understand that os.system is an easily understood one of the many. What I'm not clear about is whether under your proposal, os.system would need to be *changed* to accept e-strings, or whether it would work as it stands. Having just read through your PEP, I'm not sure I'm any the wiser. I think what you're saying is that x = 12 foo(e'number = {x}') will be translated *at compile time* to x = 12 foo(''.join(['number = ', str(x)])) But that seems to leave no way for anything to "safely quote" x. And there's no obvious way foo can influence the quoting if it *doesn't* need rewriting to know about e-strings. So you seem to be saying that e-strings will only be "safely quoted" if the function using them knows to do so. Which leads back to the question of how a user can *know* that an e-string will be safe or not when used with a particular function. That's not making the right way easy, it's giving function writers a new way to make the right thing easy - but only if they target Python versions with e-strings only, or they offer two options, one for e-strings and one for old-style strings. That's likely to make it *harder* for the end user to chose the safe option. I'm sure I'm missing something fundamental in the above, because that's so far away from offering the benefits you're suggesting. But I can't work out what.
I didn't forsee that that the function would be focused on to the point of the derailing the idea. I suppose I'll try again if you'll bear with me.
Sorry. Maybe a better idea would be to show how someone would need to write a safe os.system. If you're saying "you can just use os.system unchanged from the current version", then see above - I don't understand how.
Please explain "renders itself". What "rendering" is done when it's passed as an argument to a function (e.g. os.system)? Put this another way, what is type(e'foo {x}')? If it's not str, then at least some code (notably os.system in your example, as it wants "safe quoting") using e-strings will need to know about them. If it *is* str, then I'm baffled, as above.
Also if you check the example script at the bitbucket url, you'll see it is the case, though I've not yet implemented every case.
Sorry, I couldn't work out what bitbucket URL you meant. If you meant your PEP, there's a lot of code samples in there, but I'm not clear which bit you mean :-( Paul
On 08/25/2015 01:29 AM, Paul Moore wrote:
Agreed, I have said the same in the context of the written PEPs, however in informal conversation, I think f,i, and e, are convenient short-hand for the various ideas. In my PEP draft you'll see no mention of -strings. -Mike
participants (2)
-
Mike Miller -
Paul Moore