hello pycon welcome back uh you're back
with the education track
and uh this talk is a pre-recorded talk
but with a special super exciting twist
um the fantastic andre roberge will be
joining us uh for his talk it doesn't
work uh and he will also be joining us
in the chat um on the stream yard chat
you will be able to interact with him
during the talk and
he'll join us live afterwards
um for some questions so
without further ado uh i should
introduce him he's not here i'm
forgetting my things okay so andre first
learned programming by taking a course
in fortran when he was a teenager but he
never had much use for it uh in 2004
while in his 40s he decided to pick up
programming as a hobby and a creative
outlet to distract him from his day job
that sounds fantastic i love it
since then he mostly focused on creating
programs and programming environments
intended to help beginners learn his
favorite hobby
these include uh rupple reeborgs world
avant pai and a few others with the
latest being friendly
so
i will
pass over to the pre-recorded talk um
think up some questions put them in the
chat put them in the questions chat
and we'll answer them all throughout and
after thank you so much
welcome to it doesn't work
a talk given as part of the education
track of pycon australia 2021
my name is andre robert joining you
today from canada where i live and have
fun with python
note that many slides shown during the
stock include tiny xkcd cartoon panels
too small for you to read during the
presentation
these are intended to provide additional
entertainment to people that have
downloaded the slides
since this is the education track i'm
assuming that you have taught or planned
to teach python to someone else that i
will refer to as your students
your students have python including idle
installed on a computer
you decide to introduce them to python
using the turtle module starting with a
complete example
you show them how to run a program
success a square has been drawn
your students copied a code from your
example and attempt to run it
it doesn't work
they see virtual red ink in their
experience red ink is not a good thing
they take a closer look at the content
and see a lot of unknown jargon
traceback attribute error partially
initialized module circular import etc
at this point your students might get
discouraged thinking that programming is
not for them
they feel inadequate and might just want
to give up
could this be made more user-friendly
before we see if this is possible
let's review the type of information we
can get from a normal python traceback
we can see where in the code the error
occurred
we can see what type of exception was
raised
the message gives us an idea as to why
the exception was raised
of course it requires some experience to
be able to decipher such tracebacks
something that we cannot expect
beginners to be able to do on their own
what if there existed a better way
on the left we have a normal traceback
what if we could have like what is shown
on the right side a modified version
with shorter lines and some black and
blue in addition to the red
let's zoom in to this modified traceback
this is the modified traceback
student might perhaps recognize more
easily the text in black as being the
code they wrote
at the bottom
except for the word module
what if a nearly jargon-free easy to
understand sentence was added giving
them a hint of what might be the source
of their problem
did you give your program the same name
as a python module
when using idle we have access to a
python interpreter after running a
program
if students didn't know about python
exceptions what if asking what could
reveal the meaning of the exception in
this case here an attribute error
what if asking where would show the
location of the error more explicitly
than a traditional traceback would
we see the part in the line highlighted
in red indicating the exact location of
the problematic code
at the bottom we see a reference to
turtle.py
before continuing with this example
let me show you a similar where output
from a different example
here at the bottom instead of turtle.py
we see pythonlib turtle.py
this tells us that the code is from
python standards library and not code
written by a student
unlike what we saw with the previous
example
let's go back to that example
what if asking why gave the student a
more complete explanation as to what
might have caused the problem they have
encountered
and
if this was not enough what if there
existed yet one more option
what if typing www as a function
used python's web browser module to do
an internet search with the error
message used as a search string
all of this is possible using friendly
or friendly traceback
let's have a look at a second example
during pycon australia 2018 much fun was
had talking about something called a
flip-flop rater
the code shown on this slide was used in
an example
this code includes a text
i have had a great day with this large
boy mr bubble
you may also know him as masjid chunky
bubble or mr loves to eat the food bobo
here i show the result when i attempt to
run this example using friendly in a
terminal instead of with an idle
i get a trace back with a name error
the text in white at the bottom is a
hint headed by friendly
asking why gives us a fuller explanation
as to what might have caused the problem
it suggests that we might have forgotten
to install the module from pipi
note that friendly also subscribes to
the notion that using the flips operator
is a bad idea
when i watch the talks about the flips
operator i notice the use of the phrase
music
clearly this one example was an
indication that there must be a thriving
french-speaking community in australia
assuming they are watching this talk
those french-speaking pathonistas should
be pleased to know that friendly can
give them information in their preferred
language
this is the end of a rather long
introduction
for the rest of this talk i'd like to
give you a brief historical overview of
the evolution of friendly initially
known as friendly traceback
showing a few more examples
then i will attempt to justify the
approach i use in developing friendly by
using some work from experts in the
field
the purpose of this talk is to motivate
you to use friendly with your students
my hope is that in return you will
provide me with some feedback so that i
can make it even better
when i created friendly traceback my
initial idea was to create a tool that
could help students decipher normal
python tracebacks
so that they could eventually learn to
extract the what where and why on their
own
initially i thought of simply taking the
message included in the traceback
reformulating it so that students could
make better sense of it
and make it possible to translate this
reform loaded message into languages
other than english
so
given an error like what is shown name
error name misu is not defined
friendly trace backwards to provide all
the information shown on this slide
what is a name error
an explanation that might be useful if
such an error is encountered for the
first time
but might become superfluous after a
while
why this error might have occurred
and where exactly in the code
this is the information provided by
friendly traceback with overlaid boxes
on the slide to make it easier to parse
of course in reality
these boxes are not present and we see a
big chunk of text
here instead of using friendly traceback
i used friendly which does some
additional formatting including adding
colors
these added colors should make it easier
to parse the information
still having all information shown at
once especially with more complex
examples can lead to a huge wall of text
this led me to add the functions what
where and why that can be used
interactively to obtain only parts of
the information when required
for example why
in your program no object with the name
must you exist
i have no additional information for you
originally from the traceback did not
add i have no additional information for
you
since that was always the case
however
that has since changed as i will show in
a different example later
of course this approach of explaining
what a given exception means and what
might have caused the error simply based
on the text provided by python
is not exactly helpful when the message
is simply invalid syntax
so a little over two years ago i figured
out a way to automatically analyze a few
invalid syntax cases
and wrote a blog post inviting other
people to suggest additional examples
it did not take long for the first
suggestion to come in
over time a few more suggestions were
made encouraging me to pursue further on
my own in attempt to analyze more and
more cases
here's an example done while using new
arguably the most beginner-friendly
python editor that exists
i first start by importing everything
from friendly.new
after importing the turtle module i try
to call pen
which results in a traceback
friendly sand at the bottom includes two
suggestions
either a typo was made and i meant to
write the built-in lan instead of pen
or since span is an attribute of turtle
a module that was previously imported
perhaps a reference to that module is
missing
mu has different themes
switching to the knight theme changes
the color
and the output provided by friendly no
micro blends in
when using friendly with mu in a night
theme a student or teacher can type in
knight as a function
so that the information displayed
afterwards by friendly matches the theme
used by mu
asking y
results in a more detailed explanation
than that given by the hint added at the
bottom of the traceback by friendly
in the previous example you might have
noticed that i use a star import which
is generally frowned upon usually for
good reasons
i don't have enough time in this talk to
explain why i nonetheless suggest to do
so
i invite you to consult the
documentation for the detailed
explanation and for suggested
alternatives specific to friendly
such as the one i will show in the next
example
here's an example of a normal traceback
created when using the latest version of
jupiter lab
the details of the code are important
however i want to draw your attention to
the weird file name we see in a
traceback
how is a student supposed to make sense
of this information
let's use friendly
this time by importing a single object
from friendly.jupiter
as an alternative to doing a star import
while it is not needed i adjusted the
friendliest theme to better match the
jupiter light theme
i also set the width of friendly's
output so that it made for better screen
captures for the stock
i now run the same code as before
notice how instead of some weird file
names the traceback include references
to code blocks which is the terminology
used in jupiter's documentation
if i want to know the cause of the
problem according to friendly this time
i cannot simply type the function y
since i did not use a star import
instead i can use the y method of the
friendly object to achieve the same goal
i've mentioned friendly and friendly
trace pack
initially the project was called
friendly traceback and later renamed
friendly
at the end of june of this year the
project was split into two projects move
from my personal github site to a new
friendly traceback organization i
created
friendly traceback does the analysis
required to provide answers to the what
where and why i mentioned before
friendly takes care of providing the
required formatting in a variety of
environments
interpreters using terminals editors
such as idle and mu ipython console
jupyter notebooks etc
it builds upon friendly traceback
friendly is also the program most users
should install
some third party projects
such as the websites hack in science and
future quarter
use information provided by friendly
traceback and do their own formatting
the split was done on the request of one
of those third-party users who found the
additional dependencies to be
detrimental to the performance of their
site
the approach i use in developing
friendly is to add new examples one at a
time
trying to find a way to automatically
identify the relevant information
and providing explanations that can be
easily understood
currently there are more than 300
individual cases for which friendly can
provide an explanation
those cases were either some of my own
or very often suggested by other users
while i keep adding new examples i
rarely go back and revisit explanations
given in older examples
so i encourage all of you to look at the
examples which are all available in the
documentation site
and invite you to either suggest new
examples or better explanations for the
existing ones
when using an interactive interpreter it
is unfortunately very easy to make typos
causing spurious race-backs
can an interactive python interpreter be
user-friendly
here i have some code that caused a
traceback
i want to find out why
but i made a typo in writing the
function name at the top
this should be easy to correct given the
hint provided by friendly
i typed it correctly this time
but it does not give me the explanation
i needed
it told me that i made a mistake in
typing out y which i already knew and
has nothing to do with the first
traceback
by using the history function i can view
all the exceptions raised so far
i can go back in history
thus erasing the latest mistake
i can now ask why
and get an explanation for the first
traceback as i wanted in the first place
since recording a first version of this
talk i've added a new way to use
friendly within jupiter notebooks and
similar environments
instead of having to type what where and
why the user can simply click on buttons
to show or hide the corresponding
explanation
thus eliminating typo related problems
in these environments
in trying to improve friendly there's
always a question at the back of my mind
am i making the right choices
so far i have had some feedback from
individual users who are advanced python
programmers
but there has been no systematic
evaluation done with actual beginners
in the absence of such studies i
recently read a paper on the topic after
i saw a link to it on twitter
on designing programming error messages
for novices
readability and its constituent factors
while reading this paper i noted that
the problems associated with bad error
messages have been discussed for a few
decades without being solved
according to that paper there are two
important factors for readability of
error messages
message length and use of jargon
ideally one should
remove jargon in acronyms
write messages in complete sentences
use simple vocabulary
use an economy of words
so complete but short sentences
the paper focused on readability which
the authors deem to be more fundamental
than usability
by usability they mean how useful is the
information provided in finding a
solution to the problem
the others are groups of students
evaluating error messages from java c
and python
i expected the results to be that error
messages from java were two verbose
those from c to cryptic
and those from python just right
i was wrong
error messages from python were rated as
the worst of the three
let's consider why that might be the
case using the first example shown at
the beginning of this talk
prior to version 3.8
the error message provided by python was
relatively short
module turtle has no attribute forward
this message did not contain any
additional information about the actual
cause
then more information was added
potentially useful to more advanced
programmers
but full of jargon that cannot be
understood by beginners
however when using friendly with any
python version
an additional hint is provided which
should be
more easily understood by beginners
to be fair i must note that some recent
improvement for python where some
invalid syntax messages have been
replaced by something more useful
for example
errors due to forgetting to close a
parenthesis
are now identified correctly in python
3.10
here's the same example run with
friendly which gives the same correct
explanation for all supported python
versions
even if you only get an invalid syntax
error message
python caters to all kinds of
programmers
from beginners just learning the basics
to advanced programmers using python in
their daily job
when it comes to error messages
it would seem that python seeks a middle
ground and occasionally uses jargon not
accessible to beginners
by contrast friendly attempts to cater
to such beginners
let's have a look at a different example
where python gives an error message that
is rather obscure for beginners
none type object is not subscriptable
using friendly and asking why
gives us an explanation
but no actual clue as to what the object
causing the problem is
the note at the bottom explain what the
non-type jargon means
asking where gives us more information
friendly traceback always attempts to
isolate the part of the code that causes
problems and
identify the value of each object
here we have a dict x containing other
python digs
at the very bottom we can see that x
bracket 42 bracket 1 bracket 2 has the
value of none which is the cause of the
problem
this almost concludes this introductory
talk to friendly and friendly traceback
to find out more you could use a search
engine to find out friendly's
documentation
but there's a better way
first install friendly
start the friendly console
typing in friendly provides some basic
help
to find out even more type www as a
function
assuming you write this function call
without making any typo no exception
will have been raised and instead of
doing an internet search that function
will take you to friendly's
documentation
as in addition to unit tests i record
almost all the example tracebacks for
different python versions in a
documentation
this occasionally helps to spot
regressions it is also useful to review
the explanation given
i encourage you to do so and make
suggestions to improve them
you might also come across some notices
about design choices
these are two record choices i make for
friendly traceback inviting you to
comment about their suitability perhaps
there are better ways to present the
information
of course using pip to install packages
such as friendly is often something that
beginners find difficult ideally there
should be a better way
perhaps friendly will be installed by
default in a future version of new as
has been recorded on mu's github repo by
nicholas tallarvy muse creator
one of the main ipython and jupiter
developer has expressed support for
enabling friendly by default if it is
installed
in conclusion
i invite you to try out friendly
read the documentation and give feedback
so that it can hopefully make friendly
even more useful for you and for your
students
and of course i will come any question
you might have
thank you
um immediately after lunch we have
a fantastic talk by steven and allison
on at the turn of the tide teaching
python in real time at scale so make
sure you all join us for that one in the
meantime andre thank you once again uh
have a fantastic lunch everyone and
we'll see you soon
cheers thank you