I think we actually came up with a better idea. the command script import
code is generating a temporary python file which actually does the import,
so we can generate the code so that it uses the imp module to do an import
by full pathname. An example of code that already does this is in
lldb/te
BTW, the same test fails on our windows->android buildbot (which still
uses python 2). I haven't investigated the issue yet, I'm writing it
just as an additional data point...
cheers,
pl
On 6 April 2016 at 16:19, Zachary Turner via lldb-commits
wrote:
> Well, it would belong anywhere that does a
Well, it would belong anywhere that does an import, so in theory it belongs
in every script. In the general case, for example if you are like this:
foo
|-- bar
| baz
|-- biz.py
And you are in foo and you want to import biz.py, you could do "from
bar.baz import biz". So you just get the
It will still be a bit of a trick to change the `command script import`
handling to do `from foo import blah` in the general case, since foo can't
really be an absolute file path.
And does the `from __future__ import absolute_import` really belong in the
script your importing? Or does it belong i
Afaik there's no way to do from future imports with the c api, and
executing the statement with RunOneLine doesn't do it either, it has to be
in the script because it's treated specially by the interpreter.
There might be a way to do it with some tricks that I didn't figure out
last time.
If its
Will this be necessary for everybody who uses "command script import" with
Python 3? If so, it would be really nice to do this work in "command script
import" if possible. Otherwise everybody will have to put this goo at the top
of every .py file they write for formatters & breakpoint commands
Yea I wasn't sure if the . would be necessary or not. If you write "from
__future__ import absolute_import" at the top of each of these python files
(foo.py and foo2.py or whatever they're called) then this should guarantee
that the behavior is the same in both Python 2 and Python 3
On Tue, Apr 5
"error: module importing failed: Parent module '' not loaded, cannot
perform relative import"
If you omit the dot (i.e., `from foo import foo2`), it appears to work, but
I'm not sure that does the right thing. I'll keep investigating.
On Tue, Apr 5, 2016 at 3:40 PM, Zachary Turner wrote:
> Wit
Without the modification to sys.path
On Tue, Apr 5, 2016 at 3:39 PM Zachary Turner wrote:
> Can you try to change "import foo2" to "from .foo import foo2"
> On Tue, Apr 5, 2016 at 2:52 PM Adrian McCarthy
> wrote:
>
>> I've drilled down into the Python import statement. It's
>> in ScriptInterpre
Can you try to change "import foo2" to "from .foo import foo2"
On Tue, Apr 5, 2016 at 2:52 PM Adrian McCarthy wrote:
> I've drilled down into the Python import statement. It's
> in ScriptInterpreterPython::LoadScriptingModule. The function inserts the
> diretory into sys.path and then issues a
I've drilled down into the Python import statement. It's
in ScriptInterpreterPython::LoadScriptingModule. The function inserts the
diretory into sys.path and then issues a vanilla Python import statement.
I spoke with one of our local Python experts who said that this technique
to specify the di
I think we need some more information before we xfail this. It would help
to drill down to either the python import statement or the
PyImport_ImportModule C api call that actually does the import.
If you can get that, i can help come up with a fix. Just need to step
through the execution of the co
Author: amccarth
Date: Tue Apr 5 15:49:09 2016
New Revision: 265461
URL: http://llvm.org/viewvc/llvm-project?rev=265461&view=rev
Log:
XFail TestImport.py on Windows because Python 3 import rules don't work that
way.
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/comman
13 matches
Mail list logo
