Re: A community Poll

On Wednesday 23 December 2015 16:32:22 Curtis Maloney wrote: > > Also, I don't want this discussion to be about my specific issue with > contenttypes... more a general "community opinion of best practices" > Imports, because of IDE integration and because they make it easier to detect

Re: A community Poll

To clarify a few points: In general, I'm in favour of removing string references for things... however, when it comes to relation fields, I'm on the side of "alway lazy". Also, I don't want this discussion to be about my specific issue with contenttypes... more a general "community opinion of

Re: A community Poll

> > I'm quite sure I was driven to that PR because importing ContentTypes > was causing lots of pain with AppState not being ready. > Whenever I see this error message pop up, it's not because code directly imports ContentTypes, but because it imports some other models.py module, which in

Re: A community Poll

Hi Curtis, On 12/21/2015 06:52 AM, Curtis wrote: > Whilst I'm awake... a pull request I made to a 3rd party project > included replacing explicit model imports for relation fields with lazy > binding -- ForeignKey('contenttypes.ContentType') in this case. > > The author pointed out this didn't

Re: A community Poll

Hello Curtis, 2015-12-21 14:52 GMT+01:00 Curtis : > So aside from the obvious "preventing circular imports", what other > benefits do people see? > I'm afraid this is an example of "worse is better". String references to other models in FK definitions are one of the

A community Poll

Whilst I'm awake... a pull request I made to a 3rd party project included replacing explicit model imports for relation fields with lazy binding -- ForeignKey('contenttypes.ContentType') in this case. The author pointed out this didn't play well with their IDEs refactoring tool, and asked if