Dan Sommers [EMAIL PROTECTED] wrote:
On 28 Feb 2005 10:30:03 GMT,
Nick Craig-Wood [EMAIL PROTECTED] wrote:
Actually I would say just access the attribute directly for both get
and set, until it needs to do something special in which case use
property().
The reason why people fill
Andrew Dalke wrote:
Me:
What's wrong with the use of attributes in this case and how
would you write your interface?
Dan Sommers:
I think I'd add a change_temperature_to method that accepts the target
temperature and some sort of timing information, depending on how the
rest of the program and/or
to every single member of
every single class you write. Only provide accessor/mutator functions
if the accessor/mutator methods are a sensible and useful part of the
class's interface.
2. Don't think of these methods as accessors or mutators. Instead,
think
of them as methods that access or mutate
On Tue, 01 Mar 2005 05:37:44 -0500,
Steve Holden [EMAIL PROTECTED] wrote:
Indeed, but it also comes down to control paradigm. I don't *know*,
but I'll make a guess that Dan, who admits to being old school,
hasn't done a lot of work with GUIs, which are inherently event-based.
Not a lot of
On 01 Mar 2005 10:30:01 GMT,
Nick Craig-Wood [EMAIL PROTECTED] wrote:
However in python, there is no harm in accessing the attributes
directly. You can change the implementation whenever you like, and
change the attributes into property()s and the users will never know.
[ ... ]
Read only
Dan Sommers [EMAIL PROTECTED] wrote:
We used to have holy wars over the appropriate level of comments in
source code.
Well according to the refactoring book I just read (by Martin Fowler)
the appropriate level of comments is None. If you see a comment you
should extract the complicated code
Steve Holden wrote:
Carl Banks wrote:
Don't use getattr and setattr unless you have to construct the name
of
the attribute at run time. That's what they're for.
Well, they are surely helpful in delegation contexts as well, or do I
misunderstand?
I consider that a degenerate form of
Michael Spencer [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
When I look at how classes are set up in other languages (e.g. C++), I
often observe the following patterns:
1) for each data member, the class will have an accessor member
function (a Getwhatever function)
2) for each
On 28 Feb 2005 10:30:03 GMT,
Nick Craig-Wood [EMAIL PROTECTED] wrote:
Actually I would say just access the attribute directly for both get
and set, until it needs to do something special in which case use
property().
The reason why people fill their code up with boiler plate get/set
methods
backwards-compatible, go ahead
and use them. But try to observe the following rules of thumb:
1. Don't provide accessor or mutator function to every single member of
every single class you write. Only provide accessor/mutator functions
if the accessor/mutator methods are a sensible and useful part
On Mon, 28 Feb 2005 15:50:22 -0500, Dan Sommers wrote:
The reason their code is so inflexible is that they've filled their
classes with boiler plate get/set methods.
Why do users of classes need such access anyway? If my class performs
useful functions and returns useful results, no user of
Dan Sommers wrote:
I think I'd add a change_temperature_to method that accepts the target
temperature and some sort of timing information, depending on how the rest
of the program and/or thread is structured.
But then you put application logic into a library function. Doing this
consistently
On Tue, 01 Mar 2005 01:39:13 +0100,
Thomas Lotze [EMAIL PROTECTED] wrote:
Dan Sommers wrote:
I think I'd add a change_temperature_to method that accepts the
target temperature and some sort of timing information, depending on
how the rest of the program and/or thread is structured.
But
Me:
What's wrong with the use of attributes in this case and how
would you write your interface?
Dan Sommers:
I think I'd add a change_temperature_to method that accepts the target
temperature and some sort of timing information, depending on how the
rest of the program and/or thread is
On Tue, 01 Mar 2005 02:27:03 GMT,
Andrew Dalke [EMAIL PROTECTED] wrote:
Me:
What's wrong with the use of attributes in this case and how
would you write your interface?
Dan Sommers:
I think I'd add a change_temperature_to method that accepts the target
temperature and some sort of timing
When I look at how classes are set up in other languages (e.g. C++), I
often observe the following patterns:
1) for each data member, the class will have an accessor member
function (a Getwhatever function)
2) for each data member, the class will have a mutator member function
(a Setwhatver
[EMAIL PROTECTED] wrote:
When I look at how classes are set up in other languages (e.g. C++), I
often observe the following patterns:
1) for each data member, the class will have an accessor member
function (a Getwhatever function)
2) for each data member, the class will have a mutator member
My questions are:
a) Are the three things above considered pythonic?
Python uses a function called 'property to achieve the same effect.
This example is taken from the documentation:
class C(object):
def __init__(self):
self.__x = 0
def getx(self):
If the class had two attributes--x and y--would the code look like
something lik this:
class C(object):
def __init__(self):
self.__x = 0
self.__y = 0
def getx(self):
return self.__x
def setx(self, x):
if x 0: x = 0
Because if so, does the term 'lazy evaluation' refer to the fact that
instead of:
No, it is a common technical term. It means that a value is computed the
time it is requested for the first time.
Like this:
class Foo(object):
def __init__(self):
self.__bar = None
def
[EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
When I look at how classes are set up in other languages (e.g. C++), I
often observe the following patterns:
1) for each data member, the class will have an accessor member
function (a Getwhatever function)
2) for each data member,
is that it leaves the
accessor/mutator functions in the namespace. That may be a good or a bad thing.
If bad, you could simply delete them after the property call (which is
probably better written as close as possible to the functions)
i.e., class C(object):
def __init__(self):
self.__x
22 matches
Mail list logo
