Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)
[Rob Cliffe] > It's late to raise this, By months, yes ;-) > but what exactly are the objections to the syntax > > expr -> name # or variations such as expr => name > > instead of > > name := expr > > > > The PEP mentions that this syntax does not have a problem that "as" > > does, but does not list any downsides of it. My guess: it probably strikes too many as "excessive novelty", These are assignment expressions. Python's assignment statements put the target at the left. Why change that? ":=" is used for assignment in many more other languages than "->" is. Why fight that? > It conforms to left-to-right evaluation, where name:=expr does not. ? Only "expr" is evaluated, so left-to-right seems irrelevant here. The "evaluation" of a simple name as a binding target is a no-op (no code is generated). If you really do see this as a wart anyway, then it's positively a Good Thing that it's exactly the same "wart" as in Python's assignment statements. > It (I would argue) reduces the asymmetry of the first use of a > sub-expression in cases such as > > [ ( (f(x) -> y)**2, y**3, y**4) for x in iterable ] > > vs > > [ ( (y := f(x))**2, y**3, y**4) for x in iterable ] > > because the first "y" is closer to the way it is used, viz "**2". The first form reads a little better to me too, but not a lot better. The problem I have with variations of this example on its own (which comes up surprisingly often with minor changes) is that it's clearer spelled today via [(y**2, y**3, y**4) for y in map(f, iterable)] Spelling that with either form of assignment expression reads significantly worse than that to my eyes But more importantly, it's expected that assignment expressions will be used _most_ often to make some common `if` and `while` patterns briefer. Hardly all. Our eyes are already trained to "look at the far right end" for the value being tested, and, e.g., while data := sock.recv(): preserves that. Especially in code that doesn't _always_ use assignment expressions in such contexts (which is likely all significant blobs of code), it would be visually jarring to have to "sometimes look in the middle instead" to extract the important part of: while sock.recv() -> data: "Look to the left for the name, look to the right for the value" is the rule for assignment statements, assignment expressions, and `for` loop targets. But there's no "QED" here because this isn't a deductive science. The final answer is "because that's what Guido liked best" ;-) ___ 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 Jul 2, 2018, at 8:34 AM, Steven D'Aprano wrote: Guido has decided — and despite my concerns, I’m going to enjoy my new loop-and-a half construct:-) But a comment on this: > comprehension are no more special than > assignments inside any other expression. They bind in the current scope, > same as always, and keep the sensible identity that these two > expressions are exactly equivalent in their visible semantics: > > [x:=0, x:=1, x:=2] > > [x:=i for i in (0, 1, 2)] > > including assignments. Sure — and I don’t think that’s confusing. However, generator expressions ( why don’t we call them generator comprehensions?) are a different story, as they may be run at some arbitrary time in the future. This hasn’t been an issue (except for the loop variable, which has been addressed) because: 1) Much of the time, the gen_ex is run right away, in-line. 2) There aren’t many ways to manipulate the local namespace in a gen_ex. With assignment expressions, it will be much easier to manipulate the local namespace, so there is room for some real confusion here. So a real local namespace gen_exp (and comprehensions, for consistency) would be nice. However, that ship has pretty much sailed. Will it end up being a common problem? Probably not, because (a) is still the case, and := will be used infrequently, and hopefully with unlikely to clash names. And as for all the other languages that have assignment expressions? Do they have constructs like generator expressions? -CHB ___ 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 02/07/2018 19:19, Guido van Rossum wrote: Thank you all. I will accept the PEP as is. I am happy to accept *clarification* updates to the PEP if people care to submit them as PRs to the peps repo (https://github.com/python/peps), and that could even (to some extent) include summaries of discussion we've had, or outright rejected ideas. But even without any of those I think the PEP is very clear so I will not wait very long (maybe a week). It's late to raise this, but what exactly are the objections to the syntax expr -> name # or variations such as expr => name instead of name := expr The PEP mentions that this syntax does not have a problem that "as" does, but does not list any downsides of it. It conforms to left-to-right evaluation, where name:=expr does not. It (I would argue) reduces the asymmetry of the first use of a sub-expression in cases such as [ ( (f(x) -> y)**2, y**3, y**4) for x in iterable ] vs [ ( (y := f(x))**2, y**3, y**4) for x in iterable ] because the first "y" is closer to the way it is used, viz "**2". Regards Rob Cliffe ___ 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)
[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
Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)
Thank you all. I will accept the PEP as is. I am happy to accept *clarification* updates to the PEP if people care to submit them as PRs to the peps repo (https://github.com/python/peps), and that could even (to some extent) include summaries of discussion we've had, or outright rejected ideas. But even without any of those I think the PEP is very clear so I will not wait very long (maybe a week). On Mon, Jul 2, 2018 at 8:38 AM Steven D'Aprano wrote: > On Wed, Jun 27, 2018 at 07:29:52PM -0500, Tim Peters wrote: > [...] > > For example, if the name is declared "global" in the outer scope, you'll > > get a compile-time error if you try to declare it "nonlocal" in the > > contained scope. "parentlocal" adjusts its meaning accordingly, > becoming a > > synonym for "global" in that specific case. > > "Parentlocal" is only a thing if we buy into the paradigm that inside > comprehensions is a separate "local". And *that* is only true under > two circumstances: > > - if you are utterly immersed in the implementation of comprehensions > as invisible, implicit functions; > > - or if you start from the premise that comprehensions ought to > encapsulate not just the loop variable, but anything else as well. > > > But experimenting with locals() inside comprehensions shows that > comprehension-scope *isn't* a well-defined thing. It already bleeds out > of the comprehension, and so would some (but only some!) assignment > expressions. > > Instead, if we start from the premise that comprehensions (like any > other expression) run in the current scope, then there is no need to > invent a term "parentlocal". There's just the usual LEGB scopes, plus > class (which people usually forget). > > With no sublocal scopes (a term we never even had prior to this PEP) > assignments inside the comprehension are no more special than > assignments inside any other expression. They bind in the current scope, > same as always, and keep the sensible identity that these two > expressions are exactly equivalent in their visible semantics: > > [x:=0, x:=1, x:=2] > > [x:=i for i in (0, 1, 2)] > > including assignments. > > What about the loop variable? > > They ARE special, which is completely justified by the Zen: > > Although practicality beats purity. > > We can take a series of ever-more-detailed explanations, starting from > the highest "bird's eye" view and gradually dropping further into the > murky details of the implementation when, and if, required: > > - assignment within comprehensions is no different from assignment > in any other expression, it occurs in the local scope; > > - loop variables? they're a special case, for good reason, and are > encapsulated inside the comprehension; > > - how? they're hidden in an implicit, invisible scope, same as .0 > the implicit, invisible iterator object; > > - oh, you didn't know about the .0 variable? well forget about it, > it's an undocumented implementation detail, just like the invisible, > implicit function used by comprehensions; > > - oh, you didn't know about that either? read the source code. > > > Only the first two levels of explanation are part of Python the > language. The rest is CPython implementation. > > > > -- > 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/guido%40python.org > -- --Guido van Rossum (python.org/~guido) ___ 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] We now have C code coverage!
` # noqa` works with linters --Hobson On Fri, Jun 29, 2018 at 6:25 AM, Brett Cannon wrote: > > > On Thu, Jun 28, 2018, 21:28 Terry Reedy, wrote: > >> On 6/24/2018 5:03 AM, Ammar Askar wrote: >> >> Is it possible, given that we are not paying for those reports, to >> >> customize the 'exclude_lines' definitions? >> > >> > Do you want to exclude python code or C code? >> >> Python code. >> >> > For Python code, coverage.py also has some comments you can >> > put down to exclude lines: >> > http://coverage.readthedocs.io/en/coverage-4.2/excluding.html >> >> Yes, by default, one can use '# pragma: no cover' and if one uses the >> --branch flag, '# pragma: no branch'. For more 'advanced exclusion', >> one can use the following, normally in .coveragerc. >> [report] >> exclude_lines = ... >> "This is useful if you have often-used constructs to exclude that can be >> matched with a regex. You can exclude them all at once without littering >> your code with exclusion pragmas." >> >> For IDLE's test suite, I use a customized .coveragerc. I strongly >> prefer to not abandon that and litter the code with # pragmas. >> >> In order to make sense of the coverage report and have it be truthful, >> one needs to know what options are being used. >> Is the --branch flag set? >> Is .coveragerc or some other configuration file in use? >> If so, what is the content? >> Do we have any control over the use and content of exclusion settings? >> > > Everything is either covered by the Travis or codecov configuration files > which are both checked into the cpython repo. (I'm on vacation or else I > would provide links to the files themselves.) > > > >> -- >> Terry Jan Reedy >> >> ___ >> 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/ >> brett%40python.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/ > hobsonlane%40gmail.com > > ___ 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 Wed, Jun 27, 2018 at 07:29:52PM -0500, Tim Peters wrote: [...] > For example, if the name is declared "global" in the outer scope, you'll > get a compile-time error if you try to declare it "nonlocal" in the > contained scope. "parentlocal" adjusts its meaning accordingly, becoming a > synonym for "global" in that specific case. "Parentlocal" is only a thing if we buy into the paradigm that inside comprehensions is a separate "local". And *that* is only true under two circumstances: - if you are utterly immersed in the implementation of comprehensions as invisible, implicit functions; - or if you start from the premise that comprehensions ought to encapsulate not just the loop variable, but anything else as well. But experimenting with locals() inside comprehensions shows that comprehension-scope *isn't* a well-defined thing. It already bleeds out of the comprehension, and so would some (but only some!) assignment expressions. Instead, if we start from the premise that comprehensions (like any other expression) run in the current scope, then there is no need to invent a term "parentlocal". There's just the usual LEGB scopes, plus class (which people usually forget). With no sublocal scopes (a term we never even had prior to this PEP) assignments inside the comprehension are no more special than assignments inside any other expression. They bind in the current scope, same as always, and keep the sensible identity that these two expressions are exactly equivalent in their visible semantics: [x:=0, x:=1, x:=2] [x:=i for i in (0, 1, 2)] including assignments. What about the loop variable? They ARE special, which is completely justified by the Zen: Although practicality beats purity. We can take a series of ever-more-detailed explanations, starting from the highest "bird's eye" view and gradually dropping further into the murky details of the implementation when, and if, required: - assignment within comprehensions is no different from assignment in any other expression, it occurs in the local scope; - loop variables? they're a special case, for good reason, and are encapsulated inside the comprehension; - how? they're hidden in an implicit, invisible scope, same as .0 the implicit, invisible iterator object; - oh, you didn't know about the .0 variable? well forget about it, it's an undocumented implementation detail, just like the invisible, implicit function used by comprehensions; - oh, you didn't know about that either? read the source code. Only the first two levels of explanation are part of Python the language. The rest is CPython implementation. -- 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 Wed, Jun 27, 2018 at 03:31:42PM -0700, Guido van Rossum wrote: > I'd also like to keep the rule prohibiting use of the same name as a > comprehension loop control variable and as an inline assignment target; > this rule would also prohibit shenanigans with nested comprehensions (for > any set of nested comprehensions, any name that's a loop control variable > in any of them cannot be an inline assignment target in any of them). This > would also apply to the "outermost iterable". +1 -- 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 Mon, Jul 2, 2018 at 2:34 AM Michael Selik wrote: > > On Sun, Jul 1, 2018 at 8:21 PM Matt Arcidy wrote: >> >> [...] Can anyone adequately explain why this specific modality of learning, >> a student-in-a-seat based educator, must outweigh all other modalities [...]? > > > 1. It doesn't. > 2. It's a proxy for the other modes. > > I hope this was an adequate explanation. Absolutely, thank you. We agree it doesn't out weigh other methods. Clearly I disagree about the proxying. ___ 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)]
> I created https://bugs.python.org/issue34022 So I ran test Python test suite of the master branch on Fedora using OpenSUSE configure command: all tests pass. I also run the 6 failing tests of the master branch on Debian Sid using the same configure command than the Debian builder: the 6 tests pass. I also ran the full test suite on Debian Stretch using "./configure": all tests pass. It seems like the package builders have something special, or patches, or the bugs are specific to the 3.7 branch? Victor ___ 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 (on a Linux distro)
On 7/2/2018 3:38 AM, Petr Viktorin wrote: And while I'm responding here, a bit of reflection and a heads-up: What Fedora as a distro should do better next time is re-build the entire ecosystem with a new Python version. For 3.7 we started doing that too late, and there are way too many projects that weren't prepared for `async` as keyword and PEP 479 (StopIteration handling). With the 'next version' now being branched off of master at beta 1 rather than at the first release candidate, 'next time' starts about 4 months sooner than it used to. Doing full builds for 3.8 can start any time. It has already had about 5 months of exclusive patches. This suggests that known changes from pending to deprecation to exception should be done soon after the version branching. I don't know if there are any such still needed for 3.8. -- Terry Jan Reedy ___ 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)]
Hi, 2018-07-01 23:48 GMT+02:00 Matěj Cepl : > 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 created https://bugs.python.org/issue34022 > 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. It seems like it's the same failures. I'm running the Python test suite every day on Fedora and all tests pass. We also run tests multiple times per day on Travis CI (Ubuntu) and buildbots (Debian, Gentoo, RHEL, SLES). Wait, there is a SLES buildbot and all tests pass except of test_gdb.test_threads(). SLES is OpenSUSE no? The Debian buildbot is green on all branches. Ned Deily: > 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. We have 2 buildbot builders testing this configuration, on FreeBSD and Ubuntu. I just ran the full test suite on my Fedora using --enable-shared: all tests pass. --- $ ./configure --enable-shared $ make $ LD_LIBRARY_PATH=$PWD ./python -m test -r -j0 397 tests OK. Total duration: 3 min 9 sec Tests result: SUCCESS --- I also tried after installing Python: all tests pass as well. --- ./configure --enable-shared --prefix=/opt/py37 && make install LD_LIBRARY_PATH=/opt/py37/lib /opt/py37/bin/python3 -m test -r -j0 --- Victor ___ 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 (on a Linux distro)
On Mon, 2018-07-02 at 14:13 +0200, Victor Stinner wrote: > 2018-07-02 9:38 GMT+02:00 Petr Viktorin : > > Fedora* has been building python37 since the alphas, so the > > final update to > > rc/stable was smoother. > > (...) > > * Thanks to Miro Hrončok for most of the work in Fedora > > This work is super useful to prepare third party modules for > Python 3.7, but also to spot regressions and bugs in Python > 3.7. Fedora also helped to detect issues with the latest glibc > for example. I hope to do this as well with openSUSE, but I am just getting into the position, and it is still a lot of struggle. Best, Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 Be pitiful, for every man is fighting a hard battle. -- Ian MacLaren, at least 1898 signature.asc Description: This is a digitally signed message part ___ 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 (on a Linux distro)
2018-07-02 9:38 GMT+02:00 Petr Viktorin : > On 07/02/18 00:59, Miro Hrončok wrote: >> Note that we (=Fedora) unfortunately skip some tests. >> (...) > > [with my Fedora hat on] > > Fedora* has been building python37 since the alphas, so the final update to > rc/stable was smoother. > (...) > * Thanks to Miro Hrončok for most of the work in Fedora (I'm now working in the Python Maintenance team with Petr Viktorin and Miro Hrončok.) This work is super useful to prepare third party modules for Python 3.7, but also to spot regressions and bugs in Python 3.7. Fedora also helped to detect issues with the latest glibc for example. Examples: konlpy fails on 3.7 because calling Py_Initialize() twice fails with a fatal error https://bugs.python.org/issue33932 Setting LANG=C modifies the --version behavior https://bugs.python.org/issue33824 test_crypt segfaults when using libxcrypt instead of libcrypt https://bugs.python.org/issue32635 NIS module fails to build due to the removal of interfaces related to Sun RPC from glibc. https://bugs.python.org/issue32521 Sadly, one issue has been detected too late and has not been fixed before 3.7.0 final: https://bugs.python.org/issue34008 Victor ___ 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:21 PM Matt Arcidy wrote: > [...] Can anyone adequately explain why this specific modality of > learning, a student-in-a-seat based educator, must outweigh all other > modalities [...]? 1. It doesn't. 2. It's a proxy for the other modes. I hope this was an adequate explanation. ___ 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 11:36 PM Tim Peters wrote: > [Michael Selik] > > 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? > Generally between 20 and 40 hours. 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. Will it require you to drop other topics? > Yes. It might not seem like much, 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?" > 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. 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. Meta: About the Vasa, I'm not concerned. > Matt Arcidy brought up an interesting point, which I'll quote here: "... 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." >From my brief observations, it seems that the nattering nabobs of negativism, such as myself, are mostly educators. 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. 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. Maintaining popularity among educators is a big part of that. ___ 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 Mon, 2 Jul 2018 10:25:42 +1000 Steven D'Aprano wrote: > > 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). Those other languages don't have two different assignment operators, AFAIK. That's the main point of complication PEP 572 introduces, not the fact that assignment can now be used in an expression. > 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. I don't think R is easy to understand. It depends on the demographics. For a software engineer like me, it's pretty hard to wrap my head around R's nonsense. I think R is only easy if you accept to use it in a "tinker aimlessly until my code works" manner. Regards Antoine. ___ 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)
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 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
Re: [Python-Dev] Failing tests (on a Linux distro)
On 07/02/18 00:59, Miro Hrončok wrote: 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 [with my Fedora hat on] Fedora* has been building python37 since the alphas, so the final update to rc/stable was smoother. But it also means we aren't solving the same issues as SUSE now, so we won't be able to help all that much :( Do consider trying out alphas/betas in SUSE next time! Anyway, the SUSE tests seem to fail on .pyc files. The main change in that area was [PEP 552], try starting there. AFAIK, SUSE is ahead of Fedora in the reproducible builds area; perhaps that's where the difference is. And while I'm responding here, a bit of reflection and a heads-up: What Fedora as a distro should do better next time is re-build the entire ecosystem with a new Python version. For 3.7 we started doing that too late, and there are way too many projects that weren't prepared for `async` as keyword and PEP 479 (StopIteration handling). If you run into similar problems in SUSE, you might want to take a look at issues tracked under [Fedora bug 1565020]. [PEP 552]: https://www.python.org/dev/peps/pep-0552/ [Fedora bug 1565020]: https://bugzilla.redhat.com/showdependencytree.cgi?id=1565020 * Thanks to Miro Hrončok for most of the work in Fedora ___ 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
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(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
