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

Make decompiler and transformers optional #58

Open
Kentzo opened this issue Sep 10, 2017 · 6 comments
Open

Make decompiler and transformers optional #58

Kentzo opened this issue Sep 10, 2017 · 6 comments

Comments

@Kentzo
Copy link

Kentzo commented Sep 10, 2017

If I understand correctly, both decompiler and transformers are optional to the main functionality of the package: inspection and modification of code objects.

I propose to make both packages optional (e.g. via extras_require).

@llllllllll
Copy link
Owner

What would the benefit of this be?

@Kentzo
Copy link
Author

Kentzo commented Sep 10, 2017

The idea is to break dependency between generic core and utility functions that depend on specific Python. Version on codetransforms is currently broken for Python 3.6 because of them. Also see #60.

Perhaps they can be made optional (no import in __init__)?

@llllllllll
Copy link
Owner

llllllllll commented Sep 10, 2017

The 3.6 issue has already been resolved on master. #57

@Kentzo
Copy link
Author

Kentzo commented Sep 10, 2017

Are there precautions against further opcode changes?

It would be unfortunate to end up with incompatible package because of this.

@llllllllll
Copy link
Owner

Not currently, is there a reason to be this worried about codetransformer breaking on new versions of Python. Currently we do not support new versions of python right away regardless of how codetransformer is packaged.

@Kentzo
Copy link
Author

Kentzo commented Sep 10, 2017

Given what this package tries to accomplish it's indeed impossible to give any promises since CPython does not give them in the first place. However, certain parts of CPython were proven to be more stable than other.

I do not see how users benefit of automatic import of utility classes that are more fragile than the rest of the package.

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

2 participants