Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #105081 > unrolled thread

What is the common technique used to cross-reference in module's method?

Back to article view | Back to comp.lang.python

Contents

  What is the common technique used to cross-reference in module's method? jfong@ms4.hinet.net - 2016-03-17 03:48 -0700
    Re: What is the common technique used to cross-reference in module's method? Peter Otten <__peter__@web.de> - 2016-03-17 12:09 +0100

#105081 — What is the common technique used to cross-reference in module's method?

There are two modules (say model.py and piece.py) which has methods need to refer to each other module's methods. I saw in a book using the way below, by assigning one (the Model) object to an attribute of the other (the Piece) bject.
-------------
##model.py
import piece
...
class Model(dict):
    ...
    def all_occupied_positions(self):
        ...

    def reset_to_initial_locations(self):
        self.clear()
        for position, value in START_PIECES_POSITION.items():
            self[position] = piece.create_piece(value)
            self[position].model = self
    ...

##piece.py
...
def create_piece(value):  # Note: it's a function
   ...
   return eval(...)  # the returned object is a Piece object

class Piece():
    ...
    def moves_available(self):
        model = self.model
        ...
        if item not in model.all_occupied_positions():
            ...
    ...
-----------
Is it a common way of doing this?

Why the author use the same module name "model" for those attribute and local names? Is it a good idea or bad?

--Jach

[toc] | [next] | [standalone]

#105084

jfong@ms4.hinet.net wrote:

> There are two modules (say model.py and piece.py) which has methods need
> to refer to each other module's methods. I saw in a book using the way
> below, by assigning one (the Model) object to an attribute of the other
> (the Piece) bject. -------------
> ##model.py
> import piece
> ...
> class Model(dict):
>     ...
>     def all_occupied_positions(self):
>         ...
> 
>     def reset_to_initial_locations(self):
>         self.clear()
>         for position, value in START_PIECES_POSITION.items():
>             self[position] = piece.create_piece(value)
>             self[position].model = self

I'd pass self to the factory

              self[position] = piece.create_piece(self, value)
>     ...
> 
> ##piece.py
> ...
> def create_piece(value):  # Note: it's a function
>    ...
>    return eval(...)  # the returned object is a Piece object

and would avoid the eval().

> class Piece():
>     ...
>     def moves_available(self):
>         model = self.model
>         ...
>         if item not in model.all_occupied_positions():
>             ...
>     ...
> -----------
> Is it a common way of doing this?

Yes, but it creates a reference cycle; if you want to avoid that for 
philosophical reasons or to save memory when there are many children (here: 
pieces) you have to provide the context (the model in this case) explicitly

def moves_available(self, model):
   ...
 
> Why the author use the same module name "model" for those attribute and
> local names? Is it a good idea or bad?

The name "model" and "piece" look natural for both the module and the 
instance. Does it confuse you? then it's bad ;)

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web