Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #106661 > unrolled thread

Re: how to convert code that uses cmp to python3

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: how to convert code that uses cmp to python3 Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-04-08 09:45 +0200
    Re: how to convert code that uses cmp to python3 Steven D'Aprano <steve@pearwood.info> - 2016-04-08 22:07 +1000
      Re: how to convert code that uses cmp to python3 Marko Rauhamaa <marko@pacujo.net> - 2016-04-08 15:52 +0300

#106661 — Re: how to convert code that uses cmp to python3

Op 07-04-16 om 23:08 schreef Ben Finney:
> Antoon Pardon <antoon.pardon@rece.vub.ac.be> writes:
>
>> With this method I have to traverse the two tuples almost always
>> twice. Once to find out if they are equal and if not a second time to
>> find out which is greater.
> You are essentially describing the new internal API of comparison
> operators. That's pretty much unavoidable.

And nobody thought about this kind of cases or found them important enough?

> If you want to avoid repeating an expensive operation – the computation
> of the comparison value for an object – you could add an LRU cache to
> that function. See ‘functools.lru_cache’.

I'll have a look.

-- 
Antoon

[toc] | [next] | [standalone]

#106674

On Fri, 8 Apr 2016 05:45 pm, Antoon Pardon wrote:

> Op 07-04-16 om 23:08 schreef Ben Finney:
>> Antoon Pardon <antoon.pardon@rece.vub.ac.be> writes:
>>
>>> With this method I have to traverse the two tuples almost always
>>> twice. Once to find out if they are equal and if not a second time to
>>> find out which is greater.
>> You are essentially describing the new internal API of comparison
>> operators. That's pretty much unavoidable.
> 
> And nobody thought about this kind of cases or found them important
> enough?

Probably not.

But you know, if you can demonstrate a genuine and severe slowdown with no
easy work-around, you should report it as a bug. It wouldn't be the first
time that functions removed from Python 3 have been re-added because it
turned out that they were needed.



>> If you want to avoid repeating an expensive operation – the computation
>> of the comparison value for an object – you could add an LRU cache to
>> that function. See ‘functools.lru_cache’.
> 
> I'll have a look.

I would be stunned if tuple comparisons with only a handful of values were
slow enough that its worth caching their results with an lru_cache. But try
it, and see how you go.




-- 
Steven

[toc] | [prev] | [next] | [standalone]

#106675

Steven D'Aprano <steve@pearwood.info>:

> I would be stunned if tuple comparisons with only a handful of values
> were slow enough that its worth caching their results with an
> lru_cache. But try it, and see how you go.

There are two ways your Python program can be slow:

 * You are doing something stupid like an O(exp(n)) when there is an
   O(n**2) available.

 * Python is inherently slower than C by a constant factor.

If you are doing something stupid, do refactor your code. But you
shouldn't try to make artificial optimizations to your code to make it
perform more like C. Write it in C, maybe partially, if you have to.

For example, your performance measurements might show that Python's
method calls are slow. That may be true but it is no invitation to
eliminate method calls from your code.


Marko

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web