Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Configurable hash of functions and classes #144

Open
albertz opened this issue Aug 7, 2023 · 0 comments
Open

Configurable hash of functions and classes #144

albertz opened this issue Aug 7, 2023 · 0 comments

Comments

@albertz
Copy link
Member

albertz commented Aug 7, 2023

Currently, the hash of functions and classes is defined via (obj.__module__, obj.__qualname__) (see sis_hash_helper).

This has the same problems as it is being solved in rwth-i6/i6_experiments#157, namely that the module name usually is some string like i6_experiments.users.zeyer.experiments.exp2023_04_25_rf._moh_att_2023_06_30_import.map_param_func_v2, i.e. it includes the user name and maybe other things which are not really so relevant, so moving the class or function later on will change the hash. rwth-i6/i6_experiments#157 solves this by an explicit unhashed_package_root option.

I want to have similar logic for any function or class in Sisyphus. I almost never want the existing hashing logic. Maybe the exception is for functions or classes in i6_core, which would hopefully not be moved anymore.

For backwards compatibility, the existing logic probably should stay though? Even by default? Or just disallow it?

I have many ideas how to solve this. Here are some:

  • We can introduce some __unhashed_package_root__ (and maybe also __extra_hash__) global variables for a module. When Sisyphus sis_hash_helper stumbles upon some function or class, it would go reversely through the module hierarchy (i6_experiments.users.zeyer.experiments.exp2023_04_25_rf._moh_att_2023_06_30_import, i6_experiments.users.zeyer.experiments.exp2023_04_25_rf, i6_experiments.users.zeyer.experiments, i6_experiments.users.zeyer, ...) and checks for these global variables, and if found, it would replace the module name up to that by __extra_hash__ (or empty string).

  • Similarly as above, but just to disallow hashing in any case: __disallow_hash_root__: bool or so. That way, you do not accidentally end up with such function or class in the hash. The user must explicitly use some wrapper object (this also needs to be implemented yet, maybe in i6_core or i6_exp/common).

  • A whitelist of allowed module prefixes, and anything else would fail with an exception (if the whitelist is defined, otherwise, as currently, all would be allowed).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant