Re: [Python-Dev] PEP 394: Allow the `python` command to not be installed (and other minor edits)

[Nick Coghlan]

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 take it in the future
are mainly informed by my experiences helping to maintain the Python
Packaging User Guide these days, where the current platform dependence of
"How does a user run Python, pip, and pip-installed Python tools from the
command line?" is a frequent source of problems for folks just starting
out. (We really don't want to be maintaining separate "Windows
instructions" and "everywhere else instructions" indefinitely, but that's
where we are currently)


> 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, https://github.com/python/peps/pull/630).
> But I think this PEP is strongest in its guidelines for what distros and
> sysadmins should do *today*; I feel that that paragraph encourages hopes
> about a future that's farther away than most people care to plan, and not
> at all certain.
>

After reviewing the specifics of the proposed changes in the PR, I'm fine
with dropping any reference to future plans for the unqualified "python"
name for now (aside from clarifying how we expect it to work in virtual
environments). That accurately reflects the status quo anyway - inside a
virtual environment, 'python' has a clear expected meaning (the venv's
Python), outside a virtual environment it's thoroughly ambiguous at best.

The real deadline for figuring out the preferred post-Python-3 spelling
will be once we decide to bump the major version number again, and that's
at least a few years away, even if we eventually decide not to do a Python
3.10.

Cheers,
Nick.

P.S. Historically, we hadn't been able to get much real traction with the
"py-for-Unix-like-systems" idea, since it wasn't clear what problem, if
any, it would solve at the *distro* level. However, we may have more luck
if we're able to position it as a more forward-compatible replacement for
explicit references to 'python3' that doesn't conflict with the assumption
that `python` will refer specifically to `python2`.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

[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 already software engineers.
>
> (...)
>
> Python is special, in part, because it is not one of those languages.
> It has virtues that make it suitable even for elementary school children.
> We can show well-written Python code to non-computer folks and walk
> them through what it does without their brains melting (something I can't
> do with many of the other languages I've used).  There is a virtue
> in encouraging simple statements that read like English sentences
> organized into English-like paragraphs, presenting itself like
> "executable pseudocode".

I must admit that when I heard about this PEP I thought "this April
1st joke was already done long ago".  I'm sorry to discover that, this
time, it is not actually one.  Thank you, Raymond, for an unlikely
attempt at reminding people what made Python so special---in your
opinion, and mine.


A bientôt,

Armin.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 394: Allow the `python` command to not be installed (and other minor edits)

[Eric Snow]

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 the same lines just today, with an email
forthcoming.  Now I don't have to write it. :)

-eric
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 394: Allow the `python` command to not be installed (and other minor edits)

[Guido van Rossum]

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, https://github.com/python/peps/pull/630).
But I think this PEP is strongest in its guidelines for what distros and
sysadmins should do *today*; I feel that that paragraph encourages hopes
about a future that's farther away than most people care to plan, and not
at all certain.

On Fri, Apr 27, 2018 at 6:23 PM, Nick Coghlan  wrote:

> 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 anticipated future where python points to
>> Python 3 is removed. (We'd rather see a future where `python` doesn't exist
>> and one always has to specify `python2` or `python3`.)
>>
>
> 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 philosophy resulting from the extended Python 3 migration. (And
> then "python3" would linger solely as a backwards compatibility remnant,
> even if it referred to python 4+, or a switch to some kind of CalVer based
> versioning scheme)
>
> However, it may be possible to solve two problems at once here, as one of
> the issues we have in writing cross-platform instructions for both Windows
> and *nix systems is that "python" isn't guaranteed to be on the Windows
> path, but the "py" launcher *is*. This means the most robust tooling
> invocations on Windows are of the form "py -m pip ...", since they don't
> care about how your system PATH is configured. Getting not only "python",
> but also scripts installed with "py -m pip install --user..." to be
> reliably on the PATH is an arcane problem with assorted complications
> stemming from the differences between per-machine and per-user
> installations of Windows applications, and the "py -m module ..." approach
> avoids that mess entirely (as long as the tools of interest correctly
> support invocation via "-m").
>
> The downside of those instructions is that it means we have a platform
> split where, depending on how your system is setup, which version of Python
> you're using, and whether or not you're running in a virtual environment,
> you need to invoke Python from the command line as one of:
>
> - python
> - python3
> - py
>
> (more details at https://github.com/pypa/python-packaging-user-guide/
> issues/396 )
>
> Thanks for everyone involved, especially Guido for pitching in with the
>> intended direction -- which was not clear from (or is genuinely different
>> from) the 7-year-old PEP!
>>
>
> It's a change, and not one that's been explicitly discussed with the
> current authors of the PEP yet (although I do see that Barry has chimed in
> on the PR).
>
> I think it's a reasonable way for us to go, *if* it's accompanied by an
> explicit decision that we want to drive cross-platform convergence around
> "py" as the convention for unqualified version independent access to a
> Python interpreter (regardless of whether or not a virtual environment is
> active or not)
>
> 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).
>
> Cheers,
> Nick.
>
> P.S. Note that on Windows, `py` always refers specifically to the launcher
> (it doesn't get shadowed in virtual environments), but the launcher itself
> is virtual environment aware (see https://www.python.org/dev/
> peps/pep-0486/ for details).
>
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> guido%40python.org
>
>


-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] (Looking for) A Retrospective on the Move to Python 3

[Greg Ewing]

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 failure if we don't succeed in doing the impossible?

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 394: Allow the `python` command to not be installed (and other minor edits)

[Nick Coghlan]

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 anticipated future where python points to Python
> 3 is removed. (We'd rather see a future where `python` doesn't exist and
> one always has to specify `python2` or `python3`.)
>

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 philosophy resulting from the extended Python 3 migration. (And
then "python3" would linger solely as a backwards compatibility remnant,
even if it referred to python 4+, or a switch to some kind of CalVer based
versioning scheme)

However, it may be possible to solve two problems at once here, as one of
the issues we have in writing cross-platform instructions for both Windows
and *nix systems is that "python" isn't guaranteed to be on the Windows
path, but the "py" launcher *is*. This means the most robust tooling
invocations on Windows are of the form "py -m pip ...", since they don't
care about how your system PATH is configured. Getting not only "python",
but also scripts installed with "py -m pip install --user..." to be
reliably on the PATH is an arcane problem with assorted complications
stemming from the differences between per-machine and per-user
installations of Windows applications, and the "py -m module ..." approach
avoids that mess entirely (as long as the tools of interest correctly
support invocation via "-m").

The downside of those instructions is that it means we have a platform
split where, depending on how your system is setup, which version of Python
you're using, and whether or not you're running in a virtual environment,
you need to invoke Python from the command line as one of:

- python
- python3
- py

(more details at
https://github.com/pypa/python-packaging-user-guide/issues/396 )

Thanks for everyone involved, especially Guido for pitching in with the
> intended direction -- which was not clear from (or is genuinely different
> from) the 7-year-old PEP!
>

It's a change, and not one that's been explicitly discussed with the
current authors of the PEP yet (although I do see that Barry has chimed in
on the PR).

I think it's a reasonable way for us to go, *if* it's accompanied by an
explicit decision that we want to drive cross-platform convergence around
"py" as the convention for unqualified version independent access to a
Python interpreter (regardless of whether or not a virtual environment is
active or not)

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).

Cheers,
Nick.

P.S. Note that on Windows, `py` always refers specifically to the launcher
(it doesn't get shadowed in virtual environments), but the launcher itself
is virtual environment aware (see https://www.python.org/dev/peps/pep-0486/
for details).

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

[Glenn Linderman]

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 :)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

[Wes Turner]

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 values at the end of expressions that reference
them which fit on a single line.

There are a number of bad examples for style guides in these threads.

:=

I wasn't aware of this switch, thanks!
http://coverage.readthedocs.io/en/latest/branch.html
coverage run --branch code.py



On Friday, April 27, 2018, Tim Peters  wrote:

> 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 see how showing that example
> anywhere would do anyone any good.
>
> You can do the same kind of thing today via, e.g.,
>
> class Bindable:
> def __init__(self, value):
> self.bind(value)
>
> def bind(self, value):
> self.value = value
> return value
>
> def __bool__(self):
> return bool(self.value)
>
> def __eq__(self, other):
> return self.value == other
>
> def __str__(self):
> return str(self.value)
>
> Then:
>
> >>> x = Bindable(2)
> >>> if x == 3 or x.bind(3):
> ... print(x)
> 3
>
> And I wouldn't put that example anywhere in any docs either ;-)
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

[Tim Peters]

[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 irrelevant to control-flow analyzers as,
e.g., introducing a floor division operator (//) was.

Data-flow analyzers (if there are any for Python) are a different
story, since they need to be aware of all (re)binding operations -
although at the byte code level, all such sites remain equally
apparent (no new flavor of "store" operation is added by this PEP).
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

[Tim Peters]

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 see how showing that example
anywhere would do anyone any good.

You can do the same kind of thing today via, e.g.,

class Bindable:
def __init__(self, value):
self.bind(value)

def bind(self, value):
self.value = value
return value

def __bool__(self):
return bool(self.value)

def __eq__(self, other):
return self.value == other

def __str__(self):
return str(self.value)

Then:

>>> x = Bindable(2)
>>> if x == 3 or x.bind(3):
... print(x)
3

And I wouldn't put that example anywhere in any docs either ;-)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

[Tres Seaver]

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 like Guido will read them and go "oh!  a 
> binding expression in a ternary conditional is a fundamentally new 
> potential problem for a line-oriented coverage tool!  that's fatal" ;-)
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.


Tres.
-- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   "Excellence by Design"http://palladion.com

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

[Chris Angelico]

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 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 ;-)

Well, now, that explains a lot! :-)

> Some amount of that seems healthy to me (people are thinking about
> "language design" from a larger view than the proposal du jour).  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 like Guido will read them and go "oh!  a
> binding expression in a ternary conditional is a fundamentally new
> potential problem for a line-oriented coverage tool!  that's fatal"
> ;-)

