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

[Tim Peters]

[Michael Selik]
>>> My worry is that assignment expressions will add about 15 to 20
>>> minutes to my class and a slight discomfort.

[Tim]
>> 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?

[Michael]
> Generally between 20 and 40 hours.

Ah - so I take it you're not teaching raw computer beginners, but people
who already know how to program in some other language(s)?  If so, perhaps
you could leverage on that assignment expressions are already present in
the most heavily used languages.  Depends on the students' backgrounds, of
course.

>> Is 15-20 minutes a little, a lot, par for the course ... compared to
other topics?

> I guessed 15-20 minutes, because I'm mentally comparing it to things
> like ternary expressions. Odds and ends that make the code better,
> but not a major concept that deserves hours.

That's where I see it fitting too.  While I don't expect it will ever come
up, if I were tasked with teaching assignment expressions, I can picture
ways of doing it that would take anywhere from one minute to two hours,
depending on the target audience's backgrounds, interests, and needs ("two
hours" for those fascinated by computer language history).


>> Will it require you to drop other topics?

> Yes. It might not seem like much,

Nope!  It was a trick question.  If you had answered "no", I would have
known you were just making things up ;-)

> but every minute counts. I'd probably try to ignore := unless some
> pesky student brings it up. It's like someone saying, "Hey, I heard
> that Python can't do threads?!" I always say, "Good question," but
> internally I'm thinking, "there goes a half hour. What can I cut today?"

Absolutely.  40 hours can't possibly cover more than a significant overview
of high-order bits.


>> Would you _save_ twice as much class time if we got rid of "is"? ;-)

> Ha. You joke, but ``is`` takes about 5 minutes. About 5 or 10 minutes
> more if some clever student notices that ``1 is 1`` and I need to explain
> Singletons and interpreter optimizations versus language spec.

That surprised me!  Educators have often said "is" was hard to teach, and
it's one of the F'est of Python FAQs on StackOverflow.  I always figured
that's because it's trivial if you have deep understanding of Python's
conceptual object model, but appears to be a random Boolean generator if
you're just mucking around at a shell without that understanding.  Still,
something like this sometimes temporarily baffles even experts:

>>> [] is []  # OK, `[]` always creates a new list
False
>>> id([]) == id([])  # or does it???
True

>> If it's accepted, do read the PEP

> I've read it a few times now. I hope I didn't sound like I haven't
> read it. That'd be embarrassing.

Heh.  No, I just wanted to be sure.  It's just impossible to tell from a
discussion that's entirely "meta".

> ...
> From my brief observations, it seems that the nattering nabobs of
negativism,
> such as myself, are mostly educators.

In this specific thread, sure, but I expect that's because it has "educator
feedback" in the Subject.  There's been plenty of opposition from
non-educators in other threads.  I like this thread because it's been more
civil than most :-)

> I recently started to wonder if I'd care so much about the language if I
> didn't teach. I suspect that if I didn't worry about teaching new
features,
> Python 4 could be announced tomorrow and I wouldn't really mind.

Sure - and I wouldn't care so much (or, indeed, at all) if Python wasn't my
language of choice for most projects for over 20 years now.

> I suppose it is selfish. But I hope that you [Tim], Guido, and the so
> many others who have poured energy into this project will appreciate
> that it's not the current users, but the next billion (?!) Pythonistas
that
> will really keep the language going.

Which, perhaps paradoxically, is why I'm generally in favor of even small
(but general) improvements. regardless of short-term costs:  so the next
billion Pythonistas can benefit.

> Maintaining popularity among educators is a big part of that.

Oh, I have no idea about that.  I'm at a loss for what accounts for
longer-term language popularity, so I push for things that appeal to me as
a programmer with broad and deep experiences.  Everyone who cares about the
language _should_ be heard, but their motivations don't even need to
overlap.

When I started college, I took classes in every language for which there
was a class: assembler, FORTRAN, LISP, and SNOBOL4.  Three of those survive
as niche languages now, and the last is long dead (damned shame, too!
SNOBOL4 was brilliantly creative).

The last time I had significant contact with academia, Pascal was all the
rage (yes, that dates me).  Not only was it universally loved by educators,
it was in exactly the right place at exactly the right time:  the first
compilers for PCs were for Pascal variants, and things like Turbo Pascal
were hugely (relative to the much smaller user base at the time) popular
and influential.

Try to get a job teaching Pascal now ;-)

So while I don't pretend to know what accounts for longer-term popularity,
"evolve or die" captures a necessary condition.  Any living language that
doesn't continue evolving will die out. Fighting that is like yelling at
clouds.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20180702/817de8a3/attachment.html>