1.105.0

Author: cjdsellers

.flake8

@@ -24,7 +24,7 @@ exclude =
    dist
    docs
    noxfile.py
-ignore = E225, E227, E252, E999
+ignore = E225, E227, E252, E999, DAR402
 max-complexity = 10
 max-line-length = 150
 statistics = True
@@ -35,3 +35,4 @@ statistics = True
 # E227 missing whitespace around bitwise or shift operator (picks up pointers)
 # E252 spaces around default argument assignment (incorrect syntax)
 # E999 SyntaxError: invalid syntax (cimport seen as invalid syntax)
+# D402 Excess exception(s) in Raises section (picks up legitimate multiple exceptions)

README.md

@@ -103,11 +103,19 @@ The `master` branch will always reflect the code of the latest release version.
 Also, the documentation is always current for the latest version.
 
 The package is tested against Python 3.7 - 3.9 on both Linux and MacOS.
+We recommend running the platform with the latest stable version of Python.
 
-We recommend users setup a virtual environment to isolate the dependencies, and run the platform
-with the latest stable version of Python.
+Unfortunately Windows installations are not currently supported. Attempts have
+been made to get the project more compatible with Windows, however there are some
+low level implementation details currently preventing this from being possible.
 
-`pyenv` is the recommended tool for handling Python installations and virtual environments.
+It is a goal for the project to keep dependencies focused, however there are
+still a large number of dependencies as found in the `pyproject.toml` file.
+Therefore we recommend you create a new virtual environment for NautilusTrader
+to isolate the dependencies.
+
+`pyenv` is the recommended tool for handling system wide Python installations
+and virtual environments.
 
 > https://github.com/pyenv/pyenv
 
@@ -289,6 +297,10 @@ Refer to the [Developer Guide](https://nautilus-trader.readthedocs.io/en/latest/
 
 ## Contributing
 
+Even as some issues are marked with the `help wanted` label - this does not imply
+that help is _only_ wanted on those issues. The label indicates where 'extra attention'
+is needed.
+
 Involvement from the trading community is a goal for this project. All help is welcome!
 Developers can open issues on GitHub to discuss proposed enhancements/changes, or
 to make bug reports.

docs/source/developer_guide/coding_standards.rst

@@ -9,11 +9,11 @@ Code Style
 
 We philosophically agree with the ``Black`` formatting style, however it does not
 currently run over Cython code. So you could say we are "handcrafting towards"
-``Black``s stylistic conventions.
+``Black`` stylistic conventions.
 
 The current codebase can be used as a guide for formatting guidance.
 
-1- For longer lines of code, and when passing more than a couple of arguments
+1- For longer lines of code, and when passing more than a couple of arguments,
 it's common to take a new line which aligns at the next logical indent (rather
 than attempting a hanging alignment off an opening parenthesis).
 

docs/source/developer_guide/developing_adapters.rst

@@ -1,4 +1,4 @@
 Developing Adapters
 ===================
 
-WIP
+**work in progress**

docs/source/developer_guide/environment.rst

@@ -5,6 +5,10 @@ For development we recommend using the PyCharm `Professional` edition IDE, as it
 interprets Cython syntax. Alternatively, you could use Visual Studio Code with
 a Cython extension.
 
+``pyenv`` is the recommended tool for handling Python installations and virtual environments.
+
+> https://github.com/pyenv/pyenv
+
 ``poetry`` is the preferred tool for handling all Python package and dev dependencies.
 
 > https://python-poetry.org/
@@ -18,22 +22,22 @@ Setup
 -----
 The following steps are for Unix-like systems, and only need to be completed once.
 
-1. Install ``pre-commit`` by running::
-
-        pip install pre-commit
-
-2. Install the Cython package by running:
+1. Install the Cython package by running::
 
         pip install -U Cython==3.0a6
 
-3. Install ``poetry`` by running::
+2. Install ``poetry`` by running::
 
         curl -sSL https://raw.githubusercontent.com/python-poetry/poetry/master/get-poetry.py | python -
 
-4. Then install all Python package dependencies, and compile the C extensions by running::
+3. Then install all Python package dependencies, and compile the C extensions by running::
 
         poetry install
 
+4. Install the ``pre-commit`` package by running::
+
+        pip install pre-commit
+
 5. Setup the ``pre-commit`` hook which will then run automatically at commit by running::
 
         pre-commit run --all-files

docs/source/developer_guide/overview.rst

@@ -13,11 +13,13 @@ frameworks and libraries, whilst overcoming some of its inherent shortcomings in
 performance and lack of built in type safety (with it being an interpreted
 dynamic language).
 
