In issue 3783 (http://bugs.python.org/issue3783) the question was raised
about whether or not it's worthwhile making this guarantee:
zip(d.keys(), d.values()) == d.items()
in the face of no changes to the mapping object. At issue is whether the
SQL query should force a predictable order on t
[EMAIL PROTECTED] wrote:
In issue 3783 (http://bugs.python.org/issue3783) the question was raised
about whether or not it's worthwhile making this guarantee:
zip(d.keys(), d.values()) == d.items()
in the face of no changes to the mapping object. At issue is whether the
SQL query should for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
We had a lot of discussion recently about changing the release
schedule and splitting Python 2.6 and 3.0. There was general
consensus that this was a good idea, in order to hit our October 1
deadline for Python 2.6 final at least.
There is on
Eric> Given items(), I don't see why you'd ever need "zip(a.keys(),
Eric> a.values())" to work.
Eric> Antoine makes many of these same points in the issue comments.
And as I pointed out there's no telling what users will do. The
zip(keys,values) behavior works for dicts and has pro
On Fri, Sep 12, 2008 at 7:54 AM, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> We had a lot of discussion recently about changing the release schedule and
> splitting Python 2.6 and 3.0. There was general consensus that this was a
> good idea, in order to hit our October 1 deadline for Python 2.6 fin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sep 12, 2008, at 9:19 AM, Edward K. Ream wrote:
On Fri, Sep 12, 2008 at 7:54 AM, Barry Warsaw <[EMAIL PROTECTED]>
wrote:
We had a lot of discussion recently about changing the release
schedule and
splitting Python 2.6 and 3.0. There was gen
2008/9/12 skip <[EMAIL PROTECTED]>:
> In issue 3783 (http://bugs.python.org/issue3783) the question was raised
> about whether or not it's worthwhile making this guarantee:
>
>zip(d.keys(), d.values()) == d.items()
>
> in the face of no changes to the mapping object. At issue is whether the
>
>> select key from dict order by key
>> select value from dict order by key
Guido> What's the purpose of the "order by key" clauses here? Doesn't
Guido> that force the return order? Perhaps you meant to leave those
Guido> out?
It's simply to guarantee that the order of the el
On Fri, Sep 12, 2008 at 10:13 AM, <[EMAIL PROTECTED]> wrote:
>
>>> select key from dict order by key
>>> select value from dict order by key
>
>Guido> What's the purpose of the "order by key" clauses here? Doesn't
>Guido> that force the return order? Perhaps you meant to leave thos
On Fri, Sep 12, 2008 at 10:33 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On Fri, Sep 12, 2008 at 10:13 AM, <[EMAIL PROTECTED]> wrote:
>>
>>>> select key from dict order by key
>>>> select value from dict order by key
>>
>>Guido> What's the purpose of the "order by key" clauses h
Guido> What's the purpose of the "order by key" clauses here? Doesn't
Guido> that force the return order? Perhaps you meant to leave those
Guido> out?
>>>
>>> It's simply to guarantee that the order of the elements of values()
>>> is the same as the order of the elements o
> Gerhard suggested that if predictable
> ordering was desired that "order by rowid" would be better.
I personally don't understand what predictability brings (using a disk backend
implies that you should minimize queries, so using keys() then values() is
inefficient compared to using items() any
12 matches
Mail list logo
