Re: Adding support for importing models through the app registry while it is loading

[Aymeric Augustin]

Hello,

Quick follow-up: I just updated my PR according to this discussion:
https://github.com/django/django/pull/6547

While I was there, I made get_user_model() usable at import time.
We’ll need feedback from actual projects to know it that works.

-- 
Aymeric.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/F2DB4ACF-1B5D-4B2B-A1D5-BDCAFE519183%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: Autocomplete in Django 1.11: Widget in Forms Library?

[Tim Graham]

I was thinking about a similar issue when looking at Curtis's patch for an 
admin HStoreField widget [0]. It doesn't seem so nice to give 
contrib.postgres special treatment in the admin. Rather, I think the admin 
should have a hook to register custom widgets for arbitrary fields. If it 
provided that, I wonder if the autocomplete patch [1] could more easily be 
done as a third-party library.

[0] https://github.com/django/django/pull/6515
[1] https://github.com/django/django/pull/6385

On Friday, September 30, 2016 at 1:20:21 PM UTC-4, Collin Anderson wrote:
>
> Hi,
>
> "it could be possible to provide such a widget in contrib.admin".
>
> The current PR provides a django.contrib.admin.widgets.AutocompleteSelect 
> widget. Does that work?
>
> You could subclass it to use a different URL instead of the built-in 
> admin:autocomplete url if needed. My one worry is that if we end up adding 
> more code to handle use cases different from the admin, we'll just end up 
> re-inventing and maintaining django-select2. But, maybe simply re-using the 
> widget or subclassing the widget is good enough?
>
> Thanks,
> Collin
>
>
> On Wed, Sep 21, 2016 at 6:28 AM, guettli  
> wrote:
>
>>
>>
>> Am Dienstag, 20. September 2016 13:30:33 UTC+2 schrieb Tim Graham:
>>>
>>> I haven't seen that proposal. This type of widget would be new territory 
>>> for django.forms as none of the existing widgets require JavaScript. I lean 
>>> toward keeping things that way, but I'm open to hearing counterarguments. 
>>> Historically, Django avoided "blessing" any particular JavaScript libraries.
>>>
>>
>>
>> OK, I see you don't want widgets which require JS in django core. I can 
>> understand this.
>>
>> But since contrib.admin includes the autocomplete, it could be possible 
>> to provide such a widget in contrib.admin. 
>>
>> My intention: since the admin includes JS for autocomplete, it would be 
>> nice to re-use this in custom apps.
>>
>> I know that I can use third party libraries to get this. But if it is 
>> already in contrib.admin, it would be nice to avoid duplication
>>
>>
>>  
>>
>>> On Tuesday, September 20, 2016 at 6:51:24 AM UTC-4, guettli wrote:

 I am happy that there will be support for autocomplete in the admin in 
 1.11, if this issue/pull-request gets resolved:

 https://code.djangoproject.com/ticket/14370

 https://github.com/django/django/pull/6385/

 I looked at the changes of the docs of this pull request.

 It seems that only the contrib module "admin" gets improved.

 Is it planed to add an autocomplete widget in the django forms library?



 -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/a4411d55-6db2-4515-b680-0b8dfe03a3bd%40googlegroups.com
>>  
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a578f1c5-3e1f-4cbc-bbc4-b05d4832121b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Autocomplete in Django 1.11: Widget in Forms Library?

[Collin Anderson]

Hi,

"it could be possible to provide such a widget in contrib.admin".

The current PR provides a django.contrib.admin.widgets.AutocompleteSelect
widget. Does that work?

You could subclass it to use a different URL instead of the built-in
admin:autocomplete url if needed. My one worry is that if we end up adding
more code to handle use cases different from the admin, we'll just end up
re-inventing and maintaining django-select2. But, maybe simply re-using the
widget or subclassing the widget is good enough?

Thanks,
Collin


