Serhiy Storchaka schrieb am 28.03.2018 um 17:27:
> There is a subtle semantic difference between str.format() and "equivalent"
> f-string.
>
> '{}{}'.format(a, b)
> f'{a}{b}'
>
> In the former case b is evaluated before formatting a. This is equivalent to
>
> t1 = a
> t2 = b
>
[Steven D'Aprano ]
> ...
> Is there a down-side to 2b? It sounds like something you might end up
> doing at a later date regardless of what you do now.
There are always downsides ;-)
As Serhiy noted later, the idea that "it's faster" is an educated
guess - you can't know before it's implemented.
On Fri, Mar 30, 2018 at 4:41 AM, Nick Coghlan wrote:
> On 30 March 2018 at 21:16, Nathaniel Smith wrote:
>> And bool(obj) does always return True or False; if you define a
>> __bool__ method that returns something else then bool rejects it and
>> raises TypeError. So bool(bool(obj)) is already in
On 3/30/2018 6:29 AM, Serhiy Storchaka wrote:
29.03.18 18:06, Terry Reedy пише:
On 3/28/2018 11:27 AM, Serhiy Storchaka wrote:
The optimizer already changes semantic. Non-optimized "if a and
True:" would call bool(a) twice, but optimized code calls it only once.
Perhaps Ref 3.3.1 object.__boo
On 30 March 2018 at 21:16, Nathaniel Smith wrote:
> On Fri, Mar 30, 2018 at 3:29 AM, Serhiy Storchaka wrote:
>> 29.03.18 18:06, Terry Reedy пише:
>>>
>>> On 3/28/2018 11:27 AM, Serhiy Storchaka wrote:
The optimizer already changes semantic. Non-optimized "if a and True:"
would call
On Fri, Mar 30, 2018 at 3:29 AM, Serhiy Storchaka wrote:
> 29.03.18 18:06, Terry Reedy пише:
>>
>> On 3/28/2018 11:27 AM, Serhiy Storchaka wrote:
>>>
>>> The optimizer already changes semantic. Non-optimized "if a and True:"
>>> would call bool(a) twice, but optimized code calls it only once.
>>
>
On Fri, Mar 30, 2018 at 01:29:53PM +0300, Serhiy Storchaka wrote:
> 29.03.18 18:06, Terry Reedy пише:
> >On 3/28/2018 11:27 AM, Serhiy Storchaka wrote:
> >>The optimizer already changes semantic. Non-optimized "if a and True:"
> >>would call bool(a) twice, but optimized code calls it only once.
>
29.03.18 18:06, Terry Reedy пише:
On 3/28/2018 11:27 AM, Serhiy Storchaka wrote:
The optimizer already changes semantic. Non-optimized "if a and True:"
would call bool(a) twice, but optimized code calls it only once.
Perhaps Ref 3.3.1 object.__bool__ entry, after " should return False or
True
On 30 March 2018 at 20:05, Serhiy Storchaka wrote:
> 30.03.18 02:16, Steven D'Aprano пише:
>>
>> Is there a down-side to 2b? It sounds like something you might end up
>> doing at a later date regardless of what you do now.
>
>
> This complicate the compiler and the eval loop, especially in the cas
30.03.18 02:16, Steven D'Aprano пише:
Is there a down-side to 2b? It sounds like something you might end up
doing at a later date regardless of what you do now.
This complicate the compiler and the eval loop, especially in the case
of nested substitutions in formats, like
f'{value:+{widt
On 30 March 2018 at 03:33, Eric V. Smith wrote:
> On 3/29/2018 12:13 PM, Nick Coghlan wrote:
>> While more projects are starting to actively drop Python 2.x support,
>> there are also quite a few still straddling the two different
>> versions. The "rewrite to f-strings" approach requires explicitl
On Wed, Mar 28, 2018 at 06:27:19PM +0300, Serhiy Storchaka wrote:
> 2. Change the semantic of f-strings. Make it closer to the semantic of
> str.format(): evaluate all subexpressions first than format them. This
> can be implemented in two ways:
>
> 2a) Add additional instructions for stack man
29.03.18 13:17, Jeff Allen пише:
'{1} {0}'.format(a(), b()) # E1
f'{b()}{a()}' # E2
I think I would be very surprised to find b called before a in E1
because of the general contract on the meaning of method calls. I'm
assuming that's what an AST-based optimisation woul
On 3/29/2018 12:13 PM, Nick Coghlan wrote:
On 29 March 2018 at 21:50, Eric V. Smith wrote:
#1 seems so complex as to not be worth it, given the likely small overall
impact of the optimization to a large program. If the speedup really is
sufficiently important for a particular piece of code, I'd
On 29 March 2018 at 21:50, Eric V. Smith wrote:
> #1 seems so complex as to not be worth it, given the likely small overall
> impact of the optimization to a large program. If the speedup really is
> sufficiently important for a particular piece of code, I'd suggest just
> rewriting the code to us
On 3/28/2018 11:27 AM, Serhiy Storchaka wrote:
The optimizer already changes
semantic. Non-optimized "if a and True:" would call bool(a) twice, but
optimized code calls it only once.
Perhaps Ref 3.3.1 object.__bool__ entry, after " should return False or
True.", should say something like "Sho
On Fri, Mar 30, 2018 at 1:08 AM, Chris Angelico wrote:
> On Thu, Mar 29, 2018 at 11:28 PM, Steven D'Aprano wrote:
>> On Wed, Mar 28, 2018 at 06:27:19PM +0300, Serhiy Storchaka wrote:
>>
>>> The optimizer already changes
>>> semantic. Non-optimized "if a and True:" would call bool(a) twice, but
>>
On Thu, Mar 29, 2018 at 11:28 PM, Steven D'Aprano wrote:
> On Wed, Mar 28, 2018 at 06:27:19PM +0300, Serhiy Storchaka wrote:
>
>> The optimizer already changes
>> semantic. Non-optimized "if a and True:" would call bool(a) twice, but
>> optimized code calls it only once.
>
> I don't understand thi
On Wed, Mar 28, 2018 at 06:27:19PM +0300, Serhiy Storchaka wrote:
> The optimizer already changes
> semantic. Non-optimized "if a and True:" would call bool(a) twice, but
> optimized code calls it only once.
I don't understand this. Why would bool(a) be called twice, and when did
this change?
On 3/29/2018 6:17 AM, Jeff Allen wrote:
My credentials for this are that I re-worked str.format in Jython quite
extensively, and I followed the design of f-strings a bit when they were
introduced, but I haven't used them to write anything.
Thanks for your work on Jython. And hop on the f-strin
My credentials for this are that I re-worked str.format in Jython quite
extensively, and I followed the design of f-strings a bit when they were
introduced, but I haven't used them to write anything.
On 29/03/2018 00:48, Tim Peters wrote:
[Tim Delaney ]
...
I also assumed (not having actually
[Tim Delaney ]
> ...
> If I'm not mistaken, #3 would result in the optimiser changing str.format()
> into an f-string in-place. Is this correct? We're not talking here about
> people manually changing the code from str.format() to f-strings, right?
All correct. It's a magical transformation from
On 29 March 2018 at 08:09, Tim Delaney wrote:
> On 29 March 2018 at 07:39, Eric V. Smith wrote:
>
>> I’d vote #3 as well.
>>
>> > On Mar 28, 2018, at 11:27 AM, Serhiy Storchaka
>> wrote:
>> >
>> > There is a subtle semantic difference between str.format() and
>> "equivalent" f-string.
>> >
>> >
On 29 March 2018 at 07:39, Eric V. Smith wrote:
> I’d vote #3 as well.
>
> > On Mar 28, 2018, at 11:27 AM, Serhiy Storchaka
> wrote:
> >
> > There is a subtle semantic difference between str.format() and
> "equivalent" f-string.
> >
> >'{}{}'.format(a, b)
> >f'{a}{b}'
> >
> > In most cas
I’d vote #3 as well.
--
Eric
> On Mar 28, 2018, at 11:27 AM, Serhiy Storchaka wrote:
>
> There is a subtle semantic difference between str.format() and "equivalent"
> f-string.
>
>'{}{}'.format(a, b)
>f'{a}{b}'
>
> In the former case b is evaluated before formatting a. This is equiv
On 28 March 2018 at 20:12, Serhiy Storchaka wrote:
> 28.03.18 22:05, Paul Moore пише
>
> I can't imagine (non-contrived) code where the fact that a is
> formatted before b is evaluated would matter, so I'm fine with option
> 3.
>
>
> If formatting a and evaluating b both raise exceptions, the resu
Serhiy Storchaka schrieb am 28.03.2018 um 17:27:
> There is a subtle semantic difference between str.format() and "equivalent"
> f-string.
>
> '{}{}'.format(a, b)
> f'{a}{b}'
>
> In the former case b is evaluated before formatting a. This is equivalent to
>
> t1 = a
> t2 = b
>
28.03.18 22:04, Guido van Rossum пише:
Yes, #3, and what Tim says.
Thank you. This helps a much.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/optio
28.03.18 22:05, Paul Moore пише
I can't imagine (non-contrived) code where the fact that a is
formatted before b is evaluated would matter, so I'm fine with option
3.
If formatting a and evaluating b both raise exceptions, the resulting
exception depends on the order.
$ ./python -bb
>
On 28 March 2018 at 19:44, Serhiy Storchaka wrote:
> 28.03.18 19:20, Guido van Rossum пише:
>
>> Hm, without thinking too much about it I'd say it's okay to change the
>> evaluation order.
>
> Do you mean the option 3, right? This is the simplest option. I have already
> wrote a PR for optimizing
Yes, #3, and what Tim says.
On Wed, Mar 28, 2018, 11:44 Serhiy Storchaka wrote:
> 28.03.18 19:20, Guido van Rossum пише:
>
> > Hm, without thinking too much about it I'd say it's okay to change the
> > evaluation order.
>
> Do you mean the option 3, right? This is the simplest option. I have
> a
28.03.18 21:30, Tim Peters пише:
[Tim]
I have a hard time imaging how that could have come to be, but if it's
true I'd say the unoptimized code was plain wrong. The dumbest
possible way to implement `f() and g()` is also the correct ;-) way:
result = f()
if not bool(result):
result = g()
[Tim]
> Same top-level point, though: [for evaluating `f() and g()`]:
>
> result = f()
> if bool(result):
> result = g()
Ah, I think I see your point now. In the _context_ of `if f() and
g()`, the dumbest possible code generation would do the above, and
then go on to do
if bool(result):
28.03.18 19:20, Guido van Rossum пише:
Hm, without thinking too much about it I'd say it's okay to change the
evaluation order.
Do you mean the option 3, right? This is the simplest option. I have
already wrote a PR for optimizing old-style formating [1], but have not
merged it yet due to th
[Tim]
> I have a hard time imaging how that could have come to be, but if it's
> true I'd say the unoptimized code was plain wrong. The dumbest
> possible way to implement `f() and g()` is also the correct ;-) way:
>
> result = f()
> if not bool(result):
> result = g()
Heh - that's entirely w
[Serhiy Storchaka ]
> ...
> This is not new. The optimizer already changes semantic.
> Non-optimized "if a and True:" would call bool(a) twice, but optimized code
> calls it only once.
I have a hard time imaging how that could have come to be, but if it's
true I'd say the unoptimized code was plai
Hm, without thinking too much about it I'd say it's okay to change the
evaluation order. Can these optimizations be disabled with something like
-O0?
On Wed, Mar 28, 2018 at 8:27 AM, Serhiy Storchaka
wrote:
> There is a subtle semantic difference between str.format() and
> "equivalent" f-string.
There is a subtle semantic difference between str.format() and
"equivalent" f-string.
'{}{}'.format(a, b)
f'{a}{b}'
In the former case b is evaluated before formatting a. This is equivalent to
t1 = a
t2 = b
t3 = format(t1)
t4 = format(t2)
r = t3 + t4
In the latter
38 matches
Mail list logo
