PEP 8: on member variables vs. attributes 
Author Message
 PEP 8: on member variables vs. attributes

From PEP 8:

Designing for inheritance

      ...  In general, never make data
      variables public unless you're implementing essentially a
      record.  It's almost always preferrable to give a functional
      interface to your class instead (and some python 2.2
      developments will make this much nicer)...

But don't properties and data variables (as attributes) look
the same anyway?  So what's the diff between them, functionally
speaking?  Hasn't it been decided that get/set accessor
functions are a real hassle and that is why we see the concept
of a property replacing that of accessor methods (Delphi's
Object Pascal seems to have pioneered this) in newer
languages like C# and now also in Python via descriptors?
That would seem to contradict this particular point found in
PEP 8.



Tue, 05 Jul 2005 16:41:46 GMT  
 PEP 8: on member variables vs. attributes


Quote:
> From PEP 8:

> Designing for inheritance

>       ...  In general, never make data
>       variables public unless you're implementing essentially a
>       record.  It's almost always preferrable to give a functional
>       interface to your class instead (and some Python 2.2
>       developments will make this much nicer)...

> But don't properties and data variables (as attributes) look
> the same anyway?  So what's the diff between them, functionally
> speaking?  Hasn't it been decided that get/set accessor
> functions are a real hassle and that is why we see the concept
> of a property replacing that of accessor methods (Delphi's
> Object Pascal seems to have pioneered this) in newer
> languages like C# and now also in Python via descriptors?
> That would seem to contradict this particular point found in
> PEP 8.

They look the same, but they aren't the same thing at all.
Properties are simply a piece of syntactic sugar on top
of accessor functions. As such, they provide the same
information hiding benefits as accessors.

It's a nice piece of syntactic sugar, but it does not provide
anything fundamental that can't be accomplished in some
other way.

What it does provide is clarity and a level of encapsulation
that facilitates maintenance.

John Roth



Tue, 05 Jul 2005 20:47:12 GMT  
 PEP 8: on member variables vs. attributes


Wed, 18 Jun 1902 08:00:00 GMT  
 PEP 8: on member variables vs. attributes

Quote:

> Properties are simply a piece of syntactic sugar on top
> of accessor functions. As such, they provide the same
> information hiding benefits as accessors.

> It's a nice piece of syntactic sugar, but it does not provide
> anything fundamental that can't be accomplished in some
> other way.

> What it does provide is clarity and a level of encapsulation
> that facilitates maintenance.

They can also provide an obfuscation technique because they
make implicit things that should sometimes be explicit.  I
think this might be Yet Another Tool That can Easily be
Abused in the hands of an unthinking programmer.

When I was leading a team doing lots of Delphi development,
several developers (who had used Delphi much longer than I)
insisted on using properties for just about everything.  No
accessor methods at all.  

I rebelled against this at the time, almost outlawing properties,
because it got to the point where I couldn't tell when something
was just setting a value, possibly with a check or clipping or
something applied, and when the code -- which looked like a simple
assignment -- was actually storing some data in a file, sending
a message to another thread, stopping the machine's motion, and
then launching a Space Shuttle.

No doubt forbidding them was an overreaction, but at least it
let us start getting a handle on the complexity of the code.

I've been looking forward to having a chance to let them redeem
themselves when I start using them with Python... if they can.
Do they really enhance clarity and maintenance, or might they be
more _in the way_ of easy comprehension?

-Peter



Tue, 05 Jul 2005 22:14:59 GMT  
 PEP 8: on member variables vs. attributes


Quote:

> > Properties are simply a piece of syntactic sugar on top
> > of accessor functions. As such, they provide the same
> > information hiding benefits as accessors.

> > It's a nice piece of syntactic sugar, but it does not provide
> > anything fundamental that can't be accomplished in some
> > other way.

> > What it does provide is clarity and a level of encapsulation
> > that facilitates maintenance.

> They can also provide an obfuscation technique because they
> make implicit things that should sometimes be explicit.  I
> think this might be Yet Another Tool That can Easily be
> Abused in the hands of an unthinking programmer.

> When I was leading a team doing lots of Delphi development,
> several developers (who had used Delphi much longer than I)
> insisted on using properties for just about everything.  No
> accessor methods at all.

> I rebelled against this at the time, almost outlawing properties,
> because it got to the point where I couldn't tell when something
> was just setting a value, possibly with a check or clipping or
> something applied, and when the code -- which looked like a simple
> assignment -- was actually storing some data in a file, sending
> a message to another thread, stopping the machine's motion, and
> then launching a Space Shuttle.

> No doubt forbidding them was an overreaction, but at least it
> let us start getting a handle on the complexity of the code.

I'd say it was a slight overreaction, but only slight. My take on
the underlying problem is that there wasn't a good understanding
of what looks like a variable and what's a method.

My feeling is that if I can't name it as a variable, then it's not
a variable, it's a method.

Quote:
> I've been looking forward to having a chance to let them redeem
> themselves when I start using them with Python... if they can.
> Do they really enhance clarity and maintenance, or might they be
> more _in the way_ of easy comprehension?

