[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 17:49:43 +0100

2009/3/29 Arfrever Frehtes Taifersar Arahesis <arfrever.fta_at_gmail.com>:
>...
>> 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.
> http://docs.python.org/reference/datamodel.html#object.__lt__
> They aren't harder to understand that __cmp__().

I'm *very* well aware of the rich comparison methods. I've had commit
access to Python for a dozen years. Well before those methods were
ever discussed.

But having *four* of them rather than a single __cmp__ is simply more
complicated. And it gains us nothing.

>> 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.
>
> These changes don't require Python 3. __eq__() and other "rich comparison" methods
> are supported since Python 2.1.

Sure. They work. And so did __cmp__. As a single method instead of four.

>> 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...

Great. There is one.

I'm fine with some of the changes. Tweaking whether we print or
print() is no real big deal. But switching away from cmp() just
complicated things.

And again: for what benefit? Most of our Python code will not be compatible.

>> So why do we have to suffer with more complicated code?
>
> r36833 rather simplified code.

I say it complicated things. More methods instead of fewer. Lots of
additional comparisons instead of just using cmp(). Additional logic.

And "Python 3.0 compatibility" for scripts intended for 2.4 doesn't
add any benefit.

-g

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1472267
Received on 2009-03-29 18:49:59 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.