Guido van Rossum | 29 Jan 20:32 2003

Re: Extended Function syntax


Christian Tismer | 1 Jan 03:44 2003

Re: PEP 303: Extend divmod() for Multiple Divisors

Guido van Rossum wrote:
> On the one hand I find this a nice backwards-compatible extension of
> divmod().  On the other hand I've coded this use case with separate
> divmod() calls and never had any trouble getting it right.  So I think
> this doesn't address a real need, and it conflicts with the need to
> avoid unnecessary growth of the language.  Explaining it (especially
> why it works backward) takes some effort, and I don't want to do that
> to all the book authors etc.

I totally agree. This nice extension to divmod() turns
the function into something more polynomial algebra
related, and divmod is no longer the proper name of
the function. Also, the specialized use of it makes
it more suitable to be put into a general algebra
module for Python, for sure not into the builtins.

Having that said, let's have a closer look at divmod.

It appears in 36 .py files out of about 1500 .py files
in the Python 2.2 source distribution. This is little
more than 2 percent.
The effort to correctly remember the order of the
arguments and the results tuple does not suffice
to justify the existance of this function at all.
Furthermore, divmod does not provide any
functionality that isn't easily obtained by a
simple div and mod.

Finally, and for me this is the killer argument
for divmod:
(Continue reading)

Guido van Rossum | 1 Jan 05:22 2003

Re: PEP 303: Extend divmod() for Multiple Divisors

> Therefore, I consider divmod a waste of code and
> a function to be deprecated ASAP (and since years).

Maybe it wasn't such a good idea.

> Save brain cells, save computation time, and save
> paper and ink of the book writers by dropping divmod!

At this point, any change causes waste, so unless it's truly broken
(which I don't believe) I'm not for changing it.

> Vice versa, if at all, I suggest a built in /% operator
> as a faster equivalen to single / and %, but I believe
> this code can be used more efficiently.
> divmod should be a special case of an algebraic
> extension module and removed from the builtins.

That would have to be //% to be in line with the // operator, of
course.  But I'd rather spend the effort towards making the compiler
smart enough to recognize that divmod is a built-in so it can generate
more efficient code (and I *am* prepared to make the necessary --
slight -- changes to the language so that the compiler can make this
deduction safely).

> divmod does not save computation time, does not
> reduce programming time, does not simplify programs,
> eats paper and code space

I find

(Continue reading)

Christian Tismer | 1 Jan 10:00 2003

Re: PEP 303: Extend divmod() for Multiple Divisors

Guido van Rossum wrote:
...

>>Vice versa, if at all, I suggest a built in /% operator
>>as a faster equivalen to single / and %, but I believe
>>this code can be used more efficiently.
>>divmod should be a special case of an algebraic
>>extension module and removed from the builtins.
> 
> 
> That would have to be //% to be in line with the // operator, of
> course.  But I'd rather spend the effort towards making the compiler
> smart enough to recognize that divmod is a built-in so it can generate
> more efficient code (and I *am* prepared to make the necessary --
> slight -- changes to the language so that the compiler can make this
> deduction safely).

I stand corrected. And yes, catching certain builtins
sounds like an optimzation path that is still open.
Hey, len would have an incredible boost!!!

>>divmod does not save computation time, does not
>>reduce programming time, does not simplify programs,
>>eats paper and code space
> 
> 
> I find
> 
>   mm, ss = divmod(ss, 60)
> 
(Continue reading)

Christian Tismer | 1 Jan 12:25 2003

Re: PEP 303: Extend divmod() for Multiple Divisors

Guido van Rossum wrote:
...

> I find
> 
>   mm, ss = divmod(ss, 60)
> 
> easier to read than
> 
>   mm, ss = ss//60, ss%60

Before I retract completely, I have a small addition.

   mm = ss//60; ss %= 60

is very readable to me, very efficient, and doesn't use
extra tuples. It is also 2 characters shorter than the
divmod version (both with the usual spacing, of course).
On the other hand, divmod clearly says what is going to
happen, and in fact it is a higher level approach.

On dropping features, I came to this in the morning:

You said you might optimize certain builtins by the
compiler, instead of removing divmod.

How about this:
If divmod is supported by the compiler, there isn't
any reason to keep it as a compiled C module. Instead,
divmod could be a piece of Python code, which is
(Continue reading)

Ben Laurie | 1 Jan 13:58 2003
Picon

Re: PEP 303: Extend divmod() for Multiple Divisors

Andrew Koenig wrote:
> Lalo> I'm +0 on this (reasons below), but since Guido already said no:
> Lalo> I find this function pretty useful, as it serves to collapse
> Lalo> ugly code, and I hate ugly python code.  However, the name
> Lalo> sucks.  With your changes, 'divmod' doesn't describe it anymore.
> 
> Lalo> So I suggest you come up with a better name and offer it as a
> Lalo> contribution to, say, the math module.  In that case I would
> Lalo> prefer to have the reverse function too.
> 
> If it helps, APL uses the names "base" and "represent" for these
> two functions.

I thought it used "radix" and not "base"?

Cheers,

Ben.

--

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Guido van Rossum | 1 Jan 14:56 2003

Re: PEP 303: Extend divmod() for Multiple Divisors

> > I find
> > 
> >   mm, ss = divmod(ss, 60)
> > 
> > easier to read than
> > 
> >   mm, ss = ss//60, ss%60
> 
> Before I retract completely, I have a small addition.
> 
>    mm = ss//60; ss %= 60
> 
> is very readable to me, very efficient, and doesn't use
> extra tuples.

A good optimizing compiler could also get rid of extra tuples.

> It is also 2 characters shorter than the
> divmod version (both with the usual spacing, of course).

Shame on you.  Would you rather write Perl? :-)

