Saturday, August 22, 2020
Monday, August 10, 2020
After a couple of hours of work, I have been able to use Rich to add colour to Friendly-traceback. Rich is a fantastic project, which has already gotten a fair bit of attention and deserves even more.
The following is just a preview of things to come; it is just a quick proof of concept.
Tuesday, August 04, 2020
Wednesday, July 29, 2020
I learned about it via an issue filed for Friendly-traceback: yes, HackInScience does use Friendly-traceback to provide feedback to users when their code raises Python exceptions. These real-life experiences have resulted in additional cases being covered by Friendly-traceback: there are now 128 different test cases, each providing more helpful explanation as to what went wrong than that offered by Python. Python versions 3.6 to 3.9 inclusively are supported.
Previously, I thought I would get feedback about missing cases from teachers or beginners using either Mu or Thonny - both of which can make use of Friendly-traceback. However, this has not been the case yet, and this makes me extremely grateful for the feedback received from HackInScience.
While Friendly-traceback can provide feedback in either English or French , HackInScience only uses the English version - this, in spite of the fact that it was created by four French programmers. I suspect that it is only a matter of time until they make a French version of their site.
One excellent additional feature provided by HackInScience is the addition of formatting (including some colour) in the output provided by Friendly-traceback.
The additional cases provided by Julien Palard from HackInScience have motivated me to clear out the accumulated backlog of test cases I had identified on my own. Now, there is only one (new) issue: enabling coloured output from Friendly-traceback's console.
Please, feel free to interrupt my work on this new issue by submitting new cases that are not covered by Friendly-traceback! ;-)
 Anyone interested in providing translations in other languages is definitely welcome!
Monday, March 02, 2020
The first clue
The first clue is that, rather than executing test.py as the main module, I imported it. Can you think of a situation where this would make a difference?
I'll leave a bit of space below to give you the opportunity to possibly go back to part 1, without reading about the solution below.
Back in 2002, with the adoption of PEP 302, Python enabled programmers to modify what happens when a module is imported; this is known as an import hook. For example, it is possible to modify the source code in a module prior to it being executed by Python. This is NOT what I have done here - but I have done this for other examples that I will refer to below.
If the only thing required would be to modify the source, one could use what is described in PEP 263 and define a custom encoding that would transform the source. In this case, by adding an encoding declaration, it would have been possible to run test.py directly rather than executing it. I thought of it a while ago but, in order to cover all possible cases, one would pretty much have to write a complete parser for Python that could be used to identify and replace the various assignments statement done by print statements so as to show what you saw in part 1. However, this still would not be enough to protect against the reassignement done externally, like I did with
test.UPPERCASE = 1
The actual solution I used required three separate steps. The challenge I will mention at the end is to reduce this to two steps - something that I think is quite possible but that I have not been able to do yet - and to remove one left-over "cheat" which would allow one to redefine a constant by monkeypatching. I think that this is possible but I have not actually sat down to actually do it. I thought of waiting for a few days to give an added incentive for anyone who would like to try and get the bragging rights of having it done first! ;-)
Step 1Step 1 and 2 involve an import hook. They are independent one of another and can be done in any order.
When importing a module, Python roughly does the following:
- Find the source code
- Create a module object
- Execute the source code in the module object's dict.
test.__dict__["UPPERCASE"] = "new value"
This is because the module's __dict__ is a "normal" Python dict.
However, instead of using a module object created by Python, it should be possible to create a custom module object that uses something like the special dict mentioned before. Thus one would not need to change the way that Python execute code in the module's dict.
The challenge is to write code that creates such a module object. I would not be surprised if there remained some other ways to cheat after doing so, but hopefully none as obvious as the one shown above.
The code I have written is part of my project named ideas. The actual code for the constants example is given by this link. See also the documentation for the project. Note that, token_utils mentioned in the documentation has been put in a separate project; I need to update the documentation.
Both ideas and token-utils can be installed from Pypi.org as usual.
In many programming languages, you can define constants via some special declaration. For example, in Java you can apparently write something like:
public static final String CONST_NAME = "Name";
and this will result in a value that cannot be changed. I wrote "apparently" since I do not program in Java and rely on what other people write.
Everyone "knows" that you cannot do the same in Python. If you want to define constants, according to Python's PEP 8, what you should do is the following
Constants are usually defined on a module level and written in all capital letters with underscores separating words. Examples include MAX_OVERFLOW and TOTAL.and rely on the fact that everyone will respect this convention. However, nothing prevents you from redefining the value of these variables later in the same module, or from outside (monkeypatching) when importing the module.
Thus, if I write in a module
TOTAL = 1
# some code
TOTAL = 2
the value of the variable will have changed.
If you are willing to use optional type declaration and either use Python 3.8 with the typing module, or some earlier version of Python but using also the third-party typing-extension package, you can use something like the following:
TOTAL: Final = 0
from typing import Final
and use a tool like mypy that will check to see if the value of is changed anywhere, reporting if it does so. However, if you do run such an incorrect program (according to mypy), it will still execute properly, and the value of the "constant" will indeed change.
For people that want something a bit more robust, it is often recommended to use some special object (that could live in a separate module) whose attributes cannot change once assigned. However, this does not prevent one from deleting the value of the "constant object" (either by mistake within the module, or by monkeypatching) and reassign it.
Every Python programmer knows that the situation as described above is the final word on the possibility of creating constants in Python ... or is it?
For example, here's a screen capture of an actual module (called test.py)
Notice how the linter in my editor has flagged an apparent error (using UPPERCASE after deleting it.) And here's the result of importing this module, and then attempting to change the value of the constant.
Can you think of how I might have done this? (No photoshop, only the normal Python interpreter used.)
In part 2 , I explain how I have done this and will leave you with a (small) challenge.