> So -- to keep myself out of trouble -- I have started coding such things as,
> for example:

> result = table.use_deleted()       # returns True or False
> table.use_deleted(False)           # skip deleted records

> instead of

> result = table.use_deleted
> table.use_deleted = False

> My question:  is this [ severely | mildly | not at all ] un-pythonic?

> So -- to keep myself out of trouble -- I have started coding such things
> as, for example:

> result = table.use_deleted()       # returns True or False
> table.use_deleted(False)           # skip deleted records

> instead of

> result = table.use_deleted
> table.use_deleted = False

> My question:  is this [ severely | mildly | not at all ] un-pythonic?

>> The problem I have with properties is my typing.  I'll end up
>> assigning to an attribute, but get the spelling slightly wrong
>> (capitalized, or missing an underscore -- non-obvious things when
>> bug-hunting), so now I have an extra attribute which of course has
>> zero effect on what I'm trying to do and I start getting wierd results
>> like viewing deleted records when I *know* I set useDeleted = False...
>> 30 minutes later I notice it was /supposed/ to be use_deleted.  *sigh*

>> So -- to keep myself out of trouble -- I have started coding such
>> things as, for example:

>> result = table.use_deleted()       # returns True or False
>> table.use_deleted(False)           # skip deleted records

>> instead of

>> result = table.use_deleted
>> table.use_deleted = False

>> My question:  is this [ severely | mildly | not at all ] un-pythonic?

> Definitly and totally unpythonic. The first solution to your problem is
> to stick to standard naming conventions. If this is not enough, Chris
> pointed you to really useful tools. Also, you can override __setattr__
> to catch such errors - at least during the coding/debug phase.

>>> So -- to keep myself out of trouble -- I have started coding such things
>>> as, for example:

>>> result = table.use_deleted()       # returns True or False
>>> table.use_deleted(False)           # skip deleted records

>>> instead of

>>> result = table.use_deleted
>>> table.use_deleted = False

>>> My question:  is this [ severely | mildly | not at all ] un-pythonic?

>> Definitly and totally unpythonic. The first solution to your problem is to
>> stick to standard naming conventions. If this is not enough, Chris pointed
>> you to really useful tools. Also, you can override __setattr__ to catch such
>> errors - at least during the coding/debug phase.

> Good tools to know about, and a consistent naming pattern also makes life
> easier (which I have since done ;).

> Let's head towards murkier waters (at least murkier to me -- hopefully they
> can be easily clarified):  some of the attributes are read-only, such as
> record count; others are not directly exposed, but still settable, such as
> table version; and still others require a small amount of processing... at
> which point do I switch from simple attribute access to method access?

> Good tools to know about, and a consistent naming pattern also makes
> life easier (which I have since done ;).

> Let's head towards murkier waters (at least murkier to me -- hopefully
> they can be easily clarified):  some of the attributes are read-only,
> such as record count; others are not directly exposed, but still
> settable, such as table version; and still others require a small amount
> of processing... at which point do I switch from simple attribute access
> to method access?

> ~Ethan~

>>Bruno Desthuilliers wrote:

>>>Ethan Furman a écrit :

>>>>The problem I have with properties is my typing.  I'll end up assigning
>>>>to an attribute, but get the spelling slightly wrong (capitalized, or
>>>>missing an underscore -- non-obvious things when bug-hunting), so now I have
>>>>an extra attribute which of course has zero effect on what I'm trying to do
>>>>and I start getting wierd results like viewing deleted records when I *know*
>>>>I set useDeleted = False... 30 minutes later I notice it was /supposed/ to
>>>>be use_deleted.  *sigh*

>>>>So -- to keep myself out of trouble -- I have started coding such things
>>>>as, for example:

>>>>result = table.use_deleted()       # returns True or False
>>>>table.use_deleted(False)           # skip deleted records

>>>>instead of

>>>>result = table.use_deleted
>>>>table.use_deleted = False