True, but sometimes it takes two or three emails before I actually
understand the objection enough to know that it's actually irrelevant
:| I'm going to start ignoring any message that I don't understand, in
the hopes that it doesn't actually mean anything. :|

ChrisA
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

[Wes Turner]

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 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 ;-)
>
> Some amount of that seems healthy to me (people are thinking about
> "language design" from a larger view than the proposal du jour).  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 like Guido will read them and go "oh!  a
> binding expression in a ternary conditional is a fundamentally new
> potential problem for a line-oriented coverage tool!  that's fatal"
> ;-)


I have shared with you the overlapping concerns about this feature proposal
that I believe should be explained with DO and DON'T in the docs and/or the
PEP and/or the style guide(s) for various organizations in the Pyrhon
community.

This feature does require additions to the style-guide(s); which is why so
many have expressed concern about such a simple thing.

If you want to write debuggable and coverage-testable code, do not use the
assignment expression operator in ternary expressions or boolean-chained
expressions.

The assignment expression operator is the only way to define variables with
only comprehension scope.

Do not do this:

x = 2
if (x == 3) or (x := 3):
   print(x)

What do we call that mistake?


> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> wes.turner%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

[Tim Peters]

[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 a Golden Opportunity to
re-litigate every decision that's ever been made ;-)

Some amount of that seems healthy to me (people are thinking about
"language design" from a larger view than the proposal du jour).  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 like Guido will read them and go "oh!  a
binding expression in a ternary conditional is a fundamentally new
potential problem for a line-oriented coverage tool!  that's fatal"
;-)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] (Looking for) A Retrospective on the Move to Python 3

[Ethan Furman]

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~

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

