On 04/27/2016 09:06 PM, Christopher Reimer wrote:
On 4/27/2016 8:52 PM, Michael Torrie wrote:
In fact if it were me I would save game state to some kind of ini file,
which would mean manually going through each object and writing out the
relevant data to the ini file using the right syntax.
On 04/27/2016 10:06 PM, Christopher Reimer wrote:
> On 4/27/2016 8:52 PM, Michael Torrie wrote:
>> In fact if it were me I would save game state to some kind of ini file,
>> which would mean manually going through each object and writing out the
>> relevant data to the ini file using the right sy
On 4/27/2016 8:52 PM, Michael Torrie wrote:
In fact if it were me I would save game state to some kind of ini file,
which would mean manually going through each object and writing out the
relevant data to the ini file using the right syntax. And then reverse
the process when restoring from a fi
On 4/27/2016 8:05 PM, Ethan Furman wrote:
I ripped out the fetch_state because that will take more work -- you
can't pass a Pawn's saved state in to Piece and get the results you
want. pickle is worth looking at for saving/restoring.
The original idea was to pass a Pawn dictionary to the cons
On 04/27/2016 08:49 PM, Christopher Reimer wrote:
> On 4/27/2016 7:00 PM, Michael Torrie wrote:
>> I am guessing that the reason you are storing state as it's own
>> dictionary is so that you can pass the state itself to the constructor?
>
> Someone said it was bad to store the object itself to
On 4/27/2016 7:07 PM, Ben Finney wrote:
I would say the latter is more Pythonic, because it:
* Better conveys the intention (“set the value of the ‘self.key’
attribute”).
* Uses the built-in mechanisms of Python (don't invoke magic attributes,
instead use the system that makes use of them
On 04/27/2016 06:12 PM, Christopher Reimer wrote:
After considering the feedback I got for sanity checking my code, I've
decided to simplify the base class for the chess pieces (see code
below). All the variables are stored inside a dictionary with most
values accessible through properties. A cu
On 4/27/2016 7:00 PM, Michael Torrie wrote:
I am guessing that the reason you are storing state as it's own
dictionary is so that you can pass the state itself to the constructor?
Someone said it was bad to store the object itself to file (my original
plan) and that I should use a dictionary
On 4/26/2016 8:56 PM, Random832 wrote:
what exactly do you mean by property decorators? If you're just
accessing them in a dictionary what's the benefit over having the
values be simple attributes rather than properties?
After considering the feedback I got for sanity checking my code, I've
d
Christopher Reimer writes:
> On 4/27/2016 7:33 AM, Ian Kelly wrote:
>
> > self.__dict__ = {'key', 'value'}
> >
> > self.key = value
>
> Which expression is Pythonic?
(Note that assignment is not an expression in Python; assigment is a
statement.)
> I've seen both used in various examp
On 04/27/2016 07:12 PM, Christopher Reimer wrote:
> class Piece(object):
> def __init__(self, color, position, state=None):
> if state is None:
> self._state = {
> 'class': self.__class__.__name__,
> 'color': color,
> 'fi
On 4/27/2016 7:33 AM, Ian Kelly wrote:
This class definition looks muddled. Because Test2 inherits from dict,
the object referred to by "self" will be a dict, and self.__dict__ is
actually a *different* dict, containing the attributes of self. The
line:
self.__dict__ = {'key', 'value'}
is
On 4/27/2016 7:24 AM, Ian Kelly wrote:
Some other great questions to ask yourself are "do I really want
len(my_object) to return the number of items in this dict" and "do I
really want list(my_object) to return all the keys in this dict"? If
the answer to all those is yes, then it's probably fa
On 4/26/2016 8:56 PM, Random832 wrote:
what exactly do you mean by property decorators? If you're just
accessing them in a dictionary what's the benefit over having the
values be simple attributes rather than properties?
After considering the feedback I got for sanity checking my code, I've
d
On Tue, Apr 26, 2016 at 9:43 PM, Christopher Reimer
wrote:
> class Test2(dict):
> def __init__(self):
> self.__dict__ = {'key', 'value'}
This class definition looks muddled. Because Test2 inherits from dict,
the object referred to by "self" will be a dict, and self.__d
On Tue, Apr 26, 2016 at 11:31 PM, Ethan Furman wrote:
> On 04/26/2016 08:43 PM, Christopher Reimer wrote:
>
>> If I'm using a dictionary to store variables for an object, and
>> accessing the variable values from dictionary via property decorators,
>> would it be better to derive the class from ob
On 04/26/2016 08:54 PM, Ben Finney wrote:
(Note that “allow attribute-syntax access to dictionary items” does not
qualify as “better”, IMO; it qualifies as “needlessly confusing distinct
concepts”.)
Well, since one of the side-effects of class instances is to provide
"attribute-syntax access
On 04/26/2016 08:43 PM, Christopher Reimer wrote:
If I'm using a dictionary to store variables for an object, and
accessing the variable values from dictionary via property decorators,
would it be better to derive the class from object or dict?
class Test1(object):
def __init__(se
On Tue, Apr 26, 2016, at 23:43, Christopher Reimer wrote:
> Greetings,
>
> If I'm using a dictionary to store variables for an object, and
> accessing the variable values from dictionary via property decorators,
what exactly do you mean by property decorators? If you're just
accessing them in a
Christopher Reimer writes:
> If I'm using a dictionary to store variables for an object, and
> accessing the variable values from dictionary via property decorators
Why not use the built-in ‘dict’ type?
What does the new type do which isn't already better served by the
built-in ‘dict’ type?
(N
Greetings,
If I'm using a dictionary to store variables for an object, and
accessing the variable values from dictionary via property decorators,
would it be better to derive the class from object or dict?
class Test1(object):
def __init__(self):
self.state = {'key': '
21 matches
Mail list logo
