Re: Representation of python code ?

[Maric Michaud]

Le Sunday 14 September 2008 15:44:03 Barak, Ron, vous avez écrit*:

Hi Guys,
Is there a script/application, which gets as input python code, and
produces a (graphic) representation of the inter-relationships between its
classes/functions ? Bye,

None I know of. Not saying that it would be unfeasible, but it would be a hard
job, given the fact that most of relationships are purely dynamic.

How such an application would find the relationship (composition) between A
and B without executing this code ?

class A :
def __init__(self) :
self._b = B()

class B : pass
--
_____________

Maric Michaud

[showellshowell]

On Sep 15, 4:38*am, Maric Michaud <[e-mail]:

Le Sunday 14 September 2008 15:44:03 Barak, Ron, vous avez écrit*:

Hi Guys,
Is there a script/application, which gets as input python code, and
produces a (graphic) representation of the inter-relationships between its
classes/functions ? Bye,

If you can't find anything that's already packaged up and polished,
one possibility is to use the parser and/or compiler.ast modules in
Python to analyze your code, then produce something that graphviz can
consume.

Graphviz is something really nice to have in your bag of tricks,
anyway.

http://www.graphviz.org/

None I know of. Not saying that it would be unfeasible, but it would be ahard
job, given the fact that most of relationships are purely dynamic.

How such an application would find the relationship (composition) betweenA
and B without executing this code ?

I'm not sure this is the best counterexample. You can see statically
that A potentially creates an instance of the B class.

class A :
* * def __init__(self) :
* * * * *self._b = B()

class B : pass

[Maric Michaud]

Le Monday 15 September 2008 16:06:19 sh************@gmail.com, vous avez
écrit*:

I'm not sure this is the best counterexample. *You can see statically
that A potentially creates an instance of the B class.

class A :
* * def __init__(self) :
* * * * *self._b = B()

class B : pass

Yes, you can, but are you sure it's obvious that B in A.__init__ is the class
you think of ?

--
_____________

Maric Michaud

[showellshowell]

On Sep 15, 7:17*am, Maric Michaud <[e-mail]:

Le Monday 15 September 2008 16:06:19 [e-mail], vous avez
écrit*:

I'm not sure this is the best counterexample. *You can see statically
that A potentially creates an instance of the B class.

class A :
* * def __init__(self) :
* * * * *self._b = B()

class B : pass

Yes, you can, but are you sure it's obvious that B in A.__init__ is the class
you think of ?

I'm guessing 99% of the time it will be. It seems to me that if
you're invoking classes in a truly dynamic way, you should be explicit
about it anyway, and give methods some kind of naming convention, like
have "factory" in the name. This would not only make it easy for a
visualization program not to be tricked, but it would help out your
human readers as well.

[Tim Golden]

sh************@gmail.com wrote:

On Sep 15, 4:38 am, Maric Michaud <[e-mail]:

>Le Sunday 14 September 2008 15:44:03 Barak, Ron, vous avez écrit :

>>Hi Guys,
Is there a script/application, which gets as input python code, and
produces a (graphic) representation of the inter-relationships between its
classes/functions ? Bye,

If you can't find anything that's already packaged up and polished,
one possibility is to use the parser and/or compiler.ast modules in
Python to analyze your code, then produce something that graphviz can
consume.

On that note, perhaps have a look at PySmell [1] which
Orestis Lightning-spoke about at PyconUK over the weekend.
It's designed as an autocompletion tool, but he mentioned
that the structure it generates could well be used for
other purposes.

TJG

[1] http://orestis.gr/blog/2008/08/31/announcing-pysmell/