Manage your exceptions in Python like a PRO

When running tryceratops if any of the files aren't able to process, more information should be returned about which files can't be processed.

Specifically, running tryceratops on a simple project with only 16 files returns the following:

Done processing! 🦖✨
Processed 16 files
Found 0 violations
Failed to process 1 files
Skipped 2340 files

Without knowing which file failed to process, I'm not sure what, if anything, I should do for next steps.

This message comes from interfaces.py line 51

Isn't the naming unfortunate when there is already a Python module called triceratops?

• https://pypi.org/project/triceratops/
• https://pypi.org/project/tryceratops/

It seems there can be an encoding issue with the text in "Done processing" on Windows with anaconda:

File "C:\Users\anon\.cache\pre-commit\repoqfqlxkvs\py_env-python3\lib\site-packages\tryceratops\interfaces.py", line 50, in _present_status
    print("Done processing! \U0001f996\u2728")
  File "c:\Users\anon\anaconda3\lib\encodings\cp1252.py", line 19, in encode
    return codecs.charmap_encode(input,self.errors,encoding_table)[0]
UnicodeEncodeError: 'charmap' codec can't encode characters in position 17-18: character maps to <undefined>

Hi there,

A couple of times on existing code bases I've ran into a problem with built-in exceptions. I'm hoping to interest you into accepting it into this project, as it's the closest I've seen so far to the use case.

A simple GitHub search results in many codebases struggling with this pattern.

The issue

Often built-in exceptions are used regardless of their semantics. This results in confusing diagnostic information for the user.

if isinstance(my_var, int):
    pass
else:
    raise ValueError("...") #should be typeerror

The above examples has variations with multiple elif statements and other exception types as RuntimeError.

Similarly, if the if/elif conditions check values, not type, then a TypeError is misleading.

Proposed solution

Detect these patterns and report them, ideally fix them automatically (as pyupgrade would do).

Are you open to including this functionality in the package? If you're to busy, but open, then the community could take a turn (hacktoberfest).

I installed tryceratops and tryceratops.exe got installed into a folder that is not on my PATH variable.

What I usually do, to run things like black, is python -m black, and the same thing works for tryceratops, naturally.

However, some of the command-line options give generic info back because __name__ is now "__main__":

 > python -m tryceratops --version
__main__.py, version 0.2.3

and

 > python -m tryceratops --help
Usage: __main__.py [OPTIONS] [DIR]...
# omitted

Notice both appearances of __main__.py where I expected tryceratops or tryceratops.py. In my opinion the __main__.py doesn't look good, in a stylistic sense.

Current Click specification actually disallows Click ^8. This is causing dependency issues for me. This PR loosens the requirements to allow ^8 and ^7. This might not actually be desired, and we might want to constrain to ^8.0, but wanted to keep changes to a minimum for now. All tests are passing on Click 8.0.3.

Thanks for the project!

Hi! Enjoying the project!

One issue I have come across again is that this project's dependecy pinning causes conflicts with other libraries

It happened once before to Click, and recently again have had trouble with Rich.

• https://github.com/guilatrova/tryceratops/pull/39
• https://github.com/guilatrova/tryceratops/pull/46

Rich itself updates major versions pretty often, so this is likely to happen again in the future.

Two solutions:

1. Unpin the dependencies, this is becoming more popular. It just involves switching from pining to the major version to just enforcing a minmum version.

   - rich = "^10.14.0"
   + rich = ">=10.14.0"
   

2. Use an automation tool like Dependabot to keep your depenencies up to date, and update often.

Happy to help with either of these if you are interested.

Again, thanks for the tool!

Edit: Wrong article was linked in first point (it supported the second point)

Hello, thank you for this tool, I appreciate it.

I encountered a crash on some code with git artifact not removed:

