[Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

Antoine Pitrou solipsis at pitrou.net
Mon Jul 2 04:31:28 EDT 2018


Is this message some kind of joke or did you just send it to the wrong
mailing-list/recipient?


On Sun, 1 Jul 2018 20:21:19 -0700
Matt Arcidy <marcidy at gmail.com> wrote:
> 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
> ejected to the parent scope, but there won't be any use of it.  Teach
> the explicit declare pattern first (as everyone does anyways), explain
> to not re-use.  Regardless of when re-use is done,  it is always (or
> only) as dangerous as the effect the bound value has anyways, and any
> re-use has the potential to trigger the same dangerous behaviors.
> 
> Must we continue this educator assessment of PEP 572?  Educators are
> not gate-keepers, and the only measure of their success is what
> students learn, and students have a far larger and more fine-grained
> mosaic now than ever.   Seat-based education plays a far smaller role
> in anyone's learning path than ever before, and even while in the seat
> they have access to Google.  All this yield to tiling the outcome in
> the favor of the educator by assigning the goal meeting to them, not
> to the diligence of the student to learn.  How unfair to the student.
> 
> I consider this position purposefully ignoring motivated self-learners
> of high ability and skill, or just plain old diligent programmers who
> learned to read specs before using tools.
> 
> I don't like posting to python-dev because it's not really my realm,
> but this topic is insanely tilted against PEP572 for the most
> ridiculous of reasons.  I am Pro-572 , so I have decided to join
> critique of the educator position.  I would rather do it on
> python-Ideas, and I want more types of educators solicited, as well as
> students and learners.  And yes, lets assess your specific lesson
> plans if you will make claims it's not possible.  Do you even teach
> the difference between assignments and expressions at all?
> 
> To have this raised in the this stage of this PEP, and on the dev
> list, illustrates how long it took educators to understand the tool to
> begin with, as opposed to those who understood even if they disagree.
> To have a room full of seat-based educators provide feedback on a tool
> they have had 30m to understand as critical to shaping the language is
> not defensible in these lower courts.  This angle cannot withstand
> rigorous scrutiny because each premise is false and it rests the
> majority of students being dense.  They aren't, and the vast majority
> of learners don't need class-room education anyways, so what is this
> weight being placed on the opinion of these educators?  I agree it's
> important to hear it, but dimishingly.
> 
> This is not to say that PEP572 should be accepted otherwise.  However,
> this educator angle, raised only now and depending on this
> platonically dumb student and a non-creative approach to education, is
> just pure straw-man to distract from the point at hand.  And while I
> have repeated "straw-man" as the critique, I  dislike leaning on such
> a debate-team crutch, and of course employing straw-man doesn't mean
> the point is invalid.  it just means the rhetoric is bad.  However, as
> the underlying premise is a severe minority opinion yet claiming to be
> broad, and the absolute percentage of solicited opinions is 0% (to the
> 17th place), I don't see any importance to the position of educators
> right now, especially since these educators in the thread are
> complaining about an increase in their personal work, for which it
> appears they were compensated (this is pretty bad straw-man, sorry).
> 
> And to repeat, what about the learners?  Time spent in seat based
> education is so insanely small now.  The fact that the name is ejected
> to the parent stop is not terribly difficult, and appropriately
> factored examples showing the the effect of scope ejection will be
> easy to construct, even if trivial for explanation purposes.  So what,
> exactly, is the issue with learning it?
> 
> 
> 
> On Sun, Jul 1, 2018 at 4:35 PM Chris Barker via Python-Dev
> <python-dev at python.org> wrote:
> >
> > On Sun, Jul 1, 2018 at 8:35 AM, Michael Selik <mike at selik.org> 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.Barker at noaa.gov
> > _______________________________________________
> > Python-Dev mailing list
> > Python-Dev at python.org
> > https://mail.python.org/mailman/listinfo/python-dev
> > Unsubscribe: https://mail.python.org/mailman/options/python-dev/marcidy%40gmail.com  





More information about the Python-Dev mailing list