Dealing with restrictions

Restrictions rétablies

Avec la même idée, mais pas appliquée "au même endroit": les fonctions interdites sont maintenant définies directement dans le scope global, au lieu de hacker le contenu de __builtins__.

• les restrictions n'affectent plus pyodide lui-même (exception faite de la fonction d'import, mais cela ne devrait pas poser problème, à moins d'interdire un module de base, comme sys, os, ... ATTENTION: l'argument WHITE (white_list) ne permet pas de contourner cette limitation !
• Puisque les fonctions hackées sont dans le scope global, elles sont tout de suite visibles en faisant un dir() dans le terminal, et effacer ces fonctions (del sorted) suffit à redonner l'accès à la fonction d'origine. Pour éviter que cela soit aussi simple, ou pour éviter qu'un élève écrase l'une de ces fonctions par erreur, une vérification est faite après que le code de l'utilisateur ait été exécuté, pour être sûr que les fonctions hackées sont tjrs là et n'ont pas changé (nota:si on sait ce qui est fait ici, il est assez facile de contourner cette limitation, donc les erreurs sont peu explicites à ce sujet).

Récupérer la fonction d'origine depuis les tests:

Un nouvel outil est défini (caché) dans les builtins, qui permet d'extraire la fonction originellement interdite dans tests: move_forward("nom_truc_interdit") (le nom est choisi par opposition à get_back, qui est ce que la fonction fait réellement => au cas où des élèves regardent dans __builtins__...) À noter que si la fonction d'origine est récupérée, elle ne doit pas écraser celle définie dans le scope global, donc les tests l'utilisant doivent être faits dans une fonction:

# ...
def anti_leak():
    sorted = move_forward('sorted')
    arr = [1,3,7,1,25,8,5,2]
    exp = sorted(arr)
    assert func(arr) == exp, "some message"

anti_leak()