Movatterモバイル変換
[0]ホーム
[Python-ideas] Briefer string format
Bruce Lebanbruce at leban.us
Thu Jul 23 06:28:19 CEST 2015
On Wed, Jul 22, 2015 at 8:31 PM, Steven D'Aprano <steve at pearwood.info>wrote:>> Constant-folding 'a' + 'b' to 'ab' is an optimization, it doesn't change> the semantics of the concat. But constant-folding f'{a}' + '{b}' would> change the semantics of the concatenation, because f strings aren't> constants, they only look like them.>It doesn't have to change semantics and it shouldn't. This is a strawmanargument. While we could do it wrong, why would we? It's hardly difficultto quote the non-format string while still optimizing the concatenation.That is, f'{foo}' '{bar}' f'{oof}'could compile to the same thing as if you wrote: f'{foo}{{bar}}{oof}'the result of something like this: COMPILE_TIME_FORMAT_TRANSFORM('{foo}' + COMPILE_TIME_ESCAPE('{bar}') +'{baz'})This is analogous what happens with mixing raw and non-raw strings: r'a\b' 'm\n' r'x\y'is the same as if you wrote: 'a\\bm\nx\\y'or r'''a\bm x\y'''In the case of *implicit* concatenation, I think that the concatenations> should occur first, at compile time. Yes, that deliberately introduces a> difference between implicit and explicit concatenation, that's a> feature, not a bug!>Doing the concatenation at compile time does NOT require the "infected"behavior you describe below as noted above.> I would go further and allow all the f prefixes apart from the first to> be optional. To put it another way, the first f prefix "infects" all the> other string fragments:>> I'd call that a bug. I suppose one person's bug is another person'sfeature. It violates the principle of least surprise. When I look at a linein isolation and it starts and ends with a quote, I would not expect thatto not just be a plain string.> (Implicit concatenation is a compile-time operation, the format(...)> stuff is run-time, so there is a clear and logical order of operations.)>To you, maybe. To the average developer, I doubt it. I view the compiletime evaluation of implicit concatenation as a compiler implementationdetail as it makes essentially no difference to the semantics of theprogram. (Yes, I know that runtime concatenation *might* produce adifferent string object each time through the code but it doesn't have to.I hope you don't write programs that depend on the presence or absence ofstring pooling.)> And merging f-strings:> > f'{foo}' f'{bar'}> > similarly just becomes concatenating the results of some function calls.>> That's safe to do at compile-time:>> f'{foo}' f'{bar}'> f'{foo}{bar}'>> will always be the same. There's no need to delay the concat until after> the formats.Just as it's safe to concat strings after escaping the non-format ones.There is one additional detail. I think it should be required that eachformat string stand on its own. That is: f'x{foo' f'bar}y'should be an error and not the equivalent of f'x{foobar}y'--- BruceCheck out my new puzzle book:http://J.mp/ingToConclusions<http://j.mp/ingToConclusions>Get it free here:http://J.mp/ingToConclusionsFree<http://j.mp/ingToConclusionsFree> (available on iOS)-------------- next part --------------An HTML attachment was scrubbed...URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150722/a485e5e9/attachment-0001.html>
More information about the Python-ideasmailing list
[8]ページ先頭