On Wed, Sep 21, 2016 at 6:28 AM, guettli  wrote:

>
>
> Am Dienstag, 20. September 2016 13:30:33 UTC+2 schrieb Tim Graham:
>>
>> I haven't seen that proposal. This type of widget would be new territory
>> for django.forms as none of the existing widgets require JavaScript. I lean
>> toward keeping things that way, but I'm open to hearing counterarguments.
>> Historically, Django avoided "blessing" any particular JavaScript libraries.
>>
>
>
> OK, I see you don't want widgets which require JS in django core. I can
> understand this.
>
> But since contrib.admin includes the autocomplete, it could be possible to
> provide such a widget in contrib.admin.
>
> My intention: since the admin includes JS for autocomplete, it would be
> nice to re-use this in custom apps.
>
> I know that I can use third party libraries to get this. But if it is
> already in contrib.admin, it would be nice to avoid duplication
>
>
>
>
>> On Tuesday, September 20, 2016 at 6:51:24 AM UTC-4, guettli wrote:
>>>
>>> I am happy that there will be support for autocomplete in the admin in
>>> 1.11, if this issue/pull-request gets resolved:
>>>
>>> https://code.djangoproject.com/ticket/14370
>>>
>>> https://github.com/django/django/pull/6385/
>>>
>>> I looked at the changes of the docs of this pull request.
>>>
>>> It seems that only the contrib module "admin" gets improved.
>>>
>>> Is it planed to add an autocomplete widget in the django forms library?
>>>
>>>
>>>
>>> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-developers/a4411d55-6db2-4515-b680-
> 0b8dfe03a3bd%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFO84S4V7fwyuOCB-LXfUnfFFfaQkQKyMM4%2B8V0UXQUHg4BesA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Challenge teaching Django to beginners: urls.py

[João Sampaio]

I also prefer URLs all concentrated in a single place, instead of spread
out all over the codebase. The reason is that it is dead simple to track
which view is associated with a URL, just look at the ROOT_URLCONF file and
track the view following the patterns. If you have them spread out, you'll
need to use grep or something to find the URL pattern. But that's not
always simple, because the URL could be a complex regex with custom
parameters and grep is not suitable anymore.

URLs in view code works great for small projects. Now try that with a
project with many apps, many urls.py files and many URL endpoints to track.

On Thu, Sep 29, 2016 at 4:21 PM, Sven R. Kunze  wrote:

>
>
> Am Donnerstag, 29. September 2016 20:42:47 UTC+2 schrieb Sjoerd Job
> Postmus:
>>
>> I have a feeling this is orthogonal to the original request.
>>
>> The original request/problem was "regex is hard".
>> Your response answers/solves "the URL definition is somewhere different
>> from the view definition".
>>
>> Both issues are realistic [1], and orthogonal.
>>
>
> Oh maybe, I didn't fleshed that response out appropriately. What I wanted
> to say, is that his regex-light approach might be worth-while implemented
> in a third-party package such as described by others and me before
> inclusion in Django core (which also prefer sooner rather than later).
>
>
>> [1]: I myself have great aversion to the approach where URL patterns are
>> spread out over the codebase, but I know others are greatly prefer the
>> approach that Flask takes.
>>
>
> I tended to have this kind of aversion as well but after a while of using
> the UrlMixin, I am in love with it.
>
> I think kind of this adaptation
>  stems from the fact
> that in 99%, 1 URL corresponds to 1 View and vice-versa. Remove the view,
> you remove the URL as well and vice versa. Put it differently, it makes no
> sense to separate URl and view in different locations. That's at least our
> experience while doing Web-based applications and APIs for years.
>
> Best,
> Sven
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-developers/751b586d-0b0e-4ab2-bc42-
> a2d93308e769%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAO_YKa1HV%2Ba8td1xpwnjhNEscfGbsAUcVxwFpA%3DZRG4uBDg%2Brg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature suggestion: Option to suppress system checks in commands

