Re: GSOC 2015 project ideas suggestion

2015-03-26 Thread Tim Graham
It still doesn't interest me enough to provide any additional feedback.

On Thursday, March 26, 2015 at 1:20:42 AM UTC-4, Asif Saifuddin wrote:
>
> Hi,
>
> I have been updating my proposal and as the deadline is friday Your 
> feedback will help me to make it better in technical point of view
>
> https://gist.github.com/auvipy/1da0d96f826bd8da4d47
>
> Regards
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/451a2779-5cc5-4a8f-9a47-e84b19e4b60f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Pre-DEP: community support of unmaintained versions of Django

2015-03-26 Thread Christian Hammond
Hi Carl, James,

Sorry for the late reply on this. I've been unavailable the past week.

I know you guys are still sorting out how you want to run this, but I 
wanted to let you know that, given our current dependence on Python 2.6, 
I'm willing to do what's needed to maintain security backports for either 
an official or unofficial fork.

I'd love to know some further thoughts on the logistics for this. Things 
like how versioning would work, what you'd need from me, what kind of 
timeframes we'd have to work with, any legalese needed to be notified of 
security issues, etc.

Thanks!

Christian


On Friday, March 20, 2015 at 10:02:40 AM UTC-7, Carl Meyer wrote:
>
> Hi James, 
>
> Thanks for taking the time to write this up carefully, research the 
> history, etc. I think some form of extended community-based support 
> could work, but I have some concerns about your specific proposal; 
> mostly, that it places too much of the responsibility with the core team. 
>
> My feeling is that we don't really need a DEP or this much process 
> specified at this point; it'd be plenty for now to simply express 
> guarded openness to the idea of extended community maintenance for 1.6 
> and/or 1.4 and see if anyone actually steps up to do the work. 
>
> I'm also curious how this sounds to Christian and Stephen, who asked for 
> the extended support on django-users. Since they're the only ones who 
> have asked, if a proposal along these lines won't work for their cases, 
> then there's not much point in going forward with it. 
>
> Comments interspersed: 
>
> On 03/19/2015 04:59 PM, James Bennett wrote: 
> > There's been some recent discussion in a django-users thread[1] about 
> > the impending end-of-life of Django 1.6, which in turn will mean 
> > end-of-life for Django supported on Python 2.6. In addition, the 
> > end-of-life of the current LTS release, Django 1.4, will mean 
> > end-of-life for Django supported on Python 2.5. The following is a 
> > draft of a proposal based on ideas raised in that thread; it should be 
> > considered pre-DEP status, to be elevated to a DEP submission if there 
> > is sufficient support. 
> > 
> > 
> > Abstract 
> >  
> > 
> > The support process for older versions of Django is changed, as 
> > follows: 
> > 
> > * Official support for older versions of Django from the Django core 
> >   team will continue to end at the scheduled times (i.e., upon release 
> >   of a new minor version for non-LTS releases, at end of advertised 
> >   support lifetime for LTS releases). 
> > 
> > * Unofficial support, by persons willing to volunteer their time, will 
> >   be permitted through a secondary code repository existing solely to 
> >   provide this support. 
>
> "Permitted" sounds odd to me, since regardless of this DEP I don't think 
> the core team is in a position to forbid anyone else from continuing to 
> patch older Django releases if they want to. (I suppose if we really 
> wanted to we could prevent them from using the Django trademark to 
> describe what they are doing, but IANAL.) 
>
> I'm also not convinced we should provide a special repo under the 
> django/ org for this. That doesn't bring any technical benefits, just 
> social ones (perception of "officialness"). And I'm not clear that 
> perception of officialness is a good thing - after all, this support is 
> unofficial. So I would lean towards saying that this concept should be 
> well-proven in a third-party repo (created by whoever is doing the work) 
> before we even consider a django/ repo for it. 
>
> > * As the official end-of-life of each Django version approaches, the 
> >   Django core team will solicit proposals and volunteers to provide 
> >   unofficial support for that version past its official end-of-life, 
> >   and select maintainer(s) from amongst those volunteers. This support 
> >   will be known as "community maintenance". 
>
> This is my strongest objection to the proposal. This whole scheme will 
> only work if the community maintainer is highly motivated, and there's a 
> strong need for the extended community maintenance for a specific 
> release. One indicator of both is that the initiative comes unsolicited 
> from the community. I think it makes sense to clarify our general 
> openness to such initiative, but I'm opposed to adding an additional 
> responsibility to the core team's plate to "solicit proposals and 
> volunteers" for community maintenance of every release that hits EOL. 
>
> > Rationale 
> > - 
> > 
> > For the past five years, Django has been in the process of deprecating 
> > support for older 2.x release of Python, as part of a plan to move 
> > Django toward, first, compatibility with both Python 2 and Python 3 
> > (completed as of Django 1.6), and ultimately with only Python 3 (in a 
> > future, to-be-determined, release). 
> > 
> > The timeline for this was as follows: 
> > 
> > * May 2010: Django 1.2 instituted a minimum Python version of 2.4. 
> > 
> > 

