Alex Hunsley wrote:
> bruno at modulix wrote:
>
>> Alex Hunsley wrote:
>>
(snip)
>>>
>>> method 1:
>>>
>>> _X - (single underscore) - just cosmetic, a convention to let someone
>>> know that this data should be private.
>>>
>>>
>>> method 2:
>>>
>>> __X - (double underscore) - mangles the name (in a predictable way).
>>> Avoids name pollution.
>>>
>>>
>>> How often does either tend to get used? Personally, I'd be a little
>>> worried about using method 1, because namespace clashes could happen. Is
>>> this overly paranoid?
>>
>> Probably.
>>
>> Note that prefixing names with a single underscore have a 'protected'
>> semantic - which means that such names (well, the objects that are bound
>> to...) can be overriden/extends by child classes.
>
>
> Ah, my mistake, not merely cosmetic then! Thanks.
Well, to be more exact, the point is not that _names can be overriden,
but that, due to name mangling, the following won't work, or, at least,
not as expected:
class Base(object):
def __dothis(self):
print "Base dothis"
def dothat(self):
print "Base dothat"
def run(self):
self.__dothis()
self.dothat()
class Child(Base):
def __dothis(self):
print "__%s_dothis" % self.__class__.__name__
def dothat(self):
print "%s dothat" % self.__class__.__name__
c = Child()
c.run()
(snip)
> Sorry, I wasn't being clear. What I should have said is that I don't
> like the idea of a typo in an assignment causing the assigning of the
> wrong thing.
> e.g. imagine a simple value-holding class:
>
> class Values:
> pass
>
> v = Values()
>
> v.conductoin = 10
>
>
> ... I meant to type 'conduction' in the source but spelt it wrong.
> My value won't be there when elsewhere I refer to the correct attribute:
> "conduction".
>
This kind of mistakes are usually not too hard to spot and not too hard
to correct. You'd have the same problem with a dict (and your Values
class is not much more than a dotted_syntax dict in disguise). BTW,
Pylint or Pychecker would catch this, and most unittests too.
Now if you have a case where this could really matter (like a user's
script), you can then define a more bondage_and_the_whip class with slots.
My overall experience with programming and Python is that keeping it
stupid simple where you can is usually the best approach. Your
__setattr__as_a_typo_catcher solution looks to me like a case of
arbitrary complexification. Better to go with the language than to fight
against it.
My 2 cents...
--
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