Traceback (most recent call last):
  File "/home/psassoulas/.cache/pre-commit/repo1clg70g2/py_env-python3/lib/python3.8/site-packages/tryceratops/files/discovery.py", line 54, in _parse_python_files_from_dir
    parsed, filefilter = parse_file(filename)
  File "/home/psassoulas/.cache/pre-commit/repo1clg70g2/py_env-python3/lib/python3.8/site-packages/tryceratops/files/parser.py", line 42, in parse_file
    tree = parse_tree(content)
  File "/home/psassoulas/.cache/pre-commit/repo1clg70g2/py_env-python3/lib/python3.8/site-packages/tryceratops/files/parser.py", line 37, in parse_tree
    return ast.parse(content.read())
  File "/usr/lib/python3.8/ast.py", line 47, in parse
    return compile(source, filename, mode, flags,
  File "<unknown>", line 74
    <<<<<<< Updated upstream

Thanks for sharing this work. Interesting idea for a linter!

When ran from a pre-commit hook as a local hook:

repos:
  - repo: local
    hooks:
      - id: tryceratops
        name: tryceratops
        entry: tryceratops
        language: system
        types: [python]

and tryceratops-errors.log has not been created yet, this is raised at each check:

Traceback (most recent call last):
  File "/Users/pawlu/Documents/personal/nbpreview/.nox/pre-commit/bin/tryceratops", line 8, in <module>
    sys.exit(main())
  File "/Users/pawlu/Documents/personal/nbpreview/.nox/pre-commit/lib/python3.9/site-packages/tryceratops/__main__.py", line 62, in main
    entrypoint(prog_name="tryceratops")
  File "/Users/pawlu/Documents/personal/nbpreview/.nox/pre-commit/lib/python3.9/site-packages/click/core.py", line 829, in __call__
    return self.main(*args, **kwargs)
  File "/Users/pawlu/Documents/personal/nbpreview/.nox/pre-commit/lib/python3.9/site-packages/click/core.py", line 782, in main
    rv = self.invoke(ctx)
  File "/Users/pawlu/Documents/personal/nbpreview/.nox/pre-commit/lib/python3.9/site-packages/click/core.py", line 1066, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/Users/pawlu/Documents/personal/nbpreview/.nox/pre-commit/lib/python3.9/site-packages/click/core.py", line 610, in invoke
    return callback(*args, **kwargs)
  File "/Users/pawlu/Documents/personal/nbpreview/.nox/pre-commit/lib/python3.9/site-packages/tryceratops/__main__.py", line 57, in entrypoint
    interface.present_and_exit()
  File "/Users/pawlu/Documents/personal/nbpreview/.nox/pre-commit/lib/python3.9/site-packages/tryceratops/interfaces.py", line 95, in present_and_exit
    self._delete_empty_logs()
  File "/Users/pawlu/Documents/personal/nbpreview/.nox/pre-commit/lib/python3.9/site-packages/tryceratops/interfaces.py", line 86, in _delete_empty_logs
    is_log_empty = os.path.getsize(log_file_path) == 0
  File "/usr/local/Cellar/[email protected]/3.9.6/Frameworks/Python.framework/Versions/3.9/lib/python3.9/genericpath.py", line 50, in getsize
    return os.stat(filename).st_size
FileNotFoundError: [Errno 2] No such file or directory: '/Users/pawlu/Documents/personal/nbpreview/.tryceratops-errors.log'

Things work fine if the command is invoked directly through the terminal.

I learned that catching Exception is a dangerous shortcut. It does not communicate what is expected to fail, it might silence arbitrary unexpected errors (e.g. AttributeError where ValueError is expected) and finally it also catches severe misconditions like MemoryError. Thus usually I try to be as specific as possible.

What is your position on catching Exception? Is it something thats acceptable in Tryceratops?

This fixes issue #8 by calling the logging.shutdown function: https://docs.python.org/3/library/logging.html#logging.shutdown

As per the docs,

Informs the logging system to perform an orderly shutdown by flushing and closing all handlers. This should be called at application exit and no further use of the logging system should be made after this call.

When the logging module is imported, it registers this function as an exit handler (see atexit), so normally there’s no need to do that manually.

There might be a more appropriate place to insert this .shutdown() call, but it must be before the empty logs are deleted.

Hi! Thanks for great project.

As was mentioned in https://github.com/guilatrova/tryceratops/issues/41, there is a flake8 code clash between your project and flake8-type-checkin. When used together within single project tryceratops completely disables flake8-type-checkin. Flake8 doesn't give any warning about this, which leads to bad code passing linters silently.

Hi,

I would like to point tryceratops to a specifc configuration file using a --config option or something similar. Currently, tryceratops tries to find the configuration itself.

In my specifc use-case, I have a repository containing a cookiecutter template (https://github.com/pytask-dev/cookiecutter-pytask-project). There are two pyproject.toml files: one for the cookiecutter and one in the src folder which is rendered as part of the template. Since the latter pyproject.toml contains Jinja syntax it causes an error when tryceratops tries to read the file.

What do you think? I assume not many people are having a similar problem because they don't divide configuration files or something like that.

In the following code the parser is mistaken for a logger and using parser.exception is suggested :

import argparse

parser = argparse.ArgumentParser()
parser.add_argument(
    "config_folder", help="Path to the project configuration folder"
)
args = parser.parse_args()
try:
    int(args.config_folder) / 0
except:
    parser.error(
        f"Your configuration folder can't be divided by zero, use something else !"
    )

Hello again :)

The following code is not raising a TC003 but I think it should:

import numpy as np


def check_a_b(a: np.ndarray, b: np.ndarray) -> None:
    if len(a) != len(b):
        raise ValueError(
            "cezczeczeczecezczeczecnezklcnzelkczkenclkzecnzeklck"
            f"({len(a)})zedenzcklzelkcnzelcknzeklcnzelkncklzeckl"
            f"({len(b)})dzekckezncknzecklnzeklczkelcklzencknzeck"
        )