>>>>My question:  is this [ severely | mildly | not at all ] un-pythonic?

>>>Definitly and totally unpythonic. The first solution to your problem is to
>>>stick to standard naming conventions. If this is not enough, Chris pointed
>>>you to really useful tools. Also, you can override __setattr__ to catch such
>>>errors - at least during the coding/debug phase.

>>Good tools to know about, and a consistent naming pattern also makes life
>>easier (which I have since done ;).

>>Let's head towards murkier waters (at least murkier to me -- hopefully they
>>can be easily clarified):  some of the attributes are read-only, such as
>>record count; others are not directly exposed, but still settable, such as
>>table version; and still others require a small amount of processing... at
>>which point do I switch from simple attribute access to method access?

> Thanks to the magic of properties, the end-user-programmer need not
> know which you're using:

> http://docs.python.org/library/functions.html#property

> Let's head towards murkier waters (at least murkier to me -- hopefully
> they can be easily clarified):  some of the attributes are read-only,
> such as record count; others are not directly exposed, but still
> settable, such as table version; and still others require a small amount
> of processing... at which point do I switch from simple attribute access
> to method access?

>> Let's head towards murkier waters (at least murkier to me -- hopefully
>> they can be easily clarified):  some of the attributes are read-only,
>> such as record count; others are not directly exposed, but still
>> settable, such as table version; and still others require a small
>> amount of processing... at which point do I switch from simple
>> attribute access to method access?

> Short answer : you don't !-)

> Long answer : well, in fact you do, but the client code doesn't have to
> be aware that it's in fact calling an accessor.

> Before we go into more details, you have to know that Python has a
> pretty good support for computed attributes, with both a simple generic
> solution (the property type) and the full monty (custom types
> implementing the descriptor protocol). So from the "interface" POV, you
> should never have an explicit accessor method for what is semantically
> an attribute (wheter the attribute is a plain or a computed one being
> part of the implementation).

> Let's start with your second point: "not directly exposed but still
> settable". I assume you mean "not part of the interface, only supposed
> to be accessed (rw) from the methods" - if not, please pardon my
> stupidity and provide better explanations !-).

> So if you have attributes you don't want to "expose" to the outside
> world, just add a single leading underscore to their names.

> First and third points are solved by using computed attributes - usually
> a property. The property type takes a few accessor functions as
> arguments - typically, a getter and a setter, and eventually a
> "deleter". Used as a class attribute, a property instance will hook up
> into the attribute lookup / setup mechanism (__getattribute__ and
> __setattr__), and will call resp. it's getter or setter function,
> passing it the instance and (for the setter) value.

> This directly solves the third point. For the first one, the obvious
> solution is to use a property with a setter that raises an exception -
> canonically, an AttributeError with a message explaining that the
> attribute is read-only.

> And for something more hands-on:

> class Person(object):
>    def __init__(self, firstname, lastname, birthdate):
>        self.firstname = firstname
>        self.lastname = lastnale
>        self.birthdate = birthdate
>        self._foo = 42 # implementation only

>    def _getfullname(self):
>        return "%s %s" % (self.firstname, self.lastname)
>    def _setfullname(self, value):
>        raise AttributeError("%s.fullname is read-only" % type(self)
>    fullname = property(fget=_getfullname, fset=_setfullname)

>    def _getage(self):
>        return some_computation_with(self.birthdate)
>    def _setage(self, value):
>        raise AttributeError("%s.age is read-only" % type(self)
>    age = property(fget=_getage, fset=_setage)

> For more on computed attributes, you may want to read about the
> "descriptor protocol" (google is your friend as usual). This and the
> attribute resolution mechanism are fundamental parts of Python's inner
> working. Learn how it works if you really want to leverage Python's power.

> HTH

> Very helpful, thank you.  Hopefully my brain will be up to the
> descriptor protocol this time... the last couple times were, um, less
> than successful.  :)