David A. Wheeler has already written a draft PEP, which can be found here:
http://www.dwheeler.com/misc/pep-cmp.txt.
___
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.o
I request the addition of prod():
def prod(seq):
s = 1
for x in seq:
s *= x
prod is always as useful as sum()
___
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http:/
On Jan 5, 2008 7:11 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> > I think pep 3141's round(x, ndigits) does (1). The only thing it
> > doesn't support yet is specifying the rounding mode. Perhaps the pep
> > should say that round() passes any extra named arguments on to the
> > __round__() m
The default factory that collections.defaultdict takes cannot use key. Is
there a way to have the default factory take the key into consideration? For
example
d = collections.defaultdict(lambda title: BookShelf(title))
If not, I propose that it be added.
_
hashcollision schrieb:
> The default factory that collections.defaultdict takes cannot use key.
> Is there a way to have the default factory take the key into
> consideration? For example
>
> d = collections.defaultdict(lambda title: BookShelf(title))
>
> If not, I propose that it be added.
hashcollision schrieb:
> I request the addition of prod():
>
> def prod(seq):
> s = 1
> for x in seq:
> s *= x
>
> prod is always as useful as sum()
It would have to be called product(), and I believe it has been proposed
multiple times and been rejected under the "not every
On 06/01/2008, Georg Brandl <[EMAIL PROTECTED]> wrote:
> hashcollision schrieb:
> > I request the addition of prod():
> It would have to be called product(), and I believe it has been proposed
> multiple times and been rejected under the "not every 3-line function
> has to be builtin" rule.
Please
Paul Moore schrieb:
> On 06/01/2008, Georg Brandl <[EMAIL PROTECTED]> wrote:
>> hashcollision schrieb:
>> > I request the addition of prod():
>> It would have to be called product(), and I believe it has been proposed
>> multiple times and been rejected under the "not every 3-line function
>> has t
On 06/01/2008, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Paul Moore schrieb:
> > On 06/01/2008, Georg Brandl <[EMAIL PROTECTED]> wrote:
> >> hashcollision schrieb:
> >> > I request the addition of prod():
> >> It would have to be called product(), and I believe it has been proposed
> >> multiple ti
Paul Moore schrieb:
> On 06/01/2008, Georg Brandl <[EMAIL PROTECTED]> wrote:
>> Paul Moore schrieb:
>> > On 06/01/2008, Georg Brandl <[EMAIL PROTECTED]> wrote:
>> >> hashcollision schrieb:
>> >> > I request the addition of prod():
>> >> It would have to be called product(), and I believe it has bee
As people had disliked the py3k keyword in the tracker,
I have now changed all items that were still using it to
use the Python 3.0 version instead, and retired that keyword.
So please search for version "Python 3.0" if you want to see
issues related to Python 3000.
Regards,
Martin
__
On Jan 6, 2008 1:21 AM, Jeffrey Yasskin <[EMAIL PROTECTED]> wrote:
> On Jan 5, 2008 7:11 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> > > I think pep 3141's round(x, ndigits) does (1). The only thing it
> > > doesn't support yet is specifying the rounding mode. Perhaps the pep
> > > should sa
On Jan 6, 2008 1:19 AM, hashcollision <[EMAIL PROTECTED]> wrote:
> I request the addition of prod():
>
> def prod(seq):
> s = 1
> for x in seq:
> s *= x
>
> prod is always as useful as sum()
No it isn't.
This was discussed extensively at the time sum() was proposed and
accepted
FWIW, I don't think all of these patches are helpful. The implementations are
so easy and the effects are so obvious, that it is
simply better to decide what to do first, then do it afterwards.
My own preference is to leave the decimal module alone (except for a __round__
method to be called b
On Jan 6, 2008 5:13 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> FWIW, I don't think all of these patches are helpful. The implementations
> are so easy and the effects are so obvious, that it is
> simply better to decide what to do first, then do it afterwards.
>
> My own preference is to
[Jeffrey Yasskin]
> The other 3 methods
> specified by PEP 3141 aren't strictly necessary for 2.6, but they will
> be needed for 3.0. I'd rather not make the two versions of Decimal
> gratuitously different, so this patch puts them in the 2.6 version
> too.
If I understand you correctly, then the
On Jan 5, 2008 10:40 PM, hashcollision <[EMAIL PROTECTED]> wrote:
> David A. Wheeler has already written a draft PEP, which can be found here:
> http://www.dwheeler.com/misc/pep-cmp.txt.
Thanks, I'd missed that.
But alas, it's a bit short on the motivation for rich comparisons. For
example it fai
On Jan 6, 2008 7:40 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> [Jeffrey Yasskin]
> > The other 3 methods
> > specified by PEP 3141 aren't strictly necessary for 2.6, but they will
> > be needed for 3.0. I'd rather not make the two versions of Decimal
> > gratuitously different, so this patc
[Raymond]
>> There should probably be a PEP sets clearer guidelines about what should be
>> backported from Py3.0.
>>
>> Perhaps something like this:
>> * If there is a new feature that can be implemented in both and will make
>> both more attractive, then it should be in both.
>> * If something
On Jan 6, 2008 7:40 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> [Jeffrey Yasskin]
> > The other 3 methods
> > specified by PEP 3141 aren't strictly necessary for 2.6, but they will
> > be needed for 3.0. I'd rather not make the two versions of Decimal
> > gratuitously different, so this patc
[Jeffrey Yasskin]
>> > I'm not
>> > sure exactly what you're objecting to. Could you be more precise?
>>
>> You note said: "I'll implement Context.round() in a separate patch. Comment
>> away."
>
> Oh, sorry for not being clear then. I don't intend to write or discuss
> that separate patch until
[Jeffrey Yasskin]
> Given Guido's agreement, expect another version of this patch with
> only __trunc__.
Why is __trunc__ being backported? Is a trunc() builtin being backported?
What is the point for a synonym for int() and __int__ in
Py2.6.
Unless I'm missing something, this doesn't improve
22 matches
Mail list logo
