Re: How to disable system check framework?

[Carlton Gibson]

Sorry to be a pain but, could this thread be continued (if it's going to be) on 
Django Users?




(sorry)



—

On Wed, Aug 5, 2015 at 3:59 PM, Marcin Nowak 
wrote:

> Hi Aymeric,
> This project is complex, as I said before, and works well with Django 1.4. 
> But we need to upgrade it to newer version because of lack of support, 
> security issues, and simplifcation of maintenance and growth (we're 
> currently using three different Django versions, from 1.4 to 1.7, and we've 
> decided to upgrade all subprojects to 1.8)
> commit_manually() is used within long-live processes running as a mgmt 
> commands, where is used multiprocessing too.
> Whole process is complicated and hard to maintain. I would like to avoid 
> logical / flow changes, whose are required to replace commit_manually() 
> with atomic().
> Second use case is a extract-transform-load subsytem, which also requires 
> precise development of queries, commits and rollbacks. I'm afraid that 
> upgrade of it may be also hard.
> I think that there are rare cases, when manual transaction handling is 
> required and should be available for punctilious developer.
> *BUT* I can't say that atomic() does not fit my needs. I know how it work 
> (I belive), but it may not cover current cases (implementation).
> I must try to do replacement or bring old behaviour of commit_manually() 
> with my custom wrapper. I'm trying to change code as less as possible.
> You're asking what could be done better.. Generally speaking - an API 
> compatibility layer. As a maintainer of big and old project I would like to 
> import "commit_manually" from special module delivered with Django, which 
> will guarantee stability and compatibility. This may be even undocumented. 
> Manual commit() and rollback() functions are provided in transaction module 
> (thanks so much for that!), so making compat layer should be possible, I 
> think.
> Kind Regards,
> Marcin
> On Wednesday, August 5, 2015 at 1:16:38 PM UTC+2, Aymeric Augustin wrote:
>>
>> On 5 août 2015, at 11:09, Marcin Nowak  
>> wrote: 
>>
>> > I'm using commit_manually() frequently, but this decorator was 
>> removed... 
>>
>> Hi Marcin, 
>>
>> Sorry for derailing the discussion a bit, but could you clarify why you 
>> were 
>> using this API? I removed it after failing to find a use case where it 
>> would 
>> be preferrable to commit_on_success(). I’d love to know if I missed 
>> something 
>> in order to avoid making similar mistakes again. 
>>
>> Using commit_manually() properly required great care -- and a try/finally 
>> construct in practice -- to ensure that no code path escaped without a 
>> commit 
>> or a rollback. It also required a massive amount of boilerplate to avoid 
>> masking exceptions: 
>>
>> - 
>> https://groups.google.com/d/msg/django-developers/S3a5UAqAsmg/7C27UGl6G_0J 
>> - https://code.djangoproject.com/ticket/6623 
>>
>> If you replace it with transaction.atomic() and remove the boilerplate, 
>> you 
>> get the same behavior with ten times less code. 
>>
>> In case removing the boilerplate creates too much code churn, I documented 
>> a 
>> real drop-in replacement that doesn't have the drawbacks of 
>> commit_manually: 
>> https://docs.djangoproject.com/en/1.6/topics/db/transactions/#id5 
>>
>> What could I have done better? 
>>
>> If you don't want any changes in Django -- your posts to this list are 
>> often 
>> after-the-fact complains about new features -- perhaps you could stick 
>> with 
>> whatever version of Django you're currently running? 
>>
>> -- 
>> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/3257c139-f52e-422f-8eb4-5a97771ca367%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1438783672435.73354761%40Nodemailer.
For more options, visit https://groups.google.com/d/optout.

Fellow Reports -- May 2018

[Carlton Gibson]

Hi all,


Calendar Week 18 -- ending 4th May.

Reviewed Patches on:

https://code.djangoproject.com/ticket/8936  -- Add view (read-only) 
permission to admin
https://code.djangoproject.com/ticket/29376 -- admin improvement: Take into 
account `show_save_and_add_another`…
https://code.djangoproject.com/ticket/29351 -- Document that 
ModelAdmin.prepopulated_fields removes stop words
https://code.djangoproject.com/ticket/29363 -- Use unittest assertWarns 
methods instead of warnings.catch_warnings/simplefilter/assertions in the 
test suite.
https://code.djangoproject.com/ticket/23718 -- TEST_MIRROR setting doesn't 
work as expected (and has no tests)
https://code.djangoproject.com/ticket/28687 -- Added a 'Not Empty' option 
to admin's related filter.
https://code.djangoproject.com/ticket/29358 -- Add a system check to 
prohibit models with more than one primary_key field
https://code.djangoproject.com/ticket/28462 -- ModelAdmin.list_editable 
unusably slow and memory intensive with large datasets
https://code.djangoproject.com/ticket/27629 -- Inconsistent check of 
allow_relation in ForwardManyToOneDescriptor.__set__
https://github.com/django/django/pull/9915  -- Use double quotation marks 
for csrf form element
https://github.com/django/django/pull/9916  -- Update tutorial05.txt


Authored:

https://code.djangoproject.com/ticket/29373 -- Provide a description for 
PyPI


Triaged:

https://code.djangoproject.com/ticket/29365 -- the reverse function does 
not work in the current application, which was included in the URL using 
namespace (invalid)




Calendar Week 19 -- ending 11th May.

Reviewed Patches on:

https://code.djangoproject.com/ticket/23718 -- TEST_MIRROR setting doesn't 
work as expected (and has no tests)
https://code.djangoproject.com/ticket/29336 -- No docs for circular 
inheritance
https://code.djangoproject.com/ticket/28462 -- ModelAdmin.list_editable 
unusably slow and memory intensive with large datasets
https://code.djangoproject.com/ticket/29392 -- Command parsing does not 
handle options that conflict with `--settings`/`--pythonpath`
https://code.djangoproject.com/ticket/29379 -- Add autocomplete attribute 
to contrib.auth fields
https://code.djangoproject.com/ticket/21408 -- Fallback to timesince 
produces erroneous translations in naturaltime
https://code.djangoproject.com/ticket/20147 -- Provide an alternative to 
request.META for accessing HTTP headers
https://code.djangoproject.com/ticket/28687 -- Add a 'Not Empty' option to 
admin's related filter
https://github.com/django/django/pull/9930  -- Replaced context by comment 
in 2 humanize strings



Triaged:

https://code.djangoproject.com/ticket/29387 -- GenericRelation's on proxy 
models do not cascade deletion (worksforme: Provided patch. Did not 
reproduce)
https://code.djangoproject.com/ticket/29382 -- don't call objects with 
__call__ instantly (Duplicate)
https://code.djangoproject.com/ticket/29381 -- Move some parts of 
`django.contrib.auth.models` to `django.contrib.auth.base_user` for 
reusability (needsinfo)
https://code.djangoproject.com/ticket/29281 -- In some cases i18n 
set_language does not change url language (wontfix)
https://code.djangoproject.com/ticket/29346 -- Add "intermediary" kwarg to 
ModelForm._save_m2m 
https://code.djangoproject.com/ticket/29364 -- 
CommonMiddleware.get_full_path_with_slash should raise exception for POST / 
PUT / PATCH requests even if settings.DEBUG = False (Suggested wontfix)
https://code.djangoproject.com/ticket/29386 -- Meta Inheritance for 
default_permissions (invalid: expected behaviour)
https://code.djangoproject.com/ticket/29390 -- trans_null.ngettext() should 
consider values of -1 as singular (wontfix)
https://code.djangoproject.com/ticket/26600 -- map says a queryset is not 
iterable (Reopened for new reproduce. Then wontfix)
https://code.djangoproject.com/ticket/29394 -- Broken urls.py instructions 
in tutorial 1 (Invalid)


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/8cc0d3a9-9ac7-4c2f-9783-df6c88636895%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Fellow Reports -- June 2018

[Carlton Gibson]

Hi all,

Calendar Week 23 -- ending 8th June.

Reviewed Patches on:

https://code.djangoproject.com/ticket/29301 -- Reorder management command 
arguments in --help output to prioritize command-specific arguments
https://code.djangoproject.com/ticket/29353 -- _middleware_chain is not set 
for StaticFilesHandler
https://code.djangoproject.com/ticket/29451 -- Add compatibility with MySQL 
8
https://code.djangoproject.com/ticket/29428 -- Add support to admin for 
expressions like (Lower('myfield'),) in model Meta.ordering
https://code.djangoproject.com/ticket/11964 -- Added support for check 
constraints in model Meta.
https://code.djangoproject.com/ticket/28697 -- Add a 'Not Empty' option to 
admin's related filter
https://code.djangoproject.com/ticket/29426 -- UUID fields display poorly 
in the admin


Triaged:

https://code.djangoproject.com/ticket/29468 -- Improve Form Field 
declaration of widget `attrs`. (wontfix)
https://code.djangoproject.com/ticket/29463 -- add pagination to stacked 
inline and tabular inline. (needsinfo)
https://code.djangoproject.com/ticket/29448 -- Create management command 
management command. (wontfix)


Authored:

https://github.com/django/django/commit/b30f9b131c9489b9d9f21c311ecb46d0aea91381
 
-- Refs #29419, #8936 -- Removed change permission requirement for 
admin actions.
https://github.com/django/django/pull/10028 -- Fixed invalid SQL on 
PostgreSQL in queries tests.
https://github.com/django/django/pull/10029 -- Refs #29392 -- Added command 
line short option `-s` for specifying settings.



Calendar Week 24 -- ending 15th June.

Reviewed Patches on:

https://code.djangoproject.com/ticket/29152 -- Allow more control over 
ArgumentParser initialization in management commands
https://code.djangoproject.com/ticket/29487 -- Admin "read only" doesn't 
check change permission for object specifically
https://code.djangoproject.com/ticket/24384 -- compilemessages shouldn't 
return with exit code 0 when it fails
https://code.djangoproject.com/ticket/18620 -- Prefer current Site when 
checking M2M in "shortcut"/"view_on_site" redirect
https://code.djangoproject.com/ticket/29493 -- Block strings from being 
passed to `__in`
https://code.djangoproject.com/ticket/29494 -- Flush command doesn’t work 
on custom db_table including schema
https://code.djangoproject.com/ticket/29428 -- Add support to admin for 
expressions like (Lower('myfield'),) in model Meta.ordering

Triaged:

https://code.djangoproject.com/ticket/29493 -- Block strings from being 
passed to `__in`. (wontfix)
https://code.djangoproject.com/ticket/29494 -- Flush command doesn’t work 
on custom db_table including schema. (duplicate)
https://code.djangoproject.com/ticket/29488 -- FilteredSelectMultiple 
Controls Don't Work if The Name of the Widget Has a Space (Didn't 
reproduce. Tim eventually closed as wontfix)

Authored: 

https://code.djangoproject.com/ticket/29419 -- Allowed permissioning of 
admin actions.


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/2c82bab8-b5e1-4aad-8207-510f31a79140%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Fellow Reports -- May 2018

[Carlton Gibson]

Hi all. 

Calendar Week 20 -- ending 18th May.


Reviewed Patches on:

https://code.djangoproject.com/ticket/29408 -- ordering by field from 
related model does not validate if field exists
https://code.djangoproject.com/ticket/28743 -- Clarify the term "deployment 
server" in the documentation
https://code.djangoproject.com/ticket/3461  -- DatabaseWrapper should pass 
through args and kwargs to underlying database adapter
https://code.djangoproject.com/ticket/20147 -- Provide an alternative to 
request.META for accessing HTTP headers
https://code.djangoproject.com/ticket/28462 -- ModelAdmin.list_editable 
memory intensive with large datasets
https://code.djangoproject.com/ticket/11964 -- Add the ability to use 
database-level CHECK CONSTRAINTS
https://code.djangoproject.com/ticket/29381 -- Move some parts of 
`django.contrib.auth.models` to `django.contrib.auth.base_user` for 
reusability
https://github.com/django/django/pull/9954  -- Update http.py
https://github.com/django/django/pull/9956  -- Add missing word to 
deprecation warning text


Triaged:

https://code.djangoproject.com/ticket/29411 -- Pickling of a form fails 
after a form was used in a template. (Duplicate)
https://code.djangoproject.com/ticket/29379 -- Add autocomplete attribute 
to contrib.auth fields. (Accepted)


Calendar Week 21 -- ending 25th May.

I was at DjangoCon Europe. (Good to see you there!) 

No activity. 


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/62d9ecf5-834e-48a9-a36d-b23927ec2741%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: #29433 New split template filter

[Carlton Gibson]

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.

Django bugfix release 2.0.6

[Carlton Gibson]

Details are available on the Django project weblog: 
https://www.djangoproject.com/weblog/2018/jun/01/bugfix-release/ 


-- 
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/E35B0A2E-B45C-41F6-BC8F-2838C5683B64%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Fellow Reports -- May 2018

[Carlton Gibson]

Hi all,

Calendar Week 22 -- ending 1st June.


Reviewed Patches on:

https://code.djangoproject.com/ticket/29301 -- Reorder management command 
arguments in --help output to prioritize command-specific arguments
https://code.djangoproject.com/ticket/29419 -- Document the change in 
permissions required to perform admin actions
https://code.djangoproject.com/ticket/28687 -- Add a 'Not Empty' option to 
admin's related filter
https://code.djangoproject.com/ticket/11964 -- Added support for check 
constraints in model Meta.
https://code.djangoproject.com/ticket/29452 -- makemessages command doesn't 
set .pot file charset properly
https://code.djangoproject.com/ticket/29457 -- Spaces between argument 
separator and argument in template filter generate error
https://code.djangoproject.com/ticket/29385 -- Made Admindocs 
ModelDetailView show model properties.
https://code.djangoproject.com/ticket/26067 -- Added support for ordering 
ArrayAgg and StringAgg.
https://github.com/django/django/pull/10015 -- Minor correction in 
outputting-csv.txt


Triaged:

https://code.djangoproject.com/ticket/29456 -- Django 1.11 same filter_list 
get redisplayed in different model admin page (needsinfo: did not 
reproduce.)


Released: v2.0.6. — Thanks to Tim for the help!


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/2203129b-6a7b-46bf-9496-007f0b880748%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Django bugfix releases: 2.0.7 and 1.11.14

[Carlton Gibson]

Details are available on the Django project weblog:

https://www.djangoproject.com/weblog/2018/jul/02/bugfix-releases/

-- 
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/BE021AC2-3BA7-4A58-9B00-076AF2828E0C%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP

Re: Fellow Reports -- June 2018

[Carlton Gibson]

Hi all,

Calendar Week 25 -- ending 22nd June.

Reviewed Patches on:

https://code.djangoproject.com/ticket/29504 -- JSONField dictionary/object 
lookup using an "integer" key
https://code.djangoproject.com/ticket/29503 -- Order of parameters pass to 
__in lookup affected by de-duplication.
https://code.djangoproject.com/ticket/27398 -- Make 
SimpleTestCase.assertRedirects() URL comparison ignore ordering of query 
parameters
https://code.djangoproject.com/ticket/28643 -- Complete the ORM Function 
Library
https://github.com/django/django/pull/10078 -- Updated a test example to 
use snake case
https://code.djangoproject.com/ticket/29511 -- Added charset to 
JavaScriptCatalog's Content-Type header.


Triaged:

https://code.djangoproject.com/ticket/29502 -- AutocompleteJsonView doesn't 
work if user has "view" but not "change" (Accepted: Release blocker)
https://code.djangoproject.com/ticket/29485 -- Testing with Oracle in AWS 
RDS (oracle managed files) (needsinfo)
https://code.djangoproject.com/ticket/28808 -- Allow customizing the 
fallback language (Duplicate)
https://code.djangoproject.com/ticket/29501 -- Add support for ./manage.py 
dbshell -c SQL (Accepted)
https://code.djangoproject.com/ticket/29500 -- SQLite functions crash on 
Null values (Accepted)
https://code.djangoproject.com/ticket/29508 -- Simplify overriding 
`login_form` in AdminSite (Invalid)


Authored patches on:

https://code.djangoproject.com/ticket/29449 -- UserCreationForm and 
UserChangeForm don't work if username isn't a CharField
https://github.com/django/django/pull/10059 -- Fixed #29502 -- Allowed 
autocomplete_fields to function with only view permission to related object
https://code.djangoproject.com/ticket/29467 -- override_settings context 
manager can leave undesired settings state
https://code.djangoproject.com/ticket/29514 -- Regression in 
get_default_timezone()




Calendar Week 26 -- ending 29th June.

Vacation — No activity.



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/ff49905c-7413-4920-b454-d2e9c0f2b7f9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Fellow Reports -- April 2018

[Carlton Gibson]

Hi all, 

Calendar Week 17 -- ending 27th April.

Reviewed Patches on:

https://code.djangoproject.com/ticket/8936  -- Add view (read-only) 
permission to admin
https://code.djangoproject.com/ticket/29353 -- _middleware_chain is not set 
for StaticFilesHandler
https://code.djangoproject.com/ticket/28687 -- Add a 'Not Empty' option to 
admin's related filter

Triaged:

https://code.djangoproject.com/ticket/29361 -- 
django.contrib.flatpages.urls does not have an app_name attribute (wontfix)


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/67f52335-1a88-46cf-9843-12c696a44b9f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Fellow Reports -- April 2018

[Carlton Gibson]

Hi all, 

Calendar Week 16 -- ending 20th April. 

Reviewed Patches on: 

https://code.djangoproject.com/ticket/28462 -- ModelAdmin.list_editable 
unusably slow and memory intensive with large datasets
https://code.djangoproject.com/ticket/28600 -- Add prefetch related support 
to RawQuerySet
https://code.djangoproject.com/ticket/19580 -- Unify reverse foreign key 
and m2m unsaved model querying
https://code.djangoproject.com/ticket/29175 -- makemessages doesn't parse 
ES6 template strings
https://code.djangoproject.com/ticket/29336 -- No docs for circular 
inheritance
https://code.djangoproject.com/ticket/3006  -- generic relations do not act 
as expected in a filter/get
https://code.djangoproject.com/ticket/29049 -- Add slicing notation to F 
expressions
https://code.djangoproject.com/ticket/29341 -- Automatically Set 
'request.current_app' for all Request
https://github.com/django/django/pull/9886  -- Clarified wording in 
tutorial text.