[Bogdan Bursuc]

Hi,

You could add the setting through and env variable and obtain that variable
inside the settings file with
SILENCED_SYSTEM_CHECKS = bool(os.environ.get("SILENCED_SYSTEM_CHEKS",
false))


On Fri, Sep 30, 2016 at 11:31 AM Vlastimil Zíma  wrote:

> Hi everyone,
>
> I'd suggest an options for all commands to suppress a defined system
> checks when running a command. I know it is possible to defined
> SILENCED_SYSTEM_CHECKS in settings, but that has impact of everything
> including the check command itself. My point is to suppress system checks
> mainly for cron jobs, so they don't report errors. I don't want to use
> settings because I don't want to suppress checks for migrate and other
> commands when deploying new version of application.
>
> I don't want to suppress checks for our commands either, since there is
> only option to suppress checks completely.
>
> Any support for this feature?
>
> Regards,
> Vlastimil
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/554d79d7-1485-46c7-8ecd-352422382c00%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Thanks,
Bogdan I. Bursuc

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAGqeRU-FihzfgGpTK%2BezcpSVZBVG9eg3i3AM%3DeqE2ukgMZjNhw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Form.Media: render inline css/js

[Matthias Kestenholz]

On Thursday, September 29, 2016 at 4:11:04 PM UTC+2, is_null wrote:
>
> Thanks for the heads up, a similar ticket has been closed as wontfix, 
> because it isn't compatible with CSP: 
> https://code.djangoproject.com/ticket/13978
>
> While I'm all against inline scripts, I have a use case which seems be 
> legitimate: 
> https://github.com/yourlabs/django-autocomplete-light/pull/733/files#diff-469b501dd1f427cfe68aac4d27f28df3R84
>
> Basically, we render a `json object 
> dump here` next to the widget and use that to configure the script 
> for that widget. IMHO, the ideal solution would be to be able to place this 
> script tag in `{{ form.media }}` rather than next to the HTML widget.
>
>
There is precedent in Django (respectively django.contrib.admin) for adding 
attributes to the script tag, for example here:
https://github.com/django/django/blob/master/django/contrib/admin/templates/admin/popup_response.html

