Incorporate friendly-traceback into Mu

[ntoll]

See: aroberge/friendly#26 (comment) for context.

I imagine if the friendly-traceback flag in Mu is true, then when any Python3 code is run or debugged, then the wonderful friendly-traceback should wrap it so the user gets comprehensible error messages.

Thanks to @aroberge for all his amazing work on friendly-traceback (Mu is standing on the shoulders of giants etc...) 👍

[aroberge]

I was wondering if some information could be provided to users of Mu (possibly targeted at teachers) asking them to report any Python error message that they or their students find confusing. Even if friendly-traceback is not available yet in Mu, such information could be useful for friendly-traceback's development and its future use in Mu.

Looking at the Mu website, perhaps this could be added on https://codewith.mu/en/howto/1.0/bugs or https://codewith.mu/en/tutorials/1.0/problems ... although these deal with problems specific to Mu, and not Python. Of course, once friendly-traceback is incorporated into Mu, I imagine that a specific "how to use" page will be created for it, which would be a more appropriate place to give such information.

And to anyone reading this: if you know of cases where Python tracebacks were not helpful in helping students find the cause of their problems, you might want to see if they would have been helped by existing cases in https://aroberge.github.io/friendly-traceback-docs/docs/html/ and, if not, feel free to file an issue here: https://github.com/aroberge/friendly-traceback/issues

[aroberge]

I did not realize that one could now install third-party package inside Mu. It did fail for some reason when I tried with the alpha version, but installing the regular version over it, worked.

So, perhaps for the more adventurous ...

[aroberge]

The following results in something less confusing to the end user.

import friendly_traceback as fr

fr.install()
fr.exclude_file_from_traceback(__file__)

import test_mu

I should probably rename exclude_file_from_traceback to exclude_file, and possibly use __file__ as a default ...

[aroberge]

Ready to experiment with: https://aroberge.github.io/friendly-traceback-docs/docs/html/mu.html

[aroberge]

Question: what would be the "friendliest" code to ask people to write?

from friendly_traceback import run_program

result = run_program("my_program", __file__)
locals.update(result)

from friendly_traceback import run_program

locals.update( run_program("my_program", __file__) )

from friendly_traceback import run_program

run_program("my_program", __file__, locals())

I have tested locally a slightly different implementation that would work with the third one.

[tmontes]

@aroberge, I may be a bit out of context and, certainly, away from friendly-traceback's implementation details, but here are my impressions.

The options you shared feel very alien to beginners, IMO:

• Referring to the user's program as a str, implying that they would need two files to benefit from friendly-traceback (too much work? error prone?).
• Usage of mysterious "things" like locals and __file__.

I wonder if importing friendly_traceback couldn't be made to be enough - that would be the friendliest possible (other than having Mu importing it automatically behind the scenes, which I just thought about but think would deserve discussion).

The idea is that import friendly_traceback would have the side-effect of setting sys.excepthook to its friendly traceback display implementation. So, as long as users import it right from the start -- something that's easy to do and that beginner's are taught early (imports at the top!) -- then they would benefit from it. :)

Does this make any sense or am I missing something?

[aroberge]

@tmontes Slapping my own forehead! ... Of course ... or rather, yes, but ... At the moment, my preference is for not doing this by default. I may change my mind later, based on users' experience, or further thoughts from you or from others reading this.

Do you think that the following would be an acceptable compromise?

from friendly_traceback import help_me

and, for French users,

from friendly_traceback import aide_moi

... and hopefully a Portuguese version as well! ;-)

Instead of help_me, perhaps explain might be a better choice if this type of import would be acceptable. (I already use explain for something else; I would have to change that.)

Or perhaps help_Mu ... :-)

I definitely can make something like that work: all that is required, is to create one module per language with something the following two lines:

from . import public_api
public_api.install(lang="fr")

If the installation is done automatically upon normal import, we'd have the following situation:

# English user
import friendly_traceback

# French user
import friendly_traceback
friendly_traceback.set_lang("fr")

= = =
Regarding Mu importing friendly_traceback automatically: I'm thinking that it makes sense to not do this, at least not yet.

1. I wouldn't want any potential bugs in Friendly-traceback create problems for Mu users. If such bugs are present, they can easily be avoided by not adding this explicit import.
2. Given its simplicity compared with Mu, it is much simpler for me to make changes (based on feedback from users) and issue a new release which can be made readily available, sometimes in just a few hours after getting the feedback.

Perhaps when Friendly-traceback reaches version 1.0 (and Mu reaches version 2.0), this idea could be revisited.

[tmontes]

Do you think that the following would be an acceptable compromise?

