数据隐藏/命名空间污染 [英] data hiding/namespace pollution

问题描述

这篇文章中没有具体的问题，但是我正在寻找

人们对这些问题的看法...

我在python中遇到的数据伪隐藏的两个主要版本是

（封装）：


方法1：


_X - （单下划线） - 只是化妆品，让某人

知道这些数据应该是私密的约定。

方法2：


__X - （双下划线） - 破坏名称（以可预测的方式）。

避免名称污染。

多久一次要么倾向于习惯？就个人而言，我有点担心使用方法1，因为命名空间冲突可能会发生。

这个过于偏执吗？


另外，我认为不是人们写自己的手动吸气剂

和setter方法，他们倾向于使用__getattr__

和__setattr__上的重载，或者属性类（它本身使用上述

方法）。重载__getattr__等似乎对我更有吸引力，因为我可以捕获对未知名称的访问权限，并引发异常！

（我真的不喜欢随机属性名称拼写错误的想法

在访问类中的属性时不被注意！）


注意：我确实知道上面这些东西的使用是相当的依赖于

究竟是什么编码，项目大小等等，但是我想要了解的是
是python社区' '公认的好

做法。


谢谢，

alex

解决方案

Alex Hunsley写道：

这篇文章中没有具体的问题，但我正在寻找
人们的考虑内部问题...

我遇到的数据伪隐藏的两个主要版本
（封装）


< ; OT>

嗯......数据隐藏和封装真的是一样吗？

< / OT>

中的python是：

方法1 ：

_X - （单下划线） - 只是化妆品，让某人知道这些数据应该是私密的约定。

方法2：

__X - （双下划线） - 破坏名称（以可预测的方式）。
避免名称污染。

多久使用一次？就个人而言，我有点担心使用方法1，因为命名空间可能会发生冲突。这是过分偏执吗？


可能。


请注意，带有单个下划线的名称前缀有一个''protected''

语义 - 这意味着这样的名字（好吧，被绑定的对象是...... b $ b到......）可以被子类重写/扩展。


我个人只使用双下划线表示法仅用于* * b $ b * * * * * * * * * * * * * * * * * * * * * * * * * * *另外，我认为，不是人们编写自己的手动getter和setter方法，他们倾向于使用__getattr__
和__setattr__上的重载，或者属性类（它本身使用前面提到的方法）。


是的......这是pythonic方式。

重载__getattr__等似乎对我更有吸引力，因为
然后我可以捕获访问权限对于未知名称，并提出异常！
（我真的不喜欢随机属性名称拼写错误的想法在访问类中的属性时不被注意！）


Err ...你真的*试图访问一个不合格的属性吗？这个

通常不会被忽视（除非你考虑将

的AttributeError提升为与''未被注意''相同！） - br / >

我个人使用''魔术''访问器只用于委托或类似，并且

属性（或自定义描述符）用于其他任何东西（需要

它...）。这避免了__getattr__中的Big-Switch-Syndrom和setattr__，

并且更加明确（API，文档，内省等......）。

注意：我做的我知道上面这些东西的使用完全取决于你编码的确切程度，项目的大小等等，但是我试图找出的是蟒蛇社区'公认的好的
做法。

然后启动你的python交互式shell并输入import this


HTH

-

bruno desthuilliers

python -c" print''@''。join（[''。'' '.join（[w [:: - 1] for p in p.split（''。''）]）for

p in''o****@xiludom.gro'' .split（''@''）]）>

bruno at modulix写道：

Alex Hunsley写道：
< blockquote class =post_quotes>这篇文章中没有真正具体的问题，但我很好看用于
人们对...内部问题的思考...

我遇到的数据伪隐藏的两个主要版本
（封装）

< OT>
嗯...数据隐藏和封装是否真的相同？
< / OT>

不，他们不是，我只是在那里粗心大意，请忽略任何

明显的含义。

在python中是：

方法1：

_X - （单下划线） - 只是化妆品，让某人知道这一点的惯例数据应该是私有的。

方法2：

__ X - （双下划线） - 破坏名称（以可预测的方式）。
避免名称污染。

多久往往会被使用？就个人而言，我有点担心使用方法1，因为命名空间可能会发生冲突。这是过于偏执吗？

可能。

请注意，使用单个下划线为名称添加前缀会有受保护。
语义 - 这意味着这些名称（以及绑定到......的对象）可以被子类覆盖/扩展。

Ah ，我的错误，不仅仅是化妆品！谢谢。

我个人只使用双下划线符号来表示* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *


ok。

另外，我认为不是人们写自己的手动吸气剂和setter方法，它们倾向于使用__getattr__
和__setattr__上的重载，或者属性类（它本身使用上述
方法）。

是的。 ..这是pythonic方式。

重载__getattr__等似乎对我更有吸引力，因为
然后我可以捕获对未知名称的访问权限，并提高一个例外！
（我真的不喜欢随机属性名称拼写错误的想法在访问类中的属性时没有注意到！）

Err。 ..你真的*试图访问一个不存在的属性吗？这通常不会被忽视（除非你考虑将一个
AttributeError提升为与''未被注意''相同！ - ）

对不起，我不清楚。我应该说的是，我不会像在作业中输入拼写错误的想法那样导致分配

错误的东西。

例如想象一个简单的价值持有类：


class值：

通过


v =值（）


v.conductoin = 10

....我打算在源代码中输入''传导'但拼写错误。

当我在其他地方提到正确的属性时，我的价值不会存在：

传导。

