Write bad code to win a prize

 

Summary

Get a chance of winning a prize by writing code with ONE error that Friendly-traceback cannot properly analyze, in one of three categories:

• SyntaxError: invalid syntax
• SyntaxError: some message, where some message is not recognized.
• Any case of NameError, AttributeError, ModuleNotFoundError, UnboundLocalError, ImportError, IndexError, KeyError that is not recognized or is given an incorrect explanation by Friendly-traceback.

Submitted issues about bugs for Friendly-traceback itself are also considered for this contest.

Links: Github issue

Friendly-traceback documentation

The prize

There will be one prize given drawn randomly from all eligible submissions. The prize consists of one ebook/pbook of your choice with a maximum value of 50 USD (including delivery for pbook) as long as I can order it and have it delivered to you. Alternatively, a donation for that amount to the open source project of your choice if it can be made using Paypal.

The details

Each valid issue will get one entry for the contest. Valid issues contain code that might be expected to be written by a beginner or advanced beginner. It excludes code that uses type annotations as well as the use of async and await keywords.  The code is expected to contain ONE mistake only and not generate secondary exceptions.

The code can be run either using the friendly-console, or running in a Jupyter environment or from an editor as described in the documentation.

For a given valid submission, a bonus entry will be given if a link can be provided to an actual example from a site (such as StackOverflow, /r/python or /r/learnpython, etc.) where a question had been asked prior to this contest.

Exceptions that are not recognized by Friendly-traceback or for which the explanation (in English or French) is wrong or misleading are considered to be valid issues.

Submissions that are considered to be duplicate of previously submitted cases (because they basically have the same cause) will not be considered.

Honor code

I would ask that you do not read the source of Friendly-traceback with the sole intent of finding ways to write code that is designed to lead it to provide incorrect explanations.

End of contest

The contest will end on Monday January 25, at 8 AM Atlantic Standard Time.

Friendly-traceback du jour (Dec. 20/2020)

 

Friendly-traceback du jour (Dec. 19/2020)

 

Friendly-traceback of the day (Dec. 18/20)

Feel free to make suggestions as to what other Exception could benefit from a Friendly-traceback treatment.

pytest apparently modifies calls to range

 As I work making Friendly-traceback provide more useful information regarding the cause of an exception, I sometimes encounter weird "corner cases" about either Python itself [1] or occasionally about pytest [2]. Today, it was pytest's turn to give me a new puzzle to solve.

Consider the following:

range(1.0)

If you run this, Python will give you a TypeError: 'float' object cannot be interpreted as an integer

Using Friendly-traceback's console [3], I get something slightly more informative.

Actually, I can get even more information using "explain()":

Time to add this new working case to the unit test suite. I create a barebone one for the purpose of this blog, without capturing the output and comparing with what is expected.

import friendly_traceback

def test():
    try:
        range(1.0)
    except:
        friendly_traceback.explain_traceback()

if __name__ == '__main__':
    test()

Here's what happens if I run this using Python:

(1) is a "hint" that gets added to the traceback shown by Friendly-traceback. (2) is part of the more detailed explanation, available by typing "why()" in a Friendly console. So far, everything looks as expected.

In order to provide this kind of explanation, Friendly-traceback looks at the content of the frame where the exception was raised and does its best to deduce what needs to be changed. For example, if we modify the above example to use a variable called "end" instead of using a literal, here's what we get.

When writing unit tests, I make sure that such highlighted hints are reproduced exactly in the output that is captured. So, what happens if we run the previous example using pytest? ...

A new float variable, "start", has suddenly appeared, seemingly out of nowhere. Note that this pytest oddity is not revealed if we use a string instead of a float as the wrong type of argument.

Time to move on to handling other cases ...

[1] See this blogpost.

[2] An issue that I filed about a previous case seems to have disappeared and all that remains is this question on Stack Overflow.

[3] This is my local development version; the example shown here will be handled by versions 0.2.8 and later, to be released on pypi.

IPython and Friendly-traceback

 This is a quick update on the status of Friendly-traceback. As of today, it works with the IPython console, and works even better in a JupyterLab environment.  

First, a comparison with using it in the new Windows terminal making use of Rich for syntax highlighting, which is something that has been working for quite a while now.

Next, is the same example in an IPython console, running in a Windows terminal.

I've tried to use Rich to do syntax colouring with the IPython console ... but the result is really disappointing. 

Finally, here's what it looks like in the JupyterLab environment.

Right now, it is not possible to select a different theme for syntax highlighting; this will have to wait until later.

To find out more about Friendly-traceback (excluding this new IPython experimental support), please consult the documentation.

Friendly-traceback: work in progress

 It's been almost two months since my last blog post and I feel guilty of not having taken the time to write more regularly.  I should really tell you about how fantastic Will McGugan's Rich is, and how I have customized it for my projects. I should also tell you how Sylvain Desodt's DidYouMeanPython has been influencing Friendly-traceback latest developments. Also worthy of note is how Alex Hall's FutureCoder project is incorporating so many neat tools that it feels like a real honour that he has incorporated Friendly-traceback in it.

Alas, while I have been busy making many changes and addition to the code, the documentation is hopelessly behind and no longer gives a correct picture of what Friendly-traceback is now capable of.

So much to do, so little time. So, I will just end with a picture, and go back to coding, with a promise of writing more ... soon I hope.