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

[Harry Percival]

 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.  But maybe that's just me.

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')

PPS apologies for x-post from django-users

 --
You received this message because you are subscribed to a topic in the
Google Groups "Django users" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/django-users/tCw4bqw2tsI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-us...@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.



-- 
--
Harry J.W. Percival
--
Twitter: @hjwp
Mobile:  +44 (0) 78877 02511
Skype: harry.percival

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CACFvh98U2AOxRuCwx9TJN2%2BEX%3DAgkiUfNb7%3DOmVaPYfh%3Dn18MQ%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Proposal of (another) podcast

[Elena Williams]

Merry Festive season to everyone to whom this is relevant!

tl;dr:
- News Podcast: basically reading blog out loud, hopefully short: ~15mins 
- Aiming for 30-Dec recording/publishing
- Seeking review of script/show 
notes
 for 
the 30-Dec recording
- Seeking file hosting suggestions

In light of the recent new update email (thanks Curtis!) and apparent 
recent discussions about dispersing news and information, I'm interested in 
doing a new kind of Django podcast.

This project is intended to target the members of the community who receive 
their news via podcasts -- to complement the blog, update email, 
announcements list, twitter, etc.

The aim is to be as *short* and *content rich* as possible within reason. 
My intended format is:

0. Security Advisories
> 1. Upcoming Cut-off Dates
> 2. Releases and Release Notes
> 3. Conferences/Events
> 4. General News
> 5. Community Requests
> (+ Django Dev email list summary)
> (+ Interview with core)


I have mainly prepared the content I'd intend to record and publish on 
30-Dec:
https://github.com/elena/django-news-podcast/blob/master/_2013-12-29.md
Patches are most welcome for any corrections or additions! Obviously this 
is my first attempt at this.

After talking to Curtis Maloney (aka FunkyBob) I'd intend to sync with 
every second email update, the 29/30 December will coincide with that.

A while ago I did an outline of a proposed format, which I've discussed 
with a few people including Curtis and Russell Keith-Magee: 
https://github.com/elena/django-news-podcast

To summarise: the format is basically *reading out loud the emails* (as was 
gracefully deduced by Russ).

The intention is to be short, say ~15 minutes for the main content and 
additional/bonus content going on for no longer than 30-45 minutes.

---

I'm wary that having seen the podcasts come and go that it's obviously 
tedious and/or boring and/or problematic in some way as they have tended to 
expire. This particular factor has been something I've given a lot of 
consideration to before sending this email.

My solution to this apparent pitfall is to attempt to make it as communal, 
modular and simple as possible -- with a rigid "fill-in-the-blanks" format, 
thus easily handed around for multiple people to do, should whatever 
happens to the other podcasts, happen to me.

