[issue25315] Make it clear in the collections Python source code that OrderedDict may be overridden

[Raymond Hettinger]

Changes by Raymond Hettinger :


--
resolution:  -> not a bug
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25315] Make it clear in the collections Python source code that OrderedDict may be overridden

[Raymond Hettinger]

Raymond Hettinger added the comment:

FWIW, the decision to use __ to make the implementation more private was done 
at Guido's recommendation.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25315] Make it clear in the collections Python source code that OrderedDict may be overridden

[Raymond Hettinger]

Raymond Hettinger added the comment:

In general, the __attributes and _attributes are already considered to be 
private, so I don't see the point.  Aside from this one user that is never been 
necessary and he already knows that it doesn't work. 

Re-reading the thread, the issue isn't that he doesn't like the design choice, 
not that he didn't understand it.

The collections module isn't the only place the implementation has been made 
private (see fractions.py) for example.   Maybe a general note in the docs 
about private APIs or a FAQ entry would be appropriate, but there isn't 
anything specific to OrderedDicts (especially now that there is a C 
implementation, it should go without saying).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25315] Make it clear in the collections Python source code that OrderedDict may be overridden

[Raymond Hettinger]

Raymond Hettinger added the comment:

One other thought:  The purpose of the source links is to help people learn.  
It in no way every implies that someone should hack private implementation 
details.   We have a number of modules that have both a pure python 
implementation and a replacement with a C accelerator (heapq, counter, bisect, 
decimal, etc) they are all done in the same way as the OrderedDict.

I believe this report should be re-closed as the OP has consistently adopted 
unreasonable positions as has been unwilling to accept the responses from the 
devs volunteering their time to explain the basics of private, non-guaranteed 
implementation details.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25315] Make it clear in the collections Python source code that OrderedDict may be overridden

[R. David Murray]

R. David Murray added the comment:

What I'm suggesting it would be worth adding to the source code is a simple 
comment before the class definition for OrderedDict that says "This Python code 
may be overridden by an accelerated version of this class."  The idea being to 
prevent confusion if someone is exploring the source code for learning purposes 
but discovers it doesn't match what python actually does.

If you read all the way through the class and realize that the import after it 
does the override, you don't need the comment...but a learner exploring the 
source code is exactly the kind of person who might miss that, either by doing 
experiments before reading through the whole class or missing the implication 
of the import.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25315] Make it clear in the collections Python source code that OrderedDict may be overridden

[Raymond Hettinger]

Raymond Hettinger added the comment:

> What I'm suggesting it would be worth adding to the source code is
> a simple comment before the class definition for OrderedDict that
> says  "This Python code may be overridden by an accelerated 
> version of this class." 

Sorry, I disagree.  We've never had to do that for any of the C accelerator 
code in Python's history.  Also, we already have a comment at the point the 
import is done (and that didn't seem to matter to the OP who is just mad about 
the design choice itself).  The comment is in the same place as it is in 
heapq.py for example.  If you want to add a general FAQ entry, that would be 
fine.  Also, keep in mind that that the code is tested in our test suite, and 
it is active in other versions of Python (it is not useless as the OP suggests).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com