[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r36822 - in trunk: subversion/bindings/swig/python/svn subversion/tests/cmdline/svntest tools/dev

From: Greg Stein <gstein_at_gmail.com>
Date: Sun, 29 Mar 2009 16:54:04 +0100

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.

Period.

> 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. And because of incompatibilities, it
means that the trunk won't run under 3.0. So why do we have to suffer
with more complicated code?

-1 on 36822, and -1 on 36833. Both: complexity with zero benefit.

-g

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1471757
Received on 2009-03-29 17:54:28 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.