style: Perform full linting and fixes to the whole codebase

[lsetiawan]

Lint and fix the entire codebase to follow the PEP8 Guidelines. Currently the only one check that is turned off is the mypy, which fixes will happen in a separate PR. Pre-commit CI check should now pass.

[codecov]

Codecov Report

Attention: 4 lines in your changes are missing coverage. Please review.

Comparison is base (ffb5734) 88.70% compared to head (cfe7c5f) 88.74%.

Files	Patch %	Lines
src/caustics/data/__init__.py	0.00%	4 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##              dev     #124      +/-   ##
==========================================
+ Coverage   88.70%   88.74%   +0.04%     
==========================================
  Files          36       36              
  Lines        1885     1901      +16     
==========================================
+ Hits         1672     1687      +15     
- Misses        213      214       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[ConnorStoneAstro]

I see a lot of from x import * are removed, which is fine in general. However it means that maintenance is more work since any new function must be traced through the import hierarchy and added to all the imports and __all__'s. What is the benefit of doing things this way?

[lsetiawan]

Great question @ConnorStoneAstro!

PEP8 Standard states the following:

Wildcard imports (from import *) should be avoided, as they make it unclear which names are present in the namespace, confusing both readers and many automated tools. There is one defensible use case for a wildcard import, which is to republish an internal interface as part of a public API (for example, overwriting a pure Python implementation of an interface with the definitions from an optional accelerator module and exactly which definitions will be overwritten isn’t known in advance).

This is typically not a recommended way to import functions and classes as it is very implicit and hard to understand what is actually being imported. One great article that really hammer on this ambiguity can be found at: https://internetworking.dev/why-it-is-bad-idea-to-use-wildcard-based-imports/

However it means that maintenance is more work since any new function must be traced through the import hierarchy and added to all the imports and all's. What is the benefit of doing things this way?

To this point, really what you need is to import any new public functions in a module to the module's __init__.py. I notice that per class for example: src/caustics/light/base.py you have an __all__, this is not necessary and better to put it in the module level. Think of this module level __all__ as specifying exactly what functions or classes that you'd like to expose to your users. I think the benefit here is really readability and easier to follow the code and knowing what's getting exposed vs what's hidden. This allows both users and outside developers to easily understand the important parts of your code.

Normally when programming Python it is always better to be explicit rather than implicit to avoid any confusions, hence their PEP8 above.

[ConnorStoneAstro]

This looks great!