[Chris Angelico]

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:
>> >> > 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 pyline,
>> >> > I'm -1 on PEP 572.
>> >>
>> >> PEP 572 has never promised a performance gain, so "without any real
>> >> performance gain" is hardly a criticism.
>> >>
>> >> > How do I step through this simple example with a debugger?
>> >> >
>> >> > if re.search(pat, text) as match:
>> >> > print("Found:", match.group(0))
>> >>
>> >> Step the 'if' statement. It will call re.search() and stash the result
>> >> in 'match'. Then the cursor would be put either on the 'print' (if the
>> >> RE matched) or on the next executable line (if it didn't).
>> >
>> >
>> > Right. Pdb doesn't step through the AST branches of a line, so ternary
>> > expressions and list comprehensions and defining variables at the end of
>> > the
>> > line are 'debugged' after they're done.
>> >
>> > Similarly, code coverage is line-based; so those expressions may appear
>> > to
>> > be covered but are not.
>>
>> I'm not sure I follow. In what situation would some code appear to be
>> covered when it isn't, due to an assignment expression?
>
>
> When an assignment expression is in the else clause of a ternary expression,
> but the else clause does not execute because the condition is true, the
> assignment expression does not execute and so isn't covered.
>
> if ((1) or (x := 3)):
> if ((y := func(x)) if x else (x := 3))
>
> Is this a new opportunity for misunderstanding?
>
> Assignment expressions, though they are noticeable :=, may not actually
> define the variable in cases where that part of the line doesn't run but
> reads as covered.

Okay. How is this different from anything else involving if/else
expressions? If your code coverage checker is unable to handle
if/else, it's unable to handle it whether there's an assignment in
there or not.

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.

ChrisA
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

[Wes Turner]

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
> 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 pyline,
> >> > I'm -1 on PEP 572.
> >>
> >> PEP 572 has never promised a performance gain, so "without any real
> >> performance gain" is hardly a criticism.
> >>
> >> > How do I step through this simple example with a debugger?
> >> >
> >> > if re.search(pat, text) as match:
> >> > print("Found:", match.group(0))
> >>
> >> Step the 'if' statement. It will call re.search() and stash the result
> >> in 'match'. Then the cursor would be put either on the 'print' (if the
> >> RE matched) or on the next executable line (if it didn't).
> >
> >
> > Right. Pdb doesn't step through the AST branches of a line, so ternary
> > expressions and list comprehensions and defining variables at the end of
> the
> > line are 'debugged' after they're done.
> >
> > Similarly, code coverage is line-based; so those expressions may appear
> to
> > be covered but are not.
>
> I'm not sure I follow. In what situation would some code appear to be
> covered when it isn't, due to an assignment expression?


When an assignment expression is in the else clause of a ternary
expression, but the else clause does not execute because the condition is
true, the assignment expression does not execute and so isn't covered.

if ((1) or (x := 3)):
if ((y := func(x)) if x else (x := 3))

Is this a new opportunity for misunderstanding?

Assignment expressions, though they are noticeable :=, may not actually
define the variable in cases where that part of the line doesn't run but
reads as covered.




>
> ChrisA
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> wes.turner%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

[Chris Angelico]

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 down code review -- without any
>> > real
>> > performance gain. So, while this would be useful for golfed-down (!)
>> > one-liners with pyline,
>> > I'm -1 on PEP 572.
>>
>> PEP 572 has never promised a performance gain, so "without any real
>> performance gain" is hardly a criticism.
>>
>> > How do I step through this simple example with a debugger?
>> >
>> > if re.search(pat, text) as match:
>> > print("Found:", match.group(0))
>>
>> Step the 'if' statement. It will call re.search() and stash the result
>> in 'match'. Then the cursor would be put either on the 'print' (if the
>> RE matched) or on the next executable line (if it didn't).
>
>
> Right. Pdb doesn't step through the AST branches of a line, so ternary
> expressions and list comprehensions and defining variables at the end of the
> line are 'debugged' after they're done.
>
> Similarly, code coverage is line-based; so those expressions may appear to
> be covered but are not.

I'm not sure I follow. In what situation would some code appear to be
covered when it isn't, due to an assignment expression?

ChrisA
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

[Wes Turner]

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, while this would be useful for golfed-down (!)
> > one-liners with pyline,
> > I'm -1 on PEP 572.
>
> PEP 572 has never promised a performance gain, so "without any real
> performance gain" is hardly a criticism.
>
> > How do I step through this simple example with a debugger?
> >
> > if re.search(pat, text) as match:
> > print("Found:", match.group(0))
>
> Step the 'if' statement. It will call re.search() and stash the result
> in 'match'. Then the cursor would be put either on the 'print' (if the
> RE matched) or on the next executable line (if it didn't).


Right. Pdb doesn't step through the AST branches of a line, so ternary
expressions and list comprehensions and defining variables at the end of
the line are 'debugged' after they're done.

Similarly, code coverage is line-based; so those expressions may appear to
be covered but are not.


>
> > From https://en.wikipedia.org/wiki/Assignment_(computer_science) :
> >
> >> In some languages the symbol used is regarded as an operator (meaning
> that
> >> the assignment has a value) while others define the assignment as a
> >> statement (meaning that it cannot be used in an expression).
> >
> >
> > PEP 572 -- Assignment Expressions
> > PEP 572 -- Assignment Operator (:=) and Assignment Expressions
>
> Huh? I don't get your point.


Q: What is ':='? (How do I searchengine for it?)
A: That's the assignment operator which only works in Python 3.8+.

Q: When are variables defined -- or mutable names bound -- at the end of
the expression accessible to the left of where they're defined?
Q: What about tuple unpacking? Is there an ECMAscript-like destructuring
PEP yet?
A: Ternary expressions; list, dict, generator comprehensions;
(@DOCS PLEASE HELP EXPLAIN THIS)

Q: do these examples of the assignment expression operator all work?

"""
- 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)) > 0]

- left-to-right doesn't apply to ternary expressions

  if (y := func(x)) if (x := 3) else 0:
  while (y := func(x)) if (x := 3) else 0:

- left-to-right does apply to everything else?

- *these* are discouraged:

  if (x := 3) or (y := func(x)):
  if (3) or (func(3)):

  if ((x := 3) if 1 else (y := func(x))):
"""


> ChrisA
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> wes.turner%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

[Tim Peters]

[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 Barker ]
> I'm with Raymond here -- though I'm not sure "newbies" is quite right --
> I've found that newbies fall into two camps: folks to whom programming comes
> naturally, and those that it doesn't (OK, it's a distribution, but a bimodal
> one). And folks that are struggling with programming can struggle even with
> simple assignment (name binding), particularly when you add even function
> local scope.

Sure.  What I wrote was shorthand for what's already been covered at
length many times:  what a binding expression does is "easy to
explain" GIVEN THAT someone ALREADY UNDERSTANDS how binding a name
works.  The latter in fact seems difficult for a significant number of
people to learn, but it's utterly unavoidable that they learn it if
they're ever to write non-trivial Python programs.  That's been true
since Python's first release.

Binding expressions would be introduced much later in any sane course.
At THAT point, for students who haven't already dropped out, the
semantics are darned-near trivial to explain:  it binds the name to
the object the expression evaluates to (all of which they _already_
understand by this point), and the value of the binding expression is
that object (the only new bit).

Unlike as for most other operators, you don't even have to weasel-word
it to account for that a magical dunder method may change what ":="
does.  As for the "is" operator, the meaning is baked into the
language and can't be altered in the slightest.


> So having one more way to do assignment WILL make it harder to
> teach, not because it's that hard, but because it's one more thing to learn.

On a scale of 1 to a million, try to quantify how much harder ;-)  As
above, I can't see it getting beyond a single digit, GIVEN THAT a
student has already masteredf the far more complex assignment
_statement_ (binding expressions are limited to the single simplest
case of the many things an assignment statement can do).  "And it
returns the object" is a yawn.  But, as I already granted, it may be
truly hard to explain when it's a desirable thing to use.  That takes
experience and "good judgment", which - according to me - can be
learned but can't really be taught.


> But the fact is that as Python has evolved (particularly with the jump to
> py3) it has become less and less of a "scripting" language, and more of a
> "systems" language. And also harder to learn. Anyone remember CP4E? Python
> is not as good choice as a "newbie" language as it once was.

I agree - although I expect sticking to a subset of Python could make
life easier for beginners.  For example, would anyone in their right
mind even mention async gimmicks when teaching beginners?

Against that, though, one of the most unintentionally funny tech
things I ever read was Bjarne Stroustrup writing about why C++ is an
excellent choice for beginners.  But he does have a point:  if you
throw away the bulk of everything C++ added, there's an easily usable
little language exceedingly well hidden under it all ;-)


> Adding := will move it a little bit more along the complexity path -- not
> much, and that's where Python has gone anyway, so as Tim said, no one's
> going to suffer either way this decision goes.

Yet there will be much wailing and gnashing of teeth anyway ;-)

...
>> To judge from Stackoverflow volume, the single most misunderstood of
>> all Python operators - by far - is "is" -

> You now, I think instructors like me are partly responsible. "is" is rarely
> useful outside of comparing to singletons. Yet I use it early in instruction
> to do checks on name binding and show things with mutablilty, etc which
> has the unfortunate side effect of making it seem like a more common
> operator than it is.
>
> I've even had students write code like:
>
> if x is 3:
>
> and thanks to interning, it appears to work!

Yup, that's the real problem with "is":  its semantics are dead
simple, but "but under exactly what conditions are `x` and `y` bound
to the same object?" is intractable.  It seems to take a long time to
get across the point, that the question itself is misguided.  A full
answer requires delving into transient implementation details, which
is counterproductive because they _are_ accidents of the
implementation du jour.  What questioners need to be nudged into
asking instead is for examples of when using "is" is thoroughly sane.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

[Chris Barker]

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 _desirable_ to use
> it.
>

I'm with Raymond here -- though I'm not sure "newbies" is quite right --
I've found that newbies fall into two camps: folks to whom programming
comes naturally, and those that it doesn't (OK, it's a distribution, but a
bimodal one). And folks that are struggling with programming can struggle
even with simple assignment (name binding), particularly when you add even
function local scope. So having one more way to do assignment WILL make it
harder to teach, not because it's that hard, but because it's one more
thing to learn.

But the fact is that as Python has evolved (particularly with the jump to
py3) it has become less and less of a "scripting" language, and more of a
"systems" language. And also harder to learn. Anyone remember CP4E? Python
is not as good choice as a "newbie" language as it once was.

Adding := will move it a little bit more along the complexity path -- not
much, and that's where Python has gone anyway, so as Tim said, no one's
going to suffer either way this decision goes.

Hmm -- I wonder if a "pythonscript" will get forked off one day..

To judge from Stackoverflow volume, the single most misunderstood of
> all Python operators - by far - is "is" -


You now, I think instructors like me are partly responsible. "is" is rarely
useful outside of comparing to singletons. Yet I use it early in
instruction to do checks on name binding and show things with mutablilty,
etc which has the unfortunate side effect of making it seem like a more
common operator than it is.

