Skip to content

HACK: append sys.path from other major python via subprocess #539

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

Closed

Conversation

blueyed
Copy link
Contributor

@blueyed blueyed commented Jan 26, 2015

This makes working with Python 2 and 3 in parallel less painfull.

My use case is Jedi being used in Vim via YouCompleteMe, which only
supports Python 2, but I'd like to use the completion also when editing
Python 3 files.

What do you think? Is this a approach in the right direction?
See also #535 (API to adjust sys.path).

This makes working with Python 2 and 3 in parallel less painfull.

My use case is Jedi being used in Vim via YouCompleteMe, which only
supports Python 2, but I'd like to use the completion also when editing
Python 3 files.
@davidhalter
Copy link
Owner

Interesting, but this is really risky, because it can lead to segfaults. Jedi tries to import libraries like PyQt4 and so on. Those binaries must never be executed with the wrong Python version.

@blueyed
Copy link
Contributor Author

blueyed commented Jan 26, 2015

Those binaries must never be executed with the wrong Python version.

Is it possible to detect those somehow?
Are those in 'lib/python3.4/lib-dynload' usually - then that path could be skipped.

On my system, PyQt4 is installed in /usr/lib/python3/dist-packages/PyQt4.

@davidhalter
Copy link
Owner

I mean you could just create "ignore paths" for binaries. That would fix the issue.

But at the same time, I don't like the approach in general too much. I would rather have an implementation of #385, to make it easy to switch Python versions.

@blueyed
Copy link
Contributor Author

blueyed commented Mar 8, 2015

@davidhalter
Has this been closed automatically because the "parser" branch was deleted, or intentionally (given your last comment(s))?

@davidhalter
Copy link
Owner

automatic close. cannot even reopen it haha. Is it ok to keep it closed? IMHO this is not the way to go, because it's really just a workaround for a problem that I would like to solve different.

A patch I would accept would include something more like a fallback to just third party libraries, it would need a way to exclude all binary files. (or a different loading mechanism for binary files via multiprocessing).

This is definitely something that would take a lot of time to implement. If you're interested, go on. Otherwise you think that someone else would implement this (or you yourself want to do it). I just don't think that I will do it.

@blueyed
Copy link
Contributor Author

blueyed commented Mar 9, 2015

Is it ok to keep it closed?

Yes. Thanks for your additional information and feedback!

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

Successfully merging this pull request may close these issues.

2 participants