Re: python imports

Eric,

Consider the python code:

    from a.b.c import name

Parser builds two include tags:

  ("a.b.c" include nil nil [<begin> <end>])
  ("a.b.c.name" include nil nil [<begin> <end>])

By clicking on "a.b.c" it goes to "a.b.c" module.
By clicking on "name" it goes to "a.b.c.name" module or to the function
"name" in the module "a.b.c".

So the tag ("a.b.c.name" include nil nil [58 62]) can map to:

    file: a/b/c/name.py
    file: a/b/c.py class: name
    file: a/b/c/name/__init__.py

I can't make a decision in the function 'semantic-tag-include-filename'
because i don't know PYTHONPATHs.
After investigating the code this function:
(semantic-dependency-find-file-on-path "a.b.c.name" ....) looks a right
place.

What do you think?

Thanks,
-Andrey

On 30 September 2014 19:43, Andrey Torba <[email protected]> wrote:

> Thank you Eric. Now i got it. I did not know i can pass complex structures
> as tag names.
>
> I've managed to build grammar that parses python's imports properly
>
> Thanks,
> -Andrey
>
> On 29 September 2014 16:49, Eric M. Ludlam <[email protected]> wrote:
>
>> Hi Andrey,
>>
>> Sorry for the delay in replying.
>>
>> Converting a tag generated by the grammar into something used in the
>> buffer is a multi-step process.
>>
>> The "tags" returned from the parser can have additional internal
>> structure that represents a sort of "multi-tag" nature, or you can add
>> any other data you need.
>>
>> For example, in the C parser, the "name" of the variable:
>>
>> int x,y,z;
>>
>> is a list of 3 names, then the expand-tag function re-assembles that tag
>> into 3 new tags.
>>
>> In wisent/python.el you will see it is already monkeying around with the
>> tags.  In your case, your rule:
>>
>>     | FROM dotted_name_module IMPORT import_block
>>
>>
>> could have an action of:
>>
>>      (:module-name $2  :import $4)
>>
>> and then that could be stuck in as the "name" of the import.
>>
>> Then back in python.el's semantic-python-expand-tag function could
>> re-assemble all the :import parts with the :module-name and then deal
>> those out into the different include tags.  You could also tag the
>> import as a module instead of an include if that makes sense by changing
>> the tag class to any symbol you want.   If you invent a new kind of tag
>> class, you will need to update the tag formatters and other entries that
>> try to convert tags into other formats.
>>
>> If you feel more clever, you could stash the character locations of the
>> 2nd and 3rd module using $region inside the import_block, and then use
>> that to give those tags different positions in the buffer.
>>
>> I hope this helps!
>> Eric
>>
>>
>> On 09/29/2014 01:45 AM, Andrey Torba wrote:
>> > Hi all,
>> >
>> > In order to parse this python code:
>> >
>> > from a.b.c import (
>> >      x as xmodule,
>> >      y as ymodule,
>> >      z as zmodule,
>> >      )
>> >
>> > I created grammar:
>> >
>> > import_stmt
>> > ....
>> >    | FROM dotted_name_module IMPORT import_block
>> >      (identity $4)
>> >                          <- lisp code here which prepend "a.b.c" for
>> > each found module?
>> >    ;
>> >
>> > import_block
>> >    : PAREN_BLOCK
>> >      (let ((wisent-python-EXPANDING-block t))
>> >        (EXPANDFULL $1 import_block_as_name_list))
>> >    ;
>> >
>> > import_block_as_name_list
>> >    : LPAREN
>> >    | RPAREN
>> >    | import_as_name COMMA
>> >    | import_as_name RPAREN
>> >    ;
>> >
>> > As a result I get 3 modules: "x", "y", "z". How can i prepend "a.b.c"
>> > for each module?
>> > Also i think parser should create 3 global variables of type 'module':
>> > xmodule, ymodule, zmodule
>> >
>> > Thanks,
>> > -Andrey
>> >
>> >
>> > On 27 September 2014 16:14, Andrey Torba <[email protected]
>> > <mailto:[email protected]>> wrote:
>> >
>> >     Hello CEDET developers,
>> >
>> >     I'm investigating how to parse python's imports for the cases:
>> >
>> >     1. from ... import <classes> (works well in current implementation)
>> >        Example:
>> >        from a.b.c import Class1, Class2
>> >
>> >     2. from ... import <modules> (doesn't work)
>> >        Example:
>> >        from a.b.c import module1, module2
>> >
>> >        In this case parser must create:
>> >          - two INCLUDE-TAGs: 'a.b.c.module1' and 'a.b.c.module2'.
>> >
>> >     When we import something we don't know if it is module or class or
>> >     function... So include-tag should be 'a.b.c.something',
>> >     'a.b.c.class1', 'a.b.c.module1'. And then in the functions
>> >     'semantic-dependency-find-file-on-path' and
>> >     'semantic-tag-include-filename' we can guess which file to open:
>> >        - a/b/c/something.py
>> >        - a/b/c.py   class:something
>> >        - a/b/c/__init__.py    class:something
>> >
>> >     My question is: how can i build the grammar which makes 2 include
>> >     tags from the string: 'from a.b.c import module1, module2'. I need
>> >     to remember context ('a.b.c') and then build a full module path
>> >     (format "%s.%s" "a.b.c" "module1") ?
>> >
>> >     Thanks,
>> >     -Andrey
>> >
>> >
>> >
>> >
>> > --
>> > Regards, Andrey
>> >
>> >
>> >
>> ------------------------------------------------------------------------------
>> > Slashdot TV.  Videos for Nerds.  Stuff that Matters.
>> >
>> http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
>> >
>> >
>> >
>> > _______________________________________________
>> > Cedet-devel mailing list
>> > [email protected]
>> > https://lists.sourceforge.net/lists/listinfo/cedet-devel
>> >
>>
>>
>> ------------------------------------------------------------------------------
>> Slashdot TV.  Videos for Nerds.  Stuff that Matters.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Cedet-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/cedet-devel
>>
>
>
>
> --
> Regards, Andrey
>



-- 
Regards, Andrey

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk

_______________________________________________
Cedet-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/cedet-devel