I've even had students write code like:

if x is 3:

and thanks to interning, it appears to work!

-CHB


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 572: Write vs Read, Understand and Control Flow

[Chris Barker]

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 among experienced C developers, it
tells us a lot.

We shouldn't add a feature that people would make a point of avoiding!

OT note:


> Now the question is which Python are allowed for babies. I recall that
> a colleague was surprised and confused by context managers. Does it
> mean that try/finally should be preferred?


well, no, because try ... finally is even more confusing -- at least that's
the impression I get from spending 20 minutes on it with newbies in my
class last night :-)



>  Or metaclasses?


metaclasses are well known to be advanced juju -- they should not (and
probably don't) show up in everyday code. Even if they are used in everyday
code, the use is usually hidden -- i.e. when a user subclasses from an ORM
model class, they are using metaclasses, but they don't have to know that.

That is -- they fall into the category of stuff that should only be used by
library/framework developers -- and, in fact, the whole point is to make
everyday code easier.

In fact, the number of developers that need to write/debug metaclasses,
context managers, decorators, is far fewer than the number of folks that
USE those things. So the standards are very different.

-CHB


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Summary of Python tracker Issues

[Python tracker]

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 with patches: 2586 


Issues opened (45)
==

#3692: improper scope in list comprehension, when used in class decla
https://bugs.python.org/issue3692  reopened by Mariatta

#32799:  returned a resul
https://bugs.python.org/issue32799  reopened by xiang.zhang

#33144: random._randbelow optimization
https://bugs.python.org/issue33144  reopened by serhiy.storchaka

#33321: Add a Linux clang ubsan undefined behavior sanitizer buildbot
https://bugs.python.org/issue33321  opened by gregory.p.smith

#33325: Optimize sequences of constants in the compiler
https://bugs.python.org/issue33325  opened by serhiy.storchaka

#33326: Convert collections (cmp_op, hasconst, hasname and others) in 
https://bugs.python.org/issue33326  opened by godaygo

#33327: Add a method to move messages to IMAPlib
https://bugs.python.org/issue33327  opened by mcepl

#33328: pdb error when stepping through generator
https://bugs.python.org/issue33328  opened by Ricyteach

#0: Better error handling in PyImport_Cleanup()
https://bugs.python.org/issue0  opened by serhiy.storchaka

#1: Clean modules in the reversed order
https://bugs.python.org/issue1  opened by serhiy.storchaka

#2: Expose valid signal set (sigfillset())
https://bugs.python.org/issue2  opened by pitrou

#3: ConfigParser.items returns items present in `DEFAULTSECT` when
https://bugs.python.org/issue3  opened by chrBrd

#5: turtle.onkey doesn't pass key information when key is None
https://bugs.python.org/issue5  opened by je1234

#6: [imaplib] MOVE is a legal command
https://bugs.python.org/issue6  opened by mcepl

#7: Provide a supported Concrete Syntax Tree implementation in the
https://bugs.python.org/issue7  opened by lukasz.langa

#8: [lib2to3] Synchronize token.py and tokenize.py with the standa
https://bugs.python.org/issue8  opened by lukasz.langa

#9: Using default encoding with `subprocess.run()` is not obvious
https://bugs.python.org/issue9  opened by pekka.klarck

#33340: Inaccurate docs on `import` behaviour
https://bugs.python.org/issue33340  opened by sam_b

#33341: python3 fails to build if directory or sysroot contains "*icc*
https://bugs.python.org/issue33341  opened by locutusofborg

#33342: urllib IPv6 parsing fails with special characters in passwords
https://bugs.python.org/issue33342  opened by benaryorg

#33343: [argparse] Add subcommand abbreviations
https://bugs.python.org/issue33343  opened by porton

#33345: Documentation for PowerShell instructions
https://bugs.python.org/issue33345  opened by stevepiercy

#33346: Syntax error with async generator inside dictionary comprehens
https://bugs.python.org/issue33346  opened by pablogsal

#33347: zlibmodule undefined reference
https://bugs.python.org/issue33347  opened by Lucian Cristian

#33348: lib2to3 doesn't parse f(*[] or [])
https://bugs.python.org/issue33348  opened by zsol

#33349: 2to3 fails to parse async generators in non-async functions
https://bugs.python.org/issue33349  opened by zsol

#33350: WinError 10038 is raised when loop.sock_connect is wrapped wit
https://bugs.python.org/issue33350  opened by Alisue Lambda

#33351: Support compiling with clang-cl on Windows
https://bugs.python.org/issue33351  opened by Ethan Smith

#33352: Windows: test_regrtest fails on installed Python
https://bugs.python.org/issue33352  opened by vstinner

#33353: test_asyncio: test_sock_sendfile_mix_with_regular_send() hangs
https://bugs.python.org/issue33353  opened by vstinner

#33354: Python2: test_ssl fails on non-ASCII path
https://bugs.python.org/issue33354  opened by vstinner

#33355: Windows 10 buildbot: 15 min timeout on test_mmap.test_large_fi
https://bugs.python.org/issue33355  opened by vstinner

#33356: Windows 10 buildbot: test__xxsubinterpreters.test_already_runn
https://bugs.python.org/issue33356  opened by vstinner

#33357: [EASY C] test_posix.test_posix_spawn_file_actions() leaks memo
https://bugs.python.org/issue33357  opened by vstinner

#33358: [EASY] x86 Ubuntu Shared 3.x: test_embed.test_pre_initializati
https://bugs.python.org/issue33358  opened by vstinner

#33360: ALternative recipe for password using secrets
https://bugs.python.org/issue33360  opened by jpc4242

#33361: readline() + seek() on io.EncodedFile breaks next readline()
https://bugs.python.org/issue33361  opened by da

#33363: async for statement is not a syntax error in sync context
https://bugs.python.org/issue33363  opened by zsol

#33365: http/client.py does not print correct headers in debug
https://bugs.python.org/issue33365  opened by mstrigl

#33366: `contextvars` documentation incorrectly refers to "non-local s

[Python-Dev] quoted text not being marking correctly [was PEP 572 really the most effective way to solve the problems it's targeting?]

[Ethan Furman]

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 is happening and resolve it.  (I have no clue so can't 
offer any ideas.)


Thanks.

--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] PEP 394: Allow the `python` command to not be installed (and other minor edits)

[Petr Viktorin]

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. (We'd rather see a future where `python` doesn't 
exist and one always has to specify `python2` or `python3`.)
- The PEP now explicitly says that in an active venv, python means that 
venv's interpreter. (Some view this as a design mistake, but one not 
worth reverting now.)


There are also other edits and clarifications.

Thanks for everyone involved, especially Guido for pitching in with the 
intended direction -- which was not clear from (or is genuinely 
different from) the 7-year-old PEP!


I'll keep the PR open for a day or so, in case someone still wants to 
comment.


[Pull Request]: https://github.com/python/peps/pull/630


On 04/26/18 19:21, Ben Finney wrote:

Petr Viktorin  writes:


In Fedora, I found that PEP 394's strict recommendation that `python`
points to `python2` is holding us back.


I have read the message, but I don't see how you draw the link that PEP
394 is holding you back.


The problems are:
- For developers that are not following the language's development,
the fact that `python` invokes `python2` sends a strong signal that 2
is somehow the preferred version, and it's OK to start new projects in
it.


I agree with the statement you make later in the message:


[…] 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 reasons you say. There
should be ‘python2’ and ‘python3’ commands for Python 2 and Python 3
respectively, and no ‘python’ command should be installed by the
operating system.

