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 fo
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 co
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 o
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
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 of the
class's interface.
2. Don't think of these methods as accessors or mutators. Instead,
think
of them as m
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
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 wh
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 sor
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 i
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.
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
consistentl
On Mon, 28 Feb 2005 23:08:04 GMT,
Andrew Dalke <[EMAIL PROTECTED]> wrote:
> 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 an
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 use
ou're
concerned about keeping the interface 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 acces
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
> m
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 Get function)
> > 2) for ea
ion 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):
se
<[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 Get function)
> 2) for each data member, the
> 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 getBar(se
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
> 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):
[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 Get function)
2) for each data member, the class will have a mutator member function
(a S
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 Get function)
2) for each data member, the class will have a mutator member function
(a Set function)
3) data memb
23 matches
Mail list logo
