You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
The text was updated successfully, but these errors were encountered:
Currently, the hash of functions and classes is defined via
(obj.__module__, obj.__qualname__)
(seesis_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 explicitunhashed_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 Sisyphussis_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).
The text was updated successfully, but these errors were encountered: