On Sun, Apr 29, 2018 at 1:11 PM, Alex Walters wrote:
>
>
>> -Original Message-
>> From: Python-Dev > list=sdamon@python.org> On Behalf Of Greg Ewing
>> Sent: Saturday, April 28, 2018 10:53 PM
>> To: 'Python-Dev'
>> Subject: Re: [Python-Dev] PEP 572 contradicts PEP 3099
>>
>> Alex Walt
> -Original Message-
> From: Python-Dev list=sdamon@python.org> On Behalf Of Greg Ewing
> Sent: Saturday, April 28, 2018 10:53 PM
> To: 'Python-Dev'
> Subject: Re: [Python-Dev] PEP 572 contradicts PEP 3099
>
> Alex Walters wrote:
> > PEP 3099 is the big list of things that will not
Alex Walters wrote:
PEP 3099 is the big list of things that will not happen in Python 3.
"There will be no alternative binding operators such as :=."
The thread referenced by that is taling about a different issue,
i.e. using a different symbol to rebind names in an outer scope.
--
Greg
_
On Fri, 27 Apr 2018 14:13:32 +0200
Victor Stinner wrote:
>
> I don't think that having Python X.Y which introduces backward
> incompatible changes is an issue by itself. We did it multiple times
> during the Python 3 cycle: my PEP 446 (non-inheritable file
> descriptors) and PEP 475 (retry syscal
On Fri, 27 Apr 2018 09:49:33 -0700
Chris Barker wrote:
> On Tue, Apr 24, 2018 at 2:21 AM, Victor Stinner wrote:
>
> > Even if the C language allows assignments in if, I avoid them, because
> > I regularly have to debug my own code in gdb ;-)
> >
>
> I personally haven't written a lot of C, so
PEP 3099 is the big list of things that will not happen in Python 3.
Everything on that list is still true, 12 years after it was posted.
However...
"There will be no alternative binding operators such as :=."
While earlier versions of PEP 572 avoided breaking this declaration, the
current versio
On Sat, Apr 28, 2018 at 10:36 AM Greg Ewing
wrote:
> Victor Stinner wrote:
> > In my opinion, the largest failure of Python 3 is that we failed to
> > provide a smooth and *slow* transition from Python 2 and Python 3.
> Although for some things, such as handling of non-ascii text, it's
> hard to
On 2018-04-28, 01:33 GMT, Greg Ewing wrote:
>> In my opinion, the largest failure of Python 3 is that we
>> failed to provide a smooth and *slow* transition from Python
>> 2 and Python 3.
>
> Although for some things, such as handling of non-ascii text, it's
> hard to see how a smooth transition
On Sat, Apr 28, 2018 at 9:18 PM, Ned Batchelder wrote:
> It's entirely true that binding expressions don't change this situation at
> all, EXCEPT that the entire point of binding expressions is to be able to
> express in one statement what used to take more than one. With binding
> expressions, a
On 4/27/18 5:28 PM, Tres Seaver wrote:
On 04/27/2018 05:11 PM, Tim Peters wrote:
In this specific case, line-oriented coverage tools have missed
accounting for all possible code paths since day #1; e.g.,
x = f() or g()
You don't need to reply to messages so obviously irrelevant to the PEP
unl
On Fri, Apr 27, 2018 at 10:56:06PM +1000, Nick Coghlan wrote:
> On 27 April 2018 at 22:28, Steven D'Aprano wrote:
>
> > On Fri, Apr 27, 2018 at 08:13:20AM +0200, Andrea Griffini wrote:
> > > Now we got standard library features requiring type annotation
> >
> > We do? Did I miss them? Which std l
On Fri, Apr 27, 2018 at 8:19 PM, Tim Peters wrote:
> [Lukasz]
> >> > And that *is* a thing that you will have to explain to newbies when
> >> > they encounter it for the first time.
>
> Which they will presumably do either in class or by reading code. No
sensible instructor or course author is
On 28 April 2018 at 05:08, Nick Coghlan wrote:
> On 28 April 2018 at 12:34, Guido van Rossum wrote:
>>
>> Um, the PEP has "Unix-Like Systems" in its heading, so discussing the
>> Windows situation seems out of scope to me.
>
> Sorry, I conflated two issues there - while PEP 394 itself is specific
On 2018-04-28, 01:23 GMT, Nick Coghlan wrote:
> That isn't currently *my* desired future, as I don't want to
> see a python3 to python4 naming transition at any point,
> I want a transition from python3 back to an unqualified name
> to accurately reflect the change in version management
> philo
On Fri, Apr 27, 2018 at 04:24:35PM -0400, Wes Turner wrote:
> if ((1) or (x := 3)):
> if ((y := func(x)) if x else (x := 3))
Wes, there is *absolutely nothing new* here. This sort of error is
already possible in Python.
Do you see a lot of code like:
if (1 or sequence.append(3) or sequence
15 matches
Mail list logo
