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,
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,
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-
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
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 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
[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
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
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 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
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 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
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
[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
27 matches
Mail list logo
