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

CPython used for imported modules rather than byterun #26

Open
andychu opened this issue Apr 17, 2017 · 5 comments
Open

CPython used for imported modules rather than byterun #26

andychu opened this issue Apr 17, 2017 · 5 comments

Comments

@andychu
Copy link

andychu commented Apr 17, 2017

Thanks for this great project -- I'm learning a lot from it. I'm using byterun as a test of a bigger project, and I found and fixed a bug:

oils-for-unix/oils@62cd492

There are some irrelevant diffs there, but if you search for BUG FIX you will see this part. The core issue is that the MAKE_FUNCTION bytecode is not called if you do __import__. byterun uses the host __import__, which results in a native function, not a pyobj.Function. I also changed __repr__ of Function to make this more apparent.

Also of interest might be the speed tests at the end. I made two files: speed_main.py and speed.py. You will see that under byterun, using a function in library is much faster than using one in the same module, because it gets executed with CPython.

+ if isinstance(func, types.FunctionType):
+            defaults = func.func_defaults or ()
+            byterun_func = Function(
+                    func.func_name, func.func_code, func.func_globals,
+                    defaults, func.func_closure, self)
+        else:
+            byterun_func = func

If you are interested in a pull request, let me know. However I am highly confused about how you run byterun/__main__.py directly from the git repo with its relative imports? (and this is after 13 years of programming in Python, and being somewhat responsible for __main__.py beiing added in Python 2.5 or 2.6).

I guess you must either install it on the system or use some kind of wrapper? I think it is related to this:

http://stackoverflow.com/questions/11536764/how-to-fix-attempted-relative-import-in-non-package-even-with-init-py

I had to write a shell script wrapper than changed to the directory and used python -m byterun.__main__. Somehow changing PYTHONPATH didn't work.

@srepmub
Copy link

srepmub commented Oct 17, 2017

I also just ran into this when trying to run byterun with itself. byterun.main is only imported once, then cached, so run_fn is only called the first time.

it doesn't sound too hard to have a Module class, and replace import with a call to execfile or something similar.. is there a reason this hasn't been implemented yet?

@andychu
Copy link
Author

andychu commented Oct 17, 2017

I would guess that if you want it implemented you should send a patch yourself.

@srepmub
Copy link

srepmub commented Oct 19, 2017

sure, but before I spend lots of time on such a thing, it would be nice to know if there is a particular reason for it not being implemented yet..

@akaptur
Copy link
Contributor

akaptur commented Oct 19, 2017

Hi @srepmub and @andychu - thanks for the bug report! No, there’s not a good reason why this isn’t implemented yet, and a patch is welcome.

@andychu
Copy link
Author

andychu commented Oct 19, 2017

OK as far as I know the code I linked/quoted above fixes it. (I stopped working with this code some months ago and didn't get a response, so I didn't submit a patch.)

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

3 participants