Option for gradient coloring and alpha in edges

[pintergreg]

As I'm really interested in the gradient option I adopted @fransua's code from #11.

In general I have some concerns regarding the code structure, but for now all I did was that I copied the relevant parts from the closed PR and make it work with the current state of the code.

I also added a notebook, called gradient_test where you can see the results. But for some reason I had to comment the from pysankey.sankey.exceptions import LabelMismatch, NullsInFrame, PySankeyException to be able to import the code from my notebook. It was restored before I opened this PR.

With the new parts it is now possible to do the following:

import sankey
import pandas as pd
df = pd.read_csv(
    'fruits.txt', sep=' ', names=['true', 'predicted']
)
colorDict = {
    'apple':'#f71b1b',
    'blueberry':'#1b7ef7',
    'banana':'#f3f71b',
    'lime':'#12e23f',
    'orange':'#f78c1b',
    'kiwi':'#9BD937'
}
alphaDict = {
    'apple': 0.65,
    'blueberry': 0.65,
    'banana': 0,
    'lime': 1,
    'orange': 0.65,
    'kiwi': 0.65
}

no alpha, gradient

ax = sankey.sankey(
    df['true'],
    df['predicted'],
    colorDict=colorDict,
    color_gradient=True
)

no alpha, no gradient

ax = sankey.sankey(
    df['true'],
    df['predicted'],
    colorDict=colorDict,
    color_gradient=False
)

alpha and gradient

sankey.sankey(
    df['true'],
    df['predicted'],
    colorDict=colorDict,
    alphaDict=alphaDict,
    color_gradient=True,
)

alpha, but no gradient

sankey.sankey(
    df['true'],
    df['predicted'],
    colorDict=colorDict,
    alphaDict=alphaDict,
)

@Pierre-Sassoulas I hope it can merged as soon as possible, as I would like to see it in a release. Tell me it it still needs some care.
Thanks,

[pintergreg]

Okay, I see some mypy errors, working on it.

[Pierre-Sassoulas]

Hey, thank you for opening the MR. You can install pre-commit locally with pip install pre-commit then pre-commit install it will check the code when you commit with git. Every issue with python 3.7 you can disregard. I should remove python 3.7 from the test matrice and add 3.11 / 3.12 but I should do that in another MR.

[pintergreg]

I managed to resolve these errors. I also made a mistake during the process, so I have several commits. If that's a problem, please use the squash merge.

Additionally, a thorough review could be necessary, because I don't exactly understand some part of the code.

[Pierre-Sassoulas]

Hey ! So, I upgraded everything in #37 so the tests are now passing on main, if you rebase on it all the issues in the CI will come from the new changes.

[pintergreg]

Hey ! So, I upgraded everything in #37 so the tests are now passing on main, if you rebase on it all the issues in the CI will come from the new changes.

It's done.

[Pierre-Sassoulas]

We need to support python 3.8 so we need a from __future__ import annotations at the top of the file (thank you for adding typing!)

[pintergreg]

I used the new (from 3.10) type union operator (number: int | float,), but I will replace it with the older one (number: Union[int, float]).

[pintergreg]

There was a complexity problem in the extended plot_strips method.

pysankey/sankey/__init__.py:373:0: R0912: Too many branches (14/12) (too-many-branches)

This was because it is checked that whether the input is a tuple. As the alpha was computed the same way regardless it is a gradient strip or not, I relocated that part before the gradient check.

My test cases still work as expected.

[Pierre-Sassoulas]

I used the new (from 3.10) type union operator (number: int | float,), but I will replace it with the older one (number: Union[int, float]).

You can use the new syntax, but you need to add from __future__ import annotations at the top of the file.

[pintergreg]

I used the new (from 3.10) type union operator (number: int | float,), but I will replace it with the older one (number: Union[int, float]).

You can use the new syntax, but you need to add from __future__ import annotations at the top of the file.

Okay, but I wanted consistent code style and Union was used at other parts.

In another run, I replaced the PEP 585 style tuple[str] annotations to the pre 3.9 variant Tuple[str] (from typing namespace).

[Pierre-Sassoulas]

Great, thank you for making the test pass !

[pintergreg]

Sorry for the multiple round that was required to make them pass. Thanks for your time.

If I may, I think the version 1.5.0 would be better if you use semantic versioning as this is a new feature.

[Pierre-Sassoulas]

Ha yes, my bad and it's already released now. I added you as collaborator you should be able to add a new tag and release from the github interface (push a tag then create a release from github interface) don't hesitate to release in the future :)