The fact that ‘/usr/bin/python’ exists is an historical accident, and I
agree with the proposal you state: the best way to correct the confusion
is to bar the confusing command from being installed by packages.


- Users and sysadmins that *do* want to “live in the future” are
switching the symlink to `python3` themselves. We would like to give
them a supported, documented way to do so -- and make surer they're
aware of the caveats.


The supported, documented way to add a command pointing to a different
command already exists, and there is no need to make a Python-specific
special case.

Users who want to make a ‘python’ alias can do so in their shell; this
is supported and documented.

Users who want to add a new command file can add a suitable directory
(e.g. ‘$HOME/bin’) to their ‘PATH’ variable, and put a symlink in there
named ‘python’. This is supported and documented.

Sysadmins who want to create a system-wide command ‘python’ can put a
symlink at ‘/usr/local/bin/python’. This is supported and documented.

I disagree with making some special-case extra way; that would be both
cunfusing and superfluous.


- The `python` command is still not available out-of-the box on macOS,
so it didn't completely live up to the expectation of being the
cross-platform way to launch 2/3 source compatile scripts.


That is one of the minor ways which macOS fails to conform to
community-agreed conventions. We should not let that intransigence
distort our discussion of best practices.


To help solve these, I would like to relax recommendations on the Unix
``python -> python2`` symlink in these cases:


For the above reasons, I disagree that PEP 394 is limiting what you want
to do on free-software operating systems.

For non-free operating systems, I don't think the already-discussed PEP
394 should be weakened if the operating system vendor fails to conform.


- Users and administrators can, by a deliberate action, change
``python`` to invoke Python 3.


Yes. That is well-known and long-standardised on Unix operating systems,
and is much more broadly understood than any Python-specific special
case would be. So I don't see how anyone is being held back.

I trust that PEP 394 will not be weakened in its effect, and I wish you
well with using the already-supported, already-documented, PEP-394
compatible means to add local customisations for a ‘python’ command.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 394 update proposal: Allow changing the `python` command in some cases

[Petr Viktorin]

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 reasons you say. There
should be ‘python2’ and ‘python3’ commands for Python 2 and Python 3
respectively, and no ‘python’ command should be installed by the
operating system.

The fact that ‘/usr/bin/python’ exists is an historical accident, and I
agree with the proposal you state: the best way to correct the confusion
is to bar the confusing command from being installed by packages.


Because the above is ambiguous, I'll clarify: I am not calling for, and
PEP 394 does not call for, the banishment of the ‘python’ command.


Well, Guido *is* calling for it :)
It would break too many things, but after discussions on the PR, it's 
clear that we want a future where the "python" doesn't exist.

But while it's available, it should point to Python 2.


What I'm saying is that muddying the rules further on what ‘python’ may
or may not mean is *worse than* banishing the ‘python’ command entirely.


That's also consistent with the PR discussion. (But not that much with 
the original PEP, which said `python` is expected to eventually mean 
`python3`.)



So, short of banishing ‘python’ entirely, I think PEP 394 is already a
good clear way to address the issue. Existing, documented and supported
means to locally modify a ‘python’ command already exist and should be
sufficient.


I trust that PEP 394 will not be weakened in its effect, and I wish you
well with using the already-supported, already-documented, PEP-394
compatible means to add local customisations for a ‘python’ command.


Right. But some already-supported, already-documented mechanisms like 
Debian Alternatives or alternate package repos, are not compatible with 
PEP 394.
And as a PEP 394 compliant distro, we also won't be promoting the 
/usr/local or $HOME/bin ways to change `python` (which makes me a bit 
sad, because that documentation might have included a link to the 
caveats listed in the PEP).


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] (Looking for) A Retrospective on the Move to Python 3

[Eric Snow]

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 motivations, decisions, and challenges.
> While I've pieced some of that together over the years now since I've
> been around, I've certainly seen much of the aftermath.  For me, at
> least, it would be helpful to have a bit more insight into the
> history. :)

Thanks, all, for the responses. :)

-eric
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Reserve ':=' for type-inferred variable initialization (was PEP 572)

[Eric V. Smith]

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 missed something.)


Presumably dataclasses and typing.NamedTuple.

Eric
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

[Chris Angelico]

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 pyline,
> I'm -1 on PEP 572.

PEP 572 has never promised a performance gain, so "without any real
performance gain" is hardly a criticism.

> How do I step through this simple example with a debugger?
>
> if re.search(pat, text) as match:
> print("Found:", match.group(0))

Step the 'if' statement. It will call re.search() and stash the result
in 'match'. Then the cursor would be put either on the 'print' (if the
RE matched) or on the next executable line (if it didn't).

> From https://en.wikipedia.org/wiki/Assignment_(computer_science) :
>
>> In some languages the symbol used is regarded as an operator (meaning that
>> the assignment has a value) while others define the assignment as a
>> statement (meaning that it cannot be used in an expression).
>
>
> PEP 572 -- Assignment Expressions
> PEP 572 -- Assignment Operator (:=) and Assignment Expressions

Huh? I don't get your point.

ChrisA
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Reserve ':=' for type-inferred variable initialization (was PEP 572)

[Nick Coghlan]

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 -- maybe I have missed something.)
>

Data classes rely on the presence of annotations to spot field declarations
(it mostly doesn't care what those annotations actually say, but it does
need them to be present in order to create the list of field names).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] (Looking for) A Retrospective on the Move to Python 3

[Victor Stinner]

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 always emit a warning (at runtime) in the
previous release.

For example, "async" and "await" have been marked as deprecated in
Python 3.5, before becoming real keywords in Python 3.6. Then people
complained that they didn't see the warning which is hidden by
default, but that's another topic :-) (This issue is partially solved
in Python 3.7 with Nick's PEP 565 and my -X dev option).

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 syscalls interrupted by signals, PEP
co-written with Charles-François Natali) introduced backward
incompatible changes in Python 3.4 and 3.5. I am aware that they broke
a few applications, but it was possible to manage these issues because
each release only introduced a few backward incompatible changes.

The main issue is the deprecation process. Should we provide tools to
automatic conversion? Should we only document the deprecation, or also
emit a warning at runtime? Should the warning be displayed by default?

It's also a matter of collaboration with the Python community. For
example, help major Python projects to handle these changes. Nobody
wants to see pip broken by the next Python release for example. It
seems like we are already working closely with pip, Cython and numpy,
for example.

IMHO queuing backward incompatible changes until Python 4 is a very
bad idea. Start to break things early :-) But always follow the
deprecation process. If my vote counts, Python 4.0 should just be the
version following the previous Python 3.x release, as the Linux kernel
is now doing (Linux 3 and Linux 4 are just regular release, they don't
break everything.)

Note: Another option is to never introduce backward incompatible
changes, no? ;-)

Victor
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Is PEP 572 really the most effective way to solve the problems it's targeting?

[Ryan Gonzalez]

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 mentioned), Kotlin, Rust, and perhaps Go,
though Go wasn't focused on breaking new ground outside of ease of concurrency.
I don't know R or Felix at all, but sound interesting.  Nim is another I'm
vaguely aware of.  They surely have given some thought to the issue.

One thing that jumped out at me is that most replies here jumped to the 
question
of whether they supported assignment-expressions, but that is only one 
potential
solution.  To be more clear, I wondered how did they solve "the problem 
itself?"

Was their solution different?  Ryan somewhat alluded to that, but I'd like to
dig in a bit on that part.

In contrast, in many of the other threads I heard, "C, C++, C#, Java, etc do
assignment-expressions, they're useful and not so hard to learn."  Ok that's
reasonable, but where is the industry headed?  Python deferred long enough that
we don't necessarily have to choose a classic solution.

