2009-03-29 17:54:04 Greg Stein napisał(a):
> On Sun, Mar 29, 2009 at 06:41, Arfrever Frehtes Taifersar Arahesis
> <arfrever.fta_at_gmail.com> wrote:
> > 2009-03-28 18:15:39 Greg Stein napisał(a):
> >> -1
> >> this makes the code *very* unreadable.
> > It is/was temporary.
> >> cmp() is clean.
> > cmp() is dead :) .
> It is perfectly alive and kicking in Python 2.x.
> Your 3.0 "compatibility" is making our code harder and harder to
> maintain, for a purpose that isn't even *possible*. You're never going
> to reach full 3.0 compatibility on trunk, so all you're doing is
> screwing things up.
> These changes are making things less maintainable. Less understandable.
> I voted -1 for that reason, and I continue to maintain that. You're
> not adding any benefit, but you are *definitely* making things worse.
> All cost, no benefit.
> > In r36833 I deleted the remnants of cmp() in subversion/tests/cmdline/svntest/tree.py
> And I just looked at that. Geez. Making things even worse.
> Keep __cmp__() and the cmp() calls. They work, and they are simple,
> readable, and understandable.
"Rich comparison" methods (e.g. __eq__()) are well documented and understandable.
They aren't harder to understand that __cmp__().
> > and tools/dev/contribulyze.py. In tools/dev/trails.py cmp() was used in _freqtable_cmp()
> > which is used as 'cmp' argument of sort(). In Python 3 sort() doesn't have this argument,
> Really. I just don't care. We aren't going to require Python 3.0 on
> trunk in the next few years.
These changes don't require Python 3. __eq__() and other "rich comparison" methods
are supported since Python 2.1.
> And because of incompatibilities, it means that the trunk won't run under 3.0.
Some scripts (e.g. tools/dev/check-license.py) already work with Python 3...
> So why do we have to suffer with more complicated code?
r36833 rather simplified code.
Arfrever Frehtes Taifersar Arahesis
Received on 2009-03-29 18:42:26 CEST