from friendly_traceback import help_me

and, for French users,

from friendly_traceback import aide_moi

... and hopefully a Portuguese version as well! ;-)

I hadn't thought about the important per-language variations.
I'd love to contribute to such a Portuguese one, but no commitments, for now, ok? :-)

If the installation is done automatically upon normal import, we'd have the following situation:

# English user
import friendly_traceback

# French user
import friendly_traceback
friendly_traceback.set_lang("fr")

Ideally it could default to detect the user's UI language preference and use that -- non-trivial to do in a cross-platform way, I suppose.

The vision is that a French user would get nice French explanations with just import friendly_traceback, while a Chinese one, running the same import, would get Chinese explanations. :) Of course, the possiblitiy of overriding such default with friendly_traceback.set_lang would be very welcome.

One thing to consider is language variations like "de_DE" vs "de_CH", "en_GB" vs "en_US", "pt_PT" vs. "pt_BR", "es_ES" vs "es_MX", etc. :)

[aroberge]

I hadn't thought about the important per-language variations. I'd love to contribute to such a Portuguese one, but no commitments, for now, ok? :-)

Ok, anytime. :-)

If the installation is done automatically upon normal import, we'd have the following situation: # English userimport friendly_traceback # French userimport friendly_traceback friendly_traceback.set_lang("fr") Ideally it could default to detect the user's UI language preference and use that -- non-trivial to do in a cross-platform way, I suppose.

In a very early version, I picked up the language settings from the locale (which meant French for me). I changed that as I believe it makes sense to use English as the language used for development and testing without having to specify it.

The vision is that a French user would get nice French explanations with just import friendly_traceback, while a Chinese one, running the same import, would get Chinese explanations. :) Of course, the possiblitiy of overriding such default with friendly_traceback.set_lang would be very welcome.

`set_lang` is already supported. Giving a user an easy way to select language is something I really wish Mu would offer.

One thing to consider is language variations like "de_DE" vs "de_CH", "en_GB" vs "en_US", "pt_PT" vs. "pt_BR", "es_ES" vs "es_MX", etc. :)

This is already supported - in theory anyway. —

…

You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#963?email_source=notifications&email_token=AAEZXQWCNQAZUKEKJTJUWTDQZIBLTA5CNFSM4JTKNIF2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHFZOWI#issuecomment-566990681>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEZXQW26SXZKD7ICVS2Z5LQZIBLTANCNFSM4JTKNIFQ> .

[tmontes]

set_lang is already supported. Giving a user an easy way to select language is something I really wish Mu would offer.

Agreed, much like your request in #518, comments in #692, and my proposal in this comment, there. :)

[aroberge]

@tmontes Thank you for pointing me in the right direction. I was thinking of a possible future version of Mu, where one might have an extra option to click on a button to "run with Friendly-traceback" without modifying the user's code. To do this, the original approach I implemented would have been unavoidable. Of course, it is much simpler to have students add a single import line at the top. The documentation (https://aroberge.github.io/friendly-traceback-docs/docs/html/mu.html) for Friendly-traceback has now been updated to reflect this simpler approach.

[ZanderBrown]

non-trivial to do in a cross-platform way, I suppose

Python has a module for everything, including locale

ZanderBrown recently wrote a neat little flask app and was reminded just how much python has a module for everything

[tmontes]

Python has a module for everything, including locale

It does, and it does somewhat of bad job for our needs, I'd say:

• Depends on a few environment variables on macOS that, unfortunately, are not set when the program is not launched from a CLI shell -- such as the macOS packaged Mu version when launched by double clicking in the Finder (see Locale settings are not reflected in macOS #572 and the Improved language detection code with custom fallback for macOS. #672 fix, as well as the improvements in Much simpler locale detection code #763 / Much simpler locale detection, now relying on Qt's QLocale. #764).
• It reports the wrong language on Windows when the user interface language is different from the system default (see the just logged Windows | UI Language wrong if user preference != system default #976).

...but it kind of works! :-)

[tmontes]

@tmontes Thank you for pointing me in the right direction. I was thinking of a possible future version of Mu, where one might have an extra option to click on a button to "run with Friendly-traceback" without modifying the user's code. To do this, the original approach I implemented would have been unavoidable.

Agreed. That would be code that Mu would run under the hood to provide friendly tracebacks to beginners, regardless of users code, yes.

Of course, it is much simpler to have students add a single import line at the top. The documentation (https://aroberge.github.io/friendly-traceback-docs/docs/html/mu.html) for Friendly-traceback has now been updated to reflect this simpler approach.

Looking better and better. :)