fix: make tangled-up-in-unicode an optional dependency

[akx]

Knowing the exact Unicode properties is likely not a priority for all users. Furthermore, unicodedata as of Python 3.10 is based on UCD 13, so the category data in there ought to be fairly recent.

This should probably be documented (as well as the [unicode] extra), but I'm not sure what the best place for it would be.

Refs dylan-profiler/tangled-up-in-unicode#10 – importing tangled will create 2 gigabytes of
bytecode files and takes a while.

[akx]

Hi @fabclmnt, thanks for getting back to me!

1. If we clearly document that more in-depth character analysis is possible if one installs pandas-profiling[unicode] (at the expense of significant disk space), that should take care of that, I think?
2. visions hasn't actually required tangled since May 2021, the dependency is there for no reason. I opened the PR Remove tangled_up_in_unicode dependency dylan-profiler/visions#197 in visions prior to opening this just for that. 😄

[akx]

So @fabclmnt - with the above provisions, could this be reopened (for discussion?)?

[fabclmnt]

@akx the 2GB is a pain indeed and as I've mentioned before, we are happy to consider any other suggestion to have it sorted, different from the one suggested by this PR.

This suggestion does not fit the profile of the user and use-cases for which this package was designed for.

[akx]

This suggestion does not fit the profile of the user and use-cases for which this package was designed for.

@fabclmnt I'm not sure I understand – can you explain what the profile and the use-cases are? For users who require precise knowledge of the distribution of Unicode blocks, categories and scripts in their data, they can install pandas-profiling[unicode]. For the rest, everything remains the same.

[fabclmnt]

This suggestion does not fit the profile of the user and use-cases for which this package was designed for.

@fabclmnt I'm not sure I understand – can you explain what the profile and the use-cases are? For users who require precise knowledge of the distribution of Unicode blocks, categories and scripts in their data, they can install pandas-profiling[unicode]. For the rest, everything remains the same.

The point is precisely what you've mentioned, the user would have to know ahead that he needs or not to use the unicode at the moment of the installation which is not the case for our audience. I have particular examples and request of users that for the same use case they explore different datasets (with the need for the precise knowledge of the distribution of unicode blocks) but they only know it, whenever they use PP for the initial exploration and data understanding.

[fabclmnt]

Re-openning this PR - after having a look, this is indeed the best option.

Can you please add a note to the documentation regarding this change?

[fabclmnt]

I'll just ask you to change the commit message and change to the develop branch.

[akx]

@fabclmnt 👍 Changed base to develop, rebased, and amended readme and docs too :)

[sbrugman]

Apart from the location of the check, lgtm.

[fabclmnt]

🚀 looking good to go. Thank you @akx!

[aquemy]

Given the fact that we need to release and that the concern raised by @sbrugman is not a blocker or vital, I merge this.

Kudos to @akx !