On 11/6/05, Josiah Carlson <[EMAIL PROTECTED]> wrote: ... > > > > 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. > 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. > > > > 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 > A good idea. > > > > > 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. > All right. I will try to collect more examples for my proposal. > > > > 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. > 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.
If it really slows down things, it seems to me that the only solution is to optimize the warning module... Noam _______________________________________________ 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
