Re: [Python-Dev] PEP 572 contradicts PEP 3099

[Chris Angelico]

On Sun, Apr 29, 2018 at 1:11 PM, Alex Walters  wrote:
>
>
>> -Original Message-
>> From: Python-Dev > list=sdamon@python.org> On Behalf Of Greg Ewing
>> Sent: Saturday, April 28, 2018 10:53 PM
>> To: 'Python-Dev' 
>> Subject: Re: [Python-Dev] PEP 572 contradicts PEP 3099
>>
>> Alex Walters wrote:
>> > PEP 3099 is the big list of things that will not happen in Python 3.
>> >
>> > "There will be no alternative binding operators such as :=."
>>
>> The thread referenced by that is taling about a different issue,
>> i.e. using a different symbol to rebind names in an outer scope.
>>
>
> Yeah, that's not really the issue, if there is an issue - just the wording
> of direct assertion.  I'm just adding to the list of things that need to be
> touched if 572 is accepted, and that includes clarifying what was meant by
> that.

I'm not sure that it matters. PEP 3099 states a number of changes that
were not going to happen in Python 3000, which we now know as Python
3.0. That's still true even if Python 3.8 gains a feature. (Though
most of the rejected proposals are sufficiently backward-incompatible
that they're almost certainly going to remain rejected.)

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] PEP 572 contradicts PEP 3099

[Alex Walters]

> -Original Message-
> From: Python-Dev  list=sdamon@python.org> On Behalf Of Greg Ewing
> Sent: Saturday, April 28, 2018 10:53 PM
> To: 'Python-Dev' 
> Subject: Re: [Python-Dev] PEP 572 contradicts PEP 3099
> 
> Alex Walters wrote:
> > PEP 3099 is the big list of things that will not happen in Python 3.
> >
> > "There will be no alternative binding operators such as :=."
> 
> The thread referenced by that is taling about a different issue,
> i.e. using a different symbol to rebind names in an outer scope.
> 

Yeah, that's not really the issue, if there is an issue - just the wording
of direct assertion.  I'm just adding to the list of things that need to be
touched if 572 is accepted, and that includes clarifying what was meant by
that.

> --
> 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/tritium-
> list%40sdamon.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] PEP 572 contradicts PEP 3099

[Greg Ewing]

Alex Walters wrote:

PEP 3099 is the big list of things that will not happen in Python 3.

"There will be no alternative binding operators such as :=."


The thread referenced by that is taling about a different issue,
i.e. using a different symbol to rebind names in an outer scope.

--
Greg
___
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

[Antoine Pitrou]

On Fri, 27 Apr 2018 14:13:32 +0200
Victor Stinner  wrote:
> 
> I don't think that having Python X.Y which introduces backward
> incompatible changes is an issue by itself. We did it multiple times
> during the Python 3 cycle: my PEP 446 (non-inheritable file
> descriptors) and PEP 475 (retry syscalls interrupted by signals, PEP
> co-written with Charles-François Natali) introduced backward
> incompatible changes in Python 3.4 and 3.5.

You're comparing apples and oranges.  PEP 446 and PEP 475 are only
noticeable by programmers of low-level system and I/O routines (*I*
haven't noticed them, for example, though I did quite a bit of network
programming with Python), while the changes introduced by Python 3
affect pretty much everyone, even people who only write small simple
scripts.

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] PEP 572: Usage of assignment expressions in C

[Antoine Pitrou]

On Fri, 27 Apr 2018 09:49:33 -0700
Chris Barker  wrote:
> On Tue, Apr 24, 2018 at 2:21 AM, Victor Stinner  wrote:
> 
> > Even if the C language allows assignments in if, I avoid them, because
> > I regularly have to debug my own code in gdb ;-)
> >  
> 
> I personally haven't written a lot of C, so have no personal experience,
> but if this is at all a common approach among experienced C developers, it
> tells us a lot.

