Re: python imports

"Eric M. Ludlam" <[email protected]>
Newsgroups gmane.emacs.cedet
Message-ID <[email protected]>
I am somewhat confused by what you are asking.

For languages like C/C++, the translation from symbol name like "a.b.c" 
into a file name is handled where you noted, but that is just for 
converting from whatever unique symbology into a filename.  For example, 
in your override you might convert "a.b.c", into "a/b/c.py" or something 
like that.

Once you convert into a filename format, the function 
semantic-dependency-tag-file is another function you can override, 
though hopefully the default will do the right thing.  Use the functions 
semantic-add-system-include to make your files more findable.

Since you sometimes need to find a module, and other times need to find 
a file, your generated tags should have special :properties, such as 
:module t, or something.  When converting to a file name, you can look 
at that and decide if you want to name it in a module-like way, or in a 
file line way.

You can override semantic-dependency-tag-file to identify modules vs 
other files, and then call `semantic-dependency-tag-file-default' for 
files, and do something different for modules.

Semantic-dependnecy-find-file-on-path is called from 
semantic-dependency-tag-file-default, and is not overridable.  It is a 
utility for scanning through the various include paths that might have 
come in from different sources (semantic, ede, custom, etc) that you can 
use when overriding tag-file-default.

I hope that helps.
Eric

On 10/01/2014 01:49 AM, Andrey Torba wrote:
> 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 <http://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 <http://a.b.c.name>" module
> or to the function "name" in the module "a.b.c".
>
> So the tag ("a.b.c.name <http://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 <http://a.b.c.name>"
> ....) looks a right place.
>
> What do you think?
>
> Thanks,
> -Andrey
>
> On 30 September 2014 19:43, Andrey Torba <[email protected]
> <mailto:[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]
>     <mailto:[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]>
>          > <mailto:[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]
>         <mailto:[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]
>         <mailto:[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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.