Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)
This cynical view on students is shocking! Everyone on this list has been a student or a learner for far longer than an educator, and the perspective from students and learners are far more important than educators to assess this angle regardless. Can anyone adequately explain why this specific modality of learning, a student-in-a-seat based educator, must outweigh all other modalities learners use to increase knowledge and skill, from the perspectives of policy, tool creation, and each of our time spent learning? Shortest story: Teach not to re-use names. Short story: 1) What about the full mosaic of learning vs. this myopic view on seat-based student-educator interaction? 2) What about smart, motivated, diligent and cautious students? 3) What weight should educator opinion be given with respect to providing convenience to professional Python programmers? 4) Who is this Student Stupid von Densemeister anyways? 5) Are assignment expressions convenience and is any danger the pose unmitagatble? 6) Consider adding an "Important Topics not Covered" or "Further Reading" reading section to your class description 7) Creating examples showing this effect is easy, especially when not actually re-using the name in the expression for explanatory purposes. it's the same as creating examples showing how re-use works in comprehensions. Let's stop constructing these fake Students. They only work as appeals to the people we have come across whose lack of understanding has made our life painful. This construction is actively filtering all the good students for the sake of influencing this decision, yet again punishing or discounting the intelligent, quick, and diligent. And what of this underlying premise that educator's should _significantly_ influence language development? Limiting Python's tools to Student Straw-man's ability to learn is just dissonant, they have nothing to do with each other, nor does this cause-effect relationship actually exist. Let's evaluate this reductionist statement: "I understand X, but this other person is not capable of understanding X, therefore X should not exist" Is has there ever been an X for which this is true, let alone the backwardation necessary to fully close the statement? The actual argument is far less reductionist, yet even more ridiculous: "I understand X, this other person may take time to learn X, and may use X wrong, therefore X should not exist" "I understand assignment expressions, but this other class of person may take time to learn assignment expressions, and may use assignment expressions wrong, therefore assignment expressions should not be accepted" Rhetorically I disagree with how teaching is being presented, to the point of near insult (for me lacking a better term). You are saying these statements about _my_ learning path, (though not personally of course.) Each of you occupied a role of student at some point, and each of these statements are being made about your path as well. Do these ring true of your student experience? What about your much broader experience as a _learner_? You think a tool shouldn't exist because it took you time to learn it and you wrote some hard to debug code, and possibly crashed production, got fired, lost your house and your pet snake, and crashed the planet into the sun? Now I yield, I will accept this position: all/some students cannot learn this (or it's too complex to teach), but they must learn this during some class to quickly become effective python developers. How much weight should this position have in this decision? Let's appeal to the learner in us. How much of our learner's path, percentage of total time learning all things python related, has been in a seat listening to someone else, and that's the only place from which we gained the knowledge to meet the educator's objective? This time spent in a class, how does that compare to hours in other learning modalities? Is this percentage not exactly the weight assigned to that position? Are people hired from pure class-room based experience expected to require zero further learning? Are people more valuable based on classroom hours or work hours? As for handling teaching the subject or not, this is easily remedied with how I do it: "Important Topics not Covered", with resources. Anyone here can rightfully claim educator status by having taught another person something related to this language, which includes at-work mentoring, informal discussions, posting/replying on SO, blogging, etc. Are they not being solicited to comment as well? It's possible to answer this question while vehemently disagreeing with the PEP. This focus on people who are being ostensibly paid to teach is myopic. Concretely, it's clear to me that parent-local effects can be dangerously non-obvious when reading and mimicking code without undertsanding. But when? And how to guard against? How about this: teach proper (i.e. not) re-using names. The name will still be
Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)
On Sun, Jul 1, 2018 at 5:28 PM Steven D'Aprano wrote: > On Sun, Jul 01, 2018 at 08:35:08AM -0700, Michael Selik wrote: > > On Sun, Jul 1, 2018 at 12:39 AM Tim Peters wrote: > > > > > So, ya, when someone claims [assignment expressions will] make Python > > > significantly harder to teach, I'm skeptical of that claim. > > > > > > > I don't believe anyone is making that claim. My worry is that assignment > > expressions will add about 15 to 20 minutes to my class and a slight > > discomfort. > > How do people who teach other languages deal with this? > Python may be in a unique situation in the history of programming. It wouldn't surprise me if more people learned Python last year than any other programming language. > Assignment expressions are hardly a new-fangled innovation of Python's. > They're used in Java, Javascript, Ruby, Julia, R, PHP and of course > pretty much the entire C family (C, C++, C# at least). What do > teachers of those languages do? > Assignment expressions are not the issue. The real question is: How do open-source projects balance the addition of new features against the growth of complexity? It's the same as that "Remember the Vasa" thread. [...] R [has] *four* different ways of doing assignment. > I think that's a good explanation of why I teach Python and not R. The first time someone asked me to teach a data science course, Python wasn't the clear winner. In fact, R may have been more popular among statisticians. I picked Python for the same reason it's more popular in the industry -- it's the easiest* to use. * Easiest that gets the job done well. > As Mark and Chris said (quoting Mark below), this is just one straw in the > > struggle against piling too many things on the haystack. Unlike some > > changes to the language, this change of such general use that it won't be > > an optional topic. Once widely used, it ain't optional. > > Without knowing the details of your course, and who they are aimed at, > we cannot possibly judge this comment. I disagree. I think the sentiment holds for a great variety of courses and audiences. > Decorators are widely used, but surely you don't teach them in a one day > introductory class aimed at beginners? > Most of the time, no. Once, yes, because that's what the team needed. I was pretty proud of myself for handling that one. Because I had to teach decorators early, many other important topics were excluded. Here is the syllabus for a ten week course: > https://canvas.uw.edu/courses/1026775/pages/python-100-course-syllabus > > Note that decorators and even regular expressions don't get touched > until week ten. If you can't fit assignment expressions in a ten week > course, you're doing something wrong. If you can't fit them in a two > hour beginners course, there is so much more that you aren't covering > that nobody will notice the lack. > It's not about any one particular topic, but the trade-offs between topics. A 10-week lecture course might be 30 hours of lecture, comparable to a 4-day "bootcamp" style course. I assure you that 4 days doesn't feel long enough when those last few hours are winding down. There's always more to say. ___ 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] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)
On Sun, Jul 01, 2018 at 08:35:08AM -0700, Michael Selik wrote:
> On Sun, Jul 1, 2018 at 12:39 AM Tim Peters wrote:
>
> > So, ya, when someone claims [assignment expressions will] make Python
> > significantly harder to teach, I'm skeptical of that claim.
> >
>
> I don't believe anyone is making that claim. My worry is that assignment
> expressions will add about 15 to 20 minutes to my class and a slight
> discomfort.
How do people who teach other languages deal with this?
Assignment expressions are hardly a new-fangled innovation of Python's.
They're used in Java, Javascript, Ruby, Julia, R, PHP and of course
pretty much the entire C family (C, C++, C# at least). What do
teachers of those languages do?
R has a similar demographic of users (strong in the sciences, many
beginners to programming, growing in popularity). Once R teachers have
taught that you can assign values like this:
x = 1 + 2
does it take them 15-20 minutes to teach that you can do this as well?
y = (x = 1 + 2) + 3
Admittedly R has the advantage that they don't have to teach a distinct
assignment syntax and explain *why* it ought to be distinct. But
countering that, they have *four* different ways of doing assignment.
x <- expression
expression -> x
x = expression
assign('x', expression)
(all of which can be used as expressions).
> As Mark and Chris said (quoting Mark below), this is just one straw in the
> struggle against piling too many things on the haystack. Unlike some
> changes to the language, this change of such general use that it won't be
> an optional topic. Once widely used, it ain't optional.
Without knowing the details of your course, and who they are aimed at,
we cannot possibly judge this comment. Decorators are widely used, but
surely you don't teach them in a one day introductory class aimed at
beginners?
Here is the syllabus for a ten week course:
https://canvas.uw.edu/courses/1026775/pages/python-100-course-syllabus
Note that decorators and even regular expressions don't get touched
until week ten. If you can't fit assignment expressions in a ten week
course, you're doing something wrong. If you can't fit them in a two
hour beginners course, there is so much more that you aren't covering
that nobody will notice the lack.
--
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] Failing tests [Was: Re: Python 3.7.0 is now available! (and so is 3.6.6)]
On Jul 1, 2018, at 17:48, Matěj Cepl wrote: > On 2018-06-28, 00:58 GMT, Ned Deily wrote: >> On behalf of the Python development community and the Python 3.7 release >> team, we are pleased to announce the availability of Python 3.7.0. > > I am working on updating openSUSE packages to python 3.7, but > I have hit quite large number of failing tests (the testsuite > obviously passed with 3.6), see > https://build.opensuse.org/package/show/home:mcepl:work/python3 > (click on the red "failed" label to get logs). I fell into > a bout of depression, only to discover that we are not alone in > this problem ... Debian doesn't seem to do much better > https://is.gd/HKBU4j. Surprisingly, Fedora seems to pass the > testsuite https://is.gd/E0KA53; interesting, I will have to > investigate which of their many patches did the trick. > > Anybody has any idea, what's going on, please? Did anybody on > the python.org side run test suites on Linux? Without doing a detailed analysis of how your build system is set up, I do note you have "--enable-shared" set on ./configure which is often the source of problems. Make sure that you are building from a clean build directory and that you are not building on a system that already has an installed Python 3.7 pre-release at the same prefix location. Of course we run test suites on Linux :) Each time a change is merged our CI tests are run on Linux, we have a fleet of buildbots that test every commit on various flavors of Linux, and prior to release the release manager does a smoke test of building and testing on at least one Linux variant. That's not to say there couldn't be multiple configurations with undetected problems but the number of problems here points to something much more basic. If necessary, please open an issue on bugs.python.org so we can get this resolved quickly. Thanks! -- Ned Deily n...@python.org -- [] ___ 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] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)
On Sun, Jul 1, 2018 at 8:35 AM, Michael Selik wrote: > As Mark and Chris said (quoting Mark below), this is just one straw in the > struggle against piling too many things on the haystack. Unlike some > changes to the language, this change of such general use that it won't be > an optional topic. Once widely used, it ain't optional. > Exactly -- and I also emphasis that this would complicate the language in a broad way -- a much bigger deal than adding a self contained new expression or even the nonlocal keyword. But to be clear about my take -- it will make the language that little bit harder to teach, but it will also add a bit of complexity that will effect us non-newbies as well. Is it worth it? maybe. I know I like a better way to express the loop-and-a-half concept in particular. -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] Failing tests [Was: Re: Python 3.7.0 is now available! (and so is 3.6.6)]
On 1.7.2018 23:48, Matěj Cepl wrote: On 2018-06-28, 00:58 GMT, Ned Deily wrote: On behalf of the Python development community and the Python 3.7 release team, we are pleased to announce the availability of Python 3.7.0. I am working on updating openSUSE packages to python 3.7, but I have hit quite large number of failing tests (the testsuite obviously passed with 3.6), see https://build.opensuse.org/package/show/home:mcepl:work/python3 (click on the red "failed" label to get logs). I fell into a bout of depression, only to discover that we are not alone in this problem ... Debian doesn't seem to do much better https://is.gd/HKBU4j. Surprisingly, Fedora seems to pass the testsuite https://is.gd/E0KA53; interesting, I will have to investigate which of their many patches did the trick. Note that we (=Fedora) unfortunately skip some tests. https://src.fedoraproject.org/rpms/python3/blob/master/f/python3.spec#_1051 https://src.fedoraproject.org/rpms/python3/blob/master/f/00160-disable-test_fs_holes-in-rpm-build.patch https://src.fedoraproject.org/rpms/python3/blob/master/f/00163-disable-parts-of-test_socket-in-rpm-build.patch -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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] Failing tests [Was: Re: Python 3.7.0 is now available! (and so is 3.6.6)]
On 2018-06-28, 00:58 GMT, Ned Deily wrote: > On behalf of the Python development community and the Python 3.7 release > team, we are pleased to announce the availability of Python 3.7.0. I am working on updating openSUSE packages to python 3.7, but I have hit quite large number of failing tests (the testsuite obviously passed with 3.6), see https://build.opensuse.org/package/show/home:mcepl:work/python3 (click on the red "failed" label to get logs). I fell into a bout of depression, only to discover that we are not alone in this problem ... Debian doesn't seem to do much better https://is.gd/HKBU4j. Surprisingly, Fedora seems to pass the testsuite https://is.gd/E0KA53; interesting, I will have to investigate which of their many patches did the trick. Anybody has any idea, what's going on, please? Did anybody on the python.org side run test suites on Linux? Best, Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 The difference between death and taxes is death doesn't get worse every time Congress meets -- Will Rogers ___ 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] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)
On Sun, Jul 1, 2018 at 12:39 AM Tim Peters wrote: > So, ya, when someone claims [assignment expressions will] make Python > significantly harder to teach, I'm skeptical of that claim. > I don't believe anyone is making that claim. My worry is that assignment expressions will add about 15 to 20 minutes to my class and a slight discomfort. As Mark and Chris said (quoting Mark below), this is just one straw in the struggle against piling too many things on the haystack. Unlike some changes to the language, this change of such general use that it won't be an optional topic. Once widely used, it ain't optional. On Sun, Jul 1, 2018 at 2:19 AM Mark Dickinson wrote: > There's a constant struggle to keep the Python portion of the course large > enough to be coherent and useful, but small enough to allow time for the > other topics. > ___ 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 544 (Protocols): adding a protocol to a class post-hoc
On 30 June 2018 at 23:54, Tin Tvrtković wrote:
> [...]
>
> An attrs class has a special class-level field, __attrs_attrs__, which
> holds the attribute definitions. So maybe we can define a protocol:
>
> class AttrsClass(Protocol):
> __attrs_attrs__: ClassVar[Tuple[Attribute, ...]]
>
> then we could define asdict as (simplified):
>
> def asdict(inst: AttrsClass) -> Dict[str, Any]:
> ...
>
> and it should work out. My question is how to actually add this protocol
> to attrs classes. Now, we currently have an attrs plugin in mypy so maybe
> some magic in there could make it happen in this particular case.
>
Just add a Var with an appropriate name and type to the TypeInfo. This is
literary a dozen lines of code, you can ask on mypy tracker or typing
Gitter chat for more help.
> My second use case is a small library I've developed for work, which
> basically wraps attrs and generates and sticks methods on a class for
> serialization/deserialization. Consider the following short program, which
> does not typecheck on the current mypy.
>
> class Serializable(Protocol):
> def __serialize__(self) -> int:
> ...
>
> def make_serializable(cl: Type) -> Type:
> cl = attr.s(cl)
> cl.__serialize__ = lambda self: 1
> return cl
>
>
> @make_serializable
> class A:
> a: int = attr.ib()
>
>
> def serialize(inst: Serializable) -> int:
> return inst.__serialize__()
>
>
> serialize(A(1))
>
> error: Argument 1 to "serialize" has incompatible type "A"; expected
> "Serializable"
> error: Too many arguments for "A"
>
> I have no desire to write a mypy plugin for this library. So I guess what
> is needed is a way to annotate the class decorator, telling mypy it's
> adding a protocol to a class. It seems to have trouble getting to this
> conclusion by itself.
>
A proper solution for this would be to introduce intersection types, and
type your decorator as following:
T = TypeVar('T')
def make_serializable(cls: Type[T]) -> Type[Intersection[T, Serializable]]:
...
However, intersection types are unlikely to appear in mypy this year. In
best case they could appear around mid-2019, so you are better with writing
a plugin for now.
> (The second error implies the attrs plugin doesn't handle wrapping attr.s,
> which is unfortunate but a different issue.)
>
Your decorator is typed as (Type) -> Type, thats it, the function is a
black box for mypy (with few special exceptions), if some effect of a
function is not declared in its signature, then it is lost forever.
--
Ivan
___
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] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)
On Fri, Jun 22, 2018 at 7:28 PM, Chris Barker via Python-Dev < python-dev@python.org> wrote: > > But once it becomes a more common idiom, students will see it in the wild > pretty early in their path to learning python. So we'll need to start > introducing it earlier than later. > > I think this reflects that the "smaller" a language is, the easier it is > to learn. > For what it's worth, Chris's thoughts are close to my own here. I and several of my colleagues teach week-long Python courses for Enthought. The target audience is mostly scientists and data scientists (many of whom are coming from MATLAB or R or IDL or Excel/VBA or some other development environment, but some of whom are new to programming altogether), and our curriculum is Python, NumPy, SciPy, Pandas, plus additional course-specific bits and pieces (scikit-learn, NLTK, seaborn, statsmodels, GUI-building, Cython, HPC, etc., etc.). There's a constant struggle to keep the Python portion of the course large enough to be coherent and useful, but small enough to allow time for the other topics. To that end, we separate the Python piece of the course into "core topics" that are essential for the later parts, and "advanced topics" that can be covered if time allows, or if we get relevant questions. I can't see a way that the assignment expression wouldn't have to be part of the core topics. async stuff only appears in async code, and it's easy to compartmentalize; in contrast, I'd expect that once the assignment expression took hold we'd be seeing it in a lot of code, independent of the domain. And yes, I too see enough confusion with "is" vs == already, and don't relish the prospect of teaching := in addition to those. That's with my Python-teaching hat on. With my Python-developer hat on, my thoughts are slightly different, but that's off-topic for this thread, and I don't think I have anything to say that hasn't already been said many times by others, so I'll keep quiet about that bit. :-) -- Mark ___ 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] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)
I think I'll bow out of this now. It's just too tedious. Like here: [Nick] > I never said the motivation was to gain performance relative to the > two-statement version - I said the motivation given in the PEP is to > gain performance relative to the *repeated subexpression* version, > *without* making the transition to the already supported two-statement > version. This is what you wrote: >> "NAME := EXPR" exists on a different level of complexity, since it >> adds name binding in arbitrary expressions for the sake of minor >> performance improvement in code written by developers that are >> exceptionally averse to the use of vertical screen real estate, I'm not telepathic, so took it for it what said. It didn't say a word about "repeated expressions", nor a word about "two-statement versions" It did say "minor" performance improvements, which sure suggested to me that you had in mind the tiny changes in bytecode that can result from squashing a current two-statement spelling into a one-statement form with an embedded assignment. That fit both "minor performance improvement" and "vertical screen space", which were the only the two clues I had to go on. In the example you eventually gave in a later message, the performance difference was more on the order of a factor 2 (regexp searches can be expensive indeed), which matches nobody's idea of "minor". So the use of "minor" wholly ruled out in my mind that you had _anything_ akin to your eventual example in mind. For the rest, sure, words could be added to the PEP without end. At least some of the points I covered were telegraphically mentioned in my Appendix, although I'll grant that nobody else is telepathic either ;-) For the question: > > The remaining point of contention is only the "Inevitable cost of > > change" one: given the level of disruption this will cause in the way > > that Python gets taught to new users, is it giving a commensurate > > pay-off in increased semantic expressiveness? > > > > My answer to that question remains "No", while your answer is either > > "Yes" or "I don't see why that should matter" (I'm genuinely unsure > > which). I don't know, and I'm not qualified to guess - I don't teach Python to new users for a living. Decades ago I tutored "advanced" engineering undergrads in a variety of science-y subjects, and was routinely surprised by what broke their brains. I have noted that assignment expressions have been part of a great many languages for decades (this isn't cutting edge tech), questions about them are conspicuous by absence on StackOverflow (everyone else seems to teach them effectively), and skimming various online teaching materials for other languages convinced me that none of those professional educators thought it needed more than a page to teach (and to teach them with relatively few words). There's really not much to them: people have to learn what binding means in Python regardless, pretty much starting in the first hour, yes? "Binding" on its own is the hard part. If they don't drop out and stick around for the 10-minute lesson on assignment expressions 3 weeks later, will _that_ finally break their brains? "Wow - it not only binds the name, but ALSO returns the object that was bound?! I just can't take it - please, let's go back to the lesson on metaclasses" just doesn't seem likely to me ;-) At heart, ":=" could make a good case for being the simplest of all Python's operators. It does no computation at all, and you don't even have to worry about a dunder method changing its meaning depending on context. So, ya, when someone claims they'll make Python significantly harder to teach, I'm skeptical of that claim. Which does not mean I believe it's wrong - it means I'm skeptical. I would also be skeptical of a claim that teaching them would be no trouble at all, except nobody has made such a claim ;-) ___ 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] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)
On Sat, Jun 30, 2018 at 11:32:03PM -0500, Tim Peters wrote: [...] > So, no, gaining performance is _not_ the motivation here. You already had > a way to make it "run fast'. The motivation is the _brevity_ assignment > expressions allow while _retaining_ all of the two-statement form's > advantages in easier readability, easier reasoning, reduced redundancy, and > performance. I think the two of you (Tim and Nick) are in violent agreement :-) In fairness to Nick performance is _a_ motivation here, in the sense of "how can we avoid making redundant multiple calls to a function in an expression without splitting it into multiple statements?". If performance were the *only* concern, then I agree with your point that we already have a solution. Simply refactor this: process(expensive_call(arg), expensive_call(arg) + 1) to this: useful_value = expensive_call(arg) process(useful_value, useful_value + 1) But since performance is not the *only* concern, all the other factors you refer to (saving vertical space, DRY, side-effects, etc) count too. Assignment expressions aren't valuable because they give us One Big Win. They're valuable because they give us Many Little Wins, which we (proponents of PEP 572) believe will outweigh the (minor) additional costs in complexity and opportunities for abuse. The closest (in my opinion) assignment expressions comes to a One Big Win is to reduce the need for cascades of if... statements: m = re.match(pattern, text) if m: ... else: m = re.match(other_pattern, text) if m: ... else: m = re.match(third_pattern, text) if m: ... which wastes both vertical and horizontal space. If that were the *only* win, I'd consider dedicated syntax for if/elif statements alone, but it isn't. Little wins include: - use in while statement headers, "while x:= expr" - DRY inside comprehensions, as an alternative to the neat but somewhat obscure idiom: [(x, x+1, x*2) for a in it for x in (func(a),) if x] - running totals and similar inside comprehensions, where we need a way to initialise the total on the first iteration total = 0 [total := total + a for a in it] - and examples such as Tim's use of Heron's Formula: area = sqrt((s := (a+b+c)/2)*(s-a)*(s-b)*(s-c)) This last one is, I think, the only one where the postfix form reads better, but maybe I only say that because I'm more familiar with it: area = sqrt(s*(s-a)*(s-b)*(s-c)) where s = (a+b+c)/2 -- 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] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)
On 1 July 2018 at 14:32, Tim Peters wrote:
> [Nick]
>
>> The PEP specifically cites this example as motivation:
>
> The PEP gives many examples. Your original was a strawman
> mischaracterization of the PEP's _motivations_ (note the plural: you only
> mentioned "minor performance improvement", and snipped my listing of the
> major motivations).
I listed two motivations, not one:
1. Minor performance improvements (the "avoiding repeated
subexpressions without use multiple statements" rational)
2. Making certain coding patterns easier to spot (the loop-and-a-half
and if-elif chaining cases)
Technically, avoid repeated subexpressions without requiring a
separate line also falls into the second category.
The subsequent interaction with comprehensions and generator
expressions is an interesting side effect of extending the basic idea
to a fully coherent and self-consistent proposal, not one of the
original motivations for it.
>> group = re.match(data).group(1) if re.match(data) else None
>
>> That code's already perfectly straightforward to read and write as a
>
>> single line,
>
> I disagree. In any case of textual repetition, it's a visual
> pattern-matching puzzle to identify the common substrings (I have to
> visually scan that line about 3 times to be sure), and then a potentially
> difficult conceptual puzzle to figure out whether side effects may result in
> textually identical substrings evaluating to different objects. That's why
> "refererential transparency" is so highly valued in functional languages
> ("if subexpressions are spelled the same, they evaluate to the same result,
> period" - which isn't generally true in Python - to get that enormously
> helpful (to reasoning) guarantee in Python you have to ensure the
> subexpression is evaluated exactly once).
>
> And as you of all people should be complaining about, textual repetition is
> also prone to "oops - forgot one!" and "oops! made a typo when changing the
> second one!" when code is later modified.
That's a reasonable readability based argument, but it's not what the
PEP currently gives as a motivation for this aspect of the proposal.
>> so the only reason to quibble about it
>
> I gave you three better reasons to quibble about it just above ;-)
Then add them to the PEP, as what's currently there really isn't
offering a compelling motivation for this aspect of the proposal :)
>> is because it's slower than the arguably less clear two-line alternative:
>
>> _m = re.match(data)
>
>> group = _m.group(1) if _m else None
>
>
> I find that much clearer than the one-liner above: the visual pattern
> matching is easier because the repeated substring is shorter and of much
> simpler syntactic structure; it guarantees _by construction_ that the two
> instances of `_m` evaluate to the same object, so there's no possible
> concern about that (it doesn't even matter if you bound `re` to some
> "non-standard" object that has nothing to do with Python's `re` module); and
> any later changes to the single instance of `re.match(data)` don't have to
> be repeated verbatim elsewhere. It's possible that it runs twice as fast
> too, but that's the least of my concerns.
I agree with this, but also think the two-line form is a perfectly
acceptable way of spelling it, and a perfectly acceptable refactoring
of the one-line form with duplicated subexpressions to improve
maintainability.
> All of those advantages are retained in the one-liner too if an assignment
> expression can be used in it.
Sure, but the open design question is whether folks that would have
written the one-liner with repeated subexpressions are going to be any
more likely to use an assignment expression to avoid the repetition
without prompting by a more experienced developer than they are to use
a separate preceding assignment statement.
That assessment of "What is the increased chance that the repeated
subexpression will be avoided when the code is first written?" then
gets traded off against the overall increase in language complexity
arising from allowing name bindings in arbitrary subexpressions.
Don't get me wrong, I now agree that the proposal in PEP 572 is the
most coherent and self-consistent approach to assignment expressions
that we could pursue given the existing scoping semantics of
comprehensions and generator expressions.
The remaining point of contention is only the "Inevitable cost of
change" one: given the level of disruption this will cause in the way
that Python gets taught to new users, is it giving a commensurate
pay-off in increased semantic expressiveness?
My answer to that question remains "No", while your answer is either
"Yes" or "I don't see why that should matter" (I'm genuinely unsure
which).
>>> sometimes it allows a more compact way of reusing an expensive
>>> subexpression by giving it a name. Which they already do by giving
>>> it a name in a separate statement, so the possible improvement would
>>> be in brevity rather than
Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)
Nick Coghlan wrote: That's a performance argument, not a readability one (as if you don't care about performance, you can just repeat the subexpression). Repeated subexpressions can be a readability issue too, since you have to examine them to notice they are actually the same. They also provide an opportunity to make the error of not making them the same when they should be, and add the maintenance burden of ensuring they stay the same when changes are made. -- 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
