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 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] 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 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
[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] 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
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&R(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 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 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] 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)
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 ej
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:25 PM, Steven D'Aprano wrote: > > > 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 > That would be mine ;-) > Note that decorators and even regular expressions don't get touched > until week ten. I actually often don't ever get to regex -- why? because they are a topic all of their own, and not unique to Python. And if code uses a regex, it doesn't change anything about any other code anywhere. IN sort, regex's are a library, not a language feature. Which brings us to decorators (and I'm going to add context managers, as its similar). Decorators (and even more so context managers) are used commonly enough that we certainly have to introduce them in a intro class. But there is a really big distinction between having some idea how to use them, and knowing how they work / how to write them yourself. So I introduce: with open(filename) as the_file: do_somethign_with(the_file) early on, with only a hand-wavy explanation of what that with is all about. And when i get to properties, I teach them: @property def a_method(self): with also a hand-wavy explanation of what that @ symbol is. and if := catches on, I expect it will be far more common that either of those, especially in the simple script style codes that newbies are going to be reading/writing at first. But in the end, I, at least, am not trying to make the case that assignment expressions are going to be particularly difficult to understand, but that they are a significant complication, and any new feature like that makes the language more complex. That's it. I taught myself Python with version 1.5 in 1998 -- and have been teaching it for I think almost ten years. In that time, the language has grown substantially in complexity, and it does make it harder to teach. We (UWPCE) recently revamped our 3-class program, and had a lot of debate about how early to introduce things -- one of the instructors wanted to leave off lambda and comprehensions 'till the second course in the sequence, as part of functional programming. I I think he was right, if we were teaching it in a more isolated environment, but both of those show up in example code all over the place, so I've found it's necessary to introduce a lot at a high level early: decorators comprehensions lambda context managers *args and **kwargs (off the top of my head) So there is basically no way that we won't have to add assignment expressions early on. As someone else said: it's another straw on the haystack. -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(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] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)
[Tim] >> ... >> So, ya, when someone claims [assignment expressions will] make >> Python significantly harder to teach, I'm skeptical of that claim. [Michael Selik] > I don't believe anyone is making that claim. I haven't seen it in this specific thread, but the larger discussion has been going on for several months. > My worry is that assignment expressions will add about 15 to 20 > minutes to my class and a slight discomfort. So not intractable - which is my high-order bit ;-) For those who want more bits of precision (perhaps Guido), while quantification is good, it needs context to provide insight. Like, out of how many class hours total? Is 15-20 minutes a little, a lot, par for the course ... compared to other topics? Will it require you to drop other topics? Would you _save_ twice as much class time if we got rid of "is"? ;-) > 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. If it's accepted, do read the PEP - while the syntax will _allow_ assignment expressions just about everywhere, the recommended examples are all simple & straightforward. "If it's not obviously better, don't use it" is excellent advice. Because it's allowed almost everywhere, I expect that unanticipated "good uses" will pop up, but at the start a high majority of good uses seem to fall into a small number of patterns. Meta: About the Vasa, I'm not concerned. C++ has around 150 people relentlessly writing an endless sequence of enhancement proposals largely aimed at highly esoteric expert applications of an already extraordinarily complex language. Bjarne Stroustrup is right to be concerned about that. His goal is to cut back on the complications striving for theoretical perfection in all conceivable applications, and go back to working on ideas: that can be used by “ordinary programmers” whose main concern is to ship > great applications on time http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0977r0.pdf If C++ hadn't inherited assignment expressions from C from the start(*), I expect that's an idea he'd _want_ to consider now. They're well within the grasp of "ordinary programmers" - if they can master `j = 3`, they're 90% of the way to mastering `j := 3` (although it may be that "good taste" can't be taught at all). (*) Yes, I know about the stuff added to support yet another form of assignment expression in `if` and `switch` headers in C++ 17. That appeared to be more for "theoretical purity". Assignment expressions were always allowed there, but previously only `for` headers allowed _declaring_ a new variable inside the parens. Now `if` and `switch` allow that too. ___ 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