Triaged: 

https://code.djangoproject.com/ticket/29337 -- __len__ & __bool__ support 
in RawQueryset (Accepted)
https://code.djangoproject.com/ticket/29341 -- Spam filter on issues is 
insane (Spam. Oh the irony.)

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/9cf7e5d1-ed38-4252-a496-e68e5e193a23%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: improving our Contributor License Agreement process

[Carlton Gibson]

I started reviewing patches according to the check-list this morning and, 
for first-time contributors, I was wondering how to validate the CLA 
status. Tim pointed me here. 

There is now (what looks like) a viable third-party provider: 

https://cla-assistant.io

Amongst others, Microsoft use this for the VSCode project
https://github.com/Microsoft/vscode/issues/34239

(This looks better than rolling our own. Adding a CI check isn't that hard. 
There are services which do the document signing. etc. But then I take of 
the Programmer's Rosy Glasses and wince.)

Can we assess CLA assistant to see if it would fit our needs? 


If we're not going to do something like this then would it be worth making 
the assessment of dropping the CLA? (If so, how could that be made to 
happen?) 

Regards,

Carlton



On Wednesday, 28 October 2015 12:44:54 UTC+1, Tim Graham wrote:
>
> Avoiding unnecessary work appeals to me, so I think it would be great to 
> check with the lawyers before proceeding.
>
> On Tuesday, October 27, 2015 at 8:33:21 PM UTC-4, Russell Keith-Magee 
> wrote:
>>
>> Hi Tim,
>>
>> On Wed, Oct 28, 2015 at 12:50 AM, Tim Graham  wrote:
>>
>>> In 2014 I started to research if we could offer a Google Summer of Code 
>>> project aimed at improving Django's process for collecting and organizing 
>>> CLAs. I didn't complete that proposal when I found some existing solutions, 
>>> in particular https://cla.puppetlabs.com/ which Puppet labs said they 
>>> were planning to open source. Following up on that now, I couldn't find if 
>>> they ever did open source it and the contacts I found for the project (Dawn 
>>> and Jeff) no longer seem to work at the company.
>>>
>>> I wonder if anyone has a recommendation for a third-party solution to 
>>> solve this? Our requirements are roughly outlined below.
>>>
>>> Overview
>>> 
>>>
>>> The Django software foundation asks all past and future contributors to 
>>> sign a contributor license agreement [1]. Every contributor of non-trivial 
>>> amounts of code (more than just a line or two) to Django is required to 
>>> sign such a document. If somebody is unable to sign the document, their 
>>> contribution (whether it be code, or documentation, or string translations) 
>>> will be removed from Django.
>>>
>>> The CLA ensures that the Django Software Foundation (DSF) has clear 
>>> license to all its contributions, which in turns lets us guarantee to users 
>>> that we have no "stray" intellectual property or differently-licensed 
>>> material.
>>>
>>> The DSF current process for collecting CLAs involves downloading a PDF 
>>> and submitting it by mail, fax, or email. This process makes it difficult 
>>> to audit our commit history by mapping commits to CLAs.
>>>
>>> Requirements
>>> 
>>>
>>> Contributors must be able to do an online acceptance of terms and 
>>> conditions. We present our license terms, and the user puts in name, email 
>>> address, contact details etc. We validate that the email is valid (by 
>>> having them verify the email address), and we tie it to their Trac and/or 
>>> GitHub handle. This allows us to have tracing for every commit. We also 
>>> have a historical archive of physical documents, which we can use to 
>>> populate the database (obviously not with verified email addresses, but it 
>>> works for legal purposes).
>>>
>>> We've also got corporate CLAs which need to be signed by a corporate 
>>> representative, and can cover a bunch of employees (each employee's 
>>> contributions covered from a specific date).
>>>
>>> We should add a pull request check that indicates whether or not a 
>>> contributor has signed the CLA.
>>>
>>> [1] https://www.djangoproject.com/foundation/cla/
>>>
>>> Thanks for driving this.
>>
>> One option would be to do the same thing the PSF does - an Adobe eSign 
>> form:
>>
>> https://www.python.org/psf/contrib/contrib-form/
>>
>> (Or, any other analogous service).
>>
>> I’m also are of CLAHub:
>>
>> https://github.com/clahub/clahub
>>
>> It’s “CLA with github integration as a service” - but the owner has 
>> flagged that they’re in need of assistance. It’s also a Rails codebase 
>> (that’s not a reason to *not* use it -but it’s a reason that we might not 
>> be in a position to offer to take over maintenance).
>>
>> A final option - but this is one the DSF would need to pursue in 
>> conjunction with legal advice - would be to abandon the idea of CLAs 
>> altogether. There’s a growing body of opinion that they’re not necessary: 
>>
>> http://www.ebb.org/bkuhn/blog/2014/06/09/do-not-need-cla.html
>>
>> Russ %-)
>>
>>
>>
>>

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

Re: improving our Contributor License Agreement process

[Carlton Gibson]

Hey Tim. 

> It sounds like you have the enthusiasm for this that I had in 2014. ;-)

Yeah. What I liked was that your proposal was like a "I've actually thought 
about this" version of what I was beginning to ponder myself. :-)

I don't really think we should drop the CLAs. It's just that if they're not 
enforced then we don't address the issue they're meant to solve (which, if 
I understand it, is ultimately making sure companies can safely use Django 
without worrying about a withholding of rights at some key juncture.) 

So better... I thought... was if we can implement a decent, and easy, 
check. 

If the CLAs aren't really important then, well, I guess I would drop them 
(but I'm not hooked up on that — it's more a cognitive *huh?*)

@Tobias, I see your post come in whilst writing this: 

I think the permissions there is for the backend CLA-provider, rather than 
the end user. i.e. it needs those permissions for the CLA (which you host 
in a Gist) and the build status for the CI check and so on. 

This is the hosted version you're looking there. I'd imagine we'd host our 
own, so those permissions would be internal. 

I imagine looking at that to be part of any assessment. 

The individual contributor would need to grant only the Personal Data bit. 
(I need to look into exactly the levels.) The flow—reading from the VSCode 
docs—is to fork and then make a PR, as normal, if you've not submitted the 
CLA you're then prompted to do so.  

https://github.com/Microsoft/vscode/wiki/Contributor-License-Agreement

What I liked about it, is that it seemed to tick all the boxes. 


When Tim first proposed this in 2014 the summary seemed to be "Yes, we 
should do this, but it might be hard — oh, and we might not need to". 

Given that we still have the CLA, is it not still something that we should 
do? 

If not no worries. 

Regards,

Carlton






On Thursday, 11 January 2018 16:08:04 UTC+1, Tim Graham wrote:
>
> Hi Carlton,
>
> It sounds like you have the enthusiasm for this that I had in 2014. ;-)
>
> You could contact the DSF board if you want to try to get them to consult 
> a lawyer about the necessity of CLAs. I guess opinions might vary from 
> lawyer to lawyer.
>
> Given that Django has been operating for about 13 years without rigorous 
> enforcement of the CLAs, I guess I fail to see why we would need to start 
> rigorous enforcement now. Having CLAs available seems to be a good thing, 
> even if the comfort is mostly cognitive. I'm not sure what sort of legal 
> challenge Django would face where we would need CLAs. Collecting them seems 
> more an issue of purity than of practicality. I'm not a lawyer.
>
> On Thursday, January 11, 2018 at 9:27:17 AM UTC-5, Carlton Gibson wrote:
>>
>> I started reviewing patches according to the check-list this morning and, 
>> for first-time contributors, I was wondering how to validate the CLA 
>> status. Tim pointed me here. 
>>
>> There is now (what looks like) a viable third-party provider: 
>>
>> https://cla-assistant.io
>>
>> Amongst others, Microsoft use this for the VSCode project
>> https://github.com/Microsoft/vscode/issues/34239
>>
>> (This looks better than rolling our own. Adding a CI check isn't that 
>> hard. There are services which do the document signing. etc. But then I 
>> take of the Programmer's Rosy Glasses and wince.)
>>
>> Can we assess CLA assistant to see if it would fit our needs? 
>>
>>
>> If we're not going to do something like this then would it be worth 
>> making the assessment of dropping the CLA? (If so, how could that be made 
>> to happen?) 
>>
>> Regards,
>>
>> Carlton
>>
>>
>>
>> On Wednesday, 28 October 2015 12:44:54 UTC+1, Tim Graham wrote:
>>>
>>> Avoiding unnecessary work appeals to me, so I think it would be great to 
>>> check with the lawyers before proceeding.
>>>
>>> On Tuesday, October 27, 2015 at 8:33:21 PM UTC-4, Russell Keith-Magee 
>>> wrote:
>>>>
>>>> Hi Tim,
>>>>
>>>> On Wed, Oct 28, 2015 at 12:50 AM, Tim Graham <timog...@gmail.com> 
>>>> wrote:
>>>>
>>>>> In 2014 I started to research if we could offer a Google Summer of 
>>>>> Code project aimed at improving Django's process for collecting and 
>>>>> organizing CLAs. I didn't complete that proposal when I found some 
>>>>> existing 
>>>>> solutions, in particular https://cla.puppetlabs.com/ which Puppet 
>>>>> labs said they were planning to open source. Following up on that now, I 
>>>>> couldn't find if they ever did open source it and the contacts I found 
>

Re: improving our Contributor License Agreement process

[Carlton Gibson]

On Thursday, 11 January 2018 18:01:23 UTC+1, Marc Tamlyn wrote:
>
>  But I don't think we need to enforce it for any contribution.
>

OK. I think that's the key. If that's the view then we can go on as is. 

Thanks all.  

C. 

-- 
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/9f6bf434-f511-482b-a552-b92b8f14f96a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Fellow Report — January 19, 2018

[Carlton Gibson]

Hi All. 

This week I reviewed patches on: 

https://code.djangoproject.com/ticket/24747 -- Allowed transforms in 
order_by()
https://code.djangoproject.com/ticket/28977 -- Change Local Memory Cache to 
use LRU
https://code.djangoproject.com/ticket/28881 -- Documented that 
CommonPasswordValidator assumes lowercase
https://code.djangoproject.com/ticket/28403 -- Improve the example for 
FORMAT_MODULE_PATH and add missing formats
https://code.djangoproject.com/ticket/28838 -- annotations + 
base_manager_name + instance.save() raises exception
https://code.djangoproject.com/ticket/20218 -- Default authorization 
backend returns False when queried for object level permissions
https://code.djangoproject.com/ticket/28643 -- Complete the ORM Function 
Library
https://code.djangoproject.com/ticket/25790 -- Add a way to disable column 
sorting in the admin
https://code.djangoproject.com/ticket/28990 -- Added support for Hash and 
SP-Gist indexes; BrinIndex autosummarize parameter
https://code.djangoproject.com/ticket/28887
https://code.djangoproject.com/ticket/26974
https://code.djangoproject.com/ticket/28917 -- Remove paginator's unordered 
queryset warning for a .none() queryset

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/680acc99-9857-4e13-9a4d-13f43e6152f2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Default Authorization BackEnd Denying Permissions if Object Provided

[Carlton Gibson]

Hi Mehmet, 

Sorry for the slow reply. I didn't have capacity to return to this last 
week. 

> Hey Carlton ... What do you say?

Well, my first thought is that I don't see any great consensus for a change 
here.
I don't see it as **my** decision to make. 

This has been open a while, however, so...

I've used this API, with Django Guardian and without. It never occurred to 
me 
that there was a problem with ModelBackend's behaviour. 

For me the it (i.e. the docs) says:

> I don't do object permissions so I always return `False` if you ask. 

That seems clear, safe, and unambiguous. 

I see users read the API as hierarchical. Having thought about this issue,
ultimately, I think it's a misunderstanding (and so a docs issue).

I come back to Florian's point about what the right API should be? 

`user.has_perm("for.change_bar", obj=some_bar)`

What are we offering here? 
The ability to cycle through a number of backends checking permissions, 
**plus**
a (moderately) simple default permissions system. That's it. 
(We're not offering the most full-featured ACL-powered goodness. That's 
deliberate.)

Is this a good API for that? I think probably yes. 

Short of looking at ≈all the major frameworks out there and seeing what 
they 
offer instead, I don't see a ground for change. Not currently. 

I do see two ways forward: 

* A possible change to the docs: highlight what we're doing (again) 
  — provide the example of an alternate backend, with the other behaviour. 
  
* Possible backwards compatible refactoring of the authentication and 
authorization 
  roles of the authentication backends. Right now we have a class with two 
  responsibilities, so splitting that may make sense. (It may make future 
steps 
  clearer.) I think that would need to be done piecemeal and in PRs, with 
tests 
  and docs etc to be sensibly assessed. (It's impossible to assess code on 
the 
  mailing list, at least for me.)
  
Given the scope of the permissions system, I'm not convinced we need to 
make an 
actual code change here. (i.e. I'm not convinced about need for the second 
refactoring part.) The goal is to provide a simple but extensible system. 
We 
have that. I don't see any limitation that can't be worked around in user 
code 
if it doesn't suit. 

For me, I'd close as won't fix.
https://code.djangoproject.com/ticket/20218

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/1fb3ac66-8d78-4393-b3ca-83cba330bccf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Fellow Report -- January 26, 2018

[Carlton Gibson]

Hi All. 

This week I reviewed patches on:

https://code.djangoproject.com/ticket/25790 -- Added option to disable 
column sort in admin changelist
https://code.djangoproject.com/ticket/20118 -- Default authorization 
backend returns False when queried for object level permissions
https://code.djangoproject.com/ticket/28403 -- Improve the example for 
FORMAT_MODULE_PATH and add missing formats
https://code.djangoproject.com/ticket/28784 -- Re-phrased the documentation 
for the fake option in migrate command
https://code.djangoproject.com/ticket/28748 -- Made CharField choices' 
check stricter
https://code.djangoproject.com/ticket/8500  -- Allowed overriding the 
default admin site instance.
https://code.djangoproject.com/ticket/27728 -- Allowed overriding admin 
templatetag's templates
https://code.djangoproject.com/ticket/28977 -- Change Local Memory Cache to 
Use LRU
https://code.djangoproject.com/ticket/28838 -- annotations + 
base_manager_name + instance.save() raises exception
https://code.djangoproject.com/ticket/25718 -- Allowed using None as a 
JSONField lookup value.
https://code.djangoproject.com/ticket/9475  -- Allowed add(), create(), etc 
for m2m with through
https://code.djangoproject.com/ticket/29059 -- ChoiceWidget.optgroups() 
doesn't group choices without a group together

I also looked (briefly) at the release blocker: 

https://code.djangoproject.com/ticket/28944 -- Chaining 
values()/values_list() after QuerySet.select_for_update(of=()) crashes

... but needed much more time than I thought reasonable to say anything 
sensible.


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/60ff98a6-b17d-41fb-a733-53e056347301%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Default Authorization BackEnd Denying Permissions if ObjectProvided

[Carlton Gibson]

Hi. 

@Andrew: I'll look at your post anon, as it's longer. 

On Wednesday, 17 January 2018 20:46:27 UTC+1, Mehmet Dogan wrote:
>
> Can you give an example of what you mean by option 3. 
>

Well, I don't a concrete suggestion in mind, but the general idea would be 
to have ModelBackend proxy to another class (a Strategy ?) that did the 
actual permission check. 

We'd then have (at least) two versions: one with the current 
implementation, and one with the alternative. 

Exactly how the user would configure which version to use (etc) would need 
thinking about. 

The question is whether it's worth the price of admission, vs just, say, 
subclassing ModelBackend. 

C.

-- 
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/fc4b4544-dd15-4672-8a5b-27e9bcb7d4a9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Default Authorization BackEnd Denying Permissions if Object Provided

[Carlton Gibson]

Hi Mehmet, 

Due to the BC issues, this is fairly in-depth. 

Having looked at the history, here are my initial thoughts. 



The initial issue here is this behaviour from `ModelBackend`:

```
user.has_perm('foo.change_bar', obj)
False
user.has_perm('for.change_bar')
True
```

Although the long-standing behaviour, this is considered _unexpected_.

Ticket is: https://code.djangoproject.com/ticket/20218

There are two related tickets regarding permission-checking in the Admin:

* https://code.djangoproject.com/ticket/13539
* https://code.djangoproject.com/ticket/11383

Currently, I see three options:

1. Close as "Won't Fix", perhaps with a review of the documentation to see 
if we
   can't clarify/emphasise the behaviour somewhere.

This is the path of least resistance. It conforms to the original design
decision. It preserves the long-standing behaviour. (Whilst, yes, some 
find the
behaviour unexpected, it has a sense; it just depends how you look at 
it.)

The objection is to this kind of check:

if user.has_perm('foo.change_bar', obj=bar) or 
user.has_perm('foo.change_bar'):
...

* Whilst, granted, it's a little clumsy, there's no reason this 
couldn't be
  wrapped in a utility function. (There's a suggestion to that effect 
on the
  Django-Guardian issue tracker[^1]. This seems like a good idea, 
simple enough
  to live in user code.)
* `ModelBackend` permission lookups are cached[^2] so the performance 
worry
  here should be negligible.

2. Implement the (straight) backwards incompatible change.

The difficulty here is (we guess) why this ticket has been open so long.

If we are convinced this is the right way to go — i.e. that the current
behaviour is in fact **wrong** — then we should go ahead despite the
difficulty.

Working out what that entails is non-trivial. That's why it needs a 
decent
discussion and consensus here.

Which leads to...

3. Break out the permissions aspect of `ModelBackend` in order to make it 
   pluggable in some way. Then allow users to opt-in to a new version with 
the 
   adjusted behaviour.
   
   There is some discussion of this on one of the related tickets[^3].
   
   Again, exactly what the migration path is needs some planning. 

I'm not sure what the correct answer is. 

[^1]: https://github.com/django-guardian/django-guardian/issues/459
[^2]: 
https://docs.djangoproject.com/en/2.0/topics/auth/default/#permission-caching
[^3]: f.f. https://code.djangoproject.com/ticket/13539#comment:16


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/cab981b8-7dc7-4e9d-9dcc-442b36820cdf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Fellow Report — January 12, 2018

[Carlton Gibson]

On Wednesday, 17 January 2018 00:34:11 UTC+1, Josh Smeaton wrote:
>
> Welcome, and nice work! I've seen some of the reviews you've made and 
> you're straight into the deep end.
>

Thanks Josh. Too deep maybe  — but yes. 

I'm just happy to be able to work on Django. It's given me SO much. 

Right, to work...  

-- 
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/30d212d8-61ca-4eb1-b7e1-3f3fd08573d5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Default Authorization BackEnd Denying Permissions if Object Provided

[Carlton Gibson]

Hi Florian, 

I was hoping you'd post. You've been active on the entire (very-long) 
history of this issue. 

Can I ask for your take? 

Given your comment, would it be along the lines of "Close as "Won't Fix", 
perhaps with a review of the documentation", to point users to subclassing 
ModelBackend if they need the alternate behaviour?

Thanks!

Kind Regards,

Carlton


On Wednesday, 17 January 2018 19:45:06 UTC+1, Florian Apolloner wrote:
>
> On Wednesday, January 17, 2018 at 5:48:03 PM UTC+1, Mehmet Dogan wrote:
>>
>> Florian,
>>
>> Can you clarify this part, I am not sure what you meant:
>>
>
>
> class MyBackend(ModelBackend):
>
>def has_perm(…, obj=None,…):
>  if obj: obj = None
>  return super().has_perm(…)
>
> something along the lines of this should do 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/0f326294-a59d-41dc-bdd7-4d3ed85acf4f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: New contributor to Django with a ticket in mind

[Carlton Gibson]

Hi Jatin, Welcome! 

> Can I take this up from scratch?

I think the short answer there is going to be Yes :-)