I think it's a matter of taste and personal habit.  Some people will
often do it, some less.  Note that C also has a tendency to make it
more useful, because doesn't have exceptions, so functions need to
(ab)use return values when they want to indicate an error.  When you're
calling such functions (for example I/O functions), you routinely have
to check for special values indicating an error, so it's common to see
code such as:

  // Read up to n bytes from file descriptor
  if ((bytes_read = read(fd, buf, n)) == -1) {
  // Error occurred while reading, do something
  }


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

[Python-Dev] PEP 572 contradicts PEP 3099

[Alex Walters]

PEP 3099 is the big list of things that will not happen in Python 3.
Everything on that list is still true, 12 years after it was posted.
However...

"There will be no alternative binding operators such as :=."

While earlier versions of PEP 572 avoided breaking this declaration, the
current version does not.  Now, this isn't a major issue or anything - if
572 is accepted, that section of 3099 would just need a note added (or just
be removed).  I don't want this message to impact the fate of 572.

___
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

[INADA Naoki]

On Sat, Apr 28, 2018 at 10:36 AM Greg Ewing 
wrote:

> Victor Stinner wrote:
> > In my opinion, the largest failure of Python 3 is that we failed to
> > provide a smooth and *slow* transition from Python 2 and Python 3.

> Although for some things, such as handling of non-ascii text, it's
> hard to see how a smooth transition *could* have been achieved.
> Is it a failure if we don't succeed in doing the impossible?


I don't think it's your (I'm not core developer at the time) failure.
On the other hand, we should avoid many changes (e.g. bytes[index])
when doing such big change next time.

-- 
INADA Naoki  
___
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

[Matěj Cepl]

On 2018-04-28, 01:33 GMT, Greg Ewing wrote:
>> In my opinion, the largest failure of Python 3 is that we 
>> failed to provide a smooth and *slow* transition from Python 
>> 2 and Python 3.
>
> Although for some things, such as handling of non-ascii text, it's
> hard to see how a smooth transition *could* have been achieved.
> Is it a failure if we don't succeed in doing the impossible?

+1

My experience told me that by far the biggest problem in porting 
M2Crypto was dealiing with complete mess which was whole 
string/bytes confusioin in py2k. I don't see how it could be 
overcame gradually.

Matěj
-- 
https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
 
In those days spirits were brave, the stakes were high, men were
real men, women were real women and small furry creatures from
Alpha Centauri were real small furry creatures from Alpha
Centauri.
-- Douglas Adams

___
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 9:18 PM, Ned Batchelder  wrote:
> It's entirely true that binding expressions don't change this situation at
> all, EXCEPT that the entire point of binding expressions is to be able to
> express in one statement what used to take more than one.  With binding
> expressions, actions may be coverage-hidden within one statement that
> without them would have been coverage-visible in more than one statement.

So far, all the examples in the PEP have the exact same coverage with
and without assignment expressions, with a few exceptions where
coverage is *improved* by them (where the alternative is to duplicate
a function call). By combining multiple lines into one, we also ensure
that all of it is executed exactly once, instead of having conditional
execution.

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

[Ned Batchelder]

On 4/27/18 5:28 PM, Tres Seaver wrote:

On 04/27/2018 05:11 PM, Tim Peters wrote:


In this specific case, line-oriented coverage tools have missed
accounting for all possible code paths since day #1; e.g.,

x = f() or g()

You don't need to reply to messages so obviously irrelevant to the PEP
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.




Coverage.py can measure branch coverage, but it is still line-oriented.  
There's no support for conditionals and branches within a line (though 
I've done some wicked hacks to experiment with it: 
https://nedbatchelder.com/blog/200804/wicked_hack_python_bytecode_tracing.html).


It's entirely true that binding expressions don't change this situation 
at all, EXCEPT that the entire point of binding expressions is to be 
able to express in one statement what used to take more than one.  With 
binding expressions, actions may be coverage-hidden within one statement 
that without them would have been coverage-visible in more than one 
statement.


I'm not sure that's an argument against binding expressions, but we 
should at least acknowledge that the motivation for them is to provide 
the option to write fewer, longer statements.  That option is not always 
a good idea, for a variety of reasons.


--Ned.
___
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 10:56:06PM +1000, Nick Coghlan wrote:
> On 27 April 2018 at 22:28, Steven D'Aprano  wrote:
> 
> > On Fri, Apr 27, 2018 at 08:13:20AM +0200, Andrea Griffini wrote:
> > > Now we got standard library features requiring type annotation
> >
> > We do? Did I miss them? Which std 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).