-One of the advantages of Cython is that we don't have to concern ourselves with
-memory safety, as that is handled by its C code generator during the 'cythonization'
-step of the build. So we get the best of both worlds - with Pythons clean straight
-forward syntax, and a lot of potential to extract several orders of magnitude
-greater runtime performance through compiled C dynamic libraries.
+One of the advantages of Cython is that allocation and freeing of memory is
+handled by the C code generator during the 'cythonization' step of the build
+(unless you're specifically utilizing some of its lower level features).
+
+So we get the best of both worlds - with Pythons clean straight forward syntax,
+and a lot of potential to extract several orders of magnitude greater runtime
+performance through compiled C dynamic libraries.
 
 The main development and runtime environment we are working in is of course Python.
 However with the introduction of Cython syntax throughout the production codebase

docs/source/developer_guide/testing.rst

@@ -1,7 +1,7 @@
 Testing
 =======
 
-The test suite is divided into broad categories of tests including;
+The test suite is divided into broad categories of tests including:
     - Unit tests
     - Integration tests
     - Acceptance/System tests
@@ -55,5 +55,5 @@ of an if-else block which would catch an unrecognized value, these should be
 left in place in case there is a change to the production code - which these
 checks could then catch.
 
-Other 'design-time' exceptions may also be impossible to test for, and so 100%
+Other `design-time` exceptions may also be impossible to test for, and so 100%
 test coverage is not the ultimate goal.

docs/source/getting_started/core_concepts.rst

@@ -19,10 +19,12 @@ There are two main reasons for conducting backtests on historical data;
 Backtesting with an event-driven engine such as NautilusTrader is not meant to be the primary
 research method for alpha discovery, but merely facilitates the above.
 
-One of the primary benefits of this platform is
-that the machinery used inside the backtest engine is identical for live trading, apart from the live versions of the data and execution engines
-closer to the periphery of the system (they add asyncio queues on top of the common implementations), and integrations with external
-endpoints through adapters provided with this package (and/or developed by end users).
+One of the primary benefits of this platform is that the machinery used inside
+the backtest engine is identical for live trading, apart from the live versions
+of the data and execution engines closer to the periphery of the system (they
+add asyncio queues on top of the common implementations), and integrations with
+external endpoints through adapters provided with this package (and/or developed
+by end users).
 
 This helps ensure consistency when seeking to capitalize on alpha through a large
 sample size of trades, as expressed in the logic of the trading strategies.
@@ -31,23 +33,18 @@ Only a small amount of example data is available in the ``test`` directory of
 the repository - as used in the examples. There are many sources of financial
 market data, and it is left to the user to supply this for backtesting purposes.
 
-The platform is extremely flexible and open ended, you could inject dozens of different
-datasets into a backtest engine, running them simultaneously with time being
-accurately simulated down to the smallest ``timedelta`` definable by Python.
+The platform is extremely flexible and open ended, you could inject dozens of
+different datasets into a backtest engine, running them simultaneously with time
+being accurately simulated down to the smallest ``timedelta`` definable by
+Python.
 
 Trading Live
 ------------
-A ``TradingNode`` is able to host a fleet of trading strategies,
-with data able to be ingested from multiple data clients, and
-order execution and management through multiple execution clients.
+A ``TradingNode`` hosts a fleet of trading strategies, with data able to be
+ingested from multiple data clients, and order execution through multiple
+execution clients.
 
-There are two main modes of for live deployment;
-
-- Demo account
-- Real account
-
-The only difference here being whether the accounts are controlling
-real assets.
+Live deployments can use both demo/paper trading accounts, or real accounts.
 
 Coming soon there will be further discussion of core concepts...
 

docs/source/getting_started/installation.rst

@@ -4,26 +4,30 @@ Installation
 The ``master`` branch will always reflect the code of the latest release version.
 Also, the documentation is always current for the latest version.
 
-The package is tested against Python versions 3.7 - 3.9 on both Linux and
-MacOS. Users are encouraged to use the latest stable version of Python.
+The package is tested against Python 3.7 - 3.9 on both Linux and MacOS.
+We recommend running the platform with the latest stable version of Python.
+
+Unfortunately Windows installations are not currently supported. Attempts have
+been made to get the project more compatible with Windows, however there are some
+low level implementation details currently preventing this from being possible.
 
 It is a goal for the project to keep dependencies focused, however there are
 still a large number of dependencies as found in the ``pyproject.toml`` file.
-Therefore we recommend you create a new virtual environment for NautilusTrader.
+Therefore we recommend you create a new virtual environment for NautilusTrader
+to isolate the dependencies.
 
-There are various ways of achieving this - the easiest being to use the ``poetry``
-tool. https://python-poetry.org/docs/
+`pyenv` is the recommended tool for handling system wide Python installations
+and virtual environments.
 
-If you're not used to working with virtual environments, you will find a great
-explanation in the ``poetry`` documentation under the `Managing environments`
-sub-menu.
+> https://github.com/pyenv/pyenv
 
-Installation for Unix-like systems can be achieved through `one` of the following options;
+Installation for Unix-like systems can be achieved through `one` of the
+following options;
 
 From PyPI
 ---------
 
-To install the latest binary wheel (or sdist package) from PyPI, run:
+To install the latest binary wheel (or sdist package) from PyPI, run::
 
     pip install -U nautilus_trader
 

docs/source/user_guide/backtesting.rst

@@ -1,2 +1,4 @@
 Backtesting
 ===========
+
+**work in progress**

docs/source/user_guide/deploying_live.rst

@@ -1,34 +1,4 @@
 Deploying Live
 ==============
 
-Encryption
-----------
-
-For effective remote deployment of a live `TradingNode` which needs to access remote services,
-encryption keys must be user generated. The currently supported encryption scheme is that which is built
-into ZeroMQ being Curve25519 elliptic curve algorithms. This allows perfect forward security with
-ephemeral keys being exchanged per connection. The public `server.key` must be shared with the trader
-ahead of time and contained in the `keys\` directory (see below).
-
-To generate a new client key pair from a python console or .py run the following;
-
-.. code-block::
-
-    from pathlib import Path
-
-    import zmq.auth
-
-    keys_dir = 'path/to/your/keys'
-    Path(keys_dir).mkdir(parents=True, exist_ok=True)
-
-    zmq.auth.create_certificates(keys_dir, 'client')
-
-Live Deployment
----------------
-
-The user must assemble a directory including the following;
-
-- `config.json` for configuration settings
-- `keys/` directory containing the `client.key_secret` and `server.key`
-- `launch.py` referring to the strategies to run
-- trading strategy python or cython files
+**work in progress**

docs/source/user_guide/framework.rst

@@ -12,13 +12,16 @@ feature rich yet straight forward API. `Domain Driven Design` (DDD) and message
 have been central philosophies in the design.
 
 From a high level view - a ``Trader`` can host any number of infinitely customizable
-``TradingStrategy``s. A central ``Portfolio`` has access to ``Account``s which can all be queried.
-A common ``DataEngine`` and ``ExecutionEngine`` then allow asynchronous ingest of any data
+``TradingStrategy`` instances. A central ``Portfolio`` has access to multiple ``Account`` instances,
+which can all be queried.
+
+A common ``DataEngine`` and ``ExecutionEngine`` allows asynchronous ingest of any data
 and trade events, with the core componentry common to both backtesting and live implementations.
 
 Currently a performant Redis execution database maintains state persistence
 (swapped out for an in-memory only implementation for backtesting).
 It should be noted that the flexibility of the framework even allows the live trading
 Redis database to be plugged into the backtest engine. Interestingly there is
-only a 4x performance overhead which speaks to the raw speed of Redis and the
-platform itself.
+only a 4x performance overhead which speaks to the raw speed of Redis.
+
+**work in progress**

docs/source/user_guide/writing_indicators.rst

@@ -1,2 +1,4 @@
 Writing Indicators
 ==================
+
+**work in progress**

docs/source/user_guide/writing_strategies.rst

@@ -1,2 +1,4 @@
 Writing Strategies
 ==================
+
+**work in progress**

nautilus_trader/common/logging.pxd

@@ -107,7 +107,7 @@ cdef class LoggerAdapter:
 
     cdef readonly str component_name
     """The loggers component name.\n\n:returns: `str`"""
-    cdef readonly bint bypassed
+    cdef readonly bint is_bypassed
     """If the logger is in bypass mode.\n\n:returns: `bool`"""
 
     cpdef Logger get_logger(self)

nautilus_trader/common/logging.pyx

@@ -195,7 +195,7 @@ cdef class Logger:
         name : str
             The name of the logger.
         bypass_logging : bool
-            If the logger should be completely bypassed.
+            If the logger should be bypassed.
         level_console : LogLevel (Enum)
             The minimum log level for logging messages to the console.
         level_file : LogLevel (Enum)
@@ -359,7 +359,7 @@ cdef class LoggerAdapter:
 
         self._logger = logger
         self.component_name = component_name
-        self.bypassed = logger.bypass_logging
+        self.is_bypassed = logger.bypass_logging
 
     cpdef Logger get_logger(self):
         """
@@ -491,7 +491,7 @@ cdef class LoggerAdapter:
         LogColor color,
         str message,
     ) except *:
-        if not self.bypassed:
+        if not self.is_bypassed:
             self._logger.log(LogMessage(
                 self._logger.clock.utc_now_c(),
                 level,

nautilus_trader/data/base.pxd

@@ -35,10 +35,12 @@ cdef class Data:
 
 
 cdef class DataType:
+    cdef frozenset _metadata_key
+
     cdef readonly type type
     """The type of the data.\n\n:returns: `type`"""
     cdef readonly dict metadata
-    """The data types metadata.\n\n:returns: `dict[str, object]`"""
+    """The data types metadata.\n\n:returns: `set[str, object]`"""
 
 
 cdef class DataCacheFacade: