-
-
Notifications
You must be signed in to change notification settings - Fork 18.7k
Open
Labels
Description
about / roadmap page in the website shows a numbered list of 17 items and this doesn't seem to be the expected result by looking at the code:
pandas/web/pandas/about/roadmap.md
Lines 108 to 145 in 05de253
1. Label indexing must never involve looking in an axis twice for the same label(s). | |
This implies that any validation step must either: | |
* limit validation to general features (e.g. dtype/structure of the key/index), or | |
* reuse the result for the actual indexing. | |
2. Indexers must never rely on an explicit call to other indexers. | |
For instance, it is OK to have some internal method of `.loc` call some | |
internal method of `__getitem__` (or of their common base class), | |
but never in the code flow of `.loc` should `the_obj[something]` appear. | |
3. Execution of positional indexing must never involve labels (as currently, sadly, happens). | |
That is, the code flow of a getter call (or a setter call in which the right hand side is non-indexed) | |
to `.iloc` should never involve the axes of the object in any way. | |
4. Indexing must never involve accessing/modifying values (i.e., act on `._data` or `.values`) more than once. | |
The following steps must hence be clearly decoupled: | |
* find positions we need to access/modify on each axis | |
* (if we are accessing) derive the type of object we need to return (dimensionality) | |
* actually access/modify the values | |
* (if we are accessing) construct the return object | |
5. As a corollary to the decoupling between 4.i and 4.iii, any code which deals on how data is stored | |
(including any combination of handling multiple dtypes, and sparse storage, categoricals, third-party types) | |
must be independent from code that deals with identifying affected rows/columns, | |
and take place only once step 4.i is completed. | |
* In particular, such code should most probably not live in `pandas/core/indexing.py` | |
* ... and must not depend in any way on the type(s) of axes (e.g. no `MultiIndex` special cases) | |
6. As a corollary to point 1.i, `Index` (sub)classes must provide separate methods for any desired validity check of label(s) which does not involve actual lookup, | |
on the one side, and for any required conversion/adaptation/lookup of label(s), on the other. | |
7. Use of trial and error should be limited, and anyway restricted to catch only exceptions | |
which are actually expected (typically `KeyError`). | |
* In particular, code should never (intentionally) raise new exceptions in the `except` portion of a `try... exception` |