__subclasses__() return order
Hello, In http://bugs.python.org/issue17936, I proposed making tp_subclasses (the internal container implementing object.__subclasses__) a dict. This would make the return order of __subclasses__ completely undefined, while it is right now slightly predictable. I have never seen __subclasses__ actually used in production code, so I'm wondering whether someone might be affected by such a change. Regards Antoine.
On Sat, May 25, 2013 at 6:18 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
Hello,
In http://bugs.python.org/issue17936, I proposed making tp_subclasses (the internal container implementing object.__subclasses__) a dict. This would make the return order of __subclasses__ completely undefined, while it is right now slightly predictable. I have never seen __subclasses__ actually used in production code, so I'm wondering whether someone might be affected by such a change.
Regards
Personally I never used it, but it's now explicitly documented as returning a list. Not sure what's the right thing to do here, but perhaps returning an OrderedDict can eliminate the order problem? Eli
On Sat, 25 May 2013 06:23:56 -0700 Eli Bendersky <eliben@gmail.com> wrote:
On Sat, May 25, 2013 at 6:18 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
Hello,
In http://bugs.python.org/issue17936, I proposed making tp_subclasses (the internal container implementing object.__subclasses__) a dict. This would make the return order of __subclasses__ completely undefined, while it is right now slightly predictable. I have never seen __subclasses__ actually used in production code, so I'm wondering whether someone might be affected by such a change.
Regards
Personally I never used it, but it's now explicitly documented as returning a list. Not sure what's the right thing to do here, but perhaps returning an OrderedDict can eliminate the order problem?
It would still return a list. Regards Antoine.
On Sat, 25 May 2013 15:26:58 +0200 Antoine Pitrou <solipsis@pitrou.net> wrote:
On Sat, 25 May 2013 06:23:56 -0700 Eli Bendersky <eliben@gmail.com> wrote:
On Sat, May 25, 2013 at 6:18 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
Hello,
In http://bugs.python.org/issue17936, I proposed making tp_subclasses (the internal container implementing object.__subclasses__) a dict. This would make the return order of __subclasses__ completely undefined, while it is right now slightly predictable. I have never seen __subclasses__ actually used in production code, so I'm wondering whether someone might be affected by such a change.
Regards
Personally I never used it, but it's now explicitly documented as returning a list. Not sure what's the right thing to do here, but perhaps returning an OrderedDict can eliminate the order problem?
It would still return a list.
I guess I should explain myself more clearly: __subclasses__() already computes its result on-the-fly (it must weed out dead weakrefs) (*). So the visible behaviour of __subclasses__ wouldn't change, except for ordering. (*)
object.__subclasses__() is object.__subclasses__() False
Regards Antoine.
On 25 maj 2013, at 15:45, Antoine Pitrou <solipsis@pitrou.net> wrote:
On Sat, 25 May 2013 15:26:58 +0200 Antoine Pitrou <solipsis@pitrou.net> wrote:
On Sat, 25 May 2013 06:23:56 -0700 Eli Bendersky <eliben@gmail.com> wrote:
On Sat, May 25, 2013 at 6:18 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
Hello,
In http://bugs.python.org/issue17936, I proposed making tp_subclasses (the internal container implementing object.__subclasses__) a dict. This would make the return order of __subclasses__ completely undefined, while it is right now slightly predictable. I have never seen __subclasses__ actually used in production code, so I'm wondering whether someone might be affected by such a change.
Regards
Personally I never used it, but it's now explicitly documented as returning a list. Not sure what's the right thing to do here, but perhaps returning an OrderedDict can eliminate the order problem?
It would still return a list.
I guess I should explain myself more clearly: __subclasses__() already computes its result on-the-fly (it must weed out dead weakrefs) (*). So the visible behaviour of __subclasses__ wouldn't change, except for ordering.
+1 Makes sense to me. As currently defined, you cannot rely on the item order anyway. -- Best regards, Łukasz Langa WWW: http://lukasz.langa.pl/ Twitter: @llanga IRC: ambv on #python-dev
On Sat, May 25, 2013 at 11:49 PM, Łukasz Langa <lukasz@langa.pl> wrote:
I guess I should explain myself more clearly: __subclasses__() already computes its result on-the-fly (it must weed out dead weakrefs) (*). So the visible behaviour of __subclasses__ wouldn't change, except for ordering.
+1
Makes sense to me. As currently defined, you cannot rely on the item order anyway.
Another concurrence here - if any code in the world depends on __subclasses__ always returning entries in the exact order they happen to be returned in right now, I'm quite happy to declare that code implementation dependent and thus exempt from the normal backwards compatibility guarantees :) Cheers, Nick.
On Sat, May 25, 2013 at 9:18 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
In http://bugs.python.org/issue17936, I proposed making tp_subclasses (the internal container implementing object.__subclasses__) a dict. This would make the return order of __subclasses__ completely undefined, while it is right now slightly predictable. I have never seen __subclasses__ actually used in production code, so I'm wondering whether someone might be affected by such a change.
FWIW, when I've used __subclasses__, I've never depended on it having a stable or predictable order. (I find it somewhat difficult to imagine *why* one would do that, but of course that doesn't mean nobody has done it.)
On 2013-05-25 09:18, Antoine Pitrou wrote:
Hello,
In http://bugs.python.org/issue17936, I proposed making tp_subclasses (the internal container implementing object.__subclasses__) a dict. This would make the return order of __subclasses__ completely undefined, while it is right now slightly predictable. I have never seen __subclasses__ actually used in production code, so I'm wondering whether someone might be affected by such a change.
I do use a package that does use __subclasses__ in production code, but the order is unimportant. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
I've used __subclasses__ as an easy way to register components by sub-classing a base component. I didn't rely on the ordering. I guess the current order depends on the order in which modules are imported and so is pretty fragile anyway?
participants (7)
-
Antoine Pitrou -
Eli Bendersky -
Nick Coghlan -
PJ Eby -
Robert Kern -
Simon Cross -
Łukasz Langa