Re: Silencing deprecation warnings in the test suite

[Ramiro Morales]

On Mon, Sep 2, 2013 at 8:08 AM, Aymeric Augustin
 wrote:
> Hello,
>
> When a feature is deprecated,  it raises a PendingDeprecationWarning, either 
> at import time or at run time. After the following release it raises 
> DeprecationWarning. Assuming we have a good test coverage, these warnings 
> will be shown by the test suite, with -Wall for PendingDeprecationWarning, by 
> default for DeprecationWarning. This is annoying. The output of the test 
> suite should remain clean.
>
> Unfortunately, I've noticed that we often forget to silence warnings when we 
> deprecate a feature. For instance, right new, the test suite raises warnings 
> related to custom SQL, syncdb, and SortedDict (with -Wall).  If you committed 
> one of these deprecations, would you mind silencing the 
> PendingDeprecationWarnings in the tests?
>
> There are two ways to achieve that:
> [...]

Thanks Aymeric for raising awareness about the problem and the compact
action item description.

I plan to propose some changes that involve a deprecation cycle and
had some vague recollection about an email or ticket about the same
issue by Carl but had been unable to find it. Your mail made me search
again and luckily this time I could find it:
https://code.djangoproject.com/ticket/17049 -- Fortunately, the
recommended solution there is in the same spirit as yours.

A result of that ticket is the fact that our CI setup uses -Wall so we
can see these warnings at the console output of every configuration
e.g.:

http://ci.djangoproject.com/job/Django/database=postgres,python=python3.3/lastBuild/console

Regards,

-- 
Ramiro Morales
@ramiromorales

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Circular dependency in forms+views+models

[Marc Tamlyn]

Opened a ticket - https://code.djangoproject.com/ticket/21022


On 2 September 2013 14:37, Russell Keith-Magee wrote:

>
> I agree with Marc -- the fix here is that you should be using a named URL,
> not referencing the view directly. The circular dependency shouldn't exist
> - it should be broken by the dereferencing provided by the URL name. This
> is a feature that was added late in the development of Django (well…
> relatively. Pre 1.0, but after all the core had been laid down), so the
> docs haven't been completely updated to reflect this.
>
> Yours,
> Russ Magee %-)
>
> On Mon, Sep 2, 2013 at 7:53 PM, Marc Tamlyn  wrote:
>
>> I think the main issue here is using the view (name OR instance) as the
>> reference. We really should be pushing naming of urls more in the
>> documentation - they're always mentioned but as a "you might prefer to do
>> this" rather than a "use URL names on every URLpattern and in reverse. You
>> could also use these other methods."
>>
>> The tutorial is now quite good at following these best practices, but the
>> reference docs are not.
>>
>>
>> On 1 September 2013 08:22, Curtis Maloney wrote:
>>
>>> Given both the docs for get_absolute_url and reverse demonstrate using
>>> string references only, I think adding in clarification of why it's
>>> preferred is worthwhile.
>>>
>>> I still find it surprising how often I need to tell people on #django to
>>> not import models just to reference them in relation fields...
>>>
>>> --
>>> Curtis
>>>
>>>
>>>
>>> On 1 September 2013 17:00, Jorge Cardoso Leitao <
>>> jorgecarlei...@gmail.com> wrote:
>>>
 The way I stumbled across this problem was:

 1. views imports models and forms (both are normally needed)

 2. forms imports models (for ModelForm)

 3. models imports views (for get_absolute_url), e.g.:

 *import views*
 *class MyModel(models.Model):*
 * get_absolute_url(reverse(views.myview))*

 which leads to a circular dependency of the form
 views->forms->models->views.

 I searched and there are some questions raised in stackoverflow about
 it, e.g. 
 this
 , 
 this
 .
 This is avoided by removing one of the imports, and in this
 case the candidate is 3., replacing it with a string (e.g.
 'views.myview').

 I propose that we add a note on the documentation of 
 get_absolute_url
 explaining that get_aboslute_url should be coded by returning reverses
 of strings and
 not of functions or classes to avoid circular dependencies.

 There is a ongoing 
 thread
  about
 get_absolute_url and I think these problems are
 somewhat related: this circular dependency is a valid mistake from a
 Django user because models are depending on views, views on forms,
 forms on models.

 Another reason why I think this should be documented is that circular
 dependencies
 are difficult to debug, specially when they occur after modules are
 imported like *import module.*

 This also makes the documentation more consistent: Foreign 
 Key 
 already
 warns about circular dependencies:

 "This sort of reference can be useful when resolving circular import
 dependencies between two applications."

 In summary, I agree that the url's "anti-circular dependency" is
 correctly fixed from the implementation point of view by allowing strings,
 what I'm proposing is just to document why users should use it, i.e.
 what they are useful for, specially in the models' get_absolute_url.

 If no one objects, I can do this.

 Regards,
 Jorge

 --
 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.
 For more options, visit https://groups.google.com/groups/opt_out.