I have an admittedly ugly hack here which allows (ab)using forms.Media for 
custom additional attributes here: (It works well and I sleep well, but 
it's not nice at all.)
https://github.com/matthiask/django-content-editor/blob/master/content_editor/admin.py#L93

If this is an acceptable way of delivering additional data to the frontend 
code I might work on that during a sprint some time?

Thanks,
Matthias


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/2782925a-0d2f-44d9-a055-36b3cc4a1078%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: is_valid as property

[Michal Petrucha]

Hi everybody,

On Fri, Sep 30, 2016 at 09:04:32AM +0300, Shai Berger wrote:
> Hi Sven,
> 
> On Thursday 29 September 2016 22:09:27 Sven R. Kunze wrote:
> > 
> > Am Donnerstag, 29. September 2016 20:26:54 UTC+2 schrieb Aymeric Augustin:
> > 
> > > Generally speaking, properties are expected to be cheap and methods can be
> > > expensive. In my opinion, for lack of a better guideline, we should stick
> > > to this one. `is_valid()` falls into the expensive category, and for this
> > > reason it should remain a method.
> > 
> > Oh, I've never heard of this guideline. I just thought that properties
> > should be used to reduce visual noise (such as parentheses and "get_" or
> > "set_" prefixes.) or to replace a static attribute with a dynamic one.
> > Cheap vs. expensive never played a role so far (at least where I worked).
> 
> I'm completely with Aymeric on this one. The parentheses are not just noise, 
> they're a strong hint about the price of computation expected, and also about 
> the expectation of exceptions popping up. Properties hiding complex code are 
> downright misleading in my book, and "is_valid()", which may call user code, 
> certainly qualifies as complex.

I also agree with Aymeric and Shai on this, which is why I want to
bring up the elephant in the room: Form.errors. This is a property
which triggers full validation of the form on first access. What are
the chances of replacing Form.errors with a method?

Or maybe making it raise an error if it's accessed before the form has
been validated by calling an explicit method?

Cheers,

Michal

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20160930094345.GY6601%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: Feature suggestion: Option to suppress system checks in commands

[GMail]

Hi, wouldn't it be easier to create special settings for cron? Something like 
that:


# myprj/settings/cron.py

from myprj.settings import *
SILENCED_SYSTEM_CHECKS = ...


And in cron:

... python manage.py  --settings=myprj.settings.cron

> On 30 Sep 2016, at 11:31, Vlastimil Zíma  > wrote:
> 
> Hi everyone,
> 
> I'd suggest an options for all commands to suppress a defined system checks 
> when running a command. I know it is possible to defined 
> SILENCED_SYSTEM_CHECKS in settings, but that has impact of everything 
> including the check command itself. My point is to suppress system checks 
> mainly for cron jobs, so they don't report errors. I don't want to use 
> settings because I don't want to suppress checks for migrate and other 
> commands when deploying new version of application.
> 
> I don't want to suppress checks for our commands either, since there is only 
> option to suppress checks completely.
> 
> Any support for this feature?
> 
> Regards,
> Vlastimil
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/554d79d7-1485-46c7-8ecd-352422382c00%40googlegroups.com
>  
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/F2F20CB0-87C0-4583-AA60-27CC8E629516%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Feature suggestion: Option to suppress system checks in commands

[Vlastimil Zíma]

Hi everyone,

I'd suggest an options for all commands to suppress a defined system checks 
when running a command. I know it is possible to defined 
SILENCED_SYSTEM_CHECKS in settings, but that has impact of everything 
including the check command itself. My point is to suppress system checks 
mainly for cron jobs, so they don't report errors. I don't want to use 
settings because I don't want to suppress checks for migrate and other 
commands when deploying new version of application.

I don't want to suppress checks for our commands either, since there is 
only option to suppress checks completely.

Any support for this feature?

Regards,
Vlastimil

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/554d79d7-1485-46c7-8ecd-352422382c00%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adding aggregates to ModelAdmin.list_display

[dor]

Can we agree on the suggested design?
Or does anyone think it needs to be incorporated into *list_display*?

On Wednesday, September 21, 2016 at 7:43:06 PM UTC+3, dor wrote:
>
> I recently suggested adding a *list_aggregates* member to ModelAdmin, 
> along with a patch to match:
> https://code.djangoproject.com/ticket/27229
>
> A core developer counter-suggested changing the design of list_display to 
> achieve the same;
>
> What do you think?
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/f84765d6-32bc-477c-b45f-8a7683cadb28%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: is_valid as property

[Shai Berger]

Hi Sven,

On Thursday 29 September 2016 22:09:27 Sven R. Kunze wrote:
> 
> Am Donnerstag, 29. September 2016 20:26:54 UTC+2 schrieb Aymeric Augustin:
> 
> > Generally speaking, properties are expected to be cheap and methods can be
> > expensive. In my opinion, for lack of a better guideline, we should stick
> > to this one. `is_valid()` falls into the expensive category, and for this
> > reason it should remain a method.
> 
> Oh, I've never heard of this guideline. I just thought that properties
> should be used to reduce visual noise (such as parentheses and "get_" or
> "set_" prefixes.) or to replace a static attribute with a dynamic one.
> Cheap vs. expensive never played a role so far (at least where I worked).

I'm completely with Aymeric on this one. The parentheses are not just noise, 
they're a strong hint about the price of computation expected, and also about 
the expectation of exceptions popping up. Properties hiding complex code are 
downright misleading in my book, and "is_valid()", which may call user code, 
certainly qualifies as complex.

Have fun,
Shai.