Re: Logging config tries too hard

> > It sounds like you are maybe proposing to decide whether to pre-initialize > logging with the built-in default config or not based on whether the user's > LOGGING setting has disable_existing_loggers set to True or False? > Yes, I was thinking on my feet and this was one idea I came up with

Re: Logging config tries too hard

oggers` is explicitly set to False, then we could initialize them as we do now. How does that sound? On Tuesday, September 6, 2016 at 5:44:37 PM UTC-7, Carl Meyer wrote: > > On 09/06/2016 04:57 PM, Ivan Sagalaev wrote: > > I'm > > talking about this function: > > https

Re: Logging config tries too hard

> > Just to be sure, which version of Django are you using? There were some > simplifications in Django 1.9 that attempted to make writing custom logging > configurations easier and further changes in Django 1.10. > I'm using 1.9, but I'm referring to the code in master. > > https://github.

Re: Logging config tries too hard

> > It’s unclear to me as well how the current system is intended to be used. > I can speculate, that the idea was that you *can* disable the existing loggers and define your own, but the effect of it actually disabling all logging from Django instead of it falling through to the custom root lo

Logging config tries too hard

Hello everyone, It's been a while since I last posted here, please forgive if I break any new rules inadvertently. I'd like to revisit a decision made in [18993][]. My use case is very simple and obvious: I want all logging going into stdout. As currently implemented, I can't do it easily with

Re: __getattr__ on SimpleTemplateResponse causes problems

Though the patch in the ticket does solve the problem I completely agree with removing the code altogether… I'm not a fan of "helpfully" reformulating exceptions while trying to be more specific. In practice it hurts more than it helps, and this case is just another confirmation. -- You receiv

Re: RFC: new backports policy

On 04/19/2011 02:35 PM, Daniel Moisset wrote: I'm using 1.3 in production and there's a bugfix I really want, so I do the backport (and write the code, tests, docs). If I submit this to the issue tracker, is there a chance my patch will get into the next minor release, or you won't even consider

Re: #14891, a.k.a. "related managers don't work how we claim they do"

On 04/18/2011 02:59 PM, Carl Meyer wrote: Hmm. Why does it make sense for OneToOneField lookups to behave differently from *_set managers? If I've got a default manager that hides "deleted" objects, for instance: why should deleted objects by default "not exist" when I traverse a reverse FK, but

Re: Accidental logging disabling

On 04/18/2011 08:25 AM, Carl Meyer wrote: FWIW, I don't think changing settings in general to be non-lazy is an option - it will suddenly make a bunch of parts of Django dependent on DJANGO_SETTINGS_MODULE at import time, where currently they only require it at runtime (and even then perhaps only

Re: #14891, a.k.a. "related managers don't work how we claim they do"

On 04/18/2011 11:45 AM, Johannes Dollinger wrote: I'd vote for (C). Deprecate `use_for_related_fields` and always use the default manager for related managers. Then add the possibility to specify custom mangers for individual relations: ForeignKey(Foo, related_manager=RSpecialManager)

Re: #14891, a.k.a. "related managers don't work how we claim they do"

On 04/18/2011 11:16 AM, Carl Meyer wrote: By "just this" I presume you actually mean just the second half of what you quoted ("explicitly set to False")? In other words, you're proposing to make use_for_related_fields work as advertised, but make it default to True instead of False? Not exactly

Re: #14891, a.k.a. "related managers don't work how we claim they do"

On 04/16/2011 04:30 PM, Carl Meyer wrote: in general, related-object access for reverse-FKs and M2Ms, contrary to the documentation, will _always_ use your default manager (actually, a dynamic subclass of it) It kind of makes sense. You don't want your deleted items to appear in results just b

Re: Accidental logging disabling

On 04/15/2011 02:20 AM, akaariai wrote: I have been using setup_environ in my projects, and the lazy initialization in can cause some weird problems, for example if you do manual timing using: start = datetime.now() access settings print 'Used %s' % (datetime.now() - start) You might get weird r

Accidental logging disabling

Hello everyone! I've found a (may be minor) bug with logging and I'm not sure how it can be fixed. Here's a stripped-down example showing the problem: The settings.py simply configures a single root logger: DEBUG = True DATABASES = { 'default': { 'engine': 'django.

Re: HttpRequest.read() issues

Graham Dumpleton: Silly question. Where is the proof that using a limited stream is a performance issue? Last night I actually did test it :-). You're right the difference in performance is less than a statistical deviation between different uploads over network. Tom Christie: Even so, presum

Re: HttpRequest.read() issues

On 04/03/2011 07:03 AM, Tom Christie wrote: It's not very obvious from the docs or source if HttpRequest.read() can always be safely treated as a limited input stream, or if the developer needs to respect HttpRequest.META['CONTENT_LENGTH']. As far as I can tell the intention is that it can alway

Re: Homogenization of User and UserProfile

On 03/18/2011 07:22 AM, Carl Meyer wrote: Don't use AUTH_PROFILE_MODULE or .get_profile(). As far as I'm concerned they bring almost nothing to the table except for the "there can be only one" restriction +1 Just use OneToOneField and the regular ORM access descriptors, and you can have as ma

Re: Homogenization of User and UserProfile

On 03/15/2011 01:49 PM, Michael A. Ryan wrote: In a typical client app, your User object is most likely one robust object which you have to express in Django as both User and UserProfile. It's kind of hard to talk about "typical" Django app because there are so many different of them :-). Howe

Re: Opinions on #15012 -- cache_page and TemplateResponse incompatibilities

Hi Russell, I seem to missed this email until lately… Here's my take on it if it still matters. On 01/05/2011 08:29 AM, Russell Keith-Magee wrote: 4) Modify cache_page to force a render of the response. This defeats the purpose of introducing TemplateResponse, and would mean that template r

Re: Fetching results of a query set

On 12/12/2010 06:45 AM, Alex Gaynor wrote: Yes, if you're using iterator you'll have Django storing 100 items at a time. That being said I believe I read that some of the database wrappers do their own caching (it's either mysqldb or psycopg2, I dont' remember which). They both do. They have t

Re: RFC: #12815/#12816 -- TemplateResponse and render() shortcut

On 12/01/2010 05:05 PM, Łukasz Rekucki wrote: from django.conf import settings def without_localization(view): @wraps(view): def decorated(*args, **kwargs): # NOTE: I'm assuming this will actually have any effect - settings caching is a different issue old_value, sett

Re: RFC: #12815/#12816 -- TemplateResponse and render() shortcut

On 12/01/2010 04:26 PM, Łukasz Rekucki wrote: What about view decorators? I don't want to invent use cases here, but if I right now have a view decorator that on it's way out changes something that could alter how a template is rendered (like current language, some settings or the database conte

Re: RFC: #12815/#12816 -- TemplateResponse and render() shortcut

On 12/01/2010 02:52 PM, Łukasz Rekucki wrote: Lots of people find render_to_response so verbose, that they are using direct_to_template() view instead. Django 1.3 deprecates that one, so it would be fair to offer those people a replacement. Forcing them at the same time into the world of lazy bak

Re: RFC: #12815/#12816 -- TemplateResponse and render() shortcut

On 12/01/2010 01:03 PM, Russell Keith-Magee wrote: I'd argue it doesn't simplify anything. It saves you a grand total of 10 characters (plus a couple more on import), but at the cost of the added complexity of having two ways of doing *exactly* the same thing. There is also a loss of explicitness

Re: .limit() on a QuerySet

On 11/29/2010 11:31 PM, Christophe Pettus wrote: Before I put any work into this, I want to know if (a) I'm missing something super-obvious in the QuerySet functionality, or (b) this idea has already been explored and rejected. Hi Christophe, Looks like you're indeed missing queryset slicing

Re: RFC: #12815/#12816 -- TemplateResponse and render() shortcut

On 11/29/2010 02:58 PM, Russell Keith-Magee wrote: My counterargument would be this -- if you use TemplateResponse, there's no need to use a shortcut at all. Yes, this is what I understood from your reasoning. I'm concerned more with documentation. Namely, what are we going to suggest for usag

Re: RFC: #12815/#12816 -- TemplateResponse and render() shortcut

On 11/28/2010 10:13 AM, Russell Keith-Magee wrote: For your consideration, I present a patch to resolve #12815 and #12816, adding a TemplateResponse and a render() shortcut. Thank you! - The render() shortcut doesn't use TemplateResponse. Since render() and TemplateReponse() have exactly th

Re: Gentle Proposal: add 'render' shortcut in 1.3

On 11/02/2010 05:27 PM, Mikhail Korobov wrote: I'm quite busy now and don't think I'll be able to make the patch ready by 1.3 alpha 1. Full feature freeze is expected only by the time of beta so I don't think it's absolutely necessary to push it before alpha 1. Anyway since I care very much

Re: Django/CherryPy problem with POST data

On 11/01/2010 11:21 AM, Mark wrote: Ticket #14594 From a quick look it can be fixed in two ways: - HttpRequest.raw_post_data can always explicitly ask for content_length bytes. If content_length is absent just treat it as 0. - WSGIRequest can wra

Re: Django/CherryPy problem with POST data

On 11/01/2010 08:44 AM, Russell Keith-Magee wrote: The only changes I'm aware of making were related to getting readline() to behave correctly. The patch as submitted didn't return the right values for the readline(len) case. Which call to read() are you saying is wrong? Sorry, my memory has fa

Re: Django/CherryPy problem with POST data

On 11/01/2010 03:06 AM, Russell Keith-Magee wrote: Sounds like a ticket is called for. Mark, can you also CC: me ('isagalaev') on this ticket. I have an idea where it can be broken. I remember that the initial patch was always passing a `size` parameter into .read() of the underlying stream

Re: Gentle Proposal: add 'render' shortcut in 1.3

On 10/30/2010 10:47 PM, SmileyChris wrote: It seems a simple enough proposal that trying to access the content property would raise an error until it is explicitly baked. Problem solved. True. I seem to somehow missed it between the lines. Thanks! I'm +1 on it by the way. -- You received thi

Re: Gentle Proposal: add 'render' shortcut in 1.3

On 10/29/2010 09:38 PM, Carl Meyer wrote: Seems that a template-response-middleware might reasonably want to look at some other response data (headers? or simply extra annotation attributes?) in order to make decisions about what to do. You right. And it's not feasible (or beautiful) to just ri

Re: Gentle Proposal: add 'render' shortcut in 1.3

On 10/29/2010 09:58 AM, Russell Keith-Magee wrote: I agree that it's important to treat people as grown ups. However, this is something that is trivial to do by accident -- for example, printing response.content would be an obvious debug step -- and it will be a non-trivial thing to identify that

Re: Gentle Proposal: add 'render' shortcut in 1.3

Russel: Wouldn't it make sense to put a flag on the TemplateResponse that prohibits accidental baking? Mikhail: So maybe it will be better not to make bake/force_bake public so that users won't be able to shoot themselves in the foot? I don't think it's doable at all. People still can call a

Re: Gentle Proposal: add 'render' shortcut in 1.3

On 10/28/2010 12:24 PM, Mikhail Korobov wrote: The request handling code have to be put into WSGIHandler and into ModPythonHandler so I'll wait until the patch for http://code.djangoproject.com/ticket/9886 will be landed. I'd say it's even worth to wait for http://code.djangoproject.com/ticke

Re: Gentle Proposal: add 'render' shortcut in 1.3

On 10/27/2010 04:55 PM, Mikhail Korobov wrote: 1. 'Border' middleware is a backwards-compatible change, the requirement to bake response in middleware isn't. The difference is only that you propose to execute 'bake' in the end of response cycle and I propose to execute it at the beginning of the

Re: Gentle Proposal: add 'render' shortcut in 1.3

On 10/25/2010 04:33 PM, Russell Keith-Magee wrote: * The problem with messages is a big one -- probably even a show-stopper if we can't find a way to reconcile the general use case that it represents (i.e., we don't just need a fix for contrib.messages -- we need to explain how/why the problem

Re: Gentle Proposal: add 'render' shortcut in 1.3

Hi Russel, On 10/22/2010 05:20 AM, Russell Keith-Magee wrote: Jacob has already marked #9886 RFC, and on first inspection, the patch looks good to me too; I want to have a closer look before I commit, though. If you want to proceed assuming that #9886 will be committed (i.e., make the fix for #1

Re: Gentle Proposal: add 'render' shortcut in 1.3

On 10/21/2010 03:22 PM, Ivan Sagalaev wrote: On 10/21/2010 11:49 AM, Mikhail Korobov wrote: 2. Does TemplateResponse allow pretty exception pages or not? Is Ben's issue resolved? I'll look into it this evening (MSD). So I did. There are actually two problems: - Exceptions i

Re: Gentle Proposal: add 'render' shortcut in 1.3

On 10/21/2010 11:49 AM, Mikhail Korobov wrote: 2. Does TemplateResponse allow pretty exception pages or not? Is Ben's issue resolved? I'll look into it this evening (MSD). -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this g

Re: Gentle Proposal: add 'render' shortcut in 1.3

On 10/21/2010 11:10 AM, James Bennett wrote: Django cares about whether your views meet the following criteria: 1. Is a callable object. 2. When called, accepts an instance of HttpRequest as its first positional argument. 3. When called, returns an instance of HttpResponse or raises an exception

Re: Gentle Proposal: add 'render' shortcut in 1.3

On 10/21/2010 01:39 AM, Mikhail Korobov wrote: 1. Developer writes a view and want to reuse it (e.g. change the context). My assumptions was: a) Class based views are now the recommended way to write reusable views This is where our views differ. I have to admit that I didn't follow closely t

Re: Gentle Proposal: add 'render' shortcut in 1.3

On 10/20/2010 11:51 PM, Mikhail Korobov wrote: #12815 is about introducing TemplateResponse. Is the patch with 'render' shortcut returning just HttpResponse acceptable? I think that TemplateResponse is less useful after class-based views make their way into trunk so 'render' shortcut shouldn't bo

Re: Refactoring and file-like interface for HttpRequest

On 10/02/2010 01:54 AM, Jacob Kaplan-Moss wrote: On Fri, Oct 1, 2010 at 4:46 PM, Ivan Sagalaev wrote: During a sprint before 1.2 I was proposing to commit my ticket [9886] that deals with adding a .read() method to HttpRequest. Adrian suggested that it was too late then and it's bett

Refactoring and file-like interface for HttpRequest

Hello everyone! During a sprint before 1.2 I was proposing to commit my ticket [9886] that deals with adding a .read() method to HttpRequest. Adrian suggested that it was too late then and it's better to bring it up during 1.3 cycle. So here it is. Basic summary of changes is in the first co

Re: ANN: Improving our decision-making and committer process

On 09/30/2010 01:22 PM, Russell Keith-Magee wrote: So, let me be clear on what you're proposing: you acknowledge that the triage process is backlogged. Your proposal is to put extra workload onto the core team - the one group that is already a bottleneck in the process. Pretty much. I just don'

Re: ANN: Improving our decision-making and committer process

On 09/30/2010 03:46 AM, Russell Keith-Magee wrote: Accepted tickets can be: * Purely accepted, indicating that someone has verified that the problem exists, but not how to solve it * Accepted with a patch that is wrong in some way (e.g., fixing the symptom, not the problem) * Accepted wi

Re: ANN: Improving our decision-making and committer process

On 09/30/2010 01:40 AM, Chuck Harmston wrote: In my world, the "accepted" status should only be used in one circumstance: when a person is actively developing under or maintaining a patch for the ticket. It's an indicator that someone has taken ownership of a ticket, to prevent duplication of eff

Re: ANN: Improving our decision-making and committer process

Hello Jacob and everyone. On 09/29/2010 09:59 PM, Jacob Kaplan-Moss wrote: Starting today, we're going to be making some minor but significant changes to the way the Django core committer team "does business." That's about time :-). Congratulations and thank you! I have a comment and a sugges

Re: #717 (If-Modified-Since checked for exact match) should be fixed

On 09/22/2010 12:13 PM, Luke Plant wrote: On Tue, 2010-09-21 at 11:40 -0700, julianb wrote: Uuh, so what's with this? Nothing happened with the ticket and no further comments here either... :( I accepted it on Trac, please see my comments there. Also, you mentioned about the 'condition decora

Re: Proposal: First-class WSGI support in Django 1.3 / twod.wsgi

On 05/26/2010 03:02 PM, Gustavo Narea wrote: Among many other things, one of the components alone provides solutions to some enterprise requirements for Django: * It’s now possible to run code at startup

Re: Proposal - ChoiceField.choices need to accept callable, not only list or tuple

George Karpenkov wrote: Given your experience, the chances are that you're right, however, I don't see any way how we can pass a generator which will not be called until the form class is instantiated. Why should a call matter? The body of the generator is not executed until first iteration at

Re: Proposal - ChoiceField.choices need to accept callable, not only list or tuple

George Karpenkov wrote: http://code.djangoproject.com/ticket/13181 I'm -1 on complicating it this way. The ability to pass a callable for choices is covered by passing a generator. Am I missing something? -- You received this message because you are subscribed to the Google Groups "Django d

Re: Backwards-incompat with CsrfViewMiddleware

James Bennett wrote: Perhaps that's why, in both the 1.2 alpha release notes and the draft for the final 1.2 notes, it's listed under a big heading titled "backwards-incompatible changes". As we say in Russia "Gee, I didn't notice the elephant" :-). I still think it would be useful to add an e

Re: Backwards-incompat with CsrfViewMiddleware

Luke Plant wrote: This case is slightly different because it is down to an interaction of a changed default setting with working code, but there will always be cases like that, and I think it is much better for developers to remember the general principle that they are responsible for whatever

Backwards-incompat with CsrfViewMiddleware

Hello everyone! A couple of days ago we've noticed a (potentially big) backwards incompatibility that can bite users upgrading from 1.1 to 1.2. CSRF doc encourages users to enable CsrfViewMiddleware that will check all POST requests for csrf_token and then suggests to alter all HTML forms to

Re: [Python-Dev] PEP 391 Acceptance - Thanks!

Vinay Sajip wrote: Guido, That's great - thanks very much! I'll get on with integrating the PEP 391 implementation into trunk right away, and it should be in good time for 2.7/3.2. Thank you for your efforts! -- You received this message because you are subscribed to the Google Groups "Django

Re: Feedback requested: Multi-db database routing

Russell Keith-Magee wrote: class MasterSlaveRouter(object): def db_for_read(self, model, db=None): # Point all read operations to a random slave return random.choice(['slave1','slave2']) def db_for_write(self, model, db=None): # Point all write operations to the m

Master/slave replication in multi-db era

Russell Keith-Magee wrote: There are some cases where this shouldn't happen - for example, in a master/slave setup. I'm tinkering with some code at the moment to control this sort of database allocation. Russel, can you share your ideas on the matter? I'm about to port (soon-ish) my replicatio

Re: Logging format decision

Russell Keith-Magee wrote: You've also defined a production server that uses just two loggers - exception and info - for the entire server. Again, this isn't especially realistic - in practice, you have a large number of fine grained loggers for different parts of the system. In fact, most of o

Re: Logging format decision

Russell Keith-Magee wrote: That said - I really do want to see logging in Django's trunk. If we can sort out the details in the background and get a good implementation ready, it could easily be the first feature committed for v1.3. Agreed! I like Vinay's suggestion for exactly the reason you

Re: Model validation incompatibility with existing Django idioms

Joseph Kocherhans wrote: # Run validation that was missed by the form. p.validate_fields(fields=['user', 'primary_contact']) p.validate_unique(fields=['user', 'primary_contact']) p.validate() Can this be shortcut to p.full_validate(fields=['u

Logging format decision

Hello everyone! There was a discussion here some time ago about logging in Django that led to the ticket 12012 [1] where Simon has done most (all?) of the implementation. There is still a disagreement on the format of the configuration dict for it. Simon has implemented it from my ad-hoc pro

Re: Model validation incompatibility with existing Django idioms

Tobias McNulty wrote: I don't see why model validation should be bound up with forms at all. I'm not the one who designed it, so it's just me view. I think this is just useful: if you have a code validating, say, a CharField at the model level why not reuse it at the form level? What's impo

Re: Model validation incompatibility with existing Django idioms

Tobias McNulty wrote: I regret and apologize that I'm arriving to this thread rather late. To support the tradition, I'm apoligizing for this too :-). Though it's funny how everyone thinks they're "late" on a couple-of-days-old thread :-). Anyway... I too would opt for an implementation tha

Re: idea for using RequestContext by default

Russell Keith-Magee wrote: > Certainly - and Simon made exactly this proposal during the review of > the CSRF work. Simon even provided a sample implementation: > > http://groups.google.com/group/django-developers/msg/b1b3f8854b9ae2b1 Thanks! I keep missing nice things on django-dev@ due to many

Re: idea for using RequestContext by default

Russell Keith-Magee wrote: > I'm in complete agreement with Simon on this point. I fail to see the > benefit of decorators in this context. I can see one valid point that "render_to" guys have. Which is, incidentally, has nothing to do with the decorator syntax. An HttpResponse with an opaque st

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

Alex Gaynor wrote: > Adding the ellepsis is as simple as: > > {{ foo|slice:":100" }}{% if foo|length > 100 %}...{% endif %} Come on Alex, in what universe it qualifies as "simple"?! -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post

Re: What do people think about the get_absolute_url proposal?

Mike Malone wrote: > In my opinion, using the Site module and settings files is damn > annoying. My point is that we better fix these annoyances than leave this way of doing things altogether. > I never use the Site module This is by itself is not the reason why it might be annoying. Django ac

Re: What do people think about the get_absolute_url proposal?

Michael Richardson wrote: > With these cases (the former more so than the latter) you are creating > URLs for an entirely separate project, not your own, essentially. Not "entirely separate". These are projects sharing much of the codebase, just having different SITE_ID in settings. Anyway there

Re: What do people think about the get_absolute_url proposal?

Mike Malone wrote: > Well, not really. It's making a way to generate a URL based on the > request object global. I agree that it's not ideal, but it's not the > same as just making the request object global. My main gripe is not globalness of a request object itself (I agree with "not ideal" here

Re: What do people think about the get_absolute_url proposal?

Mike Malone wrote: > On Tue, Dec 8, 2009 at 7:52 PM, Russell Keith-Magee > wrote: >> 4. I share Mike's concern about using settings.SITE_ID to determine >> the current host, but I'm not sure I have any suggestions on how we >> could practically use request, short of encouraging the use of a >> te

Re: Conventions around plugable backends

On topic, I'm +0 on class-based approach. There's actually one passage that reminded me of something that I consider a small wart in a couple of places in Django: Russell Keith-Magee wrote: > Module-based configuration: > --- > > * The aesthetic of user-configuration op

Re: Reversing URL for a view with namespaces

Ivan Sagalaev wrote: > Ahha! This is the catch I was missing. So in order for an app to place > itself generally in the "namespace-aware" category it should define a > function that will return a triple of (patterns, app_namespace, > instance_namespace) and document

Re: Reversing URL for a view with namespaces

Russell Keith-Magee wrote: > Apologies for taking so long to get back to you on this. No problem :-) Have busy schedule myself :-) > For this last case - building a new app that you want to be namespace > aware - I think the Django admin already implements the model that > needs to be followed h

Re: Reversing URL for a view with namespaces

Russell Keith-Magee wrote: > On the 'missing something' front, reverse() now takes a 'current_app' > argument that gives context to the app lookup, which resolves the > ambiguity from the point of view of the reverse() function. I saw this one. It doesn't work in this case exactly beacuse of this

Reversing URL for a view with namespaces

Hello! I've just stumbled upon a difficult to understand problem. I have an app that has an urlconf which is included in a project under a namespace: (r'^blog/', include('app.urls', namespace='blog')), This namespace allows things like {% url blog:article ... %} which is very nice. But

Re: #9886: HttpRequest refactoring

Russell Keith-Magee wrote: > Any complete feature is potentially a candidate for > v1.2 - as long as you can convince a core developer to look into the > ticket. This is what I'm trying to do, yes :-). The ticket is assigned to Malcolm (and in fact it was created after we talked with him if such

Re: #9886: HttpRequest refactoring

Jacob Kaplan-Moss wrote: > On Thu, Sep 17, 2009 at 10:09 AM, Ivan Sagalaev > wrote: >> Ticket [9886] is one of the things that I've been holding for 1.2 time >> frame to ask for some discussion since Jacob marked it DDN. > > At first glance, you need docs and

Re: Best place for code that processes stuff from settings.py once (for logging implementation)

Benjamin Slavin wrote: > * Logging may need to come even earlier. If you truly want to log > everything, you'll want to run that code first. Is it really the case that we want to log everything? I believe that logging after initialization is enough. And for my example of a logging handler that

Re: Proposal for 1.2: built-in logging with django.core.log

Vinay Sajip wrote: > We should provide a configure_logging(dict) utility function which > takes a dict in an agreed format (such as Ivan's suggestion). Then in > settings.py users can invoke configure_logging(LOGGING) after > defining the configuration right there, in settings.py itself, or > obt

Re: Proposal for 1.2: built-in logging with django.core.log

Sorry for taking a bit long to respond. Looks like we aren't disagree much anyway but I had to get some thoughts off my chest :-). Vinay Sajip wrote: > It's similar to Django's support for, say, simplejson. I think it's > reasonable for Django to alias WatchedFileHandler so that it's > available

Re: Proposal for 1.2: built-in logging with django.core.log

Ivan Sagalaev wrote: > Standard Python logging configuration has > a noticable gap between very simplistic basicConfig which configures > only a root channel and a verbose imperative definition of handler > objects, formatter objects and logger objects. Forgot one thing. As i

Re: Proposal for 1.2: built-in logging with django.core.log

Vinay Sajip wrote: > Actually you don't need much in settings.py, and Django doesn't need > to grow any code of its own to "wrap" logging. You can either > configure logging programmatically (for which I use basicConfig, in > simple setups) or using a configuration file (ConfigParser-based, > full

Re: #9886: HttpRequest refactoring

Jacob Kaplan-Moss wrote: > On Thu, Sep 17, 2009 at 10:09 AM, Ivan Sagalaev > wrote: >> Ticket [9886] is one of the things that I've been holding for 1.2 time >> frame to ask for some discussion since Jacob marked it DDN. > > At first glance, you need docs and

Re: #9886: HttpRequest refactoring

Ivan Sagalaev wrote: > This comment[1] in the ticket is a summary of what had changed. Thanks > for looking! Forgot to add... There's no docs & tests changes in the patch yet. I'll add them after the decision if this looks good at all. --~--~-~--~~~

#9886: HttpRequest refactoring

Hello everyone! Ticket [9886] is one of the things that I've been holding for 1.2 time frame to ask for some discussion since Jacob marked it DDN. This has started as a feature allowing to .read() directly from a request object. However this has lead to a rather nice refactoring removing a lo

Re: Proposal for 1.2: built-in logging with django.core.log

Hi Simon, Simon Willison wrote: > 1. We'll be able to de-emphasise the current default "e-mail all > errors to someone" behaviour, which doesn't scale at all well. In a recent thread[1] on a similar topic Russel has also emphasized that we should improve documentation about doing logging. > 3.

Re: Replacing get_absolute_url, I am against it

James Bennett wrote: > Except I can't help thinking this is an awfully arbitrary distinction > to draw. In effect you're saying that nearly every question about an > object should be answerable by interrogating it directly, *except* for > "what's a URL I can use for you?" May be I can explain thi

Re: Replacing get_absolute_url, I am against it

Zachary Voase wrote: > If you take a look, you’ll notice that URLObject, being a subclass of > unicode, can be used *directly* within the template and it'll render > out to the URL without any magic. Beware! Using the word "magic" too loosely may infuriate certain core devs and they will sta

Re: Replacing get_absolute_url, I am against it

Jacob Kaplan-Moss wrote: >>> schema, domain, path, query, fragment = urlsplit(obj.url()) > > That's not in any way intitutive for a new user in the way that > `obj.url().schema` is. After thinking of it a bit more I agree about new users. My main concern though was about not using an estab

Re: media -> admin_media Prefix Change

drozzy wrote: > Sorry about the attitude, sometimes I think a bit too much of myself. > When do you think will get implemented? I'm not the one who decides :-). I've just raised another voice claiming that that decision may be worth reconsidering. --~--~-~--~~~---~--

Re: Replacing get_absolute_url, I am against it

Ivan Sagalaev wrote: > In the rare cases when I do need to split a URL into parts I just use > urlsplit: > > schema, domain, path, query, fragment = urlsplit(obj.url()) Oh... And for template authors we could just make 5 filters returning those parts: {{ ob

Re: Replacing get_absolute_url, I am against it

Jacob Kaplan-Moss wrote: > * The fact that the returned URL is a string often means I end up > doing something like `obj.get_absolute_url().split('/')`. Objects are > better. I kind of disagree with the last sentence here. An object in place of a well-known native type (here, str) adds another a

Re: media -> admin_media Prefix Change

drozzy wrote: > Yes, I Do, How about that he never replied to the Collin Grady's > commend about HOW it would break the code. > Seems like the ticket was never discussed but monopolized by a little > hush-hush discussion... Though I don't support this attitude I tend to agree on principle with d

Re: Replacing get_absolute_url, I am against it

drozzy wrote: > If it is going to be done I propose adding another function, and thus > have two possible functions on the model: > get_relative_url > get_absolute_url get_relative_url is rather misleading. The proper meaning of "relative" is a url relative to current url: "./some/hierarchy", "s

Re: Shouldn't custom fields in ModelForms pick up model Field options by default?

Kevin Henry wrote: >> There's also a ticket waiting for check-in implementing this common >> usecase:http://code.djangoproject.com/ticket/9223 > > Thanks, the accompanying discussion is very interesting and on point. > But as someone there points out, why stop at widgets? Because customizing wid

Re: Logging instead of connection.queries

Hello! I'd like to revive the discussion about handling debug SQL log since I don't feel we've come to any conclusion. To summarize: - Ticket [5415] deals with implementing signals upon SQL queries. Nobody had any objections to it and it helps in solving my original problem of logging. - Mal

Re: Shouldn't custom fields in ModelForms pick up model Field options by default?

Malcolm Tredinnick wrote: > If all you want to do is change the widget, you can do that in the > form's __init__ method by updating self.fields["name"].widget, for > example. There's also a ticket waiting for check-in implementing this common usecase: http://code.djangoproject.com/ticket/9223 P

  1   2   3   4   5   >