Friendly-traceback: useful tool for those teaching Python
Hello everyone, For about 20 months now, I have been working on a Python package intended to help beginners figure out what went wrong when their program generates a traceback. This package is called Friendly-traceback; you can find the fairly extensive documentation at https://aroberge.github.io/friendly-traceback-docs/docs/html/ Friendly-traceback can be used to run programs from the command line, or from an editor; it also comes with its own REPL. Jupyter notebooks are also supported. While there is still much to be added to it (I don't know if I'll ever reach a "complete enough" version to be designated as version 1.0), I would appreciate feedback from those of you who teach beginners (or advanced beginners), including any suggestion as to how it could be made more useful. All the best and stay safe, André Roberge
On Tue, Feb 2, 2021 at 5:48 AM André Roberge <andre.roberge@gmail.com> wrote:
Hello everyone,
For about 20 months now, I have been working on a Python package intended to help beginners figure out what went wrong when their program generates a traceback. This package is called Friendly-traceback; you can find the fairly extensive documentation at https://aroberge.github.io/friendly-traceback-docs/docs/html/
Hi André -- I'm reading your docs now. When I start into Python with beginners, I'll typically start with:
dir( ) # how will HyperKitty mangle this?
showing what's in the namespace, the names Python knows when "in" the namespace. But then the question right away arises: where are print, hex, str, dict... all these names Python knows? Answer (as we all know): __builtins__ So then I do a dir(__builtins__) [ pray to HyperKitty for no mangling ] and they see: Wow! Lots and Lots of names (so that's where everyone has been hiding), many with Error and/or Warning in them. Those come at the top as dir returns string elements alphabetically and capitalized Exceptions list up top (or leftmost). This will be my bridge to your Friendly-Traceback utility i.e. here would be an (early, introductory) example of a 3rd party project aimed at helping a beginner get the most out of the Python experience. Tracebacks themselves have that purpose already, and you're enhancing that existing capability, which is easy for beginners to understand. Make a good thing better. A current weakness in my curriculum is I don't spend enough time on IDE features relating to debugging and live inspecting of what's in the namespace. I demonstrate a lot using Spyder, assuring them a different IDE is just fine. Spyder has features that make it great for screen sharing Python, such as scrollback, the %magics, embedded plots... Anyway, my point is Exceptions and the Tracebacks they occasion, deserve a direct and early discussion, as any beginner is likely to stumble across both in the course of ordinary REPL use. I'm still adding pages to my most recent iteration of an Elite School (and I do have synchronous students -- we meet once a week). We'll be discussing your innovative enhancements. Ideally, at least one of us (most likely me) will install it and do Show & Tell (a Lightning Talk). Back to reading the docs... Kirby
On Tue, Feb 2, 2021 at 2:37 PM kirby urner <kirby.urner@gmail.com> wrote:
On Tue, Feb 2, 2021 at 5:48 AM André Roberge <andre.roberge@gmail.com> wrote:
Hello everyone,
For about 20 months now, I have been working on a Python package intended to help beginners figure out what went wrong when their program generates a traceback. This package is called Friendly-traceback; you can find the fairly extensive documentation at https://aroberge.github.io/friendly-traceback-docs/docs/html/
Hi André --
I'm reading your docs now.
When I start into Python with beginners, I'll typically start with:
dir( ) # how will HyperKitty mangle this?
showing what's in the namespace, the names Python knows when "in" the namespace.
But then the question right away arises: where are print, hex, str, dict... all these names Python knows?
Answer (as we all know): __builtins__
So then I do a dir(__builtins__)
I think you mean simply __builtins__, without the dir(). I use "pretty" from Rich ( https://rich.readthedocs.io/en/latest/introduction.html?highlight=pretty#pyt...) so that dicts are nicely formatted.
[ pray to HyperKitty for no mangling ] and they see:
Wow! Lots and Lots of names (so that's where everyone has been hiding), many with Error and/or Warning in them. Those come at the top as dir returns string elements alphabetically and capitalized Exceptions list up top (or leftmost).
This will be my bridge to your Friendly-Traceback utility i.e. here would be an (early, introductory) example of a 3rd party project aimed at helping a beginner get the most out of the Python experience.
Tracebacks themselves have that purpose already, and you're enhancing that existing capability, which is easy for beginners to understand. Make a good thing better.
A current weakness in my curriculum is I don't spend enough time on IDE features relating to debugging and live inspecting of what's in the namespace. I demonstrate a lot using Spyder, assuring them a different IDE is just fine. Spyder has features that make it great for screen sharing Python, such as scrollback, the %magics, embedded plots...
Anyway, my point is Exceptions and the Tracebacks they occasion, deserve a direct and early discussion, as any beginner is likely to stumble across both in the course of ordinary REPL use.
I'm still adding pages to my most recent iteration of an Elite School (and I do have synchronous students -- we meet once a week). We'll be discussing your innovative enhancements. Ideally, at least one of us (most likely me) will install it and do Show & Tell (a Lightning Talk).
Back to reading the docs...
Kirby
On Tue, Feb 2, 2021 at 11:28 AM André Roberge <andre.roberge@gmail.com> wrote:
On Tue, Feb 2, 2021 at 2:37 PM kirby urner <kirby.urner@gmail.com> wrote:
On Tue, Feb 2, 2021 at 5:48 AM André Roberge <andre.roberge@gmail.com> wrote:
Hello everyone,
For about 20 months now, I have been working on a Python package intended to help beginners figure out what went wrong when their program generates a traceback. This package is called Friendly-traceback; you can find the fairly extensive documentation at https://aroberge.github.io/friendly-traceback-docs/docs/html/
Hi André --
I'm reading your docs now.
When I start into Python with beginners, I'll typically start with:
dir( ) # how will HyperKitty mangle this?
Hah hah, look what HyperKitty did: https://mail.python.org/archives/list/edu-sig@python.org/message/C6CF53KBJNL... I'd say HyperKitty is not very friendly to the indigenous Python we used to share here.
showing what's in the namespace, the names Python knows when "in" the namespace.
But then the question right away arises: where are print, hex, str, dict... all these names Python knows?
Answer (as we all know): __builtins__
So then I do a dir(__builtins__)
I think you mean simply __builtins__, without the dir(). I use "pretty" from Rich ( https://rich.readthedocs.io/en/latest/introduction.html?highlight=pretty#pyt...) so that dicts are nicely formatted.
Like in this screenshot: https://www.flickr.com/photos/kirbyurner/50905387656/in/album-72157660337424... You have to feed __builtins__ (not quoted) to dir( ) to dump its contents as a list of strings. That solves the mystery of where quit, range, map, complex, abs and so on and on are coming from. Python knows these names and yet dir( ) -- with no argument -- does not reveal them to be present in the top-level namespace (__main__). I describe __builtins__ as like a "utility belt" of tools around your waist, so close at hand that it's unnecessary to import them. We're expanding out in concentric shells, taking in more and more of what constitutes "Python". I introduce my Five Dimensions (or Layers): 0. Core syntax: keywords and punctuation (including indentation) 1. __builtins__ 2. __ribs__ i.e. special names, magic methods, the scaffolding 3. Standard Library (batteries included) 4. 3rd Party ecosystem (from small like friendly-traceback, and rich all the way to giant frameworks like SQLAlchemy and Twisted -- to name some of the early big projects And of course your own RUR-PLE). I tell students the optimum learning curve is not about mastering all of level 0, then moving to level 1 and so on (plodding, methodical, unproductive). No, it's about spiraling, and going a little deeper into each level as we progress. So in the very first lesson I'm likely to: (a) talk about the five levels and (b) dump the contents of __builtins__ (c) remark on the "funny look" of __rib__-syntax. I'm giving them a sense of the big picture, and how much there is to know about (e.g. "Python includes about fifty special names but you will use far fewer than that on a regular basis"). In dumping the contents of builtins, I'm getting my segue to Exceptions (so much of what's in there are "flags" that might get raised). I speak very metaphorically e.g. how when you're new to an environment you're always bumping up against limits, like a baby. Or you're new to a certain sport and don't really know the rules yet. What's a foul? Can I pick up the ball and just run with it? That depends on the namespace, and the rules. Exceptions are about doing something other than crashing when a rule is broken. The environment pushes back, telling you what went wrong. Python creates such an environment for us the moment we enter the REPL. We're free to play in it, to explore, and understanding the Exceptions are there for our convenience and instruction makes them not scary. Noobs are conscientiously afraid of "breaking things" and a teacher's role includes showing safe ways to explore and gain fluency. From Exceptions, it's but a short step to try except syntax (level 0) and Tracebacks (debugger, diagnostics, IDE features, your enhancements -- level 4). Kirby
You can export notebook inputs to (hopefully mostly hyperkitty-compatible) Markdown with jupytext: ```bash conda install -c jupytext jupyterlab jupyter-lab # Pair with Markdown, light, percent, hydrogen # Click refresh in the file pane to see the jupytext-linked copy ``` Pandoc can convert the html version of a notebook (with output; i.e. from nbconvert) to e.g. 'gfm' GitHub-flavored Markdown On Wed, Feb 3, 2021, 12:34 kirby urner <kirby.urner@gmail.com> wrote:
On Tue, Feb 2, 2021 at 11:28 AM André Roberge <andre.roberge@gmail.com> wrote:
On Tue, Feb 2, 2021 at 2:37 PM kirby urner <kirby.urner@gmail.com> wrote:
On Tue, Feb 2, 2021 at 5:48 AM André Roberge <andre.roberge@gmail.com> wrote:
Hello everyone,
For about 20 months now, I have been working on a Python package intended to help beginners figure out what went wrong when their program generates a traceback. This package is called Friendly-traceback; you can find the fairly extensive documentation at https://aroberge.github.io/friendly-traceback-docs/docs/html/
Hi André --
I'm reading your docs now.
When I start into Python with beginners, I'll typically start with:
dir( ) # how will HyperKitty mangle this?
Hah hah, look what HyperKitty did:
https://mail.python.org/archives/list/edu-sig@python.org/message/C6CF53KBJNL...
I'd say HyperKitty is not very friendly to the indigenous Python we used to share here.
showing what's in the namespace, the names Python knows when "in" the namespace.
But then the question right away arises: where are print, hex, str, dict... all these names Python knows?
Answer (as we all know): __builtins__
So then I do a dir(__builtins__)
I think you mean simply __builtins__, without the dir(). I use "pretty" from Rich ( https://rich.readthedocs.io/en/latest/introduction.html?highlight=pretty#pyt...) so that dicts are nicely formatted.
Like in this screenshot:
https://www.flickr.com/photos/kirbyurner/50905387656/in/album-72157660337424...
You have to feed __builtins__ (not quoted) to dir( ) to dump its contents as a list of strings. That solves the mystery of where quit, range, map, complex, abs and so on and on are coming from. Python knows these names and yet dir( ) -- with no argument -- does not reveal them to be present in the top-level namespace (__main__). I describe __builtins__ as like a "utility belt" of tools around your waist, so close at hand that it's unnecessary to import them.
We're expanding out in concentric shells, taking in more and more of what constitutes "Python". I introduce my Five Dimensions (or Layers):
0. Core syntax: keywords and punctuation (including indentation) 1. __builtins__ 2. __ribs__ i.e. special names, magic methods, the scaffolding 3. Standard Library (batteries included) 4. 3rd Party ecosystem (from small like friendly-traceback, and rich all the way to giant frameworks like SQLAlchemy and Twisted -- to name some of the early big projects And of course your own RUR-PLE).
I tell students the optimum learning curve is not about mastering all of level 0, then moving to level 1 and so on (plodding, methodical, unproductive). No, it's about spiraling, and going a little deeper into each level as we progress. So in the very first lesson I'm likely to:
(a) talk about the five levels and (b) dump the contents of __builtins__ (c) remark on the "funny look" of __rib__-syntax.
I'm giving them a sense of the big picture, and how much there is to know about (e.g. "Python includes about fifty special names but you will use far fewer than that on a regular basis").
In dumping the contents of builtins, I'm getting my segue to Exceptions (so much of what's in there are "flags" that might get raised).
I speak very metaphorically e.g. how when you're new to an environment you're always bumping up against limits, like a baby. Or you're new to a certain sport and don't really know the rules yet. What's a foul? Can I pick up the ball and just run with it? That depends on the namespace, and the rules. Exceptions are about doing something other than crashing when a rule is broken.
The environment pushes back, telling you what went wrong. Python creates such an environment for us the moment we enter the REPL. We're free to play in it, to explore, and understanding the Exceptions are there for our convenience and instruction makes them not scary. Noobs are conscientiously afraid of "breaking things" and a teacher's role includes showing safe ways to explore and gain fluency.
From Exceptions, it's but a short step to try except syntax (level 0) and Tracebacks (debugger, diagnostics, IDE features, your enhancements -- level 4).
Kirby
_______________________________________________ Edu-sig mailing list -- edu-sig@python.org To unsubscribe send an email to edu-sig-leave@python.org https://mail.python.org/mailman3/lists/edu-sig.python.org/ Member address: wes.turner@gmail.com
%doctest_mode? output from IPython probably needs to be wrapped in a fenced code block?: ```python
help(help) help(dir) dir(dir) help(__import__('IPython.display.display'))
On Wed, Feb 3, 2021, 15:41 Wes Turner <wes.turner@gmail.com> wrote:
> You can export notebook inputs to (hopefully mostly hyperkitty-compatible)
> Markdown with jupytext:
>
> ```bash
> conda install -c jupytext jupyterlab
> jupyter-lab
> # Pair with Markdown, light, percent, hydrogen
> # Click refresh in the file pane to see the jupytext-linked copy
> ```
>
> Pandoc can convert the html version of a notebook (with output; i.e. from
> nbconvert) to e.g. 'gfm' GitHub-flavored Markdown
>
> On Wed, Feb 3, 2021, 12:34 kirby urner <kirby.urner@gmail.com> wrote:
>
>>
>>
>> On Tue, Feb 2, 2021 at 11:28 AM André Roberge <andre.roberge@gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Tue, Feb 2, 2021 at 2:37 PM kirby urner <kirby.urner@gmail.com>
>>> wrote:
>>>
>>>> On Tue, Feb 2, 2021 at 5:48 AM André Roberge <andre.roberge@gmail.com>
>>>> wrote:
>>>>
>>>>> Hello everyone,
>>>>>
>>>>> For about 20 months now, I have been working on a Python package
>>>>> intended to help beginners figure out what went wrong when their program
>>>>> generates a traceback. This package is called Friendly-traceback; you can
>>>>> find the fairly extensive documentation at
>>>>> https://aroberge.github.io/friendly-traceback-docs/docs/html/
>>>>>
>>>>>
>>>> Hi André --
>>>>
>>>> I'm reading your docs now.
>>>>
>>>> When I start into Python with beginners, I'll typically start with:
>>>>
>>>> >>> dir( ) # how will HyperKitty mangle this?
>>>>
>>>
>> Hah hah, look what HyperKitty did:
>>
>>
>> https://mail.python.org/archives/list/edu-sig@python.org/message/C6CF53KBJNLM7CF6QT35VBCCTWBTDNBU/
>>
>> I'd say HyperKitty is not very friendly to the indigenous Python we used
>> to share here.
>>
>>
>>>>
>>>
>>>> showing what's in the namespace, the names Python
>>>> knows when "in" the namespace.
>>>>
>>>> But then the question right away arises: where are
>>>> print, hex, str, dict... all these names Python knows?
>>>>
>>>> Answer (as we all know): __builtins__
>>>>
>>>> So then I do a dir(__builtins__)
>>>>
>>>
>>> I think you mean simply __builtins__, without the dir(). I use
>>> "pretty" from Rich (
>>> https://rich.readthedocs.io/en/latest/introduction.html?highlight=pretty#python-in-the-repl)
>>> so that dicts are nicely formatted.
>>>
>>>
>> Like in this screenshot:
>>
>>
>> https://www.flickr.com/photos/kirbyurner/50905387656/in/album-72157660337424600/
>>
>> You have to feed __builtins__ (not quoted) to dir( ) to dump its contents
>> as
>> a list of strings. That solves the mystery of where quit, range, map,
>> complex,
>> abs and so on and on are coming from. Python knows these names and yet
>> dir( ) -- with no argument -- does not reveal them to be present in the
>> top-level
>> namespace (__main__). I describe __builtins__ as like a "utility belt" of
>> tools
>> around your waist, so close at hand that it's unnecessary to import them.
>>
>> We're expanding out in concentric shells, taking in more and more of
>> what constitutes "Python". I introduce my Five Dimensions (or Layers):
>>
>> 0. Core syntax: keywords and punctuation (including indentation)
>> 1. __builtins__
>> 2. __ribs__ i.e. special names, magic methods, the scaffolding
>> 3. Standard Library (batteries included)
>> 4. 3rd Party ecosystem (from small like friendly-traceback, and rich
>> all the way to giant frameworks like SQLAlchemy and Twisted -- to
>> name some of the early big projects And of course your own RUR-PLE).
>>
>> I tell students the optimum learning curve is not about mastering all
>> of level 0, then moving to level 1 and so on (plodding, methodical,
>> unproductive). No, it's about spiraling, and going a little deeper
>> into each level as we progress. So in the very first lesson I'm likely
>> to:
>>
>> (a) talk about the five levels and
>> (b) dump the contents of __builtins__
>> (c) remark on the "funny look" of __rib__-syntax.
>>
>> I'm giving them a sense of the big picture, and how much there is to
>> know about (e.g. "Python includes about fifty special names but you
>> will use far fewer than that on a regular basis").
>>
>> In dumping the contents of builtins, I'm getting my segue to Exceptions
>> (so much of what's in there are "flags" that might get raised).
>>
>> I speak very metaphorically e.g. how when you're new to an environment
>> you're always bumping up against limits, like a baby. Or you're new to a
>> certain sport and don't really know the rules yet. What's a foul? Can I
>> pick up the ball and just run with it? That depends on the namespace,
>> and the rules. Exceptions are about doing something other than crashing
>> when a rule is broken.
>>
>> The environment pushes back, telling you what went wrong. Python
>> creates such an environment for us the moment we enter the REPL.
>> We're free to play in it, to explore, and understanding the Exceptions
>> are there for our convenience and instruction makes them not scary.
>> Noobs are conscientiously afraid of "breaking things" and a teacher's
>> role includes showing safe ways to explore and gain fluency.
>>
>> From Exceptions, it's but a short step to try except syntax (level 0) and
>> Tracebacks (debugger, diagnostics, IDE features, your enhancements
>> -- level 4).
>>
>> Kirby
>>
>> _______________________________________________
>> Edu-sig mailing list -- edu-sig@python.org
>> To unsubscribe send an email to edu-sig-leave@python.org
>> https://mail.python.org/mailman3/lists/edu-sig.python.org/
>> Member address: wes.turner@gmail.com
>>
>
participants (3)
-
André Roberge -
kirby urner -
Wes Turner