python3 import failure about jedi HOT 12 CLOSED

Can you tell me which line this is (which line fails)? Because Jedi is working under Python 3:

https://travis-ci.org/#!/davidhalter/jedi/jobs/2920044

from jedi.

It's the first module parsing, but I think it just stops there.

/tmp$ python3 -E
Python 3.1.3 (r313:86834, Nov 28 2010, 10:01:07)
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import jedi
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/politza/.local/lib/python3.1/site-packages/jedi-0.5b3-py3.1.egg/jedi/__init__.py", line 1, in <module>
    from .api import Script, NotFoundError, set_debug_function
  File "/home/politza/.local/lib/python3.1/site-packages/jedi-0.5b3-py3.1.egg/jedi/api.py", line 6, in <module>
    import parsing
ImportError: No module named parsing
>>>

-ap

from jedi.

I think test passes because of this line:

os.chdir(os.path.dirname(os.path.abspath(__file__)) + '/../jedi')

--

As you are in jedi/ directory, you have parsing.py at the current directory.

from jedi.

Python imports are reaaaaaly tedious sometimes...
http://bugs.python.org/issue992389 This issue says it all: Waiting to be fixed for 8 years :-) I'm not even sure if that's my problem, but still...

However, a solution for 3.3 wouldn't solve this anyway and since relative imports would be beautiful everywhere, but are no option (because they don't allow any form of circular imports, which is very strange, because as a user I don't see the difference), I have to stick to a third solution: sys.path hacks. Works great, IS ugly!

from jedi.

6f8d477

I think this solves the issue.

from jedi.

Isn't it going to be a problem when jedi library user want to use library called "debug", "keywords", "parsing", etc? I don't know if such libraries exist but there could be such libraries.

What is the problem? If circular import is your problem, can't you just import lazily or rearrange modules?

from jedi.

Isn't it going to be a problem when jedi library user want to use library called "debug", "keywords", "parsing", etc? I don't know if such libraries exist but there could be such libraries.

You're right, but I know of no better solution. Maybe I should remove the sys.path change again after the import?

What is the problem? If circular import is your problem, can't you just import lazily or rearrange modules?

Rearranging is really not an option, because the imports library needs evaluate and so on. The solution would be to throw everything in one file, which is even worse in terms of overview. I know that it is considered an anti-pattern, but I don't think there is a much better structure. Normally you don't have to write code that is recursive like this one. So you don't have that problem. Lazy importing is just ugly, isn't it?

from jedi.

argh, why do I always forget to mention the issue in my commits...
bfdfa67

from jedi.

I prefer lazy import over modifying sys.path. At least lazy import uses only "standard" import mechanism.

Modifying sys.path during import can be a problem when you hit some error while importing submodules because then you have moddified sys.path. Well, it's nitpicking but you can't stop user doing something like:

try:
    import jedi
    JEDI_AVAILABLE = True
except:
    JEDI_AVAILABLE = False
    # Here, you could have modified sys.path

BTW, by lazy import I mean importing modules at runtime:

def func():
    from SOME_MODULE_IMPORTING_ME import SOMETHING
    ...

I use this pattern sometime even if I don't have circular import, as it narrows namespace. If this function is not called a lot of times, of course.

from jedi.

I use this pattern sometime even if I don't have circular import, as it narrows namespace. If this function is not called a lot of times, of course.

Most Python libraries don't use that pattern, because it's slow. So I'm not doing it either (I call most functions a lot) But I know what you mean. It's just not an option for jedi. Because if you knew the internal structure, you would not even argue ;-). Afaik there are a few dependencies that could and should be resolved, but you won't get rid of the imports/evaluate dependency without lazy imports.

That said, this:

I prefer lazy import over modifying sys.path. At least lazy import uses only "standard" import mechanism.

is not an option anymore. So I'll have to stick to modifying sys.path. I don't like it, but there's no other 2.5/3.2 compatible way. I don't like the way imports are working right now (I'm not the only one). So I'll just stick to one hack in the main module, which is working and not influencing anything else.

from jedi.

If you need optional dependency to some modules, you often find using the lazy import pattern (or putting import in try clause). Or if you want fast start up time, lazy import is good. But I think jedi is not one of these.

I still feel uneasy about unconditionally doing sys.path.path(0). If some of modules your importing does sys.path.insert(0, ...) it breaks. But I guess I am too worried as you are using only standard libraries.

from jedi.

As long as I don't use dangerous stuff, it's working ;-)

from jedi.