I think naming standards help here, but I've certainly got nothing
against using accessor functions for everything. What I don't like
is exposing the *real* instance variables. That way leads to more
coupling and a harder time maintaining the program.

John Roth

- Show quoted text -

Quote:

> -Peter



Tue, 05 Jul 2005 23:28:51 GMT  
 PEP 8: on member variables vs. attributes

Quote:

> I rebelled against this at the time, almost outlawing properties,
> because it got to the point where I couldn't tell when something
> was just setting a value, possibly with a check or clipping or
> something applied, and when the code -- which looked like a simple
> assignment -- was actually storing some data in a file, sending
> a message to another thread, stopping the machine's motion, and
> then launching a Space Shuttle.

> No doubt forbidding them was an overreaction, but at least it
> let us start getting a handle on the complexity of the code.
> I've been looking forward to having a chance to let them redeem
> themselves when I start using them with Python... if they can.
> Do they really enhance clarity and maintenance, or might they be
> more _in the way_ of easy comprehension?

This is a judgement call based on what level of abstaction you want
for the solving of your problem.  Do you want any of your programmers
to _care_ that what really happens when a state changes is 'store some
data in a file, send a message to another thread ....'?  If their
reaction is 'we're mathematicians, don't talk to us about hardware'
then they may be absolutely correct.

Laura Creighton



Tue, 05 Jul 2005 22:55:08 GMT  
 PEP 8: on member variables vs. attributes


Wed, 18 Jun 1902 08:00:00 GMT  
 PEP 8: on member variables vs. attributes

Quote:

> From PEP 8:

> Designing for inheritance

>       ...  In general, never make data
>       variables public unless you're implementing essentially a
>       record.  It's almost always preferrable to give a functional
>       interface to your class instead (and some Python 2.2
>       developments will make this much nicer)...

> But don't properties and data variables (as attributes) look
> the same anyway?  So what's the diff between them, functionally
> speaking?
>>> class Foo(object):

...    def __init__(self):
...       self.__bar = ""
...    def __getBar(self):
...       return self.__bar
...    def __setBar(self, value):
...       if isinstance(value, str):
...          self.__bar = value
...       else:
...          raise TypeError("bar must be a string")
...    bar = property(__getBar, __setBar)
...
Quote:
>>> baz = Foo()
>>> baz.bar = 4

Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<stdin>", line 10, in __setBar
TypeError: bar must be a string

If bar was just a data variable, you'd have no control over what got assigned to it.



Wed, 06 Jul 2005 00:36:23 GMT  
 PEP 8: on member variables vs. attributes


Wed, 18 Jun 1902 08:00:00 GMT  
 PEP 8: on member variables vs. attributes

|>
|> I rebelled against this at the time, almost outlawing properties,
|> because it got to the point where I couldn't tell when something
|> was just setting a value, possibly with a check or clipping or
|> something applied, and when the code -- which looked like a simple
|> assignment -- was actually storing some data in a file, sending
|> a message to another thread, stopping the machine's motion, and
|> then launching a Space Shuttle.
|>
|> No doubt forbidding them was an overreaction, but at least it
|> let us start getting a handle on the complexity of the code.
|
|> I've been looking forward to having a chance to let them redeem
|> themselves when I start using them with Python... if they can.
|> Do they really enhance clarity and maintenance, or might they be
|> more _in the way_ of easy comprehension?
|
| This is a judgement call based on what level of abstaction you want
| for the solving of your problem.  Do you want any of your programmers
| to _care_ that what really happens when a state changes is 'store some
| data in a file, send a message to another thread ....'?  If their
| reaction is 'we're mathematicians, don't talk to us about hardware'
| then they may be absolutely correct.

Maybe it's because my programming career has never taken me into
the rarified world of large projects with an organized collaborative
structure like that, but I'm getting the feeling that my model of
programming is different than yours.