So, it sounds like many of the new generation of languages are not embracing
these expressions everywhere but rather letting folks do an assignment right in
the statement where their use case applies, if, while, maybe 
comprehensions.  Is

that accurate?

This is basically what I was trying to say, except far better worded...


Looks like I've got some homework to do, haha.

-Mike


On 2018-04-26 17:58, Steven D'Aprano wrote:
What counts as a modern language? Less than five years old? Less than
fifty years old? Are Javascript, Ruby and R modern? They all support
assignment as expressions.

I think Koitlin, Rust and Go prohibit assignment as expressions.

Swift assignment evaluates as Void (equivalent to None in Python, I
guess), so you can use assignment in an expression but it returns
nothing and only operates by side-effect.

As far as type hints go, I think that if you need explicit type hints in
the middle of an expression, it's a bad idea and you ought to pull it
out as a separate statement. That applies regardless of whether that
expression involves binding or not.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com


--
Ryan (ライアン)
Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else
https://refi64.com/


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] PEP 575 (Unifying function/method classes) update

[Jeroen Demeyer]

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).


* __objclass__ was generalized to __parent__ and stores either the 
defining class or the defining module of a built-in function/method.


* Proposed two-phase implementation for better backwards compatibility 
(at the cost of added complexity).


The first two items on the above list are meant to prepare for PEP 573 
but are sufficiently useful by itself to add them to PEP 575.


On this mailing list, there have been concerns about backwards 
compatibility. This PEP does indeed affect code not using duck typing, 
but using type checks or things like inspect.isbuiltin(). Note that 
"affect" != "break". I don't know how bad this presumed breakage is. 
Personally, I think it will be acceptable, but others may disagree. What 
I *do* know for sure is that very little breaks in the Python standard 
library. If anybody has a clever idea to estimate the breakage, I would 
love to know.



Jeroen.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Reserve ':=' for type-inferred variable initialization (was PEP 572)

[Steven D'Aprano]

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 annotation discussion I started to worry this wasn't 
> indeed the case (why the urge of repeating it so much otherwise?).

Only because people keep worrying about it. If we don't deny it, people 
will think our failure to deny it means it will happen. If we do deny 
it, they think that our repeated denials means it will happen. We're 
damned whatever we do.


> 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 missed something.)


> and a little shift towards a "not now" position.

If you're referring to my comment above about "Python 5 or Python 6", 
perhaps I should have followed my first instinct and written "Python 
5000". You know, the Python we get in the year 5000 :-)

Guido has said that Python will never *require* type-annotations and 
static type-checking, and I see no reason to doubt that. But this 
doesn't rule out a hypothetical runtime option (hence, *optional*) to 
enforce static type-safety some time in the future.

Personally I doubt this will happen: mypy is a non-trivial project 
itself, by my estimate about 200 .py files, 77000 lines of text, about 
60 kloc, and I don't think Guido wants to build it into the reference 
Python interpreter. And why bother, when it is so easy to add a single 
dependency (mypy) and integrate it with your work-flow?

My point was that reserving syntax for such a hypothetical future Python 
is a waste of time. Even if it happens, which it probably won't, it 
won't happen any time soon. By the time this hypothetical future rolls 
around, who knows what syntax we'll want?


-- 
Steve
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] (Looking for) A Retrospective on the Move to Python 3

[Serhiy Storchaka]

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/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] (Looking for) A Retrospective on the Move to Python 3

[Wes Turner]

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, decisions, and challenges.
> While I've pieced some of that together over the years now since I've
> been around, I've certainly seen much of the aftermath.  For me, at
> least, it would be helpful to have a bit more insight into the
> history. :)
>
> With that in mind, it would be worth having an informational PEP with
> an authoritative retrospective on the lessons learned from the Python
> 3 effort (and transition).  Consider it a sort of autobiography,
> "memoirs on the python-dev change to Python 3". :)  At this point the
> transition has settled in enough that we should be able to present a
> relatively objective (and consistent) view, while we're not so far
> removed that we've forgotten anything important. :)  If such a
> document already exists then I'd love a pointer to it.
>
> The document would benefit (among others):
>
> * python-dev (by giving us a clear viewpoint to inform decisions about
> future releases)
> * new-comers to Python that want more insight into the language
> * folks transitioning from 2 to 3
> * communities that have (or think they have) problems similar to those
> we faced in Python 2
>
> The PEP doesn't even have to be done all at once, nor by one person.
> In fact, there are many viewpoints that would add value to the
> document.  Hence it would probably make sense to encourage broad
> participation and then have a single editor to effect a single voice
> in the document.
>
> The contents of the retrospective document should probably cover a
> broad range of topics, since there's so much to learn from the move to
> Python 3.  To give an indication of what I mean, I've included a rough
> outline at the bottom of this message.
>
> So...I typically strongly avoid making proposals that I'm not willing
> to execute.  However, in this case I simply do not have enough
> experience in the history to feel comfortable doing a good job of it
> in a reasonable amount of time (which matters due to the tendency of
> valuable info to fade away). :/  I have no expectation that someone
> will pick this up, though I do hope since the benefit would be
> significant.  My apologies in advance if this wasted anyone's time.
>
> -eric
>
>
> 
>
> I'd hope to see something along the lines of (at least) the following,
> in rough order:
>
> * a concise summary of the document at the top (very meta, I know :) )
>   + what were we solving?
>   + what was the solution?
>   + why do it that way?
>   + what went right?
>   + what went wrong?
>   + impact on the community
>   + impact on core dev contribution
> * timeline
> * key players (and level of involvement)
>   + old guard core devs
>   + new guard
>   + folks brought on for Py3k (e.g. IIRC a swarm of Googlers dove in)
>   + non-core-devs
> * motivations
> * expectations (e.g. time frames, community reaction)
> * corresponding results
> * a summary of what we did


nine has a very concise, if incomplete in comparison to six and 2to3,
code/namespace/functional summary:
https://github.com/nandoflorestan/nine/blob/master/nine/__init__.py

https://github.com/benjaminp/six/blob/master/six.py

http://python-future.org/overview.html#automatic-conversion-to-py2-3-compatible-code

> python-future comes with two scripts called futurize and pasteurize to
aid in making Python 2 code or Python 3 code compatible with both platforms
(Py2/3). It is based on 2to3 and uses fixers from lib2to3, lib3to2, and
python-modernize, as well as custom fixers

"Cheat Sheet: Writing Python 2-3 compatible code"
http://python-future.org/compatible_idioms.html

https://github.com/PythonCharmers/python-future

> It provides future and past packages with backports and forward ports of
features from Python 3 and 2.


> * alternative approaches


#!/usr/bin/env python
# ~~✓pythonver: > 3.3✓~~


> * what went right (and was it on purpose :) )
> * what went wrong (e.g. io) and why
> * how the Py3k project differed from normal python-dev workflow (e.g.
> pace, decision-making, communications)
> * lasting impact of python-dev
> * key things that would have been better if done differently
> * key decisions/planning (mostly a priori to the release work)
>   + scope of backward compatibility
>   + process (using PEPs with PEPs 30xx guiding)
>   + schedule
>   + specific changes (i.e. PEPs 31xx)
>   + what was left out (and why)
>   + plans to help library and app authors transition (e.g. 2to3)
>   + feature/schedule overlap with Python 2 (i.e. 2.6 and 2.7)
>   + the language moratorium
> * things that got missed and why
>   + unicode/bytes in some stdlib modules (and builtins?)
> * things that were overdone (and how that got missed)
>   

Re: [Python-Dev] (Looking for) A Retrospective on the Move to Python 3

[Victor Stinner]

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 migration
simpler, etc.

