knappador / enron-py Goto Github PK

Preferably without any remaining trademark registration and using an imitation made in GIMP that isn't subject to a copyright.

Bottom line is the implementation and tools need to actually find bugs.

Connecting the type graph will tangle with enabling useful type checking. Plan for that:

1. Draw a graph of all valid coercion paths and useful make_* methods that connect the type graph
2. Graph should create an inverted DAG from the target type
3. Convert DAG to a tree via arbitrarily favored paths
4. Implement the rest of the _auto_arg helpers
5. Every outer signature coerces to the target types along the tree

Assuming we have a tree of methods in our constructors, it should become decidable whether a caller is providing enough information to construct a desired type. This does not address if the type checkers will give up for any number of reasons. Optional -> concrete may need to be completely explicit to satisfy sufficient information to construct.

The *Math metaclasses provide additional challenges for integration with type checking. The other arg could be type Any but this really only makes sense when we want to return NotImplemented for the sake of allowing the other to invoke it's __radd__ and related __r* methods. Commutative argument upgrading / downgrading is done via __r* methods now and is not particularly mind-blowing but it's not immediately clear that pylint can reason about simple math expressions ahead of runtime.

assert is being moved away from. The adoption of a favored tree of construction can deal with Optional and this process is reductive as we approach our canonical signature at the point of actual construction. The assertions on _auto* methods for non-None cases will then implement sensible RTTC where the user provided an argument and the argument breaks the reduction path. In this manner we can move away from almost all non-shared constructor coercion as well as providing tools for client classes to adopt the same type-checking.

Testing

Oddly some broken code will need to exist in the source base to verify the performance of pylint. Some integration will be necessary.

Internals frequently just delegate to {!r} and {!s} but it's pretty hideous for Decimal types

Account protects its internals by blocking flippant calls to __setattr__ and also adding access to virtual attributes amount and asset which together can comprise an AssetAmount.

Results in:

E:632,15: Instance of 'Account' has no 'amount' member (no-member)
E:637,42: Instance of 'Account' has no 'asset' member (no-member)
E:640,32: Instance of 'Account' has no 'amount' member (no-member)

Provide lint with this information for now.

AssetAmountcan upgrade Decimal arguments. It may make sense to provide for more fluid upgrade & downgrade of AssetAmount to simply the type graph.

There's a /doc folder but presumably I skipped a build step. Click docs badge for link to RTD page. (or add one on the main README if it works)

Design proposal:

• Context management uses a context stack that is pushed on __enter__
• All instantiated transfers are tracked and implement a kill method to explicitly mark dead a DoubleEntry with no intended destination
• DoubleEntry is marked applied or something to that effect when used in a context
• clone method for creating repetitive entries or reviving an entry that is dead
• Warn / throw (configurable) if a DoubleEntry runs out of scope on__exit__ and didn't get an assigned explicit fate
• Pop stacks on __exit__
• DoubleEntry from outside the scope needs to start in CREATED state to be valid for admission into the current scope

Ancillary Goals

• Double entries need to be immutable
• GeneralLedger is kicked out of being anything like an AssetBalance to focus on transaction duties

So many great emojis... 🦊 💃 🇰🇪 💡 📚 🔬 ⏲️ 🕵️‍♂️

I went as far as actually getting the project to automatically update whenever master is merged. Hope into the docs/ folder and run sphinx-build -b html source build to obtain results in docs/build/ that can be opened in a browser to preview

They look something like this:
http://enron.readthedocs.io/en/latest/enron.html#module-enron.enron

I think the TOC and general page structure are not quite ready to be maintainable. I'd like to get this up to the point that simply inserting docstrings will result in helpful docs. A lot of the pages frankly just looked like confusing blobs.

I'm not rushing to go learn about configuring Sphinx until the API is stable 🚧 🏗️ 👷‍♂️