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 relative path (bar/baz/biz.py),
split the filename / path and remove the extension {bar/baz, biz}, replace
/ with . and construct your import statement that way. That's if you're
generating a script to run. Which I still think is an odd thing to do,
since we could just run Python C API calls directly which do the right
things.
On Wed, Apr 6, 2016 at 7:53 AM Adrian McCarthy <amcca...@google.com> wrote:
> 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 in the temp script that's written
> to do the import? I would have thought the latter from everything I read
> yesterday.
>
> On Tue, Apr 5, 2016 at 6:29 PM, Zachary Turner <ztur...@google.com> wrote:
>
>> 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 any consolation, it would only be needed for shared/builtin
>> formatters.
>>
>> I guess it would help to get a better understanding of what the problem
>> is, if someone files a bug against me (or i can file it myself tomorrow) i
>> can investigate after I finish PDB stuff.
>>
>> In the meantime having it in seems like the best option imo
>>
>> On Tue, Apr 5, 2016 at 5:54 PM Jim Ingham <jing...@apple.com> wrote:
>>
>>> 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 and the like.
>>>
>>> Jim
>>>
>>>
>>> > On Apr 5, 2016, at 5:30 PM, Zachary Turner via lldb-commits <
>>> lldb-commits@lists.llvm.org> wrote:
>>> >
>>> > 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, 2016 at 4:01 PM Adrian McCarthy <amcca...@google.com>
>>> wrote:
>>> > "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 <ztur...@google.com>
>>> wrote:
>>> > Without the modification to sys.path
>>> >
>>> > On Tue, Apr 5, 2016 at 3:39 PM Zachary Turner <ztur...@google.com>
>>> wrote:
>>> > Can you try to change "import foo2" to "from .foo import foo2"
>>> > On Tue, Apr 5, 2016 at 2:52 PM Adrian McCarthy <amcca...@google.com>
>>> 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 vanilla Python import statement.
>>> >
>>> > I spoke with one of our local Python experts who said that this
>>> technique to specify the directory is probably unreliable, as the rules for
>>> where Python looks for modules has evolved. The rules for both relative
>>> and absolute module paths changed from Python 2 to 3.
>>> >
>>> > I'll revert the xfail if you want. But this has been broken for quite
>>> a while (as has another test, which I'm looking into now).
>>> >
>>> > On Tue, Apr 5, 2016 at 2:29 PM, Zachary Turner <ztur...@google.com>
>>> wrote:
>>> > 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 command until you get to the python or c code
>>> that tries to do the import
>>> >
>>> > On Tue, Apr 5, 2016 at 1:54 PM Adrian McCarthy via lldb-commits <
>>> lldb-commits@lists.llvm.org> wrote:
>>> > 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/command_script/import/TestImport.py
>>> >
>>> > Modified:
>>> lldb/trunk/packages/Python/lldbsuite/test/functionalities/command_script/import/TestImport.py
>>> > URL:
>>> http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/command_script/import/TestImport.py?rev=265461&r1=265460&r2=265461&view=diff
>>> >
>>> ==============================================================================
>>> > ---
>>> lldb/trunk/packages/Python/lldbsuite/test/functionalities/command_script/import/TestImport.py
>>> (original)
>>> > +++
>>> lldb/trunk/packages/Python/lldbsuite/test/functionalities/command_script/import/TestImport.py
>>> Tue Apr 5 15:49:09 2016
>>> > @@ -16,6 +16,7 @@ class ImportTestCase(TestBase):
>>> >
>>> > @add_test_categories(['pyapi'])
>>> > @no_debug_info_test
>>> > + @expectedFailureAll(oslist=["windows"], bugnumber="
>>> llvm.org/pr27227: Python 3 import rules are different")
>>> > def test_import_command(self):
>>> > """Import some Python scripts by path and test them"""
>>> > self.run_test()
>>> >
>>> >
>>> > _______________________________________________
>>> > lldb-commits mailing list
>>> > lldb-commits@lists.llvm.org
>>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>>> >
>>> >
>>> > _______________________________________________
>>> > lldb-commits mailing list
>>> > lldb-commits@lists.llvm.org
>>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>>>
>>>
>
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
