Add PricesCsv

.flake8

@@ -17,7 +17,8 @@ per-file-ignores =
     # D103 Missing docstring in public function - not required for all tests
     # D102 Missing docstring in public function - not required for all tests
     # D401 First line should be in imperative moood - not useful to describe fixtures
-    tests/*.py:D103,D102,D401
+    # E501 line too long - required to ease defining exception text matches
+    tests/*.py:D103,D102,D401,E501
     # E501 line-too-long, provides for a doctest line that overruns
     src/market_prices/utils/pandas_utils.py:E501
 

.github/workflows/build-test.yml

@@ -17,7 +17,7 @@ jobs:
         - uses: actions/checkout@v4
         - uses: psf/black@stable
           with:
-            options: "--check --verbose"
+            options: "--check --verbose --diff"
 
   build-and-test:
 

.pylintrc

@@ -23,7 +23,7 @@
 # usually to register additional checkers.
 load-plugins=pylint.extensions.broad_try_clause,
              pylint.extensions.confusing_elif,
-             pylint.extensions.comparetozero,
+        ;      pylint.extensions.comparetozero,  ; not loading as of Nov 23, no doc to suggest removed?
              pylint.extensions.bad_builtin,
              pylint.extensions.mccabe,
              pylint.extensions.docstyle,

README.md

@@ -13,7 +13,7 @@ A python library to create **meaningful** OHLCV datasets for financial instrumen
 
 `market_prices` provides for enhanced querying and post-processing of financial price data.
 
-Works out-the-box with prices from the Yahoo Finance API via [yahooquery][yahooquery] (see [Disclaimers](https://github.com/maread99/market_prices#disclaimers)).
+Works out-the-box with prices from the Yahoo Finance API via [yahooquery][yahooquery] (see [Disclaimers](https://github.com/maread99/market_prices#disclaimers)) or from locally stored .csv files.
 
 ## Installation
 
@@ -206,6 +206,9 @@ symbol                           MSFT     9988.HK       BTC-USD
 The [quickstart.ipynb](https://github.com/maread99/market_prices/blob/master/docs/tutorials/quickstart.ipynb) tutorial offers a fuller introduction. [Here](https://github.com/maread99/market_prices/blob/master/docs/tutorials_docs.md) you'll find links to all the tutorials which collectively cover all that `market_prices` offers.
 
 ## Features include:
+* Get price data out-the-box:
+    * `PricesYahoo` to get live and historic prices from the Yahoo Finance API via [yahooquery][yahooquery] (see [Disclaimers](https://github.com/maread99/market_prices#disclaimers)).
+    * `PricesCsv` to get price data from locally stored .csv files.
 * Include **securities trading on different exchanges** with differing opening hours across different time zones.
 * Request the **period** covered by a dataset in terms of either:
     * trading time (minutes and hours).

docs/developers/other_internals.md

@@ -134,3 +134,6 @@ NB: A daterange end that is a session close that is aligned against the base int
 
 ## `daterange.GetterIntraday.daterange_tight`
 The `daterange.GetterIntraday.daterange_tight` tightens the end (first item) so that the difference between the end and the accuracy is less than one base interval. When the downsample interval (ds_interval) is high relative to the base interval this has the benefit of preventing 'partial requests' for data that cover just the end of the daterange over which no symbol trades (and hence no data would be expected to be returned). See the property documentation for an example.
+
+## Right Limits
+Right limits were introduced January 2024 to support sourcing historic price data from locally stored .csv files (`PricesCsv`). To minimise changes and maintain much of the existing implementation (and hence tests and tutorials) a new `BASE_LIMITS_RIGHT` class attribute was introduced rather than altering the existing `BASE_LIMITS` which could have been amended to take a tuple defining both the left and right limit. Similarly, a 'limit_right' parameter was added to the `daterange._Getter` constructor rather than redefining the 'limit' parameter as 'limits' to take a tuple. On reflection, given the different treatment of each limit (with the right limit defaulting to 'now' if not defined, whereas the left limit for daily data has to be found) I think that defining left and right limits separately IS definitely the way to do. This way the right limit can be ignored for any service that provides for data to now (i.e. most of them). It's much clearer to have them left and right limits separately. Keep it this way.