Re: Quick Filter in the Admin Sidebar

[Collin Anderson]

I think this would be really helpful. Looking at the code in the gist, that 
looks about right. It's not too complicated and the basic 
toLowerCase()/indexOf() method of search should hopefully be enough (it's 
what I would do if I were implementing this!). I'd suggest adding some sort 
of clear or x button for canceling/removing the filter, but otherwise I 
think this should be ok UX wise. We can always improve it later.

On Thursday, November 19, 2020 at 9:38:25 AM UTC-5 t...@carrick.eu wrote:

> I haven't looked at the gist, but I think in principle it's a good idea. 
> ctrl+f isn't ideal.
>
> I think we need to be careful that the UX is good, if we go with this.
>
> Tom
>
> On Thu, 19 Nov 2020 at 15:16, Maxim Milovanov  wrote:
>
>> Yeah, that's why I came up with that idea. There are two projects, 44 
>> models on one, 57 models on another. It's very hard to navigate
>>
>> четверг, 19 ноября 2020 г. в 16:50:37 UTC+3, yasie...@gmail.com: 
>>
>>> I found this feature very helpful. I'm maintaining two sites with more 
>>> than 20 models registered in the admin and some time is annoying when I try 
>>> to find the one I'm looking for
>>>
>>> El miércoles, 18 de noviembre de 2020 a la(s) 15:13:02 UTC-5, Maxim 
>>> Milovanov escribió:
>>>
 Hey guys,

 I've posted a ticket  with 
 a proposal to add a quick filtering feature to the sidebar.
 To see it in action just replace the content of nav_sidebar.html by this 
 gist 
 

 Does it worth adding to the admin features? Hope for any feedback.

 Thanks,
 Maxim

>>> -- 
>> 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 view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/8376528d-a2df-43b0-829e-43a49bd44dddn%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/57ba00b9-7804-4bd6-a88e-12d73f70af3an%40googlegroups.com.

Re: Adding a security concerned feature

[Collin Anderson]

> combination of blocking IPs and having a different admin URL would raise
the bar quite a bit.

So having a different default admin URL would help, right?

On Wed, Nov 25, 2020 at 10:11 AM 'Aaron C. de Bruyn' via Django developers
(Contributions to Django itself)  wrote:

> That's security through obscurity that isn't too difficult to get past.
> It certainly raises the bar a bit, but like you said, the root problem is
> someone finding a login box and hammering away trying to guess usernames
> and passwords.  I'm betting your 'standard' login box isn't difficult to
> find if your site has one.  Once you have cracked an account, see if it
> gets you into /admin.
>
> I use django-axes.  If you keep guessing passwords, your IP gets banned.
>
> Maybe a warning could be set that says "Your admin URL is at /admin, we
> recommend you change that"?
>
> I think the combination of blocking IPs and having a different admin URL
> would raise the bar quite a bit.
>
> -A
>
> On Wed, Nov 25, 2020 at 6:51 AM Collin Anderson 
> wrote:
>
>> Hi All,
>>
>> I think at minimum we should change the default admin url for new
>> projects, as that's very easy to do, and it does provide a lot of value for
>> new projects. This helps Django to be secure by default.
>>
>> I use the default /admin/ url for my projects and bots are regurarly
>> trying different password combinitations. In addition, security scanners
>> are now starting to warn if you have an /admin/ url visible on your website.
>>
>> It would be a ton of work for me to change it, but it would be trivial if
>> this were a new project.
>>
>> I think adding the project name as a prefix would help a lot and be very
>> easy to do.
>>
>> https://github.com/django/django/compare/master...collinanderson:patch-14
>>
>> (and then the docs would need to be updated too.)
>>
>> Thanks,
>> Collin
>>
>>
>> On Thursday, November 19, 2020 at 7:11:59 PM UTC-5 arvind...@gmail.com
>> wrote:
>>
>>> A security model doesn’t necessarily have to be any one thing that’s
>>> 100% secure. It can be a combination of things which include “actual”
>>> security features as well as plain ol’ obscurity.
>>>
>>> If I have to register the admin urls on a project, I make sure to setup
>>> django-honeypot and move the admin site to something non-standard.
>>>
>>> Any one thing may not be doing much on it’s own. But the combination, if
>>> messy enough to make someone give up, will give you a better overall
>>> security situation.
>>>
>>> Just my 2¢.
>>>
>>> Onward,
>>> Arvind
>>>
>>> On 19 Nov 2020, at 23:32, r...@whidbey.com wrote:
>>>
>>> FWIW, I agree with Tim and Carlton.  There doesn't seem to me to be a
>>> compelling argument for recommending developers to change the default
>>> "/admin" url.  Any security concerns would hopefully be addressed by actual
>>> security safeguards rather than changing names to something non-standard.
>>>
>>> On Thursday, November 19, 2020 at 7:44:21 AM UTC-8 carlton...@gmail.com
>>> wrote:
>>>
>>>> On this topic, a ticket proposing to prepend the project name to the
>>>> `admin/` URL in the default project template was opened.
>>>> https://code.djangoproject.com/ticket/32209
>>>>
>>>> Given that it's the exact discussion we're having here, I've paused
>>>> that to see if there's a consensus for a change.
>>>>
>>>> Thanks. C.
>>>>
>>>> On Thursday, 19 November 2020 at 12:35:00 UTC+1 shan...@gmail.com
>>>> wrote:
>>>>
>>>>>  I've got this idea with the usage of json files that require some
>>>>> keys which is authenticated for a single user which seems to excite me for
>>>>> fact that if this was similar for admin/, then it'd give django a overhead
>>>>> advantages for future use.
>>>>>
>>>>> On Thu, 19 Nov, 2020, 4:09 pm Carlton Gibson, 
>>>>> wrote:
>>>>>
>>>>>> I think I'd come down as -1 for a system check here...
>>>>>>
>>>>>> They're not costless, there's a tendency to want to add a new system
>>>>>> check for every possible configuration choice, but, beyond implementing 
>>>>>> and
>>>>>> maintaining, the danger is it leads to too mu

Re: Adding a security concerned feature

[Collin Anderson]

Hi All,

I think at minimum we should change the default admin url for new projects, 
as that's very easy to do, and it does provide a lot of value for new 
projects. This helps Django to be secure by default.

I use the default /admin/ url for my projects and bots are regurarly trying 
different password combinitations. In addition, security scanners are now 
starting to warn if you have an /admin/ url visible on your website.

It would be a ton of work for me to change it, but it would be trivial if 
this were a new project.

I think adding the project name as a prefix would help a lot and be very 
easy to do.

https://github.com/django/django/compare/master...collinanderson:patch-14

(and then the docs would need to be updated too.)

Thanks,
Collin


On Thursday, November 19, 2020 at 7:11:59 PM UTC-5 arvind...@gmail.com 
wrote:

> A security model doesn’t necessarily have to be any one thing that’s 100% 
> secure. It can be a combination of things which include “actual” security 
> features as well as plain ol’ obscurity.
>
> If I have to register the admin urls on a project, I make sure to setup 
> django-honeypot and move the admin site to something non-standard.
>
> Any one thing may not be doing much on it’s own. But the combination, if 
> messy enough to make someone give up, will give you a better overall 
> security situation.
>
> Just my 2¢.
>
> Onward,
> Arvind
>
> On 19 Nov 2020, at 23:32, r...@whidbey.com wrote:
>
> FWIW, I agree with Tim and Carlton.  There doesn't seem to me to be a 
> compelling argument for recommending developers to change the default 
> "/admin" url.  Any security concerns would hopefully be addressed by actual 
> security safeguards rather than changing names to something non-standard.
>
> On Thursday, November 19, 2020 at 7:44:21 AM UTC-8 carlton...@gmail.com 
> wrote:
>
>> On this topic, a ticket proposing to prepend the project name to the 
>> `admin/` URL in the default project template was opened. 
>> https://code.djangoproject.com/ticket/32209
>>
>> Given that it's the exact discussion we're having here, I've paused that 
>> to see if there's a consensus for a change. 
>>
>> Thanks. C.
>>
>> On Thursday, 19 November 2020 at 12:35:00 UTC+1 shan...@gmail.com wrote:
>>
>>>  I've got this idea with the usage of json files that require some keys 
>>> which is authenticated for a single user which seems to excite me for fact 
>>> that if this was similar for admin/, then it'd give django a overhead 
>>> advantages for future use.
>>>
>>> On Thu, 19 Nov, 2020, 4:09 pm Carlton Gibson,  
>>> wrote:
>>>
 I think I'd come down as -1 for a system check here... 

 They're not costless, there's a tendency to want to add a new system 
 check for every possible configuration choice, but, beyond implementing 
 and 
 maintaining, the danger is it leads to too much noise. 
 If you get a system check warning, you shouldn't be tempted to ignore 
 it. In general I think reserving the built-in checks slightly means they 
 don't get devalued. (Folks are free, and encouraged, to implement, and 
 share, their own checks to enforce project-level standards.)

 I think it's not sufficiently clear-cut that using `/admin/` is a bad 
 idea to justify including a check. 

 (On a personal note, I like to use `/admin/`, configure nginx to only 
 serve the admin from the localhost, and then use an SSH tunnel to access 
 it 
 remotely, so I'd have to silence a system check here.) 

 C.

 On Wednesday, 18 November 2020 at 22:15:38 UTC+1 Carles Pina Estany 
 wrote:

>
> Hi, 
>
> I wasn't convinced about changing the 'admin' path until recently. My 
> reasons to change the path of 'admin' are: 
>
> -A bit less likely to be affected by bugs like 
>
> https://docs.djangoproject.com/en/3.1/releases/3.0.1/#cve-2019-19844-potential-account-hijack-via-password-reset-form
>  
> : at least the site wouldn't appear in automatic scans for 
> vulnerabilities (if checking Django versions based on the admin 
> template, etc.) . The bug/exploit might have been known before the fix 
> was implemented (and everyone updated) so I prefer to not be exposed 
> (or 
> less exposed) 
>
> -At the moment in Django there is no rate-limiting login attempts "out 
> of the box" so I prefer to avoid the opportunity if possible 
>
> -Partially out of my control: an 'admin' user might have used the same 
> password in another place and the password got leaked 
>
> Other people might have other reasons. 
>
> Cheers, 
>
> On Nov/18/2020, Tim Graham wrote: 
> > I'm not convinced that a system check promoting security by 
> obscurity adds 
> > much value. The original poster wrote "sometimes it can be a 
> security 
> > concern." Maybe that's the case (how so?) but for most sites I would 
> say 
> > it's 

Re: Removing url() ?

[Collin Anderson]

> I also understand that if seven years wasn't enough time to get around to 
doing this, ten years also wouldn't be enough. If we postpone this to 2027 
(and if Django and all of us are still around), then in 2025 or so when the 
deprecation warning starts being reintroduced we'll be asked for yet 
another extension, and every argument being made in favor of extension in 
this thread will be as applicable on that day as it is today.

Ok fine. No 10 year end date. Please keep it forever/indefinitely.

I feel like Django keeps failing to deliver on its API stability 
promise. https://docs.djangoproject.com/en/3.0/misc/api-stability/

> All the public APIs (everything in this documentation) *will not be moved 
or renamed without providing backwards-compatible aliases*.

> If new features are added to these APIs – which is quite possible – they 
will not break or change the meaning of existing methods. In other words, 
“stable” does not (necessarily) mean “complete.”

> If, for some reason, an API declared stable *must be removed or replaced*, 
it will be declared deprecated but will remain in the API for at least two 
feature releases. Warnings will be issued when the deprecated method is 
called.

I don't see a good reason as to why url() "Must be removed or replaced".

> There's also no reason why url() in particular should be given special 
treatment that other deprecated features or APIs don't get. Some other 
old-time bits went far more quickly: render_to_response(), for example, got 
the standard deprecation cycle, and was removed for good in 3.0. The old 
django.core.urlresolvers module went away in 2.0. We've also long since 
gotten rid of the patterns() helper in favor of just defining URLs as a 
standard Python list. All of those were "useless code churn" -- the 
previous functions/modules worked just fine, after all. But they're all 
gone, and if you run on a supported Django version you've either dealt with 
those changes or (in the case of render_to_response()) will deal with them 
sometime in the near future.
> So again, I don't think we should make an exception here. Doing an 
ultra-ultra-extended deprecation cycle on url() beyond the current merely 
ultra-extended one would be a bad precedent for Django's future evolution, 
and I don't see any argument for it being a unique or painful enough change 
to justify such handling.

If exception/special treadment is an issue, then I'd suggest making this an 
official policy change going forward. I would be much happier if all of the 
examples you gave were still around with warnings. All of those upgrades 
were annoying. I think an ultra-ultra-extended deprecation cycle would be a 
good precedent. I think it makes Django more attractive as a potential 
platform for people to build their website on. I don't see it getting in 
the way of future evolution. Could you say more?

> I think this discussion is analogous to the Python discussion about the 
removal of the ABCs from collections -- they were moved to collections.abc 
in 3.3, but a shim was kept; it was slated to be dropped in 3.9 (up to 3.8 
there was reason to keep the shim for compatibility with 2.7), but the 
intention to execute was met with protests a lot like Collin's. The 
deprecation warnings have been loud since 3.7, but the uproar, AFAICT, only 
came with the code change in master towards 3.9.

Right, yeah I'm trying to catch this as soon as the warning is introduced, 
rather then when url() is actually removed. I feel like collections.abc is 
a much rarer thing, however, pretty much every Django project that started 
pre 2.0 uses url().


On Tuesday, May 5, 2020 at 4:39:35 PM UTC-4, James Bennett wrote:
>
> On Tue, May 5, 2020 at 1:05 PM Collin Anderson  > wrote:If it were 10 years from the proposal being accepted 
> (2017 to 2027), I think that would be fine for removal then. It allows for 
> a more natural upgrade as path() becomes more and more common. I don't see 
> keeping url() around as slowing down Django's ability to evolve over time. 
> It makes it easier for people to upgrade, which means more projects will 
> use newer versions of django, which is a huge benefit to Django's ability 
> to evolve.
>
> I just published a kind of rant-y thing about the Python 2/3 transition, 
> so that's at the forefront of my mind. And honestly I think one lesson 
> learned there applies here too: once you get into a timeline of N years, 
> for sufficiently large N, arguments that "N years is not enough time to 
> port, but N+K years would be" simply don't hold up.
>
> I understand as well as anyone that it takes work to keep up with evolving 
> platforms, and that it can feel unrewarding to do that work -- url() 
> already exists and works, why should I have to change to callin

Re: Removing url() ?

[Collin Anderson]

> I don't think that we can revert [1] without a technical board approval 

Needing technical board approval to keep url() seems fair to me.

I think most of the 2522559 changes are ok. I'd be fine if we only made 
these changes:

https://github.com/django/django/compare/master...collinanderson:keepurl?expand=1


Re migration, we also need to change the imports from "django.conf.urls" to 
"django.urls". I think this is the sort of thing that changes an effortless 
django upgrade into an annoying django upgrade. Is it really worth it to 
force people to do this? Should Django be developer friendly?

> you have 4 more years to do this
If it were 10 years from the proposal being accepted (2017 to 2027), I 
think that would be fine for removal then. It allows for a more natural 
upgrade as path() becomes more and more common. I don't see keeping url() 
around as slowing down Django's ability to evolve over time. It makes it 
easier for people to upgrade, which means more projects will use newer 
versions of django, which is a huge benefit to Django's ability to evolve.


On Tuesday, May 5, 2020 at 3:06:12 PM UTC-4, Mariusz Felisiak wrote:
>
> TBH, I don't see a reason to create a precedent and deprecate it without 
> any removal plans. Deprecation and removal is described in DEP 201, I don't 
> think that we can revert [1] without a technical board approval 🤔 I 
> would like to highlight that url() is an alias for re_path() so as far as 
> I'm concerned migration is really straightforward and it's not 
> time-consuming, you can use a short script to update all calls, e.g. [2], 
> and you have 4 more years to do this.
>
> Best,
> Mariusz
>
> [1] 
> https://github.com/django/django/commit/2522559d1a612a4e8885de4780ff2b7aa7b8d375
>  
> 
> [2] https://gist.github.com/felixxm/210e2a241c5ac17f5d2e569c31e1354c
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/19813a63-27dd-458c-93f5-769f504dfc08%40googlegroups.com.

Getting rid of url()

[Collin Anderson]

Hi All,

Are we ok getting rid of url()?

Yesterday url() was officially slated for removal in [ticket #31534], and I 
know it was discussed and agreed upon back in [2017], even in a DEP, but I 
feel like the amount of work it would take to maintain the [shim] is near 
zero, and the total amount of programmer hours that will need to happen 
because of this change is a lot more that than. I realize it's "just" a 
project-wide find/replace from url() -> re_path(), across my ~20 projects, 
but it still seems totally useless to me. Don't we want to make upgrading 
django as easy as possible? Is getting rid of url() really worth it?

Back in 2017, the reasoning was:
"Given that it is currently used in 100% of Django projects, the smooth 
path for users would be to not deprecate django.conf.urls.url immediately, 
but to mark it as deprecated in version 3.0 (after 2.2 LTS) and remove it 
in 4.0 (after 3.2 LTS). Hopefully many projects will migrate to 
django.urls.path (the carrot) before being forced to migrate to 
django.urls.re_path (the stick)."

I haven't migrated yet, and I suppose I still have about ~3 more years to 
do it if I want to stay up to date, but that's a question of when, not if.

Again, we _could_ [deprecate without removing] if we want.

To be clear, I think the new path() was a really good improvement for 
django, and we should encourage using re_path() instead of url(), I just 
think we should maintain url() backwards-compatibility even longer, if not 
indefinitely, but maybe that's just me.

Thanks,
Collin


[ticket 
#31534] 
https://github.com/django/django/blob/f2051eb8a7febdaaa43bd33bf5a6108c5f428e59/django/conf/urls/__init__.py
[2017] 
https://groups.google.com/d/topic/django-developers/D44LSp0bPg8/discussion
[shim] https://github.com/django/django/blob/master/django/conf/urls/__init__.py
[deprecate without 
removing] 
https://groups.google.com/d/topic/django-developers/asqnjcYPnms/discussion

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a8aab648-34bf-4318-8361-2a1c43f33c36%40googlegroups.com.

Re: Removing url() ?

[Collin Anderson]

> Without raising eventually-loud deprecation warnings (further along in 
the cycle), people who still have url() in their codebases might never even 
find out that the
simplified DEP 201 URL routing is available. Raising a deprecation warning 
makes sure they find out; some projects will undoubtedly just
find-and-replace url() to re_path(), but others will probably be happy to 
find out that the simpler path() routing exists.

Yes, I'm totally fine with raising a warning, as it brings path() to 
people's attention. I just think the url() -> re_path() migration should be 
an optional thing. People who care about code quality will see the warning 
and make the change. Those who don't care about slighty higher code quality 
will get a warning, but at least Django isn't forcing them to do something 
they don't care at all about. Their code will still run just fine on newer 
versions of Django.


On Tuesday, May 5, 2020 at 1:04:02 PM UTC-4, James Bennett wrote:
>
> On Tue, May 5, 2020 at 8:42 AM Collin Anderson  > wrote: 
> > Is this really worth it? It's only a few lines of code to keep backward 
> compatibility, and it seems to me it would take almost no work to maintain 
> that compatibility shim compared to the countless programmer hours needed 
> to upgrade their code, including many unpaid programmers working on open 
> source projects. I'll personally need to do a find/replace for url() to 
> re_path() across my ~20 projects, and update all of the imports. Isn't this 
> useless code churn? 
>
> I think it should be deprecated and removed. 
>
> On the one hand, we're talking about an extremely long (~7 years) 
> timeline from when re_path() was introduced to when it would become 
> mandatory for projects that need regex-based URL routing. That seems 
> like plenty of time for projects to notice that a new URL routing 
> approach was adopted. And that's a long, *long* time to keep 
> effectively-dead code in Django, far longer than what the normal 
> deprecation cycle would be. 
>
> On the other hand, if it doesn't get removed, it sets a bad precedent 
> -- Django needs to be able to evolve over time, and part of that is 
> ensuring that once something is no longer the recommended approach it 
> gets removed from the framework. Without raising eventually-loud 
> deprecation warnings (further along in the cycle), people who still 
> have url() in their codebases might never even find out that the 
> simplified DEP 201 URL routing is available. Raising a deprecation 
> warning makes sure they find out; some projects will undoubtedly just 
> find-and-replace url() to re_path(), but others will probably be happy 
> to find out that the simpler path() routing exists. 
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/9e746ca4-97b8-4fd0-8bfb-4fa377c26b87%40googlegroups.com.

Removing url() ?

[Collin Anderson]

Hi All,

Are we _sure_ we want to completely get rid of url()?

Yesterday, url() was given a RemovedInDjango40Warning [PR]. The removal was 
approved as part of the new path() syntax back in 2017 [DEP 0201].

Is this really worth it? It's only a *few lines of code* to keep backward 
compatibility, and it seems to me it would take *almost no work to maintain* 
that compatibility shim compared to the countless programmer hours needed 
to upgrade their code, including many unpaid programmers working on open 
source projects. I'll personally need to do a find/replace for url() to 
re_path() across my ~20 projects, and update all of the imports. Isn't this 
*useless 
code churn*?

Yes, there's an advantage to having one and only one way to do it, so I 
agree we should encourage people to use re_path() instead of url(), but 
shouldn't we also make it *as easy as possible to upgrade django*? Is 
getting rid of url() really worth the cost?

Yes, the removal is still ~3+ years away, but that's a question of _when_ 
not _if_.

If we want, we _could_ deprecate url() without giving it an actual removal 
date [Compatibility Discussion] and leave the compatibility shim around 
longer, if not indefinitely.

Thanks,
Collin


[PR] https://github.com/django/django/pull/12855

[DEP 0201] 
https://github.com/django/deps/blob/master/final/0201-simplified-routing-syntax.rst

[Compatibility 
Discussion] 
https://groups.google.com/d/topic/django-developers/asqnjcYPnms/discussion

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/17899c17-2c07-4a80-baa5-e0a348d9512c%40googlegroups.com.

Re: Adding ability to choose AutoField type (signed vs unsigned)

[Collin Anderson]

Having a DEFAULT_AUTOFIELD setting makes sense to me.

On Monday, April 6, 2020 at 12:48:10 PM UTC-4, Adam Johnson wrote:
>
> Jure - yes switching the setting should generate migrations for all 
> affected models. The migration guide would cover changing models' primary 
> key fields to PositiveBigAutoFields one at a time, perhaps with a mixin as 
> you've suggested. Maybe Django should provide such a mixin to ease the 
> migration.
>
> primary keys might be GUID
>>
>
> The proposal is not to move to GUID's/UUID's, as you've used in your 
> example. It's to move to bigger integers.
>
> UUID's are a bad idea for database performance, as they distribute 
> randomly across the table, preventing any cache wins. On autoincrement 
> tables, the tail end of each table is normally most frequently read and 
> written and thus cached in memory. I don't think Django should ever suggest 
> UUID's as primary keys.
>
> On Mon, 6 Apr 2020 at 16:46, Jure Erznožnik  > wrote:
>
>> Sorry if I understand stuff incorrectly, but:
>>
>> I agree with Adam where he discusses migration issues, but I also don't 
>> see how "DEFAULT_AUTOFIELD" setting could leave tables out of the 
>> migration(s). 
>>
>> My understanding is that it would cause immediate re-provisioning of all 
>> the pk fields, including in the core django modules and third-party 
>> modules. Some of them might have programmed their logic such as to include 
>> some integer math around the primary keys (and now all auto primary keys 
>> might be GUID).
>>
>> If I understand the above correctly, the setting would have to be 
>> per-module. Could it simply be done like this:
>>
>> class PKMixin(object):id = models.UUIDField(primary_key=True, )
>>
>> Naturally, then all desired models would (also) derive from this mixin. A 
>> bit of a chore, but it would not require reconfiguration of all migrations, 
>> just the ones the programmer would specify - and would only be limited to 
>> their own module.
>>
>> OTOH, JUST FOR the unsigned vs signed integer PK, it should be relatively 
>> easy to modify makemigrations code detect existing migrations for the 
>> model, detect that the only difference is IntegerField vs 
>> PositiveIntegerField and in this case skip generating the migration (for 
>> migrating the field to an unsigned one). There could also be a flag to the 
>> management command specifying to force generating said migrations.
>>
>> Of course, ignore if this is gibberish.
>>
>> LP,
>> Jure
>>
>>
>> On 06/04/2020 17:11, Adam Johnson wrote:
>>
>> I'm in favour of the move. The setting strategy seems appropriate.
>>
>> Simon's comment on the PR that this affects a small % of projects is 
>> true. But if your project does reach that scale, you're probably one of the 
>> bigger Django organizations in the world - hopefully key advocates for the 
>> framework. It's also possible to hit this on smaller projects with tables 
>> that import a lot of new rows, such as rolling time series data imports.
>>
>> Also, this problem is *highly* asymmetric. Unnecessarily using big PK 
>> fields wastes a little storage space - unlikely to be noticed. Migrating to 
>> big PK fields can be a massive task (and can feel like "Django let you down 
>> here with bad defaults") ("Ruby on Rails does it right!").
>>
>> It will need a careful migration guide though. Pre-existing projects may 
>> need to migrate one table at a time to reduce downtime/load, or keep the 
>> setting to the smaller auto field forever. I'm happy to help with this.
>>
>> One thing we *could* add is a deploy time system check (or a management 
>> command, or something), to check what % of your tables' autofields' PK 
>> values have been "used up." This allows larger projects to prioritize their 
>> migrations.
>>
>> On Mon, 6 Apr 2020 at 15:37, Caio Ariede > > wrote:
>>
>>> Hi folks,
>>>
>>> I’ve been working on ticket #56 "Primary key columns should be UNSIGNED"  
>>> (really old) for a while now. It’s cumbersome and hard to fix for some 
>>> reasons, including backwards compatibility, nothing that a single PR can 
>>> solve but I’ll try to summarize where things are at this moment. Hopefully 
>>> we can get to a consensus so I can continue.
>>>
>>> The problem: Django has been storing primary keys as signed integers 
>>> since the beginning and this is considered a waste of resources. Very few 
>>> people seem to use negative values as primary keys, apparently.
>>>
>>> The desired solution: We want to change that in a backwards-compatible 
>>> way to not cause migrations to happen in all projects using Django, in all 
>>> of a sudden. This is where things start to get difficult.
>>>
>>> These are the links for the related ticket and PR up to this point:
>>>
>>> https://code.djangoproject.com/ticket/56 (Primary key columns should be 
>>> UNSIGNED)
>>> https://github.com/django/django/pull/11900 (PR)
>>>
>>> —
>>>
>>> While I was working on PR 11900, I stumbled across this other PR 8924 
>>> "BigAutoField as

Re: More standard template filters

[Collin Anderson]

I think it would be helpful to have builtin startswith, endswith and 
contains filters.

On Thursday, January 23, 2020 at 4:40:32 PM UTC-5, keshav kumar wrote:
>
> There are already filters which works on advance logic. for example :- 
> 'join'. So, is it not good to add filter for startswith, endswith and 
> contains as well? 
>
> On Friday, 5 April 2019 14:46:53 UTC+5:30, Adam Johnson wrote:
>>
>> FYI Jinja2 allows (most) python expressions, so this would Just Work(TM):
>>
>> {{  myvar.startswith("x") }}
>>
>> Django Template Language has a lot of legacy that prevents this from 
>> happening, afaiu it would not be possible to move to it.
>>
>> It's not hard to move your templates (asides from those extending 
>> external packages like the admin) to Jinja2, since the syntax is very 
>> similar and you can pop a Jinja2 backend in your TEMPLATES.
>>
>>
>>
>> On Fri, 5 Apr 2019 at 07:43, Curtis Maloney  wrote:
>>
>>> On 4/5/19 3:06 AM, Collin Anderson wrote:
>>> > Hi All,
>>> > 
>>> > I use django templates a lot and I always wished there was a 
>>> > myvar|startswith:"teststring", myvar|endswith:"teststring" and a 
>>> > myvar|contains:"teststring" filter.
>>>
>>> It's almost like we need a syntax for calling methods with an argument, 
>>> just like we can with filters.
>>>
>>> For example (bring on the sheds for bikes!)
>>>
>>>  {{ myvar.startswith<"teststring" }}
>>>
>>> > I instead do stuff like myvar|slice:":10" == "teststring" which is a 
>>> > total hack.
>>> > 
>>> > Is this something that could be simple and common enough to add to 
>>> > django as batteries-included built-in?
>>>
>>> Alternatively, I recall some time in the past I may have written a 
>>> "strings" template filter library simply to provide string methods as 
>>> filters...
>>>
>>> --
>>> Curtis
>>>
>>> -- 
>>> 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-d...@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/a2b323bc-9f60-f4c9-6074-4d103bd6f930%40tinbrain.net
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>> -- 
>> Adam
>>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/567c54a9-2496-4619-9d6c-59758921c8ce%40googlegroups.com.

Re: Proposal: Allow ManyToMany using a intermediary table to be defined as symmetrical

[Collin Anderson]

Hi Nadège,

Sorry for the delay. Yeah, when I was working on PR 8981, I ran into the 
symmetrical case and wasn't sure what the behavior should be, so I left the 
check in place to not allow the behavior. I asked my self the same question 
you did about possibly needing "through_reverse_defaults" and didn't have 
answer. I also didn't have a use-case for symmetrical with 
intermediary/through. I wasn't sure about other unintended consequences and 
just wanted to get the rest of the change out the door.

If you think "both objects should have the same value" then I'd say go for 
it. I suppose it does make sense considering it's supposed to be 
symmetrical as you said. If later people want through_reverse_defaults we 
could always add it later.

Thanks,
Collin


On Tuesday, April 23, 2019 at 8:13:35 AM UTC-4, Nadège Michel wrote:
>
> Hello,
>  
> We use self.referencing ManyToMany relationships with intermediate tables 
> in our work project 
> and I was wondering why we had to create ourselves the reverse link when 
> we need the relationship to be symmetrical.
> I looked at the 'symmetrical' attribute documentation and though we should 
> just set it to True instead of False, 
> but you may know that it triggers the error "fields.E332 Many-to-many 
> fields with intermediate tables must not be symmetrical.".
>
> I searched for a corresponding existing ticket a found this one which is 
> kind of related https://code.djangoproject.com/ticket/9475
> And you can see in the PR some discussion about the check 
> https://github.com/django/django/pull/8981#discussion_r247946460
> Thanks to the work of Collin Anderson in the previous PR I think we can 
> now remove that check.
>
> Questions I had:
>
>- retro compatibility?
>
> As the current behavior forces the user to set 'symmetrical=False', the 
> change is retro-compatible.
>
>- use 'through_defaults' when creating both objects or define a new 
>'through_reverse_defaults' to give different values for each row? 
>
> if you want symmetrical relationship, both objects should have the same 
> values 
> so I chose to use 'through_defaults' for both objects. Which was also what 
> was done in the #8981 
> <https://github.com/django/django/pull/8981#discussion_r247946460> PR in 
> the first place.
>
> I have a patch 
> <https://github.com/django/django/compare/master...nadege:allow-m2m-intermediate-symmetrical>
>  
> with theses changes:
>
>- removed the check 
>- removed tests for that check
>- added tests (tests/m2m_through, tests/m2m_recursive)
>- updated documentation (may need a bit more work)
>- added back the use of 'through_defaults' of #8981 
><https://github.com/django/django/pull/8981#discussion_r247946460> in 
>the:
>
> if self.symmetrical:  
> self  ._add_items(...) 
>
> Tests suite runs fine.
>
> Any thoughts on this design change / new feature?  
> I'll be happy to create a ticket and submit my patch for reviews :) 
>

-- 
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/4ef6730a-1f81-456c-9e05-7373da73da5e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 2020 Authentication Initiativ

[Collin Anderson]

Email + password auth is definitely a wanted feature out-of the box, and
probably a good first step would be to create a separate AbstractEmailUser
or something like that. Seems to me AbstractUser shouldn't be changed for
backwards compatibility reasons, but maybe something like a
BaseAbstractUser would be helpful?

And here's a past discussion and ticket (from 5 years ago):
https://groups.google.com/d/topic/django-developers/7feYlp9HqKs/discussion
https://code.djangoproject.com/ticket/20824

Also related: UserCreationForm by default allows usernames that differ only
by case
https://code.djangoproject.com/ticket/25617

On Wed, Apr 10, 2019 at 7:12 AM Barnaby  wrote:

> If we go to the most common use case, email + password is the current
> "default" of the web, rather than username + password. It would make sense
> for Django to use email + password by default.
>
> It also feels like first_name and last_name have no place in AbstractUser
> and should me moved to NamedAbstractUser or something.
>
> So we'd remove username, first_name and last_name by default.
>
> Regarding other means of authentication, I don't know if Django should
> support any out-of-the-box. Magic Links could be a decent default but they
> do raise security issues and require email setup.
>
> --
> 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/2ec07906-8a2a-4b63-a850-99e8fef95b5a%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/CAFO84S5ki%3DtuPCZyXf2e_%2Bq%3D7V8Q1a6RX3EJycx51BodwnJZBA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Specifying model relationship as string vs concrete model class

[Collin Anderson]

models.Foreignkey(User) is a more pythonic and allows more better analysis
by tools like flake8, but in some cases you need to create the ForeignKey
before User is defined, so you _have_ to use a string. Example:

https://docs.djangoproject.com/en/stable/ref/models/fields/#foreignkey

On Sat, Apr 6, 2019 at 11:53 PM Mohit Solanki 
wrote:

> Since Django allows specifying relationship between models by both as a
> string or by a model class
> "models.Foreignkey('User') vs "models.Foreignkey(User)". Which one is
> preferred and recommend and what are the downsides of choosing one over the
> other? In documentation all the examples are of the second form but i have
> seen ppl specifying relationships in string. Can someone please elaborate
> more on this?
>
> Regards,
> Mohit Solanki
>
> --
> 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/CAKB6Ln-4rU2c%3DZL%3DTCbYfFZWG8fSDq4KP9DYhUc4TDFLNFdQtw%40mail.gmail.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/CAFO84S6m4aog8bm0gwJ14K4wH4x7o-DsYk1Hf2MqSmic6qgESw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

More standard template filters

[Collin Anderson]

Hi All,

I use django templates a lot and I always wished there was a 
myvar|startswith:"teststring", myvar|endswith:"teststring" and a 
myvar|contains:"teststring" filter.

I instead do stuff like myvar|slice:":10" == "teststring" which is a total 
hack.

Is this something that could be simple and common enough to add to django 
as batteries-included built-in?

Thanks,
Collin

-- 
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/4d465a4c-6d8c-498e-8310-d03dce5338ce%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Password reset emails in combination with click tracking do not work with Intelligent Tracking Prevention on Safari for iOS 12 and macOS Mojave

[Collin Anderson]

I wouldn't mind just rolling back the security fix (or maybe making a 
straightforward way to enable/disable the behavior). We could instead 
encourage people to use  on any links (from the 
password rest page) to untrusted urls.

On Friday, February 22, 2019 at 5:03:01 AM UTC-5, Henrik Ossipoff Hansen 
wrote:
>
> Just wanted to chime in and say we also experienced this issue. We ended 
> up having to revert the security fix that was added to the view in Django 
> just to avoid the flood of customers reporting they couldn't reset their 
> passwords on our apps anymore - so I'm assuming this affects a lot of users 
> out there.
>
> torsdag den 21. februar 2019 kl. 14.48.45 UTC+1 skrev Mat Gadd:
>>
>> You can see this in action yourself using Chrome's Dev Tools. Open Dev 
>> Tools, then their Settings, and turn on "Auto-open DevTools for popups". 
>> Then, click any link in the Gmail web app. You'll see you go via 
>> google.com/url?q=original_url_here. Since they're doing this with 
>> JavaScript, the links look like they're going to open the real URL, but 
>> they *don't.*
>>
>> On Thu, 21 Feb 2019 at 10:44, Mat Gadd  wrote:
>>
>>> Exactly that, yes. We've disabled all click tracking that we can, but 
>>> Gmail has its own redirect which causes Safari's privacy features to kick 
>>> in. (Some?) Gmail users are unable to use the password reset emails.
>>>
>>> On Thursday, 21 February 2019 01:03:54 UTC, Philip James wrote:

 Mat, are you saying you're seeing Safari still blocking, even with 
 click tracking turned off, because GMail itself is inserting a redirect?

 PJJ
 http://philipjohnjames.com


 On Wed, Feb 20, 2019 at 4:46 AM Mat Gadd  wrote:

> We're also now seeing Gmail users complain that the password reset 
> links don't work, even after we disabled click tracking. It seems that 
> Google are inserting their own click tracking into users' emails, which 
> is… 
> weird?
>
> The markup of links is transformed to the following (where … is our 
> original URL):
>
> https://www.google.com/url?q=…";>Link text here
>
> Gmail is a *huge* provider of emails, and they make up around 54% of 
> our user base. Anyone using the Gmail web app can no longer reset their 
> password simply by clicking the link in the email. 
>
> On Wednesday, 23 January 2019 12:51:22 UTC, Perry Roper wrote:
>>
>> It would appear that this affects a large number of users. We're also 
>> experiencing this in the following configurations.
>>
>> - Mailgun click tracking enabled + Safari 12.0 on MacOS or any 
>> browser in iOS 12
>> - Clicking the link in the Gmail app or web app (Mailgun click 
>> tracking disabled) + Safari 12.0 on MacOS or any browser in iOS 12.
>>
>> All iOS 12 browsers and MacOS Safari users using the Gmail app, or in 
>> any email client if the site they are requesting a password from uses 
>> link 
>> tracking.
>>
>> On Thursday, 22 November 2018 20:43:15 UTC+7, Mat Gadd wrote:
>>>
>>> Hi all,
>>>
>>> I raised a ticket  
>>> regarding this and was directed here to discuss the topic. The summary 
>>> is 
>>> that the combination of using click-tracking redirects (which are 
>>> popular 
>>> with a variety of email providers) with the Django contrib.auth 
>>> password 
>>> reset views does not work in Safari on macOS and iOS as of the latest 
>>> major 
>>> versions.
>>>
>>> It took me quite a long time to work out what was happening, so I 
>>> wanted to at least raise a ticket where other people might find it, but 
>>> was 
>>> also hoping to start a discussion around how else the problem could be 
>>> mitigated. An option to disable the internal token redirect might be 
>>> useful, but that then re-opens the token up to being leaked via the 
>>> HTTP_REFERER header.
>>>
>>> Regards,
>>>  - Mat
>>>
>> -- 
> 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/c10f608f-7f5e-4bba-aa89-4779e37d61f0%40googlegroups.com
>  
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
 -- 
>>> You received this message because you are subscribed to the Google 
>>> Grou

Re: include only columns from selected related models in select_related query

[Collin Anderson]

So would you "defer" the other columns like "only()"?

If nothing else, you could try using .annotate(F('author__hometown')) (not
sure if that works) or .values('author__hometown') to just get the values
you need.

On Mon, Feb 11, 2019 at 5:50 AM Riccardo Magliocchetti <
riccardo.magliocche...@gmail.com> wrote:

> Hello,
>
> I'm debugging views leaking lots of memory in django 1.11. It looks like
> there
> is some connections with my usage of select_related(). But that's mail is
> not
> about that, not sure about my findings yet :)
>
> So I have looked again at the select_related documentation here:
> https://docs.djangoproject.com/en/2.1/ref/models/querysets/#select-related
>
> and found this:
> Book.objects.select_related('author__hometown').get(id=4) will cache the
> related
> Person and the related City
>
> Up until now i thought that only the related model i've specified would
> get
> added to selected columns e.g. only the City because of hometown. But it
> looks
> that's not how it is :)
>
> Would it make sense to add a parameter to change select_related behaviour
> to
> include only the columns of the related models specified? That could save
> quite
> a lot of bandwitdh for some use cases.
>
> What do you think?
>
> Thanks
>
> --
> Riccardo Magliocchetti
> @rmistaken
>
> http://menodizero.it
>
> --
> 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/a42050d3-25a2-2f47-c841-918d7d085757%40gmail.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/CAFO84S5M8o1ONpfm%3D27ofFRcYCeU%2B-pGxNmTbm7q1kKC6Mk64w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Automating the process of creating models from the data file provided

