[WIP] ENH magic implementation of estimator freezing #8372
Conversation
|
Yes, it's the kind of stuff that I had in mind when I said that generating classes was possible but I didn't like it. I don't like it because I think that it surprises people and my experience is that it leads to bugs and misunderstanding of the library. That said, it's a nice realization of the idea, @jnothman. You're definitely a Python wizard with great powers in magic. |
|
Sigh. That's why I ask for the ability to overload clone, so that I can play with fire at home :) |
|
But if we give up on inheritance, we can use a little less magic, no?
|
|
Yes, except: that we've never told users not to use inheritance; that we've
used it ourselves; that it's something pretty tricky to warn for (because
__instancecheck__ is bypassed if a type match suffices); and that the
recent establishment of __instancecheck__ and collection interface types
seems to encourage it over ducktyping!
…On 17 February 2017 at 01:00, Gael Varoquaux ***@***.***> wrote:
But if we give up on inheritance, we can use a little less magic, no?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#8372 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAEz61ovFDgXb23hWrUG75jsIKVfEPvQks5rdFaXgaJpZM4MDBAr>
.
|
Also, giving up on inheritance still requires In this case, at least, I think I have a simpler solution I can try. |
Fixes #8370
@GaelVaroquaux is likely to reject this outright, due to the free use of magic. However, it likely works more smoothly than any other conceivable implementation.
And we have at least agreed that freezing (in some manner) should be possible.