Should exceptions in dev server appear as tracebacks in the console by default?

[hjwp]

The docs say:


*"All messages reaching the django catch-all logger when DEBUG 
 is 
True are sent to the console. They are simply discarded (sent to 
NullHandler) when DEBUG 
 is 
False."*
https://docs.djangoproject.com/en/1.6/topics/logging/#django-s-default-logging-configuration

>From reading that, I would (naively?) expect to see tracebacks in the 
terminal I'm running manage.py runserver, if any of my views raise an 
exception for example. I don't see any, however.

Is this because the exception *is* caught, in that it gets intercepted and 
turned into the nice django debug page?  Am i misinterpreting the docs?  If 
so, would it be worth adding a couple of words of clarification in case 
anyone else might misread it like me?  Assuming anyone is that silly?

Of course, I would rather prefer it if exception tracebacks *did* go to the 
console by default, as well as to mail_admins and/or to a nice django debug 
page...

hp

PS minimal repro:

django-admin.py startproject myproj
python manage.py startapp myapp



*urls.py:*
from django.conf.urls import patterns, include, url
urlpatterns = patterns('',
# Examples:
url(r'^$', 'myapp.views.home', name='home'),
)


*myapp/views.py:*
def home(request):
raise Exception('arg')


-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/60d3c4c6-22f8-4de6-a376-6230c33ad0a9%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: ImproperlyConfigured: Requested setting USE_I18N, but settings are not configured. You must either define the environment variable DJANGO_SETTINGS_MODULE or call settings.configure() before access

[hjwp]

Weirdly I'm getting this error when I 'am' running manage.py.  I'm doing 
something slightly weird, in that I'm using Popen from inside another 
python process to run python manage.py.  Still, it worked a few weeks back 
and just started happening.  Any tips on where to look to debug it?

On Thursday, April 25, 2013 3:22:16 PM UTC+1, Tom Evans wrote:
>
> On Thu, Apr 25, 2013 at 2:56 PM, Iftikhar Ali 
>  
> wrote: 
> > when i am running the project it is running perfectly fine but when i am 
> > trying to open django-admin.py shell the error: 
>
> Don;t use django-admin to launch the shell, only use django-admin to 
> create projects¹. Once you have created your project using 
> django-admin.py, use the manage.py script it created inside your 
> project to interact in any with it - creating apps, running syncdb, 
> accessing the project shell. 
>
> See the docs here: 
>
>
> https://docs.djangoproject.com/en/1.5/ref/django-admin/#django-admin-py-and-manage-py
>  
>
> The reason you want to use manage.py over django-admin,py is that 
> manage.py can usually find your settings automatically - it 
> automatically sets the environment variable DJANGO_SETTINGS_MODULE to 
> the correct value. 
>
> Cheers 
>
> Tom 
>
> ¹ Or standalone apps. For apps within the project, you use manage.py 
> startapp, like everything else in the project. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/2320a9da-8264-49d2-af2f-0b6abba39bfd%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Testing Django Class-based views

[hjwp]

I started a discussion about testing class-based (generic) views, a couple 
of people have pitched in already, thought I'd throw this out there in case 
anyone else can help:

http://www.obeythetestinggoat.com/testing-django-class-based-generic-views-None.html

It covers a couple of simple examples of views, where I refactor a 
function-based view to a class-based view.  Then there's an attempt to use 
a CBGV for a moderately complicated use case (adding a new related item 
model to an existing list), where we've struggled to make things look 
simple...

cf the comments (randomly, on github, cf the post), but it's frustratingly 
close to being a very simple CBGV use case with just one custom method, but 
we haven't managed to make it work.. Maybe someone else will be able to 
though?  Also, any suggestions re: other approaches to testing are 
welcomed...

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/166a3255-0945-41a4-8b00-6e22289d1bfe%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.