>>>
>>>  --
>>> 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.

Re: Circular dependency in forms+views+models

[Russell Keith-Magee]

I agree with Marc -- the fix here is that you should be using a named URL,
not referencing the view directly. The circular dependency shouldn't exist
- it should be broken by the dereferencing provided by the URL name. This
is a feature that was added late in the development of Django (well…
relatively. Pre 1.0, but after all the core had been laid down), so the
docs haven't been completely updated to reflect this.

Yours,
Russ Magee %-)

On Mon, Sep 2, 2013 at 7:53 PM, Marc Tamlyn  wrote:

> I think the main issue here is using the view (name OR instance) as the
> reference. We really should be pushing naming of urls more in the
> documentation - they're always mentioned but as a "you might prefer to do
> this" rather than a "use URL names on every URLpattern and in reverse. You
> could also use these other methods."
>
> The tutorial is now quite good at following these best practices, but the
> reference docs are not.
>
>
> On 1 September 2013 08:22, Curtis Maloney wrote:
>
>> Given both the docs for get_absolute_url and reverse demonstrate using
>> string references only, I think adding in clarification of why it's
>> preferred is worthwhile.
>>
>> I still find it surprising how often I need to tell people on #django to
>> not import models just to reference them in relation fields...
>>
>> --
>> Curtis
>>
>>
>>
>> On 1 September 2013 17:00, Jorge Cardoso Leitao > > wrote:
>>
>>> The way I stumbled across this problem was:
>>>
>>> 1. views imports models and forms (both are normally needed)
>>>
>>> 2. forms imports models (for ModelForm)
>>>
>>> 3. models imports views (for get_absolute_url), e.g.:
>>>
>>> *import views*
>>> *class MyModel(models.Model):*
>>> * get_absolute_url(reverse(views.myview))*
>>>
>>> which leads to a circular dependency of the form
>>> views->forms->models->views.
>>>
>>> I searched and there are some questions raised in stackoverflow about
>>> it, e.g. 
>>> this
>>> , 
>>> this
>>> .
>>> This is avoided by removing one of the imports, and in this
>>> case the candidate is 3., replacing it with a string (e.g.
>>> 'views.myview').
>>>
>>> I propose that we add a note on the documentation of 
>>> get_absolute_url
>>> explaining that get_aboslute_url should be coded by returning reverses
>>> of strings and
>>> not of functions or classes to avoid circular dependencies.
>>>
>>> There is a ongoing 
>>> thread
>>>  about
>>> get_absolute_url and I think these problems are
>>> somewhat related: this circular dependency is a valid mistake from a
>>> Django user because models are depending on views, views on forms, forms
>>> on models.
>>>
>>> Another reason why I think this should be documented is that circular
>>> dependencies
>>> are difficult to debug, specially when they occur after modules are
>>> imported like *import module.*
>>>
>>> This also makes the documentation more consistent: Foreign 
>>> Key 
>>> already
>>> warns about circular dependencies:
>>>
>>> "This sort of reference can be useful when resolving circular import
>>> dependencies between two applications."
>>>
>>> In summary, I agree that the url's "anti-circular dependency" is
>>> correctly fixed from the implementation point of view by allowing strings,
>>> what I'm proposing is just to document why users should use it, i.e.
>>> what they are useful for, specially in the models' get_absolute_url.
>>>
>>> If no one objects, I can do this.
>>>
>>> Regards,
>>> Jorge
>>>
>>> --
>>> 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.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>
>>  --
>> 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.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe 