[Collin Anderson]

Hi Abhilasha,

This is ringing a bell. I almost started working on an "inspectfile"
feature many years ago as a Google Summer of Code project.

https://groups.google.com/d/topic/django-developers/z88grOaxEHU/discussion

https://groups.google.com/d/topic/django-gsoc/V9FdRVZ7gMg/discussion

I ended up deciding not to do it, so I don't have much else to offer you
for guidance :)

Collin

On Thu, Feb 7, 2019 at 6:34 AM Abhilasha Jha 
wrote:

> Hi all,
> I was thinking if a feature could be added to Django models, such that
> when the CSV/ text or any other commonly used data file is added to the
> project and the models are automatically created and populated. I have not
> tried to go through nitty-gritty of the feature, but am thinking of doing
> this and contributing to Django, and needed some guidance on same.
>
> Thanking you
> Abhilasha
>
> --
> 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/122a2d14-088b-4f9e-9bbc-0ea9dc0c7562%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/CAFO84S6imd1kfUW%3DOARQxjOzD0hOYqYFOHSMOwvSwFi7nx5WZg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: revisiting the Python version support policy

[Collin Anderson]

Now that we've dropped Python 2, I personally wouldn't mind having the
policy be to support all supported versions of python (except 2.7) at the
time of each Django release. So Django would drop just after Python drops.
(The most recent version of Django (and maybe LTS too) should probably also
add support for new versions of Python, so we're not holding people back
from trying out the latest Python.) But I don't have a good feel for what
the maintenance burden is for supporting old versions of Python, so I don't
see first-hand the advantages of dropping earlier. Now that we're 3.x-only,
I don't like the idea of "driving the ecosystem forwards" being an excuse
for dropping Python early. I agree "allowing users to easily use and
install django based applications" is more important.

I also like the idea of "amending the Python support version policy to
account for the Python version in Debian stable", as that's a little more
practical, though we start play favorites with distros.


On Tue, Jan 22, 2019 at 10:04 AM Federico Capoano <
federico.capo...@gmail.com> wrote:

> I would ask: what are the pros and cons of dropping support for python 3.5?
>
> I think allowing users to easily use and install django based applications
> is more important than strictly follow a python version support policy.
>
> I think that if we drop support for python 3.5, which is the default
> python version on many linux platforms right now, we will make the life of
> our users and developers harder.
> I don't understand the reason for doing so, if we have to do it for a good
> reason, like a security issue, or because django has to take advantage of
> features that are available only from python 3.6 onwards, I would be in
> favour, but if we have to do it only because the policy says so, without
> any other advantage, I would amend the policy.
>
> My 2 cents.
>
> Thanks for your hard work maintaining django
> Federico
>
>
> On Monday, January 21, 2019 at 10:56:40 AM UTC-5, Tim Graham wrote:
>>
>> When deciding when to drop support for Python 2 in Django, there was
>> consensus to adopt this Python version support policy [0]: "Typically, we
>> will support a Python version up to and including the first Django LTS
>> release whose security support ends after security support for that version
>> of Python ends. For example, Python 3.3 security support ends September
>> 2017 and Django 1.8 LTS security support ends April 2018. Therefore Django
>> 1.8 is the last version to support Python 3.3."
>>
>> Since then, we didn't abide by this policy when dropping Python 3.4,
>> mainly because Debian stable still used Python 3.4 at the time and Claude
>> argued that some people like him would have difficulty contributing to
>> Django if they had to install another version of Python [1].
>>
>> Based on the policy, it's time to drop support for Python 3.5 in the
>> master branch (Django 3.0) -- with Django 2.2 LTS supported until April
>> 2022 and Python 3.5 supported until September 2020). I created a ticket [2]
>> and PR [3] for dropping support for Python 3.5 [2], however, Claude
>> commented, "I'm not so enthusiast to drop Python 3.5 now (it is still the
>> default version in Debian stable). Couldn't this be done in Django 3.1
>> instead?"
>>
>> Are you in favor of amending the Python support version policy to account
>> for the Python version in Debian stable?
>>
>> [0]
>> https://docs.djangoproject.com/en/dev/faq/install/#what-python-version-can-i-use-with-django
>> [1]
>> https://groups.google.com/d/msg/django-developers/4rbVKJYm8DI/TTh3i04pBQAJ
>> [2] https://code.djangoproject.com/ticket/30116
>> [3] https://github.com/django/django/pull/10864
>>
> --
> 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/51dfc517-8b5a-4803-9f8d-daa1bf920e7b%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/CAFO84S5kx

Re: [Looking for feedback] Make Admin raw_id_fields the default choice for FKs, or project-wide configurable

[Collin Anderson]

> > One problem with any of the alternatives (besides making it readonly by
default) is that it requires the other model to be registered in the admin
> Off-hand I don't follow you here. Can you explain.

I stand corrected. raw_id_fields doesn't actually require the other model
to be registered.

On Fri, Jan 18, 2019 at 7:25 AM Harro  wrote:

> The problem is that you can't just use it everywhere, like mentioned
> earlier it only works if the other side of the relation is also available
> in the admin (which might not be the case, or only for some of the fields.)
>
> I would say add it to the good old djangosnippets
> <https://djangosnippets.org/> website.
>
> But that's just my 2 cents.
>
> On Friday, 18 January 2019 12:50:52 UTC+1, Josh Smeaton wrote:
>>
>> If we were happy with that particular implementation, then I'd prefer
>> adding it as an official subclass thats importable for users rather than
>> just dumping the code to the docs. But I guess the issue is a slippery
>> slope - how many subclasses do we add for various ModelAdmin use cases.
>> It's definitely an issue that bites many people, and I'd like to see some
>> way forward.
>>
>> On Friday, 18 January 2019 03:52:52 UTC+11, Santiago Basulto wrote:
>>>
>>> Ok, sorry for the Fake News, seems like it's not so complicated to make
>>> one ModelAdmin parent class that provides this behavior. Here's a working
>>> example:
>>>
>>>
>>> from django.contrib import admin
>>>
>>> from django.contrib.admin import widgets
>>>
>>>
>>> class RawFieldModelAdmin(admin.ModelAdmin):
>>> def formfield_for_foreignkey(self, db_field, request, **kwargs):
>>> db = kwargs.get('using')
>>> if 'widget' not in kwargs:
>>> if db_field.name not in (self.get_autocomplete_fields(
>>> request), self.radio_fields):
>>> kwargs['widget'] = widgets.ForeignKeyRawIdWidget(
>>> db_field.remote_field, self.admin_site, using=db)
>>>
>>>
>>> return super().formfield_for_foreignkey(db_field, request, **
>>> kwargs)
>>>
>>> Do you folks think we should add this to the docs? I still think that
>>> having a one-off setting for the "default foreign key" widget would be
>>> valuable, at least for me as a user.
>>>
>>> What do you think?
>>>
>>> On Thursday, January 17, 2019 at 11:27:12 AM UTC-5, Santiago Basulto
>>> wrote:
>>>>
>>>> I think the proposed solution of "you can just extend/subclass
>>>> ModelAdmin" doesn't work, because the fields on different models can have
>>>> different names. I can't just write one global ModelAdmin and then use it
>>>> for all my models, because they'll have different names for their fields.
>>>> Or if it works, it'll need A LOT of introspection (to dynamically check
>>>> which fields are FKs and making them part of raw_id_fields).
>>>>
>>>> Maybe I'm wrong and I'm missing the point, do you folks have an
>>>> implementation of that ModelAdmin superclass to show?
>>>>
>>>> On Thursday, January 17, 2019 at 11:00:42 AM UTC-5, Carlton Gibson
>>>> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On Thursday, 17 January 2019 16:14:31 UTC+1, Collin Anderson wrote:
>>>>>>
>>>>>> One problem with any of the alternatives (besides making it readonly
>>>>>> by default) is that it requires the other model to be registered in the
>>>>>> admin
>>>>>>
>>>>>
>>>>> Off-hand I don't follow you here. Can you explain.
>>>>>
>>>>>
>>>>>
>>>>>> I hope there's _something_ we can do to somehow improve the
>>>>>> situation. Maybe we could at least improve the examples in the
>>>>>> documentation? Maybe give an example in the docs of a ModelAdmin subclass
>>>>>> that defaults to using raw_id?
>>>>>>
>>>>>
>>>>> An example definitely.
>>>>>
>>>>> Maybe we could add an attribute to ModelAdmin with a number: More than
>>>>> this use raw_id — but what would that look like?
>>>>> (Easy subclass rather than a setting...)
>>>>>
>>>> --
> You received this 

Re: [Looking for feedback] Make Admin raw_id_fields the default choice for FKs, or project-wide configurable

[Collin Anderson]

I agree that default load-all-options is an annoying default. I just ran
into this problem again myself in the last few weeks. One problem with any
of the alternatives (besides making it readonly by default) is that it
requires the other model to be registered in the admin, which could be also
be annoying for some people.

I hope there's _something_ we can do to somehow improve the situation.
Maybe we could at least improve the examples in the documentation? Maybe
give an example in the docs of a ModelAdmin subclass that defaults to using
raw_id?

On Thu, Jan 17, 2019 at 7:55 AM Carlton Gibson 
wrote:

