marcelofa / pycee2 Goto Github PK

So when someone installs pycee through PyPI they have an entry point to execute the tool. An addition to this issue is that contributors might want to have the same entry point usage.py outside the module when developing so I need to assure that both ways to use usage.py are possible.

THis might help to fix this issue:
https://python-packaging.readthedocs.io/en/latest/command-line-scripts.html

Initially, Github actions for this project could be very simple and scaled to handle the more complex tasks as needed. In my point of view, the first task where automation is needed is the run of pytest on new pull requests. So then we can have a sanity check on the new code.

• Cache error_info dictionary to reply exactly repeated calls much faster. I'm calling this error level caching. Caching a complex dict like error_info may be time and space consuming, though.
• Add a cache for functions in the answers module that requests data from StackOverflow API. I'm calling this answer level cache. See #33
• pycee command-line tool should have the option to skip the cache and force the API query for development and debugging purposes. (I'm wondering if this is really necessary as having the caching on development will help not bursting StackOverflow with requests.). Maybe this can be implemented for error level caching only.
• Find a solution for the forever increasing cache size. Ideally, we should use an LST (least recently used) approach for deletion but an implementation that has both LST deletion and cache-to-file features is unavailable. A solution would be to fork an existing target project, implementing this, and maybe submit a PR to the target project.

Pycee and PythonBuddy both have no support for the input() function. I see this feature as a great addition as it's common for newcomers to use this builtin on their code examples and exercises.
Pycee could handle this by piping the stdin usage of the subprocess that executes the given code to the main process.

• Inplement support for input() on Pycee
• Inplement support for input() on PythonBuddy

I'd like to replace all relative imports at pycee/with absolute imports as this is a cleaner approach to imports. The only thing stopping me from doing this is that pytest won't recognize the pycee.utils module if I do from utils import foo instead of from .utils import foo

Since this code may have multiple contributors in the future, we need to standardize the code style. For that, the pre-commit will be installed to use Black and Flake8.

I feel comfortable using labels to detail the purpose of the pull request and prevent the same pull request from having multiple responsibilities. I would like to add bug-fix and refactor labels, I'll try to imagine another usefull labels. @marceloFA Accepting suggestions.

pytest can't find the pycee.utils module. Maybe this is some kind of sys.path issue?

(vevn) marcelo@DESKTOP-NNJHC7H:~/pycee2$ pytest tests/
================================================= test session starts ==================================================platform linux -- Python 3.8.5, pytest-6.1.1, py-1.9.0, pluggy-0.13.1
rootdir: /home/marcelo/pycee2
collected 0 items / 1 error

======================================================== ERRORS ========================================================
_________________________________________ ERROR collecting tests/test_pycee.py _________________________________________
ImportError while importing test module '/home/marcelo/pycee2/tests/test_pycee.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
/usr/lib/python3.8/importlib/__init__.py:127: in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
tests/test_pycee.py:1: in <module>
    from pycee.error_info import (
pycee/error_info.py:8: in <module>
    from utils import BUILTINS, EMPTY_STRING
E   ModuleNotFoundError: No module named 'utils'
=============================================== short test summary info ================================================
ERROR tests/test_pycee.py
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Interrupted: 1 error during collection !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
=================================================== 1 error in 0.15s ===================================================

We need to refactor error module because there is some long functions that need to be transformed into smaller functions

I temporarily added a 'fix' for this:

(venv) marcelo@marcelo:~/pycee2$ python3 pycee/pycee.py
Stack overflow thought we were a bot (in fact are we?)
To temporarily fix this please open the link below on the browser and do the following:
1 - Solve the captcha
2-Close the browser tab
3- Execute pycee2 again
https://stackoverflow.com/search?q=[python]+answers:1..+ModuleNotFoundError:+No+module+named+'kivy'
Anyway, remember to solve this issue, please ;)
No Results!

The actual fix would be to consult StackExchange API without any web scraping at all.
This would be quite a large work on the pycee.query_stack_api module

Supose a.py contains:

print('No code errors here')

if we run pycee a.py, we'll get:

beeblebrox@DESKTOP-NNJHC7H:~$ pycee a.py
Traceback (most recent call last):
  File "/home/beeblebrox/.pyenv/versions/3.7.9/bin/pycee", line 8, in <module>
    sys.exit(main())
  File "/home/beeblebrox/.pyenv/versions/3.7.9/bin/usage.py", line 11, in main
    error_info = get_error_info(args.file_name)
  File "/home/beeblebrox/.pyenv/versions/3.7.9/lib/python3.7/site-packages/pycee/inspection.py", line 20, in get_error_info
    code = get_code(file_name)
  File "/home/beeblebrox/.pyenv/versions/3.7.9/lib/python3.7/site-packages/pycee/inspection.py", line 153, in get_code
    with open(file_path, "r") as file:
TypeError: expected str, bytes or os.PathLike object, not NoneType

The behavior we expect is actually:

beeblebrox@DESKTOP-NNJHC7H:~$ pycee a.py
Nice! It seems that your code has no errors.

PythonBuddy is an open-source online python editor that is a good choice to integrate Pycee 2 with.

Some of the work needed to finish this feature would be:

• Make pycee 2 a pip installable package;

• Fork PythonBuddy and create the internal logic to integrate Pycee 2 in it;

• Implement a feature that allows users to navigate through collected answers;

• Implement a feature that allows users to leave feedback on the answers given to them;

• Add integration tests to the integration;

• Decide on a free (and possibly limited) cloud service to host PythonBuddy +Pycee 2;

• Deploy the application

We still have no license and in order to publish Pycee 2 as a python package and later as a web code editor, we certainly will need one. I've been thinking of the MIT license for this project as it is very simple and permissive but some discussion on this is certainly needed. This source has a few relevant information on the MIT license if someone wants to better understand it.

As mentioned by Leonardo, one important consideration is the license used by PythonBuddy, BSD-3. Their license allows for modification and distribution, which are our expected usage cases of their project, so I think it's fine and won't cause us problems.

Pycee 2 should be well-covered tests to assure as much as possible we're deploying it free of bugs.
This issue can be decomposed into the following smaller tasks:

• Add a tool to check for test coverage;
• Assert current code is well covered;
• Assert any new code also has its test coverage included in new PRs;

This is very valuable to the final users and can be separated into these following smaller tasks, for each error type:

• Consider if the current error handler could be improved. For this, I assume the heuristic that the less we process an error message, the better it is for Stackoverlfow to find the relevant related questions (and answers).
• Consider if the error has a simple nature, namely, it is only raised on a few and specific occasions. If this is the case, a handler that builds a helper message to the user manually, considering the context of this error (offending line variables, imported packages, etc) might be of greater help to the user.
• Consider if the built-in help system can be useful for error you're working on. Sometimes pydocs can be simple, understandable, and useful (and sometimes not).
• Consider how the most relevant SO questions on the error type are asked, maybe this will help you build a better error handler.
• Consider something that is not listed above to improve the error messages. I just put up on here some of my ideas on the topic but surely there are more ways to build great queries, which will lead us to great answers for final users.

I would like to suggest an update on all docstrings before we add/remove more code.

I think we need to turn this code more "clean" to understand where we started from, and what we did about it. It is interesting to know what our methods do today, or what they will start to do, or why they ceased to exist in the future.

This tool should be well covered in tests. Some initial test I can think of are related to the file_name argument:

• missing path to file raises an easy to understand error
• invalid path to file raises an easy to understand error