Raymond Hettinger wrote:
> Please ignore my last email. The idea for combining trunc, ceil,
> floor, etc was probably just a distractor.
I was going to suggest the same round(n, mode="round_method_of choice") to
both round and int(), where int is more forgiving for input. But wasn't
convince
> No, using trunc(x) makes it clear that the argument and return
> value are numbers. Using x.trunc() doesn't.
Not sure where this is notion comes from.
Terry Reedy's post provides a datapoint to the contrary.
Besides, there is no problem along these lines that
can't be cured by a better method n
Please ignore my last email. The idea for combining trunc, ceil,
floor, etc was probably just a distractor.
[GvR]
> One thing I'm beginning to feel more and more strongly about
> is that round, trunc, ceil and floor all belong in the same
> category, and either should all be builtins or should a
> One thing I'm beginning to feel more and more strongly about
> is that round, trunc, ceil and floor all belong in the same
> category, and either should all be builtins or should all
> be in math.
>
> I should also admit that the 2-arg version of round() was
> borrowed from ABC, but the use ca
On Jan 28, 2008 2:28 PM, Daniel Stutzbach
<[EMAIL PROTECTED]> wrote:
> On Jan 28, 2008 4:00 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > No, using trunc(x) makes it clear that the argument and return value
> > are numbers. Using x.trunc() doesn't.
>
> How often do you expect someone to be lo
On Jan 28, 2008 4:00 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> No, using trunc(x) makes it clear that the argument and return value
> are numbers. Using x.trunc() doesn't.
How often do you expect someone to be looking at code where a trunc()
method is being called and the variable could pl
On Jan 28, 2008 1:54 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > This is why len() is not a method:
> >
> > map(len, list_of_strings)
>
> That's a good use case - but is that the reason?
>
> I would think that the true historical reason is that when len()
> was introduced, there weren'
[MvL]
> I wouldn't want to propose removal of len(), no. However,
> I do think that adding more builtins (trunc in particular)
> is bad, especially when they make perfect methods.
+1
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mai
> This is why len() is not a method:
>
> map(len, list_of_strings)
That's a good use case - but is that the reason?
I would think that the true historical reason is that when len()
was introduced, there weren't methods in the language. And even
when support for methods was added, many types
On Jan 27, 2008 12:53 PM, Aahz <[EMAIL PROTECTED]> wrote:
> This is why len() is not a method:
>
> map(len, list_of_strings)
I disagree with that explanation -- I couldn't know that when I made
len() a function, because map() wasn't to become part of the language
for another 5-6 years.
My exp
On Jan 27, 2008 12:53 PM, Aahz <[EMAIL PROTECTED]> wrote:
> On Sun, Jan 27, 2008, "Martin v. L?wis" wrote:
> >
> > Students just asked me why len() is not a method, and I didn't know a
> > good answer; the same holds for many other builtins. This is a clear
> > candidate for a method, IMO.
>
> This
11 matches
Mail list logo
