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
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.
[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
[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
Hi,
I'd like to submit this PEP for discussion. It is quite specialized
and the main target audience of the proposed changes is
users and authors of applications/libraries transferring large amounts
of data (read: the scientific computing & data science ecosystems).
https://www.python.org/dev/p
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]
> 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 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()
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
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
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
>
28.03.18 22:04, Guido van Rossum пише:
Yes, #3, and what Tim says.
Thank you. This helps a much.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/optio
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
>
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
28.03.18 21:39, Antoine Pitrou пише:
> I'd like to submit this PEP for discussion. It is quite specialized
> and the main target audience of the proposed changes is
> users and authors of applications/libraries transferring large amounts
> of data (read: the scientific computing & data science ec
On Wed, 28 Mar 2018 23:03:08 +0300
Serhiy Storchaka wrote:
> 28.03.18 21:39, Antoine Pitrou пише:
> > I'd like to submit this PEP for discussion. It is quite specialized
> > and the main target audience of the proposed changes is
> > users and authors of applications/libraries transferring lar
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 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
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.
>> >
>> >
Python 3.6.5 is now available. 3.6.5 is the fifth maintenance release of
Python 3.6, which was initially released in 2016-12 to great interest.
Detailed information about the changes made in 3.6.5 can be found in its
change log. You can find Python 3.6.5 and more information here:
https://www.p
[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 Wed, Mar 28, 2018 at 1:03 PM, Serhiy Storchaka wrote:
> 28.03.18 21:39, Antoine Pitrou пише:
>> I'd like to submit this PEP for discussion. It is quite specialized
>> and the main target audience of the proposed changes is
>> users and authors of applications/libraries transferring large amoun
One question..
On Thu., 29 Mar. 2018, 07:42 Antoine Pitrou, wrote:
> ...
>
===
>
> Mutability
> --
>
> PEP 3118 buffers [#pep-3118]_ can be readonly or writable. Some objects,
> such as Numpy arrays, need to be backed by a mutable buffer for full
> operation. Pickle consumers that
On 3/28/2018 9:15 PM, Nathaniel Smith wrote:
There's obviously some tension here between pickle's use as a
persistent storage format, and its use as a transient wire format. For
the former, you definitely can't store code objects because there's no
forwards- or backwards-compatibility guarantee
Hi,
My name is Julia Hiyeon Kim.
My suggestion is to change the syntax for creating an empty set and an empty
dictionary as following.
an_empty_set = {}
an_empty_dictionary = {:}
It would seem to make more sense.
Warm regards,
Julia Kim
___
Python-
Hi, Julia,
On 28 March 2018 at 21:14, Julia Kim wrote:
>
> My suggestion is to change the syntax for creating an empty set and an
> empty dictionary as following.
>
You should craft your suggestion as a PEP and send it to the python-ideas
mailing list. Good luck! -- H
--
OpenPGP:
https://sks-k
Hi Julia, and welcome!
On Wed, Mar 28, 2018 at 09:14:53PM -0700, Julia Kim wrote:
> My suggestion is to change the syntax for creating an empty set and an
> empty dictionary as following.
>
> an_empty_set = {}
> an_empty_dictionary = {:}
>
> It would seem to make more sense.
Indeed it would,
27 matches
Mail list logo
