[Python-ideas] Framework for Python for CS101

[Andrew Barnert]

On Monday, May 25, 2015 5:11 AM, Rustom Mody <rustompmody at gmail.com> wrote:

>On Monday, May 25, 2015 at 1:31:58 PM UTC+5:30, Andrew Barnert via Python-ideas wrote:
>On May 24, 2015, at 22:06, Rustom Mody <rusto... at gmail.com> wrote:
>>
>>
>>Context:  A bunch of my students will be working with me (if all goes according to plan!!)to hack on/in CPython sources. 
>>>
>>>One of the things we would like to try is a framework for CS101 [Intro to programming]
>>>
>>>So for example beginners get knocked out by None 'disappearing' from the prompt
>>>Correctable by
>>>
>>>>>> import sys 
>>>>>> sys.displayhook = print 
>>>
>>>Now of course one can say: "If you want that behavior, set it as you choose"
>>>However at the stage that beginners are knocked down by such, setting up a pythonstartup file is a little premature.
>>>
>>>So the idea (inspired by Scheme's racket) is to have a sequence of 'teachpacks'.
>>>They are like concentric rings, the innermost one being the noob ring, the outermost one being standard python.
>>>
>>
>>How exactly does this work? Is it basically just a custom pythonstartup file that teachers can give to their students? Maybe with some menu- or wizard-based configuration to help create the file? Or is this some different mechanism? If so, what does setting it up, and distributing it to students, look like?
>

>Frankly Ive not thought through these details in detail(!) 

OK, but have you thought through them at all? Or, if not, are you willing to? Without some idea of what the intended interface for teachers and students is, it's going to be very hard to think through how anything else works.

For example, if you have a set of special functions (maybe in a "teachpack" stdlib module) that disable and enable different things in the current Python session, then building a teachpack is just a matter of writing (or GUI-generating) a pythonstartup file with a few function calls, and distributing it to students is just a matter of telling them how to download it and set up the PYTHONSTARTUP environment variable, which seems reasonable. But of course that limits what you can do in these teachpacks to the kinds of things you could change dynamically at runtime.

If, on the other hand, each "surgery" is a patch to CPython, there's no limit to what you can change, but assembling a teachpack is a matter of assembling and applying patches (and hoping they don't conflict), and building CPython for every platform any of the students might use, and then distributing it requires telling them to download an installer and explaining how to make sure they never accidentally run the system Python instead of your build, which doesn't seem reasonable.
>>I realize that below you talk about doing things that are currently not easy to do in a pythonstartup, like hiding all mutating sequence methods, but presumably the patches to the interpreter core would be something like adding hide_mutating_sequence_ methods() and similar functions that teachers could then choose to include in the pythonstartup file or whatever they give out.
>
>I personally would wish for other minor surgeries eg a different keyword from 'def' for generators.
>From the pov of an experienced programmer the mental load of one keyword for two disparate purposes is easy enough to handle and the language clutter from an extra keyword is probably just not worth it.

>However from having taught python for 10+ years I can say this 'overloading' causes endless grief and slowdown of beginners.

>Then there is even more wishful thinking changes -- distinguishing procedure from function.
>After 30 years of Lisp and ML and ... and Haskell and square-peg-into-round-holing these into python, Ive come to the conclusion that Pascal got this distinction more right than all these.  However I expect this surgery to be more invasive and pervasive than I can handle with my (current) resources.


That depends. If you want them to actually be different under the covers, maybe. But if you only care what they look like at the language level, that should be almost as easy as the previous idea. A "defproc" introduces a function definition with an extra flag set; it's an error to use a return statement with a value in any definition being compiled with that flag; there's your definition side. If you want a separate procedure call statement, it's compiled to, in essence, a check that the procedure flag is set on the function's code object, a normal function call, and popping the useless None off the stack, while the function call expression just needs to add a check that the procedure flag is clear.
>etc
>etc
>In short I am talking of a language that is morally equivalent to python but cosmetically different and is designed to be conducive to learning programming


I'm not sure a language that doesn't have any mutating methods, distinguishes procedures from functions, etc. is actually morally equivalent to Python. And this is also straying very far from the original idea of a restricted subset of Python. Adding new syntax and semantics to define explicit generators, or to define and call procedures, is not a subset.

And it's also very different from your original analogy to Racket teachpacks. The idea behind Racket is that Scheme is a language whose implementation is dead-simple, and designed from the start to be extensible at every level, from the syntax up, so almost anything can be done in a library. So, you can start with almost no core stdlib, and then a teachpack is just a handful of stdlib-style functions to do the things the students haven't yet learned how to do (or, sometimes, to standardize what the students did in a previous exercise).

If you really wanted to do this, I think the first step would have to be transforming Python into an extensible language (or transforming CPython or another implementation into a more general implementation) in the same sense as Scheme. Maybe Python plus macros and read-macros would be sufficient for that, but I'm not sure it would be, and, even if it were, it sounds like a much bigger project than you're envisioning.

And honestly, I think it would be less work to design a new language that's effectively Python-esque m-expressions on top of a Scheme core. Since it's "only a toy" language for teaching", you don't need to worry about all kinds of issues that a real language like Python needs to deal with, like making iteration over a zillion items efficient, or having a nice C API, or exposing even the most advanced functionality in an easy-to-use (and easy-to-hook) way.