In my world, everyone who deals with code is eventually liable to care
how it works.  Especially with regard to state changes or side effects.
Not so much because we're itching to exploit this knowledge for evil
violations of one kind or another, more because it's eventually the only
way to understand why it works the way it does.  (Note ``eventually'',
I'm speaking of a last resort but a common one.)  We can't afford to
make code opaque to anyone.

Python's notation and the ``consenting {*filter*}s'' attitude help make code
more reliably understandable, for users and I think even for its authors.
That used to be one of the attractions of Python.  I'm sure that there
are other ways to live where that wouldn't be such a big concern, but
of course there are many other programming languages too.




Wed, 06 Jul 2005 01:52:20 GMT  
 PEP 8: on member variables vs. attributes

Quote:

> In my world, everyone who deals with code is eventually liable to care
> how it works.  Especially with regard to state changes or side effects.
> Not so much because we're itching to exploit this knowledge for evil
> violations of one kind or another, more because it's eventually the only
> way to understand why it works the way it does.  (Note ``eventually'',
> I'm speaking of a last resort but a common one.)  We can't afford to
> make code opaque to anyone.

One of the programmers, whom I respected very much on the project I
mentioned, was quite of the opposite view to mine.  He kept insisting
that one shouldn't *want* to know what a given property does.  He
used the example of a library package, where "clearly" I shouldn't
have to know about all the nitty-gritty details that go on under
the hood.

In the end, we found agreement based on one point: so long as one
cannot *trust* that the library is *bomb-proof, bug-free, fully
documented code*, there's a good chance one needs to know what is
going on underneath, especially to work around problems or even
just to figure out how to use the library.

I was of the opinion that we were not using, or creating, such
a library, and that therefore we had to insist on very limited
use of properties.

I guess I'm saying that the principle is sound, but practically I
have yet to see a situation where it would work for me.

-Peter



Wed, 06 Jul 2005 03:20:49 GMT  
 PEP 8: on member variables vs. attributes

Quote:

> > In my world, everyone who deals with code is eventually liable to care
> > how it works.  Especially with regard to state changes or side effects.
> > Not so much because we're itching to exploit this knowledge for evil
> > violations of one kind or another, more because it's eventually the only
> > way to understand why it works the way it does.  (Note ``eventually'',
> > I'm speaking of a last resort but a common one.)  We can't afford to
> > make code opaque to anyone.

> One of the programmers, whom I respected very much on the project I
> mentioned, was quite of the opposite view to mine.  He kept insisting
> that one shouldn't *want* to know what a given property does.  He
> used the example of a library package, where "clearly" I shouldn't
> have to know about all the nitty-gritty details that go on under
> the hood.

> In the end, we found agreement based on one point: so long as one
> cannot *trust* that the library is *bomb-proof, bug-free, fully
> documented code*, there's a good chance one needs to know what is
> going on underneath, especially to work around problems or even
> just to figure out how to use the library.

> I was of the opinion that we were not using, or creating, such
> a library, and that therefore we had to insist on very limited
> use of properties.

> I guess I'm saying that the principle is sound, but practically I
> have yet to see a situation where it would work for me.

One reason why a property-based approach might work better in Python is its
superior exception handling, which (while it might produce some surprises,
just like database triggers can) at least allows property-handling errors to
be trapped outside.

regards
--
Steve Holden                                  http://www.holdenweb.com/
Python Web Programming                 http://pydish.holdenweb.com/pwp/
Bring your musical instrument to PyCon!    http://www.python.org/pycon/



Wed, 06 Jul 2005 04:26:35 GMT  
 PEP 8: on member variables vs. attributes


Quote:


> > I rebelled against this at the time, almost outlawing properties,
> > because it got to the point where I couldn't tell when something
> > was just setting a value, possibly with a check or clipping or
> > something applied, and when the code -- which looked like a simple
> > assignment -- was actually storing some data in a file, sending
> > a message to another thread, stopping the machine's motion, and
> > then launching a Space Shuttle.

> > No doubt forbidding them was an overreaction, but at least it
> > let us start getting a handle on the complexity of the code.

> > I've been looking forward to having a chance to let them redeem
> > themselves when I start using them with Python... if they can.
> > Do they really enhance clarity and maintenance, or might they be
> > more _in the way_ of easy comprehension?

> This is a judgement call based on what level of abstaction you want
> for the solving of your problem.  Do you want any of your programmers
> to _care_ that what really happens when a state changes is 'store some
> data in a file, send a message to another thread ....'?  If their
> reaction is 'we're mathematicians, don't talk to us about hardware'
> then they may be absolutely correct.

I don't think any library exists that is that clean in the real world.
I certainly have never encountered one that hasn't, at some point,
turned around and bit me because the library's assumptions didn't
match my understanding.

John Roth

- Show quoted text -

Quote:

> Laura Creighton



Wed, 06 Jul 2005 05:30:20 GMT  
 PEP 8: on member variables vs. attributes


Wed, 18 Jun 1902 08:00:00 GMT  
 PEP 8: on member variables vs. attributes

Quote:
> From PEP 8:

> Designing for inheritance

>       ...  In general, never make data
>       variables public unless you're implementing essentially a
>       record.  It's almost always preferrable to give a functional
>       interface to your class instead (and some Python 2.2
>       developments will make this much nicer)...

I get both your points.  I guess my precise question would
be:  Doesn't the recommendation to use properties (for
its syntactic sugar benefits) essentially deprecate the
suggestion to make a 'functional' interface to your class?
Properties, after all, are identical in usage to attributes.  
I guess better clarifying language is needed in the PEP.


Wed, 06 Jul 2005 11:39:30 GMT  
 
 [ 18 post ]  Go to page: [1] [2]

 Relevant Pages 

1. PEP 266: Optimizing Global Variable/Attribute Access

2. Proposed PEP: Optimizing Global Variable and Attribute Access

3. Types (was: Attribute vs Instance Variable)

4. Why memq vs memv vs member, etc.?

5. Attributes PEP Enhancement

6. New PEP: Attribute Access Handlers

7. PEP 288: Generator Attributes

8. Template objects as member-variables

9. SWIG, C++ and static member variables

10. How to implement OOP member variables?

11. Problem accessing different member variables in class depending on passed in value

12. Static member variables

 

 
Powered by phpBB® Forum Software