> On the other hand, divmod clearly says what is going to
> happen, and in fact it is a higher level approach.

Yes.

> On dropping features, I came to this in the morning:
> 
> You said you might optimize certain builtins by the
(Continue reading)

Tim Peters | 1 Jan 18:35 2003
Picon
Picon

RE: PEP 303: Extend divmod() for Multiple Divisors

[Christian Tismer]
>> Therefore, I consider divmod a waste of code and
>> a function to be deprecated ASAP (and since years).

[Guido]
> Maybe it wasn't such a good idea.

You can remove divmod() when I'm dead.  Before then, it stays.  I'm sure all
will agree that's a reasonable compromise.

> ...
> But what about long division, where divmod can (in extreme cases)
> really save time by doing the division only once?

On my box, divmod(x, y) is already 40% faster than "x//y; x%y" when x is a
63-bit int and y is 137354.  In the hundreds of places I've used it in
programs slinging multi-thousand bit integers, it's essentially twice as
fast.

But I don't care so much about that as that divmod() is the right conceptual
spelling for the operation it performs.

If we have to drop a builtin, I never liked reduce <wink>, although Jeremy
pointed out that its most common use case no longer requires writing a
lambda, or importing operator.add:

>>> reduce(int.__add__, range(11))
55
>>>

(Continue reading)

Barry A. Warsaw | 1 Jan 20:36 2003

RE: PEP 303: Extend divmod() for Multiple Divisors


>>>>> "TP" == Tim Peters <tim.one <at> comcast.net> writes:

    TP> If we have to drop a builtin, I never liked reduce <wink>,
    TP> although Jeremy pointed out that its most common use case no
    TP> longer requires writing a lambda, or importing operator.add:

Hey, if we'll killing off builtins, I vote for apply().

-Barry
Raymond Hettinger | 1 Jan 20:59 2003

Re: PEP 303: Extend divmod() for Multiple Divisors

[Tim]
>     TP> If we have to drop a builtin, I never liked reduce <wink>,
>     TP> although Jeremy pointed out that its most common use case no
>     TP> longer requires writing a lambda, or importing operator.add:

[Barry]
> Hey, if we'll killing off builtins, I vote for apply().

buffer() and intern() are two candidates for least understood,
least used, and most likely not to be missed.

Raymond Hettinger

Gmane