Hello,
I'm back from the vacation.
@Hanne Moa - As far as I know, you can skip packages, files and everything
can be customized. It's the same with the rules. I did not prioritized the
Sonar rules - they are the default ones and Sonar is detecting not only
possible bugs and issues but code sme
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
It’s unclear to me as well how the current system is intended to be used.
All my projects do this:
> # Configure logging manually to avoid merging with Django's defaults.
>
> LOGGING = {
> # custom logging configuration goes here
> }
>
> logging.config.dictConfig(LOGGING)
>
> LOGGING_CONFI
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.
https://github.com/django/django/commit/8efea1b8d5b5fb0cfef1a3244c339cebf8af36c5
https://g
Hi Aymeric,
On 09/04/2016 01:03 PM, Aymeric Augustin wrote:
> Hello,
>
> Since Django 1.7, `get_user_model()` cannot be called at import time.
> Django contains a lot of methods that start with `UserModel =
> get_user_model()` while it would be more natural to declare it as a
> global variable in
Hi Carl,
Thanks for the feedback!
> On 06 Sep 2016, at 19:39, Carl Meyer wrote:
>
> 1) A kwarg to `get_model` seems fine, but I don't like the vague FUD of
> `unsafe=True` (if it's really "not safe" we shouldn't add it / make it
> public at all). How about something more specific like
> `requir
On 09/06/2016 12:55 PM, Aymeric Augustin wrote:
> Hi Carl,
>
> Thanks for the feedback!
Of course! Thanks for working on things :-)
> ...
> The change I’m proposing doesn’t introduce random bugs. If models are
> missing reverse relations, that will be deterministic.
+1
>> Is it possible
>> to
>
> 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
>
> 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.
On 09/06/2016 04:57 PM, Ivan Sagalaev wrote:
> I'm
> talking about this function:
> https://github.com/django/django/blob/master/django/utils/log.py#L66
>
> When `LOGGING_CONFIG` isn't explicitly disabled it first unconditionally
> initializes logging with the hard-coded configuration and then app
Carl, I think this is the thread with your past comments:
https://groups.google.com/d/topic/django-developers/no2IhnRty68/discussion
To avoid a new setting, we could add some custom key/value to LOGGING for
the new behavior and pop it before the dict is passed to dictConfig.
On Tuesday, Septemb
11 matches
Mail list logo
