Home Original page

[Python-ideas] Framework for Python for CS101

Wes Turner wes.turner at gmail.com
Wed May 27 00:58:57 CEST 2015 
On Tue, May 26, 2015 at 5:41 PM, Steven D'Aprano <steve at pearwood.info>
wrote:

> On Tue, May 26, 2015 at 01:19:59PM -0500, Wes Turner wrote:
>
> > Ways to teach Python from first principles:
>
> Most of these methods fail to teach *Python*. They teach something
> similar, but different to, Python: almost-Python.
>
> If Rustom wishes to fork Python to create his own version of almost-
> Python, he doesn't need to discuss it here. I'd rather he didn't discuss
> it here -- this is PYTHON-ideas, not Cobra-ideas, or Lua-ideas, or
> Rustom's-purely-functional-almost-python-ideas.
>

I agree.

* Language syntax propositions -> python-ideas at python.org
  * Or, if not feasible for the general community,
     RPython and Sandboxing research do identify
     methods for (more than) syntactical restriction
* Teaching -> edu-sig at python.org
   * IPython Notebook, JupyterHub
     * A custom interpreter with RPython and a custom Jupyter kernel
       may be of use.


>
> There is, or at least was, a strong tradition of creating specialist
> teaching languages, starting with Pascal which developed as a more
> restricted and more pure form of Algol. But this is not the place to
> discuss it.
>

https://en.wikipedia.org/wiki/History_of_Python


>
>
> > * Restrict the syntactical token list ("switch features on and off")
> >   * Fork Python
> >   * RPython -- https://rpython.readthedocs.org/en/latest/
>
> I'm pretty sure that RPython is not designed as a teaching language. The
> PyPy guys are fairly insistent that RPython is not a general purpose
> language, but exists for one reason and one reason only: building
> compilers.
>

Rather than forking, writing an interpeter may be more maintainable
(and relatively consistent with a widely-deployed language with versioned
semantics):

https://rpython.readthedocs.org/en/latest/#writing-your-own-interpreter-in-rpython


>
>
> >   * https://pypi.python.org/pypi/RestrictedPython
> >   * http://pyvideo.org/video/2585/building-and-breaking-a-python-sandbox
> >   * OR: execute code in container (e.g. LXC, LXD, Docker (JupyterHub);
> > virtualization)
>
> Sandboxing Python and restricting the functionality of almost-Python are
> unrelated issues. Purely functional almost-Python would want to replace
> things like dict.update which modifies the dict in place with a built-in
> function which returns a new, updated, dict. Running regular Python in a
> container doesn't make it almost-Python, it is still regular Python.
>

If hosting (or trying to maintain n shells), sandboxing and containers are
directly relevant.

* IPython notebooks can be converted to edX courses (link above)
* There are reproducible Dockerfiles for development and education
* A custom interpreter with RPython and a custom Jupyter kernel may be of
use.

Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150526/a95e50f8/attachment-0001.html>
More information about the Python-ideas mailing list