Re: [Python-ideas] Briefer string format
Thanks for thinking about it, Chris. After several mentions of u'' and b'' I was waiting patiently for '' and r''. I guess r'' does nothing but what does '' or "" do at runtime? "\tcommand line --params\n" --> " command line --params " It looks like there is some runtime conversion happening there, though I don't know the implementation details. On Mon, 20 Jul 2015 10:51:28 +1000, Chris Angelico wrote:
Also, Re: below, this a subtle but important improvement Steve, thanks! Yes, a transformation from: f"{x} {y}" to "string with braces".format(x=x, y=y) This is very much what I was thinking. If the second form is ok, the first should be too, syntax aside, if it does the same thing. The drawback being it might take a tool like an upgraded pyflakes/pycharm to notice y hadn't been defined yet. (Might a further optimization in C be possible to skip the function call, but basically work like this? No locals/globals()?) -Mike On Mon, Jul 20, 2015 at 10:43 AM, Steve Dower <Steve.Dower@microsoft.com> wrote:
Why wouldn't this be a compile time transform from f"string with braces" into "string with braces".format(x=x, y=y, ...) where x, y, etc are...
On Mon, Jul 20, 2015 at 2:42 PM, Mike Miller <python-ideas@mgmiller.net> wrote:
No, it's not runtime conversion; it's an alternative syntax. Aside from unicode vs bytes, all types of string literals are just different ways of embedding a string in your source code; this is why it's sometimes important to talk about a "raw string literal" rather than abbreviating it to "raw string", as if the string itself were different. You can play around with it in the interactive interpreter. All strings show the same form in repr, namely the unprefixed form (again, apart from a b"..." prefix on bytes); once the compiler has turned source code notation into constants, they're just string objects. ChrisA
On Jul 19, 2015, at 21:42, Mike Miller <python-ideas@mgmiller.net> wrote:
(Might a further optimization in C be possible to skip the function call, but basically work like this? No locals/globals()?)
Why do you keep bringing up optimization? Do you actually have code where the call to str.format or str.format or str.__mod__ or locals is actually a relevant cost? It seems to me that whenever that call is too slow to bear, calling __str__ or __format__ on all of the substitutes variables must be far more of a problem, so your optimized version would still be useless.
On Mon, Jul 20, 2015 at 2:42 PM, Mike Miller <python-ideas@mgmiller.net> wrote:
No, it's not runtime conversion; it's an alternative syntax. Aside from unicode vs bytes, all types of string literals are just different ways of embedding a string in your source code; this is why it's sometimes important to talk about a "raw string literal" rather than abbreviating it to "raw string", as if the string itself were different. You can play around with it in the interactive interpreter. All strings show the same form in repr, namely the unprefixed form (again, apart from a b"..." prefix on bytes); once the compiler has turned source code notation into constants, they're just string objects. ChrisA
On Jul 19, 2015, at 21:42, Mike Miller <python-ideas@mgmiller.net> wrote:
(Might a further optimization in C be possible to skip the function call, but basically work like this? No locals/globals()?)
Why do you keep bringing up optimization? Do you actually have code where the call to str.format or str.format or str.__mod__ or locals is actually a relevant cost? It seems to me that whenever that call is too slow to bear, calling __str__ or __format__ on all of the substitutes variables must be far more of a problem, so your optimized version would still be useless.
participants (3)
-
Andrew Barnert -
Chris Angelico -
Mike Miller