Victor

2018-04-26 18:25 GMT+02:00 Eric Snow :
> 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, decisions, and challenges.
> While I've pieced some of that together over the years now since I've
> been around, I've certainly seen much of the aftermath.  For me, at
> least, it would be helpful to have a bit more insight into the
> history. :)
>
> With that in mind, it would be worth having an informational PEP with
> an authoritative retrospective on the lessons learned from the Python
> 3 effort (and transition).  Consider it a sort of autobiography,
> "memoirs on the python-dev change to Python 3". :)  At this point the
> transition has settled in enough that we should be able to present a
> relatively objective (and consistent) view, while we're not so far
> removed that we've forgotten anything important. :)  If such a
> document already exists then I'd love a pointer to it.
>
> The document would benefit (among others):
>
> * python-dev (by giving us a clear viewpoint to inform decisions about
> future releases)
> * new-comers to Python that want more insight into the language
> * folks transitioning from 2 to 3
> * communities that have (or think they have) problems similar to those
> we faced in Python 2
>
> The PEP doesn't even have to be done all at once, nor by one person.
> In fact, there are many viewpoints that would add value to the
> document.  Hence it would probably make sense to encourage broad
> participation and then have a single editor to effect a single voice
> in the document.
>
> The contents of the retrospective document should probably cover a
> broad range of topics, since there's so much to learn from the move to
> Python 3.  To give an indication of what I mean, I've included a rough
> outline at the bottom of this message.
>
> So...I typically strongly avoid making proposals that I'm not willing
> to execute.  However, in this case I simply do not have enough
> experience in the history to feel comfortable doing a good job of it
> in a reasonable amount of time (which matters due to the tendency of
> valuable info to fade away). :/  I have no expectation that someone
> will pick this up, though I do hope since the benefit would be
> significant.  My apologies in advance if this wasted anyone's time.
>
> -eric
>
>
> 
>
> I'd hope to see something along the lines of (at least) the following,
> in rough order:
>
> * a concise summary of the document at the top (very meta, I know :) )
>   + what were we solving?
>   + what was the solution?
>   + why do it that way?
>   + what went right?
>   + what went wrong?
>   + impact on the community
>   + impact on core dev contribution
> * timeline
> * key players (and level of involvement)
>   + old guard core devs
>   + new guard
>   + folks brought on for Py3k (e.g. IIRC a swarm of Googlers dove in)
>   + non-core-devs
> * motivations
> * expectations (e.g. time frames, community reaction)
> * corresponding results
> * a summary of what we did
> * alternative approaches
> * what went right (and was it on purpose :) )
> * what went wrong (e.g. io) and why
> * how the Py3k project differed from normal python-dev workflow (e.g.
> pace, decision-making, communications)
> * lasting impact of python-dev
> * key things that would have been better if done differently
> * key decisions/planning (mostly a priori to the release work)
>   + scope of backward compatibility
>   + process (using PEPs with PEPs 30xx guiding)
>   + schedule
>   + specific changes (i.e. PEPs 31xx)
>   + what was left out (and why)
>   + plans to help library and app authors transition (e.g. 2to3)
>   + feature/schedule overlap with Python 2 (i.e. 2.6 and 2.7)
>   + the language moratorium
> * things that got missed and why
>   + unicode/bytes in some stdlib modules (and builtins?)
> * things that were overdone (and how that got missed)
>   + unicode/bytes in some stdlib modules (and builtins?)
> * (last but not least) challenges faced by folks working to transition
> their exiting code to Python 3
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> https://mail.python.org/mailman/options/python-dev/vstinner%40redhat.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 

Re: [Python-Dev] (Looking for) A Retrospective on the Move to Python 3

[Nick Coghlan]

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 whole
>>> Py3k effort predates my involvement in the community so I missed a
>>> bunch of context about the motivations, decisions, and challenges.
>>> While I've pieced some of that together over the years now since I've
>>> been around, I've certainly seen much of the aftermath.  For me, at
>>> least, it would be helpful to have a bit more insight into the
>>> history. :)
>
> It would certainly be an interesting document, but I suspect you’ll get a bit 
> of the old “ask 3 lawyers and get 5 opinions” kind of response. ;)

http://python-notes.curiousefficiency.org/en/latest/python3/questions_and_answers.html
covers some of the questions Eric is asking (mostly from my PoV, but
Guido corrected my answer to the initial "Why was Python 3 made
incompatible with Python 2?" question shortly after I posted the first
version of it).

https://www.curiousefficiency.org/posts/2014/08/python-4000.html is a
more retrospective-y article that looks more at the implications for
Python 4.

For the "What actually happened?" info, probably the 3 main documents
to look at would be PEP 3000 (the process doc), PEP 3100 (accepted
changes that didn't get their own PEPs), and PEP 3099 (explicitly
rejected ideas that also didn't get their own PEPs).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

[Wes Turner]

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)) > 0]

- left-to-right doesn't apply to ternary expressions

  if (y := func(x)) if (x := 3) else 0:
  while (y := func(x)) if (x := 3) else 0:

- left-to-right does apply to everything else?

- *these* are discouraged:

  if (x := 3) or (y := func(x)):
  if (3) or (func(3)):
  if ((x := 3) if 1 else (y := func(x))):

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 pyline,
I'm -1 on PEP 572.

How do I step through this simple example with a debugger?

if re.search(pat, text) as match:
print("Found:", match.group(0))

How do I explain what ':=' is when teaching Python?

AFAIU, semantically: Python = ('equals') indicates a statement. What you
are proposing is adding an ':=' ('colon equals') assignment operator which
defines a variable which is limited in scope only in list, dict, and
generator comprehensions.

>From https://en.wikipedia.org/wiki/Assignment_(computer_science) :

> In some languages the symbol used is regarded as an operator (meaning
that the assignment has a value) while others define the assignment as a
statement (meaning that it cannot be used in an expression).


PEP 572 -- Assignment Expressions
PEP 572 -- Assignment Operator (:=) and Assignment Expressions

On Friday, April 27, 2018, Steven D'Aprano  wrote:

> On Thu, Apr 26, 2018 at 08:48:12AM -0700, Łukasz Langa wrote:
> >
> > > On Apr 25, 2018, at 11:10 PM, Steven D'Aprano 
> wrote:
> > > Criticising binding-
> > > expressions for that reason, especially implying that we must always
> use
> > > parens, is simply FUD.
> >
> > The PEP has more examples with parentheses than without.
>
> Yes? Parens aren't mandatory, and my point that other operators also
> sometimes needs parens still holds.
>
>
> > >> As soon as we have to wrap a part of an expression in parentheses,
> > >> parsing the entire thing becomes more complex.
> > >
> > > Unless it becomes less complex to read and understand.
> >
> > You're ignoring the context of the discussion. The new parentheses are
> > there because there's a new assignment there. That's more complex.
>
> I'm not ignoring the context of the discussion. I'm comparing binding-
> expression with and without parens. That's what I thought you were
> doing.
>
> If that wasn't your intended meaning, then I apologise but please
> understand why I answered the way I did.
>
> I still stand by my argument: parens are not always needed, and even
> when they are not needed, adding them can sometimes make things
> *easier* and *less complex* to read.
>
>
> [...]
> > If you think demonstrating cases where the end result won't be an
> > improvement is picking at straws, then maybe the improvement of PEP
> > 572 is as well.
>
> Any feature can have cases where the end result is worse than not using
> the feature. That *alone* isn't a strong argument against a feature.
>
> Do you have much existing code using binding expressions? Of course not.
> Will you be adding them to code that already exists? Probably not -- you
> can't do so until you are using 3.8 at minimum, and if your code needs
> to be backwards compatible, you can't use it until you've dropped
> support for 3.7 and older. That might not be for five or ten years.
>
> So it is likely that for most people only new code will use this
> feature. It is not reasonable to say that if I have existing code like
> this:
>
> spam = expression
> if long_condition_that_takes_up_most_of_the_line == spam or spam:
> ...
>
> that I'm going to immediately change it to a one-liner:
>
> if long_condition_that_takes_up_most_of_the_line == (spam :=
> expression) or spam:
> ...
>
> and push it over the maximum line width. With or without parentheses.
> Why would I do something so silly? Using binding expressions isn't
> mandatory and most coders don't intentionally do things that make their
> code worse.
>
> And if I wouldn't change existing code and push it over the limit, why
> would I write new code that does it? Especially when there are much
> better alternatives:
>
> if (long_condition_that_takes_up_most_of_the_line
> == (spam:=expression)
> or spam):
> ...
>
>
> We have a history of adding features that can be abused, but aren't.
> People hardly ever abuse list comps with overly long and complex
> multiple-loop comprehensions:
>
> [... for a in sequence for b in something for c in another for d in
> something_else]
>
> I'm sure we've all seen one or two of those. But it 

