PEP 8 and properties

[John Roth]

"Jonathan P." <jbperez808 at yahoo.com> wrote in message
news:f57664b9.0301191717.2fa584d5 at posting.google.com...
> From PEP 8:
>
> Designing for inheritance
>
>   ...  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)...
>
> Do properties (what I believe is being referred to
> by the phrase 'some Python 2.2 developments') count
> as a functional interface?  Their usage is identical
> to public variables/attributes, so I have to disagree.

I think there's some confusion here. The dictum that
you don't expose variables comes from the "information
hiding" school of thought. A variable is part of the
internal implementation of the class, and you should
be able to change it freely. A function, on the other
hand, is part of an API, and doesn't constrain changes
to the implementation nearly as much.

Now, if the language includes properties, then the
assessment changes, because there is no external
difference between variables and properties. You
can publish a variable, and then if you want to change
the implementation so that the variable doesn't (even
conceptually) exist any more, you can make it
a property, which lets you slide the accessor functions
in under the hood.

> I have yet to be fully convinced that accessor
> functions (and now, properties) are a good
> abstraction.  I'm very uncomfortable about the
> idea of properties allowing side effects.  I
> can't help but feel that they are yet another
> addition to that mess of conceptual kludges known
> as OOP.  OOP seems to have much less of a solid
> theoretical foundation than the relational or
> functional models and it shows in all the annoying
> complexity you see in most OOP languages.  I
> wonder if studying Smalltalk can yield some OOP
> wisdom.  OOP was originally only about message
> passing between objects, but it has strayed from
> the path of its (purported) initial simplicity.
> ( guess who/which language is to blame ;-) )
>
> I believe that Python's language design is such
> that direct usage of 'public variables' is
> not a bad practice at all.  I'm currently building
> a fairly complex class library and should be in a
> position to prove or disprove this to myself.

I personally prefer simple variables for one reason:
you can assign to a variable while you cannot assign
to an accessor function.

On the other hand, functions protect you from
spelling errors.

John Roth