At this stage (it's been on my mind for so long) I'm willing to champion 
this for as long as I can, though if anyone is interested in helping out 
with helping with any part of this project, eg, preparation, interviews, 
recording, editing, other segments, journalism/recording advice,  I'll 
welcome it enthusiastically!

I'm concerned about posting erroneous information, but I think that this is 
unavoidable and hopefully by making the script/show notes open to patches 
this will be a tractable problem.

--

Ideally I'd love to add *interviews* to the format.

For example it seems as though it would have been great to have a chat with 
Aymeric during this time as he's been doing a lot of work and to have him 
summarise this in his own words would be informative, though perhaps I'll 
be able to chase him up in the new year when I have real internet back 
again.

Also it feels like too much to attempt: doing an interview for this first 
edition (which I intend to record tomorrow). I've been travelling during 
this time and my internet has been appallingly (un-skype-ably) bad and it's 
also too much pressure at this early stage. 

--
 
I may still get it all wrong and don't promise anything will come of this 
suggestion, though have gotten to the stage where I feel confident enough 
to approach this list.

Essentially this is my own itch -- I'm motivated to scratch it and it seems 
like a bit of fun.

My final dilemma is where to make the podcast available from (in a hosting 
sense), but as I don't know the final file size yet I haven't agonised 
about this. I have plenty of options -- though any advice would be 
sincerely appreciated.

Any feedback at all would be sincerely appreciated actually! 
---
Elena Williams
@elequ

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ddc13c72-a45e-4083-b242-c90b36024ae3%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Improving aggregate support (#14030)

[Anssi Kääriäinen]

On Wednesday, December 25, 2013 5:52:10 PM UTC+2, Josh Smeaton wrote:
>
> So I've gone ahead and tried to remove SQLEvaluator by pushing its 
> functions down into ExpressionNode. For the most part, it's working well. I 
> rebased on akaariai/lookups_3 to make sure that any changes to lookups 
> would be reflected in this change as they are *somewhat* related. The diff 
> between lookups and my patch is below:
>
>
> https://github.com/jarshwah/django/compare/akaariai:lookups_3...aggregates-14030?expand=1
>
> There is still a lot missing (I haven't touched GIS yet), and some of the 
> tests are failing. I'm running tests against SQLITE and Postgres at the 
> moment, but I'll add in Oracle and MySQL once I've got something closer to 
> finished.
>
> I'm having some trouble with the test that is currently failing, and if 
> someone could point out where I'm going wrong that'd be awesome. 
> Specifically, ExpressionTests.test_filter() is failing on updates spanning 
> relationships (line 
> 179).
>  
> The problem is that relabeled_clone isn't being called or used at the 
> appropriate time. I did some debugging, and I *think* that 
> Lookup.process_rhs() is being called before Lookup.relabeled_clone(), which 
> results in the ExpressionNode using the incorrect alias. I assume this is a 
> problem with how I've refactored ExpressionNode since the same tests pass 
> when I checkout lookups_3. ExpressionNode.relabeled_clone is called, but 
> after the SQL has already been generated. Should I be providing a method or 
> attribute for Lookup to inspect maybe?
>
>
To me it seems the problem is in the relabeled_clone method. The children 
are relabeled_clone()'d, but the return value (the relabeled clone) is just 
discarded.

In addition avoid defining custom __deepcopy__. Instead you could 
copy.copy() self in start, and then alter self's mutable values manually.

I'd appreciate some feedback on the patch as it stands too if possible. I 
> think this is the right direction to head towards, as it simplifies the 
> existing F() evaluation, and should allow a straightforward implementation 
> of Aggregates on top. I'll be away until the 2nd of January, but will pick 
> this up again then.
>

I have always found the F() -> SQLEvaluator way of producing SQL limiting 
and confusing, so +1 from me for getting rid of that.

The idea of F() evaluated by SQLEvaluator (or models.aggregates evaluated 
by models.sql.aggregates) is that this deduplicates the user facing API 
from the implementation. This is needed if you have custom Query class (for 
example for nonrelational engine).

The implementation (that is, SQLEvaluator) is used in two stages. First, 
when adding the Expression to the query and then when compiling the actual 
query string. If you need to customize how Expressions are added to the 
query, then it means you have a custom Query class. That again means that 
you can wrap the F()/Aggregate object in any way you like, as you control 
the Query object. For the second part the new query expression API offers 
you a direct way to alter query string compilation for different backends 
(see add_implementation() in 
https://github.com/django/django/pull/2019/files#diff-986a7aa3149cc32d19b751d7ab166082R222).

So, I think we should be safe as far as feature parity goes. If the new way 
of writing expressions is actually better for non-sql backend support isn't 
clear to me. I just haven't worked with non-SQL backends enough to say.

The big problem is that if we drop the SQLEvaluator and similarly the 
models/aggregates.py <-> models/sql/aggregates.py ways of writing 
Expressions and Aggregates, then there will be a lot of broken 3rd party 
aggregates and expressions. Even if the APIs are private I am not willing 
to just drop the old way. So, some backwards compatibility is required.

 - Anssi

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/f2e215f2-1acb-4cf6-8e5c-70e136ff5fe2%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.