mystilleef wrote:
> Marc 'BlackJack' Rintsch wrote:
>
>>In <[EMAIL PROTECTED]>, mystilleef
>>wrote:
>>
>>
>>>Maric Michaud wrote:
(snip)
>>>>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. How
>>>does that solve my naming issues.
>>
>>Then you have to change all references to that private attribute. What's
>>the problem here? As it was private I would expect to find all the
>>references "nearby" in the same module or class.
>
> Right, but tmp isn't private.
Right, but that's your choice. Would you complain about "almost any
other language" if you had to hunt a badly named public method thru 27KLOC ?
(snip)
>>Python is not almost all other languages and in Python code you usually
>>won't find those trivial getters and setters because we have properties if
>>the access might become a bit more complex in the future.
>>
> Ha! I bet you haven't read too many Python codes.
>
I have read tens of thousands LOC of Python in the seven past years.
Computed attributes came in with 2.2x IIRC, so there's a lot of 'legacy'
code that uses getters and setters. Porting this code to a
computed-attribute style would break all client code. Having the two
schemes coexisting would make for bloated APIs and
too-many-ways-to-do-it. So we live with this until Py3K. And none of
these considerations contradicts the point that there's no more use for
javaish getters/setters in Python, nor that javaish getters/setters are
not pythonic.
--
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
