Noam Raphael <[EMAIL PROTECTED]> wrote: > > On 11/5/05, Josiah Carlson <[EMAIL PROTECTED]> wrote: > ... > > > 1. It doesn't add complexity, or a new builtin. > > > > It changes default behavior (which I specified as a portion of my > > statement, which you quote. > > > > And you are wrong, it adds complexity to the implementation of both > > class instantiation and the default comparison mechanism. The former, I > > believe, you will find more difficult to patch than the comparison, > > though if you have not yet had adventures in that which is writing C > > extension modules, modifying the default class instantiation may be > > the deal breaker for you (I personally would have no idea where to start). > > Sorry, I meant complexity to the Python user - it won't require him to > learn more in order to write programs in Python.
Ahh, but it does add complexity. Along with knowing __doc__, __slots__, __metaclass__, __init__, __new__, __cmp__, __eq__, ..., __str__, __repr__, __getitem__, __setitem__, __delitem__, __getattr__, __setattr__, __delattr__, ... The user must also know what __cmp_include__ and __cmp_exclude__ means in order to understand code which uses them, and they must understand that exclude entries overwrite include entries. > > Wow, 20 lines of support code, how could one ever expect users to write > > that? ;) > > This might mean that implementing it in C, once I find the right > place, won't be too difficult. > > And I think that for most users it will be harder than it was for you, > and there are some subtleties in those lines. So put it in the Python Cookbook: http://aspn.activestate.com/ASPN/Cookbook/Python > > > 3. It will make other objects behave better, not only mine - other > > > classes will get a meaningful comparison operator, for free. > > > > You are that the comparison previously wasn't "meaningful". It has a > > meaning, though it may not be exactly what you wanted it to be, which is > > why Python allows users to define __eq__ operators to be exactly what > > they want, and which is why I don't find your uses compelling. > > > I think that value-based equality testing is a better default, since > in more cases it does what you want it to, and since in those cases > they won't have to write those 20 lines, or download them from > somewhere. You are making a value judgement on what people want to happen with default Python. Until others state that they want such an operation as a default, I'm going to consider this particular argument relatively unfounded. > > From what I have previously learned from others in python-dev, the > > warnings machinery is slow, so one is to be wary of using warnings > > unless absolutely necessary. Regardless of it being absolutely necessary, > > it would be 2 years at least before the feature would actually make it > > into Python and become default behavior, IF it were desireable default > > behavior. > > 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. - Josiah _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com