我个人只使用''魔术''访问者对于委托或类似，以及
属性（或自定义描述符）的任何其他东西（需要
它...）。这样可以避免__getattr__和setattr__中的Big-Switch-Syndrom，而且更加明确（API，文档，内省等......）。

好吧，好点。

注意：我确实知道上述事情的使用完全取决于你究竟是什么？重新编码，项目规模等等，但我想要了解的是python社区公认的良好实践。

然后启动你的python交互式shell并输入import this

谢谢你，我不知道这个！

alex

Alex Hunsley< la ** @ tardis.ed.ac.molar.uk>写道：

抱歉，我不清楚。我应该说的是，我不喜欢在作业中输入错字导致分配错误内容的想法。
想象一个简单的价值持有类：

类值：
传递

v =值（）

v.conductoin = 10

...我打算在源代码中键入''传导'但拼写错误。
我在其他地方的价值不会出现在那里我指的是正确的属性：
传导。

最近有一个大线程再次被提出（是的，你不是

第一个，第二个，第三个......）。您应该编写单元测试，使用

工具，如pychecker，pylint等。


-

Jorge Godoy< go * **@ieee.org>

There''s no really specific questions in this post, but I''m looking for
people''s thought on the issues within...
The two main versions I''ve encountered for data pseudo-hiding
(encapsulation) in python are:

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?

Also, I presume that rather than people writing their own manual getter
and setter methods, they tend to use either overloading on __getattr__
and __setattr__, or the Property class (which itself uses aforementioned
methods). Overloading __getattr__ etc. seems more attractive to me, as
then I can capture access to unknown names, and raise an exception!
(I really don''t like the idea of random attribute name typos going
unnoticed when accessing attributes in a class!)

Note: I do know that the use of the above things is quite dependent on
what exactly you''re coding, the size of the project etc., but what I''m
trying to find out about is the python communities'' recognised good
practices.

thanks,
alex

解决方案

Alex Hunsley wrote:

There''s no really specific questions in this post, but I''m looking for
people''s thought on the issues within...
The two main versions I''ve encountered for data pseudo-hiding
(encapsulation)
<OT>
Hmmm... Are data-hiding and encapsulation really the same things ?
</OT>
in python are:

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.

I personnally only use the double-underscore notation only for things
that are *really* implementation-specific *and* should *really not* be
overriden.

Also, I presume that rather than people writing their own manual getter
and setter methods, they tend to use either overloading on __getattr__
and __setattr__, or the Property class (which itself uses aforementioned
methods).
Yeps... This is the pythonic way.
Overloading __getattr__ etc. seems more attractive to me, as
then I can capture access to unknown names, and raise an exception!
(I really don''t like the idea of random attribute name typos going
unnoticed when accessing attributes in a class!)
Err... Have you *really* tried to access an inexistant attribute ? This
is usually not ''unnoticed'' (unless you consider the raising of an
AttributeError as being the same as ''unnoticed'' !-)

I personnaly use ''magic'' accessors only for delegation or like, and
properties (or custom descriptors) for anything else (that requires
it...). This avoid the Big-Switch-Syndrom in __getattr__ and setattr__,
and is much more explicit (API, documentation, introspection etc...).
Note: I do know that the use of the above things is quite dependent on
what exactly you''re coding, the size of the project etc., but what I''m
trying to find out about is the python communities'' recognised good
practices.

Then launch your python interactive shell and type "import this"

HTH
--
bruno desthuilliers
python -c "print ''@''.join([''.''.join([w[::-1] for w in p.split(''.'')]) for
p in ''o****@xiludom.gro''.split(''@'')])"

bruno at modulix wrote:

Alex Hunsley wrote:

There''s no really specific questions in this post, but I''m looking for
people''s thought on the issues within...
The two main versions I''ve encountered for data pseudo-hiding
(encapsulation)

<OT>
Hmmm... Are data-hiding and encapsulation really the same things ?
</OT>

No, they''re not, I was just being careless there, please disregard any
apparent implication that they are.

in python are:

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.

I personnally only use the double-underscore notation only for things
that are *really* implementation-specific *and* should *really not* be
overriden.
ok.

Also, I presume that rather than people writing their own manual getter
and setter methods, they tend to use either overloading on __getattr__
and __setattr__, or the Property class (which itself uses aforementioned
methods).

Yeps... This is the pythonic way.

Overloading __getattr__ etc. seems more attractive to me, as
then I can capture access to unknown names, and raise an exception!
(I really don''t like the idea of random attribute name typos going
unnoticed when accessing attributes in a class!)

Err... Have you *really* tried to access an inexistant attribute ? This
is usually not ''unnoticed'' (unless you consider the raising of an
AttributeError as being the same as ''unnoticed'' !-)

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".
I personnaly use ''magic'' accessors only for delegation or like, and
properties (or custom descriptors) for anything else (that requires
it...). This avoid the Big-Switch-Syndrom in __getattr__ and setattr__,
and is much more explicit (API, documentation, introspection etc...).

Right, good point.

Note: I do know that the use of the above things is quite dependent on
what exactly you''re coding, the size of the project etc., but what I''m
trying to find out about is the python communities'' recognised good
practices.

Then launch your python interactive shell and type "import this"

Thanks for that, I didn''t know about that!
alex

Alex Hunsley <la**@tardis.ed.ac.molar.uk> writes:

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".

Recently there was a big thread where that was raised again (yep, you''re not
the first, nor the second, nor the third...). You should write unittests, use
tools like pychecker, pylint, etc.

--
Jorge Godoy <go***@ieee.org>

这篇关于数据隐藏/命名空间污染的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！