On Sat, Jun 7, 2008 at 2:54 AM, Nicolas Lara <[EMAIL PROTECTED]> wrote:
>
>> You are explicitly asking for different output, so the fact that
>> different output happens shouldn't be entirely surprising. And
>> remember - In your propsal, you're getting back different output as
>> well - one versi
>
> My point is that the user shouldn't ever need to worry. A list that
> contains multiple versions of similar things is easy to process by
> iteration. A list that contains "similar things except for the one the
> isn't" is not as trivial to process.
>
>
> Bleh. Adding methods to clean up after
On Wed, Jun 4, 2008 at 2:23 AM, Nicolas Lara <[EMAIL PROTECTED]> wrote:
>
> On Mon, Jun 2, 2008 at 8:53 AM, Russell Keith-Magee
> <[EMAIL PROTECTED]> wrote:
>> for values in Author.objects.values('name','age'):
>> for name,age in values.items():
>> print name, age
>>
>> Simple use cases li
On Mon, Jun 2, 2008 at 8:53 AM, Russell Keith-Magee
<[EMAIL PROTECTED]> wrote:
>
> On Sun, Jun 1, 2008 at 9:04 PM, Nicolas Lara <[EMAIL PROTECTED]> wrote:
>>
>> I dont mind changing it to indexes. To me it is more readable with the
>> list copying/slicing. I might do a bit of profiling for that to
On Sun, Jun 1, 2008 at 9:04 PM, Nicolas Lara <[EMAIL PROTECTED]> wrote:
>
> I dont mind changing it to indexes. To me it is more readable with the
> list copying/slicing. I might do a bit of profiling for that to see
> the efficiency gain or simple change it to indexes. I'll write back
> about thi
Sorry 'bout that :) . I don't think the why of it ultimately matters,
code snippet Russell used does the same thing at the SQL-aggregation
stuff does, the speed difference should hold. Plus I agree it looks
cleaner.
On Jun 2, 1:31 am, Ludvig Ericson <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP S
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> s = 'abc'
> t = s[:]
> s is t
>> True
>>
>> I'm willing to be corrected here, but my understanding was that for
>> loop iteration was one of those optimization cases.
>
> It looks like it's an immutable-optimization from my further
> tes
On Mon, Jun 2, 2008 at 8:54 AM, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
>
> Lugwid appears correct:
I know he is - like I said in my reply to Ludwig, I picked a bad
example. My point was that slicing doesn't _always_ produce a copy -
it depends on the optimizations available to the bytecode
On Mon, Jun 2, 2008 at 8:48 AM, Ludvig Ericson <[EMAIL PROTECTED]> wrote:
>
> What you're seeing is Python's str cache. Similarly:
(I knew that example would come back to bite me...)
Yes, this particular example is due to Python's string handling. My
point was that there are cases where a slice
> To my understanding, a slice isn't automatically a copy - it will be
> in most cases, but there are cases where the bytecode compiler will
> use the original list as an optimization. One example:
>
> >>> s = 'abc'
> >>> t = s[:]
> >>> s is t
> True
>
> I'm willing to be corrected here, but
Lugwid appears correct:
In [1]: s = ['a', 'b', 'c']
In [2]: t = s[:]
In [3]: s is t
Out[3]: False
In [4]: id(t)
Out[4]: 138735596
In [5]: id(s)
Out[5]: 138740172
On Jun 1, 7:48 pm, Ludvig Ericson <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> > To my understand
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> To my understanding, a slice isn't automatically a copy - it will be
> in most cases, but there are cases where the bytecode compiler will
> use the original list as an optimization. One example:
>
s = 'abc'
t = s[:]
s is t
> True
>>>
On Sun, Jun 1, 2008 at 8:20 PM, Tim Chase
<[EMAIL PROTECTED]> wrote:
>
> > * On a similar note, I can see a lot of places where you
> > seem to be copies of lists (or sublists) - this is an
> > expensive operation if you do it a lot, especially since
> > most cases you could get the same effec
On Sun, Jun 1, 2008 at 4:39 AM, Russell Keith-Magee
<[EMAIL PROTECTED]> wrote:
> SELECT author.id, author.name, author.age, COUNT(book.id)
> FROM author INNER JOIN book ON author.id=book.author_id
> GROUP BY author.id, author.name, author.age;
>
> is the same as
>
> SELECT author.id, author.name
hello,
On Sun, Jun 1, 2008 at 7:39 AM, Russell Keith-Magee
<[EMAIL PROTECTED]> wrote:
>
> On Sun, Jun 1, 2008 at 4:02 AM, Nicolas E. Lara G.
> <[EMAIL PROTECTED]> wrote:
>>
>> Hello,
>> Today I've commited what could be called the first working version of
>> aggregate support. For those of you no
> * On a similar note, I can see a lot of places where you
> seem to be copies of lists (or sublists) - this is an
> expensive operation if you do it a lot, especially since
> most cases you could get the same effect by keeping the
> index values and slicing the original list as required.
>
On Sun, Jun 1, 2008 at 4:02 AM, Nicolas E. Lara G.
<[EMAIL PROTECTED]> wrote:
>
> Hello,
> Today I've commited what could be called the first working version of
> aggregate support. For those of you not keeping track of the project,
> it can be found at: http://code.google.com/p/django-aggregatio
Hello,
Today I've commited what could be called the first working version of
aggregate support. For those of you not keeping track of the project,
it can be found at: http://code.google.com/p/django-aggregation/
Some words on the status of the project.
Working
* Currently both ann
18 matches
Mail list logo
