[docs] Code, test, and doc review for PEP-0435 Enum (issue 17947)

eliben at gmail.com eliben at gmail.com
Sun May 12 15:21:31 CEST 2013


http://bugs.python.org/review/17947/diff/8113/Lib/enum.py
File Lib/enum.py (right):

http://bugs.python.org/review/17947/diff/8113/Lib/enum.py#newcode214
Lib/enum.py:214: return cls._enum_map.copy()
On 2013/05/12 14:47:01, stoneleaf wrote:
> On 2013/05/11 05:23:57, eli.bendersky wrote:
> > I still don't like this copy(). Can you say what it is for? If
someone wants
> to
> > screw an Enum up he can access _enum_map directly - Python doesn't
excel at
> data
> > hiding. OTOH, copy needlessly makes innocent code (99.99% of the
code) slower.
> 
> Doc string added.  I don't think speed is an issue.  I do think that
innocent
> user code shouldn't have to worry that removing an item, or combining
with
> another dict, will corrupt the enumeration.
> 
> If they access the private structure it's on them; if they access the
public
> interface we shouldn't be handing them a time-bomb.

I see what you're saying and it makes sense in C++, but not in Python.
In Python it's so easy to screw everything up, such protections are not
usually done. You can start but you will never stop, because there're so
many. You can replace any method on an existing Python object, and
that's a "public interface".

>>> class Foo:
...   def bar(self): return 2
... 
>>> f = Foo()
>>> f.bar()
2
>>> f.bar = 10
>>> f.bar
10

I think that a documentation note that says the returned dict should not
be mucked with is good enough for __members__. If someone does care
about performance, the usual assumption is that copies are not being
made behind the back.

http://bugs.python.org/review/17947/


More information about the docs mailing list