Re: [Python-Dev] Order of positional and keyword arguments

[Antoine Pitrou]

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 surprising.  If you write f(b=2, a=1), you are
also passing arguments "not in order", but it still looks ok to me.

> 2. Argument values are evaluated not from left to right. This 
> contradicts the general rule that expressions are evaluated from left to 
> right (with few known exceptions).

Well... If you have code that relies on that rule, I would agree it's
brittle code and should be rewritten differently (perhaps by assigning
to temporary variables explicitly).

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Order of positional and keyword arguments

[Chris Jerdonek]

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 not from left to right. This contradicts
> the general rule that expressions are evaluated from left to right (with few
> known exceptions).
>
> I never seen the form `f(b=2, *[1])` in practice (though the language
> reference contains an explicit example for it), and it looks weird to me. I
> don't see reasons of writing `f(b=2, *[1])` instead of more natural `f(*[1],
> b=2)`. I propose to disallow it.

Coincidentally, I recently came across and reviewed a PR to Django
that proposed exactly this, or at least something very similar. They
proposed changing--

def create_cursor(self, name=None):
to--
def create_cursor(self, name=None, *args, **kwargs):

https://github.com/django/django/pull/9674/files#diff-53fcf3ac0535307033e0cfabb85c5301R173

--Chris



>
> This will also make the grammar simpler. Current grammar:
>
>argument_list: `positional_arguments` ["," `starred_and_keywords`]
> :   ["," `keywords_arguments`]
> : | `starred_and_keywords` ["," `keywords_arguments`]
> : | `keywords_arguments`
>positional_arguments: ["*"] `expression` ("," ["*"] `expression`)*
>starred_and_keywords: ("*" `expression` | `keyword_item`)
> : ("," "*" `expression` | "," `keyword_item`)*
>keywords_arguments: (`keyword_item` | "**" `expression`)
> : ("," `keyword_item` | "," "**" `expression`)*
>keyword_item: `identifier` "=" `expression`
>
> Proposed grammar:
>
>argument_list: `positional_arguments` ["," `keywords_arguments`]
> : | `keywords_arguments`
>positional_arguments: ["*"] `expression` ("," ["*"] `expression`)*
>keywords_arguments: `keyword_argument` ("," `keyword_argument`)*
>keyword_argument: `identifier` "=" `expression` | "**" `expression`
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/chris.jerdonek%40gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Every Release Can Be a Mini "Python 4000", Within Reason (was (name := expression) doesn't fit the narrative of PEP 20)

[Greg Ewing]

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, bigger even than making "print" no longer a
statement. It seems like there should be more justification
for it than "well, it became redundant with :=".

How would you complete the following sentence? "The ':='
symbol is a much better symbol for assignment than '=',
because..."

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Reserve ':=' for type-inferred variable initialization (was PEP 572)

[Greg Ewing]

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 language, but I can't see a smooth way to get there
from existing Python.

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Reserve ':=' for type-inferred variable initialization (was PEP 572)

[Andrea Griffini]

>> 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 annotation
discussion I started to
worry this wasn't indeed the case (why the urge of repeating it so much
otherwise?).

Now we got standard library features requiring type annotation and a little
shift
towards a "not now" position.

I'm just wondering... I'm NOT saying this would be bad (or good).


On Fri, Apr 27, 2018 at 2:36 AM, Steven D'Aprano 
wrote:

> Hi Fatty, and welcome!
>
> On Thu, Apr 26, 2018 at 08:00:55PM +0200, Fatty Morgan wrote:
>
> > The natural interpretation of 'name := expr' is a PEP 526
> > type-annotated variable initialization 'name : T = expr' with the
> > type annotation T omitted, the tokens ':' and '=' coalesced, and
> > the implied type T inferred as 'type(expr)'.
>
> I'm not sure why you say that is the "natural" interpretation,
> unless you're saying that Guido, Chris, myself and dozens of other
> people taking part of this conversation are unnatural, since none of us
> thought of that interpretation *smiles*
>
> The := token is the second most common assignment operator in
> programming languages, behind only = single equals sign. For those of us
> who were raised on Pascal, it is entirely natural to use = for equality
> tests and := for assignment, and languages that use == for equality are
> the ones which are weird.
>
> Since type-annotations are still only used by a small proportion of
> Python code and Python developers, I doubt that they will jump to the
> interpretation of "explicit type hint with no type given".
>
> If the type-checker can infer the type of the expression, there's no
> need to use the colon at all.
>
> name := expression  # can infer type here
> name = expression  # why not just infer the type here?
>
> So using : Type without the type is entirely unnecessary. The colon is
> only needed when you have to specify a type manually.
>
> Your comments about some entirely hypothetical "Python with enforced
> static typing" are interesting but so blue-sky that I honestly doubt
> that there's any point in discussing them now. We're focused on Python
> 3.8 and 3.9, not Python 5 or Python 6.
>
>
> --
> Steve
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> agriff%40tin.it
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] (Looking for) A Retrospective on the Move to Python 3

[Ethan Furman]

On 04/26/2018 09:02 PM, Alex Walters wrote:


http://pyvideo.org/pycascades-2018/bdfl-python-3-retrospective.html link to 
Guido’s talk, for your convenience


Many thanks!

--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 394 update proposal: Allow changing the `python` command in some cases

[Ben Finney]

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 reasons you say. There
> should be ‘python2’ and ‘python3’ commands for Python 2 and Python 3
> respectively, and no ‘python’ command should be installed by the
> operating system.
>
> The fact that ‘/usr/bin/python’ exists is an historical accident, and I
> agree with the proposal you state: the best way to correct the confusion
> is to bar the confusing command from being installed by packages.

Because the above is ambiguous, I'll clarify: I am not calling for, and
PEP 394 does not call for, the banishment of the ‘python’ command.

What I'm saying is that muddying the rules further on what ‘python’ may
or may not mean is *worse than* banishing the ‘python’ command entirely.

So, short of banishing ‘python’ entirely, I think PEP 394 is already a
good clear way to address the issue. Existing, documented and supported
means to locally modify a ‘python’ command already exist and should be
sufficient.

> I trust that PEP 394 will not be weakened in its effect, and I wish you
> well with using the already-supported, already-documented, PEP-394
> compatible means to add local customisations for a ‘python’ command.

-- 
 \   “Try to learn something about everything and everything about |
  `\  something.” —Thomas Henry Huxley |
_o__)  |
Ben Finney

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com