On Jun 1, 2:15 pm, Russell Keith-Magee <freakboy3...@gmail.com> wrote:
> IMHO, that use case would be better handled with two different > settings files -- one with DEBUG=True and debug logging, and one with > DEBUG=False and production logging. Having multiple settings files > isn't an unusual deployment arrangement; there are many guides to > Django deployment that will advise that approach. Of course that would work - as long as people are happy to keep the multiple settings files in sync after changing something which would be common to both of them (e.g. a database setting). It's not the epitome of DRY, I feel, even if there are lots of recommendations to do this out there. > Your proposal also requires that we start recommending that users put > logic into their settings.py, and I'm not comfortable making that a > recommended practice. Nothing else in a Django settings file is a > callable; I don't see why logging needs to break that trend. It doesn't, and I understand why you're nervous about this. OTOH, settings.py is Python code, as per an original Django design decision, and there's often already logic in settings.py (for example, os.path manipulation code is a not unusual pattern). > My YAGNI objection is grounded in the fact that I can't see why lots > of flexibility is required in the logging configuration process. For > all the example cases I can envisage, there is exactly 1 function call > that the logging setup process needs to make, and the value passed to > that function is a configuration dictionary that can live in settings. I didn't say it was needed for logging configuration, just that it covered both logging configuration and other sorts of code of the type alluded to in Simon's post. > *If* we were to accept the use case that configurable logging setup > function is required, I'd be much more inclined to have a > LOGGING_SETUP = 'path.to.my.setup_function', with a default value that > points to an implementation that just calls > configure_logging_from_dict(). However, we can also add this later in > an entirely backwards compatible way if it turns out to be a common > requirement. Sure, that would work. But you wouldn't do that unless a lot of people asked for it, and I'm not saying that it would be a really common requirement. So it's perfectly possible that a small but not totally insignificant minority would be inconvenienced. I suppose that's not enough to weigh against your worries relating to recommending logic in settings.py - well then fair enough, what more can I say? :-) > This is exactly why startup.py is being proposed. We need to have a > place to reliably register signal handlers, search callbacks, and > anything else that has historically been put in urls.py. Sure, and I'm not saying that the startup.py approach wouldn't work. > "No extra cost" isn't a very good argument, because there is always a > cost. In this case, it's not the cost of implementation or execution > that concerns me - it's the cost of having a public API that we need > to maintain, and a point of backwards compatibility that needs to be > maintained if we ever modify the model loading infrastructure > (something that the GSoC is working on, for example). The "no extra cost" was not the main thrust of the argument, since the costs we are talking about are startup one-off costs as far as runtime goes. The public API maintenance overhead is a valid issue, but that maintenance and backward compatibility overhead would also be present for the startup.py approach, or any other approach for that matter. After all, we're talking about a public API to support invoking users' startup code. > It's not about the names, it's about the pattern that is being > reimplemented. Your proposal may well be simple, but it doesn't change > the fact that "callbacks" are essentially a reimplementation of > exactly what signals do, but with less flexibility. A signal is just > an agreement to call a bunch of functions -- exactly like the callback > you describe, except that signals allow for a generic registration > (rather than using a setting), and signals can be filtered based on > the arguments with which the callback was invoked. A callback is a lower level concept than an event handler, in my view. Signal handlers are effectively event handlers, which associate the lower level callback concept with filtering, arguments etc. Of course, that distinction doesn't matter in this case - if you don't like the callbacks because they involve logic in settings.py, I can't really argue against that. > As your quote from Simon indicates, there is a need to provide a > reliable location that can be used for registrations, installing > signal handlers, and other 'on startup' behaviors. This can't be a > signal because you need to have somewhere to install the first signal > handler. So, startup.py needs to use a different approach, and needs > to happen as early as possible in the process. Right after logging is > configured is as good a place as any. The only operational difference > between startup.py and your PRE_MODEL_CALLBACKS list is that > startup.py doesn't require any new settings in order to work -- you > just drop a startup.py in your app, and you're done. It doesn't seem to me that having one or two new settings is such a big deal (as we're talking about having a new LOGGING setting anyway), but it's your call. I see it as a taste thing, myself. It's probably the case that the startup.py approach would be an easier sell to newbies, too. > However, once this initial startup has been invoked, any other > callback that is required can be handled by signals. There is no > operational difference between the POST_MODEL_CALLBACKS and a > 'models_loaded' signal; but again, the signal approach doesn't require > any new settings. All we are arguing about is the need for this signal > at all. > > Your comment about avoiding the model loading race condition is > certainly a valid one, and that's probably enough to get me over the > line on the need for this signal. My only concern is whether there is > anything else that a "models_loaded" signal should be 'after'. If > we're going to introduce a "we've finished setup" signal, I want to > make sure that the place we emit it is a point at which we can > guarantee that we've actually finished the setup :-) Okay, and thanks for all the feedback. Regards, Vinay Sajip -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