The history on that ticket is long. (There's the issue over updating 
primary keys vs how those are handled in the Admin; either seems 
legitimate.) 

Once you have an idea it might be worth summarising the issue, with your 
suggestion, here to get some input. 

The first step beyond that would be tests showing exactly the issue you'll 
be fixing. (There were some patches uploaded; I don't know if they're still 
current.) 

I hope that helps. 

Kind Regards,

Carlton





On Monday, 15 January 2018 07:22:57 UTC+1, Jatin wrote:
>
> Hello everyone, 
>I have been a long time user of Django and figured I could 
> probably contribute a little back to the project by contributing some code. 
>
> Is it possible for me to take up this ticket? 
> https://code.djangoproject.com/ticket/2259
>
> I see this was opened quite a while back and has a Pull Request that was 
> closed because of a regression issue. Can I take this up from scratch?
>
> Thanks
> Jatin
>
>

-- 
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/2aae444b-c90a-4671-a9f7-3b7de02f6b27%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Fellow Report — January 12, 2018

[Carlton Gibson]

Hi all, 

With help from Tim, Aymeric and Frank, I got started on the fellowship this 
week. 
(Thank you all!)


I've Reviewed Patches on: 

https://code.djangoproject.com/ticket/24747 -- Allowed transforms in 
QuerySet.order_by()
https://code.djangoproject.com/ticket/29002 -- Corrected cached template 
loader docs about when it's automatically enabled

https://code.djangoproject.com/ticket/28977 -- Change Local Memory Cache to 
Use LRU
https://code.djangoproject.com/ticket/29004 -- Add optional database view 
support to inspectdb
https://code.djangoproject.com/ticket/28761 -- Document prefixes in 
InlineFormsets
https://code.djangoproject.com/ticket/28885 -- Bottom parts of 
"Congratulations!" page cut off internationalized content


I'm still finding my feet (exactly how things are done etc) so all input is 
welcome and appreciated (!!!)

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/f2966dae-a157-4916-85a4-cf6c99a27893%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Fellow Report -- February 5, 2018

[Carlton Gibson]

Hi all, 

Last week I reviewed patches on

https://code.djangoproject.com/ticket/29076 -- Changed .refresh_from_db() 
to clear cached relationships.
https://code.djangoproject.com/ticket/29036 -- Changed SelectDateWidget's 
empty value
https://code.djangoproject.com/ticket/29082 -- Make the test client 
automatically encode JSON data
https://github.com/django/django/pull/9649  -- Fixed imports per isort 
4.3.0.
https://code.djangoproject.com/ticket/28835 -- Made development server 
shutdown on SIGTERM
https://code.djangoproject.com/ticket/27795 -- Audit force_text invocations
https://github.com/django/django/pull/9648
https://github.com/django/django/pull/9652
https://code.djangoproject.com/ticket/25718 -- Allowed using None as a 
JSONField lookup value.
https://github.com/django/django/pull/9651  -- Simplified aggregation.tests.
https://code.djangoproject.com/ticket/29059 -- Made 
ChoiceWidget.optgroups() group non-grouped choices in null group.
https://code.djangoproject.com/ticket/27999 -- Add test Client support for 
HTTP 307 and 308 redirects
https://code.djangoproject.com/ticket/27398 -- Make 
SimpleTestCase.assertRedirects() URL comparison ignore ordering of query 
parameters

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/9716cab5-ea4a-44d3-8224-e8e9386f2398%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ticket 28404

[Carlton Gibson]

Hi Collin, 

Thanks. That's perfect. 

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/f8b67e70-b290-4272-b26a-dd2928be2bb0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Method for allowing different `MAIL FROM` or `Return-Path` and `From` headers.

[Carlton Gibson]

Hi Ian, 

As you describe it here, this sounds quite reasonable. It seems worth a 
Trac ticket. 

* We need `Return Path` because ...
* Currently possible but ...
* Either document or add new `return_path` parameter. 

My initial thought is that a `Note` block in the docs explaining the 
approach from the original ticket may be enough here. 

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/2b20f5d9-d386-425a-bebd-e2b344556386%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Fellow Report -- February 12, 2018

[Carlton Gibson]

Hi all. 

Last week I reviewed patches etc on the following tickets: 

https://code.djangoproject.com/ticket/27728 -- Allowed overriding admin 
templatetag's templates.
https://code.djangoproject.com/ticket/25790 -- Add a way to disable column 
sorting in the admin
https://code.djangoproject.com/ticket/29115 -- Allow rendering of admin 
forms with Jinja2
https://code.djangoproject.com/ticket/28933 -- Implement a range-based 
filter for Django Admin date_hierarchy
https://code.djangoproject.com/ticket/28404 -- Django admin 
empty_value/empty_value_display doesn't check for empty strings
https://code.djangoproject.com/ticket/9214  -- Allow different `MAIL FROM` 
or `Return-Path` and `From` headers.
https://github.com/django/django/pull/9676  -- Fixed typo in 
docs/ref/models/querysets.txt. + Backport
https://code.djangoproject.com/ticket/28635 -- Admin's preserved filters 
don't work if the URL has non-ASCII characters in it
https://code.djangoproject.com/ticket/27810 -- Add query expression support 
for ModelAdmin list_display's admin_order_field
https://code.djangoproject.com/ticket/17962 -- Add 
ModelAdmin.get_deleted_objects() hook
https://code.djangoproject.com/ticket/29106 -- Make manage.py test display 
the test tags that are in use
https://code.djangoproject.com/ticket/23718 -- TEST_MIRROR setting doesn't 
work as expected (and has no tests)
https://code.djangoproject.com/ticket/28917 -- Remove paginator's unordered 
queryset warning for a .none() queryset
https://code.djangoproject.com/ticket/28835 -- Development server doesn't 
shut down on SIGTERM
https://code.djangoproject.com/ticket/28712 -- Add ability to apply 
separate attributes to ChoiceWidget options

For those following along, my current focus is on the "Patches needing 
review"
backlog. https://dashboard.djangoproject.com/metric/patches/

The idea here is that I can give Tim a shorter list of "Ready for checkin" 
patches
to review whilst I'm sharpening my eye for issues such as patch style and 
other gotchas. 

I'll move into other areas once the backlog is reduced some more. 

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/3cad2c9c-42b4-427e-9009-b703e994d427%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Connection or integration Between two Apps in djnago 2.0

[Carlton Gibson]

Hi. 

This list is for contributions to Django. For usage questions please post 
to Django Users. 

https://groups.google.com/forum/#!forum/django-users

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/21558613-04d8-4013-be8e-cb1c7272b6f8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ticket 28404

[Carlton Gibson]

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

Fellow Report -- February 19, 2018

[Carlton Gibson]

Hi All, 

Last week I reviewed patches (etc) on: 

https://code.djangoproject.com/ticket/21381 -- Remove contrib.redirects 
dependency on contrib.sites
https://code.djangoproject.com/ticket/18937 -- Use modern Python packaging 
metadata standard (1.2, PEP 345)
https://code.djangoproject.com/ticket/24270 -- Wheel package does not 
contain 'extras' directory
https://code.djangoproject.com/ticket/28905 -- Overhaul extra_requires to 
include more optional dependencies
https://code.djangoproject.com/ticket/27449 -- Make 
django.utils.translation.trans_real.get_supported_language_variant public 
API
https://code.djangoproject.com/ticket/25718 -- Can’t use queries with JSON 
’null’ values with JSONField
https://code.djangoproject.com/ticket/29115 -- Allow rendering of admin 
forms with Jinja2
https://code.djangoproject.com/ticket/17962 -- Add 
ModelAdmin.get_deleted_objects() hook
https://code.djangoproject.com/ticket/28379 -- Fix redirect loop in 
AccessMixin if a user lack permission
https://code.djangoproject.com/ticket/28690 -- 
django.utils.http.parse_http_date two digit year check is incorrect
https://code.djangoproject.com/ticket/27810 -- Add query expression support 
for ModelAdmin list_display's admin_order_field
https://code.djangoproject.com/ticket/17379 -- Don't deactivate 
translations by default in management commands
https://code.djangoproject.com/ticket/28048 -- Allow generic date views to 
use related fields as date_field
https://code.djangoproject.com/ticket/26291 -- Allowed loaddata to handle 
forward references in natural_key fixtures.

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/6fff6b5d-77ae-4ae7-b48d-3c2aae85c21e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Fellow Report -- February 26, 2018

[Carlton Gibson]

Hi all, 

Last week I reviewed patches on the following tickets: 

https://code.djangoproject.com/ticket/27449 -- Added 
get_supported_language_variant to public API
https://code.djangoproject.com/ticket/28755 -- 
django.utils.translation.check_for_language doesn't check in the app folders
https://code.djangoproject.com/ticket/17962 -- Added 
ModelAdmin.get_deleted_objects() hook
https://code.djangoproject.com/ticket/27728 -- Allowed overriding admin 
templatetag's templates.
https://code.djangoproject.com/ticket/29135 -- get_object_or_404() and 
get_list_or_404() swallow AttributeError in queryset filtering
https://code.djangoproject.com/ticket/28398 -- Allow management command 
invocation to suggest commands for mistyped commands
https://code.djangoproject.com/ticket/17379 -- Don't deactivate 
translations by default in management commands
https://code.djangoproject.com/ticket/25718 -- Can’t use queries with JSON 
’null’ values with JSONField
https://code.djangoproject.com/ticket/29132 -- update_last_login signal 
handler shouldn't be connected if User.last_login attribute isn't a field
https://code.djangoproject.com/ticket/22449 -- Colorize output of test 
results
https://code.djangoproject.com/ticket/28690 -- 
django.utils.http.parse_http_date two digit year check is incorrect
https://code.djangoproject.com/ticket/11974 -- Submit_row in admin doesn't 
follow the pattern of using admin/app_label/model/submit_line.html
https://code.djangoproject.com/ticket/21076 -- Offer the ability to store a 
hash of session IDs rather than the ID itself
https://code.djangoproject.com/ticket/18620 -- Prefer current Site when 
checking M2M in "shortcut"/"view_on_site" redirect
https://code.djangoproject.com/ticket/28988 -- Multi-table inheritance 
breaks GenericRelation querying


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/a48e2d75-6396-4e28-90a0-47e6b0efebbf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Fellow Reports -- July 2018

[Carlton Gibson]

Hi all,


Calendar Week 30 -- ending 29 July.


Triaged:

https://code.djangoproject.com/ticket/29598 -- 
contrib.postgres.FloatRangeField should be renamed DecimalRangeField 
(Accepted)
https://code.djangoproject.com/ticket/29599 -- chunk_size for 
InMemoryUploadedFile is not used (Invalid)
https://code.djangoproject.com/ticket/29593 -- Removal of QUERY_TERMS is 
not in 2.1 "features removed" page (Accepted)


Reviewed:

https://code.djangoproject.com/ticket/29243 -- Improve efficiency of 
migration graph algorithm
https://code.djangoproject.com/ticket/28581 -- Pagination topic docs need a 
little restructuring
https://code.djangoproject.com/ticket/29589 -- Insert a new method 
part_page_range for class Page in django.core.paginator.py
https://code.djangoproject.com/ticket/26891 -- ForeignObject/ForeignKey 
does not obey lookup registration API
https://code.djangoproject.com/ticket/26184 -- Allow using custom lookups 
and transforms in ModelAdmin.search_fields
https://code.djangoproject.com/ticket/13091 -- admin list_editable with 
unique_together raises Integrity Error


Authored:

https://github.com/django/django/pull/10227 -- Fixed #29593 -- Added 
QUERY_TERMS removal to v2.1 release notes.
https://github.com/django/django/pull/10216 -- Refs #13091 -- Added test 
for commit=False idiom with partial unique_together validation.



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/8ced471b-13a9-4289-b820-4c686fb8dec1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Help wanted testing proposal for the Migration Graph algorithm

[Carlton Gibson]

Hi all.

Do you have a project with a slow and complicated migration history?

If so, any chance you could lend a brief hand testing?

See https://github.com/django/django/pull/9804 

This refactors the migration graph algorithm and in principle should make 
it significantly faster. 
(More or less linear vs currently exponential.)

Two questions: 

1. Is it correct with very complicated histories?
2. Is it a lot quicker? 

To answer this could you profile the following script on your complicated 
project against the PR vs against master
(or any recent version of Django really)?

Are there any errors with the PR that you don't see otherwise? 
What's the speedup, if any?

Thanks for your help! 

Kind Regards,

Carlton



The scipt: 
===

All it does is calculate the full forwards and backwards migration plan for 
each app in your project. It doesn't apply anything. 