> This topic has come up before.
>
> e.g.
> https://groups.google.com/d/topic/django-developers/md39xtT_JEM/discussion
>
>
> (In which Aymeric suggests something similar to Harro's suggestion here.)
>
> On Thursday, 17 January 2019 06:32:15 UTC+1, Harro wrote:
>
>> If you want it in your whole project you could just extend the ModelAdmin
>> and make the raw_id_fields a property that returns all the fields then use
>> that as a base class for all your ModelAdmins,
>> looking at the code the check if it is a foreignkey happens before that
>> in all cases, so having non foreignkey fields in the list shouldn't matter.
>>
> --
> 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/2ba44b9f-6526-4a6a-8311-632e83aeb4ba%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/CAFO84S7zSQUCTgzQn_J2fuJwN54LdMqDhirCU7tp%2BL2odHAoPg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: RFC: #30053 Allow for conditional QuerySet.update_or_create()

[Collin Anderson]

Seems to me a documentation example or improvement could be helpful.

On Mon, Dec 31, 2018 at 11:30 AM Joshua Cannon 
wrote:

> Personally, the snippet suggested in the ticket is sufficient for my needs
> (although I'm saddened by having to duplicate the setattr logic).
> However, I filed the ticket after Googling "Django conditional
> update_or_create" and finding no appropriate solution. You might be right
> about the use case being niche, however others have ran into this too, with
> the proposed solutions being less-than-ideal.
> (I won't link anything here, but searching stackoverflow for "Django
> conditional update_or_create" should lead you to the same question/answers
> I came across).
>
> Perhaps the "solution" here isn't additional code, but rather a section in
> documentation that suggests a solution? It's extremely unfortunate that
> this is easy to get wrong in so many ways, but also isn't appropriate to
> add directly to Django.
>
>
>
> On Friday, December 28, 2018 at 12:38:04 PM UTC-6, Adam Johnson wrote:
>>
>> I think the use case is probably quite niche, and I'd like to know some
>> more concrete details than the current comment on the ticket "(E.g. only
>> update if the value of a DateTimeField is less than some value)". It may be
>> there's a way to achieve the same application-level outcome using a
>> different design. If it is necessary, there are also some analogous use
>> cases, like passing a 'create' condition predicate or passing conditions to
>> get_or_create, that it seems it would make sense to implement at the same
>> time but would complicate Django and the scope of the change further.
>>
>> Also I agree with Simon that passing around predicate callables doesn't
>> feel very Django-ey or pythonic.
>>
>> On Fri, 28 Dec 2018 at 16:31, charettes  wrote:
>>
>>> Thanks for taking the time to post here Joshua!
>>>
>>> The main reason why I asked to gather feedback from this list is that
>>> I'm not convinced
>>> that the benefits outweighs the additional complexity this will add to
>>> the already quite
>>> loaded update_or_create() signature handling and how the fact a callable
>>> predicate
>>> is not something that is used anywhere else in Django AFAIK.
>>>
>>> The fact this can be achieved with the same number of queries by doing a
>>> save(update_fields) from the return value of a previous get_or_create
>>> with a
>>> bit of boilerplate[0] pushes me to a -1 because I don't think it's a
>>> common enough
>>> pattern to warrant the addition of a specialized option.
>>>
>>> Cheers,
>>> Simon
>>>
>>> [0] https://code.djangoproject.com/ticket/30053#comment:13
>>>
>>> Le vendredi 28 décembre 2018 11:15:33 UTC-5, Joshua Cannon a écrit :

 Howdy folks!

 At the suggestion of Simon Charette, I'd like to get feedback on how
 the community feels about the feature request #30053
 .
 The gist of the problem is that sometimes the "update" part of
 "update_or_create" should be conditional. The proposed solution adds a
 backwards-compatible "update_condition" parameter to "update_or_create"
 which should be a unary callable that takes in the retrieved table instance
 and returns a boolean of whether the update should be performed.

 Nasir Hussain has already started work on a possible solution on PR
 10800 .

 I'd love to hear other people's thoughts.

>>> --
>>> 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/82df287a-9e59-496b-956e-b0d4bd79760d%40googlegroups.com
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>> --
>> Adam
>>
> --
> 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/14f8cae0-0df1-4974-b80f-41e689e0d0d8%40googlegroups.com
> 

Re: New to open source community

[Collin Anderson]

Hi Pradeep,

You could try also joining the #django-dev irc channel.

Also checkout the "Advice for new contributors" if you haven't yet:
https://docs.djangoproject.com/en/dev/internals/contributing/new-contributors/

Thanks,
Collin


On Sun, Dec 16, 2018 at 2:18 PM Pradeep Sukhwani 
wrote:

> Hi there,
>
> I'm new to the open source community. Although I use Django a lot in my
> projects I'm struggling to get into the open source community. As it's has
> been a month but still, I'm not able to understand how can I take a step
> into this open source community? Any help or suggestions would be
> appreciated.
>
> --
> Thanks
> Pradeep Sukhwani
>
> --
> 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/4c6c304f-06f6-4bf7-aa5e-d064a49244b7%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/CAFO84S5GeEnPym971%3Dk_DiUFf1iA-PsE_rw2KCOUgzOFcnH1kQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: normalizing newlines in form fields

[Collin Anderson]

Maybe the newline character could be part of the setting, something like
normalize_newlines_to='\n'. And then just do a
normalize_newlines_to.join(value.splitlines()) could work.

On Mon, Nov 12, 2018 at 10:49 AM Jakub Kleň  wrote:

> Regarding the link you sent, I also think that the current behaviour is
> inconsistent. I'm now not sure if we should go with \n, or \r\n, but I
> think we definitely should normalize this. If you are writing to files on
> windows, all your browsers would send \r\n over post, so the files would be
> generated properly, but as soon as you deploy, and the first client enters
> some data from OSX for example, you have a problem which you couldn't even
> notice before. What I'm trying to say here is that I think it's better if
> it was consistent, and you could catch the issue during implementation.
>
> On Monday, November 12, 2018 at 3:58:39 PM UTC+1, Jakub Kleň wrote:
>>
>> I'm thinking if it wouldn't be nice if django automatically normalized
>> newlines of data entered by the user. The implementation would be really
>> simple, there's already a function for it in
>> django.utils.text.normalize_newlines, and it would go into
>> django.forms.fields.CharField.to_python the same as split() (maybe also
>> with an ivar for controlling the behavior, although I'm not sure if it's
>> needed). 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/3c773fc0-7049-4d66-ae14-9a322e884774%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/CAFO84S5iAmyAc%2Byf1BXgZ6X5Cr5vwxujmoPDBqaUDXhDFm%2BhGA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Allow skipping CSRF check for Referer header

[Collin Anderson]

Aas a data point, I've customized my csrf checking to skip the referrer
checking if there's a correct origin header. Though yes, it doesn't work in
some browsers. (I haven't set up Referrer-Policy so that hasn't been an
issue for me yet.)

I think it's worth mentioning too that same-site cookies are starting to
get a lot of browser support and could be an alternative csrf protection:
https://caniuse.com/#feat=same-site-cookie-attribute

>For some websites, checking the Referer header may provide no added
security benefit. For example, an HSTS-preloaded website which controls all
of its subdomains has nothing to gain from this check - there are no
untrusted subdomains which can mount an attack, and HSTS prevents an HTTP
MITM attack.
> To allow these websites to provide more flexibility to their users,
Django should support disabling this CSRF Referer check. This could be done
through a new setting, e.g. ' CSRF_REFERER_CHECK' (defaulting to 'True' to
avoid breaking existing sites).
I think this could make sense as long as it's well documented what the
requirements are to stay secure, and maybe a clear example of the attack
vector.



On Sat, Nov 10, 2018 at 10:47 AM Florian Apolloner 
wrote:

> Not neccessarily, one could still use the Origin header in cases where
> software strips the Referer and if you set the Referrer-Policy to
> same-origin you shouldn't have problems with firefox either.
>
> On Saturday, November 10, 2018 at 1:42:41 PM UTC+1, Adam Johnson wrote:
>>
>> I would think that feature flag rules it out for a long time?
>>
>> On Sat, 10 Nov 2018 at 09:52, Florian Apolloner 
>> wrote:
>>
>>> Wouldn't one alternative be checking the Origin header? It appears
>>> though that all browsers support it with the sad exception that it is still
>>> behind a feature flag in Firefox. :/ (
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1424076)
>>>
>>> On Saturday, November 10, 2018 at 1:03:08 AM UTC+1, Adam Johnson wrote:

 I also discovered a similar problem recently when deploying the
 "Referrer-Policy" header using James Bennett's library:
 https://django-referrer-policy.readthedocs.io/en/stable/ . Initially I
 opted for 'no-referrer' as I figured it was the most secure, but since this
 check is only done on HTTPS-enabled sites, it wasn't discovered that all
 forms were broken until production where HTTPS is used.

 I think the existence of Referrer-Policy bolsters the argument for this
 option, since some users might want to use 'no-referrer'. And in fact the
 current check presumes the Referrer Policy is left at the default,
 no-referrer-when-downgrade , and I'm pretty sure other values than
 no-referrer break it as well.

 +1 from me (I wonder if it could even be automatic if HSTS is enabled?)

 On Fri, 9 Nov 2018 at 21:31, Aaron Hill  wrote:

> Currently, Django's CSRF middleware will reject any 'non-safe' HTTPS
> request that lacks a Referer header: ​
> https://github.com/django/django/blob/22e8ab02863819093832de9f771bf40a62a6bd4a/django/middleware/
> csrf.py#L242
>
> However, some users may prevent their browsers from sending the
> Referer header, due to privacy concerns. These users are unable to submit
> 'non-safe' requests (e.g. POST requests) on HTTPS-enabled Django-powered
> website that use CSRF protection.
>
> For some websites, checking the Referer header may provide no added
> security benefit. For example, an HSTS-preloaded website which controls 
> all
> of its subdomains has nothing to gain from this check - there are no
> untrusted subdomains which can mount an attack, and HSTS prevents an HTTP
> MITM attack.
>
>
> To allow these websites to provide more flexibility to their users,
> Django should support disabling this CSRF Referer check. This could
> be done through a new setting, e.g. ' CSRF_REFERER_CHECK' (defaulting
> to 'True' to avoid breaking existing sites).
>
> --
> 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/bcc04352-cd39-485a-83ad-49d0608d6ccd%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


 --
 Adam

>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Django developers (C

Re: Simplify authentication backend interface

[Collin Anderson]

> Add default implementations for get_all_permissions() and has_perm(),
either in PermissionMixin or in a new BaseBackend class.
On a first glance, I think that makes sense to me.

> Also note that the separation between user and group permissions may not
be applicable with custom backends.
That also makes sense to me. It does seems like kind of an implementation
detail as to where the permission is actually coming from, though I think
that information could be useful in some cases, so somehow making it
optional would be nice.

On Sat, Nov 10, 2018 at 3:07 AM Tobias Bengfort 
wrote:

> I feel like the interface for authentication backends is unnecessarily
> complex: Basically, you only need authenticate() and has_perm(), but
> currently the interface also includes get_group_permissions(),
> get_all_permissions(), and has_module_perms().
>
> The architecture is like this: User inherits from PermissionMixin which
> implements the methods get_group_permissions(), get_all_permissions(),
> has_perm(), has_perms(), and has_module_perms().
>
> All of these methods basically just call the corresponding methods on
> the authentication backends, if available. has_perms() is the only
> exception, as it is just a shortcut to call has_perm() multiple times.
>
> I believe that has_perm() is vastly more important than
> get_*_permissions(). Still, I can understand that the latter exist. What
> I find confusing is that there is no get_user_permissions() in this
> interface. Whithout its counterpart, get_group_permissions() seems
> pretty much useless to me. Also note that the separation between user
> and group permissions may not be applicable with custom backends.
>
> Another issue is that developers can easily end up with inconsistent
> backends: There is no guarantee that get_all_permissions() will return a
> superset of get_group_permissions(). There is also no guarantee that
> has_perm() will be equivalent to `perm in get_all_permissions()`.
>
> Then there is the issue of has_module_perms(). As far as I understand,
> this should have been called has_app_perms(). It is used in
> contrib.admin where it makes a lot of sense, but I don't really see how
> it could be useful anywhere else.
>
> I looked at some popular backends to see how they are implemented:
>
> The default ModelBackend implements get_user_permissions() and
> get_group_permissions(). get_all_permissions() joins their results and
> has_perm() and has_module_perms() call get_all_permissions(). The
> results of get_all_permissions() are cached.
>
> django-guardian works pretty much the same. However, even though the
> mechanism is the same, get_group_permissions() is not exposed in the
> interface. has_module_perms() is missing.
>
> django-rules only implements has_perm(). get_*_permissions() are
> missing. has_module_perms() exists, but it is just an alias to
> has_perm().
>
> I guess the benefits of simplifying the interface do not justify
> breaking changes for most of these issues. However, I think there are
> two changes that could significantly improve the situation:
>
> -   Either add get_user_permissions() or remove get_group_permissions()
> -   Add default implementations for get_all_permissions() and
> has_perm(), either in PermissionMixin or in a new BaseBackend class.
>
> Any thoughts?
>
> tobias
>
> --
> 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/9eb25389-d59e-1f6c-4b50-d1c7a986f923%40posteo.de
> .
> 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/CAFO84S4SKCkN3X_-Hw4gWhVd2AHd8hZN6X2phEy0RriiiuMV8Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Idea: Allow queryset.get() and queryset.filter() to accept a positional argument for implicit primary key filtering

[Collin Anderson]

You could probably also just monkey patch like so:

from django.db.models import Manager, QuerySet
Manager.ident = QuerySet.ident = lambda self, pk: self.get(pk=pk)

On Wed, Nov 7, 2018 at 3:33 PM C. Kirby  wrote:

> I bit the bullet and put together a small app to handle this, with maybe
> even less typing. It monkey patches all installed models so you can run
> Model.ident_(pk)
> Can be found at https://github.com/ckirby/django-model-ident
>
> Chaim
>
> --
> 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/4bdacfe9-8fca-4b59-a15d-27553c731d4e%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/CAFO84S5Hkm4D3o%2BAmFgV8YHX2ZKH42hG5QU6UycJpjvS8dp3xw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Ticket/Issue Tracker

[Collin Anderson]

A few years ago I realized I really liked the UI of Trello.com, so I tried 
creating a trello-style view of django tickets:

https://djello.collinand.org/ (beware, I'm not a designer :)

It's basically just 100 lines of JS and a little CSS. It's still my go to 
for finding tickets.

I thought I'd share that as an idea for how to improve find-ability.


-- Forwarded message -
From: Tom Forbes
Date: Fri, Oct 26, 2018 at 8:09 PM
Subject: Re: Widening participation (Thoughts from DjangoCon)

How much of this would you attribute to the current ticketing system 
itself, rather than tickets being tagged appropriately?

I know when I started contributing I found trac to be pretty intimidating 
in terms of complexity, especially the search. I still prefer to use the 
'Search Trac' field in the root code.djangoproject.com page than fiddle 
with the myriad of options and drop downs in the browse tickets section.

If we think of getting new people onboard as a conversion funnel we need to 
stop dropoff as much as possible, and that extends to the UI of the ticket 
tracker as well I believe.

Tom

On Fri, 26 Oct 2018, 22:43 Ian Foote wrote:

> Hi Carlton,
>
> I've had similar thoughts sitting in the back of my mind for at least a 
> couple of months, so thank you for sharing this. I agree that finding 
> tickets is one of the big problems here, both for new contributors and for 
> sprint leaders. At Pycon UK I took on the role of sprint leader along with 
> Adam Johnson and directing people to appropriate tickets was a definite 
> difficulty. I was also unaware of the django core mentorship list and will 
> be joining that soon. I'm willing to spend some time mentoring a small 
> number of people, life permitting.
>
> Ian
>
> On Fri, 26 Oct 2018 at 14:44, Carlton Gibson wrote:
>
>> Hi All. 
>>
>> OK, so last week I was at DjangoCon US in San Diego. (Thank you if you 
>> organised that! Hi! if we met and chatted.) 
>> I gave a talk ("Your web framework needs you!") inspired by the 
>> discussion on the 
>>  DSF 
>> list and the proposal to dissolve Django Core 
>> . (Can’t see the DSF list? Join 
>> the DSF 
>> 
>> .)
>> I was asking for more participation in general, and participation that is 
>> more representative of the wider Django community in particular.
>>
>> There was lots of good input from many people, including (but not, at 
>> all, limited to) representatives of groups such Pyladies, DjangoGirls, and 
>> so on. 
>>
>>
>> The recurring themes seem to me to fit into three categories:
>>
>>1. The importance of *mentoring*.
>>2. The difficulty of *finding tickets*.
>>3. The importance of *sprints*.
>>
>> The rest here is a summary of that. Hopefully it’s useful. 
>>
>> Finding Tickets
>>
>> The next thing was that there’s not enough guidance on what to work on. 
>>
>> The guidance is to look for *Easy Pickings*. There are ≈1300 accepted 
>> open tickets in TRAC. 13 of these are marked *Easy Pickings*. 
>>
>> That’s not enough. I think we’re too tight with it (or need another 
>> grade). 
>>
>> There are *many* tickets which aren’t super hard: I put it that, most of 
>> our community solve harder problems every day *using Django* than most 
>> tickets require. 
>>
>> Yes, they still require time, love, energy, etc — and maybe some 
>> mentoring — but it’s not primary research, in the main.
>>
>> I talked to people who had (at the conference) got the test suite running 
>> and such, but been overawed by the (for want of a better phrase) *sheer 
>> face* of issue tracker. 
>>
>> We would do well to invite people better here. (I don’t have instant 
>> solutions.) 
>>
>

-- 
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/3b85c677-9244-46f4-b526-bf919bd74057%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Make `raw_id_fields` the default functionality in the admin

[Collin Anderson]

raw_id_fields can be a bit confusing to people. Have you tried the new
autocomplete_fields? It's almost as easy to use as a select field, and it
should help solve the problem. However, it's not as easy to make the
default (because it requires specifying search_fields on the related model)

On Wed, Oct 17, 2018 at 12:02 PM Yo-Yo Ma  wrote:

> One last note: M2M could also benefit from this, and could continue to
> look for `filter_horizontal` and not use a raw IDs field in those cases.
>
> On Wednesday, October 17, 2018 at 11:59:43 AM UTC-4, Yo-Yo Ma wrote:
>>
>> I have yet to ever come across a situation where the default 
>> field is more useful than the raw ID field, pertaining foreign key fields
>> in the admin.
>>
>> I have, however, personally witnessed a major publishing company bring
>> their production app servers to a halt (out of memory) due to Django
>> attempting to generate 2.5 million  tags for some dozen
>> admins that were all refreshing an admin changeview, wondering why it was
>> taking so long to load.
>>
>> Another thing worth noting is that when the  is most useful (when
>> there are very few records to select) also happens to be when the raw ID
>> field is most easily used (since the selection changelist only contains the
>> same very few records). IOW, the raw ID field's usefulness is universal,
>> working well with just a few records, and also working well (due to search
>> / sort) when there are many records.
>>
>> Nary a transition would be required, since the `raw_id_fields` could
>> simply be ignored.
>>
>> A new `select_fields = []` could be added for those who wish to easily
>> use the old functionality.
>>
>> Is there any reason why this couldn't or shouldn't be done?
>>
>> --
> 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/e0262150-ec7e-487d-8fb1-b64f8df2e7a3%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/CAFO84S4kK_D5c8MbE3OHDhsNcrpuTJpLBfbx79hD%2BS-DDnjdTA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: #29752 Adding a ALLOWED_HOSTS_IGNORABLE_URLS setting

[Collin Anderson]

You might be able to handle this by a middleware that gets called early
enough in the process (before CommonMiddleware) to avoid calling
request.get_host(). A simple if request.path == '/statuscheck/': return
HttpResponse() should work. As long as you never call request.get_host(),
django doesn't about ALLOWED_HOSTS.

Maybe we should patch CommonMiddleware to avoid calling request.get_host()
if not needed:
https://github.com/django/django/compare/master...collinanderson:avoidrequest.get_host

On Fri, Sep 14, 2018 at 1:55 PM Matt Pegler  wrote:

> AWS will send a request to a specific path and make sure it receives a
> status 200 response. If the response status is not 200, it will consider
> that instance unhealthy and will not route traffic to that instance. The
> path can be anything that can be used as a signal that the application is
> running properly.
>
> -Matt
>
> On Fri, Sep 14, 2018 at 11:29 AM, Tim Graham  wrote:
>
>> Sorry, I still don't understand what "whitelisting the health check path" 
>> looks like.
>>
>> Here's the snippet for anyone reading the thread after the pastebin expires.
>>
>> ALLOWED_HOSTS = ['ourdomain.com']EC2_PRIVATE_IP = Nonetry:  # AWS provided 
>> magic service that returns metadata about the instance making the call  
>> EC2_PRIVATE_IP = 
>> requests.get('http://169.254.169.254/latest/meta-data/local-ipv4', timeout = 
>> 0.01).textexcept requests.exceptions.RequestException:  passif 
>> EC2_PRIVATE_IP:  ALLOWED_HOSTS.append(EC2_PRIVATE_IP)
>>
>>
>>
>> On Friday, September 14, 2018 at 2:03:11 PM UTC-4, Matt wrote:
>>>
>>> We would find this valuable for the reason Jonas outlined. Health checks
>>> from AWS are sent without a host header, which causes the request to fail
>>> the host check. By whitelisting the health check path, it would simplify
>>> deployments to AWS and possibly others. Here's the workaround we use in
>>> production to support AWS health checks that may help give some more
>>> context: http://dpaste.com/2BS0C5M
>>>
>>> -Matt
>>>
>>> On Fri, Sep 14, 2018 at 10:44 AM, Tim Graham  wrote:
>>>
 What would be the value of that setting for your use case?

 On Friday, September 14, 2018 at 11:52:46 AM UTC-4, Jonas H wrote:
>
> Hi,
>
> I've started a discussion on
> https://code.djangoproject.com/ticket/29752 to add a new
> ALLOWED_HOSTS_IGNORABLE_URLS setting.
>
> The setting can become handy if you can't control the Host header sent
> to your application but still want to accept the request. An example of
> this is health checks made by AWS ECS/Fargate – google "django
> allowed_hosts aws" and find 16,000 results with tips how to work around 
> the
> problem.
>
> I'd like to discuss the addition on this list as per Tim's triage.
>
> Jonas
>
 --
 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/48278799-baea-4943-91b0-4d1f2318c3a5%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/58003490-00cb-4b01-856b-a7672e3e3c13%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/CA%2BSd1WdX0Cp2nLmGy

Re: HTML5 and XHTML5 documents

[Collin Anderson]

> serve Django Admin as 'text/html', and let other apps choose for
themselves.
Yes, DEFAULT_CONTENT_TYPE is deprecated, so the admin (soon) should always
return text/html, and other apps can choose for themselves. (see ticket
#23908 )

I think django should be encouraging html instead of xhtml, but it
shouldn't be too hard to use django with xhtml.

Forms are probably the next biggest issue after the admin, right? I agree a
3rd-party package would be best for that. Templates could probably handle
most if not all of it. I'd be fine changing that one line in
django/forms/forms.py as_table from  to . maybe render_css too.
(or maybe those need to get moved to templates?) The 3rd party package
could provide xhtml versions of template tags and filters where needed.

On Fri, Aug 17, 2018 at 4:08 PM James Bennett  wrote:

>
>
> On Fri, Aug 17, 2018 at 3:41 AM, Nils Fredrik Gjerull 
> wrote:
>>
>> I am talking about being able to serve pages as application/xhtml+xml,
>> this is defined by browser support as is the SGML version of HTML5. I
>> hardly think XML version of HML5 is more ill-defined than the SGML
>> version. I am not talking about supporting validators, as the browsers
>> are the validators. No need to use a validator if the browser makes it
>> clear when it is not. No need to limit what entities to use as long at
>> it is supported by the browsers.
>>
>
> If you're basing your understanding on browser support, you're not doing
> XML/XHTML. You're doing "a thing that looks like XHTML and works in my
> browser".
>
> I'm even *more* against having Django try to do that, since it's a moving
> target.
>
> --
> 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/CAL13Cg9UEtSBEPnc0_OJWy4HHALSA-XOLhgKBnnF5Fq7%3Dr811Q%40mail.gmail.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/CAFO84S6LtuC7J3bpk1HjSyTaE9pEuN8OjWkSx%3DpL%2BqG3e6M4Rg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: python manage.py inspectdb makes all fields with a default value blank=True, null=True

[Collin Anderson]

It's tricky to automatically convert the database default value to python,
but I wonder if it would help to put the default value in a python comment
at the end of the field? like:

models.IntegerField(blank=True, null=True)  # DB Default value: 1

That way it's more clear in models.py what's going on in the database, and
you can more easily change the model yourself if you want.

On Fri, Jul 20, 2018 at 5:31 PM Kimball Leavitt 
wrote:

> I opened a ticket for it here -->
> https://code.djangoproject.com/ticket/29583
>
> On Friday, July 20, 2018 at 3:27:33 PM UTC-6, Kimball Leavitt wrote:
>>
>> Note: I posted this on django-users
>> 
>>  and
>> was told to come here.
>>
>> I'm not sure if this is a bug, feature request, or something else.
>>
>> Summary: *python manage.py inspectdb* makes all fields with a default
>> value *blank=True, null=True*
>>
>> I'm using:
>>
>>- Ubuntu 16.04
>>- Python 3.7.0
>>- Django 2.0.4
>>- Mariadb 10.2.16
>>
>>
>> Before I get into this, I realize that
>>
>>- "Django is best suited for developing new applications"
>>- This probably isn't a huge deal or a high priority
>>
>> ...BUT I figured I'd submit this anyway while I was thinking about it.
>> Maybe it'll save someone some extra work down the line.
>>
>>
>> Steps to reproduce:
>>
>>
>>- Setup a legacy db in *settings.py* (see
>>https://docs.djangoproject.com/en/2.0/howto/legacy-databases/)
>>   - Prerequisite: you have a column in one of your tables that has a
>>   default value.
>>   - Example: *test_field int(11) *DEFAULT 1
>>   - Run *python manage.py inspectdb [--database DATABASE_NAME  [
>>TABLE ] ] > models.py*
>>- Open *models.py*
>>   - If you don't include *> models.py* you can see the output from
>>   the commandline
>>- *test_field* will look something like this:
>>   - *test_field* = models.IntegerField(*blank=True, null=True*)
>>   - What I would expect:
>>   - *test_field* = models.IntegerField(*default=1*)
>>
>>
>> What I've been able to dig up:
>>
>> # from inspectdb.py
>> 
>>  (line
>> 144, comments included in the original file)
>>
>> *142  # Add 'null' and 'blank', if the 'null_ok' flag was present in the*
>> *143  # table description.*
>> *144  if row[6]:  # If it's NULL...*
>> *145  extra_params['blank'] = True*
>> *146  extra_params['null'] = True*
>>
>>
>> # from introspection.py
>> 
>>  in *get_field_description *(line 95, comment is mine)
>>
>>
>> *86  fields = []*
>> *87  for line in cursor.description:*
>> *88 info = field_info[line[0]]*
>> *89 fields.append(FieldInfo(*
>> *90   *line[:3],*
>> *91**  to_int(info.max_len) or line[3],*
>> *92  to_int(info.num_prec) or line[4],*
>> *93  to_int(info.num_scale) or line[5],*
>> *94  line[6],*
>> *95  info.column_default, # THIS LINE IS JUST WHATEVER THE
>> COLUMN DEFAULT IS*
>> *96  info.extra,*
>> *97  info.is_unsigned,*
>> *98  ))*
>> *99  return fields*
>>
>>
>> I'm sure there are a lot of things I don't understand about this, but I
>> don't think that having a default value should automatically add *blank=True,
>> null=True. *
>> *Is having a default value really a "'null_ok' flag"?*
>>
>> I think it should only put *blank=True, null=True* if the default is set
>> to *NULL* in the column. Otherwise, it should set the default to
>> whatever the default value is (ex: *default=1*)
>>
>> Caveat: I've only tested this with int fields.
>>
> --
> 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/a6aedffd-a04b-4c38-8218-850aa3394364%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-developer

Re: Re: The behavior of QueryDict.get(_key_, _default=None_)

[Collin Anderson]

You might want to try json encoding your data if you want to preserve
integers, lists, etc.

On Thu, Jul 19, 2018 at 10:54 PM Collin Anderson 
wrote:

> Using your example, the client is sending this string:
>
> ?wordPos=2&wordPos=3
>
> It's not an array like ?wordPos=2,3
>
> On Thu, Jul 19, 2018 at 10:27 PM Zhao Lee  wrote:
>
>> I have to confess I don’t know much about web development .
>>
>> I used to expect QueryDict.get(_key_, _default=None_) to return data
>> type that client side offered, for example , if client side send
>> {'wordPos':(2,3)} , I expect get('wordPos') to return it, whereas the
>> current behavior is far from explanation , even using getlist('wordPos'),
>> it just returns ['2','3'], then I have to do additional work to convert
>> it back to its first shape, just found this inconvenient, so I made this
>> post.
>> BTW, why integers were converted to strings after the transmission?
>>
>>
>>
>> 在2018年07月19 20时44分, "Florian Apolloner"写道:
>>
>>
>> On Thursday, July 19, 2018 at 8:52:56 AM UTC+2, Carlton Gibson wrote:
>>>
>>> The usual case is to need a single value from the query string, so `[]`
>>> and `get()` both return scalars.
>>> `getList()` exists specifically for the case where you do want multiple
>>> values.
>>>
>>
>> I'd like to expand on this, because the current behaviour has even more
>> important aspects. The query string is supplied by the user and as such is
>> completely untrusted data. If `.get` were to change to return lists if
>> there are lists, this would mean that the user could control the data
>> structures in the view. This is not something we'd ever want.
>>
>> Aside from that it is technically impossible to change the behaviour of
>> get to return lists: What would ?some_param=1 result in? Would it all of a
>> sudden be a list with one item? Since there is no difference between a
>> scalar value and a one item list in terms of query strings, this has to
>> stay the decision of the developer. They are the only ones knowing how the
>> data should look like and can handle it accordingly.
>>
>> Cheers,
>> Florian
>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Django developers  (Contributions to Django itself)" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/django-developers/snBepnO5AjY/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, 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/4e15b2a8-895e-4c43-9b61-5dce2759d23c%40googlegroups.com
>> <https://groups.google.com/d/msgid/django-developers/4e15b2a8-895e-4c43-9b61-5dce2759d23c%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>> 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/47f81b86.5f.164b581f067.Coremail.redstone-cold%40163.com
>> <https://groups.google.com/d/msgid/django-developers/47f81b86.5f.164b581f067.Coremail.redstone-cold%40163.com?utm_medium=email&utm_source=footer>
>> .
>> 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/CAFO84S5yuyc7qEQ6F5G3kO%2Bu4OzNzqGhtVDQWu2mkqBfj7P5mQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Re: The behavior of QueryDict.get(_key_, _default=None_)

[Collin Anderson]

Using your example, the client is sending this string:

?wordPos=2&wordPos=3

It's not an array like ?wordPos=2,3

On Thu, Jul 19, 2018 at 10:27 PM Zhao Lee  wrote:

> I have to confess I don’t know much about web development .
>
> I used to expect QueryDict.get(_key_, _default=None_) to return data type
> that client side offered, for example , if client side send
> {'wordPos':(2,3)} , I expect get('wordPos') to return it, whereas the
> current behavior is far from explanation , even using getlist('wordPos'),
> it just returns ['2','3'], then I have to do additional work to convert
> it back to its first shape, just found this inconvenient, so I made this
> post.
> BTW, why integers were converted to strings after the transmission?
>
>
>
> 在2018年07月19 20时44分, "Florian Apolloner"写道:
>
>
> On Thursday, July 19, 2018 at 8:52:56 AM UTC+2, Carlton Gibson wrote:
>>
>> The usual case is to need a single value from the query string, so `[]`
>> and `get()` both return scalars.
>> `getList()` exists specifically for the case where you do want multiple
>> values.
>>
>
> I'd like to expand on this, because the current behaviour has even more
> important aspects. The query string is supplied by the user and as such is
> completely untrusted data. If `.get` were to change to return lists if
> there are lists, this would mean that the user could control the data
> structures in the view. This is not something we'd ever want.
>
> Aside from that it is technically impossible to change the behaviour of
> get to return lists: What would ?some_param=1 result in? Would it all of a
> sudden be a list with one item? Since there is no difference between a
> scalar value and a one item list in terms of query strings, this has to
> stay the decision of the developer. They are the only ones knowing how the
> data should look like and can handle it accordingly.
>
> Cheers,
> Florian
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers  (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/snBepnO5AjY/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/4e15b2a8-895e-4c43-9b61-5dce2759d23c%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/47f81b86.5f.164b581f067.Coremail.redstone-cold%40163.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/CAFO84S7i7YOrqmWamGo5vwr8RW0L6EBuvdsBEAh-0LjDwNtNEA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: New Feature discussion: making admin app & model url configurable

[Collin Anderson]

Maybe we could make an AdminSite.get_urls_for_model(self, model,
model_admin)

https://github.com/django/django/pull/10108/files

On Fri, Jun 29, 2018 at 8:57 AM  wrote:

> Personally, I'm not sure I see that much value. As I see it, the admin is
> intended for technical users, not as a general admin interface for end
> users (in this context I'm mostly talking about non-programmers). While it
> can and I sometimes do allow end-users to use the admin directly, I really
> feel like it's not the intended use.
>
> I'm also not really sure what modifying the URLs would achieve, since
> users aren't likely to be typing them in directly, anyway.
>
> Tom
>
> On Friday, June 29, 2018 at 10:49:26 AM UTC+1, Ramez Ashraf wrote:
>>
>> Hello guys,
>>
>> I use the admin quite extensively in my work with Django, and it's
>> awesome.
>> One place that can use some polish is the urls.
>> As you know, the admin urls evolve around are the  /
>>  , and those two can get technical, long and in short not user
>> friendly.
>> Hence, I propose a new feature of making those urls configurable
>>
>> First of all, what do you think ? Would you benefit from this new
>> feature? and mainly i'm asking devs with extensive use of the admin.
>>
>> Now for the technical part:
>> The idea was initially is to state those configuration around the
>> AppConfig (for the app part of the url) and in the model meta (for the
>> model part)
>> I got a review from Tim, that he don't like the idea of the meta, and i
>> can kinda agree with his point, and so, where do you suggest stating this
>> configuration?
>>
>> Another idea that cross my mind now, is to state those configuration in
>> the `settings.py`, something like this
>>
>> ADMIN_URLS = {
>> 'apps': {
>> 'celery_queue_tools': 'cool-app-name'
>> },
>> 'models': {
>>'mylongmodelname': 'user-friendly'
>> }
>> }
>>
>> This is just another idea of where to write the url customization
>> configuration, all is up for discussion.
>>
>> Thank you all and awaiting your feedback.
>>
>>
>>
>>
>> --
> 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/d6c3b94e-3bcd-49b5-b1b5-1c93c381ec11%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/CAFO84S5WV7K_A1ZWqAVcXc85%3D5UZtHp_txm_rVmuvMDitNDwmg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Redirect using HTTP status "303 See Other"

[Collin Anderson]

I don't think we should make any changes to HttpResponseRedirect, for
backwards compatibility reasons if nothing else.

It might make sense to encourage people to use HttpResonse(status=303)
directly, rather than using subclasses.

On Mon, Jun 4, 2018 at 3:51 PM, Duane Hutchins  wrote:

> The "302 Found" redirect is used by default in ​django.http.response
> HttpResponseRedirect.
>
> Could we discuss changing this to use "303 See Other" redirects?
>
> 303 redirects are more in-line with the intent of the redirect after a
> change, and also 303 redirects disallow browser caching.
> If a browser serves a cached response without revalidation, then the
> server would not receive the request.
>
> 303 redirects are not supported by HTTP/1.0, but all modern browsers now
> support HTTP/1.1 or higher.
>
> What does everyone think about changing 302 redirects to 303?
>
> --
> 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/ms
> gid/django-developers/829cedfb-855b-496a-9bf9-f60c6772f212%
> 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/CAFO84S4w7T9sbepdTkQ4rKLy6dtL9u5fRBhJ_7_FRV4qZq_V6g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Spaces between argument separator and argument in template filter generate error

[Collin Anderson]

Maybe it would be worth having a more friendly error message?

On Thu, May 31, 2018 at 8:59 PM,  wrote:

> Thank you for your reply.
> I understand your opinion well
>
> 2018년 5월 31일 목요일 오전 11시 41분 22초 UTC+9, oli...@kidsnote.com 님의 말:
>>
>> In the template filter system now,
>>
>> spaces between augment separator and augments generate error.
>> For example, the following template code generates the following error.
>>
>> {{ value | filter: "arg"}}
>>
>> TemplateSyntaxError at /
>> Could not parse the remainder: ': "arg"' from 'value | filter: "arg"'
>>
>> https://code.djangoproject.com/ticket/29457
>>
>>
>> What do you think of this ticket?
>>
>> --
> 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/b133457b-e474-47b6-b37f-
> cdab3fa6ee2f%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/CAFO84S4oFP_hxC6u84HagpXJy3ko7hvTkQjTO85CNfegFSX%3DUg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: #29433 New split template filter

[Collin Anderson]

There's been a few cases where I would have found a split filter to be
useful. I don't remember them off the top of my head.

I like that the behavior of it should be pretty well defined: just return
obj.split() if val is None else obj.split(val)

On Wed, May 30, 2018 at 6:32 AM, Carlton Gibson 
wrote:

> Hi Kamil,
>
> I'd think the preference here would be to NOT add new filters lightly —
> i.e. to close as wontfix — and recommend users create their own filters (or
> pull the logic into say a `get_context()` method) if they need this kind of
> thing.
>
> Slight aside: "Hi guys" may not fairly address everyone on the list. How
> about "Hi folks" or similar. 🙂
>
> Kind Regards,
>
> Carlton
>
> --
> 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/50bc0125-3ba2-4429-82e0-
> 4327d1490752%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/CAFO84S7c8bXPYaOEUb0-H%3DMqd3iv9Kx4xrDW%3D0HDxhetwH7ZdA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Set formfield.initial when created using modelformset_factory

[Collin Anderson]

Hi Brock,

Yes, that's the intended behavior, and you can see the same behavior on a
regular form, without using formsets, which might make it a little more
clear what's going on:

class MyForm(forms.Form):
name = forms.CharField()

form = MyForm(initial={'name': 'test'})
form.initial  #yields {'name':'test'}
form['name'].initial #yields 'test'
form.fields['name'].initial #yields None

The field itself is shared between all instances of MyForm, so passing in
initial data to one instance of MyForm shouldn't modify the field. Instead,
the BoundField is used to hold the data for a particular form, and as you
mention, as the initial value on the boundfield has that value you expect.

Hope this helps,
Collin


On Wed, May 23, 2018 at 2:04 PM, Brock Hallenbeck 
wrote:

> When creating a formset using modelformset_factory and passing in a list
> of dictionaries to use as initial values, those values can be retrieved
> from the relevant form, and the relevant boundfield on that form.
> However the formfield class itself has no knowledge of that initial data.
>
> Is this intended behavior? I feel like I should be able to catch that
> initial value in my formfield subclasses.
>
> Here is a dpaste illustrating what I am talking about:
>
> https://dpaste.de/As6Z
>
> --
> 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/1d84a32c-d70a-4d42-8b94-
> ca19f27ede0e%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/CAFO84S7n32FSzz-2JDf3BYVJTc5RdkyzO2%3Dv9YNbCEpnj-9g_g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: email login, create and save

[Collin Anderson]

Do you want something like this?

class EmailUserCreationForm(UserCreationForm):
username = User._meta.get_field('username').formfield(label='Email',
validators=[validators.validate_email])

def save(self, commit=True):
self.instance.email = self.cleaned_data['username']
return super().save(commit=commit)


class EmailAuthenticateForm(UserCreationForm):
username = User._meta.get_field('username').formfield(label='Email')


On Fri, May 4, 2018 at 7:20 AM, Ali A Cetrefli 
wrote:

> Dear developers,
>
> Please make new email UserCreateFormbyEmail, UserAuthenticatebyEmail
>
> I know, You have many custom authentication methods, but nature of
> internet in signup forms is by email not username..
>
> best regards..
>
> --
> 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/c31d4b3d-c71f-4f0b-b3c4-
> 5be1e8e7d34b%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/CAFO84S7c%3DKBE_xxgaqtUDGgc8cJK8_C5iBE6RCUkyqA%2Bjp%3DPCg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: #django-dev IRC channel

[Collin Anderson]

Hi Kenneth,

The Contributing to Django
 page is
part of the Django's main documentation, so open a ticket for django:
https://code.djangoproject.com

The source for that page is here: https://github.com/
django/django/blob/master/docs/internals/contributing/index.txt

Thanks,
Collin



On Fri, Apr 27, 2018 at 2:24 AM, Kenneth  wrote:

> Thank you for the reply, Josh.
>
> Should I post it as an issue in the djangoproject.com repository (
> https://github.com/django/djangoproject.com/issues) and not as a ticket
> in the ticket tracker (https://code.djangoproject.com) because this is an
> issue with the website?
>
> On Thursday, April 26, 2018 at 9:11:06 PM UTC-4, Josh Smeaton wrote:
>>
>> Yes - that's probably a good idea!
>>
>> On Thursday, 26 April 2018 05:11:33 UTC+10, Kenneth wrote:
>>>
>>> Hello,
>>>
>>> I was just curious about the #django-dev IRC Channel.
>>> Currently, the only mention for this channel is on the Code of Conduct
>>> FAQ  page.
>>> Should it also be mentioned on the Contributing to Django
>>>  page?
>>>
>>> --
> 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/ms
> gid/django-developers/f6accde6-2314-462d-82d1-7ab68997f7fe%
> 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/CAFO84S7Rycbh4JdEQYs1EF5sutD%2B%3DWUoeQ9MV8TkynE-ppbZ1g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: ModelAdmin.prepopulated_fields removes stop words

[Collin Anderson]

Hi Kelly,

I believe it's in urlify.js
https://github.com/django/django/blob/master/django/contrib/admin/static/admin/js/urlify.js#L172-L175

Collin


On Wed, Apr 25, 2018 at 4:51 PM, Kelly  wrote:

> Hello,
>
> I am working on ticket 29351 
> and I am documenting that ModelAdmin.prepopulated_fields removes stop
> words. I have looked in the codebase, but I am having trouble finding
> exactly where this logic is so that I can made the documentation as
> specific as possible.
>
> Can anyone help pinpoint where the stop words are being filtered out or is
> just stating that stop words are filtered out sufficient?
>
> Cheers,
>
> Kelly
>
> --
> 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/706f3bb8-0e91-4123-be85-
> 960383843c30%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/CAFO84S7ZBwjYsufzo8j6eFJotaYtTUobb783q2Lv%2Bj%3D%3DvHbf8Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Fabric examples in documentation

[Collin Anderson]

A little bit more information: Fabric2 has been actively developed over the
last year, but is still Alpha (may get api changes):
https://github.com/fabric/fabric/tree/v2
http://bitprophet.org/blog/2017/04/17/fabric-2-alpha-beta/

I agree removing references to fabric might be the way to go. There are
lots of ways to deploy files.

On Wed, Apr 25, 2018 at 1:55 PM, Florian Apolloner 
wrote:

> I'd just drop the paragraph
>
> On Wednesday, April 25, 2018 at 7:42:45 PM UTC+2, Tim Graham wrote:
>>
>> From https://code.djangoproject.com/ticket/29360:
>>
>>   "The ​Serving the site and your static files from the same server
>> 
>> and the ​Serving static files from a dedicated server
>> 
>> documentation references Fabric and fabfiles. Fabric (as linked in the
>> docs) is a Python 2.5-2.7 only project. This should probably change since
>> Django 2.0+ is Python3 only.
>> Fabric has a ​roadmap  for Python 3
>> support, last updated May 2015. They propose moving eventually to a Fabric2
>> ... unfortunately there already exists a ​Fabric3
>>  fork, so keeping Fabric in the docs
>> could (eventually) lead to confusion."
>>
>> What do you think is the best way to proceed here?
>>
> --
> 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/8bcf106a-03a6-4d88-893f-
> fc37482af262%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/CAFO84S6JhvQtnJEdTZzM5_Loi%2B6LWCxgA4aM366AgMfsN2WDFA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Shouldn't manage.py call python3 instead of python?

[Collin Anderson]

but python3 manage.py  doesn't work on windows, right?

On Tue, Apr 10, 2018 at 10:17 PM, Josh Smeaton 
wrote:

> As a datapoint, I've seen roughly 1 person per week in #django IRC
> confused about specific startup exceptions due to them using python 2
> rather than python 3 on Django >= 2.0. Unsure how many of these are due to
> the shebang. That said, it looks like there are no good solutions other
> than maybe ensuring our docs always show the form *python3 manage.py
> * rather than *./manage.py *.
>
> On Wednesday, 11 April 2018 12:02:31 UTC+10, Bobby Mozumder wrote:
>>
>> In any case you’re going to see a lot of Django 2.0 developers on Mac OS
>> hit this problem when they install to default Python or use standard Python
>> install convention where Python 3.5 is installed as “python3".
>>
>> -bobby
>>
>> On Apr 10, 2018, at 3:46 PM, Aymeric Augustin <
>> aymeric@polytechnique.org> wrote:
>>
>> On 10 Apr 2018, at 17:43, Florian Apolloner  wrote:
>>
>> On Tuesday, April 10, 2018 at 1:28:33 PM UTC+2, Tim Allen wrote:
>>>
>>> Since `django-admin startproject my_project` is created on the fly from
>>> templates, couldn't we dynamically create the `manage.py` executable based
>>> on some system introspection and an agreed upon priority
>>>
>>
>> Wouldn't that result in something along the lines of "works on my system"
>> and breaks elsewhere? after all manage.py is committed into git more often
>> than not.
>>
>>
>> ... which directs us to the correct solution: setting PYTHONPATH and
>> DJANGO_SETTINGS_MODULE correctly and using django-admin instead of
>> manage.py.
>>
>> pip / setuptools rewrites the shebang line appropriately when it installs
>> the django-admin script. (I'm not sure how this happens exactly.)
>>
>> My point is — there's no perfect solution. At best we can aim for a less
>> imperfect solution than the status quo.
>>
>> --
>> 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-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/ms
>> gid/django-developers/C36A8494-1094-4A03-A402-618BB999F927%
>> 40polytechnique.org
>> 
>> .
>> 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/33ec0ccb-a63b-4451-bfec-
> 815b9e5f52a7%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/CAFO84S6xks7eiFGWYtvvWo0E8JXaiHWOPLvVbY_T_UQHy0YURw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Shouldn't manage.py call python3 instead of python?

[Collin Anderson]

I'm thinking something like #!/usr/bin/env
{{ os.path.basename(sys.executable) }} when running startproject. (Though
on windows I that would be #!/usr/bin/env python.exe - not sure if that
would work or not)

On Mon, Apr 9, 2018 at 3:58 PM, Adam Johnson  wrote:

> (Or would it work to use os.path.basename(sys.executable) ?)
>
>
> The shebang is interpreted by the OS so this is before python even starts
> :)
>
> On 9 April 2018 at 20:53, Collin Anderson  wrote:
>
>> I personally just edit my manage.py to change it from python to python3.
>> Maybe we could just document that?
>>
>> (Or would it work to use os.path.basename(sys.executable) ?)
>>
>> On Sun, Apr 8, 2018 at 11:02 AM, Tom Forbes  wrote:
>>
>>> It may be an obstacle but I believe it’s better than having them nuke
>>> their base systems by accident by installing a package that conflicts with
>>> their base system. This isn’t such a huge issue on MacOS but on Linux it is
>>> and I’ve seen it happen a few times. Not to mention the issue of multiple
>>> conflicting dependencies across projects - all in all it’s really not a
>>> recommended and we should not look to make it easier IMO.
>>>
>>> People have different setups and whatever works, works, but things like
>>> pipenv are maturing rapidly and solve the convenience issue you
>>> describe. I personally use virtualenvwrapper which is really simple to
>>> set up and displays the current virtual environment in the prompt, and
>>> makes it really easy to switch between them/create new ones.
>>>
>>> Tom
>>>
>>>
>>>
>>> On 8 April 2018 at 15:00:46, Bobby Mozumder (bmozum...@gmail.com) wrote:
>>>
>>> I never really liked the idea of using VirtualEnv or HomeBrew over the
>>> default installation in Mac OS.  (FreeBSD has the same naming issues).
>>>
>>> Having beginners use VirtualEnv or HomeBrew always struck me as a huge
>>> obstacle to getting a beginners Django developer's environment operational,
>>> as well as being a huge pain-in-the-ass of always setting VirtualEnvs for
>>> each shell.  So, I personally don’t use them anymore, and just use the base
>>> system now.
>>>
>>> I wish there was a process of running Django out-of-the-box from a
>>> default Mac OS install.
>>>
>>> -bobby
>>>
>>> On Apr 8, 2018, at 8:27 AM, Tom Forbes  wrote:
>>>
>>> This only seems to be an issue when you are using the base system
>>> interpreter to run manage.py. installing Django and other dependencies
>>> there is not recommended for a variety of reasons, and this isn't a problem
>>> when using a virtualenv, it doesn't seem like there is much to fix IMO.
>>>
>>>
>>> On Sun, 8 Apr 2018, 08:19 Bobby Mozumder,  wrote:
>>>
>>>> Is it OK to reopen that ticket?
>>>>
>>>> The problem is that python2 and python3 need to coexist in most
>>>> systems, and you can’t just rename python3 to python.
>>>>
>>>> -bobby
>>>>
>>>> On Apr 6, 2018, at 8:30 PM, Tim Graham  wrote:
>>>>
>>>> It was tried in https://code.djangoproject.com/ticket/27878 but it
>>>> caused problems, particularly on Windows.
>>>>
>>>> On Friday, April 6, 2018 at 6:35:50 PM UTC-4, Josh Smeaton wrote:
>>>>>
>>>>> I think you're right and PEP394 is the relevant text:
>>>>> https://www.python.org/dev/peps/pep-0394/
>>>>>
>>>>> TL;DR
>>>>>
>>>>> For now, *python* should refer to python2 and *python3* should be
>>>>> used to refer to python 3.
>>>>>
>>>>> On Saturday, 7 April 2018 07:07:35 UTC+10, Bobby Mozumder wrote:
>>>>>>
>>>>>> The header of manage.py has: #!/usr/bin/env python
>>>>>>
>>>>>> Shoudn’t it be: #!/usr/bin/env python3
>>>>>>
>>>>>> Since 2.0 is now only Python3. Both my Mac OS & FreeBSD environments
>>>>>> have Python 3.5+ as “python3". (I’m not sure about Linux or other
>>>>>> environments).
>>>>>>
>>>>>> Is that a bug I need to file?
>>>>>>
>>>>>> -bobby
>>>>>>
>>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Django developers (Co

Re: Shouldn't manage.py call python3 instead of python?

[Collin Anderson]

I personally just edit my manage.py to change it from python to python3.
Maybe we could just document that?

(Or would it work to use os.path.basename(sys.executable) ?)

On Sun, Apr 8, 2018 at 11:02 AM, Tom Forbes  wrote:

> It may be an obstacle but I believe it’s better than having them nuke
> their base systems by accident by installing a package that conflicts with
> their base system. This isn’t such a huge issue on MacOS but on Linux it is
> and I’ve seen it happen a few times. Not to mention the issue of multiple
> conflicting dependencies across projects - all in all it’s really not a
> recommended and we should not look to make it easier IMO.
>
> People have different setups and whatever works, works, but things like
> pipenv are maturing rapidly and solve the convenience issue you describe.
> I personally use virtualenvwrapper which is really simple to set up and
> displays the current virtual environment in the prompt, and makes it really
> easy to switch between them/create new ones.
>
> Tom
>
>
>
> On 8 April 2018 at 15:00:46, Bobby Mozumder (bmozum...@gmail.com) wrote:
>
> I never really liked the idea of using VirtualEnv or HomeBrew over the
> default installation in Mac OS.  (FreeBSD has the same naming issues).
>
> Having beginners use VirtualEnv or HomeBrew always struck me as a huge
> obstacle to getting a beginners Django developer's environment operational,
> as well as being a huge pain-in-the-ass of always setting VirtualEnvs for
> each shell.  So, I personally don’t use them anymore, and just use the base
> system now.
>
> I wish there was a process of running Django out-of-the-box from a default
> Mac OS install.
>
> -bobby
>
> On Apr 8, 2018, at 8:27 AM, Tom Forbes  wrote:
>
> This only seems to be an issue when you are using the base system
> interpreter to run manage.py. installing Django and other dependencies
> there is not recommended for a variety of reasons, and this isn't a problem
> when using a virtualenv, it doesn't seem like there is much to fix IMO.
>
>
> On Sun, 8 Apr 2018, 08:19 Bobby Mozumder,  wrote:
>
>> Is it OK to reopen that ticket?
>>
>> The problem is that python2 and python3 need to coexist in most systems,
>> and you can’t just rename python3 to python.
>>
>> -bobby
>>
>> On Apr 6, 2018, at 8:30 PM, Tim Graham  wrote:
>>
>> It was tried in https://code.djangoproject.com/ticket/27878 but it
>> caused problems, particularly on Windows.
>>
>> On Friday, April 6, 2018 at 6:35:50 PM UTC-4, Josh Smeaton wrote:
>>>
>>> I think you're right and PEP394 is the relevant text:
>>> https://www.python.org/dev/peps/pep-0394/
>>>
>>> TL;DR
>>>
>>> For now, *python* should refer to python2 and *python3* should be used
>>> to refer to python 3.
>>>
>>> On Saturday, 7 April 2018 07:07:35 UTC+10, Bobby Mozumder wrote:

 The header of manage.py has: #!/usr/bin/env python

 Shoudn’t it be: #!/usr/bin/env python3

 Since 2.0 is now only Python3. Both my Mac OS & FreeBSD environments
 have Python 3.5+ as “python3". (I’m not sure about Linux or other
 environments).

 Is that a bug I need to file?

 -bobby

>>>
>> --
>> 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/7cdf48bb-ab0b-449d-8f33-
>> a4c6d369%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/E1881F92-2D8C-45D8-8315-E5D72D0D7B6E%40gmail.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-de

Re: URL Query Params via Reverse.

[Collin Anderson]

Hi Matthew,

Are you aware of Python's urlencode?
https://docs.python.org/3/library/urllib.parse.html#urllib.parse.urlencode

It sounds like you want something like:
def reverse_with_querystring(viewname, data=None):
return "{url}{querystring}".format(url=reverse(viewname),
querystring='?' + urlencode(data) if data else '')

Collin

On Mon, Mar 5, 2018 at 5:35 AM, Matthew Bridges <
matthew.brid...@wearefarm.com> wrote:

> Hello all, first contribution to the dev community here, I wanted to get
> some thoughts on a feature that I thought might be a helpful.
>
> I notice myself writing this pattern a lot when constructing redirect URLS.
>
> ```
> def some_view(request):
>  querystring = "?some-key={some_key}&another-
> key={another_key}".format(some_key=some_value, another_key=another_value)
>  url = "{url}{querystring}".format(url=reverse('some_app:some_view'),
> querystring=querystring)
>  return HttpResponseRedirect(url)
> ```
>
> I was thinking about writing a helper function that grabbed a reversed
> URL, and unpacked a data dict into a query string. Building up strings
> feels nasty, and doing this in a functional manner feels much nicer.
>
> Pseudo code might look something like:
>
> ```
> def reverse_with_querystring(viewname, data=None)
> # get viewname
>
> # loop over data
>
> # IRI encode url
>
> # return constructed URL
> ```
>
> ```
> url = reverse_with_querystring('myapp:myview', data={'keyone': '123',
> 'keytwo' 321)
> ```
>
> Questions:
>  - Do other people use this syntax to build up querystrings / am I solving
> a problem that doesn't need solving?
>  - Is there already a helper that allows this behaviour?
>  - If the function were to be included, would django/urls be the
> appropriate module, given that the function utilises reverse? Or perhaps
> somewhere else. The behaviour would be similar to get_absolute_url type
> functions.
>  - Am I doing this right?
>
> Thanks :)
>
> --
> 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/7846f70a-ddf9-47fe-b99f-
> 915d2ff7ce48%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/CAFO84S6gUxTurNqD5KgqP_k7O5UWfddceAjWN8ujuq9AJ%3DJG%3DQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: please make django model independent,i wanna use without full django project, thanks

[Collin Anderson]

Hello,

Do you mean not use the entire django package? or not use an entire
"project" directory as created by startproject? Why don't you want to use
full django project?

Thanks,
Collin

On Thu, Mar 1, 2018 at 5:31 AM, 王冯俊  wrote:

> please make django model independent,i wanna use without full django
> project
>
> thanks
>
> --
> 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/6bfed047-73d4-491f-a5dd-
> ae4f4aaffb6d%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/CAFO84S5GL2B0iYfAHCBiC2tumuZhvwko9r1ZytYv7UTyeKM2zQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Raising awareness to issue #17664

[Collin Anderson]

"{% if %} template tag silences exceptions inconsistently"

On Thu, Mar 1, 2018 at 8:57 AM, Robert Roskam 
wrote:

> I spent some time looking at this issue last week, and I wanted to raise
> awareness here. It's an issue that's been out there for 6 years, and I
> think I have a path forward.
>
> However, the path forward would be a breaking change.
>
> https://code.djangoproject.com/ticket/17664
>
> --
> 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/9706ad6e-7e3a-40fa-b42e-
> 5753886ddbdb%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/CAFO84S6O%2BmRvz%3DG%2BxnHwBcye%3Db-ne%3DLuQT8hfkEdg_9scNnaSQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

[Collin Anderson]

> Maybe we could just alias and warn when using the old name, leaving a
decision on deprecation until some time in the future.

I'm a fan of delaying deprecation/removal if we do change it. :)

On Wed, Feb 21, 2018 at 4:41 PM, Josh Smeaton 
wrote:

> I agree that the names are misleading and we should probably provide
> better names. I'm wary of deprecating the old names because it'll create a
> lot of churn (some of which would be the right thing to do). Maybe we could
> just alias and warn when using the old name, leaving a decision on
> deprecation until some time in the future.
>
> On Monday, 29 January 2018 03:14:27 UTC+11, Stuart Cox wrote:
>>
>> In my experience, misuse of mark_safe() — i.e. marking stuff safe which
>> *isn’t* actually safe (e.g. HTML from a rich text input) — is one of the
>> biggest causes of XSS vulnerabilities in Django projects.
>>
>> The docs warn to be careful, but unfortunately I think Django devs have
>> just got too used to mark_safe() being *the way* to insert HTML in a
>> template. And it’s easy for something that was safe when it was authored
>> (e.g. calling mark_safe() on a hard-coded string) to be copied /
>> repurposed / adapted into a case which is no longer be safe (e.g. that
>> string replaced with a user-provided value).
>>
>> Some other frameworks use scary sounding names to help reinforce that
>> there are dangers around similar features, and that this isn’t something
>> you should use in everyday work — e.g. React’s dangerouslySetInnerHTML.
>>
>> Relatedly, this topic
>>  
>> suggested
>> making it more explicit that mark_safe() refers to being safe for use in
>> *HTML* contexts (rather than JS, CSS, SQL, etc).
>>
>> Combining the two, it would be great if Django could rename mark_safe() to
>> dangerously_trust_html(), |safe to |dangerously_trust_html, @csrf_exempt to
>> @dangerously_csrf_exempt, etc.
>>
>> Developers who know what they’re doing with these could then be
>> encouraged to create suitable wrappers which handle their use case safely
>> internally — e.g.:
>>
>> @register.filter
>> def sanitize_and_trust_html(value):
>> # Safe because we sanitize before trusting
>> return dangerously_trust_html(bleach.clean(value))
>>
>>
>> --
> 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/05de4602-5c44-41bf-b675-
> ab15d69fb46d%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/CAFO84S7x0y07eY4uYO2cKCe4%2B8jo9x%3DrO0QA3EAbJvU1pmbJ5Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Thoughts re looser coupling of django.contrib.auth and django.contrib admin

[Collin Anderson]

Hi Steve,

If it helps at least in the short-term, those fields currently don't need
to be actual database columns. I have a custom user that has these
properties/methods to make work with the admin.

Collin

@property
def is_anonymous(self):
return not self.is_authenticated

@property
def is_authenticated(self):
return bool(self.pk)

@property
def is_active(self):
return bool(self.pk)

@property
def is_superuser(self):
# run some code to figure out if they have "admin" custom
permission or not
return permission_check is True

@property
def is_staff(self):
return self.is_superuser

def has_module_perms(self, app_label):
return self.is_superuser

def has_perm(self, perm):
return self.is_superuser

On Thu, Feb 8, 2018 at 1:58 PM, Stephan Doliov 
wrote:

> Hi,
> I would like to solicit some feedback regarding some existing tight
> coupling between django.contrib.auth and django.contrib admin.
>
> The existing, and nominally swappable user model that ships with django
> assumes, for the out-of-the-box application benefit of
> django.contrib.admin, that there are 3 differentiable fields that should
> ship with any swappable user model that wishes to be swappable:
> is_staff
> is_superuser
> and
> is_active
>
> I would like to propose that at least the "is_staff" and the
> "is_superuser" attributes that are part of the default user model become
> fallbacks to a more generic permissions (maybe even swappable
> permissions???) approach.
>
> What I am envisioning is  that whereever there are checks for
> is_superuser, is_staff and is_active that they be wrapped in a way that if
> the custom user model did not offer these attributes, that perhaps some
> "pluggable permissioning" take their place. I enumerate the existing admin
> dependencies in this post, the is_superuser is relevant prolly in a
> different thread as it only touches the default user model (and not admin
> directly)
>
> For example: from django/contrib/admin/views/decorators.py
> from django.contrib.auth import REDIRECT_FIELD_NAME
> from django.contrib.auth.decorators import user_passes_test
>
>
>
>
> def staff_member_required(view_func=None, redirect_field_name=REDIRECT_
> FIELD_NAME,
>   login_url='admin:login'):
> """
> Decorator for views that checks that the user is logged in and is a
> staff
> member, redirecting to the login page if necessary.
> """
> actual_decorator = user_passes_test(
> lambda u: u.is_active and u.is_staff,
> login_url=login_url,
> redirect_field_name=redirect_field_name
> )
> if view_func:
> return actual_decorator(view_func)
> return actual_decorator
>
> itself could wrap u.is_active and u.is_staff.
> or, IMO, better yet, the actual decorator could be overriden by the custom
> user model:
> e.g. the user model could:
> def user_is_staff_test(self):
> if self.has_permissions(['list of perms']):
> return True
> else:
> return False
> and
> def user_is_superuser_test(self):
> if self.has_permissions(['list of other perms']):
> return True
> else:
> return False
>
>
> and then existing decorator could be modifed to to fetch the
> user_passes_test method and revert to a default if it doesn't exist.
>
> Similar mods would be required for the Admin Site
> class django/contrib/admin/sites.py
> def has_permission(self, request):
> """
> Return True if the given HttpRequest has permission to view
> *at least one* page in the admin site.
> """
> return request.user.is_active and request.user.is_staff
>
>
> And the AdminAuthenticationForm (django/contrib/admin/forms.py):
> class AdminAuthenticationForm(AuthenticationForm):
> """
> A custom authentication form used in the admin app.
> """
> error_messages = {
> 'invalid_login': _(
> "Please enter the correct %(username)s and password for a
> staff "
> "account. Note that both fields may be case-sensitive."
> ),
> }
> required_css_class = 'required'
>
>
> def confirm_login_allowed(self, user):
> if not user.is_active or not user.is_staff:
> raise forms.ValidationError(
> self.error_messages['invalid_login'],
> code='invalid_login',
> params={'username': self.username_field.verbose_name}
> )
>
>
>
> I would love to hear people's thoughts on this. I am targeting an
> architecture where the user model as simply two meaningful columns (I don't
> care too much about the surrogate "id" PK), email & password.
>
> The other attributes would be stored elsewhere. I can see carrying a
> convenience field of "is_active" in this table but that too could be
> managed in other ways (user inactivation could be done by migrating a db
> row to an "inactive users" table, e

Re: ticket 28404

[Collin Anderson]

Hi Carlton,

There are some cases where I really do want an empty string displayed
(though not in a linked column). Maybe only use it only when it's an
auto-linked field/column? Or maybe only use this behavior in
display_for_field()? (So if you use a custom function/method, you can still
have full control.)

Thanks,
Collin


On Wed, Feb 7, 2018 at 5:30 AM, Carlton Gibson 
wrote:

> [Better Subject] Fix admin change list display of empty string values.
>
> I'll summarise; I'd like to elicit any objections.
>
> The issue is that the admin change list doesn't display the "empty value"
> placeholder for empty strings,
> which is the recommended way of handling "nullable" CharFields.
>
> The image attached to the issue demonstrates the issue nicely:
>
>
> 
>
> These rows won't even be clickable.
>
> Options:
>
> 1. Make the existing admin `empty_value_display` option also handle empty
> strings.
> 2. Add a new admin option for empty strings, separate from `None`
> (null=True) cases.
>
> We have PR that's not too far off for option 1.
>
> More to the point I'm in favour of option 1 because:
>
> * We have enough admin options already
> * The empty string is just how text-type fields handle the `null` case.
> (i.e. this should already be the behaviour.)
>
> *Are there any reasons we can't adjust `empty_value_display` to also be
> used for empty strings?*
>
> Original Issue: https://code.djangoproject.com/ticket/28404
> PR: https://github.com/django/django/pull/9391
>
> Thanks for the input all!
>
> Kind Regards,
>
> Carlton
>
>
>
>
>
> --
> 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/92b12dbc-ace6-4d72-9234-
> 5563625446b2%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/CAFO84S6Wo193A2G4aGqJo_dpQqGgVRC8RnFTmfy71R1RxrgwiA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: DEP Pre-posal: Re-Designing Django Forms

[Collin Anderson]

I personally use the (undocumented?) formfield() method, which takes the
model defaults and lets you override things. I think it's pretty elegant,
though maybe it could use some less verbose syntax (maybe have a
forms.ModelDefault(label='Note') that does this for you).

class NoteModalForm(forms.ModelForm):
comment = Note._meta.get_field('comment').formfield(label='Note')
is_blocker = Note._meta.get_field('is_blocker').formfield(label='Blocking
Issue', initial=False)
picture = Note._meta.get_field('picture').formfield(label='Picture',
required=True, widget=DragNDropFileButtonInput(button_text='Select file to
Upload', button_classes='btn btn-bordered uploader'))

class Meta:
model = Note
fields = ['comment', 'is_blocker', 'equipment', 'picture']

I should also note, you can change fields without overriding __init__; just
use base_fields:
NoteModalForm.base_fields['picture'].required = True
NoteModalForm.base_fields['is_blocker'].initial = False

As far as client-side validation goes, yes, Django really only does
client-side validation that's available from plain html. Do you have some
ideas for how dependent fields should work? I personally think it would be
hard to find a one-size-fits all solution for more complicated cases, but
it's probably possible. I think there are some 3rd party libraries that do
this. I think a first step would be to natively handle dependent-fields
programmatically in the back-end, so the form "knows" that those fields are
related. Then maybe django could pass that relationship information to the
html as data-* attributes.

On Wed, Jan 31, 2018 at 10:31 AM, Robert Roskam 
wrote:

> Hey All,
>
> Something I've regularly run into as a challenge is the implementation of
> Django forms work well in the simple use cases, but as the use case grows
> in complexity, Django forms become more difficult to work with.
>
> I know that's a super general statement, but here's the simplest complex
> example I can give you. Lets say you're making an application for a home
> builder, so that their Project Managers can better coordinate the builds.
> One of the features is the ability to take notes and pictures on anything
> that's not yet done and specifically if it relates to a specific piece of
> equipment (AC, furnace, water pump, etc), they can add that too. Below is a
> moderately simplistic example:
>
> class Note(models.Model):
> project = models.ForeignKey('project_management.Project',
> related_name="notes")
> equipment = models.ForeignKey('equipment.Equipment', null=True,
> blank=True, related_name="notes")
> picture = models.FileField(null=True, blank=True)
> is_blocker = models.BooleanField(default=True)
> comment = models.TextField()
> created_by = models.ForeignKey('users.User', verbose_name="Created
> By")
> created_date = models.DateTimeField(default=timezone.now,
> verbose_name="Created Date")
>
>
> class NoteModalForm(forms.ModelForm):
> class Meta:
> fields = ('comment', 'is_blocker','equipment', 'picture')
> model = Note
> labels = {
> 'comment': 'Note',
> 'is_blocker': 'Blocking Issue',
> 'picture': 'Picture',
> }
> widgets = {
> 'picture': DragNDropFileButtonInput(button_text='Select file
> to Upload',
> button_classes='btn
> btn-bordered uploader'),
> }
>
>
>
> General comments first:
>
>1. I would say there's no better way to accomplish what is currently
>on that form given the current Form Meta API. (Willing to be challenged on
>this point, btw.)
>2. The repetition of picture 3 times over (fields tuple, labels dict,
>widgets, dict) seems to be inherently not DRY. If this gets very long, then
>it becomes harder to manage.
>3. The API on the Model Form itself behaves not quite like you'd
>expect initially. You'd expect redeclaring fields directly on a form for it
>to function like a dictionary update, if the value doesn't exist in the
>incoming dictionary, it keeps what's there. It actually behaves like
>re-declaration. This very significant behavior is buried in a note (
>https://docs.djangoproject.com/en/2.0/topics/forms/
>modelforms/#overriding-the-default-fields
>
> ).
>Additionally, you'll have sources like pydanny basically tell you this is
>an anti-pattern: https://www.pydanny.com/overloading-form-fields.html
>4. The API on Meta leads you to believe initially that you can
>override lots of things via Meta, and it's difficult to discover what is or
>is not supported. (I usually dig into django.forms.models, and then wander
>around until I get to ModelForm.)
>   - Here's the list: *model, fields, exclude, widgets,
>   localized_fields, labels, help_texts, error_messages, field_classes

Re: Why Django render DateField type as text instead of date ?

[Collin Anderson]

Hi,

The history of why is here:
https://code.djangoproject.com/ticket/16630#comment:11

You can get type="date" like so on your form: birth_date
= forms.DateField(attrs={'type': 'date'}, required=False)

Thanks,
Collin


On Tue, Jan 23, 2018 at 12:43 AM, Ruchit Bhatt  wrote:

> Hi folks,
> Here i am eager to find out why django render model dateField type as text
> ??
>
> 
>
> instead of
> 
>
> *Is there any alternative or inbuilt method to render datefield as date ?*
>
>
> This is my code
>
> *models.py*
> class HumanUser(AbstractUser):
> birth_date = models.DateField(null=True, blank=True, verbose_name=
> u"DOB")
>
>
> *forms.py*
> class profile_form(forms.ModelForm):
>
> def __init__(self, *args, **kwargs):
> kwargs.setdefault('label_suffix', '')
> super(profile_form, self).__init__(*args, **kwargs)
> for field in self.fields:
> self.fields[field].widget.attrs.update({'class': 'form-control
> form-control-line', })
>
> class Meta:
> model = User
> fields = [
> 'full_name',
> 'birth_date',
> 'mobile',
> 'bio',
> 'gender',
> ]
>
>
> *HTML output*
>
>  id="id_birth_date" />
>
>
>
> --
> 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/caa35f1c-3a8e-4e45-954b-
> 14876efdf8db%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/CAFO84S7iFbgnV7FqE56xvM_EuY5sYA9jXAgErxmkie8ijgxbFg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Don't assume that missing fields from POST data are equal to an empty string value.

[Collin Anderson]

Maybe it would be helpful to have an option where it errors if
(non-boolean) fields are non-existent in the POST data? (Though I have some
GET-forms where I would not want that behavior) Maybe I could somehow set
allow_missing_fields = True in that case?

On Tue, Jan 23, 2018 at 4:56 AM, Tai Lee  wrote:

> From my perspective, this issue is about silent data loss, which is about
> one of the worst bugs you can have and one that Django typically tries very
> hard to avoid or fix, even if it breaks compatibility.
>
> It is extremely easy to cause silent data loss with the behaviour being
> discussed. For whatever reason, if a field is not provided in the request
> data, then Django is assuming it is an empty string and overwriting
> existing data.
>
> Sure, if you're in complete control over your backend and frontend and you
> explicitly tell your model forms which fields to *include* (not exclude),
> you can protect yourself against *one* scenario where additional fields are
> added to a model but the developer forgets to update the corresponding form
> class.
>
> But that's not the only scenario. If you *exclude* fields, then new fields
> added to the model will still be included automatically, and if the form
> data doesn't include them, there could be silent data loss.
>
> And the client submitting data could be completely outside the control of
> the backend developer. Either it's managed by another developer or another
> team, or it's entirely 3rd party code that the backend developer doesn't
> even know exists. Explicitly defining which fields to include or exclude
> won't help prevent silent data loss here.
>
> Cheers.
> Tai.
>
>
> On Tue, Jan 23, 2018 at 10:13 AM, Curtis Maloney 
> wrote:
>
>> On 01/22/2018 06:03 PM, Anupam Jain wrote:
>>
>>> Wow - I just realised that we have been losing data for sometime on our
>>> web platform since there were some fields in the ModelForm that were hidden
>>> and not being sent. They were all being overwritten as blank values. Thank
>>> God, we use django-reversion to track changes. Will take us sometime to
>>> recover the data though.
>>>
>>
>> Just something vaguely related that this post prompted in me ...
>>
>> My general guide is... if you're using hidden fields, then you're
>> probably doing it wrong.
>>
>> There are very few valid cases for passing data in hidden fields. In most
>> cases you really want to exclude the fields from the model. This has the
>> added benefit of protecting from a malicious user who edits the values of
>> the hidden fields.
>>
>> A ModelForm will _only_ update fields on the model that it has fields
>> for. No matter what the user - or your code [such as clean functions] -
>> manages to get into the cleaned_data dict.
>>
>> --
>> Curtis
>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Django developers  (Contributions to Django itself)" group.
>> To unsubscribe from this topic, visit https://groups.google.com/d/to
>> pic/django-developers/w8UKCLjOMpg/unsubscribe.
>> To unsubscribe from this group and all its topics, 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/ms
>> gid/django-developers/f06e134e-f596-3938-0bdf-daea0a56d505%40tinbrain.net
>> .
>>
>> 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/ms
> gid/django-developers/CAEJB-EOZX8BuTAXKX63zUmP3XwtaPuwSgajXF
> 7gO%2BVBd%2BHJ2hQ%40mail.gmail.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/CAFO84S5WXub3qofQKh%3DzfCvJLLh9foJ%3DipS0Zgv-hgzatTX%2BUA%40mail.gmail.com.
For more options, visit https://g

Re: ManytoMany Field save_form_data has not support for through table

[Collin Anderson]

Hi Andrew,

Sure, do you want propose some tests? You could even open a new PR.

Thanks,
Collin
574-339-1060


On Thu, Jan 18, 2018 at 12:40 AM, Andrew Standley 
wrote:

> Hi Collin,
>   The patch seems to work perfectly with intermediate models without
> required fields.
>
> However looking over the pull request I noticed that there does not
> appears to be success tests for intermediate models with extra required
> fields.
> Is this something I could help out with?
>
> Cheers,
>   Andrew
>
> --
> 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/e5ca3a21-3f27-441c-a4cf-
> 7a5ed9aa4f60%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/CAFO84S7jdD8i%2BQirNTfKRTdLF%2Bf-6Lu-7k2L1asv3A7X%3Dsic_w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: ManytoMany Field save_form_data has not support for through table

[Collin Anderson]

Hi Andrew,

Would allowing set() for through models help in your case?
https://github.com/django/django/pull/8981

Thanks,
Collin


On Mon, Jan 15, 2018 at 5:14 PM, Andrew Standley <
astand...@linear-systems.com> wrote:

> Greetings,
> I've been messing around with trying to update some custom forms to
> instead be model forms, and I ran into something that struck me as odd.
>
> ModelForm relies on the models fields to select a default form field, and
> to save the returned form data. However the ManytoManyField does not appear
> to have behavior for dealing with 'through' models. The save_form_data just
> calls `set` on the ManyRelatedManager, which errors out if a through model
> without auto_created=True is defined.
>
> As far as I can tell I either have to write a lot of boiler plate in my
> ModelForm (add a custom field, override the __init__, override save(),
> etc), or define a custom ManyToManyField which overrides save_form_data.
> This seems odd to me as the through model seems like the sensible place for
> any behaviour required by the extra fields it defines.
>
> The ManyToMany field has knowledge of everything needed to access the
> intermediate model's default manager. It would make perfect sense to me
> that to have to implement custom clear/add/remove methods on either the
> model or it's manager for any through models that defined extra fields, and
> then be able to plug-and-play with the ModelForm framework. So my question
> is:
>
> Is there any particular reason that save_form_data does not have some
> default behavior for through models?
>
> Cheers,
> Andrew
>
>
>
> --
> This message has been scanned by E.F.A. Project and is believed to be
> clean.
>
>
> --
> 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/ms
> gid/django-developers/e1fe8354-e1d1-05a1-e433-6fcf7e46216a%
> 40linear-systems.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/CAFO84S5crVgjpsNMiU8gPbs%3DYjBmDwrmgMVi9fjLqxBDa%2B7-0g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Hello everyone I'm a new member

[Collin Anderson]

Yes, wait until at least 2019 to deprecate those.
https://code.djangoproject.com/ticket/27753

On Mon, Dec 18, 2017 at 10:45 AM, Adam Johnson  wrote:
> Please don't do that, as I recall we'll just delete django.utils.six after
> the minimum recommended django version for third party libraries is 2.0.
>
> On 18 December 2017 at 15:05,  wrote:
>>
>> Hello Asad,
>>
>> as a first task you can remove the Python2-specifics from
>> django/utils/six.py , and deprecate python_2_unicode_compatible().
>>
>> Greetings
>>   Дилян
>>
>> On Wednesday, December 13, 2017 at 3:10:31 AM UTC+1, Asad Ahmed wrote:
>>>
>>> Hello everyone,
>>> I'm new to open source community. I've been working on python and django
>>> framework for few years now. I've done few projects based on them and ML.
>>> I'm planing for Gsoc.
>>> I would be really grateful if anyone can guide me on how to proceed for
>>> open source contribution on django.
>>>
>>> Thanks
>>> Your sincerely
>>> Asad Ahmed
>>>
>> --
>> 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/5d3082f3-ff2e-442b-9886-04e1e8119eac%40googlegroups.com.
>>
>> For more options, visit https://groups.google.com/d/optout.
>
>
>
>
> --
> Adam
>
> --
> 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/CAMyDDM3RtMCq_Ki8dqb5r%3DU9%2BKHhtb%2BGnYkKPX0dCHO344OPDA%40mail.gmail.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/CAFO84S6GxYXtiFFU-F3r80AzdRCLBH6f%2BaAAqDtu1PuvMdbQxQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: make Model __unicode__() default to self.name

[Collin Anderson]

Hi Alex,

> I think __str__ is a more user/human-friendly thing, which I don't think
can be generated automatically.

Yes, having a good __str__ is important, and thats why i think defaulting
it to the pk is good, because it's better than nothing. Yes, you'll still
want to override __str__ with something better (that likely doesn't include
the PK).

So if you're overriding __str__ anyway, why not also override __repr__ to
include the PK?

Or what are you actually proposing, something like this?
https://github.com/django/django/compare/master...collinanderson:patch-12

Thanks,
Collin




On Mon, Dec 11, 2017 at 6:32 AM, Alex Corcoles  wrote:

> Sorry to resurrect this, but I commented on the bug tracker (
> https://code.djangoproject.com/ticket/28839#comment:4 ) and was told to
> take the discussion here.
>
> I want to point out that __str__ is used for "GUI" purposes (such as
> dropdown texts in ModelForm/ModelAdmin) and putting a default __str__ with
> a PK doesn't seem to make sense. I think __str__ is a more
> user/human-friendly thing, which I don't think can be generated
> automatically.
>
> On the other hand, it does make sense to include the PK in __repr__, so I
> would suggest backtracking on this change and making an equivalent change
> in __repr__.
>
> On Saturday, April 8, 2017 at 8:41:56 PM UTC+2, Collin Anderson wrote:
>>
>> I just made a pull request.
>> https://github.com/django/django/pull/8336
>>
>> (1) is my first choice, pk=1 is my second choice. I'd be fine with either.
>>
>> On Sat, Apr 8, 2017 at 12:08 PM, Marco Silva 
>> wrote:
>>
>>> just saw that __repr__ is now under discusion here
>>> https://groups.google.com/forum/#!topic/django-developers/UNKFMg6DO5s
>>>
>>>
>>> sábado, 8 de Abril de 2017 às 17:06:05 UTC+1, Marco Silva escreveu:
>>>>
>>>> I have no idea what is the best way, just say that comment. this is the
>>>> original PR
>>>> https://github.com/django/django/commit/d2a26c1a90e83dab
>>>> df3d67ceec4d2a70fb86
>>>>
>>>> I think you should submit the PR to change the __str__ method, and
>>>> maybe open a new discussion regarding __repr__
>>>>
>>>> sexta-feira, 7 de Abril de 2017 às 15:34:32 UTC+1, Kapil Garg escreveu:
>>>>>
>>>>> The opened ticket is about Model.__str__ method. Should i open a new
>>>>> ticket for this change ?
>>>>> As i see in code, self.__class__ is used in a lot of places but will
>>>>> it effect optimization if we change lookups from self.__class__ to 
>>>>> self.cls
>>>>>
>>>>> Because the methods where class is being used frequently, already
>>>>> store it in local variable and then make references to local variable.
>>>>>
>>>>> So should it really be changed ?
>>>>>
>>>>> On Fri, Apr 7, 2017, 6:52 PM Marco Silva  wrote:
>>>>>
>>>>>> I noticed this on the init
>>>>>>
>>>>>> def __init__(self, *args, **kwargs):
>>>>>>  # Alias some things as locals to avoid repeat global lookups
>>>>>>  cls = self.__class__
>>>>>>
>>>>>> maybe you should change it to self.cls??
>>>>>> Try to submit a PR to the open ticket.
>>>>>>
>>>>>> segunda-feira, 3 de Abril de 2017 às 21:07:47 UTC+1, Kapil Garg
>>>>>> escreveu:
>>>>>>>
>>>>>>> So does this patch seem fine ?
>>>>>>>
>>>>>>> diff --git a/django/db/models/base.py b/django/db/models/base.py
>>>>>>> index 3c1cb9a..f58e12b 100644
>>>>>>> --- a/django/db/models/base.py
>>>>>>> +++ b/django/db/models/base.py
>>>>>>> @@ -504,7 +504,7 @@ class Model(metaclass=ModelBase):
>>>>>>>  return '<%s: %s>' % (self.__class__.__name__, u)
>>>>>>>
>>>>>>>  def __str__(self):
>>>>>>> -return '%s object' % self.__class__.__name__
>>>>>>> +return '%s object pk=%s' % (self.__class__.__name__,
>>>>>>> self._get_pk_val())
>>>>>>>
>>>>>>>  def __eq__(self, other):
>>>>>>>  if not isinstance(other, Model):
>>>>>>>
>>>>>>>
>>>>>>>
>>

Improving Backward Compatibility

[Collin Anderson]

Hi All,

I think it would help if Django was better at *deprecations and backward 
compatibility*. I’ve brought this up [before 
], 
but didn’t get any feedback, so here’s another try at it, with some *specific 
ideas of how to improve things below*.

*Background*:

The [API docs ] 
say “*If, for some reason, an API declared stable must be removed or 
replaced*, it will be declared deprecated but will remain in the API for at 
least two feature releases.” - I’ve always thought of the “must be removed” 
as “there’s really no alternative”. I think that if it's not broken, Django 
should avoid breaking it.

I maintain lots of Django projects, and upgrading is not a small task. 
There are enough changes to undocumented APIs already happening that it 
would be great if the documented ones didn't change as much.

I also think it’s a little disappointing that *3rd party libraries don’t 
get easy 1.8 and 2.0 support out of the box*. Both of those releases are 
currently supported, but if the library uses deprecated features to support 
1.8, it won’t work on 2.0 by definition.

Yes, backward compatibility means Django has more technical debt, and yes 
it comes at a cost (more code, more docs, tests run longer, more thank-less 
maintenance etc), but it means Django’s not forcing users to do the tedious 
work of changing their code. That’s a _huge_ benefit. Isn’t the whole point 
of a framework to have documented and tested code so the user doesn’t need 
to do tedious things? “it takes care of much of the hassle of Web 
development, so you can focus on writing your app.”

Some deprecations I thought could have gone better: #17209 (auth views), 
#26013 (urls.urlresolvers), #22218 (url patterns()), #23276 (url() 
strings), #14675 (urls.defaults), #6735 (views.generic.simple), #18651 
(assignment_tag).

*Ideas of how to improve backward compatibility*:

*1.* I think it would help if any breaking change, and any new 
deprecation/removal (any change that adds to those sections in the release 
notes) received 3-7 days *feedback from the mailing list*, with a clear 
subject, something like “deprecating X”, "changing x's defaults", “renaming 
X” or “removing X”. It's a little more bureaucracy, but I think there's a 
huge benefit to making sure everyone's on the same page about these things. 
(This already happens for some, but not all deprecations.)

I don’t pay close attention to tickets and pull requests, so I often don’t 
notice that there’s a new deprecation/removal until _after_ it’s already 
been merged. The few people on the ticket may have agreed to removing 
something, but not necessarily the larger community. Or, if it was being 
discussed, a lot of discussion was on the new feature, and it wasn’t clear 
that a deprecation/removal would be included in the change. (Sometimes the 
deprecation is thrown in as an after-thought / "while we're at it, lets 
rename...")

Having a *clear email in django-developers* would also give more people the 
initial heads-up to avoid using the old code.

*2.* For some changes, Django has decided to delay/*hold off 
deprecating/removing a feature until after the next LTS or “eventually”* 
(some good examples: #23433 (django-admin.py), #27753 (utils.six, etc), 
#25236 (ifequal), #25978 (render_to_response), #28593 (url() -> re_path()). 
I think this delay is a really good thing, and I think it should be *more 
official/documented to encourage its use* (if not the default). As [Russ 
put it 

]:

“The only other suggestion I've got is to add a new "pre-deprecation" step 
to our deprecation process - a flag that lets us indicate that at some 
point, we intend to deprecate something, but we haven't decided when that 
will be. This would essentially be a "*don't use this on new code, but 
there's no rush in replacing it*". It could also be accompanied with a 
Warning so that existing uses could be found and replaced if someone was so 
inclined.”

Delaying the removal would *help libraries support both 1.8 and 2.0* (for 
example) at the same time. (Also, I think a longer removal timeline might 
make it a little less likely for something to be deprecated/removed in the 
first place. - A good thing, in my opinion.)

Thanks,
Collin

[before] 
https://groups.google.com/d/msg/django-developers/ZWy2Esj46nE/jzSP3DRIEAAJ

[API docs] https://docs.djangoproject.com/en/2.0/misc/api-stability/

[Russ put it] 
https://groups.google.com/d/msg/django-developers/J7vpMKSHk7U/3vGPs71MCgAJ

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

Re: Feature request: get_first_or_404

[Collin Anderson]

Is there a different between get_first_or_none() and the already existing
first()?

If we do first, some may want get_last_*() for everything too :)

On Tue, Nov 28, 2017 at 8:31 PM, Josh Smeaton 
wrote:

> From my experiences, all projects I've worked on have implemented
> get_first_or_none and get_first_or_404, and usually slightly differently. I
> think these shortcuts would make sense for Django. Interested to hear how
> common the usage would be from others on the list though.
>
> --
> 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/ms
> gid/django-developers/fcabccc7-3da2-456f-ad92-90145b700635%
> 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/CAFO84S5RjujimJHhs6aU9dRqF5jQH8An8dA-3mrY2Y37_CFEcg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Templates: __html__ method support

[Collin Anderson]

I think this is a good idea. Django has used __html__ internally for the
last 4 years so it's not something new [0]. I'm surprised this doesn't work
out-of-the box.

[0] https://code.djangoproject.com/ticket/7261

On Tue, Sep 26, 2017 at 9:26 AM, George-Cristian Bîrzan 
wrote:

> On Tuesday, September 26, 2017 at 3:34:29 PM UTC+3, Jonas H wrote:
>>
>> Proposal: Support the __html__ method as an alternative/addition to the
>> __str__ for turning objects into strings in the template layer.
>>
>>
> Dunder methods' names shouldn't be invented, so a better name is needed.
>
> --
> 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/16f056c0-0ed8-424f-ae9e-
> 9ab7a7bf66cb%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/CAFO84S6Wx8APyAtTH1Z-p_YJi%3DFYkLUqWq2tdrtbevzJAiqndQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: New Feature: Allow password reset token to expire in under a day

[Collin Anderson]

Seconds is consistent with all of the other settings, even for long ones
like CSRF_COOKIE_AGE and SESSION_COOKIE_AGE. It also means you can avoid
importing datetime in your settings file.

On Thu, Sep 21, 2017 at 8:36 PM, Tom Forbes  wrote:

> It also seems odd to express it as seconds, it's often going to be a large
> value between an hour and several days and the lowest resolution for the
> value anyone would need is minutes.
>
> On 22 Sep 2017 01:29, "Tom Forbes"  wrote:
>
>> I would still vote for a timedelta, im not sure if there is a strong
>> consensus in the thread.
>>
>> Representing the time as seconds always irks me, you can make it more
>> readable by using multiplication but you often end up with a comment anyway
>> and it doesn't scan nearly as well. Having to do 'timedelta.seconds' is OK,
>> but it seems a bit like busywork.
>>
>> It's a small thing but I don't see any practical problem with just
>> accepting a timedelta, they are nicer to work with in the settings file
>> itself and within Django, especially if the TimestampSigner accepts them
>> natively and we start to use that.
>>
>> On 21 Sep 2017 22:41, "Zhiqiang Liu"  wrote:
>>
>> If most agree, I will proceed with using seconds.
>>
>> It is a good idea for the potential documentation Dylan!
>>
>> Zach
>>
>>
>> On Thursday, September 21, 2017 at 10:09:50 AM UTC-4, Dylan Reinhold
>> wrote:
>>
>>> I still think seconds are the way to go, but maybe the documentation
>>> could give a clue that timedelta().seconds can be used for readability
>>> PASSWORD_RESET_TIMEOUT = datetime.timedelta(hours=6, minutes=30).seconds
>>>
>>> Dylan
>>>
>>> On Thu, Sep 21, 2017 at 6:14 AM, Zhiqiang Liu 
>>> wrote:
>>>
 Yeah I don't think float number of days is a good choice because the
 calculation will be weird with precision issues.

 I think it makes sense to use PASSWORD_RESET_TIMEOUT. For timedelta vs.
 integer seconds. Timedelta has the benefit of readability, but integer has
 the benefit of simplicity. I think in SETTINGS everything should be as
 simple as possible, so I think integer seconds is a better choice here. And
 it is used in most applications too.


 On Thursday, September 21, 2017 at 8:56:36 AM UTC-4, charettes wrote:
>
> That's what I proposed on the ticket but I feel like it felt odd to
> me, the setting name does't suggest this is possible and it might be hard
> to achieve exact second precious because of float rounding?
>
> In my opinion introducing PASSWORD_RESET_TIMEOUT with timedelta
> support would be the best option.
>
> Simon
>
> Le jeudi 21 septembre 2017 05:26:23 UTC-4, Adam Johnson a écrit :
>>
>> Why not just keep PASSWORD_RESET_TIMEOUT_DAYS and allow floats? Then
>> you can just do 1/24 for an hour.
>>
>> On 21 September 2017 at 09:50, Eddy C  wrote:
>>
>>> I think Minute, with default value 30 or 60, is the best unit for
>>> this setting.
>>>
>>> 3 minutes (even 1) is short enough for edge case and 720 (12 hours)
>>> also looks good.
>>>
>>> On Thursday, September 21, 2017 at 6:22:20 PM UTC+10, Tom Forbes
>>> wrote:

 I think we shouldn't shoe-horn a timedelta into the existing
 setting, so my vote is with the second option, but I think a timedelta 
 is
 much more readable than just an integer.

 Also, the existing 3 day timeout for password links is quite
 surprising from a security point of view. The consultants I work with 
 would
 flag up a token that lasts longer than 12 hours as an issue during a
 pentest.

 IMO a new, far shorter default should be added to this setting.

 On 21 Sep 2017 03:56, "Zhiqiang Liu"  wrote:

 I need general consensus on how to proceed with supporting password
 expire time to be under a day. Currently it is not possible because we 
 use
 PASSWORD_RESET_TIMEOUT_DAYS.

 In ticket 28622  we
 have two options.

 One is to continue to use the same setting
 PASSWORD_RESET_TIMEOUT_DAYS, but change the value to non-integer (such 
 as
 timedelta) so we can send hours, minutes, etc to it.

 The other one is to create a new setting like
 PASSWORD_RESET_TIMEOUT which takes seconds.To support backward
 compatibility, I think we should keep PASSWORD_RESET_TIMEOUT_DAYS and 
 its
 default value of 3. Only use PASSWORD_RESET_TIMEOUT when provided.

 I'm unsure which one is better, so inputs are welcome.

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

Re: drop support for MySQL 5.5 in Django 2.0?

[Collin Anderson]

As a datapoint for MySQL, Most of my websites are on Ubuntu 16.04 (Python
3.5, MySQL 5.7), though I do have one on 14.04 (Python 3.4, MySQL 5.5) that
I _would_ upgrade to Django 2.0 if we kept 5.5 support, but it's not a big
deal to leave it at 1.11 until I switch to 16.04.

On Sat, Aug 26, 2017 at 11:09 AM, Tim Graham  wrote:

> MySQL 5.5 is end-of-life in December 2018. Usually we drop support for a
> particular database version in the Django release prior to the end-of-life
> date [0], so that would mean dropping support in Django 2.1 (released
> August 2018). We don't have MySQL 5.5 testing in our continuous integration
> servers and in local testing, I noticed some GIS test failures with MySQL
> 5.5. Before investigating them, I thought I'd ask to see if there might be
> consensus to drop support for MySQL 5.5 in Django 2.0 instead of 2.1. I'd
> guess anyone using MySQL 5.5 users would stick with Django 1.11 LTS or
> older.
>
> https://github.com/django/django/pull/8980 shows the cleanups for removal
> of MySQL 5.5 support. Also, MySQL 5.5 is the last usage among the built-in
> database backends for the supports_microsecond_precision database feature
> so there's a chance that could be removed also, though I found usage of it
> in django_pyodbc [1].
>
> [0] https://code.djangoproject.com/wiki/SupportedDatabaseVersions -- though
> we've made some exceptions like dropping support earlier for Oracle 11,
> https://groups.google.com/forum/#!topic/django-developers/IawbBWzPXaA/
> discussion
> [1] https://github.com/lionheart/django-pyodbc/issues/87
>
> --
> 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/367b0ca0-1ec9-48b6-a513-
> 4c66a30c491d%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/CAFO84S7E6Zp284KUKv2NALN3G%2BBUWMxMPPt2uJDFcMtGuz3aig%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: I would like to discuss my proposal for a working way to call .add() on an m2m with through= model

[Collin Anderson]

Hi All,

I have a pull request for simple add()/create() etc with m2m through tables
if any wants to try it out: https://github.com/django/django/pull/8981

If people are happy with the API, I'll add the docs too.

Collin


On Mon, Apr 17, 2017 at 3:53 PM, Luis Masuelli 
wrote:

> I'm quite happy to see the topic is at least being considered! <3.
>
> Although I suggested a solution, I like the solution posted by Collin in
> the PR (I'd prefer solutions not involving signature changes in methods,
> but anyway those signature changes Colin posted are not so... obtrusive).
>
> I'd like to, however, propose a little change in Collin's code.
> Immediately before this code in _add_items:
>
> self.through(**dict(through_defaults, **{
> '%s_id' % source_field_name:
> self.related_val[0],
> '%s_id' % target_field_name: obj_id,
> }))
>
> This one:
>
> if callable(through_defaults):
> through_defaults =
> through_defaults(self.related_val[0], obj_id)
>
> With these two lines, we could allow passing a callable to through_fields
> (as we pass callables for defaults in django fields). The return value of
> such callable should be a dictionary, while the arguments should be source
> and target ids.
>
> But even if this little change is not implemented, I like the Collin's
> solution anyway.
>
> Another subtopic to discuss is about enhancing the Collin's solution, is
> to allow through_defaults be specified on field definition (In the same way
> we define default values in... scalar... fields; I leave open the
> discussion on whether such value should be overriden when using add,
> create, or any of these methods as changed by Collin).
>
> I like how this is going and hope that any solution (even if it is just
> the as-is solution provided by Collin, with no changes) be accepted in any
> near-future version <3.
>
> El martes, 21 de marzo de 2017, 20:29:33 (UTC-5), Alex Hill escribió:
>>
>> Here's a little bit more historical discussion on the topic: 
>> *https://groups.google.com/d/topic/django-developers/uWe31AjzZX0/discussion
>> *
>>
>> On Wed, 22 Mar 2017 at 05:57 Russell Keith-Magee 
>> wrote:
>>
>>> On Tue, Mar 21, 2017 at 2:37 PM, Adam Johnson  wrote:
>>>
 It does seem like a somewhat arbitrary historical restriction. Collin's
 PoC change is surprisingly small and simple.

 Seems like it would be fine if Django allowed add() and let any errors
> about missing data bubble-up.
>

>>> As the person who *made* the “somewhat arbitrary historical
>>> restriction”… :-)
>>>
>>> Honestly - the reason it was made was scope creep.
>>>
>>> I was trying to land Eric’s work on #6095, which was already moderately
>>> complex. Nobody disagreed that adding an object to an m2m with a through
>>> model was a *bad* idea - there were just a few design decisions that had to
>>> be made. But if we made those decisions, #6095 was going to take *another*
>>> couple of months to land; the perfect being the enemy of the good, we
>>> decided to limit scope and land “simple” m2m add, and revisit the issue
>>> later.
>>>
>>> I guess now is “later”… :-)
>>>
>>> Yours,
>>> Russ Magee %-)
>>>
>>> --
>>> 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/ms
>>> gid/django-developers/CAJxq849m632K%3DaMfXGBtF%3DhMXFS9ujzU6
>>> xfUzNxSRkkN_UrkqQ%40mail.gmail.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/a32cf6ae-324a-40c1-b9d9-
> 31bd43af2c2c%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d

Re: To keep or not to keep: logging of undefined template variables

[Collin Anderson]

I used to do that too (string_if_invalid that raises an exception). What
was nice about this, is you could explicitly wrap the variable in an if tag
to silence the error if you were ok with it. (I'm not sure if this behavior
is still true.)

{% if var_that_sometimes_exists %}{{ var_that_sometimes_exists }}{% endif %}

On Thu, Aug 24, 2017 at 11:59 AM, Sjoerd Job Postmus 
wrote:

> As an anecdotal data-point: at the company I'm working at, we are running
> Django with a custom object as "string_if_invalid" that raises an exception
> on string-interpolation. This way missing template variables *do* get
> converted to an exception. I myself am very happy with this solution, as it
> forces us to make sure templates and views match up correctliy. The essence
> is that it's better to get an exception, than incorrect output (Yes, you
> should test beforehand, but sometimes there's a combinatorial explosion
> that makes that hard).
>
>
> On Thursday, August 24, 2017 at 5:21:38 PM UTC+2, Tim Graham wrote:
>>
>> We received a report that shows the large number of undefined variable
>> warnings when rendering an admin changelist page [0].
>>
>> I'm still not sure what the solution should be, but I created #28526 [1]
>> to track this problem: finding a remedy to the problem of verbose, often
>> unhelpful logging of undefined variables.
>>
>> I don't think "the end goal of errors raising when using undefined
>> variables" is feasible. My sense is that relying on the behavior of
>> undefined variables is too entrenched in the Django template language to
>> change it at this point. (If someone wanted to try to fix all the warnings
>> in the admin templates, that might provide a useful data point). See the
>> "Template handling of undefined variables" thread [2] for a longer
>> discussion.
>>
>> [0] https://code.djangoproject.com/ticket/28516
>> [1] https://code.djangoproject.com/ticket/28526
>> [2] https://groups.google.com/d/topic/django-developers/LT5ESP0w
>> 0gQ/discussion
>>
>> On Tuesday, June 20, 2017 at 4:12:52 AM UTC-4, Anthony King wrote:
>>>
>>> -1 for removing logs. Like Vlastimil, it's helped me spot a couple of
>>> stray bugs.
>>>
>>> What I'd actually like to see is this becoming stricter, with the end
>>> goal of errors raising when using undefined variables.
>>>
>>> For the verbosity, perhaps there's a middle ground? only log once per
>>> variable access per template context, and provide a formatter that will
>>> clean up the output?
>>>
>>> I believe in debug mode, you have access to line numbers and character
>>> positions, so the final output could look something like this:
>>>
>>> ``
>>> some_app/home.html:32:24: Undefined variable: *missing_variable*
>>> ``
>>>
>>> I'm unsure how much effort this would take, but it would definitely make
>>> the logging a lot more user + developer friendly.
>>>
>>> On 20 June 2017 at 08:48, Vlastimil Zíma  wrote:
>>>
 -1 to the removal. I was annoyed by the logging at first, but then I
 started to clean individual logs. Half way through, I found several usages
 of long removed variables, one unused template (as a side effect) and I
 updated several views to always provide defined context variables.

 All in all, I consider the warnings very useful for a cleaning, though
 I wouldn't be against an option to silence them. Which can already by
 accomplished by LOGGING, can't it?

 Vlastik

 Dne neděle 26. března 2017 11:14:23 UTC+2 Melvyn Sopacua napsal(a):
>
> On Thursday 16 March 2017 12:03:07 Tim Graham wrote:
>
> > Ticket #18773 [0] added logging of undefined template variables in
>
> > Django 1.9 [1], however, I've seen several reports of users finding
>
> > this logging more confusing than helpful.
>
>
>
> With channels hitting 2.0 and the already large stack of moving parts
> surrounding Django you need some basic system administration skills and
> programming experience to work with the system. And there are quite a few
> examples to link to from the user's list that deal with those moving parts
> rather then Django itself. It is not an application that you
> download, install and run.
>
>
>
> An introduction "What you need to know before starting Django" would
> help a lot in this respect and explaining the noisiness of some logging
> belongs in there.
>
>
>
> Because it *is* useful if you defined that variable to True in your
> settings, and it's working in all projects but this one. It could be
> there's an extra piece of context middleware that uses the same name and
> deletes the variable from the context. It could be there's a Mixin missing
> in the view hierarchy. Or a typo you don't notice anymore after plowing
> through 20+ included template bits.
>
>
>
> Noisy logging is exactly what you want when debugging. It should log
> things that may be working as designed

Re: Automatic prefetching in querysets

[Collin Anderson]

I like that idea - keep it a private API for now and make it a public API
once people have used it a little bit.

On Fri, Aug 18, 2017 at 4:01 AM, Shai Berger  wrote:

> On Friday 18 August 2017 09:08:11 Anssi Kääriäinen wrote:
> > Maybe we should just add the queryset method. This is the smallest atomic
> > task that can be done. Even if there's only the queryset method
> available,
> > it's possible to enable prefetches per model by using a Manager.
> >
> I disagree on both counts: I don't think it's the smallest atomic task, and
> I'm not so sure it's the right thing to do.
>
> The smallest atomic task, the way I see it, is building the infrastructure
> that would allow adding the queryset method -- but would also allow
> different
> APIs to be set around it.
>
> And since there is as yet no consensus on the correct API for "end" users,
> I
> would rather not define one immediately.
>
> Shai.
>

-- 
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/CAFO84S4hduThLVTwN-Y0uqVy48aRRndvMgzmGOb24zTD9g0wmQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Automatic prefetching in querysets

[Collin Anderson]

"turn it on/off per model" - I wonder if we just have a custom
manager/mixin for the per model case. objects =
AutoPrefetchRelatedManager(). The manager can return a queryset with
prefetch_related(auto=True) or whatever already applied.

On Thu, Aug 17, 2017 at 1:33 PM, Andrew Godwin  wrote:

> Just some quick thoughts, as most of the points I would bring up have been
> discussed:
>
> - This should definitely be opt-in for the first release, it's too big a
> change to make opt-out straight away.
>
> - You should be able to turn it on/off per model, probably in Meta, not in
> a setting, and obviously be able to override it on the queryset level
>
> - I am concerned for the nasty performance edge cases this will cause with
> single-object access patterns (like Anssi's example), but I think the
> overall gain would likely be worth it.
>
> In general, very large sites won't be able to use this at all as JOINs or
> cross-table queries in one piece of code aren't allowed, but they probably
> already have plenty of expertise in this area. We also need to give
> consideration to how it will interact with multiple database support, and
> third-party solutions to things like sharding.
>
> Andrew
>
> On Thu, Aug 17, 2017 at 2:02 AM, Malcolm Box  wrote:
>
>> Hi,
>>
>> I think there's a potential to make this opt-in, and improve the
>> out-of-box experience.
>>
>> Summarising the discussion, it seems that the rough consensus is that if
>> we were building the ORM from scratch, then this would be entirely sensible
>> behaviour (with necessary per-QS ways to disable) - it would remove a
>> common performance problem (N+1 queries), would improve areas where adding
>> prefetch_related to queries is awkward, and in rare cases where it
>> decreased performance there would be documented ways to fix.
>>
>> So the main disagreement is about how to get there from here, and there's
>> concern about three types of users:
>>
>> 1 - Existing, non-expert users whose sites work now (because otherwise
>> they would have already fixed the problem) but who have lurking N+1 issues
>> which will break them later
>> 2 - Existing, non-expert users whose sites work now, but would have
>> performance issues if this was enabled by an upgrade
>> 3 - Existing, expert users who have already found and fixed the issues
>> and who could therefore get no benefit but might suffer a performance
>> degradation.
>>
>> I'll assert that the size of these populations above is listed in roughly
>> size order, with #1 being the biggest. This is a hunch based on most sites
>> not having huge tables where N+1 becomes a problem - at least not until
>> they've been running for a few years and accumulated lots of data...
>>
>> There is another population that hasn't been considered - users starting
>> django projects (ie people running django-admin startproject). Over time,
>> this is by far the largest population.
>>
>> So would a sensible approach be:
>>
>> - Feature is globally opt-in
>> - startproject opts in for new projects
>> - Release notes mention the new flag loudly, and encourage people to try
>> switching it on
>> - We add the debug tracing to help people find places where this setting
>> would help - and encourage them to enable it globally before trying
>> individual queryset.prefetch_related
>>
>> Then over time, all new projects will have the new behaviour. Old
>> projects will gradually upgrade - everyone in category 1 will hit the "make
>> it work" switch the first time they see the warning / see a problem.
>> Experts can choose how they migrate - as Adam points out, even experts can
>> miss things.
>>
>> Finally after a suitable warning period, this can become an opt-out
>> feature and we arrive in the sunny world of an ORM that works better for
>> all users.
>>
>> Cheers,
>>
>> Malcolm
>>
>> On Wednesday, 16 August 2017 21:17:49 UTC+1, Aymeric Augustin wrote:
>>>
>>> On 15 Aug 2017, at 11:44, Gordon Wrigley  wrote:
>>>
>>> I'd like to discuss automatic prefetching in querysets. Specifically
>>> automatically doing prefetch_related where needed without the user having
>>> to request it.
>>>
>>>
>>>
>>> Hello,
>>>
>>> I'm rather sympathetic to this proposal. Figuring out N + 1 problems in
>>> the admin or elsewhere gets old.
>>>
>>>
>>> In addition to everything that was said already, I'd like to point out
>>> that Django already has a very similar "magic auto prefetching" behavior in
>>> some cases :-)
>>>
>>> I'm referring to the admin which calls select_related() on non-nullable
>>> foreign keys in the changelist view. The "non-nullable" condition makes
>>> that behavior hard to predict — I'd go as far as to call it non
>>> deterministic. For details, see slide 54 of https://myks.org/data/20161
>>> 103-Django_Under_the_Hood-Debugging_Performance.pdf and the audio
>>> commentary at https://youtu.be/5fheDDj3oHY?t=2024.
>>>
>>>
>>> The feature proposed here is most useful if it's opt-out because it
>>> targets people who aren't aware that the prob

Re: Automatic prefetching in querysets

[Collin Anderson]

Hi Gordon,

How is it implemented? Does each object keep a reference to the queryset it
came from?

Collin

On Tue, Aug 15, 2017 at 2:44 PM, Gordon Wrigley 
wrote:

> Sorry maybe I wasn't clear enough about the proposed mechanism.
>
> Currently when you dereference a foreign key field on an object (so
> 'choice.question' in the examples above) if it doesn't have the value
> cached from an earlier access, prefetch_related or select_related then
> Django will automatically perform a db query to fetch it. After that the
> value will then be cached on the object for any future dereferences.
>
> This automatic fetching is the source the N+1 query problems and in my
> experience most gross performance problems in Django apps.
>
> The proposal essentially is to add a new queryset function that says for
> the group of objects fetched by this queryset, whenever one of these
> automatic foreign key queries happens on one of them instead of fetching
> the foreign key for just that one use the prefetch mechanism to fetch it
> for all of them.
> The presumption being that the vast majority of the time when you access a
> field on one object from a queryset result, probably you are going to
> access the same field on many of the others as well.
>
> The implementation I've used in production does nest across foreign keys
> so something (admittedly contrived) like:
> for choice in Choice.objects.all():
> print(choice.question.author)
> Will produce 3 queries, one for all choices, one for the questions of
> those choices and one for the authors of those questions.
>
> It's worth noting that because these are foreign keys in their "to one"
> direction each of those queryset results will be at most the same size (in
> rows) as the proceeding one and often (due to nulls and duplicates) smaller.
>
> I do not propose touching reverse foreign key or many2many fields as the
> generated queries could request substantially more rows from the DB than
> the original query and it's not at all clear how this mechanism would
> sanely interact with filtering etc. So this is purely about the forward
> direction of foreign keys.
>
> I hope that clarifies my thinking some.
>
> Regards
> G
>
> On Tue, Aug 15, 2017 at 7:02 PM, Marc Tamlyn 
> wrote:
>
>> Hi Gordon,
>>
>> Thanks for the suggestion.
>>
>> I'm not a fan of adding a layer that tries to be this clever. How would
>> possible prefetches be identified? What happens when an initial loop in a
>> view requires one prefetch, but a subsequent loop in a template requires
>> some other prefetch? What about nested loops resulting in nested
>> prefetches? Code like this is almost guaranteed to break unexpectedly in
>> multiple ways. Personally, I would argue that correctly setting up and
>> maintaining appropriate prefetches and selects is a necessary part of
>> working with an ORM.
>>
>> Do you know of any other ORMs which attempt similar magical
>> optimisations? How do they go about identifying the cases where it is
>> necessary?
>>
>> On 15 August 2017 at 10:44, Gordon Wrigley 
>> wrote:
>>
>>> I'd like to discuss automatic prefetching in querysets. Specifically
>>> automatically doing prefetch_related where needed without the user having
>>> to request it.
>>>
>>> For context consider these three snippets using the Question & Choice
>>> models from the tutorial
>>>  
>>> when
>>> there are 100 questions each with 5 choices for a total of 500 choices.
>>>
>>> Default
>>> for choice in Choice.objects.all():
>>> print(choice.question.question_text, ':', choice.choice_text)
>>> 501 db queries, fetches 500 choice rows and 500 question rows from the DB
>>>
>>> Prefetch_related
>>> for choice in Choice.objects.prefetch_related('question'):
>>> print(choice.question.question_text, ':', choice.choice_text)
>>> 2 db queries, fetches 500 choice rows and 100 question rows from the DB
>>>
>>> Select_related
>>> for choice in Choice.objects.select_related('question'):
>>> print(choice.question.question_text, ':', choice.choice_text)
>>> 1 db query, fetches 500 choice rows and 500 question rows from the DB
>>>
>>> I've included select_related for completeness, I'm not going to propose
>>> changing anything about it's use. There are places where it is the best
>>> choice and in those places it will still be up to the user to request it. I
>>> will note that anywhere select_related is optimal prefetch_related is still
>>> better than the default and leave it at that.
>>>
>>> The 'Default' example above is a classic example of the N+1 query
>>> problem, a problem that is widespread in Django apps.
>>> This pattern of queries is what new users produce because they don't
>>> know enough about the database and / or ORM to do otherwise.
>>> Experieced users will also often produce this because it's not always
>>> obvious what fields will and won't be used and subsequently what should be
>>> prefetched.
>>> Additionally th

Re: Admin actions.js performance

[Collin Anderson]

I can confirm it's slightly faster in my case (maybe 20-50ms for 58 rows, 3
inputs per row).

I can get it ~15ms faster by making it just one event handler, though it's
a bigger change:
$('#result_list').on('change', 'td:nth-child(n+2) :input', function() {

On Fri, Aug 4, 2017 at 7:29 AM, ecas  wrote:

> Hi,
>
> I was doing some loading time benchmarking in Chrome and I noticed that
> the javascript that sets up the actions in the admin page takes some time.
>
> I pinpointed the problem to this jquery:
>
> $('form#changelist-form table#result_list tr').find('td:gt(0)
> :input').change(function() {
> list_editable_changed = true;
> });
>
> If I replace it with the following top-down approach, the execution time
> of the overall function call is reduced from ~115ms to ~53ms (as seen in
> the attached screenshots)
>
> $('form#changelist-form table#result_list tr')
> *.find('td:gt(0)').find(':input')*.change(function() {
> list_editable_changed = true;
> });
>
> Has anybody noticed this or can reproduce it?
>
> Thanks!
>
> --
> 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/86804109-cd6d-4514-82c1-
> 72b53e000ef2%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/CAFO84S5OPJ-1crxYrhPgW%3DfpVZcgfYjWGEyy2wi_Gpr9KRnLPw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Default to BigAutoField

[Collin Anderson]

I might be wrong, but if the default changes, won't the migrations detect
it and migrate it just fine, including foreign keys?

All of my migrations have this:
('id', models.AutoField(auto_created=True, primary_key=True,
serialize=False, verbose_name='ID')),

So everyone would either need to manually specify the AutoField to keep the
old behavior, or run makemigrations to auto-generate migrations to
BigAutoField. This seems similar to increasing the max_length of
EmailField, user.username, and user.last_name, though would affect a lot
more models in this case.

(I'm not sure what I think about the setting idea.)

(While we're at it, maybe we could make it a (new) PositiveBigAutoField to
help out the mysql folks and close the oldest open ticket:
https://code.djangoproject.com/ticket/56 :)



On Fri, Jun 9, 2017 at 9:37 PM, Tim Graham  wrote:

> I'm not sure how this could work with migrations. In a sense, it would
> involve making the auto-generated primary key "swappable", including
> foreign keys that point to it. This sounds like a headache.
>
> I haven't thought of a possible solution since Kenneth floated this idea
> in #django-dev yesterday.
>
> On Friday, June 9, 2017 at 7:11:05 PM UTC-4, Curtis Maloney wrote:
>>
>> I know people hate settings, but what about one for auto id field type?
>>
>> It would let you handle backwards compatibility, uuid, and bigint...
>>
>> --
>> C
>>
>>
>> On 10 June 2017 5:42:42 AM AEST, Jacob Kaplan-Moss 
>> wrote:
>>>
>>> I think this would be a good improvement, and I'd like to see it. I've
>>> been bitten by integers overflowing at least twice I can remember in my
>>> career, which is two times too many.
>>>
>>> However, a major thing we'd have to work out is the upgrade path
>>> Consider a simple model:
>>>
>>> class Person(Model):
>>> name = CharField()
>>>
>>> In Django 1.11, this actually generates a model with an integer `id`
>>> field. But in we change it, in Django vNext, that `id` field would "turn
>>> into" a bigint magically without the underlying table changes. That'd be
>>> confusing: you'd expect the model to be "fixed" by pugrading to vNext, but
>>> it wouldn't be. I think the migrations engine would detect this as a
>>> migration (?), so perhaps that's the path forward, but it could still be
>>> super-confusing. We've never shipped a release of Django that required a
>>> migration to _all_ your models.
>>>
>>> Have you thought about what the upgrade path should look like, Kenneth?
>>>
>>> Jacob
>>>
>>> On Fri, Jun 9, 2017 at 11:24 AM, Kenneth Reitz 
>>> wrote:
>>>
 Dear Django Dev,



 At Heroku, we have the privilege of seeing an extremely broad range of
 customers utilizing tools like Django to build their applications and
 companies. One of the things that we’ve seen customers hit, time and time
 again when using tools like Django, is integer overflows for primary keys.
 Their application starts behaving unpredictably once they reach the
 overflow, not even knowing such a constraint exists, and they often think
 the problem is with their database provider, rather than with their schema.
 Once they realize what is wrong, it’s a relatively trivial fix, but a
 migration can take several hours to complete, which results in unacceptable
 amounts of downtime.



 Because of this, Heroku, as a company, would like to encourage bigints
 as a sane reasonable default for primary keys for application models. If
 the Django project agrees with this idea, that would mean that Django would
 provide BigAutoField as the default for ‘id’ instead of AutoField.



 Rails made this change recently
 , and has seen
 success in doing so.



 I’m happy to provide the code to do this, but I wanted to discuss it
 here before doing so, to hear what the general consensus was to the
 proposal of such a change.





 Pros:

-

Users of Django, following the docs, won’t accidentally hit the int
overflow barrier.
-

Encourages best-practices from the beginning.
-

Bigints don’t take up much more storage than ints when using
Postgres.
-

In-line with other frameworks moving forward on this issue, like
Rails .



 Cons:

-

Backwards compatibility would need to be considered.


 Why not UUID?



 I agree! I love using UUID for my primary keys, and I think a patch to
 Django which provides an AutoUUIDField would be wonderful. However, there
 are a few major drawbacks to making this the new default:



1.

It’s confusing to new users, would make onboarding process more
difficult.
2.

   

Re: Value of tightening URLValidator/EmailValidator regular expressions?

[Collin Anderson]

Hi All,

There's a PR [0] to make validation match HTML. Though there's a question 
about what to do with domain_whitelist.

Here's the background:
- Originally Django didn't allow any dotless (non-FQDN) domain names.

- People wanted to use "localhost", but the SMTP spec said "Local nicknames 
or unqualified names MUST NOT be
   used." So domain_whitelist was added to allow more user-specified 
domains. https://code.djangoproject.com/ticket/4833

- We're proposing to change the behavior of email validation to allow a lot 
more email addresses including all dotless domains, so you don't need to 
specify specific domains to allow.

- Though maybe it still makes sense to deny dotless domain names.

I think the options currently are:
1 - Immediately remove domain_whitelist so people get a hard error. It's 
probably not used in third-party apps where multiple Django version support 
might be important.

2 - Deprecate domain_whitelist and ignore with a warning.

3 - Keep restricting dotless domains unless they are in domain_whitelist.

Collin

[0] https://github.com/django/django/pull/8081


On Tuesday, April 5, 2016 at 1:41:14 PM UTC-4, Tim Graham wrote:
>
> Any thoughts about whether or not to make similar simplifications to 
> URLValidator? There's an old ticket to add a DomainNameValidator [0] 
> which may or may not be worth moving forward with based on the decision.
>
> [0] https://code.djangoproject.com/ticket/18119
>
> On Saturday, April 2, 2016 at 3:05:14 AM UTC-4, Shai Berger wrote:
>>
>> On Saturday 02 April 2016 09:44:54 Josh Smeaton wrote: 
>> > For what reason Zach? 
>>
>> There is only one reason for which a strict and accurate validation is 
>> required, as far as I can see, and that is if your application is not 
>> just 
>> using existing email addresses (i.e. sending mail to users) but actually 
>> manages them (i.e. creates mail addresses). 
>>
>> Such applications are few and far between... 
>>
>> > Without a canonical regex implementation to copy or 
>> > include, we're stuck poorly reimplementing a bunch of esoteric rules to 
>> > what end? The main purpose of email validation is to provide relevant 
>> > feedback to the user, and to guard against obviously bad or malicious 
>> data. 
>> > "Looks vaguely like an email address" is probably too loose to be 
>> useful, I 
>> > admit. The proposal to copy the regex from the html5 email input widget 
>> > seems like a fine compromise to me. 
>> > 
>> > We should also err on the side of allowing incorrect addresses rather 
>> than 
>> > rejecting correct addresses. I'd much rather have bad signups that need 
>> to 
>> > be done again rather than users that can't sign up with their valid 
>> > addresses. 
>> > 
>>
>> ...and their needs should not imply a high burden of maintenance on the 
>> rest 
>> of the community; they can and should implement their own validation. 
>>
>> +1 everything Josh said. 
>>
>> Shai. 
>>
>

-- 
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/e6074d2a-b84f-41cb-bd77-842c63169f2f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [JOB POST] Django backend developer per Centre Comune di Ricerca - JRC

[Collin Anderson]

(Django-users is a better place for job postings:
https://groups.google.com/d/forum/django-users )

On Tue, May 23, 2017 at 5:17 PM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> Hello Jorge,
>
> Job postings are inappropriate on this mailing list.
>
> Thanks for your understanding,
>
> --
> Aymeric.
>
>
>
> On 23 May 2017, at 14:54, Jorge Lopez 
> wrote:
>
> We are looking for an experienced Python-Django developer, for a consulting 
> activity at the Joint Research Centre, Ispra site, in the area of Forest 
> management.
> If you are interested, please contact Mr. Matteo Villa - 
> matteo.vi...@finconsgroup.com
>
>
> --
> 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/09446035-2ffe-459f-8212-
> 5a51f02c2486%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/02F78E0F-F4F2-4247-B11F-
> 2CB19D52CAAE%40polytechnique.org
> 
> .
>
> 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/CAFO84S6%3D5zajsHxxC-jxpbe3t9C-iztH4WboWZgHT5zKwqV29A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Admin and CSS Custom Properties

[Collin Anderson]

I suggest supporting IE11+, as that's the latest on Windows 7 and there's
not much 9-10 usage. Now's probably a good time to bump them if needed
because we're just past an LTS.

Though, yes, it doesn't allow CSS variables.

On Fri, Apr 28, 2017 at 6:38 AM, Curtis Maloney  wrote:

> I recently discovered that the stated "policy" on browser support in Admin
> is... well... not clear at all.
>
> https://docs.djangoproject.com/en/1.11/faq/admin/#what-brows
> ers-are-supported-for-using-the-admin
>
> It claims to support full function for "YUI's A-Grade" browsers, but the
> link it provides does nothing to explain the supported versions, and a
> further "target environments matrix" link still lists IE6.
>
> So perhaps it's time to update the FAQ, and have a discussion on what
> Admin's browser support policy needs to be updated to.
>
> --
> Curtis
>
> On 28/04/17 19:14, Patrick Guido wrote:
>
>> On 27 April 2017 at 23:18, Adam Johnson > > wrote:
>>
>> Thanks for introducing me to a new CSS feature! I clearly don't keep
>> up with front end stuff enough.
>>
>> Re: your issues:
>>
>> 1. From the support grid at the bottom of the Smashing Magazine
>> article you linked, it looks like it's only IE 11 and Edge 14 that
>> are major browsers that don't support it. However I feel like if
>> Django is going to announce a feature like "you can override the
>> Admin colours", it should work in all browsers. I'm not sure if we
>> have a written policy for this though.
>>
>> I guess it also depends on use cases, usually (where I work) we tend to
>> support only latest browsers when it comes to admin, since
>> it will be used by only a few people :) But I see your point.
>>
>> A friend of mine was suggesting configuring colours in python, but this
>> means that the css would be rendered via python, which is
>> not ideal.
>> Another solution would be to add a JS polyfill to make it work on older
>> browsers, but I'm against it :)
>> Let's also keep in mind that this (if approved) will be included in
>> django 2.0 or later, so the browser support will be even better :)
>>
>>
>> 2. I'm not a huge fan of an additional HTTP request for every admin
>> page load, for every admin site in existence whether or not the
>> colours have been overridden. HTTP/2 isn't very widely deployed
>> still so requests still ain't cheap.
>>
>> Uhm, I think we can easily skip one request if the colours have not been
>> overridden. We can put the vars in base.css.
>> Then we can add the variables by changing the template (but that's more
>> cumbersome) either by adding an external css link
>> or by adding a style tag with the variables.
>>
>>
>> 3. This can be overcome with a test to ensure the two files are in
>> sync, I guess?
>>
>> Uhm, true!
>>
>>
>> And one more question: how much less painful is this to override the
>> colours compared to the variable-less way, where you just clone the
>> colour definitions of every rule in the original file in a second
>> override file?
>>
>> I haven't checked all the rules, but I think it will require quite a bit
>> of work. Maybe we can create a "template" file
>> that can be used to override quite easily the colours, but that doesn't
>> scale too well I think.
>>
>>
>> --
>> Patrick Guido Arminio
>>
>> --
>> 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/CAOUxZcu
>> gkWEnyx3wt7uXNYJE_Rgix-5N_iPwxMbZS73RA63%3DFw%40mail.gmail.com
>> > ugkWEnyx3wt7uXNYJE_Rgix-5N_iPwxMbZS73RA63%3DFw%40mail.
>> gmail.com?utm_medium=email&utm_source=footer>.
>> 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/ms
> gid/django-developers/db7742bc-769b-85fe-af87-c398fa99215d%40tinbrain.net.
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are 

Re: Django test suite taking > 2 hours, gets stuck, have to Ctrl-C

[Collin Anderson]

Hi Dylan,

Was there a traceback when you pressed ctrl+c? That might show where it's
getting stuck.

You could try using --parallel=1 to disable multi-process which might also
give you some more information.

(And does the test suite run fine without your patch? :)

I assume you're testing using the sqlite database?

Good luck,
Collin


On Sat, Apr 22, 2017 at 1:34 AM, 'Dylan Verheul' via Django developers
(Contributions to Django itself)  wrote:

> Hi, I am trying to contribute my first patch (see ticket 28105).
>
> I am following the instructions on https://docs.djangoproject.
> com/en/1.11/intro/contributing/, but the test suite just gets stuck after
> about 11K-12K tests (depending on version and python version).
>
> Example: Ran 11904 tests in 2963.657s (runtests, Python 2, after Ctrl-C)
>
>
> I have actually let the tests run overnight, but no result.
>
>
> I have tried both runtests and tox, Python 2 and Python 3, master branch
> and stable/1.11.x.
>
>
> My patch and tests are about done, but I am really stuck trying to get the
> test suite to work properly.
>
>
> My hardware is a new MacBook Pro with several Django and Python projects
> running on it (including tests). I use pyenv and brew to manage my python
> environments.
>
>
> Any help in getting the test suite to run would be greatly appreciated.
>
>
> Thanks.
>
>
> Dylan
>
> --
> 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/907c23ac-2086-41ce-b2cb-
> 4ca171ff4247%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/CAFO84S66xUis_XqxRy-iWoz%2Bp9Lcidtu991qnuC36Lca_61GoQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: A New Design for the "Congratulations!" Page

[Collin Anderson]

I was also reminded of green color the green color discussion.

>From the discussion about the admin redesign [0][1]:
"makes keeping a visual identity for Django hard to separate from the admin
UI"
"the admin is part of _your_ site, not ours, and so should have a
visually-distinct theme/brand that can enforce the user's theme, not ours."

I think the green might be less of an issue for this page, as end users
shouldn't see it, and really it might make sense to keep the Django brand
here, as that's what the page is all about.

[0] https://github.com/django/django/pull/4232
[1]
https://groups.google.com/d/topic/django-developers/HJAikaEBqJ4/discussion



On Tue, Apr 18, 2017 at 3:18 PM, Ryan Hiebert  wrote:

>
>
> On Tue, Apr 18, 2017 at 11:27 AM Daniele Procida  wrote:
>
>> On Tue, Apr 18, 2017, Tim Allen  wrote:
>>
>> >It struck me that this page is valuable real estate
>>
>> Yes it is! Firstly, I think that both your idea and design are excellent
>> and I approve.
>>
>> Secondly, since that space is valuable, perhaps it could also say:
>>
>> This release of Django has been sponsored by . 
>>
>> Django is free open-source software. Support Django's development
>> 
>>
>> The more I think about this, the less I think it's a bad idea...
>>
>
> Finding funding for open source is notoriously difficult, and if this can
> turn out to be a net benefit for the project, I think this is a really neat
> way to do it. Good thinking, Daniele.
>
> One comment on the design, though, that might be worth considering. The
> admin redesign that happen a few releases back originally chose to use
> similar styling to djangoproject.com, but it was decided that it would be
> better to keep it a blue theme instead, so that they were visually
> distinctive. I think that reasoning also applies here, to keep this initial
> page distinctive from the pages that are actually hosted on
> djangoproject.com.
>
> Overall, I love the idea, thanks for putting the work in.
>
> --
> 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/CABpHFHSRnbUpQz3Q7E1ivZC%2BfK82gW2%
> 3DcpKQerapSrXddPkveA%40mail.gmail.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/CAFO84S7CGJN4GL%2BH8mJcLo6NP%3Ditb-OicKRdkfP6NDExN0ngjw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: A New Design for the "Congratulations!" Page

[Collin Anderson]

Beautiful.

The Google Font should not be an issue. We're already distributing that as
part of the admin, which is installed by default. The page could just
reference /static/admin/css/fonts.css.

Does a license need to be included for the rocket animation, or is that
your own work?

I hope the links could be auto-generated so they don't need to be
hand-updated with every version.

I think the unused css should be removed. We're not
using button,input,optgroup,select,textarea, etc.



On Tue, Apr 18, 2017 at 12:03 PM, Tim Allen 
wrote:

> Switching to another font is certainly an option. Is the issue with Google
> Fonts the Apache license versus the Django BSD license?
>
> --
> 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/c635d1e2-45e5-4b31-8ae2-
> f6acb00f943f%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/CAFO84S6bSKaWgyrCV7AWTLBKe%3DkfF%2Bm2j91FwiYKLXPFwGQd9A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: make Model __unicode__() default to self.name

[Collin Anderson]

I just made a pull request.
https://github.com/django/django/pull/8336

(1) is my first choice, pk=1 is my second choice. I'd be fine with either.

On Sat, Apr 8, 2017 at 12:08 PM, Marco Silva 
wrote:

> just saw that __repr__ is now under discusion here
> https://groups.google.com/forum/#!topic/django-developers/UNKFMg6DO5s
>
>
> sábado, 8 de Abril de 2017 às 17:06:05 UTC+1, Marco Silva escreveu:
>>
>> I have no idea what is the best way, just say that comment. this is the
>> original PR
>> https://github.com/django/django/commit/d2a26c1a90e83dab
>> df3d67ceec4d2a70fb86
>>
>> I think you should submit the PR to change the __str__ method, and maybe
>> open a new discussion regarding __repr__
>>
>> sexta-feira, 7 de Abril de 2017 às 15:34:32 UTC+1, Kapil Garg escreveu:
>>>
>>> The opened ticket is about Model.__str__ method. Should i open a new
>>> ticket for this change ?
>>> As i see in code, self.__class__ is used in a lot of places but will it
>>> effect optimization if we change lookups from self.__class__ to self.cls
>>>
>>> Because the methods where class is being used frequently, already store
>>> it in local variable and then make references to local variable.
>>>
>>> So should it really be changed ?
>>>
>>> On Fri, Apr 7, 2017, 6:52 PM Marco Silva  wrote:
>>>
>>>> I noticed this on the init
>>>>
>>>> def __init__(self, *args, **kwargs):
>>>>  # Alias some things as locals to avoid repeat global lookups
>>>>  cls = self.__class__
>>>>
>>>> maybe you should change it to self.cls??
>>>> Try to submit a PR to the open ticket.
>>>>
>>>> segunda-feira, 3 de Abril de 2017 às 21:07:47 UTC+1, Kapil Garg
>>>> escreveu:
>>>>>
>>>>> So does this patch seem fine ?
>>>>>
>>>>> diff --git a/django/db/models/base.py b/django/db/models/base.py
>>>>> index 3c1cb9a..f58e12b 100644
>>>>> --- a/django/db/models/base.py
>>>>> +++ b/django/db/models/base.py
>>>>> @@ -504,7 +504,7 @@ class Model(metaclass=ModelBase):
>>>>>  return '<%s: %s>' % (self.__class__.__name__, u)
>>>>>
>>>>>  def __str__(self):
>>>>> -return '%s object' % self.__class__.__name__
>>>>> +return '%s object pk=%s' % (self.__class__.__name__,
>>>>> self._get_pk_val())
>>>>>
>>>>>  def __eq__(self, other):
>>>>>  if not isinstance(other, Model):
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Monday, 3 April 2017 23:07:56 UTC+5:30, Collin Anderson wrote:
>>>>>>
>>>>>> I'd recommend not saying "unsaved". "new" if anything. UUID pk's may
>>>>>> default to generating a pk before save, so it might just be best to show
>>>>>> the actual current pk value
>>>>>>
>>>>>> On Mon, Apr 3, 2017 at 1:06 PM, Kapil Garg 
>>>>>> wrote:
>>>>>>
>>>>>>> So what should the final __str__ show: Should it be 'ClassName
>>>>>>> object pk=Something' and if pk is None then should it be 'ClassName 
>>>>>>> object
>>>>>>> (unsaved)' or 'ClassName object pk=None' ?
>>>>>>>
>>>>>>> On Sunday, 2 April 2017 23:47:01 UTC+5:30, Collin Anderson wrote:
>>>>>>>>
>>>>>>>> Makes sense to me. Maybe still keep the "Transaction object" part,
>>>>>>>> and use None if no pk.
>>>>>>>>
>>>>>>>> On Sun, Apr 2, 2017 at 11:09 AM, Kapil Garg 
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Ticket 27953 <https://code.djangoproject.com/ticket/27953> is
>>>>>>>>> regarding this proposal and the suggestion is about adding "pk" in 
>>>>>>>>> Model
>>>>>>>>> string representation if it exists.
>>>>>>>>>
>>>>>>>>> On Thursday, 11 July 2013 09:16:25 UTC+5:30, Collin Anderson wrote:
>>>>>>>>>>
>>>>>>>>>> Hi All,
>>>>>>>>>>
>>>>>>>

Re: Proposal: make Model __unicode__() default to self.name

[Collin Anderson]

Hi All,

Looking at the code snippet, cls is a _local_ variable, not an instance
attribute (self.cls). If we changed it to an instance attribute, it would
lose most of the speed optimization. Also, self.cls would possibly clash
with a field named "cls".

Collin


On Fri, Apr 7, 2017 at 10:33 AM, Kapil Garg  wrote:

> The opened ticket is about Model.__str__ method. Should i open a new
> ticket for this change ?
> As i see in code, self.__class__ is used in a lot of places but will it
> effect optimization if we change lookups from self.__class__ to self.cls
>
> Because the methods where class is being used frequently, already store it
> in local variable and then make references to local variable.
>
> So should it really be changed ?
>
> On Fri, Apr 7, 2017, 6:52 PM Marco Silva  wrote:
>
>> I noticed this on the init
>>
>> def __init__(self, *args, **kwargs):
>>  # Alias some things as locals to avoid repeat global lookups
>>  cls = self.__class__
>>
>> maybe you should change it to self.cls??
>> Try to submit a PR to the open ticket.
>>
>> segunda-feira, 3 de Abril de 2017 às 21:07:47 UTC+1, Kapil Garg escreveu:
>>
>> So does this patch seem fine ?
>>
>> diff --git a/django/db/models/base.py b/django/db/models/base.py
>> index 3c1cb9a..f58e12b 100644
>> --- a/django/db/models/base.py
>> +++ b/django/db/models/base.py
>> @@ -504,7 +504,7 @@ class Model(metaclass=ModelBase):
>>  return '<%s: %s>' % (self.__class__.__name__, u)
>>
>>  def __str__(self):
>> -return '%s object' % self.__class__.__name__
>> +return '%s object pk=%s' % (self.__class__.__name__,
>> self._get_pk_val())
>>
>>  def __eq__(self, other):
>>  if not isinstance(other, Model):
>>
>>
>>
>>
>> On Monday, 3 April 2017 23:07:56 UTC+5:30, Collin Anderson wrote:
>>
>> I'd recommend not saying "unsaved". "new" if anything. UUID pk's may
>> default to generating a pk before save, so it might just be best to show
>> the actual current pk value
>>
>> On Mon, Apr 3, 2017 at 1:06 PM, Kapil Garg  wrote:
>>
>> So what should the final __str__ show: Should it be 'ClassName object
>> pk=Something' and if pk is None then should it be 'ClassName object
>> (unsaved)' or 'ClassName object pk=None' ?
>>
>> On Sunday, 2 April 2017 23:47:01 UTC+5:30, Collin Anderson wrote:
>>
>> Makes sense to me. Maybe still keep the "Transaction object" part, and
>> use None if no pk.
>>
>> On Sun, Apr 2, 2017 at 11:09 AM, Kapil Garg  wrote:
>>
>> Ticket 27953 <https://code.djangoproject.com/ticket/27953> is regarding
>> this proposal and the suggestion is about adding "pk" in Model string
>> representation if it exists.
>>
>> On Thursday, 11 July 2013 09:16:25 UTC+5:30, Collin Anderson wrote:
>>
>> Hi All,
>>
>> Have you ever quickly set up a model, ran syncdb, and added a few sample
>> objects in the admin to only see a bunch of "MyModel object"s in the
>> changelist? I always forget to add a __unicode__()/__str__() method on my
>> models.
>>
>> I ran "git grep -1 __unicode__" on some of my django projects and noticed
>> a lot of repeated code. In fact, it seems that in about a _third_ of all my
>> cases, I'm just returning self.name, or returning self.name would have
>> been a good default. I looked at a few 3rd party apps for comparison and
>> found similar results, though not for every app.
>>
>> IMHO, returning self.name (if the field or property exists) is a
>> sensible default for __unicode__. We can still return "MyModel object" if
>> there's no "name" attribute. You'll still end up adding your own
>> __unicode__ method much of the time, just like you always have.
>>
>> Yes, it's "magic", but we can document it.
>> Yes, it's a little more confusing, but we don't have to explain it during
>> the tutorial.
>> Yes, it's backwards incompatible, but only in rare cases should it be a
>> problem.
>> Yes, it could look like any Model without a "name" field is "wrong", but
>> it's not.
>> Yes, "title" is also very popular, but name is better. :)
>>
>> It has the effect of being a little more friendly in many cases, and can
>> result in more DRY code.
>>
>> What do your __unicode__/__str__ methods look like? Is this a bad idea?
>&g

Re: Proposal: make Model __unicode__() default to self.name

[Collin Anderson]

I'd recommend not saying "unsaved". "new" if anything. UUID pk's may
default to generating a pk before save, so it might just be best to show
the actual current pk value

On Mon, Apr 3, 2017 at 1:06 PM, Kapil Garg  wrote:

> So what should the final __str__ show: Should it be 'ClassName object
> pk=Something' and if pk is None then should it be 'ClassName object
> (unsaved)' or 'ClassName object pk=None' ?
>
> On Sunday, 2 April 2017 23:47:01 UTC+5:30, Collin Anderson wrote:
>>
>> Makes sense to me. Maybe still keep the "Transaction object" part, and
>> use None if no pk.
>>
>> On Sun, Apr 2, 2017 at 11:09 AM, Kapil Garg  wrote:
>>
>>> Ticket 27953 <https://code.djangoproject.com/ticket/27953> is regarding
>>> this proposal and the suggestion is about adding "pk" in Model string
>>> representation if it exists.
>>>
>>> On Thursday, 11 July 2013 09:16:25 UTC+5:30, Collin Anderson wrote:
>>>>
>>>> Hi All,
>>>>
>>>> Have you ever quickly set up a model, ran syncdb, and added a few
>>>> sample objects in the admin to only see a bunch of "MyModel object"s in the
>>>> changelist? I always forget to add a __unicode__()/__str__() method on my
>>>> models.
>>>>
>>>> I ran "git grep -1 __unicode__" on some of my django projects and
>>>> noticed a lot of repeated code. In fact, it seems that in about a _third_
>>>> of all my cases, I'm just returning self.name, or returning self.name
>>>> would have been a good default. I looked at a few 3rd party apps for
>>>> comparison and found similar results, though not for every app.
>>>>
>>>> IMHO, returning self.name (if the field or property exists) is a
>>>> sensible default for __unicode__. We can still return "MyModel object" if
>>>> there's no "name" attribute. You'll still end up adding your own
>>>> __unicode__ method much of the time, just like you always have.
>>>>
>>>> Yes, it's "magic", but we can document it.
>>>> Yes, it's a little more confusing, but we don't have to explain it
>>>> during the tutorial.
>>>> Yes, it's backwards incompatible, but only in rare cases should it be a
>>>> problem.
>>>> Yes, it could look like any Model without a "name" field is "wrong",
>>>> but it's not.
>>>> Yes, "title" is also very popular, but name is better. :)
>>>>
>>>> It has the effect of being a little more friendly in many cases, and
>>>> can result in more DRY code.
>>>>
>>>> What do your __unicode__/__str__ methods look like? Is this a bad idea?
>>>>
>>>> Thanks,
>>>> Collin
>>>>
>>>> --
>>> 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/ms
>>> gid/django-developers/c7254a96-7ee3-4262-a90b-83dcfe8fa3d4%
>>> 40googlegroups.com
>>> <https://groups.google.com/d/msgid/django-developers/c7254a96-7ee3-4262-a90b-83dcfe8fa3d4%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>> 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/1a84fb1c-522f-4bc4-b214-
> 0831a63f13ae%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/1a84fb1c-522f-4bc4-b214-0831a63f13ae%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> 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/CAFO84S76_%3DB_7kuLj0DbXZ%2BZw78J7nGWdKnGM57qFtEVDb4BfA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: make Model __unicode__() default to self.name

[Collin Anderson]

Makes sense to me. Maybe still keep the "Transaction object" part, and use
None if no pk.

On Sun, Apr 2, 2017 at 11:09 AM, Kapil Garg  wrote:

> Ticket 27953 <https://code.djangoproject.com/ticket/27953> is regarding
> this proposal and the suggestion is about adding "pk" in Model string
> representation if it exists.
>
> On Thursday, 11 July 2013 09:16:25 UTC+5:30, Collin Anderson wrote:
>>
>> Hi All,
>>
>> Have you ever quickly set up a model, ran syncdb, and added a few sample
>> objects in the admin to only see a bunch of "MyModel object"s in the
>> changelist? I always forget to add a __unicode__()/__str__() method on my
>> models.
>>
>> I ran "git grep -1 __unicode__" on some of my django projects and noticed
>> a lot of repeated code. In fact, it seems that in about a _third_ of all my
>> cases, I'm just returning self.name, or returning self.name would have
>> been a good default. I looked at a few 3rd party apps for comparison and
>> found similar results, though not for every app.
>>
>> IMHO, returning self.name (if the field or property exists) is a
>> sensible default for __unicode__. We can still return "MyModel object" if
>> there's no "name" attribute. You'll still end up adding your own
>> __unicode__ method much of the time, just like you always have.
>>
>> Yes, it's "magic", but we can document it.
>> Yes, it's a little more confusing, but we don't have to explain it during
>> the tutorial.
>> Yes, it's backwards incompatible, but only in rare cases should it be a
>> problem.
>> Yes, it could look like any Model without a "name" field is "wrong", but
>> it's not.
>> Yes, "title" is also very popular, but name is better. :)
>>
>> It has the effect of being a little more friendly in many cases, and can
>> result in more DRY code.
>>
>> What do your __unicode__/__str__ methods look like? Is this a bad idea?
>>
>> Thanks,
>> Collin
>>
>> --
> 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/c7254a96-7ee3-4262-a90b-
> 83dcfe8fa3d4%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/c7254a96-7ee3-4262-a90b-83dcfe8fa3d4%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> 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/CAFO84S46Vg_A%3Dab0GSo%3D4RkmUK85%3D%2BcNb8C6WMDB%2BcpZrt9XVA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Add better support for ManyToMany with intermediary table fields, and reverse relationships, specially in forms

[Collin Anderson]

Hi Gabriel,

Yes, the hope is to make the situation better and more standard. Here's
some of the status:
https://code.djangoproject.com/ticket/24317 - real reverse fields.
https://code.djangoproject.com/ticket/897 - real reverse many to many fields
https://code.djangoproject.com/ticket/12203 - many to many with through
tables

Also, filtering fields on the .multiple attribute might help you out. Not
sure though. If it isn't, maybe open a pull request with a proposal for an
attribute that would work for you?

Quoting the advice from the first ticket:
- Find places where field.remote_field responds to different API than Field.
- Fix these one at a time while trying to have backwards compat, even if
the API isn't public.
- In addition, simplifications to the APIs are welcome, as is a high level
documentation of how related fields actually work.
- We need to try to keep backwards compat as many projects are forced to
use the private APIs.
- But most of all, do small incremental changes.

As far as your specific use-case goes, "a widget that is a table with
inputs for cells". The closest thing Django has is an "inline formset"
(though not actually a form field) which is designed exactly for reverse
relationships. You would say:

ThroughFormSet = inlineformset_factory(MainModel, ThroughModel)

https://docs.djangoproject.com/en/1.11/topics/forms/modelforms/#inline-formsets
(Or in the admin, you just use an inline which uses an inlineformset under
the hood.)

Collin


On Thu, Mar 30, 2017 at 3:30 PM, Gabriel Canto  wrote:

> When you are creating a system from scratch, coming with a ideal and
> organized model is simple enough, but when you are trying to replicate a
> real world system/issue into your models, things get complicated.
>
> By complicated I mean, almost every relationship is a M2M with
> intermediary fields, that's the issue I'm trying to solve using Django,
> real world documents, contracts, people.
>
> The main concern is making the CRUD web app easy for the user eyes.
>
> Django really made things difficult, specially because in our context the
> relationship direction doesn't matter, we want both forward and reverse
> fields when editing an object
>
>
> *First suggestion: give reverse relationships a common attribute for an
> easier way of getting them*
>
> This is the code I had to make to get only reverse relationships of a
> model, it is very ugly and not my proudest work, but it works(so far)
>
>  #I'm sure there's a better way of doing this
>  #This is the documented way of getting reverse fields, but it also gets
> ManyToOne rel with the through table of forward m2m rels, so we have to
> filter them
>  reverse_fields = [f for f in opts.get_fields() if f.auto_created and not
> f.concrete]
>  reverse_m2m = [f for f in reverse_fields if f.__class__.__name__ ==
> 'ManyToManyRel' and f.on_delete == None and not getattr(model,f.field.name
> ,False)]
>  #Also filtering the ManyToOne rel with the through table of the reverse
> m2m rels, because we need to differentiate them from reverse ManyToOne with
> other models(not through)
>  reverse_m2m_through = [f for f in reverse_fields if f.__class__.__name__
> == 'ManyToOneRel'  and f.related_model in [f.through for f in reverse_m2m
> if getattr(f,'through',False)]]
>  forward_m2m = [f.remote_field for f in opts.get_fields() if not 
> f.auto_created
> and f.many_to_many]
>  #Filtering the ManyToOne rels with the through table of forwards m2m
> rels, same logic as above
>  forward_m2m_through = [f for f in reverse_fields if f.__class__.__name__
> == 'ManyToOneRel'  and f.related_model in [f.through for f in forward_m2m
> if getattr(f,'through',False)]]
>  reverse_fields_final = itertools.chain(reverse_m2m, [f for f in
> reverse_fields if f not in itertools.chain(reverse_m2m,
> reverse_m2m_through, forward_m2m, forward_m2m_through)])
>
> *Second suggestion: following the first suggestion, give support to edit
> reverse rels in forms, and m2m with through tables*
>
> An optional argument to ModelForm to also catch reverse relationships,
> using a specific form field for it, example : ReverseModelChoiceField,
> etc..., this can be done with just a simple changes to their forward
> counterpart classes
>
> And, the most complex suggestion probably, is to add a form field to deal
> with M2M with through tables that contain intermediary fields, this can be
> done with a widget that is a table with inputs for cells, plus also work
> with reverse as suggested above, so I'm suggesting the creation of the 5
> following model form fields :
>
>
>1. ReverseModelChoiceField
>2. ReverseMultipleModelChoiceField
>3. ReverseManyToManyWithIntermediaryField (I'm sure there's a better
>name)
>4. ManyToManyWithIntermediaryField
>
> --
> 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 dj

Re: Deprecate is_superuser, is_staff and is_active

[Collin Anderson]

Hi Thomas,

"If the user should have all permissions, then why not give him all these
permissions at database level?" - I have some use cases where there are
only 3-5 people that need to log into the admin. I don't really need to set
different levels of access for different people. I also don't want to have
to go through and add new permissions to every person every time I add a
model. So, I just mark them all as is_superuser and don't use permissions
at all. It keeps things simple.

Something like this might handle your situation:
class MyUser:
# etc
is_superuser = False
is_staff = property(lambda u: u.has_perm('admin'))

Collin

On Fri, Mar 24, 2017 at 8:55 AM, guettli 
wrote:

>
>
> Am Freitag, 24. März 2017 12:42:03 UTC+1 schrieb Andrew Ingram:
>>
>> I've always felt that `is_staff` should be changed to a permission such
>> as `can_access_admin` provided by the Admin app itself.
>>
>
>
>
>> However, `is_superuser` is slightly different, in that it's not a
>> permission, but rather a flag that says "this user has EVERY permission".
>> It's also potentially nonsensical from a functional perspective, you could
>> have two permissions that are intended to be mutually exclusive, but a
>> superuser would nonetheless have both of them - potentially resulting in a
>> broken/nonsense UI.
>>
>
> Thank you for this easy to understand use case. I ask myself if "this user
> has EVERY permission" is needed at all. If the user should have all
> permissions, then why not give
> him all these permissions at database level? It's like a very special 1:N
> relation which is: 1:∞  :-)
>
>
>
>
>
>> This is the main reason why almost nobody should be a superuser (yet
>> nearly every Django project i've inherited has nearly every member of staff
>> marked as superusers).
>>
>>
> Unfortunately we detected this "best practice" too late. We need to switch
> now, but this not related to django-dev, this needs to be solved in our
> company.
>
>
>
>> `is_active` is intended to be used a little differently isn't it? It's
>> not saying "user has no permissions", it's saying "user is disabled". It's
>> not access-control, it's data.
>>
>>
> Let's look at our use case: I want a queryset of all users which have a
> given permission. Do I want to be
> inactive users in this queryset?  I am unsure. But I am sure: I want this
> queryset to be simple at SQL level.
>
>
>
>> I think that most of it could do with a rethink, but `is_staff` is
>> probably the biggest wart.
>>
>> Andy
>>
>>
>>
>
> Thanky you Andy
>
> Regards,
>   Thomas
>
> --
> 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/66dc2010-eca4-409f-9dea-
> f1a4f5aa8217%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/CAFO84S5fJaGgDZpXQLpKd2B9jZCfxBvEqKbjnqWceOf0w1q5hQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: I would like to discuss my proposal for a working way to call .add() on an m2m with through= model

[Collin Anderson]

Hi,

Check out https://code.djangoproject.com/ticket/9475

Seems like it would be fine if Django allowed add() and let any errors
about missing data bubble-up. I personally think passing in a defaults dict
(just like get_or_create does) would also be fine, but a callback seems
like overkill.

Here's a proof of concept:
https://github.com/django/django/compare/master...collinanderson:ticket9475

Collin


On Mon, Mar 20, 2017 at 5:46 PM, Luis Masuelli 
wrote:

> I was reading this link in the official history
>  and this other
> link in this group
> ,
> but still do not understand why the issue against a way to call .add() to
> add a through model. I thought several approaches (they are all backward
> compatible for the end-user) that could work:
>
>1. Avoid the restriction to call add() if the model has only the two
>FK fields.
>2. An additional way to call .add() specifying additional fields to
>fill (this one is not mine; was discussed in the linked thread). You risk
>getting a (wrapped?) exception if you do not populate other fields
>appropriately.
>3. (This one was the first I thought and perhaps the easiest to
>implement) Allow the ManyToManyField to specify a kwarg like
>`through_factory=` which expects a callable which would populate more data.
>The restriction to call .add() would remain if no `through_factory=` is
>specified.
>4. Avoid the restriction to call delete() if the model has only the
>two FK fields.
>
> I considered these cases:
>
>- It is quite trivial a model with only two fields, but perhaps the
>intermediate models could have additional useful methods. I see no trouble
>having such model and allowing .add() or .delete() calls there.
>- Having a special factory method would allow calls to .add() since
>we'd be providing a way to make .add() actually know how to create an
>instance of the intermediate model.
>- You can combine these points, implement one, none, or all of them.
>- (I did not consider extended use cases for delete() intentionally,
>since perhaps a strange model (with different field pairs) could fit in
>different relationships, although I cannot think in a case with multiple
>relationships not incurrin in, perhaps, duplicate data when tried to be
>used as through= model, but anyway I prefer to keep silence for other cases
>involving delete(), but the case I stated).
>- It is up to the user to be careful regarding migrating an
>intermediate model regarding adding, changing, or deleting fields. But
>anyway, this applies to any modification in the database models right now.
>- Points 1, 2, 3 and/or 4 could be implemented with no clash. A
>combined approach of 1, 2, 3 would look like this (this flow only applies
>for the case when the through= is present - such scenario right now only
>consists of raising an exception; the case with no through= model would not
>be affected at all):
>   - Instantiate `instance = ThroughModel(fka=a, fkb=b,
>   **kwargs_from_add)` with the respective model instances a and b, from
>   classes A and B which hold the desired M2M relationship. In this case, 
> the
>   point 2 just adds the **kwargs_from_add. If point 2 is not implemented, 
> no
>   **kwargs_from_add would be present.
>   - (*If point 3 is implemented*) Call the callable in
>   `through_factory=` invoking it `like_this(instance)`, if the callable is
>   present. It is expected to save the instance.
>   - (*If either point 1 is implemented and the model has only two
>   fields, or point 2 is implemented*) Manually save the instance (if
>   point 3 was not implemented or it was but the factory callable was not
>   specified). (*Otherwise - point 2 not implemented AND (point 1 not
>   implemented or model with more than two fields*)) Raise the
>   currently implemented exception for the .add() method with through=
>   specified (with a different string message) because the through_factory 
> was
>   not present, and so the framework does not know how to populate 
> additional
>   fields.
>   - Catch-and-reraise (or don't catch at all and let them be) the
>   error for missing data in the tried-to-save model.
>- An example of the callable in point 3 would be like this (just an
>example for, say, a game!):
>   - def on_added(through_model_instance):
>   through_model_instance.balance = 1000.0 #although this one
>   could be a default value at db level.
>   through_model_instance.save()
>   through_model_instance.achievements.create(tag='joined-this-
>   relation')
>
> I understand these approaches, combined or not, could not be perfect or
> bug-free. But I'd like to discuss them instead of plainly discard them.
> 

Re: Provide forms field/widget type information for use in templates

[Collin Anderson]

Hi,

If it helps It looks like there's a widget.input_type attribute, so you can
at least do {% if theform.thefield.field.widget.input_type == "checkbox" %}
etc.

Collin


On Mon, Mar 20, 2017 at 9:46 AM, Paweł Adamczak  wrote:

> Hiya,
>
> I would like to 'resurrect' ticket #13009
> , or at least discuss it.
>
> I think that the suggested feature would be beneficial, as it comes up
> every time I'm implementing HTML flats different types of fields require
> different rendering (the most common example being checkboxes, where the
> input field is before the label). Adding an easy, builtin method of
> checking the field type/widget would be much nicer in my opinion then using
> then using  - just for example - this approach
> .
>
> That question also comes up in couple of StackOverflow questions:
> - http://stackoverflow.com/questions/3927018/django-how-
> to-check-if-field-widget-is-checkbox-in-the-template (viewed 7594 times)
> - http://stackoverflow.com/questions/1809874/get-type-of-
> django-form-widget-from-within-template (viewed 15015 times)
> - http://stackoverflow.com/questions/20424375/django-
> templates-how-to-know-form-field-type-and-add-any-buttons-based-on-field
> (viewed 3633 times)
>
> From the ticket:
>
>> Broadly the idea has merit, but it needs a bit of finesse - specifically,
>> what determines the "type" of the field? Do we just use the type of the
>> input element on the widget? What do we do in the case of multi-widgets?
>
>
> As far as I understand Django tries to structure its widget structure
> based
> on the HTML spec , and
> I would follow that convention as close as possible, with widget 'types'
> (the nomenclature would probably need to be different) like 'input_text',
> 'input_email', ..., 'input_radio', 'input_checkbox', and 'select'. In other
> cases we would just mimic the widget name ('multi_widget').
>
> What do you think?
> I would be happy to contribute to Django and implement the above in a
> feature pull request.
>
> --
> 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/02725db5-3873-4651-9f2e-
> 01c7b2af9f85%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/CAFO84S4wndx1sKYf9hnQsytCZeLgjGBeJZJM94xr-SJazZx-4Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Add ability to choose a different secret for PasswordResetToken

[Collin Anderson]

"the self-service site is basically a small subset of our internal site. So
if somebody would gain access to our interal site, he/she would already
have access to a superset of data of the other site. So there is really no
point to also take over to the other site."

Just curious: why not just use the same SECRET_KEY for both sites?

On Sat, Mar 18, 2017 at 6:11 AM, jann.haber via Django developers
(Contributions to Django itself)  wrote:

> Thank you for your input. Yes I meant the PasswordResetTokenGenerator,
> sorry for this.
>
> It agree, it would be a fairly small addition to Django, however there
> doesn't seem to be an easy (non-hackish) way to get around. Since the
> impact on Django would be very small, I wanted to share my thoughts here.
> In our scenario, the self-service site is basically a small subset of our
> internal site. So if somebody would gain access to our interal site, he/she
> would already have access to a superset of data of the other site. So there
> is really no point to also take over to the other site.
>
> I'll give the override_settings a closer look, but this seems like
> something one wouldn't want in a production environment.
>
> Am Samstag, 18. März 2017 10:32:06 UTC+1 schrieb Adam Johnson:
>>
>> Presumably you mean PasswordResetTokenGenerator when you write
>> PasswordResetToken.
>>
>> Seems like a fairly small feature, but my security sense is tingling when
>> you say you're putting the secret key of one application in a variable for
>> another.
>>
>> Normally in a situation where multiple applications need to share login
>> data, I would consider having a centralized application for identity
>> management.
>>
>> Also in your current structure, you don't necessarily need to replace
>> _make_token_with_timestamp (which is prone to break if Django changes
>> that code) - you could (somewhat hackily) wrap with override_settings(SE
>> CRET_KEY=other_key) around your call to PasswordResetTokenGenerator
>> .make_token.
>>
>> On 17 March 2017 at 20:54, jann.haber via Django developers
>> (Contributions to Django itself)  wrote:
>>
>>> Hi everybody,
>>>
>>> I have two sites in my project. One is for internal use to add members
>>> of our club to our database, one is a self-service page for our members.
>>> On registration of a member using our internal site, I want to send a
>>> password reset link to the member for easy registration to our self-service
>>> page.
>>> Since the two sites run on different servers and different SECRET_KEYs,
>>> I need to specify a different secret for the token generated with our
>>> internal site to work on the self-service page.
>>> I managed to do so by overwriting the method _make_token_with_timestamp
>>> of PasswordResetToken, however, I think this is quite an ugly solution.
>>>
>>> How would you think about the secret being an attribute of the
>>> PasswordResetToken class, which is then passed to salted_hmac? The default
>>> could be settings.SECRET_KEY for backwards compatibility.
>>>
>>> I have so far not contributed to django, but I would like to start and I
>>> believe, this small change might be a good start. If you agree, I could
>>> open a ticket in trac.
>>>
>>> Best Regards,
>>> Jann
>>>
>>> --
>>> 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/ms
>>> gid/django-developers/ca9e1cde-002d-491b-899a-02bfd50fbed6%
>>> 40googlegroups.com
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Adam
>>
> --
> 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/4e1c275f-1ea5-482d-affa-
> e70b95ffac24%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 u

Re: Removing and renaming Django's Python 2 related helpers

[Collin Anderson]

Hi All,

django.utils.six _is_ documented, so I think it should go through the
normal deprecation timeline.

https://docs.djangoproject.com/en/1.11/topics/python3/#writing-compatible-code-with-six

Seems fine to me to start the deprecation in 2.0, but I'm sure people would
appreciate starting the timeline later.

Collin


On Wed, Jan 25, 2017 at 2:34 PM, Tim Graham  wrote:

> A difference is that a deprecation starting in 2.2 is in 2 releases (2.2,
> 2.3) while the deprecation starting in 3.0 is in 3 releases (3.0, 3.1, 3.2).
>
> On Wednesday, January 25, 2017 at 10:30:40 AM UTC-5, Aymeric Augustin
> wrote:
>>
>> Hello Tim,
>>
>> On 25 Jan 2017, at 16:11, Tim Graham  wrote:
>>
>> - in Django 2.2 for removal in Django 3.1 (August 2020)
>> - in Django 3.0 for removal in Django 4.0 (Dec. 2021)
>>
>>
>> Either option seems fine to me.
>>
>> Are there advantages to starting the deprecation in a LTS (2.2) vs. in
>> the release that follows a LTS (3.0)?
>>
>> --
>> 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/75ba8da6-dac2-4b3f-bf7a-
> b64c0732693e%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/CAFO84S7Of17Sknf0caRasOKbzsP6rX2ZS820bm3ApgnET5By7g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Responsive admin

[Collin Anderson]

I think for the admin fonts, we put those in a separate css file:
fonts.css, so you could easily disable them by replacing that file with a
blank file. We could probably do the same thing with a responsive.css file.

(Though if we do give the option to switch, do we now need to support and
test every change for both cases? or maybe from now on we only touch
responsive.css?)

Collin

On Mon, Jan 9, 2017 at 8:26 AM, Marc Tamlyn  wrote:

> I'd suggest including this with a mechanism (on the admin site?) to
> disable it for a while if that causes problems for existing custom setups?
>
> Marc
>
> On 9 January 2017 at 11:59, Adam Johnson  wrote:
>
>> - perhaps supplying an empty CSS file with the same name overrides the
>>> file provided by the admin? (I’m not sure)
>>
>>
>> It does, as long as the app it's in is before django.contrib.admin in
>> INSTALLED_APPS, django-grappelli
>>  uses this mechanism
>> to extend/replace the admin's javascript and styles.
>>
>> I'm totally +1 for the responsive CSS too, thanks for your work on
>> django-flat-theme!
>>
>> On 9 January 2017 at 11:50, Aymeric Augustin <
>> aymeric.augus...@polytechnique.org> wrote:
>>
>>> Hello Elky,
>>>
>>> I’d love to see this responsive design merged in Django. I’m using the
>>> admin from my phone quite often and the lack of a responsive design makes
>>> that painful.
>>>
>>> The admin gets very few CSS changes. I don’t think we should refrain
>>> from adding a useful responsive design out of fear that it will be hard to
>>> maintain.
>>>
>>> An opt-out mechanisms for third-party apps that don’t want the
>>> responsive styles will a nice touch (but not absolutely necessary in my
>>> opinion). I don’t think a setting is appropriate. I’d rather use the
>>> template or static file overriding mechanisms, for example:
>>> - perhaps supplying an empty CSS file with the same name overrides the
>>> file provided by the admin? (I’m not sure)
>>> - alternatively responsive styles could apply only within
>>> body.responsive; the admin’s template would have a >> class=“responsive”>; third party apps could override that template and
>>> remove the class
>>>
>>> Thanks for you work on the admin’s style,
>>>
>>> --
>>> Aymeric.
>>>
>>> On 9 Jan 2017, at 11:59, elky  wrote:
>>>
>>> Hi guys,
>>>
>>> Few months ago I released *django-flat-responsive*
>>>  app - a simple
>>> extension for admin that makes interface mobile and tablet friendly. I
>>> tested it on few complex projects using major mobile browsers and it works
>>> good. Now I'm going to make pull request to Django repo but before I want
>>> to ask community -- is it necessary to have responsive admin?
>>>
>>> My thoughts:
>>>
>>> Pros:
>>> - It's modern
>>> - Few times I really needed to make some edits inside admin through my
>>> mobile (it was painful), so I think some people want admin to be responsive
>>>
>>> Cons:
>>> - New admin features should be always tested on mobile devices (or on
>>> different screen sizes at least). It also uses CSS3 flexbox so developers
>>> shoul learn how it works
>>> - 3rd party apps should care about responsive layout. It's not so easy
>>> for some apps like Django Admin Tools or some CMS based on admin
>>>
>>> As fas as django-flat-responsive just adds one CSS file to static
>>> folder, what if to have an option in *settings.py* that enables
>>> responsive admin?
>>>
>>> I would glad to hear your thoughts
>>>
>>> Thank you
>>>
>>> --
>>> 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/ms
>>> gid/django-developers/dd915c1d-d8a8-4f91-a223-268e17044cd1%4
>>> 0googlegroups.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/ms
>>> gid/django-developers/5A95FC83-B1DD-408C-94B7-9A4E81A6F1D3%4
>>> 0polytechnique.org
>>> 

Re: Provide a simpler way to default runserver IP/port to 0.0.0.0:8000

[Collin Anderson]

If it helps, there's a also a shortcut: ./manage.py runserver 0:8000. Much
easier to type.

On Mon, Nov 28, 2016 at 8:48 AM,  wrote:

> This was filed as https://code.djangoproject.com/ticket/27537 , but
> moving here for discussion.
>
> We have the following use case:
> * An app uses a VM for the local development environment (eg via Vagrant).
> * It's required to be accessible from the VM host (either on it's own IP,
> or on localhost via eg Virtualbox port forwarding) to allow development to
> occur using editors/browsers on the host. (The configuration is such that
> connections are only allowed from the VM host and not other machines on the
> network, so this is still secure.)
> * The app has no need for nginx/apache, since production is Heroku (where
> that's discouraged) and so it uses gunicorn + WhiteNoise.
> * During development, devs want to use runserver rather than gunicorn for
> convenience (and familiarity for existing Django devs).
> * However `./manage.py runserver` doesn't work, since that binds to the
> loopback adapter of the VM guest OS only (127.0.0.1) and not 0.0.0.0. (This
> is a sensible default.)
> * Therefore `./manage.py runserver 0.0.0.0:8000` must be used, which:
>   - is not immediately obvious to devs new to the project (which is open
> source, so we often have new contributors). Docs are great, but not
> everyone reads them fully - defaults that work out of the box are best.
>   - means even once they realise the need for the explicit binding
> address, they have to type it out every time.
>
> Current workarounds are:
> a) Add an nginx/apache/varnish service to the VM to reverse proxy from
> 0.0.0.0:X to 127.0.0.0:8000, increasing bootstrap time and boilerplate.
> b) Not use runserver, and use gunicorn instead (where the `PORT`
> environment variable can be set, making it bind to `0.0.0.0:` [1]).
> c) Add bash aliases to the development environment (but then they're not
> immediately discoverable either, and break muscle memory for existing
> Django users).
> d) Write a custom runserver command that overrides the inbuilt one (but
> this requires overriding the `handle()` method, since `127.0.0.1` is
> hardcoded [2], so even more boilerplate).
>
> Possible changes that would make this easier:
> 1) Allow overriding runserver default IP/port using Django settings.
> 2) Allow overriding runserver default IP/port using environment variables
> (like `PORT` already supported by gunicorn, that defaults the IP to
> `0.0.0.0` too).
> 3) Move the hardcoded `127.0.0.1` string [2] to an attribute on the
> `Command`, like `default_port` is, to at least reduce the boilerplate for
> overriding using a custom runserver command.
>
> I can imagine (3) would be more likely to be accepted, however it would
> still mean we have to override runserver, so (1) or (2) would be preferred.
>
> I'm happy to implement this - it would just be helpful to know people's
> thoughts before I open a PR.
>
> Many thanks :-)
>
> Ed
>
> [1] https://github.com/benoitc/gunicorn/blob/
> 6eb01409da42a81b7020cd78c52613d8ec868e94/gunicorn/config.py#L543-L544
> [2] https://github.com/django/django/blob/eb42d8d5d9b0968ce12d09760afff6
> 84bee56a3a/django/core/management/commands/runserver.py#L95
>
> --
> 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/1f272641-1fbd-4b0a-8f45-
> b757c0d2b975%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/CAFO84S4zkeG0DBLA98_cAObatqFPKGPwQuWN2WCsKEmfOMjW%2BQ%40mail.gmail.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: Add HTML5 required attribute on form widgets

[Collin Anderson]

Hi Jon,

They're regular input fields that I'm using jQuery to .hide() and .show()
form fields on the front end of my ecommerce sites, based on different
radio buttons. It's all my jQuery code. I then have custom logic in the
backend to delete fields from forms, or select which form to validate
against. (Login vs Create account, Checkout vs Apply promo code, Use a
saved address or add new address, etc.)

Thanks,
Collin


On Thu, May 5, 2016 at 2:34 PM, Jon Dufresne  wrote:

> On Thu, May 5, 2016 at 11:29 AM, Collin Anderson 
> wrote:
>
>> If anyone is running into hidden required fields preventing forms from
>> submitting (like me), I've been using this jQuery code for a somewhat-hacky
>> quickfix:
>>
>> $(':hidden[required]').removeAttr('required')
>>
>>
> The changes made on master should not be adding required to hidden inputs.
> I added a check to prevent this. Are you experiencing different?
>
> Are these inputs hidden by Django or from another source?
>
> Cheers,
> Jon
>
> --
> 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/CADhq2b44N4VxvtoB-QYykapRoQtCXHbrNpOzxbay0KzmpSjHqQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CADhq2b44N4VxvtoB-QYykapRoQtCXHbrNpOzxbay0KzmpSjHqQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
> 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/CAFO84S7SPxiSy1Esfn04D7qoQP91dJ5Vs3XA6RA%3DrfPpzoRUgQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Add HTML5 required attribute on form widgets

[Collin Anderson]

If anyone is running into hidden required fields preventing forms from 
submitting (like me), I've been using this jQuery code for a somewhat-hacky 
quickfix:

$(':hidden[required]').removeAttr('required')

On Saturday, April 2, 2016 at 12:27:28 PM UTC-4, Jon Dufresne wrote:
>
> On Wed, Mar 30, 2016 at 7:01 AM, Alex Riina  > wrote:
>
>> What's the plan for formsets with extra?
>>
>> I could see the required only getting applied to the first min forms but 
>> I'm not sure there is an actual workable case there. It seems like it will 
>> get too messy with adding and deleting at the same time.
>>
>> If can_delete is false and extra is 0, it seems like the required 
>> attribute could at least be used. Because of this, I think it should 
>> probably be an initialization argument, default to false, or be overridden 
>> when constructing forms in formsets.
>>
>> https://github.com/gregmuellegger/django-floppyforms/issues/75
>>
>>
> Thanks for highlighting this.
>
> I'll investigate implementing the suggestion "If can_delete is false and 
> extra is 0, it seems like the required attribute could at least be used. 
> Because of this, I think it should probably be an initialization argument, 
> default to false, or be overridden when constructing forms in formsets." 
> Thanks.
>
> I think with this concern, this feature can't be solved entirely by 
> template-base widgets as something other then Field.required is necessary 
> for the formset case.
>
> Cheers,
> Jon
>
>

-- 
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/38bb7257-7d81-4197-bc9d-feb686e8508c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Vendoring Select2

[Collin Anderson]

Hi All,

I'm in favor of this change. This has the potential to replace the 
raw_id_fields and filter_horizontal which I think would be a huge win. 
Those widgets are out-dated not only in terms of code, but also from a UI 
point of view.

I'll try to give my answers to some questions before they come up.

- Aren't we having a discussion about adding hard-dependencies instead of 
vendoring code? Yes, and I think it's something we could consider down the 
road for this case, if our experiments with other libraries work out. This 
is little different though different because it's front-end code. For one 
thing, if we do a dependency on a 3rd party library, you'd have to add that 
library to INSTALLED_APPS for it to pick up the static files. Even then, it 
will only work if you use collectstatic (which I personally do not). Also, 
because this is front-end javascript, in theory there shouldn't be security 
holes in the code (we're not supposed to trust browser code in any case). 
Again, I think it's something we could consider down the road.

- Why select2? I haven't heard any serious proposals of a different library 
to use.

- Why not write the UI ourselves? Feel free. I spent a few hours at the 
Django Under the Hood sprints trying to write my own and it's a lot of 
work. You need to ajax-in the data, position the box in the right spot, 
handle keyboard events, etc. That's more javascript code we need to 
maintain (which, yes, we don't like doing :), and there's already a 
polished library we can use.

- Why not make it a generic form widget? I think this would be a lot more 
work. It would require adding a url endpoint and likely more configuration. 
If it's admin-only (for now), we can re-use the permission system and 
search_fields and keep it simple and seemless. I think making it generic is 
something we could consider down the road.

Thanks!
Collin

On Wednesday, April 6, 2016 at 9:25:08 AM UTC-4, Johannes Hoppe wrote:
>
> Hi,
>
> as promised I started working on an autocomplete field for 
> `django.contrib.admin` as a more convenient alternative to `row_id_fields`.
>
> We had a longer discussion in the ticket and also at the sprints at 
> DjangoConEU with some of the maintainers for famous 3rd party autocomplete 
> integrations.
>
> We concluded that select2 is the most mature and stable solution, that 
> also doesn't require us to write our own JS code. (I know how much we hate 
> it ;)
>
> Notable:
> 1. In order to use `jQuery.noConflict(true);` I hat to add a wrapper 
> around the vendored Select2 library. I think that is better than leaving 
> `jQuery` in the global namespace.
> 2. `$.select2` will only be added to `django.jQuery` and therefore not 
> interfere with other implementations. One should still be able to use 3rd 
> party libraries.
> 3. Select2 is unter MIT license.
>
> All in all I tried not to break anything and have this as new opt in 
> solution. Lets see how it plays out.
>
> All I need for you is to decided on wether or not with should vendor 
> Select2.
>
> PR is here: https://github.com/django/django/pull/6385
>
> Thanks in advance!
> Joe
>

-- 
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/c2c6fd19-da23-4f11-9465-6816681d3aa2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: A helpful ImportError for manage.py when Django isn't installed/available

[Collin Anderson]

We could also wait til after we remove py2 support in January. That way we
can be sure that on py3 it will also print the original exception so it
doesn't get hidden. (Right?)

On Fri, Apr 1, 2016 at 6:23 AM, Shai Berger  wrote:

> An idea: Catch the exception; in the handler, try to simply "import
> django".
> If this works, reraise, if it fails, print helpful message.
>
> On Thursday 31 March 2016 20:15:05 Tim Graham wrote:
> > Ben Welsh (palewire) raised a proposal on a GitHub pull request [0]:
> >
> > I've seen newbies flounder when they receive this error after running
> > manage.py.
> >
> > $ python manage.py
> > Traceback (most recent call last):
> >   File "manage.py", line 7, in 
> > from django.core.management import execute_from_command_line
> > ImportError: No module named django.core.management
> >
> > The root cause is almost always simple, like forgetting install Django
> with
> > pip or neglecting to "activate" a virtual environment. But the Python
> > jargon doesn't do much to help people new to our world connect the dots.
> >
> > My proposal: Catch that error and print out a more verbose message that
> > explains to the user exactly what's wrong. Here's my draft. I'd welcome
> any
> > changes, but I think something along these lines could better welcome new
> > people into Django.
> >
> > Traceback (most recent call last):
> >   File "manage.py", line 11, in 
> > installed and available on your PATH variable?")
> > ImportError: Couldn't import Django. Are you sure it's installed and
> > available on your PYTHONPATH environment variable? Did you forget to
> > activate a virtual environment?
> >
> >
> >
> > -
> > Claude says, "I'm not convinced about this. Aren't we hiding other
> possibly
> > helpful import errors (at least on Python 2)?"
> > Aymeric says, "I share Claude's concern. We've been constantly removing
> > that sort of "helpful" exception wrapping from Django"
> > Aymeric again, after further investigation, "Importing
> > django.core.management doesn't ripple too far. Specifically it doesn't
> > import any of the user's code. This reduces the likelihood of masking
> > useful errors. It will mask exception info if Django is installed
> > incorrectly, for instance because two installs happened in the same
> > location (but I think that's less likely since pip/virtualenv became
> > mainstream and since we added code to setup.py to detect existing
> > installs).
> >
> > Does anyone else have opinions on the change? I suppose another option
> > could be to try to reraise the original exception with the "helpful
> > message" added.
> >
> >
> > [0] https://github.com/django/django/pull/6314
>

-- 
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/CAFO84S7xXEUzRXRS%2BPDHc0%2Bso_aa0jkNSO9M0wTD%3DcFXrxHb0A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Add HTML5 required attribute on form widgets

[Collin Anderson]

Hi All,

I think things are kind of quiet because djangocon.eu is starting tomorrow.

My opinion: In the past we changed things to use html5 types (number,
email, url, etc) and we didn't use a deprecation warning in those cases,
just mentioned it in the release notes. I'm sure it will break some
people's applications, but I think as long as we made it easy to remove the
required attribute it shouldn't be a big problem to not warn first.

Thanks,
Collin


On Mon, Mar 28, 2016 at 5:27 PM, Jon Dufresne 
wrote:

> Hi,
>
> I'm working on ticket #22383 to add the HTML5 required attribute to form
> widgets.
>
> The hope is this will add an additional level of validation at the client
> side. The feedback provided to the user is much faster than a server round
> trip.
>
> This is something I've done manually in my own projects. I'll frequently
> add "required" to widget attrs to take advantage of this validation. As I
> already use this frequently, I'm motivated to see it adopted by the Django
> core.
>
> This feature have been discussed in the ticket [1] as well as a previous
> email thread [2].
>
> In the past, there were two discussed concerns:
>
> * Allow a project to opt-out of using the required attribute
> * Add a deprecation warning that new version of Django will include the
> required attribute
>
> Past discussion settled on using the class attribute
> Form.use_required_attribute to decide if a form's widget should render the
> HTML5 required attribute. As this was the previous consensus I have
> implemented a PR [3]. To be on the safe side, this PR also adds the
> deprecation warning.
>
> Upon review, Tim Graham replied with the following:
>
> I fear the deprecation will be quite annoying if every form in a project
>> needs to be modified to silence all warnings.
>> ...
>> I guess I'm not sure if a deprecation path provides more value than
>> making a backwards-incompatible change. For example, if we expect a
>> majority of projects to adopt this change, then a deprecation will require
>> every Django project to silence the warning instead of a subset of users to
>> opt-out.
>>
>
> No problem for me. I'm OK skipping the deprecation path. I don't see it as
> necessary, I was simply trying to accommodate other opinions. I have
> created a second PR which is identical to the first, but without the
> deprecation warning [4].
>
> Also in the review Tim suggested the following:
>
> I wonder if template-based widget rendering (#15667
>> ) might ease this change. A
>> project could provide custom widget templates if they don't want the
>> required attribute (or if they want required='required'.
>>
>
> This is a different approach than previously discussed. I see the merit in
> this suggestion and think it could be a better implementation. With this
> idea, we could avoid adding the Form.use_required_attribute, entirely.
> However, template-based widget is still very much a WIP. I worry waiting on
> that feature may mean this simpler feature may miss a release cycle. Is it
> reasonable to expect the template-based widget rendering to land before the
> next alpha/beta cut?
>
> Tim asked I post these ideas to the mailing to get other opinions and
> feedback on these two points.
>
> Thanks,
> Jon
>
>
> [1] https://code.djangoproject.com/ticket/22383
> [2]
> https://groups.google.com/forum/#!topic/django-developers/obw18wSc4xU/discussion
> [3] https://github.com/django/django/pull/6341
> [4] https://github.com/django/django/pull/6352
>
> --
> 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/CADhq2b7z08aYuY_wpzCCkCaEfOAT5uQvh74wsPCJoZT0hF5aGg%40mail.gmail.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/CAFO84S4get-fKgr20oy58rnwnZ2stXFqzA5u2xisYwOyLjd7uQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: relative path in {% extends "...base.html" %} like relative import

[Collin Anderson]

Hmm... I suppose the closest alternative we have would be to store the base
template name in a variable and pass it in from the view.

On Fri, Mar 18, 2016 at 12:42 PM, Vitaly Bogomolov 
wrote:

> Hi, All.
>
> For django.template.backends.django.DjangoTemplates (filesystem and
> app_directories) it can be very useful. This can be implemented?
>
> WBR, Vitaly.
>
> --
> 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/ccb20872-b91c-493b-b9f6-b4a28170cb99%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/CAFO84S4Q9qmqNGaZzoJEH-Jtzc2RwevjES9oPuQUV3W%2B0i824w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [GSOC] Original Idea/Seeking Mentor: Conditions API (Related to Auth)

[Collin Anderson]

Hi Connor,

I personally usually avoid class based views whenever possible and stick to 
function based views whenever possible. Would these Conditions be usable 
within function based views too?

Thanks,
Collin


On Thursday, March 17, 2016 at 8:00:16 AM UTC-4, Connor Boyle wrote:
>
> My original inspiration actually was Django Rest Framework, but I wanted 
> to show that I had actually thought it out and that it is indeed possible 
> to implement in core Django (albeit not quite as cleanly as DRF does it). 
> I'll try to finish a more detailed write-up of how they compare, but in 
> short they are very similar. In terms of overall paradigm, the largest 
> difference is that DRF's "permissions" are designed exclusively for being 
> run given the request or the request and the result of get_object(). My 
> proposal, on the other hand, would allow conditions to be written that 
> don't require these arguments and in fact require other arguments, although 
> it does provide appropriate sub-classes for these extremely common usage 
> cases. This is enabled by one other key difference between the two: my 
> proposal's separation between the evaluate() layer–the one that's generally 
> overridden by the developer or by common usage sub-classes–and the run() 
> layer–which calls the evaluate() layer after picking which keyword 
> arguments it should pass to it.
>
> On Thursday, March 17, 2016 at 1:31:37 AM UTC+8, Ryan Hiebert wrote:
>>
>>
>> On Mar 16, 2016, at 11:55 AM, Connor Boyle  wrote:
>>
>> I'm hoping to add a feature that I've thought Django has needed for a 
>> long time, and thought that Google Summer of Code would be an excellent 
>> opportunity for it. Basically, it would be an API for defining 'Conditions' 
>> and applying them to Views. [snip]
>>
>> 1. How clear and convincing is the section describing what's wrong with 
>> the current solution ('The Problem(s)')? Any criticisms on that section 
>> would be very welcome.
>>
>>
>> It seems like a neat idea, and reasonably well thought out, though I 
>> don't have the standing needed to speak to its viability as a GSOC project 
>> or for inclusion in Django. I'd be interested to see a write-up comparing 
>> this with Django Rest Framework's Permissions, which seem pretty similar in 
>> concept. http://www.django-rest-framework.org/api-guide/permissions/
>>
>

-- 
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/2748d40d-ed70-48e0-a613-27d938a77fbb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: change to the way list_editable form data is submitted in the admin

[Collin Anderson]

I could see this feature being helpful. (Submitting the original data and
comparing it to be sure we don't silently have a merge conflict).

On Wed, Mar 16, 2016 at 11:14 PM, John C  wrote:

> Thanks. #11652 is a good description of the same problem in the context of
> the "change" page. I think that, in practice, it is more of a problem with
> a list_editable, since you're updating many records at once. This makes a
> "collision" with some other part of the system more likely.
>
> I think the approach outlined in #16549, which requires persisting a
> version number, would suffice but is not really necessary. I can understand
> wanting to make the solution applicable more widely than just one
> particular admin feature; however, the best solution depends on the
> context. In the case of #11652, optimistic locking is a good fit, because
> we can't assume the granularity of the different fields on the model.
> Whereas with list_editable, it's a bunch of records of the same type. It is
> quite safe to assume that we can consider the records that were updated by
> the user, compared to the values originally displayed, and do all these
> changes independently of one another. From this point of view, it is
> actually an optimization, to skip the update when there is no change.
>
> -John
>
> On Wednesday, March 16, 2016 at 8:21:40 PM UTC-5, Josh Smeaton wrote:
>>
>> I know this particular case has been discussed before. Here are two
>> related tickets (I think there's a better canonical ticket but I can't find
>> it just now): https://code.djangoproject.com/ticket/11652 and
>> https://code.djangoproject.com/ticket/16549
>>
>> I haven't done the required reading recently, so I can't comment on
>> whether or not your idea could be accepted. But hopefully those tickets
>> should provide a bit more information for investigation puproses.
>>
>>
>>
>> On Thursday, 17 March 2016 11:37:06 UTC+11, John C wrote:
>>>
>>> Hey,
>>>
>>> For the past five years, I've been using Django to manage a database of
>>> online applications. I absolutely love it! Makes my job so much easier.
>>>
>>> In general, any problems I run into, there's usually an easy workaround.
>>> But I wonder if that's even feasible in this case. Anyway, here's the
>>> problem: in managing submissions we make a lot of use of the list_editable
>>> attribute of ModelAdmin, particularly for status columns. It's extremely
>>> handy to be able to load up a list, filter it, and then make status changes
>>> to selected records all in one go.
>>>
>>> However, there are times when these status columns are also changing on
>>> their own, due to what's happening on the front end. I have to be very
>>> careful to ensure that this doesn't happen in between when I load an admin
>>> list and when I click "Save." If so, then I may end up overwriting the
>>> newly changed data, back to what it was when the list was loaded in my
>>> browser. This is because all rows are always saved, based on the data in
>>> the form inputs from the list.
>>>
>>> I propose that a copy of the list_editable values be sent along as a
>>> hidden form element (or, alternatively, that Javascript be used to detect
>>> values changed in response to user input). That way, in the admin form
>>> handler, only rows that have been intended to be changed would be updated
>>> to submitted values.
>>>
>>> It adds some complexity, sure, but are there any disadvantages I haven't
>>> thought of? From my perspective, it would solve a rather frustrating
>>> problem.
>>>
>>> Thanks,
>>> John Cronan
>>>
>>> --
> 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/1f970804-7b49-44da-916f-21270e4a3cac%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/CAFO84S5M7OB-CsHPAwVjze%2B9NkbiPbJ_qNd2SYVKm3hA5vsBhw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout

Re: Revisiting multiline tags

[Collin Anderson]

Here's the actual code PR https://github.com/django/django/pull/2556

On Sun, Mar 13, 2016 at 1:26 AM, Martijn van Oosterhout 
wrote:

>
> On 12 March 2016 at 05:31, Curtis Maloney  wrote:
>
> I think this conversation needs to come to a conclusion, and that
>>> conclusion should be simple. Several people have asked a very simple
>>> question of the purists: what is the "correct" way of writing tags which
>>> by nature need to be very long, without line breaks and without them
>>> being 400 characters long. If no acceptable answer can be given, we need
>>> to just implement the line break mechanic and give the developers back
>>> their whitespace.
>>>
>>
>> As pointed out by Josh in another email, I wrote a patch to permit
>> multi-line tags.  I asked for feedback.  I got _none_.
>>
>> If people really wanted this feature, why didn't we hear more about it?
>> What can we do to get more people to know about it, and to give more
>> feedback?
>>
>> I would recommend you review the history of this discussion, collect the
>> pros and cons, formulate a DEP, and we can go from there.
>>
>> I'm quite sure the patch will still work fine.
>>
>>
> Presumably you're talking about this:
> https://github.com/django/deps/pull/3/files
>
> I'm not sure what feedback you're expecting, but if +1's are what's
> needed, then here you go: +1.
>
> The thing is, this feature is a nice to have but no show stopper. The
> first time a developer runs into this (by trying the obvious and finding it
> doesn't work), they'll check the documentation, shrug their shoulders at
> the weird Django developers and get on with their job.
>
> Perhaps 1% will go to the effort of seeing if it has been proposed, find
> it's been mentioned several times and think "someone is working on it" and
> get on with their job.
>
> Perhaps 1% of those will note it hasn't been done yet, dig deeper and find
> your proposal and the various bugs, note it's been blocked, figure it's a
> lost cause and get on with their job.
>
> If this change requires a horde of developers waking up and calling for
> it, then it's never going to happen. The current situation will however
> continue to cause wasted developer time until eternity. Simply because
> there is no obvious reason why it shouldn't work. It's not ambiguous, it's
> not going to confuse anyone, it's just one of those little things that
> makes computers just a little bit more user friendly.
>
> Have a nice day,
> --
> Martijn van Oosterhout  http://svana.org/kleptog/
>
> --
> 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/CADWG95v7eMb8u85PyS3MsigXMVoKs3a_H9zx8aGJBsetBaWyLQ%40mail.gmail.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/CAFO84S6iJt9DCuRM5LKDWX%3DB02BUq7zBgf8TDp3-%2BrC4xGHLRQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Override the default form field for a model field

[Collin Anderson]

A few thoughts, just to see if we can solve the problem by documenting some
existing code:

Would making a subclass overriding formfield() work?

class RadioSelectBoolean(models.BooleanField):
def formfield(self, *args, **kwargs):
kwargs['widget'] = forms.RadioSelect
super(RadioSelectBoolean, self).formfield(*args, **kwargs)

Or would using fields_for_model help?
https://github.com/django/django/blob/master/django/forms/models.py#L111

On Thu, Mar 17, 2016 at 1:49 PM, James Pic  wrote:

> If we prefer to remove form related stuff from models, then we should
> be able to register new default model forms:
>
> models.py:
>
> class YourModel(models.Model):
> your_field = models.BooleanField()
>
> forms.py:
>
> class YourModelDefaultForm(django.?.ModelFormConfiguration):
> class Meta:
> help_texts = dict(your_field='your help text')
>
> # Set it as default
> django.?.register(YourModel, YourModelDefaultForm)
>
> --
> 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/CALC3KaeL2VefbA_GfkhaYf8jWJvr%3DsRLLjyP4FcHL9_q_EwfxA%40mail.gmail.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/CAFO84S4R_oHPRot1uL6p2kCqTppQb4yL0-d0DPQtgyy7VbWnAQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Translate permission Django

[Collin Anderson]

Maybe we could have __str__ run the text through _()? I don't do much
translating.

On Mon, Mar 7, 2016 at 10:21 AM, Tim Graham  wrote:

> This has been discussed in several tickets (
> https://www.google.com/search?&q=translate+permissions+site%3Acode.djangoproject.com)
> and mailing list threads (search the archives of this list for "translate
> permissions"). As far as I can tell, there's no clear solution at this time.
>
> On Monday, February 29, 2016 at 10:03:12 AM UTC-5, Marcos Serrano wrote:
>>
>>
>> 
>>
>>
>> 
>>
>>
>> El lunes, 29 de febrero de 2016, 10:20:36 (UTC+1), Marcos Serrano
>> escribió:
>>>
>>> Hello,
>>>
>>> How to translate the default permissions django . Keywords ( Add, Delete 
>>> ... )
>>>
>>> --
> 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/2fac44f8-0d92-4830-a68d-6e4e48018921%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/CAFO84S52fbNggXAHaQs5VAc8mCttaqwFEJpFCyVRsOEC6RgMrw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.