On Nov 17, 12:50 am, Jannis Leidel <[EMAIL PROTECTED]> wrote:
>
> The two -1 from core devs veto the feature for the next version, not
> the whole feature. We can go on discussing it here. I still hope they
> chime in though :)
>
I hope so too.
>
> Indeed, my idea though is to dodge imports
On Nov 17, 1:13 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> My -1 is because of basically the same thing Jannis has pointed out (and
> as I mentioned in my comment). There's a big ticket with various
> proposals and at some point last year Adrian mentioned he had another
> idea and that
>> Indeed, my idea though is to dodge imports in settings.py and just
>> use
>> dotted module names.
>
> I'm not sure why importing in settings.py is such a bad thing. Putting
> in dotted module names just moves the importing to somewhere else
> (which you don't control) and seems more
On Mon, 2008-11-17 at 02:24 -0800, Vinay Sajip wrote:
>
>
> On Nov 17, 1:13 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
> wrote:
> > My -1 is because of basically the same thing Jannis has pointed out (and
> > as I mentioned in my comment). There's a big ticket with various
> > proposals and at
The last thing new people need when they come in and start playing
around with the dev server is to worry about all the issues that can
come up with threading. I would never recommend to anyone who doesn't
really know what they're doing and anyone who does can easily use any
one of the number of
On Nov 16, 2008, at 07:26, Chris wrote:
> 3. Fear of multi-threading bugs shouldn't be a reason to avoid multi-
> threading, especially when it could be very useful. We don't even know
> if there are multi-threading bugs. And even if there are, they can be
> fixed.
There are bugs. Django isn't
Is there any documentation as to why Django is not threadsafe? It just
seems to me that with the Global Interpreter Lock and all, it would be
threadsafe. I don't intend to start a flame, I am just curious about
learning why this might be. I am favor of the mutlitprocess approach layed
out by
On Mon, Nov 17, 2008 at 10:54 AM, Ludvig Ericson
<[EMAIL PROTECTED]> wrote:
> There are bugs. Django isn't thread-safe, and we know that.
Um...
That's just not true. At one point (two years ago?) it wasn't, but
these days Django's deployed all over the place in mutli-threaded
situations. If it
On Nov 17, 11:20 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
>
> The InstalledAppsRevision wiki page. That was produced after the PyCon
> sprint. Since that involved a bunch of people, a number of them
> maintainers, I tend to view it as fairly canonical as to what is wanted
> in the
On Nov 17, 10:31 am, Jannis Leidel <[EMAIL PROTECTED]> wrote:
>
> Importing in the settings.py is effectively not required by any other
> part of Django.
Is importing in settings.py regarded generally as bad practice? If so,
I wasn't aware of this.
> What do you mean by "which you don't
On Nov 16, 11:03 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> I know this is a horribly nebulous question (like all benchmarking),
> and it's completely dependent on the speed of your machine and a
> million other factors. However, if we are going to start adding
> signals to very
On Mon, Nov 17, 2008 at 2:01 PM, Matthew D. Hancher
<[EMAIL PROTECTED]> wrote:
> Okay, I decided to do a bit of profiling to keep the conversation moving.
I did too; I took a stab at measure the raw speed of calling signals.
My code's at http://gist.github.com/25892; the output looks like:
Matthew, would you mind sticking the script you used to test this up
on dpaste?
Alex
On Nov 17, 3:01 pm, "Matthew D. Hancher" <[EMAIL PROTECTED]>
wrote:
> On Nov 16, 11:03 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]>
> wrote:
>
> > I know this is a horribly nebulous question (like all
I've been trying to dump some data to fixtures for the last couple
days, and I've ran into various problems each time. It's been quite
difficult each time to determine the problems, as there's no useful
tracebacks on the error messages:
[EMAIL PROTECTED]:~/Development/iplatform] ./manage.py
Try to use `--traceback` switch that prints exception's traceback
On Tue, Nov 18, 2008 at 00:41, David Cramer <[EMAIL PROTECTED]> wrote:
>
> I've been trying to dump some data to fixtures for the last couple
> days, and I've ran into various problems each time. It's been quite
> difficult each
Ahh. I suppose that makes sense. Is there any reason it doesn't show
them by default?
On Nov 17, 3:45 pm, "Alex Koshelev" <[EMAIL PROTECTED]> wrote:
> Try to use `--traceback` switch that prints exception's traceback
>
> On Tue, Nov 18, 2008 at 00:41, David Cramer <[EMAIL PROTECTED]> wrote:
>
>
[EMAIL PROTECTED] wrote:
> Matthew, would you mind sticking the script you used to test this up
> on dpaste?
I'd love to, but it wasn't really a script per se, so much as a hodge-
podge that involved twiddling the server, restarting it, running some
tests, changing the server config again,
On Mon, Nov 17, 2008 at 4:14 PM, matt westerburg <[EMAIL PROTECTED]> wrote:
> Is there any documentation as to why Django is not threadsafe? It just
> seems to me that with the Global Interpreter Lock and all, it would be
> threadsafe.
That wouldn't as nice as "really-really thread safe". You
On Mon, Nov 17, 2008 at 3:49 PM, David Cramer <[EMAIL PROTECTED]> wrote:
> Ahh. I suppose that makes sense. Is there any reason it doesn't show
> them by default?
Because they're hard to read and scary for folks not familiar with
Python. "I just typed this one thing and got twenty lines of error
On Mon, Nov 17, 2008 at 3:41 PM, David Cramer <[EMAIL PROTECTED]> wrote:
> I've been trying to dump some data to fixtures for the last couple
> days, and I've ran into various problems each time. It's been quite
> difficult each time to determine the problems, as there's no useful
> tracebacks on
Hi again, time for my next GeoDjango-on-SQLite question.
In order to load the SpatiaLite extensions for SQLite, you first need
to enable SQLite extensions in the first place. Unfortunately,
pysqlite did not expose this functionality until pysqlite 2.5.0, which
means it didn't make it into
As long as you get the connection itself, i would think that would be
sufficient, obviously the receiver should know which connection it is
in the multi-db scenario, as it won't be able to just infer that based
on the settings.
On Nov 17, 6:15 pm, "Matthew D. Hancher" <[EMAIL PROTECTED]>
wrote:
On Thu, Nov 13, 2008 at 1:48 PM, Jacob Kaplan-Moss
<[EMAIL PROTECTED]> wrote:
> I've also reviewed most of the features on the list. I'll talk about the
> review process -- and how y'all can contribute -- below, but if you just wanna
> see my thoughts, they're here:
>
I know that this is likely to be a tricky/boring task and that it is
probably low-priority since we're on the way to 1.1, but I thought at
least I'd ask: Is there any plan in the short/mid term to upgrade
Trac?
My personal itch is that the current version (0.10.4) doesn't allow
email
On Mon, Nov 17, 2008 at 11:20 PM, Julien Phalip <[EMAIL PROTECTED]> wrote:
> I know that this is likely to be a tricky/boring task and that it is
> probably low-priority since we're on the way to 1.1, but I thought at
> least I'd ask: Is there any plan in the short/mid term to upgrade
> Trac?
Hi guys,
I wrote a post on django platform optimizations which i learned from
building (still learning actually) kwippy (http://kwippy.com) , i
would love to hear more tips from you guys out there :).
http://www.desinerd.com/blog/technical/django-optimizations-within-the-platform/
Looking
Hi Adrian,
> * View-02 (Add RequestContext to render_to_response() by default): A
> ticket or mailing-list discussion wasn't linked-to on this one, so I'm
> going purely on the name of the change -- but I really don't like it.
> I rarely use RequestContext; I'd even feel comfortable saying I
>
On Tue, Nov 18, 2008 at 12:04 AM, Yuri Baburov <[EMAIL PROTECTED]> wrote:
> I'm always wondeing how it's possible that Django creators don't use
> django in ways that are written in django documentation. That leads to
> misunderstanding in expectations, and should explain why some tickets
> don't
After months of being frustrated (and hearing other people being
frustrated) with our newish documentation index, I took some time
tonight to reorganize the links, to make it easier and faster to find
things. Take a look here:
http://docs.djangoproject.com/en/dev/
I opted for a much more
+1!
Just one suggestion - if the final "bateries included" could be split into
contrib apps, and core library that'd be nicer.
On Tue, Nov 18, 2008 at 8:44 PM, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> After months of being frustrated (and hearing other people being
> frustrated) with our
For all three of our projects in django, we've gone through and used our own
exended version of render_to_response, which uses RequestContext by default.
Its such a blessing.
On Tue, Nov 18, 2008 at 7:42 PM, James Bennett <[EMAIL PROTECTED]>wrote:
>
> On Tue, Nov 18, 2008 at 12:04 AM, Yuri
On Tue, Nov 18, 2008 at 12:42 AM, James Bennett <[EMAIL PROTECTED]> wrote:
> On Tue, Nov 18, 2008 at 12:04 AM, Yuri Baburov <[EMAIL PROTECTED]> wrote:
>> I'm always wondeing how it's possible that Django creators don't use
>> django in ways that are written in django documentation. That leads to
32 matches
Mail list logo
