Re: [Python-Dev] Class decorators vs metaclasses
On 11/5/05, Alex Martelli <[EMAIL PROTECTED]> wrote:
> On 11/4/05, Eyal Lotem <[EMAIL PROTECTED]> wrote:
> > I have a few claims, some unrelated, and some built on top of each
> > other. I would like to hear your responses as to which are
> > convincing, which arne't, and why. I think that if these claims are
> > true, Python 3000 should change quite a bit.
> >
> > A. Metaclass code is black magic and few understand how it works,
> > while decorator code is mostly understandable, even by non-gurus.
>
> I disagree. I've held many presentations and classes on both
> subjects, and while people may INITIALLY feel like metaclasses are
> black magic, as soon as I've explained it the fear dissipates. It all
> boils down do understanding that:
>
> class Name(Ba,Ses): <>
>
> means
>
> Name = suitable_metaclass('Name', (Ba,Ses), <>)
>
> which isn't any harder than understanding that
>
> @foo(bar)
> def baz(args): ...
>
> means
>
> def baz(args): ...
> baz = foo(bar)(baz)
I disagree again. My experience is that metaclass code is very hard to
understand. Especially when it starts doing non-trivial things, such
as using a base metaclass class that is parametrized by metaclass
attributes in its subclasses. Lookups of attributes in the base
metaclass methods is mind boggling (is it searching them in the base
metaclass, the subclass, the instance [which is the class]?). The
same code would be much easier to understand with class decorators.
> > B. One of Decorators' most powerful features is that they can
> > mixed-and-matched, which makes them very powerful for many purposes,
> > while metaclasses are exclusive, and only one can be used. This is
>
> Wrong. You can mix as many metaclasses as you wish, as long as
> they're properly coded for multiple inheritance (using super, etc) --
> just inherit from them all. This is reasonably easy to automate (see
> the last recipe in the 2nd ed of the Python Cookbook), too.
Multiple inheritence is an awful way to mix class fucntionalities
though. Lets take a simpler example. Most UT frameworks use a
TestCase base class they inherit from to implement setup, tearDown,
and then inherit from it again to implement the test itself. I argue
this is a weak approach, because then mixing/matching setups is
difficult. You would argue this is not the case, because of the
ability to multiply-inherit from test cases, but how easy is the
equivalent of:
@with_setup('blah')
@with_other_setup('bleh')
def my_test():
# the blah setup and bleh other setup are up and usable here,
# and will be "torn down" at the end of this test
The equivalent of this requires a lot more work and violating DRY.
Creating a specific function to multiply inherit from TestCases is a
possible solution, but it is much more conceptually complex, and needs
to be reimplemented in the next scenario (Metaclasses for example).
> > especially problematic as some classes may assume their subclasses
> > must use their respective metaclasses. This means classdecorators are
> > strictly more powerful than metaclasses, without cumbersome
> > convertions between metaclass mechanisms and decorator mechanisms.
>
> The assertion that classdecorators are strictly more powerful than
> custom metaclasses is simply false. How would you design
> classdecorator XXX so that
>
> @XXX
> class Foo: ...
>
> allows 'print Foo' to emit 'this is beautiful class Foo', for example?
> the str(Foo) implicit in print calls type(Foo).__str__(Foo), so you
> do need a custom type(Foo) -- which is all that is meant by "a custom
> metaclass"... a custom type whose instances are classes, that's all.
I would argue that this is not such a useful feature, as in that case
you can simply use a factory object instead of a class. If this
feature remains, that's fine, but the fact it allows for a weak form
of "decoration" of classes should not kill the concept of class
decorators.
The only reason of using metaclasses rather than factory objects, in
my experience, was that references to class objects are considered
different than references to factories (by pickle and deepcopy, and
maybe others) and that can be a useful feature. This feature can be
implemented in more readable means though.
> > C. Interesting uses of classdecorators are allowing super-calling
> > without redundantly specifying the name of your class, or your
> > superclass.
>
> Can you give an example?
@anotherclassdecorator
@supercallerclass
class MyClass(object):
@supercaller
def my_method(self, supcaller, x, y, z):
...
result = supcaller.my_method(x, y, z)
...
Could be nice to remove the need for decorating the class, and only
decorating the methods, but the method decorators get a function
object, not a method object, so its more difficult (perhaps portably
impossible?) to do this.
Note that "__metaclass__ = superclasscaller" could also work, but then
combining "anotherclassdecorator" would require a lot more code at
worst, or a complex m
Re: [Python-Dev] PEP 352 Transition Plan
[Guido van Rossum] > I've made a final pass over PEP 352, mostly fixing the __str__, > __unicode__ and __repr__ methods to behave more reasonably. I'm all > for accepting it now. Does anybody see any last-minute show-stopping > problems with it? I did not follow the thread, so maybe I'm out in order, be kind with me. After having read PEP 352, it is not crystal clear whether in: try: ... except: ... the "except:" will mean "except BaseException:" or "except Exception:". I would except the first, but the text beginning the section titled "Exception Hierarchy Changes" suggests it could mean the second, without really stating it. Let me argue that "except BaseException:" is preferable. First, because there is no reason to load a bare "except:" by anything but a very simple and clean meaning, like the real base of the exception hierarchy. Second, as a bare "except:" is not considered good practice on average, it would be counter-productive trying to figure out ways to make it more frequently _usable_. -- François Pinard http://pinard.progiciels-bpi.ca ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 352 Transition Plan
> [Guido van Rossum] > > > I've made a final pass over PEP 352, mostly fixing the __str__, > > __unicode__ and __repr__ methods to behave more reasonably. I'm all > > for accepting it now. Does anybody see any last-minute show-stopping > > problems with it? [François] > I did not follow the thread, so maybe I'm out in order, be kind with me. > > After having read PEP 352, it is not crystal clear whether in: > > try: > ... > except: > ... > > the "except:" will mean "except BaseException:" or "except Exception:". > I would except the first, but the text beginning the section titled > "Exception Hierarchy Changes" suggests it could mean the second, without > really stating it. This is probably a leftover from PEP 348, which did have a change for bare 'except:' in mind. PEP 352 doesn't propose to change its meaning, and if there are words that suggest this, they should be removed. Until Python 3.0, it will not change its meaning from what it is now; this is because until then, it is still *possible* (though it will become deprecated behavior) to raise string exceptions or classes that don't inherit from BaseException. > Let me argue that "except BaseException:" is preferable. First, because > there is no reason to load a bare "except:" by anything but a very > simple and clean meaning, like the real base of the exception hierarchy. > Second, as a bare "except:" is not considered good practice on average, > it would be counter-productive trying to figure out ways to make it more > frequently _usable_. What bare 'except:' will mean in Python 3.0, and whether it is even allowed at all, is up for discussion -- it will have to be a new PEP. Personally, I think bare 'except:' should be removed from the language in Python 3.0, so that all except clauses are explicit in what they catch and there isn't any confusion over whether KeyboardInterrupt, SystemExit etc. are included or not. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Should the default equality operator compare values instead of identities?
On 11/3/05, Josiah Carlson <[EMAIL PROTECTED]> wrote: ... > > Right, but lists (dicts, tuples, etc.) are defined as containers, and > their comparison operation is defined on their contents. Objects are > not defined as containers in the general case, so defining comparisons > based on their contents (as opposed to identity) is just one of the two > assumptions to be made. > > I personally like the current behavior, and I see no /compelling/ reason > to change it. You obviously feel so compelled for the behavior to > change that you are willing to express your desires. How about you do > something more productive and produce a patch which implements the > changes you want, verify that it passes tests in the standard library, > then post it on sourceforge. If someone is similarly compelled and > agrees with you (so far I've not seen any public support for your > proposal by any of the core developers), the discussion will restart, > and it will be decided (not by you or I). Thanks for the advice - I will try to do as you suggest. > > > > To summarize, I think that value-based equality testing would usually > > be what you want, and currently implementing it is a bit of a pain. > > Actually, implementing value-based equality testing, when you have a > finite set of values you want to test, is quite easy. > > def __eq__(self, other): > for i in self.__cmp_eq__: > if getattr(self, i) != getattr(other, i): > return False > return True > > With a simple metaclass that discovers all of those values automatically, > and/or your own protocol for exclusion, and you are done. Remember, not > all 5-line functions should become builtin/default behavior, and this > implementation shows that it is not a significant burdon for you (or > anyone else) to implement this in your own custom library. > You are right that not all 5-line functions should become builtin/default behaviour. However, I personally think that this one should, since: 1. It doesn't add complexity, or a new builtin. 2. Those five line doesn't include the metaclass code, which will probably take more than five lines and won't be trivial. 3. It will make other objects behave better, not only mine - other classes will get a meaningful comparison operator, for free. > > P.S. One thing that you should remember is that even if your patch is > accepted, and even if this is desireable, Python 2.5 is supposed to be > released sometime next year (spring/summer?), and because it is a > backwards incompatible change, would need at least 2.6-2.7 before it > becomes the default behavior without a __future__ import, which is > another 3-4 years down the line. I hope that the warning can go in by Python 2.5, so the change (which I think will cause relatively few backwards incompatibility problems) can go in by Python 2.6, which I think is less than 2 years down the line. > > I understand you are passionate, really I do (you should see some of my > proposals), but by the time these things get around to getting into > mainline Python, there are high odds that you probably won't care about > them much anymore (I've come to feel that way myself about many of my > proposals), and I think it is a good idea to attempt to balance - when > it comes to Python - "Now is better than never." and "Although never is > often better than *right* now." > > Removing __hash__, changing __eq__, and trying to get in copy-on-write > freezing (which is really copy-and-cache freezing), all read to me like > "We gotta do this now!", which certainly isn't helping the proposal. > Thanks - I should really calm down a bit. I will try to go "safe and slowly", and I hope that at the end I will succeed in making my own small contribution to Python. Noam ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Should the default equality operator compare values instead of identities?
Noam Raphael <[EMAIL PROTECTED]> wrote:
> On 11/3/05, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> > > To summarize, I think that value-based equality testing would usually
> > > be what you want, and currently implementing it is a bit of a pain.
> >
> > Actually, implementing value-based equality testing, when you have a
> > finite set of values you want to test, is quite easy.
> >
> > def __eq__(self, other):
> > for i in self.__cmp_eq__:
> > if getattr(self, i) != getattr(other, i):
> > return False
> > return True
> >
> > With a simple metaclass that discovers all of those values automatically,
> > and/or your own protocol for exclusion, and you are done. Remember, not
> > all 5-line functions should become builtin/default behavior, and this
> > implementation shows that it is not a significant burdon for you (or
> > anyone else) to implement this in your own custom library.
> >
> You are right that not all 5-line functions should become
> builtin/default behaviour. However, I personally think that this one
> should, since:
> 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).
> 2. Those five line doesn't include the metaclass code, which will
> probably take more than five lines and won't be trivial.
class eqMetaclass(type):
def __new__(cls, name, bases, dct):
if '__cmp_include__' in dct:
include = dict.fromkeys(dct['__cmp_include__'])
else:
include = dict.fromkeys(dct.keys)
for i in dct.get('__cmp_exclude__'):
_ = include.pop(i, None)
dct['__cmp_eq__'] = include.keys()
return type.__new__(cls, name, bases, dct)
It took 10 lines of code, and was trivial (except for not-included
multi-metaclass support code, which is being discussed in another thread).
Oh, I suppose I should modify that __eq__ definition to be smarter about
comparison...
def __eq__(self, other):
if not hasattr(other, '__cmp_eq__'):
return False
if dict.fromkeys(self.__cmp_eq__) != \
dict.fromkeys(other.__cmp_eq__):
return False
for i in self.__cmp_eq__:
if getattr(self, i) != getattr(other, i):
return False
return True
Wow, 20 lines of support code, how could one ever expect users to write
that? ;)
> 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.
> > P.S. One thing that you should remember is that even if your patch is
> > accepted, and even if this is desireable, Python 2.5 is supposed to be
> > released sometime next year (spring/summer?), and because it is a
> > backwards incompatible change, would need at least 2.6-2.7 before it
> > becomes the default behavior without a __future__ import, which is
> > another 3-4 years down the line.
>
> I hope that the warning can go in by Python 2.5, so the change (which
> I think will cause relatively few backwards incompatibility problems)
> can go in by Python 2.6, which I think is less than 2 years down the
> line.
As per historical release schedules (available in PEP form at
www.python.org/peps), alpha 1 to final generally takes 6 months. It
then takes at least a year before the alpha 1 of the following version
is to be released.
Being that 2.4 final was released November 2004, and we've not seen an
alpha for 2.5 yet, we are at least 6 months (according to history) from
2.5 final, and at least 2 years from 2.6 final.
>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.
> Thanks - I should really calm down a bit. I will try to go "safe and
> slowly", and I hope that at the end I will succeed in making my own
> small contribution to Python.
You should also realize that you can make contributions to Python
without changing the language or the implementation of the langauge.
Read and review patches, help with bug reports, hang out on python-list
and
Re: [Python-Dev] Why should the default hash(x) == id(x)?
Noam Raphael wrote: > Is there a reason why the default __hash__ method returns the id of the > objects? You are asking "why" question of the kind which are best answered as "why not". IOW, you are saying that the current behaviour is bad, but you are not proposing any alternative behaviour. There are many alternatives possible, and they are presumably all worse than the current implementation. To give an example: "why does hash() return id()"? Answer: The alternative would be that hash() returns always 0 unless implemented otherwise. This would cause serious performance issues for people using the objects as dictionary keys. If they don't do that, it doesn't matter what hash() returns. > This leads me to another question: why should the default __eq__ > method be the same as "is"? Because the alternative would be to always return "False". This would be confusing, because it would cause "x == x" to give False. More generally, I claim that the current behaviour is better than *any* alternative. To refute this claim, you would have to come up with an alternative first. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Should the default equality operator compare values instead of identities?
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.
>
> class eqMetaclass(type):
> def __new__(cls, name, bases, dct):
> if '__cmp_include__' in dct:
> include = dict.fromkeys(dct['__cmp_include__'])
> else:
> include = dict.fromkeys(dct.keys)
>
> for i in dct.get('__cmp_exclude__'):
> _ = include.pop(i, None)
>
> dct['__cmp_eq__'] = include.keys()
> return type.__new__(cls, name, bases, dct)
>
> It took 10 lines of code, and was trivial (except for not-included
> multi-metaclass support code, which is being discussed in another thread).
>
> Oh, I suppose I should modify that __eq__ definition to be smarter about
> comparison...
>
> def __eq__(self, other):
> if not hasattr(other, '__cmp_eq__'):
> return False
> if dict.fromkeys(self.__cmp_eq__) != \
>dict.fromkeys(other.__cmp_eq__):
> return False
> for i in self.__cmp_eq__:
> if getattr(self, i) != getattr(other, i):
> return False
> return True
Thanks for the implementation. It would be very useful in order to
explain my suggestion.
It's nice that it compares only attributes, not types. It makes it
possible for two people to write classes that can be equal to one
another.
>
> 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.
>
>
> > 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.
>
...
>
> 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.
...
>
> You should also realize that you can make contributions to Python
> without changing the language or the implementation of the langauge.
> Read and review patches, help with bug reports, hang out on python-list
> and attempt to help the hundreds (if not thousands) of users who are
> asking for help, try to help new users in python-tutor, etc.
I confess that I don't do these a lot. I can say that I from time to
time teach beginners Python, and that where I work I help a lot of
other people with Python.
> If you
> have an idea for a language change, offer it up on python-list first
> (I've forgotten to do this more often than I would like to admit), and
> if it generally has more "cool" than "ick", then bring it back here.
>
I will. Thanks again.
Noam
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Should the default equality operator compare values instead of identities?
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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Should the default equality operator compare values instead of identities?
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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Why should the default hash(x) == id(x)?
On 11/5/05, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > More generally, I claim that the current behaviour is better than > *any* alternative. To refute this claim, you would have to come > up with an alternative first. > The alternative is to drop the __hash__ method of user-defined classes (as Guido already decided to do), and to make the default __eq__ method compare the two objects' __dict__ and slot members. See the thread about default equality operator - Josiah Carlson posted there a metaclass implementing this equality operator. Noam ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Why should the default hash(x) == id(x)?
Noam Raphael <[EMAIL PROTECTED]> wrote: > > On 11/5/05, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > More generally, I claim that the current behaviour is better than > > *any* alternative. To refute this claim, you would have to come > > up with an alternative first. > > > The alternative is to drop the __hash__ method of user-defined classes > (as Guido already decided to do), and to make the default __eq__ > method compare the two objects' __dict__ and slot members. > > See the thread about default equality operator - Josiah Carlson posted > there a metaclass implementing this equality operator. The existance of a simple equality operator and metaclass is actually a strike against changing the default behavior for equality. - Josiah ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Why should the default hash(x) == id(x)?
Noam Raphael wrote: > On 11/5/05, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > >>More generally, I claim that the current behaviour is better than >>*any* alternative. To refute this claim, you would have to come >>up with an alternative first. >> > > The alternative is to drop the __hash__ method of user-defined classes > (as Guido already decided to do), and to make the default __eq__ > method compare the two objects' __dict__ and slot members. > no, whether object has an __hash__ and what is the default hashing are different issues. Also all this discussion should have started and lived on comp.lang.python and this is a good point as any to rectify this. > See the thread about default equality operator - Josiah Carlson posted > there a metaclass implementing this equality operator. > > Noam > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/pedronis%40strakt.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Should the default equality operator compare values instead of identities?
Noam Raphael <[EMAIL PROTECTED]> wrote: > > 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. > 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 to use. > 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. - Josiah ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