Dev environment should be fine. (It's the migrations, not the applied state 
that's in play.) 

As ever, please read it before running it. You can do anything similar if 
you want.

I used IPython from `django-admin shell`: 

%timeit %run ./migration_graph_timing.py 

If that doesn't work for you and you want me to make it actually run as a 
stand-alone, let me know. 


import sys

from django.db import connection
from django.db.migrations.loader import MigrationLoader

loader = MigrationLoader(connection)

backwards = loader.graph.root_nodes()
forwards = loader.graph.leaf_nodes()

print('Calculating backward plans:')
for root in backwards:
loader = MigrationLoader(connection)
sys.stdout.write('.')
#print(loader.graph.backwards_plan(root))
sys.stdout.write('\n')
print('Calculating forward plans:')
for leaf in forwards:
loader = MigrationLoader(connection)
sys.stdout.write('.')
# print(loader.graph.forwards_plan(leaf))

sys.stdout.write('\nRun Done\n\n')


-- 
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/1632a574-e13d-467c-b0b7-22085f3920ab%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Fellow Reports -- July 2018

[Carlton Gibson]

Hi all,

Calendar Week 28 -- ending 15th July.

Reviewed:

https://github.com/django/django/pull/10151 -- Add check for type of 
ALLOWED_HOSTS
https://code.djangoproject.com/ticket/28598 -- BCC addresses are ignored in 
the console and file email backends
https://code.djangoproject.com/ticket/20147 -- Provide an alternative to 
request.META for accessing HTTP headers
https://github.com/django/django/pull/10164 -- Fixed unclosed test files to 
avoid ResourceWarning
https://code.djangoproject.com/ticket/29557 -- Add on_commit decorator
https://github.com/django/django/pull/10172 -- Added asserts for all 
warnings in deprecation tests.
https://code.djangoproject.com/ticket/29198 -- Add a "--plan" option to the 
migrate command.
https://code.djangoproject.com/ticket/29478 -- cached_property decorator 
doesn't work with mangled method names.
https://code.djangoproject.com/ticket/29528 -- Invalid URLs passing 
validation by URLValidator.


Triaged:

https://code.djangoproject.com/ticket/29552 -- Path for 'commands' is 
incorrect in pt-BR docs (Accepted. Fixed on Transifex.)
https://code.djangoproject.com/ticket/29542 -- Annotated field created by 
subquery, referenced inside of F() generates invalid SQL (Accepted)
https://code.djangoproject.com/ticket/29534 -- Use rlwrap if available for 
oracle backend dbshell (Accepted)
https://code.djangoproject.com/ticket/29558 -- Request for more information 
on past versions of django (Invalid)
https://code.djangoproject.com/ticket/29522 -- Make Serializers easier to 
modify (Accepted)
https://code.djangoproject.com/ticket/29560 -- Add an option to 
django-admin to always colorize output (Accepted)
https://code.djangoproject.com/ticket/29557 -- Add on_commit decorator 
(wontfix)
https://code.djangoproject.com/ticket/29565 -- syntax error with Python 3 
on 1.11 (wontfix)
https://code.djangoproject.com/ticket/29561 -- Window Function Lag/Lead 
supported on Filter (Not equal) for FloatField (Invalid:Usage question)



Calendar Week 29 -- ending 22 July.

Reviewed:
 --
https://github.com/django/django/pull/10187 -- Fixed django/http/request.py 
docstring typo.
https://code.djangoproject.com/ticket/28917 -- Remove paginator's unordered 
queryset warning for a .none() queryset
https://code.djangoproject.com/ticket/29572 -- Use pymysql instead of 
mysqldb…
https://code.djangoproject.com/ticket/29528 -- Made URLValidator reject 
invalid characters in the username and password
https://code.djangoproject.com/ticket/26819 -- Using a ArrayField on 
Meta.unique_together throws "unhashable type: 'list'" on validate_unique 
method
https://code.djangoproject.com/ticket/29198 -- Add a "--plan" option to the 
migrate command 
https://code.djangoproject.com/ticket/29467 -- Made override_settings 
handle errors in setting_changed signal receivers
https://code.djangoproject.com/ticket/29570 -- Add check that MEDIA_URL is 
not inside STATIC_URL.


Triaged:

https://code.djangoproject.com/ticket/29425 -- Auto language redirect does 
not work if prefix_default_language=False in root URLConf (needsinfo)
https://code.djangoproject.com/ticket/29573 -- Add link from per-item 
aggregation topic discussion to `annotate()` ref. (Accepted)
https://code.djangoproject.com/ticket/29578 -- Django 2.1b and 2.1rc1 put 
thousand separator in _selected_action field containing id (Accepted)
https://code.djangoproject.com/ticket/29579 -- Objects count after Many to 
many related query shows wrong (needsinfo)


Authored:
https://github.com/django/django/pull/10194 -- Document changes to file 
upload permissions in Django 1.11


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/859cf89c-853d-4adb-a48c-1c6ccfeefb64%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: HTML5 and XHTML5 documents

[Carlton Gibson]

Hi Nils. 

> ... and an issue (#29681), which was 
prematurely closed as wontfix. 

As per the when you already re-opened #29038 on this issue, there now needs 
to be a consensus here before 
we can (or will) consider a new ticket for this. That's not "premature" — 
it's just how the project management of 
Django works. The mailing list allows a wider discussion on issues that 
have previously been resolved. 
I ask you to respect that. 

The PR: https://github.com/django/django/pull/10308

Only half-joking, the diff here makes me want to weep. For me, 150 files 
and 1803 line changes is just too much to 
enforce something that is of minority appeal. 

On XHTML5 generally, I have no problem with properly closing tags, and I 
guess `/>` if you must but I look at `checked="checked"` and my personal 
response is that I just don't want that. 

I understand the benefits of XML but I think trying to enforce it in a web 
framework in 2018 and beyond is skating to where the puck was, so to speak. 
Developers expect HTML5 and it we don't go with that as a default every PR 
that comes in will need "correcting" for the XML syntax, and we'll end up 
with a 10:1 increase in new issues asking why we're not taking advantage 
the new, more concise, syntax. 

You want to serve the pages you generate with XHTML. Fine. (Beyond custom 
widget templates what do you need?) But (from the PR) why do we need to 
serve (e.g.) the Admin so? Or have the examples in the docs (and code 
comments) be XHTML compliant? Or the template we use to test the email 
sending functionality? (I appreciate you probably scripted these changes.)

Does it really matter if framework provided pages use HTML5? Why? (If it 
does matter can you not warp a middleware around HTML Tidy, or similar, to 
do the conversion for you?)

If there are barriers to you creating XHTML pages, we can look at those, 
but I'd be -1 on bringing it back framework wide. 

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/ba8245ff-85b4-4369-8504-eb080136d238%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Discussion: ModelForms not allowing unbounded RangeField values

[Carlton Gibson]

Hey James, 

Thanks for your follow-up here. 

I think for me the thing that's compelling is the flow you describe in comment 
12 :

* A user renders an unbound model form, where all model fields have 
defaults. 
* The form is pre-filled with the default values. 
* The form is submitted without changes. (The default values are submitted.)
* A new model instance is created with the defaults in place. 

*Except* that doesn't work with range fields. 

In your case, where you've specified a default (and null=False) it makes 
sense that the form field would return
a `self.range_type(None, None)` rather than None here. 

What I'm not sure about is whether that always makes sense? 

What if I don't define that default on the model field? What if I want 
`None`? 

forms.CharField will always return it's empty_value here (by default `''`) 
but this is independent of the model default. 

Q: Do we want the same sort of behaviour for (forms) RangeFields? 
(Possibly we do...?)


C.

-- 
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/cc76cfb5-39d9-4bee-8a00-6764855eb5c0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Fellow Reports -- August 2018

[Carlton Gibson]

Hi all,


Calendar Week 31 -- ending 05 August.


Triaged:

https://code.djangoproject.com/ticket/29632 -- After migrating a Django 
project from Python 2 to 3, db migration of django.contrib.sites fails with 
TypeError: attribute name must be string, not bytes (needsinfo)
https://code.djangoproject.com/ticket/29631 -- Feature Request: 
models.UniqueBooleanField() (wontfix)
https://code.djangoproject.com/ticket/29620 -- Document possible 
performance benefits from transactions (needsinfo)
https://code.djangoproject.com/ticket/29626 -- cache.backends.db does not 
implement delete_many() (Accepted)
https://code.djangoproject.com/ticket/29618 -- using query parameters to 
filter by boolean causes validation error due to lower)ase true/false 
(Invalid - Usage question.
https://code.djangoproject.com/ticket/22296 -- m2m_changed pk_set value 
inconsistent between post_add and post_remove (Duplicat) of #29615
https://code.djangoproject.com/ticket/29615 -- Document difference in 
behaviour between m2m_changed behaviour for add() vs remove() when called 
multiple times. (Accepted)



Reviewed:

https://code.djangoproject.com/ticket/29623 -- DurationField 
ValidationError message should use proper gettext variables
https://github.com/django/django/pull/9424 -- Fixed #26974, #28887, #28990, 
#29614 -- Added support for B-Tree, Hash and SP-Gist indexes; BrinIndex 
autosummarize parameter.
https://github.com/django/django/pull/10251 -- Translations for 2.1.x
https://code.djangoproject.com/ticket/25513 -- Refactor the admin paginator 
customizations to make them reuseable



Authored:

https://github.com/django/django/pull/10250 -- [2.1.x] Updated translations 
from Transifex



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/ce22b1f0-7ed6-4359-9cee-10809292b285%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Fellow Reports -- August 2018

[Carlton Gibson]

Hi all,


Calendar Week 32 -- ending 12 August.


Triaged:

https://code.djangoproject.com/ticket/29649 -- admin readonly_fields with 
unique_together raises IntegrityError (Duplicate of #13091)
https://code.djangoproject.com/ticket/29643 -- Hashing list in Q objects 
when using __in lookup (needsinfo)
https://code.djangoproject.com/ticket/29642 -- Add check for signatures of 
custom error views. (Accepted)
https://code.djangoproject.com/ticket/29641 -- Add support for unique 
constraints to Meta.constraints (Accepted)
https://code.djangoproject.com/ticket/29640 -- Document (deprecate?) 
Paginator._get_page (Accepted.)


Reviewed:

https://code.djangoproject.com/ticket/29653 -- Using 
GenericRelation.related_query_name through an inherited abstract class 
crashes
https://code.djangoproject.com/ticket/29644 -- String representation of 
SearchQuery gives inaccurate results
https://code.djangoproject.com/ticket/29612 -- Add prefetch_related() cache 
invalidation for GenericRelations
https://github.com/django/django/pull/10259 -- added VSTS hosted CI
https://code.djangoproject.com/ticket/28661 -- Auto-truncate indexes on 
MySQL when max index size is reached
https://code.djangoproject.com/ticket/28598 -- BCC addresses are ignored in 
the console and file email backends



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/13bce8c2-7f2b-42bf-a006-5dbf99a51ba8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: #24483 fix breaks dynamic choices

[Carlton Gibson]

It's not clear from your OP what you mean by "dynamic choices" (I can still 
provide a callable; is that not "dynamic"?) 

Your best bet it to draw up a reproducible example (or even better a test 
case) of exactly the behaviour that used to work but now doesn't. 
I'd suggest putting that in a new Trac ticket referencing #24483. 

Then we've got something concrete to go on. 

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/0ede9c71-5946-4f85-abc5-e1073647438e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Help wanted testing proposal for the Migration Graph algorithm

[Carlton Gibson]

Thanks Jeff. Super. 

(PR is fine )

-- 
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/47b62016-c689-41fe-a66f-d64b8b43e711%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: HTML5 and XHTML5 documents

[Carlton Gibson]

Hi Nils. 

Tim's original advice still stands: 

> Have you tried creating custom widget templates for XHTML?
> https://docs.djangoproject.com/en/stable/ref/forms/renderers/

Once you have widget templates in place, if there are particular issues you 
are facing we can consider them 
but the summary here seems to be that there's little desire to do anything 
further. 

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/7edb2e61-db12-44b9-bedf-f06addf0f1e1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Help wanted testing proposal for the Migration Graph algorithm

[Carlton Gibson]

Making the script less noisy here I commented out the actual work.
(So it didn't function as a test.) 
(No comment. )

Corrected version:

```
import sys

from django.db import connection
from django.db.migrations.loader import MigrationLoader

loader = MigrationLoader(connection)

backwards = loader.graph.root_nodes()
forwards = loader.graph.leaf_nodes()

print('Calculating backward plans:')
for root in backwards:
loader = MigrationLoader(connection)
sys.stdout.write('.')
plan = loader.graph.backwards_plan(root)
#print(plan)
sys.stdout.write('\n')
print('Calculating forward plans:')
for leaf in forwards:
loader = MigrationLoader(connection)
sys.stdout.write('.')
plan = loader.graph.forwards_plan(leaf)
# print(plan)

sys.stdout.write('\nRun Done\n\n')

```

-- 
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/981a90ea-fa4a-4c6f-8e78-198d5a3751a1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GDPR and parent domain cookies

[Carlton Gibson]

Hi Vasili and Micheal. 

I misread `SafeExceptionReporterFilter` as implementing the key 
`ExceptionReporter` method. 

I totally agree with the assessment. Have reopened and Accepted on that 
basis. 

Good work! Thank you! 

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/fa8b4740-9b18-475a-aac0-a173dc70d5b4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Carlton Gibson]

Hi Philip. 

This is unlikely(!!!) to be changed. As it says on the ticket, it's 
considered a feature, not a bug. 

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. 

Having said all that, I think a lot of people new to Django get up and 
running, and well beyond that, 
without ever knowing that `getList()` exists. (I guess they discover it, 
with Google/StackOverflow, first 
time they need it.) 

A quick scan of the tutorial and docs suggests that `getList()` is probably 
under-documented. (It appears just twice in `request-response.txt`.) 
Maybe an addition to the beginning of the QueryDict section 
 
demonstrating 
the basic use-cases would be a good addition.

Kind Regards,

Carlton



On Thursday, 19 July 2018 08:19:34 UTC+2, Philip Lee wrote:
>
> I was trapped by the behavior of `QueryDict.get(_key_, _default=None_)` 
> for a bit while before consulting the documentation , for that *If the key 
> has more than one value, it returns the last value.*
> So as for  multiple values for the same key,  is returning the last value 
> of key more often expected than returning all the values of the key(that is 
> the behavior of `QueryDict.getlist(_key_, _default=None_)` right now)?  If 
> not, I'd suggest to change the behavior of `QueryDict.get(_key_, 
> _default=None_)` to return all the values of the same key for a natural 
> usage so that avoid confusing problems caused by the current behavior like 
>
> https://stackoverflow.com/questions/50044626/querydict-returning-strange-value-in-django
> https://code.djangoproject.com/ticket/1130 
>
>

-- 
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/7718573c-e380-4158-afa0-4fd37eb03154%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django bugfix release: 2.1.1

[Carlton Gibson]

Hi Paulo

It looks like there's something going wrong with your pip: 

The install works correctly and PyPI is showing 2.1.1 as the latest 
version. 

https://pypi.org/project/Django/



```
Last login: Sun Sep  2 00:07:29 on ttys001
~/ve $ mktmpenv 
New python executable in /Users/carlton/ve/tmp-a4084573c79e645/bin/python3.6
Also creating executable in /Users/carlton/ve/tmp-a4084573c79e645/bin/python
...
This is a temporary environment. It will be deleted when you run 
'deactivate'.
(tmp-a4084573c79e645) ~/ve/tmp-a4084573c79e645 $ pip install Django==2.1.1 
--no-cache-dir
Collecting Django==2.1.1
  Downloading 
https://files.pythonhosted.org/packages/ca/7e/fc068d164b32552ae3a8f8d5d0280c083f2e8d553e71ecacc21927564561/Django-2.1.1-py3-none-any.whl
 
(7.3MB)
100% || 7.3MB 5.2MB/s 
Collecting pytz (from Django==2.1.1)
  Downloading 
https://files.pythonhosted.org/packages/30/4e/27c34b62430286c6d59177a0842ed90dc789ce5d1ed740887653b898779a/pytz-2018.5-py2.py3-none-any.whl
 
(510kB)
100% || 512kB 4.0MB/s 
Installing collected packages: pytz, Django
Successfully installed Django-2.1.1 pytz-2018.5
```

Kind Regards,

Carlton



On Saturday, 1 September 2018 17:30:46 UTC+2, Paulo Maciel wrote:
>
> pip install Django==2.1.1
> Could not find a version that satisfies the requirement Django==2.1.1
>
> Em sexta-feira, 31 de agosto de 2018 05:52:28 UTC-3, Carlton Gibson 
> escreveu:
>>
>> Details are available on the Django project weblog: 
>>
>> https://www.djangoproject.com/weblog/2018/aug/31/bugfix-release/ 
>>
>

-- 
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/fd173074-0eed-45d4-963a-c8bdd3d82134%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Fellow Reports -- August 2018

[Carlton Gibson]

Hi all,


Calendar Week 35 -- ending 31 August.


Triaged:

https://code.djangoproject.com/ticket/29723 -- Backwards-incompatible 
change of has_add_permission in 2.1 (Accepted.)
https://code.djangoproject.com/ticket/29714 -- Option to hide cookies in 
error reports (Accepted.) 
https://code.djangoproject.com/ticket/29711 -- One can use as actions 
functions generated only by the first call to another function (Invalid.)


Reviewed:

https://github.com/django/django/pull/10357 -- Fix backwards incompatible 
release note location
https://github.com/django/django/pull/10356 -- Replace snippet:: with 
code-block::
https://github.com/django/django/pull/10355 -- Fixed #29723 -- Fixed crash 
if InlineModelAdmin.has_add_permission() doesn't accept the obj argument.
https://github.com/django/django/pull/10352 -- converted all single line 
comments to multiple line comments
https://github.com/django/django/pull/10342 -- Fixed LayerMapping encoding 
in geodjango tutorial.
https://github.com/django/django/pull/10341 -- Added getattr for 
profilefield in order to be used as the same model
https://code.djangoproject.com/ticket/29243 -- Improve efficiency of 
migration graph algorithm


Released v2.1.1



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/067c5eb2-934f-46ba-8585-c933e001%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django bugfix release: 2.1.1

[Carlton Gibson]

Cool. Thanks 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/42D86F9B-B713-402F-8BB3-0F7AC0394FB7%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP

Adjusting MRO of the CBVs

[Carlton Gibson]

There's a ticket adjusting the MRO of DeleteView. 

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

I'm closing this as `wontfix`: 

* It's nice in theory but...
* not worth the breaking change. 

I'm posting here because I'm half-inclined to a Someday/Maybe (any least): 
surely, improving the structure of the code is something we can/should do. 

I'm just not at all sure of whether it's worth it, when we could do it, and 
what a migration path would look like. (And so on.) 

If you want to have a look, that would be great. I'd be very happy for 
anyone to adjust the resolution if you can see better. 

Thanks. 

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/f3761ffe-63a4-4336-b481-4d47bea1b23e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Fellow Reports -- September 2018

[Carlton Gibson]

Hi all,


Calendar Week 36 -- ending 09 September.


Triaged:

https://code.djangoproject.com/ticket/29741 -- There is no way to validate 
a ModelAdmin against it's inline formsets (Invalid)
https://code.djangoproject.com/ticket/29739 -- BaseModelFormSet ignores 
excess rows in initial when extra < len(initial) (Duplicate of #16995)
https://code.djangoproject.com/ticket/29744 -- Optimization: Multiple 
URLResolvers may be unintentionally be constructed by calls to 
`django.urls.resolvers.get_resolver` (Accepted)
https://code.djangoproject.com/ticket/29737 -- Error loading jython 
callable 'application': No module named mysite (Invalid)
https://code.djangoproject.com/ticket/29735 -- MRO of DeleteView need to be 
changed. (wontfix)
https://code.djangoproject.com/ticket/29733 -- update_or_create - 
documentation misleading (Invalid)
https://code.djangoproject.com/ticket/29673 -- Thread urlconf isnt 
reset after response complete (Accepted)
https://code.djangoproject.com/ticket/29711 -- Add system check to ensure 
uniqueness of admin actions' __name__. (Accepted.)
https://code.djangoproject.com/ticket/29688 -- ModelAdmin: Add attribute to 
override manager used by ModelAdmin.get_queryset() (wontfix)
https://code.djangoproject.com/ticket/29724 -- Admin date_hierarchy filter 
by month displays an extra day (Accepted.)
https://code.djangoproject.com/ticket/29730 -- Update docs for sending 
emails (needsinfo)
https://code.djangoproject.com/ticket/29726 -- Setting the Shanghai time 
zone causes a query error (Invalid)
https://code.djangoproject.com/ticket/29729 -- Update Writing your 
first patch for Django tutorial (Accepted)



Reviewed:

https://code.djangoproject.com/ticket/29560 -- Add an option to 
django-admin to always colorize output
https://code.djangoproject.com/ticket/16995 -- ModelFormSet initial data 
from initial parameter uses "extra" forms
https://github.com/django/django/pull/10371 -- Bugfix: Support Python 3.7 
for 1.11
https://code.djangoproject.com/ticket/29727 -- Lookup using F() on a 
non-existing model field doesn't throw an error
https://code.djangoproject.com/ticket/29734 -- Added option to sort message 
strings for translations by msgid
https://code.djangoproject.com/ticket/29573 -- Add link from per-item 
aggregation topic discussion to `annotate()` ref.
https://github.com/django/django/pull/10367 -- Refs #29713 -- Improved 
error message from translation system check.
https://code.djangoproject.com/ticket/29538 -- Query Expression in ordering 
of a related object fails
https://code.djangoproject.com/ticket/29243 -- Improve efficiency of 
migration graph algorithm
https://code.djangoproject.com/ticket/29713 -- Add a django check to ensure 
the LANGUAGE_CODE setting uses the standard language ID format



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/15fdd0b2-c866-4a68-ac47-0541d8a3f4c3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Passing initial data to model formsets - a suggested improvement

[Carlton Gibson]

Hi Mark. 

What I'm not sure about here is how things have changed from Carl's 
original observation in the comment you link.

On Thursday, 6 September 2018 13:53:05 UTC+2, Mark Gensler wrote:
>
> https://code.djangoproject.com/ticket/16995#comment:1
>

> ... if it's an improvement at all, it's not enough of one to justify 
making a backwards-incompatible change. 

As such I'm initially sceptical. 

I think I'm not really seeing your use-case, so perhaps if you motivated 
that some... 

What you do say is this: 

> ...the length of the initial data may not be known at the time of class 
construction. 

OK. But there's nothing to stop you defining a base FormSet class which has 
all the knowns and then using `modelformset_factory()` to pass in the 
known-at-runtime `extra` value that you need. 

https://docs.djangoproject.com/en/2.1/ref/forms/models/#modelformset-factory

Another way of saying "perhaps if you motivated that some..." is, Why isn't 
that good enough? 

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/76a7d8ec-2d3a-4075-a210-ba200ef46013%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Django bugfix release: 2.1.1

[Carlton Gibson]

Details are available on the Django project weblog:

https://www.djangoproject.com/weblog/2018/aug/31/bugfix-release/

-- 
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/127D72C0-2CE8-45C2-A7FD-8E9A50BC7DB8%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP

Re: Help wanted testing proposal for the Migration Graph algorithm

[Carlton Gibson]

Hi Dan. 

Super! 

On Tuesday, 28 August 2018 17:28:32 UTC+2, d...@thread.com wrote:
>
> I've run it on our codebase with ~1100 migrations and ~380 apps.
>

Yes! This is what I was looking for. 
 

> There were no exceptions thrown - the script completed cleanly, although I 
> haven't actually migrated with it or checked that the migrations work. I 
> assume the script is enough to ensure consistent migrations? 
>

Perfect. The changes just relate to how the graph of migrations is built. 
This feeds into forward_plan, backwards_plan etc. (The individual 
migrations remain the same; theres no real need to migrate.) 

That the script executes without error on a large project is more or less 
what we want to see here. (There was additional input on the PR confirming 
the same, so that's good.) 

There's a second version of the script that writes the generated plans to a 
file. If you were to run this with v2.1 or master and the PR branch, you 
should find the generated plans to be same (i.e. the files to be 
identical). I'll paste this script at the bottom. If you have time to run 
it, as a extra check, that would be cool.

Around a 3.5% speedup.
>

OK. Perfect.

It looks like the kind of cycles that would lead to worst case performance 
don't really come up. (Most migrations just have a single dependency on the 
previous one, and that's it.) 
As such the performance boost of this patch is not massive. (Still worth 
having, other things being equal.)

We would expect slightly better improvement in real-life, since the script 
here recreates the loader (which regenerates the graph) each time through 
the loop, whereas `migrate` etc re-use the loader (which in the patch, vs 
master, only does the graph validation a single time).

However, still, performance will not be the key issue. 

Currently, with the feedback, my thinking is that the patch is a good 
refactoring (that will likely lead to further improvements). So I'm keen.
I just need to go over the code and tests again. 

Second version of script to follow. 

Thanks for the input. It's really helpful! 

Kind Regards,

Carlton



# Save as e.g. migration_graph.py
# Set DJANGO_SETTINGS_MODULE
# From project dir run: python migration_graph.py
# compare output from v2.1 or higher and PR. 
#
import sys

import django
django.setup()

from django.db import connection
from django.db.migrations.loader import MigrationLoader

f = open('plans-{}'.format(django.__version__), 'w')
print('Writing plans for v{}'.format(django.__version__))

loader = MigrationLoader(connection)
backwards = loader.graph.root_nodes()
forwards = loader.graph.leaf_nodes()

print('Calculating backwards plans:')
for root in backwards:
loader = MigrationLoader(connection)
sys.stdout.write('.')
plan = loader.graph.backwards_plan(root)
f.write(str(plan))
f.write('\n')

f.write('\n' * 3)
sys.stdout.write('\n')

print('Calculating forwards plans:')
for leaf in forwards:
loader = MigrationLoader(connection)
sys.stdout.write('.')
plan = loader.graph.forwards_plan(leaf)
f.write(str(plan))
f.write('\n')

f.close()
sys.stdout.write('\nRun Done\n\n')

 

-- 
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/24ad1be0-c2a4-4a24-9b6c-24a748a09dcb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Fellow Reports -- August 2018

[Carlton Gibson]

Hi all,


Calendar Week 33 -- ending 19 August.


Triaged:

https://code.djangoproject.com/ticket/29672 -- Returns an empty model field 
that is filled with a trigger in the database. (Invalid)
https://code.djangoproject.com/ticket/29656 -- Range Fields do not support 
blank values via ModelForm (Duplicate of #27039.)
https://code.djangoproject.com/ticket/29671 -- Unable to modify UserAdmin 
to prevent editing/viewing passwords (invalid)
https://code.djangoproject.com/ticket/29669 -- admin.E033 incorrectly 
raised when adding a calculated field in the ordering tuple of a 
ModelAdmin (Accepted)
https://code.djangoproject.com/ticket/29664 -- Need Proper error handling 
for CBV in urls. (wontfix)
https://code.djangoproject.com/ticket/29667 -- path converters dont 
handle spaces well. (Accepted)


Reviewed:

https://code.djangoproject.com/ticket/29681 -- Support XHTML5 (XML 
serialization of HTML5)
https://github.com/django/django/pull/9212 -- Fixed a race condition 
problem in migrations howto.
https://github.com/django/django/pull/10303 -- close # TODO: why cant 
I make this ..app2
https://code.djangoproject.com/ticket/29677 -- 
StaticFilesStorage.post_process does not seem to exist, contrary to 
documentation
https://code.djangoproject.com/ticket/29646 -- Document the validators that 
each model and form field uses
https://code.djangoproject.com/ticket/29529 -- Allow FilePathField path to 
accept a callable.
https://code.djangoproject.com/ticket/29243 -- Refactor migration graph code



Calendar Week 34 -- ending 26 August.


Triaged:

https://code.djangoproject.com/ticket/29707 -- New admin autocomplete 
widget ignores limit_choices_to filter in referring FK definition 
(Accepted.)
https://code.djangoproject.com/ticket/29704 -- manage.py test does not 
always accept test-runner specific command line options (Accepted.)
https://code.djangoproject.com/ticket/29705 -- RuntimeError while saving 
webp file to Image-Field (Accepted.)
https://code.djangoproject.com/ticket/29700 -- Document 
ModelAdmin.autocomplete_view() and AutocompleteJsonView (as customisation 
point). (Accepted.)
https://code.djangoproject.com/ticket/29680 -- Paginate start with last 
Page (wontfix)
https://code.djangoproject.com/ticket/29691 -- Support ForeignKey based 
model inheritance (wontfix)
https://code.djangoproject.com/ticket/29694 -- QuerySet.values_list() 
combined with .extra() or .annotate() may produce wrong .union() (Duplicate 
of #29229)


Reviewed:

https://code.djangoproject.com/ticket/29688 -- ModelAdmin: Add attribute to 
override manager used by ModelAdmin.get_queryset()
https://code.djangoproject.com/ticket/29243 -- Improve efficiency of 
migration graph algorithm



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/1494bc67-b57b-4d70-8812-754e08c3c548%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: MariaDB, official support

[Carlton Gibson]

This seems a bit more pressing now: 2.0.7 broke MariaDB compatibility. 

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

I'm sure that can be fixed. But we're in a tricky position now. 

Claude has marked the ticket as a Release Blocker, which is understandable, 
but I can't see how we can 
both support and not-support MariaDB, especially when we don't have test 
coverage on CI to support it. 

Adam, you came to mind immediately when I saw the ticket here, since you've 
talked about this. 
(So I'm glad you're already on this thread.) 

Where are we on MariaDB support? What timescale can we add it (if at all)? 
What can we realistically do in the interim? 

v2.2 is scheduled for the end of 2018. That's the earliest we can get it in 
now. 
What's a realistic workflow if we're going to consider MariaDB breaking 
changes as out of bounds before then? 

Thanks for the input all! 

C.  

-- 
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/4cf1e564-e0ad-4576-ba53-4d9276633cff%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Fellow Reports -- July 2018

[Carlton Gibson]

Hi all,

Calendar Week 27 -- ending 6th July.


Reviewed:

https://code.djangoproject.com/ticket/28540 -- Document changes to file 
upload permissions in Django 1.11
https://code.djangoproject.com/ticket/29544 -- Add a MariaDB database 
backend



Triaged:

https://code.djangoproject.com/ticket/29519 -- Django admin actions: 
_selected_action disregarded when `difference` is applied to queryset via 
filters (needsinfo: did not reproduce)
https://code.djangoproject.com/ticket/29529 -- Allow FilePathField path to 
accept a callable. (accepted)



Released 2.0.7 and 1.11.14.


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/732decbf-e03f-466c-a2bc-cd00cdc845f0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Jenkins resources

[Carlton Gibson]

Hi Matt, 

The Jenkins configuration is not public I'm afraid. 

I'm one of the Django Fellows. If you wanted to invite me to your VSTS 
project I would be happy to review and offer pointers as you did the actual 
work, assuming that would help?

The main thing would be setting up the grid of supported versions, against 
different Pythons and DBs. I guess I'd start just with Python 3.7 (or 3.6) 
using SQLite and then grow out from there. 

The most basic setup would just be: 

* Clone
* install pip dependencies
* cd tests && ./runtests.py. 

If you can set up the grid of supported environments, that becomes 
interesting. 

I can only presume it's being actively worked on but, VSTS' integration 
with GitHub wasn't great last time I looked (?)

Finally, I don't think we're looking to move the CI but would Microsoft 
provide free resource to the DSF (us) for testing Django? 

Thanks. Interesting. 

Kind Regards,

Carlton


On Thursday, 12 July 2018 00:09:19 UTC+2, Matt Cooper wrote:
>
> Hi Django devs. I've looked all over for the tools that power djangoci.com, 
> but I don't see them. Are the Jenkins configuration, scripts, and resources 
> available someplace?
>
> Full disclosure, I'm on the Visual Studio Team Services group at 
> Microsoft. We're making sure that our CI system is as good a home for 
> Python (and PHP, and Ruby, and ...) projects as any system out there. One 
> of the research activities I'm doing is trying to get a CI pipeline set up 
> for well-known Python projects. Then I can see where we have gaps, where we 
> have better features, etc.
>
> Thanks,
> Matt
>

-- 
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/3f25427c-2a96-4b30-a3a8-0987a4ecab61%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Cast with AutoField results in a 'type does not exist' error in PostgreSQL 10.1

[Carlton Gibson]

Hi Andrew, 

Reading the description, it seems like you may have hit a bug. 

Could you possibly put this into an actual test case and open a PR
(plus Trac ticket) with that  assuming the test fails? 

With code in hand it's much easier to assess (and fix). 

Thanks. 

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/6b51e80d-d237-4e6d-814e-2d70d0229139%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Jenkins resources

[Carlton Gibson]

Hi Matt,

The settings files from the django-box project are 
here: https://github.com/django/django-box/tree/master/roles/djangodata/files
If you look in each, you'll see they basically just redefine the connection 
details for the 'default' and 'other' DB. 
(There's not much more to it really.)

You can see supported Python versions 
here: 
https://docs.djangoproject.com/en/dev/faq/install/#what-python-version-can-i-use-with-django
For master it's now just Python 3.5-3.7. 

> tests.timezones.ForcedTimeZoneDatabase generates output with an invalid 
timestamp...

Not sure what that's about, but if you think there's an issue our end open 
a ticket at https://code.djangoproject.com. 

> ... what issues you faced ...

None in particular. My observation was more from a UX perspective. VSTS is 
all built around the idea you host on visualstudio.com 
but if you don't do that whole areas are blank (and a bit 
superfluous/confusing). It seems to have changed a bit, I see. :)

Finally: 

> I'm confident we can put something together in terms of resources for the 
DSF... 

Great! Of course we don't have to talk about it now. (It was more a 
speculative ask..  :-) 

I think we're OK to discuss here if it's not too noisy. Otherwise do hit me 
off-list. 
(Is there no VSTS messaging...? You could create an issue on your GitHub 
clone and @mention me. :-)

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/5f1b112b-212e-413f-aa8d-e97553b7538d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: About #8500 and #27728

[Carlton Gibson]

Hi Raffaele, 

Thanks for both your effort and your patience. 

There are around 60 patches needing review (or just reviewed or being 
improved or...) at the moment, so it can take a while to get to. 

I will look at this issue on Monday. 

Please don't loose heart. 

Kind Regards,

Carlton


On Friday, 19 January 2018 22:41:22 UTC+1, Raffaele Salmaso wrote:
>
> Hi all,
> as these PR have merge conflicts that need to be resolved, and it takes 
> time to keep that ready to merge, I would be glad to know if continue to 
> work on them (and how to get them merged) or just drop them and carry on.
>
> Thanks
>
> On Tue, Sep 5, 2017 at 10:57 AM, Raffaele Salmaso  > wrote:
>
>> Hi all,
>> I'm working to ticket #8500 and #27728 to improve a bit the admin, and 
>> being asked to ask to django-developers about some decision.
>>
>> In ticket #8500 I've used a LazyObject to defer the the real 
>> django.contrib.admin.sites.site instantiation, so admin.site is always the 
>> custom one.
>> The first approach was simpler, with a setting. But as Tim pointed out it 
>> doesn't need to be a setting, so I rewrote to be a custom field for 
>> (Simple)AdminConfig (and django itself doesn't need to know it existence)
>>
>> Currently I'm monkey patching in my custom admin setup (
>> https://bitbucket.org/rsalmaso/django-fluo is my own utility library)
>>
>> > class FluoAdminConfig(AdminConfig):
>> > default_site = "fluo.admin.sites.AdminSite"
>> >
>> > def ready(self):
>> > self.override_admin_site()
>> > super().ready()
>> >
>> > def override_admin_site(self):
>> > from django.contrib import admin as django_admin
>> > from django.contrib.admin import sites as django_sites
>> > from fluo import admin as fluo_admin
>> > from fluo.admin.sites import DefaultAdminSite
>> >
>> > site = DefaultAdminSite()
>>
>> where the DefaultAdminSite is the same as in PR
>> > class DefaultAdminSite(LazyObject):
>> > def _setup(self):
>> > AdminSiteClass = 
>> import_string(apps.get_app_config('admin').default_site)
>> > self._wrapped = AdminSiteClass()
>>
>>
>> I think it is a better approach than the Jannis' one (
>> https://code.djangoproject.com/attachment/ticket/8500/8500.1.diff), as 
>> Adam claims it is simpler, because
>> - it doesn't require to rewrite your admin.py to add an helper function 
>> in admin.py
>> > def register(site):
>> > site.register(...)
>> - it works with all current third party modules (so don't have to add a 
>> custom adapter in my own project)
>> - can use the @admin.register() decorator as is
>>
>> Currently all my projects use this approach, and I'm really happy because 
>> I find no problem with 3rd apps, they always use my custom instance, and 
>> don't have two different site.
>>
>> In ticket #27728 I've rewrite all include template tags (submit_row, 
>> pagination, admin_actions, search_form, date_hierarchy, result_list, 
>> prepopulated_fields_js, object_tools) to be overridable by the "standard" 
>> admin pattern (["admin/app_label/app_model/template_name", 
>> "admin/app_label/template_name", "admin/template_name"]).
>> This patch solves even the tickets #11974, #12566, #18957, #19235, #26763.
>> Choose to patch all include tags because:
>> - I have a project where I override all of them (!)
>> - they are all the same implementation, so easy to replicate
>>
>> The approach is to create a custom InclusionAdminNode, which handle all 
>> common task to split the include parameters, select the correct template 
>> and wrapping the original tag function (which are never changed).
>>
>> Hope this clears all intentions and have them in django 2.0 :)
>>
>> -- 
>> | Raffaele Salmaso
>> | https://salmaso.org
>> | https://bitbucket.org/rsalmaso
>> | https://github.com/rsalmaso
>>
>
>
>
> -- 
> | Raffaele Salmaso
> | https://salmaso.org
> | https://bitbucket.org/rsalmaso
> | https://github.com/rsalmaso
>

-- 
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/9b5418c5-5828-40b0-8f3e-dac9d50fd26c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: About #8500 and #27728

[Carlton Gibson]

Hi Raffaele,

I took a look at both these PRs — they both seem like good wins to me. 
I've commented briefly on the issues. 

Here I would just ask if people using the Admin have capacity to review 
that 
would be great. (If not I'm inclined to push these forwards.)

* https://github.com/django/django/pull/7765
* https://github.com/django/django/pull/7840

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/a0dd742a-708b-46c8-a956-1d5b9824a1b7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Default Authorization BackEnd Denying Permissions if ObjectProvided

[Carlton Gibson]

Hi Mehmet

On Tuesday, 23 January 2018 15:05:06 UTC+1, Mehmet Dogan wrote:
>
> Do you think what Florian or I sent is a good example to include in the 
> docs for the way #1?
>

Yes.

I was just looking for where. Candidates: 

* https://docs.djangoproject.com/en/2.0/topics/auth/default/#topic-authorization
* 
https://docs.djangoproject.com/en/2.0/ref/contrib/auth/#django.contrib.auth.models.User.has_perm
* 
https://docs.djangoproject.com/en/dev/topics/auth/customizing/#handling-authorization-in-custom-backends

None of these are quite right. (Although top one is favourite. The last one 
has this line: "If you wish to provide custom behavior for only part of the 
backend API, you can take advantage of Python inheritance and subclass 
ModelBackend instead of implementing the complete API in a custom 
backend..." — which is about as close as we get.)

There's also this discussion: 

* https://code.djangoproject.com/wiki/RowLevelPermissions

Looking at this, I don't think we're quite saying what I took us to be 
saying. i.e. we're not clearly spelling out the object-permissions 
situation. 
(Beyond those pages all the top search results are from DRF, and Django 
Guardian, which must be where people are picking up this knowledge.)

As such, if you wanted to work on a docs focused PR here I'd be happy to 
review and input on that on GitHub. 
(I take it this would say a bit more than currently on how User.has_perms() 
proxies to the backends, such that some may handle object-level 
permissions.)

Thanks for the effort! 

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/684dc59f-ba6f-44b0-9da3-59b1dad06062%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Fellow Report -- March 12, 2018

[Carlton Gibson]

Hi All, 

Last week I reviewed patches on the following issues: 

https://code.djangoproject.com/ticket/28574 -- Add Queryset.explain() method
https://github.com/django/django/pull/9752  -- Minor fixes to improve 
install.txt's clarity
https://code.djangoproject.com/ticket/29180 -- makemigrations autodetector 
ignoring existing migrations
https://code.djangoproject.com/ticket/23406 -- Migrations not found when 
only .pyc files are available (e.g. in a frozen environment)
https://code.djangoproject.com/ticket/28250 -- Ignore soft applied 
migrations in consistency check
https://code.djangoproject.com/ticket/29165 -- Initial data howto could 
better explain how to use migrations
https://code.djangoproject.com/ticket/28988 -- Multi-table inheritance 
breaks GenericRelation querying

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/fa8cd6ef-b6de-41d2-a825-069b6285b829%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Improving usefulness of management command help output via reordering options

[Carlton Gibson]

Hi David. 

Your suggestion seems sensible, good even. (To me at least. ) 

If you'd be happy to do the work for it then a Trac ticket + PR would be 
the way to go. 
(Assuming there are no objections.) 

Kind Regards,

Carlton


On Friday, 6 April 2018 01:24:12 UTC+2, David Foster wrote:
>
> Currently if you run a custom management command with --help, you will get 
> output that looks like:
>
> $ python3 manage.py import_layout_calendar --help
>
> usage: manage.py import_layout_calendar [-h] [--version] [-v {0,1,2,3}]
>
> [--settings SETTINGS]
>
> [--pythonpath PYTHONPATH]
>
> [--traceback] [--no-color]
>
> [--simulate] [--no-strict] 
> [--debug]
>
> [--replace] [--fast-validate]
>
> [args [args ...]]
>
>
> Imports the calendar for a layout in the database.
>
>
> positional arguments:
>
>   args
>
>
> optional arguments:
>
>   -h, --helpshow this help message and exit
>
>   --version show program's version number and exit
>
>   -v {0,1,2,3}, --verbosity {0,1,2,3}
>
> Verbosity level; 0=minimal output, 1=normal 
> output,
>
> 2=verbose output, 3=very verbose output
>
>   --settings SETTINGS   The Python path to a settings module, e.g.
>
> "myproject.settings.main". If this isn't 
> provided, the
>
> DJANGO_SETTINGS_MODULE environment variable will 
> be
>
> used.
>
>   --pythonpath PYTHONPATH
>
> A directory to add to the Python path, e.g.
>
> "/home/djangoprojects/myproject".
>
>   --traceback   Raise on CommandError exceptions
>
>   --no-colorDon't colorize the command output.
>
>   --simulateSuppress all database modifications
>
>   --no-strict, -S   Do not promote all warnings to errors
>
>   --debug   Perform all validating and importing live, without
>
> capturing output
>
>   --replace Delete the current layout overlay before 
> importing.
>
>   --fast-validate   Disables full simulated import as part of 
> validation
>
> I have highlighted in yellow the useful information specific to the 
> command that is *not* boilerplate. Notice that most of this yellow text is 
> at the end of the output, with the boilerplate dominating what the user 
> reads first.
>
> I propose reordering the options in the output so that the useful 
> information is at the *beginning* rather than the end, so that it looks 
> more like the following:
>
> $ python3 manage.py import_layout_calendar --help
>
> usage: manage.py import_layout_calendar [-h] [--simulate] [--no-strict]
>
> [--debug] [--replace]
>
> [--fast-validate] [--version]
>
> [-v {0,1,2,3}] [--settings 
> SETTINGS]
>
> [--pythonpath PYTHONPATH]
>
> [--traceback] [--no-color]
>
> [args [args ...]]
>
>
> Imports the calendar for a layout in the database.
>
>
> positional arguments:
>
>   args   |  
> 
>
>
> optional arguments:
>
>   -h, --helpshow this help message and exit
>
>   --simulateSuppress all database modifications
>
>   --no-strict, -S   Do not promote all warnings to errors
>
>   --debug   Perform all validating and importing live, without
>
> capturing output
>
>   --replace Delete the current layout overlay before 
> importing.
>
>   --fast-validate   Disables full simulated import as part of 
> validation
>
>   --version show program's version number and exit
>
>   -v {0,1,2,3}, --verbosity {0,1,2,3}
>
> Verbosity level; 0=minimal output, 1=normal 
> output,
>
> 2=verbose output, 3=very verbose output
>
>   --settings SETTINGS   The Python path to a settings module, e.g.
>
> "myproject.settings.main". If this isn't 
> provided, the
>
> DJANGO_SETTINGS_MODULE environment variable will 
> be
>
> used.
>
>   --pythonpath PYTHONPATH
>
> A directory to add to the Python path, e.g.
>
> "/home/djangoprojects/myproject".
>
>   --traceback   Raise on CommandError exceptions
>
>   --no-colorDon't colorize the command output.
>
> Thoughts?
>
> --
> David Foster | Seattle, WA, USA
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.

Re: Should ModelChoiceIterator cache its QuerySet?

[Carlton Gibson]

Hi François, 

Thank you for a good write-up of the issue. 

Having looked at this from each direction I can't see a way of squaring all 
the desires here.

I see the possibility of an inconsistency between the __len__() and 
__iter__() calls. This would certainly be nice to avoid but I'm not sure it 
is the overriding concern here. 

I can easily see the memory issue being more significant than you're giving 
it credit for. 

The original issue (#23623) cited a ≈25% reduction in peak memory usage 
moving to the iterator. Choices are used in validation and not just 
template rendering. If not reset, the queryset is retained for the lifetime 
of the form instance, not just the ModelChoiceIterator iteration. With a 
large formset, with forms using ModelChoiceField on foreign keys with many 
thousands of records, the retained queryset would likely add up quickly. 

As such, I don't think we can just switch the default implementation. (I 
think we'd quickly see a lot of complaints.)

I **do see** the appeal of re-using the queryset for a whole lot of cases. 
Many times I would trade a bit more memory for the lifetime of a form 
instance for one less query. (Although, just personally, I'm not sure how 
often `if field.choices` actually comes up, for me.)

So, conclusions (with _I think we should…_ etc elided):

* Close your PR as is. https://github.com/django/django/pull/9867 — We 
can't just change the behaviour. 
* Look at Tim's PoC PR. https://github.com/django/django/pull/8649 — Can we 
implement __len__() to not _fetch_all()? Can we implement the custom 
__bool__ to avoid `count()`? Can we do that without an extra DB query? 
* If we **can't** avoid the extra query then we have to decide whether it's 
an acceptable price? 
* wontfix: If it's not, the existing behaviour is _OK_: it's not 
incorrect for __len__() to _fetch_all(), and your previous fix makes sure 
we don't waste that effort if it has been done. 
* Fix: I'd guess the extra query probably is OK, especially with an 
optimised __bool__ just checking existence. It's the price of consistency 
here. 
* Can we then document, and maybe provide, an alternate ModelChoiceIterator 
that just re-uses the queryset? 
* Advantages of this are consistency, fewer DB hits etc. 
* Cost is the higher memory use.

That's my take on the issue thus far. 

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/f8653583-4d19-4a06-9d68-f81639ea6937%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Design Decision: GFK Reverse Lookups

[Carlton Gibson]

Hi All.

https://github.com/django/django/pull/9748 adds the ability to perform 
simple queries on a generic foreign key: 

TaggedItem.objects.filter(content_object=object_instance)

You still can't do anything more complex, such as:

TaggedItem.objects.get(content_object__name='Diamond')

This is a long standing 
Someday/Maybe: https://code.djangoproject.com/ticket/3006



The patch seems more or less OK to me but I'm not sure if we shouldn't 
*instead* guide users firmly towards defining a GenericRelation. 

GenericRelation provides for the more powerful querying, and, this way, 
provides the one correct way™ to do things. 

I'm wondering what the correct view should be: whether we take this patch 
or close the issue as wontfix and solely recommend GenericRelation. 



Thanks for your input. 

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/c81e6d2d-7254-4ad5-b8dd-c8c05726f55c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Fellow Reports -- April 2018

[Carlton Gibson]

Hi All, 

Calendar Week 14 — ending 6th April. I reviewed patched on: 

https://code.djangoproject.com/ticket/28462 -- ModelAdmin.list_editable 
unusably slow and memory intensive with large datasets
https://code.djangoproject.com/ticket/27991 -- Add 'obj' kwarg to 
InlineModelAdmin.has_add_permission()
https://code.djangoproject.com/ticket/29231 -- Add title option for admin 
filter when providing a field name
https://code.djangoproject.com/ticket/29226 -- @modify_settings 
append/remove/prepend is affected by dictionary order
https://code.djangoproject.com/ticket/29288 -- {% widthratio %} fails to 
assign to variable if exception happens
https://code.djangoproject.com/ticket/25718 -- Allowed using None as a 
JSONField lookup value
https://code.djangoproject.com/ticket/29212 -- Redirect loop with 
@permission_required and redirect_authenticated_user
https://code.djangoproject.com/ticket/29248 -- Model field names can 
conflict with admin's field-box CSS class
https://code.djangoproject.com/ticket/29289 -- Clarified comment regarding 
what data is hashed to generate PasswordResetTokenGenerator tokens.


Calendar Week 15 — ending 13th April. I reviewed patched on: 

https://code.djangoproject.com/ticket/3006  -- generic relations do not act 
as expected in a filter/get
https://code.djangoproject.com/ticket/28312 -- ModelChoiceIterator uses 
cached length of queryset.
https://code.djangoproject.com/ticket/29301 -- Reorder management command 
arguments in --help output to prioritize command-specific arguments
https://code.djangoproject.com/ticket/29306 -- Prevent template variable 
lookups from intiatiating a class
https://code.djangoproject.com/ticket/29193 -- Altering a field with a 
unique constraint drops and rebuilds FKs to other fields in the table
https://code.djangoproject.com/ticket/28600 -- Add prefetch related support 
to RawQuerySet
https://code.djangoproject.com/ticket/29212 -- Redirect loop with 
@permission_required and redirect_authenticated_user
https://code.djangoproject.com/ticket/29313 -- Add documentation for how to 
use F() expressions in combination with nulls_last
https://code.djangoproject.com/ticket/19580 -- Unify reverse foreign key 
and m2m unsaved model querying
https://code.djangoproject.com/ticket/29286 -- QuerySet.values_list() 
crashes when combining annotated and not-annotated querysets with union().
https://code.djangoproject.com/ticket/29296 -- admindocs ViewIndexView 
crashes if a syndication Feed (or something without __qualname__) is 
configured


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/ded9bc6f-d0d9-4d2a-a524-a2a37f9da72b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Fellow Report -- April 1, 2018

[Carlton Gibson]

Hi All. 

Week ending 23/3 I reviewed patches on:

https://code.djangoproject.com/ticket/29173 -- Document that Model.save() 
doesn't refresh fields from the database
https://code.djangoproject.com/ticket/28574 -- Add Queryset.explain() method
https://code.djangoproject.com/ticket/23406 -- Allow migrations to be 
loaded from .pyc files (e.g. in a frozen environment)
https://code.djangoproject.com/ticket/27654 -- Propogate alters_data value 
to subclasses
https://code.djangoproject.com/ticket/21381 -- Remove contrib.redirects 
dependency on contrib.sites
https://code.djangoproject.com/ticket/18620 -- Prefer current Site when 
checking M2M in "shortcut"/"view_on_site" redirect
https://code.djangoproject.com/ticket/28718 -- Password reset shouldn't 
depend on the current password being hashed with a supported hasher
https://code.djangoproject.com/ticket/29212 -- Redirect loop with 
@permission_required and redirect_authenticated_user
https://code.djangoproject.com/ticket/29232 -- Add title option for admin 
filter when providing a field name


Triaged: 

https://code.djangoproject.com/ticket/29198 -- Add a --plan option to the 
migrate command
https://code.djangoproject.com/ticket/29215 -- Document potential change to 
behaviour of QuerySet methods when upgrading to Python 3.6


Committed:

https://github.com/django/django/pull/9810  -- Update order of import 
statements to reflect code


Last week I was on vacation (with family, for Easter). 


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/62811adc-d88a-42da-b806-4fbc2e597c85%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Fellow Report -- March 19, 2018

[Carlton Gibson]

Hi all.

Last week I reviewed patches on: 

https://code.djangoproject.com/ticket/23406 -- Migrations not found when 
only .pyc files are available (e.g. in a frozen environment)
https://code.djangoproject.com/ticket/28184 -- FileField storage param 
should allow a callable
https://code.djangoproject.com/ticket/29116 -- Geometry editing issue when 
widget map_srid different from original value srid
https://code.djangoproject.com/ticket/28646 -- Migration calls "CREATE 
INDEX" when one already exists when 'unique' field attribute is added 
(PostgreSQL)
https://code.djangoproject.com/ticket/28504 -- Add hooks into 
SchemaEditor.alter_field() and reduce complexity
https://code.djangoproject.com/ticket/28535 -- Message on conflicting 
migrations is misleading for rebase workflows
https://code.djangoproject.com/ticket/29103 -- sqlmigrate produces byte 
literal in SQL for one-off string default value in TextField, CharField on 
MySQL
https://code.djangoproject.com/ticket/29206 -- ValidationError when a reset 
password link contains a bad UIDB64 UUID
https://code.djangoproject.com/ticket/29200 -- RadioSelect does not render 
its label in MultiWidget
https://code.djangoproject.com/ticket/28959 -- Clicking "No, take me back" 
on the delete selected inline foreign key / one-to-one field confirmation 
page does nothing
https://code.djangoproject.com/ticket/29184 -- TabularInline read-only 
fields ignore ModelForm Meta.labels and help_texts
https://code.djangoproject.com/ticket/27468 -- Move 
utils.crypto.salted_hmac() from SHA1 toward SHA256
https://code.djangoproject.com/ticket/27991 -- Add 'obj' kwarg to 
InlineModelAdmin.has_add_permission()

Triaged:

https://code.djangoproject.com/ticket/29216 -- Add the ZalgoScript 
filtration!-- Closed invalid
https://code.djangoproject.com/ticket/29217 -- Small typo in spanish 
translation  -- Fixed on Transifex 


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/daa48c03-d9c3-4ae0-b682-340bc1008811%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Fellow Report -- March 5, 2018

[Carlton Gibson]

Hi all, 

Last week I reviewed patches (etc) on: 

https://code.djangoproject.com/ticket/18620 -- Prefer current Site when 
checking M2M in "shortcut"/"view_on_site" redirect
https://code.djangoproject.com/ticket/3461  -- DatabaseWrapper should pass 
through args and kwargs to underlying database adapter
https://code.djangoproject.com/ticket/26291 -- Allowed loaddata to handle 
forward references in natural_key fixtures.
https://code.djangoproject.com/ticket/22449 -- Colorize output of test 
results
https://code.djangoproject.com/ticket/21963 -- makemessages still ignores 
translations in templates with inline comment tags
https://code.djangoproject.com/ticket/27728 -- Allowed overriding admin 
templatetag's templates.
https://code.djangoproject.com/ticket/28184 -- FileField storage param 
should allow a callable
https://code.djangoproject.com/ticket/19580 -- Unify reverse foreign key 
and m2m unsaved model querying
https://code.djangoproject.com/ticket/29166 -- in lookup doesn't work with 
lists in a When clause
https://code.djangoproject.com/ticket/29116 -- Geometry editing issue when 
widget map_srid different from original value srid
https://code.djangoproject.com/ticket/28250 -- Ignore soft applied 
migrations in consistency check
https://code.djangoproject.com/ticket/28835 -- Made development server 
shutdown on SIGTERM
https://code.djangoproject.com/ticket/29144 -- `DjangoTranslation.merge` 
loses fallbacks
https://code.djangoproject.com/ticket/29172 -- Using Window in Subquery 
causes AttributeError
https://code.djangoproject.com/ticket/28459 -- Improved performance of time 
difference expressions on MySQL


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/3a207fc3-a6f5-4787-b417-a432b4e8993a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Widening participation (Thoughts from DjangoCon)

[Carlton Gibson]

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. 

Mentoring

For whatever reasons, the exiting *Contributing How-To* 
 doesn’t 
lead to contributions from a demographic that matches the wider Django 
Community. 

The point that came up again and again about this was that *mentoring* is 
one of the best (perhaps the best?) tool in helping to change this. 

Django Core Mentorship

We don’t have an official mentoring programme but we do have the 
django-core-mentorship 
list . 

This must be about the best-kept secret in the Django world: it’s gets ≈0 
traffic, but I told everybody at DjangoCon about it, and that they should 
use it. 

If you are not on django-core-mentorship, and you’re willing to help 
prospective contributors, please sign-up. I’m hoping we can drive some 
traffic to it. 

Maybe there’s call for something more formal, but at least until DCM is 
actually being used, that seems (to me) like something we can postpone. 

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

Sprints

I’m not historically a Django-sprinter. (I have too many children for that 
TBH, but they’re getting older…)

I always thought it was for a hard-core to work on hard issues. 

Shows what I know… 

It was strongly impressed upon me that the real benefit of sprints is being 
able to give new contributors the support they need to make their first (or 
second or…) contribution. 

In particular, groups such as Pyladies can organise a sprint event with the 
specific goal of helping members of the community get across the barriers 
to contributing. This can reach numbers that otherwise simply aren’t 
possible. (So wow. Basically.)

Sprints & Mentoring

Obviously having mentors at sprints is a key component. 

But even if you (or I) can’t attend a sprint, maybe we can (sometimes) be 
available at the right time to contribute remotely. Maybe, in fact, remote 
mentors are a key resource in more remote parts of the Django-sphere. 

It turns out just being on e.g. Twitter can be enough here. 

If we’re all on django-core-mentorship, maybe sprint organisers could post 
notice of an upcoming sprint. 

Sprints & Finding Tickets

It turns out it’s equally hard for a sprint organiser to work out what 
tasks to give sprinters. 

At DjangoCon (some) people have a topic and asks others to join them. But, 
maybe if you’re short of experts and so on, that’s not necessarily a model 
that allows that scales out in other contexts. 

It was put to me that, if we had something like curated project boards 
(think Trello or GitHub projects) with groups of tickets… perhaps some 
easier, some harder… Perhaps with a *curating mentor*, even if remote… — 
*THEN* it becomes much easier for a small groups to organise a sprint, 
whatever their group may look like, wherever they may be. 

It struck me that, whilst we can (say) filter tickets by component (and 
such) we’re were a way from this. 

(Again, I don’t have instant solutions — but I suspect there’s an 80:20 
available somewhere here…) 

And finally…

Beyond all that, we clearly have a problem 

Re: Python string formatting

[Carlton Gibson]

We had a bit of a discussion of this on 


Python 2 docs have got this re format(): 

> This method of string formatting is the new standard in Python 3, and 
should be preferred to the % formatting described in String Formatting 
Operations in new code.

​https://docs.python.org/2/library/stdtypes.html#str.format

But it's not there for Python 3 (
​https://docs.python.org/3/library/stdtypes.html#str.format) so I'm not 
clear what we're meant to think. 
(I had thought %-formatting deprecated...) 

Anyone know? 

Regardless, waiting a bit and moving straight to f-strings (as Simon 
suggests) seems sensible. (If we're convinced we do want to change.)

-- 
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/e7cf5b0d-cff4-4c6d-a9ec-1af4a82d5a56%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Python string formatting

[Carlton Gibson]

Sorry, I typed that up and forgot to paste the link 

On Wednesday, 31 October 2018 20:14:14 UTC+1, Carlton Gibson wrote:
>
> We had a bit of a discussion of this on 
>

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


-- 
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/54ffdece-7da1-4bd9-baa5-f441cd03f4ea%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: race condition on making directories when multiple files are uploaded to the same folder

[Carlton Gibson]

Yep. Coming up shortly...

On Thursday, 1 November 2018 13:45:20 UTC+1, Tim Graham wrote:
>
> It's in a regression in Django 2.0 that will be fixed in today's 2.1.3 
> release.
> https://code.djangoproject.com/ticket/29890
>

-- 
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/2ffd28a5-b2ea-447e-bf5c-e338fff5d2b0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Django bugfix release: 2.1.3

[Carlton Gibson]

Details are available on the Django project weblog:

https://www.djangoproject.com/weblog/2018/nov/01/bugfix-release/

-- 
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/A5A49193-088D-46F6-86D8-07FD83A37F23%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Fellow Reports -- October 2018

[Carlton Gibson]

Hi all,


Calendar Week 43 -- ending 28 October.


Triaged:

https://code.djangoproject.com/ticket/29889 -- ArrayField cannot contain 
JSONField; causes SQL error (needsinfo)
https://code.djangoproject.com/ticket/29879 -- CSRF AJAX section should 
warn about the CSRF_COOKIE_HTTPONLY setting (Accepted)
https://code.djangoproject.com/ticket/29863 -- Allow 
configuration/customization of sensitive settings sanitization for error 
emails (Duplicate)
https://code.djangoproject.com/ticket/29873 -- Link to access related field 
on the admin tool (needsinfo)
https://code.djangoproject.com/ticket/29874 -- Typo in Writing your 
first Django app, part2. (wontfix)



Reviewed:

https://code.djangoproject.com/ticket/29879 -- CSRF AJAX section should 
warn about the CSRF_COOKIE_HTTPONLY setting
https://github.com/django/django/pull/9272 -- Cleaned-up duplicate 
connection functionality.
https://code.djangoproject.com/ticket/29721 -- Migrations are not applied 
atomically
https://code.djangoproject.com/ticket/15602 -- Using get_readonly_fields 
and StackedInline/TabularInline admin objects doesnt allow creating 
new objects, immutible existing objects
https://code.djangoproject.com/ticket/29830 -- Fixed loss of custom utf-8 
body encoding in mails.
https://code.djangoproject.com/ticket/29877 -- Dive Into Python 3 links in 
documentation no longer valid
https://code.djangoproject.com/ticket/29868 -- Database constraint checks 
are not retained on sqlite
https://code.djangoproject.com/ticket/28184 -- FileField storage param 
should allow a callable




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/d46f83f5-744e-4e97-894a-fdb04867f2a1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Fellow Reports -- November 2018

[Carlton Gibson]

Hi all,



Calendar Week 44 -- ending 04 November.




Released: Django v2.1.3




Triaged:


https://code.djangoproject.com/ticket/29917 -- admin.E130 (__name__ 
uniqueness) regression (needsinfo)

https://code.djangoproject.com/ticket/29905 -- Can you fix ticket 26171 in 
1.8.x (wontfix)




Reviewed:


https://code.djangoproject.com/ticket/29917 -- Admin actions are duplicated 
when using model admins with inheritance

https://code.djangoproject.com/ticket/29891 -- Fix incorrect quoting in 
queryset.query

https://code.djangoproject.com/ticket/29615 -- Document difference in 
behaviour between m2m_changed behaviour for add() vs remove() when called 
multiple times.

https://code.djangoproject.com/ticket/29868 -- Database constraint checks 
are not retained on sqlite




Authored:


https://github.com/django/django/pull/10607 -- Fixed #29917 — Adjusted MRO 
collection of ModelAdmin.actions.




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/d947b603-027d-496c-bac2-fe3212d13fb1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Make input field remove newlines from value

[Carlton Gibson]

Hi Jakub. 

Definitely stripping input isn't something I'd want to add: what if I want 
to accept input with trailing whitespace? 

Rather, the approach is to transform the incoming data in your form or 
serialiser at the clean or validation step. 

See: 

* 
https://docs.djangoproject.com/en/2.1/ref/forms/validation/#cleaning-a-specific-field-attribute,
 
for Django Forms, or 
* 
https://www.django-rest-framework.org/api-guide/serializers/#field-level-validation,
 
for Django REST Framework serialisers. 

If you're sure you want the stripped value, I don't see anything wrong with 
a custom widget, as you've used. 
(I don't see it as a monkey patch: custom widgets are not an anti-pattern — 
there's no way we can account for every use-case in the core framework.) 

Thus, I agree with the wontfix here. 

Kind Regards,

Carlton



On Friday, 2 November 2018 01:14:48 UTC+1, Jakub Kleň wrote:
>
> I created this ticked today, and it got closed with a wontfix flag, but I 
> still think it would be a good idea to implement:
> https://code.djangoproject.com/ticket/29912
>
> The reason why it got closed is that django shouldn't modify the input 
> like that, but the link which is mentioned in the response talks about 
> stripping spaces from beginning and end of values, which was resigned some 
> time ago, but It's now a part of django. All form fields automatically 
> strip spaces from beginning and end after submission. It's even the default 
> behaviour, although it's optional.
>
> The next thing that is mentioned in the reply, is that the input may come 
> from an API. I understand this change would be backwards incompatible, it 
> it's turned on by default, but there's no problem in managing this. There 
> could be a flag for it on django.forms.fields.CharField, and ModelForm 
> could automatically enable/disable it the same as it assigns the TextInput 
> / Textarea widget. It seems right to me to differentiate between single 
> line / multiline fields. I was thinking on how to resolve this issue today, 
> and as I have 23 forms in my project, it seemed error-prone to do it in 
> Form.clean_xxx, in so many places.
>
> As a temporary solution, I implemented it for django.forms.widgets.Input 
> by overriding value_from_datadict (monkey patch, which i would definitely 
> like to remove in the future).
>
> From the logical standpoint, it seems relevant to me to implement such a 
> functionality for  fields. From my point of view, the main 
> difference between an  and a  is that input is just for 
> one-line values, whereas a textarea is used when you need a multiline input 
> from the user. Even web browsers have this restriction, and I think it 
> would be a bit safer and more consistent. It took me a while to realise 
> that I should remove newlines for all my input fields. Maybe it's not even 
> such a bad idea to implement it in the widgets, as I'm thinking about it. 
> It would be a lot easier, and maybe it's even the right place for 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/91b0b60d-40cd-4054-a421-d6cbc7ee9744%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Fellow Reports -- October 2018

[Carlton Gibson]

Hi all,


Calendar Week 40 -- ending 07 October.


Released Django versions 1.11.16, 2.0.9 and 2.1.2.


Triaged:

https://code.djangoproject.com/ticket/29818 -- ValueError when parsing 
querydata to autofill a Django admin form (needsinfo)
https://code.djangoproject.com/ticket/29821 -- Add JSONField for all 
supported DBs (and move into core). (Accepted)
https://code.djangoproject.com/ticket/29817 -- Deprecate FILE_CHARSET 
setting (wontfix)



Reviewed:

https://github.com/django/django/pull/10473 -- Removed Jinja2 dependency 
from admin_checks tests.
https://code.djangoproject.com/ticket/29750 -- Add a pre-dispatch() hook 
for class-based views
https://github.com/django/django/pull/10473 -- Removed Jinja2 dependency 
from admin_checks tests.
https://github.com/django/django/pull/10470 -- Refs #27795 -- Removed 
force_bytes() usage in sessions.
https://github.com/django/django/pull/10469 -- Refs #27795 -- Removed 
force_bytes() usage in MySQL backend.
https://github.com/django/django/pull/10448 -- Avoid starting a transaction 
when only a single (or atomic queries) are executed.




Calendar Week 41 -- ending 14 October.


Triaged:

https://code.djangoproject.com/ticket/29841 -- Fixtures counting backward 
(wontfix)
https://code.djangoproject.com/ticket/29837 -- Allow email sending with a 
newline in the subject (Invalid)
https://code.djangoproject.com/ticket/29835 -- list_filter does not follow 
admin ordering, only model meta (Accepted)



Reviewed:

https://github.com/django/django/pull/10505 -- Refs #29826 -- Removed 
unused characters from urlize configuration.
https://code.djangoproject.com/ticket/29408 -- Add validation of related 
fields in model Meta.ordering
https://code.djangoproject.com/ticket/29826 -- urlize does not handle HTML 
angle brackets correctly


Authored: 

https://github.com/djangocon/2018.djangocon.us/pull/244 -- Adjusted 
`your-web-framework-needs-you` bio and talk outline.


Calendar Week 42 -- ending 21 October.


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[1] and the proposal to dissolve Django Core[2]. 

[1]: https://groups.google.com/d/topic/dsf-members/GWOzvsOAGUs/discussion
- Can't see that? Join the DSF: 
https://docs.google.com/forms/d/e/1FAIpQLSd5lbWxAO-sylEEjHVKBNIpmHlhdJRf0_LCo8glnLUWd-Q2Sw/viewform
[2]: https://github.com/django/deps/pull/47

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. 

I'll send a separate email about this tomorrow. 


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/6d103f24-321d-4831-b900-7a79cb6fc880%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to remove ModelAdmin's collection of actions from superclasses

[Carlton Gibson]

The idea was that you could define a base admin and have the actions appear 
without having to redeclare them. 

The only question is are people actually using that? (I can't think of a 
third-party app that provides an admin with actions that you're meant to 
subclass for instance — anyone?) 

If not, then the "usual Python behaviour" argument is favourite. (i.e. +1) 

— 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/6314b21b-5be9-4ab3-ba9d-7e246d796e4b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to extend support for object permission

[Carlton Gibson]

Hi Tobias, 

Thank you for your effort here. Sorry for the slowish response: it's just a 
question of getting round to it. 

The basic issue here is people what to avoid this: 

if user.has_perm('foo.change_bar', obj=bar) or 
user.has_perm('foo.change_bar'):
...

(Or they find it surprising or ...) 

Last time this came up (around #20218) there weren't very many or strong 
opinions, so I came down against a breaking change. 
(I don't mind the existing permissions: they've been the same ≈forever, so 
I see no reason to change.) 

What you've done in your two PRs is nice I think: 

* https://github.com/django/django/pull/10601
* https://github.com/django/django/pull/10600

* Added a `DefaultObjectBackend` on an opt-in basis which gives the 
alternate behaviour. 
* Added the `get_premission_object()` hook, so that can be overridden. 

Both of these have small footprints and no breaking changes. So I think +1 
yes. 

My only concern thus far is bringing out the change well enough in the 
release notes and docs. 
(Split between the two PRs I'm not sure it quite does that.) 

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/a544987a-1a6a-4d5b-81e0-db8783f597aa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to extend support for object permission

[Carlton Gibson]

OK, makes sense. 

My current thinking is to Accept both. Perhaps you could put docs changes 
you'd make in a third PR (or ticket if you like, to discuss the outline)?
(Maybe one PR with three commits makes it easier to review as a whole.) 

Thanks for the input! 

On Thursday, 8 November 2018 11:55:54 UTC+1, Tobias Bengfort wrote:
>
> On 08/11/2018 11:43, Carlton Gibson wrote: 
> > My only concern thus far is bringing out the change well enough in the 
> > release notes and docs. 
> > (Split between the two PRs I'm not sure it quite does that.) 
>
> My impression is that authentication backends and object permissions 
> have already been underdocumented before these changes. I would like to 
> help improving the documentation in general. However, the content and 
> structure of the documentation could be very different depending on 
> which of my changes get accepted. So my idea was to rework the 
> documentation afterwards. 
>
> 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/747af93e-4798-47fe-a809-beec551b8162%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Postgres PGCrypto in Django?

[Carlton Gibson]

Hi Peter, 

Thanks for the follow-up here. For me, optional field-level encryption 
would be a cool addition. 
 
Can I solicit some opinions: 

* Do we think this would merit a place in `contrib.postgres` (vs the 
third-party package)?
* Postgres buffs: any comment on the actual implementation?  

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/7307627b-802e-4824-a488-d913a5890df8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Extending django.contrib.auth.models Group name to be 191 character max_length

[Carlton Gibson]

(Before I start, I'm +1 but... )

Just having a quick go over the history here...

* Original discussion floated a change to 100 or 150 chars. 
* Aymeric valued fixing the issue for 99.999% of cases. 
* Tom Christie wanted an "human value", not a machine one. 100 chars 
was suggested. 
* Florian said 150 chars, still human, a bit longer. 
* This didn't get resolved. 

* 
https://code.djangoproject.com/changeset/15ef1dd478c5b6f005e5f782b7619f718ed55e84
 
set the limit to 254 chars for User.username.
* Comment at https://code.djangoproject.com/ticket/20846#comment:25 begins, 
"This patch breaks on MySQL..." — some discussion of using 191 chars. 
* 
Eventually 
https://github.com/django/django/commit/780bddf75b93784470a2e352ed44ee35a751d667
 
reduces the limit to 150 chars. 

* 
https://github.com/django/django/commit/d5b573d872bbe0d5825efaee2d41cb3cdc75417b
 
follows suit (to 150 chars) for `last_name`

Current state of play is that username and last_name are 150 chars. 
first_name is still 30 chars. 
https://github.com/django/django/blob/ff8020ed49571b0fece67d10d7398d5f57cbaa74/django/contrib/auth/models.py#L288-L308

I don't know what's going on with first_name but I think 150 chars is the 
go-to value here. 

(Hey, nice  )

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/d675e31b-60bc-4dbc-ada0-eb4dda78d311%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: easy pcikings

[Carlton Gibson]

Hi Abhith. 

Have a look at the Triage Workflow 
docs: 
https://docs.djangoproject.com/en/dev/internals/contributing/triaging-tickets/#triage-stages

For each stage of the ticket's lifecycle they give you what's next. (e.g. 
if it's "New", can you reproduce the issue so it can move to "Accepted", if 
"Accepted", does it have a patch, and can you add one. And so on.) 

If seems complicated but mostly it's just "Is this a real issue?" and "Can 
I fix it?" 

Assuming it can be reproduced, creating a Unit Test is the next best 
step: 
https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/unit-tests/#unit-tests
Often, once there's a failing test, the fix won't be far away. 

Make sure you read the Advice for New 
Contributors: 
https://docs.djangoproject.com/en/dev/internals/contributing/new-contributors/

And if you get stuck, email 
django-core-mentorship: 
https://groups.google.com/forum/#!forum/django-core-mentorship 
— that's the place for help with contributing. 
Make sure you include as much details as you can (e.g. ticket number, where 
you've got to and any errors you're seeing etc) — the more detail you can 
provide the easier it is to help you. 

I hope that gets you started, and welcome aboard! 

Kind Regards,

Carlton


On Sunday, 4 November 2018 14:53:07 UTC+1, aby...@gmail.com wrote:
>
> Hi i am Abhith,iam new to django and i have read the newcomers guide.
> I found an open ticket under new pickings.But i dont know what to do next
> Can someone pls guide me.
> 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/4df73f5d-2b27-4a58-8c8b-d9947cdf326a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Can we remove FILE_CHARSET?

[Carlton Gibson]

Thanks for the input everyone. 

So Jon, are you basically saying that Vasili's concern shouldn't come up? 
(That the whole "SQL data files" bit is misleading...?)

-- 
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/6d555b4d-0b38-452c-8f40-8e690f9b33a6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Can we remove FILE_CHARSET?

[Carlton Gibson]

Thanks for the follow-up Jon. 

I'll let Vasili follow-up on his use-case if possible/relevant. 

TBH I'm not at all sure about the SQL data files bit, which is in part why 
I asked here. 
(Encoding issues!) 

> Maybe that sentence should be rephrased to "template
files, static files, and translation catalogs".

OK, so IF it's just this, then I'm on Windows doing development in UTF-8 no 
problem (and can't really envisage doing much different as it stands) but: 

* Is that always available these days? (I'd guess yes.)
* Is is something we want to impose? Not sure. Are there people doing 
otherwise? (No idea.)

(If we can drop a setting, that'd be )

-- 
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/13cc5f04-967b-4f53-92f6-cbe155014edc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Django bugfix releases 1.11.16 and 2.0.9

[Carlton Gibson]

Details are available on the Django project weblog: 
https://www.djangoproject.com/weblog/2018/oct/01/bugfix-releases/ 


-- 
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/F0053153-780F-4D11-953F-FA5EFFC3D486%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Django security release issued: 2.1.2

[Carlton Gibson]

Today the Django team issued 2.1.2 as part of our security 
process. This release address a security issue, and we encourage all 
users to upgrade as soon as possible: 

https://www.djangoproject.com/weblog/2018/oct/01/security-release/ 


As a reminder, we ask that potential security issues be reported via 
private email to secur...@djangoproject.com  
and not via Django's Trac 
instance or the django-developers list. Please see 
https://www.djangoproject.com/security  
for further information. 

-- 
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/361FBF25-F849-47A9-AA24-3717B465F75F%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adjusting Django's security notification policy

[Carlton Gibson]

On Sunday, 30 September 2018 06:51:41 UTC+2, James Bennett wrote:
>
> Does anyone else have feedback on this? I'd like to push it forward.
>

I don't know if this would fly but, given that pre-notification is mainly 
thought of for large-scale ("enterprise"?) deployments that can't 
realistically "Just Update!", 
could we make Corporate Sponsorship of the DSF a requirement for 
pre-notification? (These are big companies, with payroll. A sponsorship is 
loose change in this context, and may at least encourage trying to 
update...) 

(Just a thought.) 

C.

-- 
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/b3f4aa4c-9b00-41ac-8668-87ffa570f2d6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Can we remove FILE_CHARSET?

[Carlton Gibson]

> FILE_CHARSET (default:'utf-8') 
> The character encoding used to decode any files read from disk. This 
includes template files and initial SQL data files.

Is there anywhere where this isn't UTF-8? (Or can't be decreed to be so?)

Jon has a suggestion to remove it:

Ticket: https://code.djangoproject.com/ticket/29817
PR: https://github.com/django/django/pull/10472/

Claude on GitHub: 


> You preach to a convert! However it's not about not being able to encode 
in UTF-8, but about the common file encoding on some platforms, especially 
Windows. I'm not using Windows for a long time now, so I can't say if UTF-8 
is a common encoding nowadays or if it needs a special handling (say change 
a program preference) in most Windows text editors.

Do you know about this? Can I ask for your input here? 

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/38cf5604-106b-4e06-a1f0-796b7bd071c0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Fellow Reports -- September 2018

[Carlton Gibson]

Hi all,


Calendar Week 37 -- ending 16 September.


Triaged:

https://code.djangoproject.com/ticket/29758 -- Document testing custom 
error handlers (Accepted)
https://code.djangoproject.com/ticket/29750 -- Add a pre-dispatch() hook 
for class-based views (Accepted)


Reviewed:

https://code.djangoproject.com/ticket/11154 -- Inconsistency with 
permissions for proxy models
https://code.djangoproject.com/ticket/29711 -- Add system check to ensure 
uniqueness of admin actions' __name__.
https://code.djangoproject.com/ticket/29755 -- Infinite migrations created 
after removing Meta.default_related_name
https://code.djangoproject.com/ticket/14357 -- Prevent inappropriate 
order-based grouping on values+annotate queries
https://code.djangoproject.com/ticket/29538 -- Query Expression in ordering 
of a related object fails
https://code.djangoproject.com/ticket/29724 -- Admin date_hierarchy filter 
by month displays an extra day
https://code.djangoproject.com/ticket/29746 -- FlatpageForm help_text is 
misleading when APPEND_SLASH is False
https://code.djangoproject.com/ticket/29573 -- Add link from per-item 
aggregation topic discussion to `annotate()` ref.
https://code.djangoproject.com/ticket/16995 -- ModelFormSet initial data 
from initial parameter uses "extra" forms


Authored:

https://github.com/django/django/commit/bf39978a53f117ca02e9a0c78b76664a41a54745
-- Fixed CVE-2018-16984 -- Fixed password hash disclosure to admin 
"view only" users.




Calendar Week 38 -- ending 23 September.


Triaged:

https://code.djangoproject.com/ticket/29776 -- Pulling part of 
django.conf.settings from the database (wontfix)
https://code.djangoproject.com/ticket/29775 -- custom url converters are 
not picked up on reverse when part of included patterns with namespace 
(Accepted
)
https://code.djangoproject.com/ticket/29768 -- Confusing error when 
AppConfig subclass's name is misspelled (Accepted)


Reviewed:

https://code.djangoproject.com/ticket/29778 -- Unique index cannot be 
created for db table, whose name should be quoted
https://code.djangoproject.com/ticket/29765 -- Mention 
MIDDLEWARE/INSTALLED_APPS order is important in settings.py
https://code.djangoproject.com/ticket/29767 -- Django ORM: Cast between 
datetime and date.
https://code.djangoproject.com/ticket/11154 -- inconsistency with 
permissions for proxy models
https://code.djangoproject.com/ticket/20147 -- Provide an alternative to 
request.META for accessing HTTP headers
https://code.djangoproject.com/ticket/29761 -- GIS test failures



Calendar Week 39 -- ending 30 September.


Triaged:

https://code.djangoproject.com/ticket/29797 -- Allow the makemessages 
command to accept a directory to operate on like xgettext does (wontfix)
https://code.djangoproject.com/ticket/29798 -- truncatewords_html fails on 
some self-closing tags (Invalid)
https://code.djangoproject.com/ticket/29799 -- Allow registration and 
unregistration of lookups per field instances. (Accepted)
https://code.djangoproject.com/ticket/29782 -- Better error message when 
filtering users with AnonymousUser (Accepted)
https://code.djangoproject.com/ticket/29785 -- Using {{ csrf_token }} 
throws exception (AttributeError: 'dict' object has no attribute 'META') if 
no render context (Invalid)
https://code.djangoproject.com/ticket/29784 -- Review and update the 
external links in the settings reference documentation (Accepted)


Reviewed:

https://github.com/django/django/pull/10458 -- Updated naturaltime 
translation test.
https://github.com/django/django/pull/10448 -- Avoid starting a transaction 
when only a single (or atomic queries) are executed.
https://github.com/django/django/pull/10446 -- Refs #28909 -- Simplifed 
code using unpacking generalizations.
https://code.djangoproject.com/ticket/29758 -- Document testing custom 
error handlers
https://github.com/django/django/pull/10381 -- Fixed #11154 and #17904 -- 
Inconsistency with permissions for proxy models
https://github.com/django/django/pull/10430 -- Refs #29784 -- Switched to 
https:// links where available.



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/5b571a79-0bdd-48ce-a364-29c177f97f62%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adding a database-agnostic JSONField into Django

[Carlton Gibson]

This has come up again, with an example implementation for Oracle: 

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

Anyone know of an SQLite implementation?



-- 
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/215a0e1c-6947-4375-ba1d-38d310c32411%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adding a database-agnostic JSONField into Django

[Carlton Gibson]

Sorry, what I meant was a Django field. (I wasn't clear enough.) 

Charles Leifer has good posts covering SQLite+JSON http://charlesleifer.com/
His Peewee ORM has a 
JSONField http://docs.peewee-orm.com/en/latest/peewee/sqlite_ext.html#sqlite-ext

I was just wondering if someone knew if someone had already wrapped up a 
Django equivalent?

(If so we'd have reference implementations for all the supported DBs...)

On Thursday, 4 October 2018 13:12:42 UTC+2, Jon Dufresne wrote:
>
> > Anyone know of an SQLite implementation?
>
> A quick search shows the JSON1 extensions exists:
> https://www.sqlite.org/json1.html
>
> According to the release history (https://sqlite.org/changes.html) this 
> was added in version 3.9.0 (2015-10-14).
>
> But I have no direct experience working with it.
>
> On Thu, Oct 4, 2018 at 12:19 AM Carlton Gibson  > wrote:
>
>> This has come up again, with an example implementation for Oracle: 
>>
>> https://code.djangoproject.com/ticket/29821
>>
>> Anyone know of an SQLite implementation?
>>
>>
>>
>> -- 
>> 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/215a0e1c-6947-4375-ba1d-38d310c32411%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/django-developers/215a0e1c-6947-4375-ba1d-38d310c32411%40googlegroups.com?utm_medium=email_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/593cb04e-6de6-4ccd-9b8d-d175f95d970f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adjusting Django's security notification policy

[Carlton Gibson]

Yes. That all sounds reasonable. 

We DO timely releases to all (and we pre-announce so people know they’re 
coming). 

It’s just this extra category of people who get the patch separately, early. 
There’s extra overhead in that. And it removes one motivation to update. 

I’m kind of inclined to advocate the RoR approach or no pre-notification, but I 
accept the argument that in big enterprises it’s just not realistic to require 
people to keep up to date. It just feels like $$$ outsourcing work they should 
be doing without actually covering the cost of that. 

I don’t see it as pay-for-access: beyond getting pre-notification you get no 
privileges. More it’s due-diligence. Using end-of-life software is arguably 
negligent. Companies doing it just need to take on the extra costs. 

However… those are just thoughts… the wind goes the other way. No problem! 

Thanks both. 

> On 3 Oct 2018, at 11:17, Markus Holtermann  wrote:
> 
> Can: yes. Should: no.
> 
> I would be really saddened to see companies being able to buy security by 
> throwing money at us. That makes us look like we can be bought. And that 
> sends the wrong signal, from my perspective. Timely security updates should 
> be available to everyone. 
> 
> Should enterprises sponsor the DSF, open source projects, or the open source 
> community in general: yes, absolutely.
> 
> What we could think about is something where companies above a yearly revenue 
> of US$ x need to sponsor in order to be on a pre-notification list. But the 
> moment we do that we put people's data at risk. A company that doesn't want 
> to pay for that sponsorship and thus won't get pre-notifications may remain 
> on an insecure version longer that they should or would if they had received 
> a pre-notification. And that's terrible as well.
> 
> My 2¢
> 
> Markus
> 
> On Wed, Oct 3, 2018, at 9:14 AM, Carlton Gibson wrote:
>> 
>> On Sunday, 30 September 2018 06:51:41 UTC+2, James Bennett wrote:
>>> 
>>> Does anyone else have feedback on this? I'd like to push it forward.
>>> 
>> 
>> I don't know if this would fly but, given that pre-notification is mainly 
>> thought of for large-scale ("enterprise"?) deployments that can't 
>> realistically "Just Update!", 
>> could we make Corporate Sponsorship of the DSF a requirement for 
>> pre-notification? (These are big companies, with payroll. A sponsorship is 
>> loose change in this context, and may at least encourage trying to 
>> update...) 
>> 
>> (Just a thought.) 
>> 
>> C.
>> 
>> -- 
>> 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/b3f4aa4c-9b00-41ac-8668-87ffa570f2d6%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/AAC3433C-65FF-41AD-AB40-C53EF7A6FB02%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Fellow Reports -- January 2019

[Carlton Gibson]

Hi All, 



Calendar Week 2 -- ending 13 January.



Triaged:


https://code.djangoproject.com/ticket/30097 -- 
InlineModelAdmin.has_add_permission() requires obj argument (Accepted)

https://code.djangoproject.com/ticket/30096 -- Use case of extra() (invalid)




Reviewed:


https://github.com/django/django/pull/10381 -- Fixed #11154, #17904 and 
#22270 -- Inconsistency with permissions for proxy models

https://code.djangoproject.com/ticket/28554 -- Add support for multiple 
file fields

https://code.djangoproject.com/ticket/29943 -- Document that admin 
changelist adds `pk` to ordering.

https://github.com/django/django/pull/10692 -- Refs #17198 -- Detected 
existing total ordering in admin changelist.

https://code.djangoproject.com/ticket/20147 -- Provide an alternative to 
request.META for accessing HTTP headers

https://code.djangoproject.com/ticket/23829 -- Allow customizing the 
`ping_google` URL



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/5d3af7c7-dd41-49a3-bcc7-7c845d4e8a93%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: status of 2.2 release blockers

[Carlton Gibson]

Hi Vaclav, 

I think current status is "Still work to do" there, so not really... 

C. 

On Wednesday, 16 January 2019 17:52:17 UTC+1, Václav Řehák wrote:
>
> Hi,
>
> is it possible to get this fix included in 2.2?
>
> https://github.com/django/django/pull/10643 - Fixed #29915 -- Support 
> hyphens in UUIDField filtering
>
> Vaclav
>
> Dne pondělí 14. ledna 2019 3:04:29 UTC+1 Tim Graham napsal(a):
>>
>> Time to kick off the progress tracker for the next major release!
>>
>> The 2.2 feature freeze is scheduled (according to 
>> https://code.djangoproject.com/wiki/Version2.2Roadmap) for tomorrow, 
>> January 14. Typically we've released the alpha a few days later to finish 
>> up a few last minutes things.
>>
>> I have a few patches I want to finish reviewing:
>>
>> https://github.com/django/django/pull/10840 - Refs #28478 -- Adjusted 
>> prevention of connections to disallowed databases. (regression fixes)
>> https://github.com/django/django/pull/10381 - Fixed #11154, #17904 and 
>> #22270 --  Inconsistency with permissions for proxy models
>> https://github.com/django/django/pull/10171 - Fixed #20147 -- Added 
>> HttpRequest.headers.
>> https://github.com/django/django/pull/8981 - Fixed #9475 -- allow add(), 
>> create(), etc for m2m with through
>>
>> I guess Claude will also like to update translations catalogs as he did 
>> for 2.1.
>>
>

-- 
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/1dccf9db-f6de-4c9b-a936-dae5768f31cd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Carlton Gibson]

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 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/59493dc3-881e-4728-9f9d-d816195ac803%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Carlton Gibson]

> On 18 Jan 2019, at 17:20, Santiago Basulto  wrote:
> 
> Seems like everybody agrees that for large sites, it's necessary.

Hang on, slow down. 

Personally, I’m not sure it’s too onerous as-is. I’ve not yet seen exactly why 
subclassing ModelAdmin in one’s project isn’t good enough. It really depends on 
with the “it” is “it’s necessary” is taken to mean…

- Better examples in docs: Great, no problem. 
- **More** API on ModelAdmin: OK, maybe, but what does that look like exactly? 
- A setting: Really? Do we have to? Can we explore other options first?

Both the docs and adjustments to ModelAdmin options could be pushed forward 
with a PR. “Better handling of FK widgets for fields with large counts” — 
sounds great, but what does that involve?

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/9A970D0F-B329-4D54-B89F-40536F0A03F1%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Carlton Gibson]

> On 19 Jan 2019, at 11:48, Santiago Basulto  wrote:
> 
> Haha, sorry, got overly excited. What's the usual process to make these sort 
> of decisions in these cases? Should we ask the users list?

No problem. :)

We make decisions here. Say you’d have opened a Trac ticket for this, I’d have 
probably said `needsinfo`. So same as I’m saying here, we need to pin down 
what’s being proposed. 

> The setting proposal is purely from my perspective as a user. For *my* 
> (completely unilateral) point of view, this is very important and I'd love to 
> have a place to just flip a switch and change them all; well, I'd even prefer 
> for it to be the default behavior, but I know selects look cool too.
> 
> Now, from a "development" perspective, I do understand that it might be a big 
> change.

Adding a setting may not be any harder than creating a subclass: the underlying 
implementation may look virtually identical. But in that case it’d be likely 
we’d favour the subclass, since a setting is a bit like a sledge-hammer — it’s 
probably overkill when you could just change an import and a superclass 
declaration. 

But, again, what does it look like? Is it better than (i.e. simple enough) 
providing a better example and letting people implement their own? 

FWIW, I think the default select is right for the vast majority of cases and is 
more useable by an order of magnitude. For me, it’s never really been an issue 
declaring raw_id_fields. (But yes, it does come up, so very happy to see 
suggestions.)

As Adam says, something like this could be put on PyPI, even if not in Django 
itself. Is there not something already I wonder? 

Don’t be discouraged. Please pursue the thought if you want it: implement 
something, open a PR, let’s discuss! 

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/541532A8-32DB-4760-B82B-1F63FE16CC07%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Introduction GSoC

[Carlton Gibson]

Hi Folks. 

First off: can we please keep it civil. Let's offer positive responses 
where possible. Thanks 

There's no harm in people asking for help: there is a contributing guide, 
but if folks aren't finding it, perhaps we need a bigger sign-post.  

So...

The place to begin is 
here: https://docs.djangoproject.com/en/dev/internals/contributing/

See the Development Dashboard: https://dashboard.djangoproject.com

Looking at Unreviewed Tickets on the issue tracker and helping to Triage 
them is super helpful. 
That's a good place to get familiar. 

That doesn't make a GSoC project, so looking through Accepted tickets (take 
your time! ) 
would be a good place to look for ideas. 

I don't think we have a ready list of GSoC-scale project ideas we can point 
you to I'm afraid. (Anyone?)

I hope that at least gets you started. 

Welcome aboard! 

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/18569029-82a3-494c-ab06-6c0a958eb2b4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.