DjangoBot: #django-dev

Hi guys, is there any way to see the SQL a query generates apart from the setting.DEBUG=True plus from django.db import conection ; print connection.queries method?

I'm tracking a SQL generation-related Django test suite failure under win32 and can't get to see the offending SQL: http://dpaste.com/59719

cramm: if you're using trunk just str(queryset)

or queryset.query.as_sql()

Hi, could someone take a look at #7061? I suspect telenieko misunderstood my description when closing the ticket. I didn't re-open just in case it's me who's off the track.

More specifically, doesn't this improve i18n docs to better describe what Django actually does: http://code.djangoproject.com/attachment/ticket...

jkocherhans: Is the plan to merge NFA before the EuroPython NFA sprint, or before the alpha sprint?

Alex_Gaynor: I wanted to do it before the EuroPython sprint, but I don't think it's gonna happen

What issues are remaining that are blockers(aka any good tickets to work on)?

I have one last major API change I'd like to make, but I haven't had time to write it all up yet

Or is it mostly the registration stuff?

brosner knows better than I do at this point. I haven't been following very closely for the last couple of months :(

I think he says it's ready for merge :D

that's good news :)

that would own, I'll start a project soon - It would be great if it would get merged soon :P

may I ask if there's a special design decision on why send_mail is blocking ? I think it would be logical if it wouldn't block.

Personal opinion: if you want send_mail to be non-blocking, use a local mail queue on the webserver.

They're easy to run, take no time to deliver to, and have no effect on the final message where the mail is being relayed to.

If send_mail was non-blocking, there would be *all sorts* of problems with web requests finishing before send_mail was done.

"Check back later to see if your email was successfully sent!" :)

As it is, the Django folks try to avoid claiming that threading is even supported within the framework, so any form of async I/O is going to get a definite -1 around here.

I have a hard time taking a *nix box seriously that doesn't have a proper local daemon, even if all it does is forward upstream.

There are reasons for it in an environment that requires a little more paranoia than usual, but at that point you will have other restrictions that will make a blocking e-mail send the least of your concerns.

looks like I'll do a daemon that forwards, as the mail is managed by 3rd party

and I tought first that smtp to it would be easy & doable, but now it timeouts

A daemon on the local box might even be overthinking it. What about just a cron job that runs every minute?

I'm trying to get access to the database name from the django testing framwork test and when I print settings.DATABASE_NAME it doesn't print out the test database name. From the source it seems like it sets the DATABASE_NAME to the test database.

Hi guys, anyone using Mac OS X?

sakyamuni: sakyamuni what about settings.TEST_DATABASE_NAME?

sakyamuni: I try to print that and TEST_DATABASE_NAME is not in settings.

'module' object has no attribute 'TEST_DATABASE_NAME'