Some more comments. Sorry, this is going to be long.
André wrote:
"Due to the addition of these soft keywords, parsing Python code became
much more complex and required a change to a new type of parser (PEG
parser) which even experienced programmers find challenging to master."
You have the causality backwards there.
The PEG parser was not introduced in order to add the match statement
and soft keywords. Soft keywords were included because we had already
changed to the PEG parser, which made it much, much easier to include
soft keywords instead of the old LL(1) parser.
Which actually wasn’t precisely LL(1).
The old LL(1) parser did, sometimes, use soft-keywords, e.g. at one
point “as” was a soft-keyword, only becoming a full reserved keyword in
Python 2.6 (with a warning in 2.5).
I’m not terribly impressed by the Twitter thread you linked to. The only
concrete complaint made about PEG parsers in general was:
"One complaint about PEGs is that they are very hard to compare against
the theoretical framework of the rest of the parsing world."
in other words academics don’t like PEG because it doesn’t fit their
theories.
In any case, the difficulty of writing or understanding a PEG parser is
irrelevant here. You don’t have to write a PEG parser or understand how
CPython’s parser works in order to read Python code.
André said:
"This ever-increasing complexity can make it more difficult to create
and maintain tools designed to help beginners understand what went wrong
in their program or to help them avoid errors."
Does it? How? These tools are surely not writing their own parsers for
Python code, instead of using the stdlib AST libraries to use Python’s
own parser.
In any case, do you imagine that these tools will only support your
Python 101? Linters, code checkers, IDEs and other tools are extensively
used by experienced developers who want to use the full set of Python
language features.
Even if Python 101 exists, these tools will still have to support the
full set of Python features.
André again:
"Something like Python 101 would flag advanced syntax as invalid and
help educators teach their students the basics of Python programming
before moving on to more advanced topics."
This sounds like an horrific nightmare scenario. Imagine doing a course
where you are forced to program below your capability, punishing the
advanced students while not actually helping the under-achievers.
Aside from academic fraud, which is pretty easily handled at this level:
"Hello student Fred, can you please explain what lines 30 and 31 of your
script are doing?"
how do you think students are writing code that is beyond their
capability? If students haven’t learned about comprehensions, do you
think they just pushed keys at random and a working comprehension
appeared in their code? Obviously not.
So why punish them for writing comprehensions, if they know how to use
them?
André quotes Greg Wilson:
"It’s easy to say, “Just ignore decorators and async I/O and the :=
operator in class,” but that’s disingenuous. Newcomers will bump into
these things as soon as they search online for help, because they
actually are helpful for people who are programming in the large; that’s
just not my use case."
Right. And they are also useful for newcomers too, which is why Python
101 is a terrible idea. Python 101 is essentially a way of punishing
students who can and do learn from unapproved sources such as on-line
resources.
When the student tries to run some Python code, they find it doesn’t
work. If they are an advanced student who understands that they are
programming in a straight-jacket with Python 101, they will feel
frustrated that they have to dumb down their code just to satisfy the
compiler and instructor.
And if they are not advanced, they will be utterly perplexed why the
code doesn’t work. Have they done something wrong when the internet says
it should work?
No. The error comes from the instructor, who claims to be teaching
Python, but is actually teaching another language, a subset of Python.