jf...@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 ;)
--
https://mail.python.org/mailman/listinfo/python-list