Re: GSoC 2015: Improved URL Pattern Matching (Draft)

2015-03-26 Thread Aymeric Augustin
Hi Alexander,

I won’t repeat what Russell said, just add a few things.

A few months ago I had a use case for internationalization that looked pretty 
simple but turned out to be tricky to implement: 
https://github.com/oscaro/django-o18n . 
Resolving is easy, the hard part is reversing. Perhaps you could check that 
your design allows implementing this pattern without monkey-patching.

The API you’re proposing for patterns cannot work because it’s a “SyntaxError: 
non-keyword arg after keyword arg”. You’ll have to find something else.

Your milestone 3 shouldn’t take more than a few days once milestones 1 and 2 
are in. However it’s good to have some padding for unforeseen complications :-)

-- 
Aymeric.



> On 26 mars 2015, at 00:03, Alexander Patel 
>  wrote:
> 
> Hello, all, 
> My name is Alex Patel, and I am an undegraduate at Harvard College in the 
> United States studying mathematics and philosophy. I intend to submit a 
> proposal to work on Django's URL dispatch mechanism for this year's Google 
> Summer of Code, and am posting to solicit any feedback, comments, or concerns 
> before I submit the final proposal on Friday. 
> I've included the abstract to the draft of my proposal below:
> Abstract
> Django features a powerful and complete URL dispatching mechanism, defined in 
> django.core.urlresolvers, that uses regular expression pattern matching to 
> map requested URLs to views with speed and reliability. Having not been 
> subject to significant changes since the beginning of the project's 
> development, however, this tool has not been updated to reflect the 
> extensibility, flexibility, and ease of development at the core of Django's 
> philosophy. For example, it is not possible for developers to specify a 
> non-regex based resolver for a URL configuration, nor is there a standardized 
> way to extend the current resolver to support common patterns or alternative 
> pattern syntaxes to simplify the process of easily writing pretty URLs.
> 
> The primary objective of this project is to formalize a public-facing API to 
> support the use of alternative URL resolving mechanisms. This will involve 
> substantial refactoring and abstraction of the current URL resolution 
> mechanism, which suffers from a tight coupling of internal components and 
> little documentation for quick extension by developers. Further, it will 
> involve reincorporating Django's regex-based RegexURLResolver as the default 
> resolving mechanism, the performance and backwards compatibility of which 
> must be thoroughly analysed and tested. Finally, the project aims to 
> incentivize developers to create and release alternative URL resolvers 
> compliant with the new API through outreach efforts and a proof-of-concept 
> alternative resolving mechanism.
> 
> You can find a link to the full draft as a Github Gist here 
> .
> The deadline for GSoC is this Friday at 19:00 UTC. Any feedback before then 
> would be greatly appreciated. Thanks a ton!
> Best, 
> Alex
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers (Contributions to Django itself)" 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/e45c8521-bacb-448f-9231-34452e89439b%40googlegroups.com
>  
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/4585945D-3302-4F34-A39D-DED04F7B8F29%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.


Re: GSoC 2015: Improved URL Pattern Matching (Draft)

2015-03-26 Thread Alexander Patel
Russ - 

Thanks a ton for the feedback. I really appreciate you taking the time to 
look over my proposal. 

