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

Facilitate user defined type factories #30

Open
Helveg opened this issue Jul 8, 2020 · 1 comment
Open

Facilitate user defined type factories #30

Helveg opened this issue Jul 8, 2020 · 1 comment

Comments

@Helveg
Copy link
Collaborator

Helveg commented Jul 8, 2020

Add patch.monkey entry point because

A) It's a pun I can't resist
B) The p property can then be monkey patched before it is imported by scripts.

The advertised objects should be factories for callables that take the PythonHocInterpreter as argument. The factories themselves are passed the entire PythonHocModule because they can't import patch (circular import as this entry point is called during import of the patch module).

Patch should also get a submodule monkey with in it a method patch because what's better than a pun? A double pun! And with patch.monkey.patch you should be able to watertightly patch some stuff like all the functions that can start a simulation

@Helveg
Copy link
Collaborator Author

Helveg commented Sep 13, 2021

Monkey patching might have adverse effects when patch is used in multiple projects and generally has adverse side effects. Great pun, bad idea.

Instead inheritance to create your own patch.interpreter.PythonHocInterpreter could be used, a type map could be added and all patched wrappers could check if they need to return patch.objects.* or a user defined type instead.

@Helveg Helveg changed the title Facilitate monkey-patching Facilitate user defined type factories Sep 13, 2021
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