Re: [Python-Dev] PEP 572 contradicts PEP 3099
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
> -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
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
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
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
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
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
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
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
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)
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
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)
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)
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
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