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

Matt Arcidy marcidy at gmail.com
Sun Jul 1 23:21:19 EDT 2018


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