Hi,
2018-04-28 5:08 GMT+02:00 Armin Rigo :
> Hi,
>
> On 26 April 2018 at 07:50, Raymond Hettinger
> wrote:
> >> [Raymond Hettinger ]
> >>> After re-reading all the proposed code samples, I believe that
> >>> adopting the PEP will make the language harder to teach to people
> >>> who are not alre
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 to
Unix-like systems, my thoughts on where I'd like to
Hi,
On 26 April 2018 at 07:50, Raymond Hettinger
wrote:
>> [Raymond Hettinger ]
>>> After re-reading all the proposed code samples, I believe that
>>> adopting the PEP will make the language harder to teach to people
>>> who are not already software engineers.
>
> (...)
>
> Python is special, in
On Fri, Apr 27, 2018 at 7:23 PM, Nick Coghlan wrote:
> The key missing piece for doing that would be to define how we'd want a `py`
> launcher to work on *nix systems, and then provide that as part of CPython
> 3.8+ (and potentially backport it to a 3.7x maintenance release).
I was thinking along
Um, the PEP has "Unix-Like Systems" in its heading, so discussing the
Windows situation seems out of scope to me.
You're one of its authors, so if you really want to keep the paragraph
about the anticipated unified future we can keep it (though preferably this
should be discussed in the issue, htt
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 see how a smooth transition *could* have been achieved.
Is it a
On 28 April 2018 at 01:37, Petr Viktorin wrote:
> Hello,
> After discussion on the [Pull Request], my update to PEP 394 changed scope
> somewhat. The new major changes are:
>
> - The `python` command may not exist at all in some cases (see the PEP for
> details)
> - The paragraph about the antici
On 4/27/2018 2:11 PM, Tim Peters wrote:
That's easy: any time there's a long thread to which Guido has
contributed at least twice, it will be seen as a Golden Opportunity to
re-litigate every decision that's ever been made;-)
You're getting pretty good at that QOTD thing, Tim :)
___
It's certainly a contrived example. Actual code with such a mistake is
generally far more subtle.
The mistake is that it's assigning a value within a clause of a conditional
that won't be evaluated.
Oh well. I'll suffer the then worsened zig-zaggy eye movements in code
reviews caused by defining
[Tres Seaver ]
> FWIW, Ned Batchelder's 'coverage.py' does a good job with branch coverage.
> I haven't seen anything in this discussion which indicates that binding
> expressions will change that at all.
I don't think you missed anything relevant either ;-) Binding
operators are exactly as irrel
Wes, sorry, but I really don't follow what you're saying. For example,
[Wes Turner ]
> Do not do this:
>
> x = 2
> if (x == 3) or (x := 3):
>print(x)
>
> What do we call that mistake?
It displays 3 - while it appears to be silly code, there's nothing
about it that's undefined. So I fail to
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
> unless you want to. It's not
On Sat, Apr 28, 2018 at 7:11 AM, Tim Peters wrote:
> [Chris Angelico ]
>> ...
>> I don't understand why people bring up all these arguments that have
>> absolutely nothing to do with the proposal at hand. None of this has
>> in any way changed.
>
> That's easy: any time there's a long thread to w
On Friday, April 27, 2018, Tim Peters wrote:
> [Chris Angelico ]
> > ...
> > I don't understand why people bring up all these arguments that have
> > absolutely nothing to do with the proposal at hand. None of this has
> > in any way changed.
>
> That's easy: any time there's a long thread to wh
[Chris Angelico ]
> ...
> I don't understand why people bring up all these arguments that have
> absolutely nothing to do with the proposal at hand. None of this has
> in any way changed.
That's easy: any time there's a long thread to which Guido has
contributed at least twice, it will be seen as
On 04/27/2018 04:34 AM, Serhiy Storchaka wrote:
27.04.18 13:25, Nick Coghlan пише:
and PEP 3099 (explicitly
rejected ideas that also didn't get their own PEPs).
"There will be no alternative binding operators such as :=."
Which is why changing that requires a PEP now.
--
~Ethan~
On Sat, Apr 28, 2018 at 6:24 AM, Wes Turner wrote:
>
>
> On Friday, April 27, 2018, Chris Angelico wrote:
>>
>> On Sat, Apr 28, 2018 at 6:06 AM, Wes Turner wrote:
>> >
>> >
>> > On Friday, April 27, 2018, Chris Angelico wrote:
>> >>
>> >> On Fri, Apr 27, 2018 at 8:18 PM, Wes Turner
>> >> wrote
On Friday, April 27, 2018, Chris Angelico wrote:
> On Sat, Apr 28, 2018 at 6:06 AM, Wes Turner wrote:
> >
> >
> > On Friday, April 27, 2018, Chris Angelico wrote:
> >>
> >> On Fri, Apr 27, 2018 at 8:18 PM, Wes Turner
> wrote:
> >> > IDK, I could just be resistant to change, but this seems like
On Sat, Apr 28, 2018 at 6:06 AM, Wes Turner wrote:
>
>
> On Friday, April 27, 2018, Chris Angelico wrote:
>>
>> On Fri, Apr 27, 2018 at 8:18 PM, Wes Turner wrote:
>> > IDK, I could just be resistant to change, but this seems like something
>> > that
>> > will decrease readability -- and slow dow
On Friday, April 27, 2018, Chris Angelico wrote:
> On Fri, Apr 27, 2018 at 8:18 PM, Wes Turner wrote:
> > IDK, I could just be resistant to change, but this seems like something
> that
> > will decrease readability -- and slow down code review -- without any
> real
> > performance gain. So, whil
[Lukasz]
>> > And that *is* a thing that you will have to explain to newbies when
>> > they encounter it for the first time.
[Tim]
>> Sure. That doesn't frighten me, though. It's easy to explain what it
>> does - although it may be hard to explain when it's _desirable_ to use
>> it.
[Chris Bar
On Thu, Apr 26, 2018 at 1:33 PM, Tim Peters wrote:
> And that *is* a thing that you will have to explain to newbies when they
> encounter
> > it for the first time.
>
> Sure. That doesn't frighten me, though. It's easy to explain what it
> does - although it may be hard to explain when it's _d
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 have no personal experience,
but if this is at all a common approach am
ACTIVITY SUMMARY (2018-04-20 - 2018-04-27)
Python tracker at https://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open6615 (+28)
closed 38510 (+26)
total 45125 (+54)
Open issues wi
On 04/27/2018 05:35 AM, Ryan Gonzalez wrote:
[snip]
Ryan, the quoted text in your emails is not being marked as such, meaning that the entire email appears to be from you.
This makes it really difficult to pick out your responses.
I would really appreciate it of you could figure out why that
Hello,
After discussion on the [Pull Request], my update to PEP 394 changed
scope somewhat. The new major changes are:
- The `python` command may not exist at all in some cases (see the PEP
for details)
- The paragraph about the anticipated future where python points to
Python 3 is removed. (
On 04/27/18 02:03, Ben Finney wrote:
Ben Finney writes:
Petr Viktorin writes:
[…] we feel that the only way to *enforce* that guidelines is to
provide environments where the `python` command does not work
(unless explicitly installed).
Yes. The ‘python’ command is confusing, for the rea
On Thu, Apr 26, 2018 at 10:25 AM, Eric Snow wrote:
> In pondering our approach to future Python major releases, I found
> myself considering the experience we've had with Python 3. The whole
> Py3k effort predates my involvement in the community so I missed a
> bunch of context about the motivati
On 4/27/2018 8:28 AM, 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 lib features are you referring to?
(That's not a rhetorical question -- maybe I have m
On Fri, Apr 27, 2018 at 8:18 PM, Wes Turner wrote:
> IDK, I could just be resistant to change, but this seems like something that
> will decrease readability -- and slow down code review -- without any real
> performance gain. So, while this would be useful for golfed-down (!)
> one-liners with py
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 lib features are you referring to?
>
> (That's not a rhetorical question --
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. It
can be explained by the long list of backward incompatible changes.
My advice would be to restrict the number of backward incompatible
changes per release, and
On April 27, 2018 12:16:09 AM Mike Miller wrote:
Sorry all, wasn't specific enough.
By "modern" I mean the last decade perhaps. New languages that have had a
chance to look at the older generations and choose their best ideas, while
leaving behind the rest.
Personally I thought of Swift (Ryan
Hello all,
I have updated PEP 575 and its reference implementation. See
https://www.python.org/dev/peps/pep-0575/
The main differences with respect to the previous version are:
* METH_PASS_FUNCTION now passes the function *in addition* to self
(previously, it was passed *instead* of self).
*
On Fri, Apr 27, 2018 at 08:13:20AM +0200, Andrea Griffini wrote:
> >> We're focused on Python 3.8 and 3.9, not Python 5 or Python 6.
>
> Hmmm... When I was hearing the repeated belated saying that Python
> will never ever jump on the statically typed ship on each and every
> static type annotat
27.04.18 13:25, Nick Coghlan пише:
and PEP 3099 (explicitly
rejected ideas that also didn't get their own PEPs).
"There will be no alternative binding operators such as :=."
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/ma
On Thursday, April 26, 2018, Eric Snow wrote:
> In pondering our approach to future Python major releases, I found
> myself considering the experience we've had with Python 3. The whole
> Py3k effort predates my involvement in the community so I missed a
> bunch of context about the motivations,
I gave the talk "Python 3: 10 years later" at FOSDEM and Pycon Italy
and will give it again at Pycon US next month:
https://fosdem.org/2018/schedule/event/python3/
My talk is focused on the migration path. How to "port" Python 2 code
to Python 3, 2to3 tool, six module, things done to make the migr
On 27 April 2018 at 03:18, Barry Warsaw wrote:
> On Apr 26, 2018, at 09:28, Eric Snow wrote:
>>
>> On Thu, Apr 26, 2018 at 10:25 AM, Eric Snow
>> wrote:
>>> In pondering our approach to future Python major releases, I found
>>> myself considering the experience we've had with Python 3. The who
So, the style guidelines for this new feature -- and also ternary
expressions and comprehension -- would need to mention that:
- debuggers have no idea what to do with all of this on one line
- left-to-right doesn't apply to comprehensions
results = [(x, y, x/y) for x in input_data if (y := f(x
On Thu, 26 Apr 2018 22:25:09 +0300
Serhiy Storchaka wrote:
>
> f(b=2, *[1]) is surprised in two ways:
>
> 1. Argument values are passed not in order. The first value is assigned
> to the second parameter, and the second value is assigned to the first
> parameter.
I don't find it that surprisi
On Thu, Apr 26, 2018 at 12:25 PM, Serhiy Storchaka wrote:
> f(b=2, *[1]) is surprised in two ways:
>
> 1. Argument values are passed not in order. The first value is assigned to
> the second parameter, and the second value is assigned to the first
> parameter.
>
> 2. Argument values are evaluated
Eric Snow wrote:
Unless I've missed something, there's no prohibition against
deprecating things (and then later removing them) or other breaks in
backward compatibility.
I suppose that's true, but even so, changing "=" is going
to feel like a really big change in the style of the
language, big
Fatty Morgan wrote:
Distinguishing in a rather unobtrusive way (no 'var' or 'let')
the initialization of a previously unbound variable 'name := expr'
and the re-assignment of a previously bound variable 'name = expr'
That would be a massively confusing change. It's a fine idea
for a new languag
44 matches
Mail list logo