Re: Django Trac ticket keywords

[Dan Poirier]

On Thu. 2013-08-29 at 06:15 PM EDT, "Daniele Procida"  wrote:

> Would there be any objection if I used a keyword ("afraid_to_commit"
> or something) to mark tickets that I think would be suitable for
> first-time committers doing the "Don't be afraid to commit" tutorial
> to tackle?

My first reaction to that keyword name is "I should be especially afraid
to commit this ticket". Not sure that's the intention.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Silencing deprecation warnings in the test suite

[Aymeric Augustin]

Hello,

When a feature is deprecated,  it raises a PendingDeprecationWarning, either at 
import time or at run time. After the following release it raises 
DeprecationWarning. Assuming we have a good test coverage, these warnings will 
be shown by the test suite, with -Wall for PendingDeprecationWarning, by 
default for DeprecationWarning. This is annoying. The output of the test suite 
should remain clean.

Unfortunately, I've noticed that we often forget to silence warnings when we 
deprecate a feature. For instance, right new, the test suite raises warnings 
related to custom SQL, syncdb, and SortedDict (with -Wall).  If you committed 
one of these deprecations, would you mind silencing the 
PendingDeprecationWarnings in the tests?

There are two ways to achieve that:

1) In a particular test

def test_foo(self):
with warnings.catch_warnings(record=True) as w:
warnings.simplefilter("always")
# frobnicate deprecated stuff
# go ahead with the test

2) For an entire test case

django.test.utils contains three helpful mixins if you want to silence warnings 
throughout a TestCase: IgnorePendingDeprecationWarningsMixin, 
IgnoreDeprecationWarningsMixin, and IgnoreAllDeprecationWarningsMixin.

Thank you,

-- 
Aymeric.



-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Order of INSTALLED_APPS

[Shai Berger]

On Monday 02 September 2013 12:34:03 VernonCole wrote:
> It also affects _how_ South works, not just _whether_ it works.  Only this
> week I had to install a patch for the formhub package which consisted of
> re-ordering INSTALLED_APPS so that tables were built in the correct order
> on PostgreSQL installations.
> 
This is getting off-topic for this list -- but South has a concept of 
dependencies between migrations, which is the right way to get migrations in 
the right order. You shouldn't depend on INSTALLED_APPS order for that.

Unless I'm missing something, in which case, let's take it to the South list.

Shai.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Circular dependency in forms+views+models

[Marc Tamlyn]

I think the main issue here is using the view (name OR instance) as the
reference. We really should be pushing naming of urls more in the
documentation - they're always mentioned but as a "you might prefer to do
this" rather than a "use URL names on every URLpattern and in reverse. You
could also use these other methods."

The tutorial is now quite good at following these best practices, but the
reference docs are not.


On 1 September 2013 08:22, Curtis Maloney wrote:

> Given both the docs for get_absolute_url and reverse demonstrate using
> string references only, I think adding in clarification of why it's
> preferred is worthwhile.
>
> I still find it surprising how often I need to tell people on #django to
> not import models just to reference them in relation fields...
>
> --
> Curtis
>
>
>
> On 1 September 2013 17:00, Jorge Cardoso Leitao 
> wrote:
>
>> The way I stumbled across this problem was:
>>
>> 1. views imports models and forms (both are normally needed)
>>
>> 2. forms imports models (for ModelForm)
>>
>> 3. models imports views (for get_absolute_url), e.g.:
>>
>> *import views*
>> *class MyModel(models.Model):*
>> * get_absolute_url(reverse(views.myview))*
>>
>> which leads to a circular dependency of the form
>> views->forms->models->views.
>>
>> I searched and there are some questions raised in stackoverflow about it,
>> e.g. 
>> this
>> , 
>> this
>> .
>> This is avoided by removing one of the imports, and in this
>> case the candidate is 3., replacing it with a string (e.g.
>> 'views.myview').
>>
>> I propose that we add a note on the documentation of 
>> get_absolute_url
>> explaining that get_aboslute_url should be coded by returning reverses of
>> strings and
>> not of functions or classes to avoid circular dependencies.
>>
>> There is a ongoing 
>> thread
>>  about
>> get_absolute_url and I think these problems are
>> somewhat related: this circular dependency is a valid mistake from a
>> Django user because models are depending on views, views on forms, forms
>> on models.
>>
>> Another reason why I think this should be documented is that circular
>> dependencies
>> are difficult to debug, specially when they occur after modules are
>> imported like *import module.*
>>
>> This also makes the documentation more consistent: Foreign 
>> Key 
>> already
>> warns about circular dependencies:
>>
>> "This sort of reference can be useful when resolving circular import
>> dependencies between two applications."
>>
>> In summary, I agree that the url's "anti-circular dependency" is
>> correctly fixed from the implementation point of view by allowing strings,
>> what I'm proposing is just to document why users should use it, i.e. what
>> they are useful for, specially in the models' get_absolute_url.
>>
>> If no one objects, I can do this.
>>
>> Regards,
>> Jorge
>>
>> --
>> 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.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>  --
> 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.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Order of INSTALLED_APPS

[VernonCole]

It also affects _how_ South works, not just _whether_ it works.  Only this 
week I had to install a patch for the formhub package which consisted of 
re-ordering INSTALLED_APPS so that tables were built in the correct order 
on PostgreSQL installations.

On Sunday, September 1, 2013 11:04:03 PM UTC+1, Marc Tamlyn wrote:
>
> I don't think it would break South installations as custom app commands 
> will always override builtins. Could you open a ticket for that? The 
> inconsistency is problematic. Obviously it would be backwards incompatible, 
> but we need to gauge the size of the impact.
>
> Marc
> On 1 Sep 2013 21:31, "Kevin Christopher Henry" 
>  
> wrote:
>
>> Sorry to be late to this thread, I just came across it.
>>
>> There's another place where the order of INSTALLED_APPS matters: 
>> management commands. Management commands associated with apps that come 
>> later in INSTALLED_APPS will replace those with the same name that are 
>> listed earlier. I can't find this documented anywhere, but a look at the 
>> code confirms it. South, for example, takes advantage of this to override 
>> the syncdb command (and hints at the ordering issue when the documentation 
>> says: "add 'south' to the end of INSTALLED_APPS").
>>
>> So a documentation update should probably note this specifically in the 
>> management documentation, as well as mentioning it in the box for 
>> INSTALLED_APPS. (I also think static files should also be mentioned in the 
>> box, since as Aymeric points out that is another area dependent on the 
>> order of apps.)
>>
>> One thing that's unfortunate is that the semantics of ordering for 
>> management commands is opposite that of the other cases. For templates, 
>> static files, and translations, listing an app *first *gives it 
>> precedence, whereas with management commands it's listing it *last.*Ideally 
>> this would be changed so that management commands were consistent 
>> with the other cases, but that would create serious backwards compatibility 
>> issues. Like, breaking everyone's South installation. :-O
>>
>> Cheers,
>> Kevin
>>
>>
>> On Wednesday, August 14, 2013 5:26:47 AM UTC-4, Stefano Crosta wrote:
>>>
>>> Done! 
>>> https://code.**djangoproject.com/ticket/**20914#ticket
>>>
>>> thanks!
>>>
>>> On Tuesday, August 13, 2013 12:20:48 PM UTC+2, Aymeric Augustin wrote:

 2013/8/13 Stefano Crosta 

> My proposal would then be to simply add another box to the 
> https://docs.**djangoproject.com/en/dev/ref/**settings/#installed-apps
>  to 
> say "order matters" once more and link the other two pages for 
> translations 
> and templates.
> *if you think this would* help I could do it as well as a ticket. To 
> save everybody's time no answer will mean it's not worth it!
>

 Yes, please file one, and include a link to this discussion.

 -- 
 Aymeric. 

>>>  -- 
>> 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-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.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.