Suggested PEP sections from PEP 1 and PEP 12

[gvanrossum]

PEP 1 and PEP 12 suggest specific headings for a PEP. While I don't think we need to strictly follow the template, a few are worth adding/modifying:

• Motivation and Rationale: If I understand PEP 12 correctly, motivation is why want to add something -- that's our current Rationale and Goals section, while rationale is an explanation of specific design decisions.

• Backwards Compatibility: We just say "None" but it's a bit subtler than that, with soft keywords requiring a parser with unlimited lookahead/backtracking.

• Security Implications (None)

• How to Teach This: Anyone want to say something about this? How does it change the teachability of Python? Is this something to teach on day 1 or in advanced courses only?

[viridia]

Actually, I think Backwards Compatibility really is "None" - because no existing code should be affected by this change.

(The issue with compatibility of tools might be considered "Forward Compatibility" - I'm not sure.)

In terms of teachability - well, it definitely is an advanced concept. It really depends on the approach you are taking. Consider the following extremes:

• The way I learned programming in the Air Force was first they taught assembly language, then Fortran, then COBOL - so I learned the bottom of the stack first and worked upward.
• The way beginning CS students at MIT used to be taught was using the Abselson and Sussman book, which was a very abstract / algebraic way of thinking about programs, which only in later chapters discussed the way the code was actually executed.
• A lot of students at code camps are just taught Java or Python, with a basic understanding of syntax but no knowledge of the deeper underpinnings.

These different approaches would perceive the "fundamentalness" of match differently; for someone steeped in the algebraic approach, matching is fairly low-level and primitive, whereas someone who thinks in terms of machine instructions would consider it a higher level construct.

[gvanrossum]

Actually, I think Backwards Compatibility really is "None" - because no existing code should be affected by this change.

We know that, but the average reader of the PEP probably has never heard of soft keywords, and in the past discussion of adding pattern matching has often been stymied or at least distracted by the need to come up with a decent keyword. (Ivan's choice for as was also in part guided by this.)

So I think it would be good to discuss why there is no backward compatibility issue. We should also reiterate in this section that we have no intention to ever make match or case into hard keywords (because we don't want to have to break the re.match() API).

teachability

Maybe in this section we could offer a concise tutorial to the new match statement aimed at existing Python users with intermediate skills? Or something that we could add to "the" Python tutorial.

[viridia]

Maybe in this section we could offer a concise tutorial to the new match statement aimed at existing Python users with intermediate skills? Or something that we could add to "the" Python tutorial.

Hmmm. I think perhaps we should wait until after the PEP is accepted - or close to being accepted - before we spend too much effort on tutorials. The audience that this PEP is aimed won't need it, they are presumably capable of figuring out how to use it from the spec. And chances are that this PEP will undergo additional revisions in response to community feedback; and as you probably know, it's more difficult to revise a spec in place than it is to write brand new prose, because there are always little bits of the old design left over that you have to spot and clean up.

[viridia]

I actually think the more important question is, "Is this a win overall?" I mean, it is clearly a win for some kinds of problem sets - the expr.py example is measurably better with match than without it. However, what remains to be seen is how broadly this win applies to other kinds of problem domains and code structures, which we won't know until match is used much more widely.

This Python developer's survey from 2019 shows the various application domains in which Python is used (scroll down to the section "What do you use Python for?"). The top three categories are data analysis, web development, and machine learning. I'm not sure what data analysis means, but I imagine both it and machine learning are heavily oriented towards processing of homogenous numerical data along the lines of numpy or TensorFlow - not much opportunity for using match there.

Web development - something I am a bit more familiar with - is a different story because there are multiple layers involved, each with their own design patterns and structures. However, I doubt match will be used for URL routing, which is handled by existing frameworks such as Django. I could possibly see it being used in the business logic that processes SQL query results, although it would be rare.

It is only when we get to the fifth-most popular category, "web parsers / scrapers / crawlers" that we start to see real opportunities for using match.

Perhaps the thing to do is come up with an example program that falls in that category. I don't have any good ideas at the moment, however.

[gvanrossum]

Yeah, data science and machine learning are responsible for Python's growth in popularity, but they are not very sophisticated Python users -- there just aren't enough sophisticated users to tip the popularity scales. Their training is not in CS but science, math or sales.

If my experience at Dropbox and Google is valid, web developers are more likely to be sophisticated users trained as computer scientists. I think they'll find many uses for match that we haven't thought of. And there's a lot of stuff between SQL and URL routing. Remember that Ivan (a Dropboxer, undoubtedly grepping through the Dropbox server code base) found that isinstance() is the second most common function call, frequently followed by attribute access. That screams class pattern (although quite possibly it also begs for the one-off syntax).

I don't know how web parsers/scrapers/crawlers work these days, but I suspect they do a lot of string processing, for which match is not a great match.

I wonder if decoding JSON makes a decent application? Certainly the mapping and sequence patterns fit nicely with JSON's major data types.

Anyway, I was just hoping we could write something in the "How to teach this" section to satisfy the people who look at every PEP with the perspective of a trainer who has to cram every Python feature in a 5-day class (there are a bunch of those active on python-ideas and some core devs too). Maybe I'll just put a summary in the repo README, which is wildly out of date (again).

[gvanrossum]

Nobody's asked for this, so I'll change this to unpeppable.

[gvanrossum]

Seems to have died down. Closing.