On Wednesday, March 25, 2015 at 11:11:02 PM UTC-4, Russell Keith-Magee 
wrote:
>
> Hi Alex,
>
> On Thu, Mar 26, 2015 at 7:03 AM, Alexander Patel <
> alexand...@college.harvard.edu > wrote:
>
>> Hello, all, 
>> My name is Alex Patel, and I am an undegraduate at Harvard College in the 
>> United States studying mathematics and philosophy. I intend to submit a 
>> proposal to work on Django's URL dispatch mechanism for this year's Google 
>> Summer of Code, and am posting to solicit any feedback, comments, or 
>> concerns before I submit the final proposal on Friday. 
>> I've included the abstract to the draft of my proposal below:
>> *Abstract*
>>
>> Django features a powerful and complete URL dispatching mechanism, 
>> defined in django.core.urlresolvers, that uses regular expression 
>> pattern matching to map requested URLs to views with speed and reliability. 
>> Having not been subject to significant changes since the beginning of the 
>> project's development, however, this tool has not been updated to reflect 
>> the extensibility, flexibility, and ease of development at the core of 
>> Django's philosophy. For example, it is not possible for developers to 
>> specify a non-regex based resolver for a URL configuration, nor is there a 
>> standardized way to extend the current resolver to support common patterns 
>> or alternative pattern syntaxes to simplify the process of easily writing 
>> pretty URLs. 
>>
>> The primary objective of this project is to formalize a public-facing API 
>> to support the use of alternative URL resolving mechanisms. This will 
>> involve substantial refactoring and abstraction of the current URL 
>> resolution mechanism, which suffers from a tight coupling of internal 
>> components and little documentation for quick extension by developers. 
>> Further, it will involve reincorporating Django's regex-based 
>> RegexURLResolver as the default resolving mechanism, the performance and 
>> backwards compatibility of which must be thoroughly analysed and tested. 
>> Finally, the project aims to incentivize developers to create and release 
>> alternative URL resolvers compliant with the new API through outreach 
>> efforts and a proof-of-concept alternative resolving mechanism.
>> You can find a link to the full draft as a Github Gist here 
>> .
>> The deadline for GSoC is this Friday at 19:00 UTC. Any feedback before 
>> then would be greatly appreciated. Thanks a ton!
>>
>
> Thanks for sending in a proposal. The proposal itself is strong - I've got 
> some questions about API design choices, but they're more in the realm of 
> "design details that need to be sorted out", rather than "fundamental 
> flaws/weaknesses in your proposal". Design details notwithstanding, the 
> timeline seems well thought out and achievable; the milestones you've 
> proposed are good targets against which we can evaluate your progress.
>
> The only thing I'd flag as a potential weakness (and it's not a critical 
> flaw) is the item in week 1-2 to formalise the specification. The wheels of 
> Django move slowly - I wouldn't expect any non-trivial design discussion to 
> come to a firm resolution in 2 weeks. This is an area where you'll need to 
> start early, possibly before the formal GSoC period.
>
> It's also an area where having a working example will make the discussion 
> a lot more compelling. In practice, much of the "real" discussion will 
> probably happen near the end of your proposal when you've got something 
> ready to merge, rather than in the abstract design phase.
>

Definitely noted. I think that both prepending more time onto the design 
phase before the formal GSoC period and reworking the timeline to permit 
more time for feedback are necessary. 
 
>
>
> Yours,
> Russ Magee %-)
>
>
> Broadly, I think the design you've proposed is workable. However, I've got 
> two suggestions - or rather, design considerations that I don't know if 
> you've given any thought to. Both come in the form of end use cases that 
> ideally would be possible as a result of your refactoring.
>
 

>
> Firstly, it should be possible to define a URL dispatcher that takes into 
> account the *domain*, as well as the URL. For example, I want my main 
> example.com website to be a landing and sales page, but with login 
> capability; but I want .example.com to be a user-specific site. 
> This is possible to do right now with some ROOT_URLCONF trickery and some 
> little known Middlware details, but there's no reason it should be part of 
> the main capability of URLConf - if only because it would be nice for 
> reverse to be able to return the subdomain when necessary.
>