Thanks Nick. But they're not exactly used as *type* annotations.

It was inevitable that something in the std lib would eventually make 
use of annotations, but unless they're used for type-checking, that's 
hardly eating away at the promise "no mandatory static typing".


-- 
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] (name := expression) doesn't fit the narrative of PEP 20

[Steve Holden]

On Fri, Apr 27, 2018 at 8:19 PM, Tim Peters  wrote:

> [Lukasz]
> >> >  And that *is* a thing that you will have to explain to newbies when
> >> > they encounter it for the first time.
>
> ​Which they will presumably do either in class or by reading code. No
sensible instructor or course author is going to bring name-binding
expressions up until standard assignment has been thoroughly assimilated.
In my own teaching experience I observed that those used to static
languages took a little time to adapt to the indirection of Python's names,
but not long.
​


> ​[...]
>
> 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.
>
> ​I was half-expecting someone to pop up and suggest only functional
programming as a means to avoid having to teach assignment ...
​


> 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.
>
> ​But surely that depends on HOW MUCH of the language you aim to teach.
​Over the years Python has become a much more complex language, but it has
a fairly easily-identified subset that can act as a basis for building
useful programs. Some instructors avoided teaching comprehensions, but a
sensible course would try to ensure that students could understand the code
they were most likely to encounter "in the wild."

[
> ​...]
>
> 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'd expand that to say that identity comparison is most useful for types
whose instances are all unique. For other types there's the unfortunate
impedance mismatch between identity and equality (which is user-definable
anyway).
​


> > I've even had students write code like:
> >
> > if x is 3:
> >
> > and thanks to interning, it appears to work!
>
> ​No, thanks to interning it DOES work. For interned values.​

​But instructors have to touch on implementation artefacts at times, and I
used to find it instructive to write the same code with two different
integer constants and ask why they gave different results. It certainly
helped people to master the semantics of assignment (as did the phrase
"Python never copies data on assignment").​

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

​I'd argue that without some knowledge of the potential pitfalls students
can't be expected to learn how to make that distinction.

regards
 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] PEP 394: Allow the `python` command to not be installed (and other minor edits)

[Paul Moore]

On 28 April 2018 at 05:08, Nick Coghlan  wrote:
> On 28 April 2018 at 12:34, Guido van Rossum  wrote:
>>
>> Um, the PEP has "Unix-Like Systems" in its heading, so discussing the
>> Windows situation seems out of scope to me.
>
> Sorry, I conflated two issues there - while PEP 394 itself is specific 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)

Strong +1 on this. I am not a Unix user, so my opinions on PEP 394 are
not relevant, but I agree with Nick that the current mess over "how to
write general instructions for a newcomer on how to run Python or
Python-related commands" is unsustainable. We have:

1. In a virtualenv - python
2. On windows - py (or "python" might work, if you're lucky, and it
may or may not work the same as "py")
3. On Unix - python3 (or if you have a self-installed Python, or
something like pyenv, "python" maybe, who knows).
4. If you're using something like Anaconda - quite likely "python",
but I'm not honestly sure except on Windows

And it's even worse once you get to something like pip: "pip", "pip3",
"python -m pip", "py -m pip", "python3 -m pip", ...

