[Python-Dev] Should the default equality operator compare values instead of identities?
jcarlson at uci.edu
Sun Nov 6 01:30:52 CET 2005
Noam Raphael <noamraph at gmail.com> wrote:
> On 11/6/05, Josiah Carlson <jcarlson at uci.edu> wrote:
> > >
> > > Sorry, I meant complexity to the Python user - it won't require him to
> > > learn more in order to write programs in Python.
> You are right. But that's Python - I think that nobody knows all the
> exact details of what all these do. You look in the documentation. It
> is a compliation - but it's of the type that I can live with, if
> there's a reason.
Regardless of whether people check the documentation, it does add
complexity to Python.
> > > All right. I hope that those warnings will be ok - it's yet to be
> > > seen. And about those 2 years - better later than never.
> > It won't be OK. Every comparison using the default operator will incur
> > a speed penalty while it checks the (pure Python) warning machinery to
> > determine if the warning has been issued yet. This alone makes the
> > transition require a __future__ import.
> How will the __future__ statement help? I think that the warning is
> still needed, so that people using code that may stop working will
> know about it. I see that they can add a __future__ import and see if
> it still works, but it will catch much fewer problems, because usually
> code would be run without the __future__ import.
What has been common is to use __future__ along with a note in the
release notes specifying the changes between 2.x and 2.x-1. The precise
mechanisms when using __future__ vary from import to import, though this
one could signal the change of a single variable as to which code path
> If it really slows down things, it seems to me that the only solution
> is to optimize the warning module...
Possible solutions to possible problem of default __eq__ behavior:
1. It is not a problem, leave it alone.
2. Use __future__.
3. Use warnings, and deal with it being slow.
4. Make warnings a C module and expose it to CPython internals.
You are claiming that there is such a need to fix __eq__ that one would
NEEDs to change the warnings module so that the __eq__ fix can be fast.
Again, implement this, post it to sourceforge, and someone will decide.
More information about the Python-Dev