mystilleef wrote:
> Bruno Desthuilliers wrote:
>
>>mystilleef wrote:
>>(snip)
>>
>>>Python doesn't have any philosophy with regards to naming identifiers.
>>
>>Yes it does.
>
>
> No it doesn't.
>
>
>>>>But they are in Python and that is the python's philosophy. All attribute or
>>>>method not beginning with an '_' *is* API.
>>>
>>>Right, and what if I want to change a private API to a public one.
>>
>>Then you provide a public API on top of the private one.
>>
>>class MyClass(object):
>> def __init__(self, ...):
>> self._attr = XXX
>>
>> # seems like we really have enough use
>> # cases to justify exposing _imp_attr
>> @apply
>> def attr():
>> def fget(self):
>> return self._attr
>> def fset(self):
>> self._attr = attr
>> return property(**locals())
>>
>>
>> def _method(self, ...):
>> # code here
>>
>> # seems like we really have enough use
>> # cases to justify exposing _imp_method
>> method = _impmethod
>>
>>Note that none of this actually breaks encapsulation.
>
>
> Ha! Just as bad as getters and setter.
What point are you trying to make here ? Of course a computed attribute
is just syntactic sugar for getters and setters - what else could it be?
The difference is that you don't need to write explicit getters/setters
beforehand, nor to use a "behaviour" semantic.
>
>>>How
>>>does that solve my naming issues.
>>
>>How could this solve *your* naming issue ? This is totally unrelated.
>>You choose a bad name for a *public* symbol.
>
>
> My point exactly! It doesn't solve my problem!
What do you hope ? Something that cures cancer ? Please enlighten us and
explain how explicit getters/setters would have solved the problem of
badly named getters/setters ?
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in '[EMAIL PROTECTED]'.split('@')])"
--
http://mail.python.org/mailman/listinfo/python-list