It seems that the most stable way to support this would be to have the 
handler pass both the path and the subdomain prefix, if not just 
request.get_full_path() (in some 

Re: Help needed with Oracle GIS backend

2015-03-26 Thread Shai Berger
Hi Jani.

On Wednesday 25 March 2015 09:58:00 Jani Tiainen wrote:
> 
> We're still running Oracle and GIS. Though we do have built custom
> backend based on Django GIS backend - mainly to have support for
> Oracle XE, 3D functionality and in general to make it faster.
> 
> It's currently closed source but we're working on to open source it
> in hope that it could interest more wider audience (mainly because it
> would enable GIS use with free Oracle XE).
> 
That is good news. I would like to draw your attention to 
https://code.djangoproject.com/ticket/21273 where a partial attempt was 
already made to add GIS/Oracle-XE support.

Thanks,
Shai.


Re: Help needed with Oracle GIS backend

2015-03-26 Thread Tim Graham
Before the fellowship started, I worked a bit on Oracle GIS to fix it up 
and get its tests passing, but I'm unsure if I should continue to try to do 
so as part of my duties in the absence of anyone else stepping up. Clearly 
if no one uses this backend, it's wasted effort. Should we try advertising 
through other channels? Maybe the members of the technical board could 
offer some guidance on this as I'd not like to make the decision about 
dropping support unilaterally. I realize 2 weeks is not much time to 
solicit feedback, but Claude's patch is a big one, and I'd like it not to 
go stale.

On Wednesday, March 25, 2015 at 3:58:22 AM UTC-4, Jani Tiainen wrote:
>
> Hi, 
>
> We're still running Oracle and GIS. Though we do have built custom 
> backend based on Django GIS backend - mainly to have support for 
> Oracle XE, 3D functionality and in general to make it faster. 
>
> It's currently closed source but we're working on to open source it 
> in hope that it could interest more wider audience (mainly because it 
> would enable GIS use with free Oracle XE). 
>
> On Tue, 24 Mar 2015 04:48:38 -0700 (PDT) 
> Tim Graham  wrote: 
>
> > I also advertised this on the geodjango mailing list with the following 
> > message <
> https://groups.google.com/d/topic/geodjango/D_nL5W4vxmE/discussion> 
> > : 
> > 
> > Do we have any users of the Oracle GIS backend that have interest and 
> > ability to help maintain it? Claude has worked on several issues for 1.9 
> > that need to be completed on Oracle. If we cannot find help, then I 
> think 
> > we'll be forced to declare the Oracle GIS backend unmaintained and drop 
> > support for it. 
> > 
> > issues: 
> > * https://code.djangoproject.com/ticket/12400#comment:12 
> > * https://github.com/django/django/pull/4027 
> > 
> > On Monday, March 16, 2015 at 3:20:40 PM UTC-4, Claude Paroz wrote: 
> > > 
> > > Hi, 
> > > 
> > > In ticket #24214, I built a patch to replace all geo-specific Manager 
> > > methods by class-based ORM functions. This will allow us to get rid of 
> > > convoluted query code in the GeoDjango ORM. It will also be far much 
> easier 
> > > to add support for specific database functions. The code is already in 
> good 
> > > shape, however we are missing the Oracle part of the patch. I won't 
> work on 
> > > that part myself, that's why I'm here to ask for help with it from 
> anyone 
> > > which is a bit familiar with the Oracle GIS backend. Help much 
> appreciated! 
> > > 
> > > https://code.djangoproject.com/ticket/24214 
> > > 
> > > Claude 
> > > 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups "Django developers  (Contributions to Django itself)" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an email to django-develop...@googlegroups.com . 
> > To post to this group, send email to django-d...@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/9a43a6d2-eec9-4518-afc3-0d3d0b4e5bef%40googlegroups.com.
>  
>
> > For more options, visit https://groups.google.com/d/optout. 
>
>
> -- 
> Jani Tiainen 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/f758b58d-47a0-41fe-a3ba-0f246173a463%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Two phase cleaning of models/forms

2015-03-26 Thread Marc Tamlyn
In particular it is worth noting the addition of form.add_error[1] in
Django 1.7 which makes long clean methods much nicer to handle.

[1]
https://docs.djangoproject.com/en/1.7/ref/forms/api/#django.forms.Form.add_error

On 25 March 2015 at 16:11, Carl Meyer  wrote:

> Hi Thomas,
>
> On 03/25/2015 03:37 AM, Thomas Güttler wrote:
> > Up to now the validation/cleaning of a attribute can not access the
> > value of an other attribute.
> >
> > The work around is to override the clean() method of the form/model.
> >
> > A team mate and I talked about it, and we asked ourself, if
> > a two phase cleaning would help here.
> >
> > Our idea:
> >
> >  - The first clean phase works like the current implementation
> >
> >  - The second clean phase is optional and does nothing except the user
> > implements it.
> >
> >  - In the second clean phase your are allowed to peek into
> >the results of the first clean phase.
> >The clean method for the second phase would need to get the other
> > values passed in.
> >
> >
> > I would like to have this on model level, not only for forms.
> >
> > Example:
> >
> > class Issue(models.Model):
> > state=models.CharField(choices=[('in_progress', 'In progress'),
> > ('wait_until_due_date', 'Wait until due date')])
> > due_date=models.DateField(null=True)
> >
> >
> > We want to implement this constraint:
> >
> >  - due date must be set, if the state is "wait_until_due_date".
> >  - due date must not be set, if state is different from
> > "wait_until_due_date".
> >
> > We know that we can use the clean() method of the model, but a field
> > based solution would
> > be more preferred.
>
> Why?
>
> > class Issue(models.Model):
> > state = models.CharField(choices=[('in_progress', 'In progress'),
> > ('wait_until_due_date', 'Wait until due date')])
> > due_date = models.DateField(null=True,
> > validators2=[check_state_and_due_date_match])
> >
> > def check_state_and_due_date_match(due_date, all_fields):
> > state = all_fields['state']
> > if due_date:
> > if state != 'wait_until_due_date':
> > raise ValidationError('If due date is set, state must be
> > "wait_until_due_date"')
> > return
> > if  state != 'wait_until_due_date':
> > raise  ValidationError('If no due date is set, state must be
> > "wait_until_due_date")
> >
> >
> > Open questions: I am unsure if this should be used only for validation,
> > or if it should be possible
> > to alter values, too.
> >
> > What do you think?
> >
> > Other solutions or improvements?
>
> I think this is unnecessary complexity to add to the validation process.
> There is nothing that this proposal makes possible that isn't already
> possible using the clean() method. In cases where the clean() method
> becomes too long or convoluted, you can break it up into smaller methods
> yourself.
>
> In fact, I would guess that your proposal could be entirely implemented
> on top of current Django, by overriding the clean() method to implement
> what you've outlined above.
>
> Carl
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers  (Contributions to Django itself)" 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/5512DE42.8000800%40oddbird.net
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/CAMwjO1Gnhfp3XkOwEgaqhjbTBzGTxF3uv7-dgDF9drMCmt_%3Dhg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Extending the URL Dispatcher (GSoC 2015 proposal)

2015-03-26 Thread Marten Kenbeek
I've updated my proposal with a few more changes. Specifically, I've added 
a small part about reversing namespaced urls without specifying the 
namespace. In some circumstances this can provide looser coupling between 
third-party apps and arbitrary, reversible objects. It can also ease the 
transition from non-namespaced urls to namespaced urls by providing an 
intermediate step where an url name can match both. This step is absolutely 
necessary if third-party apps want to switch to namespaced urls but also 
want to provide backwards compatibility with previous versions. 

Additionally, I've included a timeline. Not my strongest point, but I think 
it's a decent guideline of what I'll be working on during the project. 

The up-to-date proposal can be found 
at 
http://www.google-melange.com/gsoc/proposal/public/google/gsoc2015/knbk/5629499534213120.
 
Any additional feedback before (or after) the deadline is greatly 
appreciated. If something in the proposal is not clear, let me know and 
I'll try to explain it better in my proposal. 

There are still a few design decisions to make between now and the start of 
GSoC, but I'll probably create a separate thread for those. 

Thanks,
Marten

Op maandag 2 maart 2015 17:57:24 UTC+1 schreef Marten Kenbeek:
>
> Hey all,
>
> I'm working on a proposal to extend the URL dispatcher. Here, I'd like to 
> provide a quick overview of the features I propose. 
>
> I'd like to:
> - Allow matching based on request attributes such as the subdomain or 
> protocol, and business logic such as the existence of a database object.
> - Make middleware configurable for a subset of views. It should be easy to 
> add, reorder or replace middleware at any level in the (currently 
> recursive) matching algorithm. 
> - Provide conventions for common patterns, such as an easy-to-configure 
> URL router for all generic Model views. For generic views, this should be a 
> one-liner. For custom views and other non-default options, this should 
> still be relatively easy to configure compared to writing out all patterns. 
>
> In the process, I'd like to formalize some classes used in the dispatcher. 
> Currently, the RegexURLPattern and RegexURLResolver classes provide most of 
> the functionality of the URL dispatcher. By abstracting these classes, and 
> factoring out the loading mechanism and some other internals, I hope to 
> provide an extensible dispatching framework for third-party apps.
>
> The full, yet incomplete proposal can be found at 
> https://gist.github.com/knbk/325d415baa92094f1e93 if you want more 
> details. It currently contains a slightly more in-depth discussion of the 
> current dispatcher and the proposed features, and a start on the redesign 
> of the dispatcher. 
>
> I'm mostly looking for some feedback on the general direction of these 
> features, though any feedback is welcome. I'm still working on it, so 
> details might change based on new insights.
>
> Thanks,
> Marten
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/b0df1d73-5ce4-4417-85f5-214faca6c3fc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: improving debug logging in development

2015-03-26 Thread Collin Anderson
Hi All,

A little off topic, but here's what I do to generate "yellow" html 
tracebacks in production behind the scenes:

from django.views import debug
html = debug.ExceptionReporter(request, is_email=False, *sys.exc_info()).
get_traceback_html()

Though, I do that within the got_request_exception signal; not sure if it 
would work in the logging framework.

Collin

On Thursday, March 26, 2015 at 5:58:43 AM UTC-4, HM wrote:
>
> What about the yellow 500 error-page when in debug-mode? I'd like to have 
> a copy of the complete thing *somewhere* now that what's sent by email is 
> sanitized. Cloning a running system, turning DEBUG on and attempting to 
> trigger the same error isn't always easy. Is the 500-data loggable at all?
>
> On 24 March 2015 at 03:18, Aron Griffis  > wrote:
>
>> On Mon, 2015-03-23 at 19:16 -0600, Carl Meyer wrote:
>> > And it still seems to me that it's bad for Django's default config to
>> > set `level: ERROR` and `propagate: False` on the django.request and
>> > django.security loggers, as that prevents those logs from propagating to
>> > higher-level handlers someone may want to install.
>>
>> My fix for this has been the following snippet in settings.py:
>>
>> # The DEFAULT_LOGGING dict is unhelpful and resides even with
>> # disable_existing_loggers=True. This prevents propagation to the root
>> # logger for loggers defined in DEFAULT_LOGGING.
>> from django.utils.log import DEFAULT_LOGGING
>> DEFAULT_LOGGING['loggers'] = {}
>>
>> -Aron
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers  (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@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/1427163497.27346.3.camel%40arongriffis.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/9d3d774b-edf3-4716-a79c-072b2313fff8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: improving debug logging in development

2015-03-26 Thread Hanne Moa
What about the yellow 500 error-page when in debug-mode? I'd like to have a
copy of the complete thing *somewhere* now that what's sent by email is
sanitized. Cloning a running system, turning DEBUG on and attempting to
trigger the same error isn't always easy. Is the 500-data loggable at all?

On 24 March 2015 at 03:18, Aron Griffis  wrote:

> On Mon, 2015-03-23 at 19:16 -0600, Carl Meyer wrote:
> > And it still seems to me that it's bad for Django's default config to
> > set `level: ERROR` and `propagate: False` on the django.request and
> > django.security loggers, as that prevents those logs from propagating to
> > higher-level handlers someone may want to install.
>
> My fix for this has been the following snippet in settings.py:
>
> # The DEFAULT_LOGGING dict is unhelpful and resides even with
> # disable_existing_loggers=True. This prevents propagation to the root
> # logger for loggers defined in DEFAULT_LOGGING.
> from django.utils.log import DEFAULT_LOGGING
> DEFAULT_LOGGING['loggers'] = {}
>
> -Aron
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers  (Contributions to Django itself)" 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/1427163497.27346.3.camel%40arongriffis.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/CACQ%3DrrdpDkRP_oO3OrE2rakvXbXpWw77Mewov%2B2nsRFg8WZ%3DjQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.