I don't want to push any particular solution here myself (my almost
exclusively Windows experience is too biased for me to understand the
trade-offs) but IMO, it's definitely something we need to solve.

Paul
___
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)

[Matěj Cepl]

On 2018-04-28, 01:23 GMT, Nick Coghlan wrote:
> That isn't currently *my* desired future, as I don't want to 
> see a python3 to python4 naming transition at any point, 
> I want a transition from python3 back to an unqualified name 
> to accurately reflect the change in version management 
> 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)

+1

Matěj
-- 
https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
 
We can tell our level of faith in what God wants to do for us by
our level of enthusiasm for what we want God to do for other.
   -- Dave Schmelzer

___
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

[Steven D'Aprano]

On Fri, Apr 27, 2018 at 04:24:35PM -0400, Wes Turner wrote:

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

Wes, there is *absolutely nothing new* here. This sort of error is 
already possible in Python.

Do you see a lot of code like:

if (1 or sequence.append(3) or sequence[-1]):

in real life? If you do, then I'm really, really sorry that you are 
forced to deal with such rubbish code, but honestly, the vast bulk of 
Python programmers do not write like that, and they won't write this 
either:

if (1 or (x := 3)):


[...]
> 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.

The same applies to any operation at all.

/sarcasm
I guess adding print() to the language was a mistake, because we 
can write rubbish code like this:

if 1 or print(x):

and then be confused by the fact that x doesn't get printed.
/end sarcasm

In another post, you insisted that we need to warn in the PEP and the 
docs not to do this sort of thing. Should we also go through and add 
these warnings to list.append, dict.update, set.add, etc?

I trust that the answer to that is obviously no.

And neither do we have to assume that people who use binding-expressions 
will lose their minds and start writing the sort of awful code that 
they don't write with anything else.



-- 
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] (name := expression) doesn't fit the narrative of PEP 20

[Cesare Di Mauro]

Hi,

2018-04-28 5:08 GMT+02:00 Armin Rigo :

> Hi,
>
> On 26 April 2018 at 07:50, Raymond Hettinger
>  wrote:
> >> [Raymond Hettinger ]
> >>> After re-reading all the proposed code samples, I believe that
> >>> adopting the PEP will make the language harder to teach to people
> >>> who are not 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.
>

Same feeling here. What I really appreciate of Python from long time is its
readability: the fact that usually I read the code as English-like
sentences.

It was nice to see the usage of the "as" keyword in the try/except
construct as well as in the with one, instead of introducing another bunch
of symbols which will make it more difficult to decode the meaning of the
writing.
Same for the "if/else" ternary operator, which I read like "[give] x if
cond else y", instead of the cryptic "?:" of C-like languages. It was a
nice and wise design decision.

For similar reasons, I did/don't like the @ for matrix multiplication
because it doesn't give me any immediately, useful information which makes
it easier to decode the meaning. A "mul" binary operator would have worked
better, for example.

I hope that Python core developers refuse the temptation to introduce new
operators using symbols for new features: it's a short way to keep
backward-compatibility, for sure, but if the price to pay is the
readability, then I don't think that it's worth to do it.

Regarding the assignment operator, I also find it a (bad, since it's not so
much readable inside expressions) duplicate of the assignment statement. To
be more precise, why should we keep the latter once with the former we can
do the same things (and more)? Then drop the assignment statement and just
leave the operator!

BTW, as a pythonist I've also felt the need to have some way to "bind"
values to variables in some context, but it's pretty much related to
comprehensions, for obvious reasons I think.
I would have appreciated an "as" keyword, only inside such constructs, but
I don't see any value extending it for any generic context, since we
already have the assignment statement which works quite well and doesn't
introduce nasty side-effects "ala C-like languages".
So, IMO it's better to stay as we are instead of introducing another kludge
to the language, if we cannot maintain a good readability.

Cheers,

Cesare
___
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