check this:

Technical Details
The project is comprised in four different modules/components:
Statistical report as a new CLI-option
This component involves building an additional CLI module to cooltools and its respective library module, inspired by this current issue: https://github.com/open2c/cooltools/issues/415. The main idea of this component is to calculate and report comprehensive statistics for any .cool file. The associated stats comprise the number of contact points across regions (cis/trans), fraction of contacts within and between regions, distance decay of contacts, among others, that could be restrained to a specific region(s) or chromosome(s) specified by the user. This component will offer easier parallelization strategies achieved by PyO3 and Rust modules to make it faster and easier to implement. The module will be called “coolstats.py” and will use the current dependencies cooltools uses to parse command-line arguments (click). Additionally, will construct similar classes as seen in pairtools, another software produce by the Open2C team, with similar structures (e.g. CoolCounter class) and functions. However, to preserve independence and a better organization, each metric will have its own function. The proposed output is a .txt file with the organized stats and additional plots representing those results saved to the current directory by default or any directory the user specifies with the flag -d/–dir. Other types of formats or the specific layout will be discussed with the team.
CLI-related functionality corrections
Solve current issues related to the CLI behavior, such as smoothing and aggregation across regions in get_expected_cis() or dropping headers for fetch_chromsizes(), and also implement alternate reductions for aggregation across diagonals, such as variance or standard deviation, adding new arguments to control these features preserving the current functionality as default. These changes can be achieved with the current code and without any extra dependencies. Furthermore, this component will be implemented with its respective documentation following the current guidelines of Open2C and unit tests to ensure the viability of the software.
Refactoring of current structures
Using the initial ideas from here: https://github.com/open2c/cooltools/issues/227 and here https://github.com/open2c/cooltools/issues/502, I plan to implement a new class for snipper (called Snipper) and re-use the current methods attached. Additional modifications will be added to enhance the functionality and solve current issues, such as decoupling selecting and snipping methods (e.g. snipper.select() and snipper.snip()) and converting bed-like inputs to 2D structures (e.g. bedpe) to reduce overheading over subsequent conversions. As part of this refactoring, I also plan to create a separate mini-repository to store log-smoothing-related functions that will be used not only by cooltools but the whole Open2C ecosystem. The basic functionality of the latter will comprise operating over the core cooltools structures (e.g. numpy arrays and pandas dataframes) with flexibility on column names. 
Rust-based acceleration of core modules and polars as an efficient alternative
Based on a current issue, some parts of cooltools can improve by parallelization strategies, as seen here: https://github.com/open2c/cooltools/commit/c6b705d7aac895006efe797cb22da332793a7ae2#commitcomment-84603046, for example. As mentioned in the first component here, using PyO3 and Rust could be of great advantage. Here, a function called “send_chunk()” will receive a subset of the Hi-C contact matrix that corresponds to a specific genomic region and the parameters to perform the calculations in parallel using the rayon crate.
On the other hand, I propose to explore the possibility of using the polars package, a query engine for dataframes natively multi-threaded, to perform dataframe calculations currently done using pandas. Since polars have demonstrated to be way faster than pandas in tasks related to querying, grouping or sorting (see https://medium.com/cuenex/pandas-2-0-vs-polars-the-ultimate-battle-a378eb75d6d1), and also considering that polars can accept pandas dataframes as inputs, benchmarking current cooltools operations using polars instead of pandas could potentially lead to significant advantages. I plan to apply this proposal first to functions using “sort_values()” and benchmark them against the current implementation.  This also could be applied to other Open2C tools, such as bioframe, within the sort_bedframe() function.

Based on all that, please do this:

Abstract (Summary)
Short description of your project. Max 10 sentences. This SHOULD NOT be a copy of the project idea text.