And rewrite it in every project?! No, thanks. I'd like to write it now
and have no troubles in future at all.
On Jun 2, 9:12 am, "Leo Soto M." <[EMAIL PROTECTED]> wrote:
> On Wed, May 28, 2008 at 5:08 PM, Alex Koshelev <[EMAIL PROTECTED]> wrote:
> > On May 29, 12:57 am, "Leo Soto M." <[EMAIL
On Wed, May 28, 2008 at 5:08 PM, Alex Koshelev <[EMAIL PROTECTED]> wrote:
> On May 29, 12:57 am, "Leo Soto M." <[EMAIL PROTECTED]> wrote:
>> I see that almost all Field subclasses which implements
>> get_db_prep_save end calling Field.get_db_prep_save anyway. That's
>> curious, because
I am running Django on a centos box using lighttpd and fastcgi. I
found that if I didn't daemonize the fastcgi process and did not
specify a socket name to the manage.py script that the fcgi handlers
cooperated better and was able to place all of the fcgi process under
the control of lighttpd and
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
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
-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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> I'm +1 on this. An exception should only appear on the console if
> something serious is broken.
The term you're looking for is "error", not exception. An exception
can be expected.
Where would you fellows suggest we catch this exception, and
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
I'm +1 on this. An exception should only appear on the console if
something serious is broken.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to
On Sat, May 31, 2008 at 10:25 PM, Russell Keith-Magee
<[EMAIL PROTECTED]> wrote:
> The change looks good to me. However, I would note that there is an
> analogous change required for OneToOneFields on
> SingleRelatedObjectDescriptor, around line 190.
Ah, thanks -- good eyes.
Jacob
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,
Jacob Kaplan-Moss wrote:
> So, a proposal: I'd like to change FK assignment to be "special" like
> you suggested. I'd like to:
>
> * Raise a ``ValueError`` if you try to assign an object of the wrong
> type to a FK.
Why not defer it to save()? Currently you can assign invalid values to
other
No it's not really a problem,
thats why i called it an 'issue' between quotes :)
It's probably better called something like a style issue.
But some people see this as an problem, cause you get a loud (perhaps
for some scarry) looking exception. For something which is essentially a
non-problem.
Currently, QuerySet.delete() ignores custom Model.delete() methods
(#6915 [1]). I'd like to discuss possible solutions - foo.delete()
should be equivalent to Foo.objects.filter(pk=foo.pk).delete().
1. Disallow custom Model.delete() methods, offer signals only.
That's easy, but no real option
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
I'd prefer multiple methods (save(), insert(), update()) to make
subclassing easier. If that's not an option, I'd suggest
Model.save(allow_update=True, allow_insert=True)
Then False,False would obviously be a no-op.
___
Johannes
--~--~-~--~~~---~--~~
You
> * 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:
While writing a little patch to get rid of the (annoyingly loud) 'broken
pipe' exception/traceback; i found that there actually a ticket for it
# which is marked won't fix.
Is it really a problem at all?
Ludvig "toxik" Ericson
[EMAIL PROTECTED]
21 matches
Mail list logo
