Re: Thoughts on Django Model attribute (descriptor) inheritance.

2019-06-21 Thread Carlton Gibson
Hi Ryan, 

That does look related, yes. 

On Friday, 21 June 2019 15:47:53 UTC+2, Ryan Hiebert wrote:
>
> Hopefully that's a correct connection, and I'm not sending you chasing 
> something irrelevant to your current task.
>

TBH any pointers are handy at this stage in the game. 

Thanks! 

(Still interested in hearing what original thoughts were if anyone _can_ 
dig them up in the grey-matter...)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c35f0b82-5b82-4cfb-bd98-4756ee93dea9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Thoughts on Django Model attribute (descriptor) inheritance.

2019-06-21 Thread Carlton Gibson
Hi All

Can I ask folks to have a look at this please? 

Ticket is: https://code.djangoproject.com/ticket/30427
PR is: https://github.com/django/django/pull/11337

The original change that introduced the current behaviour is 
https://github.com/django/django/pull/6491/files#diff-bf776a3b8e5dbfac2432015825ef8afeR699

*Question: *What was the reason for this comment: 

# Don't override classmethods with the descriptor. This means that
# if you have a classmethod and a field with the same name, then

#such fields can't be deferred (we don't have a check for this).


In case it rings any bells...

PR there was called:

"Replaced dynamic classes with non-data descriptors for deferred 
instance loading."

Related mailing list discussion: 
https://groups.google.com/forum/#!msg/django-developers/BDAlTyJwQeY/Fh2Qy07cAQAJ

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/94d1f059-8cb2-435b-be52-66d3ae1a4721%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Fellow Reports -- June 2019

2019-06-17 Thread Carlton Gibson
Hi all, 



Calendar Week 24 -- ending 16 June.


Triaged:

https://code.djangoproject.com/ticket/30566 -- Unable to do key lookup when 
a key is a number on PostgreSQL JSONB field (wontfix)
https://code.djangoproject.com/ticket/30527 -- Problem with creating 
migrations for subclassed field changes. (Invalid)
https://code.djangoproject.com/ticket/30207 -- Optimise paginator for 
tables with massive records (Needsinfo)
https://code.djangoproject.com/ticket/30554 -- Excessive logging by 
autoreload in v 2.2.1 and 2.2.2 (Invalid)



Reviewed:

https://code.djangoproject.com/ticket/12952 -- Models history doesnt 
use verbose names
https://code.djangoproject.com/ticket/30066 -- UserManager.create_superuser 
doesnt allow for omitting email or password, unlike create_user which 
does.
https://code.djangoproject.com/ticket/30547 -- Document what happens during 
model validation with Meta.constraints.
https://github.com/django/django/pull/11209 -- Fixed #30451 -- Implemented 
ASGI handler and coroutine-safety.
https://github.com/django/django/pull/11417 -- Fixed #30512 -- Used 
email.headerregistry.parser for parsing emails in sanitize_address().
https://github.com/django/django/pull/10910 -- Fixed #30128 -- Fixed 
handling timedelta timezone in database functions.
https://code.djangoproject.com/ticket/30128 -- Using database functions 
with tzinfo=datetime.timezone(datetime.timedelta(...)) results in an 
incorrect query
https://github.com/django/django/pull/11468 -- Added missing support for 
PointOnSurface function on MariaDB.
https://code.djangoproject.com/ticket/30553 -- Misleading logging 
documentation about disable_existing_loggers default value.



Authored:

https://github.com/django/django/pull/11472 -- Refs #30512, #15042 -- Added 
local-only address to sanitize_email() tests cases.



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/a7a3121d-37eb-43b8-93ca-34463f61bf03%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: How to test whether a formset instance is properly initialized

2019-06-15 Thread Carlton Gibson
Hey Parth, 

>  I'm currently using a python shell to create objects and then check manually 
> its attributes, etc.

More or less, do the same thing, but in a test case. 

# Declare class

# Create instance

# self.assertEqual()/assertIs()/etc expected attributes. 
# … same but for behaviour too. (Give it some data, is_valid(), etc)

Look in tests/forms_tests/tests/test_formsets/py::FormsFormsetTestCase. 
There are cases there using formset_factory(). Your versions will just declare 
the FormSet instead. 

Hope that helps.
If you have difficulties, open a PR with what you’ve got: it may be easier to 
help you there. 

Kind Regards,

Carlton


> On 15 Jun 2019, at 07:04, PARTH PATIL  wrote:
> 
> I'm currently working on ticket #10403 
>  -- Declarative syntax for 
> Formsets
> 
> How to test whether a formset instance is correctly initialized??
> 
> The thing which I'm trying to achieve is to initiate a formset without using 
> formset_factory(). I'm able to create objects of class derived from the 
> BaseFormSet, but its really difficult for me to check whether it is properly 
> initiated or not as expected from a formset instance.
> 
> Should I write tests for this??
> And if yes, which all parameter values should I assert in the test to 
> conclude that my formset instance is indistinguishable from the one created 
> using formset_factory.
> 
> Also is there any better way to test this? I'm currently using a python shell 
> to create objects and then check manually its attributes, etc. which I know 
> is not a good way. 
> 
> -- 
> You received this message because you are subscribed to the Google 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/583effcf-041e-4d30-9693-62a8f9559901%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/9EE0DD77-54A3-4E41-8175-ACD275C5E0A4%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


Fellow Reports -- June 2019

2019-06-10 Thread Carlton Gibson
Hi All. 


Calendar Week 23 -- ending 09 June.


Released Django versions 2.2.2, 2.1.9 & 1.11.21. 



Triaged:

https://code.djangoproject.com/ticket/30555 -- Migration files generated do 
not follow PEP8 E501 rule (wontfix)
https://code.djangoproject.com/ticket/30475 -- Use of i18n_patterns and a 
buggy 404 template trigger internal server error without a backtrace. 
(Invalid)
https://code.djangoproject.com/ticket/30515 -- Document 
django.shortcuts.resolve_url. (wontfix)
https://code.djangoproject.com/ticket/30536 -- Allow running custom logic 
in django.setup(). (Accepted)



Reviewed:

https://code.djangoproject.com/ticket/29834 -- Union queryset with ordering 
breaks on ordering with derived querysets
https://code.djangoproject.com/ticket/29444 -- Allow fields to be part of 
the RETURNING clause during INSERT
https://code.djangoproject.com/ticket/29379 -- Add autocomplete attribute 
to contrib.auth fields
https://code.djangoproject.com/ticket/28567 -- Incompatibility between the 
set_language() view, LocaleMiddleware, and i18n_patterns() when 
prefix_default_language=False.
https://github.com/django/django/pull/11442 -- Fixed #28567 -- Added 
examples of redirect_to context variable when using set_language() view.
https://github.com/django/django/pull/11439 -- Removed redundant object 
descriptions to prevent warnings with Sphinx 2.1.0.
https://github.com/django/django/pull/11435 -- Refs #30536 - Make 
django.setup() idempotent and tweakable




Authored: 

https://github.com/django/django/commit/deeba6d92006999fee9adfbd8be79bf0a59e8008
--  Fixed CVE-2019-12308 -- Made AdminURLFieldWidget validate URL 
before rendering clickable link.
https://github.com/django/django/commit/34ec52269ade54af31a021b12969913129571a3f
-- Applied jQuery patch for CVE-2019-11358. 


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/a658c4a9-6880-488a-983d-290a6f34e3ab%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Django security releases issued: 2.2.2, 2.1.9 and 1.11.21

2019-06-03 Thread Carlton Gibson
Today the Django team issued 2.2.2, 2.1.9, and 1.11.21 as part of our security 
process. These releases address security issues, and we encourage all users to 
upgrade as soon as possible: 

https://www.djangoproject.com/weblog/2019/jun/03/security-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/8A290D5D-F090-4323-8587-79B4B66E7587%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Fellow Reports -- May 2019

2019-05-31 Thread Carlton Gibson


Hi all. 


Calendar Week 22 -- ending 02 June.



Triaged:


https://code.djangoproject.com/ticket/30509 -- Various FileResponse fixes 
and changes (Accepted)

https://code.djangoproject.com/ticket/30530 -- url `path` accepts newlines 
in various places. (wontfix)

https://code.djangoproject.com/ticket/30514 -- Occasional CSRF cookie not 
set Django 2.1 (needsinfo)

https://code.djangoproject.com/ticket/30528 -- Django Admin adds Javascript 
in different sequences (Duplicate of #30153/#30179)




Reviewed:


https://code.djangoproject.com/ticket/30064 -- Admin search with a null 
character crashes with A string literal cannot contain NUL (0x00) 
characters. on PostgreSQL

https://github.com/django/django/pull/11432 -- Simplfied 
m2m_recursive.tests.

https://github.com/django/django/pull/11414 -- Fixed #30509 -- Various 
FileResponse fixes and changes.



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/da6647d0-e5e6-47db-98fd-e7a9b84aefb5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Fellow Reports -- May 2019

2019-05-28 Thread Carlton Gibson
Hi all. 


Calendar Week 19 -- ending 12 May.


Triaged:

https://code.djangoproject.com/ticket/30472 -- Argon2id should be supported 
and become the default variety for Argon2PasswordHasher (Accepted)
https://code.djangoproject.com/ticket/30469 -- Boolean False becomes NULL 
with recent mysql-connector-python (Invalid)
https://code.djangoproject.com/ticket/30470 -- Complete assertHTMLEqual() 
support for all self closing tags (Accepted)
https://code.djangoproject.com/ticket/30468 -- assertHTMLEqual doesnt 
account for all ASCII whitespace in a class attribute. (Accepted)
https://code.djangoproject.com/ticket/30467 -- `makemigrations app_label` 
sometimes tries to create migrations for unrequested app_label (invalid)
https://code.djangoproject.com/ticket/30449 -- Ordering problem in 
admin.RelatedFieldListFilter and admin.RelatedOnlyFieldListFilter (Accepted)
https://code.djangoproject.com/ticket/30453 -- Djangos template 
library tags cant use already decorated things like lru_cache because of 
getfullargspec (needsinfo)
https://code.djangoproject.com/ticket/30466 -- FieldFile.save documentation 
is misleading (wontfix)
https://code.djangoproject.com/ticket/30459 -- If a StackedInline has 
fieldsets with the collapsed class, the Show link 
doesnt work on inline forms added with the Add another [inline 
object] link (Accepted)
https://code.djangoproject.com/ticket/30463 -- Deprecation message crashes 
when using a query expression in Model.ordering. (Accepted)
https://code.djangoproject.com/ticket/30457 -- on_commit should be 
triggered in a TestCase (Accepted)



Reviewed:

https://github.com/django/django/pull/11353 -- Fixed #30459 - Delegated 
hide/show JS toggle to parent div
https://github.com/django/django/pull/11348 -- Fixed #30470 -- Added 
assertHTMLEqual() support for all self closing tags.
https://github.com/django/django/pull/11346 -- Fixed trivial source comment 
typo.
https://github.com/django/django/pull/11344 -- Refs #27804 -- Used 
subTest() in HTMLEqualTests.test_self_closing_tags.
https://github.com/django/django/pull/11345 -- Fixed #30468 -- Fixed 
assertHTMLEqual() to handle all ASCII whitespace in a class attribute.
https://github.com/django/django/pull/11165 -- Fixed #30310 -- Added 
support for looking up HttpHeaders.headers using underscores.
https://github.com/django/django/pull/11343 -- Refs #30399 -- Made 
assertHTMLEqual normalize character and entity references.
https://code.djangoproject.com/ticket/27086 -- running servers.tests may 
hang in parallel mode on Mac OS X
https://github.com/django/django/pull/11209 -- Fixed #30451 -- Implemented 
ASGI handler and coroutine-safety.
https://github.com/django/django/pull/9884 -- Fixed 29336 -- Added docs for 
circular template inheritance.



Authored:

https://github.com/django/django/pull/11336 -- Removed redundant check from 
StaticFilesHandler.





Calendar Week 20 -- ending 19 May.


Triaged:

https://code.djangoproject.com/ticket/30475 -- Use of i18n_patterns and a 
buggy 404 template trigger internal server error without a backtrace 
(needsinfo)
https://code.djangoproject.com/ticket/30481 -- Document that force_text() 
allows lone surrogates. (Accepted)
https://code.djangoproject.com/ticket/30478 -- Do not require npm installed 
for JavaScript tests (tox -e javascript) (wontfix)



Reviewed:

https://github.com/django/django/pull/11374 -- Fixed #30485: Fixed 
django.utils.http.urlencode in the doseq=False case.
https://code.djangoproject.com/ticket/25633 -- GeoDjango KyngChaos 
installation instructions are outdated
https://code.djangoproject.com/ticket/30196 -- Make FileResponse always set 
Content-Disposition header.
https://code.djangoproject.com/ticket/30199 -- get_or_create documentation 
encourages unsafe usage
https://github.com/django/django/pull/11370 -- Make it very clear where 
LOGGING setting goes - be consistent.
https://code.djangoproject.com/ticket/30486 -- Custom aggregate function 
example needs updating for Django 2.2s `allow_distinct`
https://github.com/django/django/pull/11373 -- Fixed typo and added 
allow_distinct in docs/ref/models/expressions.txt
https://github.com/django/django/pull/11371 -- Fixed #30483 -- Switched 
test requirement to psycopg2 package.
https://code.djangoproject.com/ticket/30220 -- Use headless browsers for 
selenium tests.
https://github.com/django/django/pull/11362 -- Changed tuple choices to 
list in docs.
https://github.com/django/django/pull/11363 -- Changed docs to link to 
Pythons description of iterable.
https://github.com/django/django/pull/11366 -- Fixed mis-capitalisation in 
comment.



Authored:

https://github.com/django/django/pull/11353 -- Fixed #30459 - Delegated 
hide/show JS toggle to parent div.




Calendar Week 21 -- ending 26 May.


Triaged:

https://code.djangoproject.com/ticket/30505 -- rdering of Field.choices is 
significant for makemigrations (Accepted)
https://code.djangoproject.com/ticket/30504 -- Order of arguments on 
redirect incorrect on 

Re: Introduction

2019-05-11 Thread Carlton Gibson
Thank you Tobias. Good explanation.

An additional point I picked up from Tim is that if you have a Reproduced
at... but the bug is fixed on master then you have a starting point to git
bisect where the issue was fixed.

On Sat, 11 May 2019 at 15:28, Tobias Kunze  wrote:

> Hi Ruchit,
>
> On 19-05-10 23:19:16, Ruchit Vithani wrote:
> >I have following queries regarding tickets on Trac. In many of the
> tickets,
> >some people comment `Regression in` and `Reproduced at`, and both of them
> >link to some commit on GitHub. I could not understand what these links
> >specify.
>
> The "regression in" comments point to commits that have either
> introduced or re-introduced the issue in the ticket. Regressions are
> explained in the contributing documentation, including a guide on how to
> figure out which commit caused the regression:
> <
> https://docs.djangoproject.com/en/2.2/internals/contributing/triaging-tickets/#bisecting-a-regression
> >
>
> This is helpful because it gives you a start when trying to fix the
> issue. You can look at the causing commit, and figure out if this
> behaviour was intentional, if it was discussed in the ticket referenced
> in the commit, if it was accidental, etc. It also helps you to develop a
> fix that doesn't break anything else unintentionally. So even if you
> don't have the time or experience to find a fix, finding and noting
> which commit caused a regression can be very helpful.
>
> The 'reproduced at' comments are indeed not mentioned in the triage
> documentation – maybe you could add them?  Sometimes people add comments
> like that when they accept a ticket, for better documentation of why
> they decided to accept a ticket. There is a note about this workflow
> here:
> https://docs.djangoproject.com/en/2.2/internals/contributing/new-contributors/
>
> They can also be useful with old tickets: With more than a thousand
> open tickets, and most of them older than the last one or two releases,
> it's not always obvious that an issue still persists. (For instance, I
> recently came across a ticket that called for the introduction of
> template-based form rendering, which has been part of Django for some
> time now.) Adding a comment that the issue still persists currently (and
> linking to the tested commit for reference) can be helpful to show that
> an 8 year old bug is still relevant.
>
> I hope this helps,
> 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/20190511132755.gmpmcetv33npqlji%40cordelia.localdomain
> .
> 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/CAJwKpyRmus1j7xwz2NEjbzUYN1ncft0vu0uCqh6x8_xsebnCxA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Introduction

2019-05-08 Thread Carlton Gibson
Hi Ruchit, 

Welcome aboard! 

There's a whole section on finding a ticket in the talk I gave at DjangoCon 
Europe recently. Check it out: 

https://www.youtube.com/watch?v=F4StlMFb5Ms

In the Trac you can filter by component which helps: 

https://code.djangoproject.com/query?status=assigned=new=contrib.admin=id=summary=status=owner=type=component=version=1=id

(That has the Admin selected, but you can change that.) 

If you get into specific issues getting started email django-core-mentorship 
 and we'll 
see if we can get you going. 

Good luck. Have fun! 

Carlton

On Wednesday, 8 May 2019 13:59:36 UTC+2, Ruchit Vithani wrote:
>
> Hello developers! My name is Ruchit Vithani and I am a student at DA-IICT, 
> Gandhinagar in India. I'm familiar with open source and I've also 
> contributed to some projects.  I'd love to be a part of this awesome 
> community and would like to contribute. I've read the contributing guide. 
> Can someone guide me on what to do next? Also, please inform me if there 
> are any other community platforms to chat and where should I pick my first 
> ticket to work on. 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/43b0b23f-793c-4a06-ab94-55aece5fe888%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: After #28321 len(formset.forms) != len(formset.errors) is possible

2019-05-08 Thread Carlton Gibson
Hi Carsten. 

Any chance you can put this into a failing test case in a PR? (Much easier 
to reason about code. ) 

Thanks. 
C. 

On Wednesday, 8 May 2019 13:58:25 UTC+2, Carsten Fuchs wrote:
>
> Dear group, 
>
> I just upgraded from Django 1.11 to 2+ and thereby found 
> https://code.djangoproject.com/ticket/28321 
> The ticket was resolved with commit 
> https://github.com/django/django/commit/f32d24652b920135eb6a0f3de74599f03e181731
>  
>
> Well, this change leaves us with a situation where `formset.forms` 
> possibly no longer aligns with `self.errors`. 
>
> Was that intended? 
>
> The original ticket reporter suggested that for a deleted form with 
> errors, an empty dict should be added to formset._errors in a formset's 
> full_clean(). This would have preserved the alignment of formset.forms and 
> formset.errors. 
>
> Note that the formset implementation often uses index-based iterations 
> over the forms which seems to suggest, although there is no other 
> indication or hint, that formset.forms[i] correlates to formset.errors[i] 
> for all valid i. (That was also my understanding from the documentation 
> before having looked at the implementation.) 
>
> [ In my application code I have the requirement that even deleted forms 
> must meet certain validation criteria. Therefore I relied on the Django 
> 1.11 / pre-#28321 behavior, where at the same time   formset.is_valid() == 
> True   and   any(formset.errors) == True   was possible. While I found this 
> undocumented, it was my preferred behavior. ] 
>
> Any thoughts? 
>
> Best regards, 
> Carsten 
>
>

-- 
You received this message because you are subscribed to the Google 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/a4703c73-6c25-46ef-a948-c3377057d09a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: injecting settings

2019-05-07 Thread Carlton Gibson
Also see the django-appconf 
app: https://github.com/django-compressor/django-appconf

This is used by django-compressor (hence it's home) and others to add (and 
allow overriding) per-app settings. 


-- 
You received this message because you are subscribed to the Google 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/0bda8e4a-d308-4da1-b34e-a0c7ed5c8621%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: GSoC Proposal: Add Cross-DB JSONField, ArrayField, and HStoreField

2019-05-07 Thread Carlton Gibson
Hey Sage, Hey Parth. 

First-off welcome on board! 

The goal for the next couple of weeks is to get more deeply involved, 
whilst I guess you start thinking about your projects too. You can follow 
here, the dashboard  and the timeline 
 — you don't need to be on top of 
it all!!! — to see what's going on. 

I'll email you off list to get the conversation started. Then I think using 
django-core-mentorship for group conversations isn't a bad idea, and then 
we can have you post periodically to django-developers here to report on 
progress, or if we need to ask questions more widely. 

Well done again. 

Kind Regards,

Carlton


On Tuesday, 7 May 2019 15:05:59 UTC+2, part...@gmail.com wrote:
>
> I had the same doubt in my mind, what is the best medium to contact 
> mentors?

-- 
You received this message because you are subscribed to the Google 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/8c4ab41c-5bf4-49c8-9d72-61434d03c0bd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: First ASGI pull request is ready for review

2019-05-01 Thread Carlton Gibson
Yes, I’ll review properly first half of next week.

For the DEP, can you break out how and where people might input. There’s
massive interest. 

Great work as ever Andrew. Thank you so much!

C.

On Wed, 1 May 2019 at 08:46, Andrew Godwin  wrote:

>
>
> On Tue, Apr 30, 2019 at 11:34 PM Mariusz Felisiak <
> felisiak.mari...@gmail.com> wrote:
>
>> Thanks for this patch. Can you add a trac ticket? also Can you give me &
>> Carlton few days for review? I should be able to do this somewhere in the
>> next week.
>>
>
> I can indeed. I wasn't sure if you wanted to get around to reviewing it or
> not, but take all the time you need to review. I'm sure there's some more
> in there that could be tightened up.
>
> (Forgive me if I seem like I am being pushy - just trying to make sure we
> keep forward progress!)
>
>
>>
>> Are we going to create "Async" DEP?
>>
>>
> We probably should do now there is a more solid plan - the discussion on
> the mailing list from before was only really about this first step, not
> about what it would look like to adopt this more fully. I don't think the
> solid agreement from before means we get to skip writing this up, and from
> here on out it becomes much more of a new feature than merely adding safety
> and a new handler.
>
> Andrew
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAFwN1urbURE-v2wtts49or54OD-ui%3DWEKVaZY%2BFUk9xQbOsu1Q%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAJwKpyR4yME8VyMKrSaFZGkvZdOuh4eQiX6u74Vm-4UFEWs%2Bvw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: A different approach for the auto-reloader

2019-04-30 Thread Carlton Gibson
Hi Ramiro. 

I had a quick look at this — it looks great. (And various folks are having 
fun with Watchman, so if the promise delivers it'll be welcome.) 

Do you want to make an actual PR (perhaps with a ticket) so we can get a 
proper review going? 

Thanks for the input, as ever! 

Kind Regards,

Carlton


On Wednesday, 24 April 2019 06:33:50 UTC+2, Ramiro Morales wrote:
>
> Hi all,
>
> I had a stab at a somewhat simpler development server automatic reloading 
> strategy 
> https://github.com/django/django/compare/master...ramiro:synch-reloader
>
> Intention is to test how an implementation of a design by Gary Bernhardt 
> would look. The best written description I could find is this:
>
> https://github.com/devlocker/tychus/issues/3
>
> Gary also had posted some tweets (this is how I got interested in the 
> topic) which seems to have been deleted since then.
>
> Main idea is: Actual checking of changes on the filesystem for modules 
> under monitoring isn't performed in a loop or by depending on a OS kernel 
> feature but per-HTTP request by a front-end proxy process which is in 
> charge of restarting the 'upstream' web server process (in our case a 
> dumbed-down runserver dev server) only when it detects there have been 
> changes. 
>
> Been meaning to try this for some time. It would have been much harder 
> before Tom Forbes' work on refactoring and cleaning up the reloading code 
> for Django 2.2. IMHO Tom's code is so very well thought that for example I 
> just had to lightly subclass StatReload to implement this totally different 
> strategy.
>
> Current form of the code is a new experimental 'serverrun' (for lack of a 
> better name) added to the Django code base whose command line UI mimics 
> 100% the runserver one. 
>
> It copies code from a few places of our code base: The runserver command, 
> the WSGI app hosting code, etc.
>
> I decided to implement this as a new built-in command for now a) to ease 
> experimentation and b) because it needs some minor changes to the 
> 'runserver' command to handle cosmetic details (logging). If the idea is 
> accepted (read further below for reasons in favor of this) then maybe we 
> can switch runserver to this code. Or if the idea isn't deemed appropate 
> for Django core them I might implement it as an standalone django 
> app/project.
>
> If the idea of a smarter stat()-based FS status monitor like this gets 
> actually tested and validated in the field (i.e. by users with big source 
> code trees) it could allow us to possibly stop needing to depend on all of:
>
> * watchman
> * pyinotify
> * watchdog
> (and removing our support code for them from the Django code base).
>
> Also, this would mean:
>
> * Setup simplification for final users (no third party Python libraries or 
> system daemon to install)
> * Better cross-platform portability for Django (we go back to 
> piggy-backing stat() from the stdlib as our only way yo trigger code 
> reloading).
>
> Additionally, as the reloading is performed fully (by restarting the whole 
> HTTP server) and is triggered from another process (the transparent http 
> proxy one) we can drop some contortions we currently need to make:
>
> - Having to wait for the app registry stabilization
> - Avoiding race conditions with the url resolver
>
> I suspect there could be power efficiency advantages too as:
>
> * The scanning for changes is triggered by HTTP requests which should be 
> less frequent than periodically every N seconds.
> * If the developer modifies more than one file before switching to the 
> browser there is need of only one FS scan to cater for all these changes, 
> which is performed just in time for the first HTTP request so the code 
> executed to render/serve it is 100% accurate in regard to actually 
> reflecting the state of the code on disk.
>
> Similar projects include:
> - serveit: https://github.com/garybernhardt/serveit
> - tychus: https://github.com/devlocker/tychus
> - wsgiwatch: https://github.com/dpk/wsgiwatch
>
> Feedback is welcome!
>
> Regards,
>
> -- 
> Ramiro Morales
> @ramiromorales
>

-- 
You received this message because you are subscribed to the Google 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/edf0baf4-f6d0-468d-86e3-c4f06d5e82d3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Fellow Reports -- April 2019

2019-04-30 Thread Carlton Gibson
Hi all. 


Calendar Week 17 -- ending 28 April.


Triaged:

https://code.djangoproject.com/ticket/30395 -- Document ModelForm 
specifying field class corresponding to model fields with choices. 
(Accepted)
https://code.djangoproject.com/ticket/30392 -- Onboarding new contibutors 
improvements (needsinfo)
https://code.djangoproject.com/ticket/30348 -- Add superuser_required 
decorator. (Accepted)
https://code.djangoproject.com/ticket/21048 -- Error page should not invoke 
callables passed through WSGI META structure (wontfix)



Reviewed:

https://github.com/django/django/pull/11166 -- Fixed #30312 -- Relaxed 
admin check from django.contrib.sessions to SessionMiddleware subclasses.
https://code.djangoproject.com/ticket/30361 -- Watchman timing out when 
loading server
https://github.com/django/django/pull/11276 -- Fixed #30399 -- Changed 
django.utils.html.escape()/urlize() to use html.escape()/unescape().
https://github.com/django/django/pull/11169 -- Fixed #30318 -- Added check 
for when custom error handler cannot be imported.
https://github.com/django/django/pull/11275 -- Fixed #30362 -- Noted 
partial indexes and constraints restrictions with abstract base classes.
https://github.com/django/django/pull/11228 -- Fixed #30366 -- Fixed 
StatReloaderTests with HFS+ filesystems
https://code.djangoproject.com/ticket/30342 -- Remove the 
LANGUAGES_BIDI=LANGUAGES check.
https://github.com/django/django/pull/11203 -- Fixed #27086 - Docd 
multithreading error while testing on MacOS.
https://github.com/django/django/pull/11165 -- Fixed #30310 -- Added 
support for looking up HttpHeaders.headers using underscores.



Authored:

https://github.com/django/django/pull/11283 -- Fixed #30351 -- Adjusted 
proxy model permission data migration to handle pre-existing permissions.




Calendar Week 18 -- ending 05 May.


(I'm off the rest of the week. May update, but likely not.)


Triaged:

https://code.djangoproject.com/ticket/30372 -- Django (moderately) High CPU 
usage at Idle (needsinfo)
https://code.djangoproject.com/ticket/30398 -- Check database 
connections health before its reused (Accepted)
https://code.djangoproject.com/ticket/30375 -- Use NO KEY when 
doing select_for_update for PostgreSQL (Accepted)
https://code.djangoproject.com/ticket/30416 -- Runservers reloading 
mechanism should restore terminal state completely (Accepted)
https://code.djangoproject.com/ticket/30411 -- Improve traceback formatting 
in technical 500 text responses (Accepted)
https://code.djangoproject.com/ticket/30415 -- Refactor runtests.py to 
allow using other test runners. (Accepted)
https://code.djangoproject.com/ticket/30424 -- Queries within 
AppConfig.ready() can cause issues with some Django db commands (Invalid)
https://code.djangoproject.com/ticket/30426 -- Make security headers 
default (Accepted)



Reviewed:

https://code.djangoproject.com/ticket/30419 -- Minor improvements for docs 
related to Meta.indexes


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/af822b18-c077-4b4f-a7b5-bf6cf0136641%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Proposal to format Django using black

2019-04-29 Thread Carlton Gibson
Hi Alex. 

So I use git blame on Django *a lot: *a new ticket comes in, I have no idea 
at all how to triage it so I need to look at the history to make a sensible 
decision. I use git blame to find the commit, to find the original ticket, 
in which there's a discussion, which 爛 explains why things are as they 
are. (Mostly...)

But we're already at the the point where more times than not I need to skip 
multiple commits to get back to the original decision. 

Look at `master` right now. https://github.com/django/django/commits/master
(Screenshot attached) 

The last three commits from this morning are all "tidy-ups" that obscure 
the history. This is typical. Rarely now is there such a old block that 
hasn't been adjusted at all. So it's normal to have to jump commits. 

A big Black commit will add to this. (It's the concern I do have.) But it's 
not a game changer. It's just more of the same. I'm pretty sure it's the 
motivation needed to up my git blame foo to the next level, at which point 
I'll likely save time ironically. 

For this reason, weighed against the benefits, I don't think the git 
history should be a blocker. I hope that makes sense. 

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/01b0bcb5-3540-455e-b06e-d16ad2ec04d8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Deferring "Sign the CLA"

2019-04-27 Thread Carlton Gibson
I had something like DocuSign or similar in mind. (But it’s just a Maybe...
at this point.)

The goal being to smooth away the barriers that stop people contributing
before they’ve even started, IMO replacing “Find a Printer” with “Get set
up with GPG” isn’t a step forwards. 



On Sat, 27 Apr 2019 at 19:30, J. Pic  wrote:

> Maybe accept gpg signatures for the cla document in a repo users make pull
> request too from now on and it's done.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAC6Op18YnQ3Trw7F84Q65HFBrat4aNLL1gpL0MCR5CiN_MStuA%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAJwKpyT6d%2Bs8gCE%3DroYSQ705007pwnMHustLC%2BX1d8gpWAL3EA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Deferring "Sign the CLA"

2019-04-27 Thread Carlton Gibson

> On 27 Apr 2019, at 18:51, Florian Apolloner  wrote:
> 
> I think the question is if we need those at all. This is something the DSF 
> should be able to answer.

Ah, you’ve preempted a later question. 

Right now I just wanted to move it down the page. 

Maybe some online signing service would be good. (?)
(Anyone think they could get us setup quickly?)

I mentioned tying it into the Github workflow a while back, but that’s probably 
overkill.
(We don’t have so many signings that an online service we link to wouldn’t be 
enough, is the thought.)

I’ve asked Frank (DSF president) if the board can discuss whether we still need 
the CLA. 

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/F70B1E18-7FF7-4985-9906-46D5A4677C11%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


Deferring "Sign the CLA"

2019-04-27 Thread Carlton Gibson
Hi all. 

The CLA makes two appearances in the docs: 

* New contributors: First Steps 

* Twice in Submitting Patches 


This has come up before but, we don't actually check or insist that people 
sign the CLA. It's a nice to have, and we don't we don't want to get rid of 
it (last time at least) but that's all. 

I'd like to do two things: 

1. Move the CLA reference in First Steps to it's own section further down 
the page, saying something like... "once you get to making a larger 
contribution...". 
2. Review the wording on Submitting Patches page similarly. 

*Why?* Again, just to smooth the on-ramp. Step 1 of First Steps shouldn't 
be "Find a printer". 
(That's obviously too quick. I can spell it out more fully if the point 
isn't clear )

Any great objection? 
Thanks.
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/83c903fe-55d1-4d0b-aa56-f2a8b4d1da1c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Fellow Reports -- April 2019

2019-04-24 Thread Carlton Gibson
Hi all. 


Calendar Week 14 -- ending 07 April.

Released Django 2.2.


Triaged:

https://code.djangoproject.com/ticket/30323 -- Django 2.2 autoreloader is 
failing intermittently (not using watchman) (Accepted)
https://code.djangoproject.com/ticket/30335 -- TypeError: unhashable type: 
list when paginating queryset with KeyTransform annotation 
(Accepted)
https://code.djangoproject.com/ticket/30334 -- extra option for 
InlineModelAdmin instances should be 0 if user is lacking 
add permission (Accepted)
https://code.djangoproject.com/ticket/30320 -- using deserialization 
object.save() is inconsistent (Invalid)
https://code.djangoproject.com/ticket/30318 -- Add new system check message 
when path.to.view is cannot be imported (Accepted)
https://code.djangoproject.com/ticket/30310 -- New HTTPRequest.headers not 
usable in templates because of hyphens (Accepted)
https://code.djangoproject.com/ticket/30317 -- model_to_dict() makes 
separate db calls for each missing field (wontfix)
https://code.djangoproject.com/ticket/30314 -- Enable SESSION_COOKIE_SECURE 
by Default (wontfix)
https://code.djangoproject.com/ticket/30316 -- Link to default logging 
dictConfig in documentation (Accepted)
https://code.djangoproject.com/ticket/30252 -- ImageFields to_python() 
stores reference to closed Image object (Accepted)
https://code.djangoproject.com/ticket/30313 -- SQLite min version in Django 
2.2 breaks Centos 7 compatability (wontfix)
https://code.djangoproject.com/ticket/30311 -- Cant replace global 
admin actions with specialized ones per-admin (invalid)
https://code.djangoproject.com/ticket/30308 -- Clarify in documentation 
that runserver is overridden for django.contrib.staticfiles (wontfix)
https://code.djangoproject.com/ticket/30303 -- Error handler page 
generating unicode decode error. (needsinfo)



Reviewed:

https://code.djangoproject.com/ticket/30324 -- UnicodeDecodeError when 
loading debug templates.
https://github.com/django/django/pull/11165 -- Added __getitem__() to 
HttpHeaders.headers
https://github.com/django/django/pull/11155 -- Fixed #30304 -- Added 
support for HttpOnly, SameSite, and Secure flags on language cookies.
https://github.com/django/django/pull/11166 -- Fixed #30312 -- Relaxed 
admin checks for sessions app







Calendar Week 15 -- ending 14 April.


Was at DjangoCon Europe and sprints. 

* Talk: 
https://2019.djangocon.eu/talks/feeding-the-pony-contributing-back-to-django-how-t/

The sprints were good. I spent a lot time helping people get started, find 
an
issue etc. 

The big take-home for me was the need for some kind of "Intro to
sprints" workshop to help here and provide a better group experience and 
some
mentoring. (I was doing that but one-on-one isn't ideal.)



Triaged:

https://code.djangoproject.com/ticket/27910 -- Allow using an Enum class in 
model Field choices (Accepted)
https://code.djangoproject.com/ticket/30363 -- utils.numberformat.format 
renders small decimals in exponential notation. (Accepted)
https://code.djangoproject.com/ticket/30338 -- sitemap.xml template should 
not use localization (Invalid)



Reviewed:

https://code.djangoproject.com/ticket/30318 -- Add new system check message 
when custom error handler path.to.view cannot be imported







Calendar Week 16 -- ending 21 April.

I was on holiday. 

Processed the GSoC applications. Applied for "Season of Docs".


Triaged:

https://code.djangoproject.com/ticket/30333 -- __hash__ is not inherited 
from model.Model if __eq__ is defined (Duplicate of 30254)


Authored:

https://github.com/django/django/pull/11184 -- Refs #30254 -- Added tests 
verifying model class __hash__() inheritance.



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/296e710f-826e-4a8b-8deb-8eb70ae58202%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Proposal to format Django using black

2019-04-24 Thread Carlton Gibson
On Wednesday, 24 April 2019 08:58:57 UTC+2, Josh Smeaton wrote:
>
> lots of bikeshedding
>

Yeah.  

But we've already got a style guide, so **IF** we can get a YAPF config to 
work to that then hopefully the arguments against using a formatter here 
would be moot. (Note that **IF** — I only said I'd have a play.) 

Equally, **IF** it's true that the Python community is standardising around 
black then, we should join in. But I get the impression that's not a done 
deal yet. 

I'm not fussed on the code style. The brain/eye adapts. As I said before, I 
would like us to have an auto formatter of some kind. 

-- 
You received this message because you are subscribed to the Google 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/1f79a79f-3aee-4bc2-90f8-55274e56c0d5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: UnicodeDecodeError: 'cp949' codec can't decode byte 0xe2 in position 9735: illegal multibyte sequence

2019-04-24 Thread Carlton Gibson


On Wednesday, 24 April 2019 02:19:32 UTC+2, Hyogeun Kim wrote:
>
>
> PS: I tested on my Mac and I got this error message "UnicodeDecodeError: 
> 'ascii' codec can't decode byte 0xe2 in position 9735: illegal multibyte 
> sequence" and It works as well with version 1.11 and 2.1 on Mac
>

Yes. OK. It will depend on your system locale. There was an implicit 
assumption of something using UTF-8. Either way resolved in 2.2.1. 

Please open a new ticket if something else comes up. 

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/18392f8a-4a3a-4dd1-a24d-adece942ff22%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Proposal to format Django using black

2019-04-24 Thread Carlton Gibson
Thanks for the YAPF suggestion (and sample config!) I'll have a go with 
this this week. 
(If we can get auto-formatting, just on diffs(?), that matches the existing 
style...)

On Monday, 22 April 2019 20:10:41 UTC+2, thinkwel...@gmail.com wrote:
>
> I wonder if there's a middle ground between minimizing code churn and 
> having a standardized formatter. Our team recently switched to yapf after 
> carefully configuring a .style.yapf file that's included in the root 
> directory of every new repo. Once that config file is done, the workflow 
> for yapf vs an unconfigurable formatter is identical.
>
>
> I experimented a bit with the following .style.yapf settings on the django 
> codebase and think the output is as good as black's without some of the 
> arbitrariness of string quotes:
>
> [style]
> based_on_style = pep8
> column_limit=100
> i18n_function_call=['_']
> blank_line_before_nested_class_or_def=True
> join_multiple_lines=False
> indent_dictionary_value=False
>
> coalesce_brackets=True
> dedent_closing_brackets=True
> align_closing_bracket_with_visual_indent=False
> space_between_ending_comma_and_closing_bracket=False
>
> split_complex_comprehension=True
> split_before_first_argument=True
> split_before_logical_operator=False
> split_before_bitwise_operator=False
> split_arguments_when_comma_terminated=True
> split_before_expression_after_opening_paren=True
> split_before_named_assigns=True
>
>
> Yapf currently has more stars than black, but whether black has more 
> momentum or not, who can say.
>
>
> On Monday, April 22, 2019 at 10:14:44 AM UTC-4, Nick Sarbicki wrote:
>>
>>
>>> I'm just saying that if "As contributor, I can haz automatic code 
>>> formatter to lower the barrier" is precisely the story you want to solve, 
>>> then black may not be the only solution you want to consider deeply ;)
>>>
>>>
>> Jamie, sure, I wasn't responding directly to you about this, more to the 
>> general people arguing against blacks style choices. I would happily 
>> consider alternatives to black - although (without any formal research to 
>> back this claim) it does feel like black has the most community support.
>>
>> My point is mostly that if there is a growing community consistency 
>> through black then I'd be hesitant to choose another tool that goes against 
>> this.
>>
>>  
>>
>>> > Consistency in the end is the most important thing (even PEP8 agrees 
>>> > there). 
>>>
>>> Not sure where you got that impression: 
>>> https://pep8.org/#a-foolish-consistency-is-the-hobgoblin-of-little-minds 
>>> 
>>>  
>>>
>>> Pep8 clearly states consistency is less important then readability (it's 
>>> the 
>>> first thing mentioned and mentioned repeatedly that you can use as an 
>>> argument 
>>> to break consistency). And this is the primary advantage of black, since 
>>> readability is hard to quantify (and therefore lint or format) and I 
>>> think 
>>> this is where black has succeeded (by breaking consistency where it is 
>>> needed). 
>>> I mostly follow the discussion with interest from the sidelines, but 
>>> just 
>>> wanted to correct this consistency argument: if you want consistent 
>>> code, go 
>>> with autopep8, it'll keep your lines consistent below 79 characters and 
>>> quite 
>>> an unreadable mess. 
>>> -- 
>>>
>>
>> Thanks for the correction Melvyn, you're right - aside from readability 
>> and backwards compatibility consistency is important.
>>
>> I'd also note the irony of using PEP8 to argue for consistency with a 
>> tool that is (at least on line length) inconsistent with PEP8. Although I 
>> really don't want to start a debate on line length.
>>
>

-- 
You received this message because you are subscribed to the Google 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/1d5de155-f957-4132-84f7-a19c69fb2cc0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: UnicodeDecodeError: 'cp949' codec can't decode byte 0xe2 in position 9735: illegal multibyte sequence

2019-04-23 Thread Carlton Gibson


On Tuesday, 23 April 2019 14:30:48 UTC+2, Carlton Gibson wrote:
>
>
> What IS the right way of setting the locale on Windows...? 
>

Not sure if it's the only way but, on Windows 10 you can tick a "Use 
Unicode UTF-8 for worldwide language support", box in "Region & Language" - 
"Administrative" - "Change system locale" - "Region Settings".

This has a "beta" label next to it... 

After a reboot it adjusts `local.getpreferredencoding(False)` to `cp65001`, 
which the internets tell me is UTF8, which is what you want I think. 

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/60421d6e-793a-49c1-b972-cb955382fd33%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: UnicodeDecodeError: 'cp949' codec can't decode byte 0xe2 in position 9735: illegal multibyte sequence

2019-04-23 Thread Carlton Gibson


On Tuesday, 23 April 2019 14:27:24 UTC+2, Carlton Gibson wrote:
>
> If you set the `PYTHONIOENCODING` to utf8 before launching...
>

Not actually sure this is sufficient. What IS the right way of setting the 
locale on Windows...? 

-- 
You received this message because you are subscribed to the Google 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/634f2e7f-9e07-4630-89db-0c61cf82373a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: UnicodeDecodeError: 'cp949' codec can't decode byte 0xe2 in position 9735: illegal multibyte sequence

2019-04-23 Thread Carlton Gibson
This looks to be https://code.djangoproject.com/ticket/30324, which will be 
fixed by 2.2.1 next week. 
(Please open a new ticket with full details if it is distinct.) 

If you set the `PYTHONIOENCODING` to utf8 before launching Python you 
shouldn't this. (Or related unicode errors)

https://docs.python.org/3.7/using/cmdline.html#envvar-PYTHONIOENCODING

HTH
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/fb967656-c067-4c03-ac42-90e040507c15%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Google "Season of Docs"

2019-04-22 Thread Carlton Gibson
Quick update: 

I've applied Django for Season of Docs. Don't know if we're accepted yet 
but 爛

As per the timeline Technical Writer applications open May 29th.

https://developers.google.com/season-of-docs/docs/timeline

I put a wiki page here:

https://code.djangoproject.com/wiki/2019SeasonOfDocs

If you have specific project ideas please add them. 
(TBH: "Take on the tickets" is what I'd really like ) 

If you'd like to mentor, assuming we get accepted etc, please let 
me/Mariusz know.

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/c4432dad-2054-45d9-94e3-d917b0801e32%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Proposal to format Django using black

2019-04-20 Thread Carlton Gibson


On Friday, 19 April 2019 20:33:13 UTC+2, Mariusz Felisiak wrote:
>
>
> I don't think that our code style is any barrier for newcomers. ...we've 
> never blocked any patch due to stylistic nitpicks. I also don't believe 
> that it will increase the number of contributors, if I would like to 
> contribute to any package it wouldn't matter to me.
>

So, I've been out banging the drum for new contributors for a year or so 
now. I've had a number of personal reports that this just isn't true. 

Members of our community who want to contribute to Django are finding the 
review process off-putting. (They've used stronger language than that.) We 
have a host of people that have made a single contribution and never come 
back. 

"Wrap to 79 chars", or whatever, would be better gone. I'm not sure I like 
Black per se, but using an auto-formatter would enable review comments to 
focus on substantive points. ("Can we rephrase this slightly to more 
like")  (From experience in Go and Elm lands, the community using a 
single formatter has great benefits. After a couple of week your brain gets 
used to the different style.) 

It's not a panacea. But we have a massive barrier to entry. We need to 
address that. Using an auto-formatter would be one step. 

-- 
You received this message because you are subscribed to the Google 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/f198ce19-eb91-4bdc-a4bf-323daca60134%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: GSOC Proposal : CrossDB JSON Field

2019-04-17 Thread Carlton Gibson
Deadline for submissions has passed. I’m reviewing this week.

On Wed, 17 Apr 2019 at 08:52, Adam Johnson  wrote:

> Hi Rohit!
>
> It seems your email thread has been missed by the list, I don't know why,
> perhaps it hit some spam filters. There's also another thread from a
> student proposing the same projectt:
>
>
> https://groups.google.com/d/msgid/django-developers/415dbb68-d1a8-4642-8908-e6414dde1ad0%40googlegroups.com
>
> I think the last message on that thread is a big development with regards
> to this project, since Raphael has written a third-party implementation
> that has most of the features:
> https://github.com/raphaelm/django-jsonfallback
>
> I'm not sure what we do with regards to two GSOC proposals for the same
> task, maybe Carlton or others would like to weigh in?
>
> Thanks,
>
> Adam
>
> On Fri, 5 Apr 2019 at 03:02, Rohit Jha  wrote:
>
>> Hi
>>
>> I am Rohit Jha, I am a sophomore at IIT Roorkee. I am planning to
>> participate in GSOC. My draft Proposal can be found here :
>>
>>
>> https://docs.google.com/document/d/1jSEir_wuYlBqvQTmWJUF3mpquuIH4ElZG1hFBeMl1HI/edit?usp=sharing
>>
>> Feedback is much appreciated
>>
>> 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/fcaed3da-3b9f-44a0-85a5-7d5007775360%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
> Adam
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAMyDDM10QJiERJ_hPW9cGP5ZZmYhzNcG6Ufny57a9MuL1uNLiA%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAJwKpyTg-x8QCVCTn4ziZ2kGbjzZx%2BRjDhe3P9Lthn_xzfxeGA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Proposal to format Django using black

2019-04-13 Thread Carlton Gibson
We spend a lot of time spotting small formatting errors and then asking for
those to be fixed and then waiting for an update. This wastes reviewer time
and slows down the feedback cycle. Many pull requests drag out because of
it.

For this reason I would be 100% behind adopting black, and applying that in
a single commit.

My only reservation is about the history. I don’t know the tools Florian
mentioned but I wonder if there is a clever git blame usage that would
allow bringing over a single commit change of this sort?

Even if we can’t solve that I’d still be +1 for the added ease to
contributors and the speed benefits to review efforts.

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


Re: Google "Season of Docs"

2019-04-11 Thread Carlton Gibson
Hi William.

A few people have shown interest so I will apply as an org for us. Then
candidates can apply. (I’m hopeful we could get multiple slots but it’s a
new programme so I don’t really know.)

C.

On Wed, 10 Apr 2019 at 21:03, William Hakizimana 
wrote:

> Just out of curiosity, I was wondering if we got any traction on this.
>
> On Monday, March 18, 2019 at 5:27:47 AM UTC-5, Carlton Gibson wrote:
>>
>> Hi all,
>>
>> Parallel to GSoC, Google now have this "Season of Docs" programme:
>>
>> https://developers.google.com/season-of-docs/
>>
>> The idea is experienced technical writers can get funding to work with
>> open source projects on their docs.
>>
>> There are a lot of open Documentation issues
>> <https://code.djangoproject.com/query?status=assigned=new=Documentation=Accepted=id=summary=status=component=owner=type=version=1=id>
>> .
>>
>> As such if you have, or if you know someone with, strong writing skills
>> and you
>> (they) might be interested here let me know and we can look into this.
>>
>> I can't quite work out whether if we just apply we might attract a
>> writer, but it would be
>> awesome if already someone in the community was keen for this.
>>
>> 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/4fc398b3-151f-49fc-8279-9b2f300aa348%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/4fc398b3-151f-49fc-8279-9b2f300aa348%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/CAJwKpySz6iPOnpJFYdyrOMYaT76Zpd1-VXBY98xkjG2s9w90eQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Help for GSoC proposal (Formset improvements)

2019-04-08 Thread Carlton Gibson
Hi Parth. 

Well, the wizard () got moved out to it's own 
app https://django-formtools.readthedocs.io/en/latest/
But yes, there's no reason why this sort of thing wouldn't potentially in 
scope. 

Kind Regards,

Carlton


On Sunday, 7 April 2019 23:47:23 UTC+2, PARTH PATIL wrote:
>
> (Sorry I typed the incomplete message in the last post)
>
> I came across this ticket while going over the feature list of Forms and 
> Formsets (# 18830 )
>
> Feature requested in this thicket is something like
>
> *FormWizard:*
> * It will be like a container which can have forms, formsets, and 
> formwizards itself.*
>  
>
>1. Is this kind of feature still required?
>2. Will this be a good addition to the Form?
>3. Should I mention this in my proposal, as there is few time left for 
>the final submission I may not be able to draft it properly?
>
> The possible use of this will be to attach different forms in an HTML and 
> this form wizard will handle saving, etc of the forms. I was thinking of 
> keeping something like a management form similar to formset which will 
> handle the individual object and ensure which fields correspond to which 
> form/formset element within the wizard.
>
>
>
> On Tuesday, March 26, 2019 at 11:26:56 PM UTC+5:30, PARTH PATIL wrote:
>>
>> I was planning  to do the "Formset Improvements 
>> " 
>> project in GSoC. I would need some more explanation on what is expected as 
>> nothing was clearly mentioned there.
>> You can link the related tickets or elaborate on what is needed that 
>> would be helpful.
>>
>> I dug a little bit deeper into this. and found some related issues 1 
>> 
>>  
>> | 2. 
>> 
>>
>> I'm planning to add a request variable in the BaseFormSet Class 
>> 
>>  
>> and then handle it such that it will be available within every form (not 
>> completely polished till now).
>>
>>1. Is this a good approach?
>>2. Will this solve the problem? (If not please mention the problems 
>>which will not be solved
>>
>> I am also looking for some additional features that maybe added to 
>> formset so am open for suggestions.
>> I'm currently in middle of making the abstract so before moving forward i 
>> would like to get some confirmation that this is correct approach. Thank you
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/519108f2-4030-49d3-8ce8-137f32a48743%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Should we backport adding support for psycopg2 2.8 to the 1.11.x and 2.1.x?

2019-04-05 Thread Carlton Gibson
OK, so for me, this should go into v2.2, but not v2.1 or v1.11. (I see you 
already backported to 2.2 so... )

My general take here is that we could be half-a-notch more generous 
backporting to the current version (e.g. 2.2 now) but should be just as 
strict as we are once a version is out of mainstream support. (Loosely: 
Given how easy the update process is these days, I don't think we do anyone 
any favours keep older versions on life-support...) 

C.

On Thursday, 4 April 2019 14:52:23 UTC+2, Mariusz Felisiak wrote:
>
> Patch for adding support for psycopg2 *2.8* is ready (see ticket #30331 
> 
>  
> and PR11171 ). Fix is quite 
> straightforward and works with all supported version of psycopg2, i.e. 
> *2.5.4+*. The question is, should we backport this fix to the *1.11.x* 
> and *2.1.x*? Theoretically it doesn't qualify due to our backport policy, 
> because both are in the "extended support" time.
>

-- 
You received this message because you are subscribed to the Google 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/c7a802c5-c19a-41de-8283-abd742144541%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: GSoC Proposal (FormSet Improvement)

2019-04-03 Thread Carlton Gibson
Yes, just pseudo code — so when reviewing your proposal next week it's easy 
to see that it'll be the right approach. 

On Wednesday, 3 April 2019 17:51:18 UTC+2, PARTH PATIL wrote:
>
>
>
> On Wednesday, April 3, 2019 at 8:58:26 PM UTC+5:30, Carlton Gibson wrote:
>>
>> Hey Parth. 
>>
>> Right. So, thanks for making the effort so far. Good. 
>>
>> Can you add more detail about yourself. You've not contributed to Django 
>> right? So the concern at this point would be whether you're able to fulfil 
>> the project. 
>>
>
> I have contributed to Django (see #30189 
> <https://code.djangoproject.com/ticket/30189>), I have mentioned it at 
> the end of my proposal, I would try to highlight that. 
>
>  
>
>> What's your experience with Django? (and if you want to implement a 
>> declarative formset syntax, Python more generally?)
>> (Perhaps you said this, but it needs to be in the proposal.) 
>>
>
> Sure I will add some of my projects in the proposal. 
>
>>
>> You don't necessarily need to have ideas for the final code, but what 
>> does e.g. the usage look like with your idea (i.e. adding the request 
>> parameter)? 
>> (So the formset gets the request and this is available where...? and so 
>> on: can you SHOW in your proposal that this WILL address the issues?)
>>
>
> I'm a little bit confused here, What you mean by "SHOW that this works"? 
>
>- Do you just write some pseudo code, and say this will work?
>- Or I have to prove in some way that this will work??
>
>
>> HTH.
>>
>> Kind Regards,
>>
>> Carlton
>>
>>
>> On Monday, 1 April 2019 21:29:33 UTC+2, PARTH PATIL wrote:
>>>
>>> Here is a link to my GSoC proposal
>>> Its a first draft so you are open to comment and suggest changes
>>>
>>>
>>> https://docs.google.com/document/d/1JuoVOU5xMwXY7JrHJshezIyuIpFfoEM49rO3e0rfNhE/edit?usp=sharing
>>>
>>>
>>> Best Regards,
>>>
>>> PARTH PATIL
>>>
>>> SOFTWARE DEVELOPER, AUV-IITB
>>>
>>> CONVENOR, ELECTRONICS & ROBOTICS CLUB IIT BOMBAY.
>>>
>>> [image: Image result for FACEBOOK ROUND ICON] 
>>> <https://www.facebook.com/parth.patil.77> [image: Image result for 
>>> instagram ROUND ICON] <https://www.instagram.com/code_blooded18/> [image: 
>>> Image result for linkedin ROUND ICON] 
>>> <https://www.linkedin.com/in/parth-patil-256291117/>
>>>
>>>

-- 
You received this message because you are subscribed to the Google 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/deae8484-5a5c-4158-b5ef-f262f30eb6eb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: GSoC Proposal (FormSet Improvement)

2019-04-03 Thread Carlton Gibson
Hey Parth. 

Right. So, thanks for making the effort so far. Good. 

Can you add more detail about yourself. You've not contributed to Django 
right? So the concern at this point would be whether you're able to fulfil 
the project. 
What's your experience with Django? (and if you want to implement a 
declarative formset syntax, Python more generally?)
(Perhaps you said this, but it needs to be in the proposal.) 

You don't necessarily need to have ideas for the final code, but what does 
e.g. the usage look like with your idea (i.e. adding the request 
parameter)? 
(So the formset gets the request and this is available where...? and so on: 
can you SHOW in your proposal that this WILL address the issues?)

HTH.

Kind Regards,

Carlton


On Monday, 1 April 2019 21:29:33 UTC+2, PARTH PATIL wrote:
>
> Here is a link to my GSoC proposal
> Its a first draft so you are open to comment and suggest changes
>
>
> https://docs.google.com/document/d/1JuoVOU5xMwXY7JrHJshezIyuIpFfoEM49rO3e0rfNhE/edit?usp=sharing
>
>
> Best Regards,
>
> PARTH PATIL
>
> SOFTWARE DEVELOPER, AUV-IITB
>
> CONVENOR, ELECTRONICS & ROBOTICS CLUB IIT BOMBAY.
>
> [image: Image result for FACEBOOK ROUND ICON] 
>  [image: Image result for 
> instagram ROUND ICON]  [image: 
> Image result for linkedin ROUND ICON] 
> 
>
>

-- 
You received this message because you are subscribed to the Google 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/d0a1ca3a-9e5a-4027-ac3e-75c8adc4d968%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: GSoC Proposal: Add Cross-DB JSONField, ArrayField, and HStoreField

2019-04-03 Thread Carlton Gibson
Hi Sage. 

Thanks for the proposal. It's looking OK. Couple of points: 


   - There IS an Oracle implementation. See the ticket here: 
   https://code.djangoproject.com/ticket/29821
   - Something that looks like an ArrayField, yes. HStore... not so sure 
   it's worth mimicking. 
   - On the timeline: I think you've spread the coding bit too thin and not 
   allocated enough for Documenting.
  - I think you if you want full-guns at the SQLite PoC in week 1 and 2 
  you'd have something in place quite quickly. 
 - The base field should be simple enough™
 - The SQLite only lookups shouldn't be too complicated. 
  - As I commented on the other thread on this topic, we'll need to 
  advise on getting people set up with SQLite with the JSON extension. 
  - There's more in this that you think I'd guess. No harm in putting 
 time in the schedule for it. 
  - Allow for the possibility you complete early and have time to work 
  on other things...
  - This stuff is difficult to get right. It's more balance that exact 
  times: 
 - The actual timeline won't match the plan ever. 
 - you don't need to worry about two days off for holiday 
  
Your contributions so far have been super. Thank you. 

Kind Regards,

Carlton


On Tuesday, 2 April 2019 13:41:37 UTC+2, Sage M.A. wrote:
>
> Hello, everyone! My name is Sage. I'm a 19-year-old computer science 
> student from Indonesia. I'm planning to join the Google Summer of Code 
> (GSoC) this year, and I want to contribute to Django. I have written a 
> draft for my proposal in this gist 
> . I 
> have submitted two small patches for Django, and I hope to contribute more 
> in the future. Feedbacks are much appreciated, 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/622f8f17-3d52-4ca8-864a-baaa064d1485%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Enable SESSION_COOKIE_SECURE by Default

2019-04-03 Thread Carlton Gibson
Hi Matthias, 

Yes, super thanks. Breaking login in development would qualify as a good 
*Why* yes. 

I'll assume we're NOT going to do this, but anyone with input, please do 
comment. 

> (The same reasoning should probably be applied to CSRF_COOKIE_SECURE.

Absolutely. And, soon, `LANGUAGE_` 
too. https://github.com/django/django/pull/11155


Thanks. C. 




On Wednesday, 3 April 2019 10:19:15 UTC+2, Matthias Kestenholz wrote:
>
> On Wed, Apr 3, 2019 at 10:02 AM Carlton Gibson  > wrote:
>
>> Hi all. 
>>
>> https://code.djangoproject.com/ticket/30314
>>
>> >  Per the documentation, "Leaving this setting off isn’t a good idea 
>> because an attacker could capture an unencrypted session cookie with a 
>> packet sniffer and use the cookie to hijack the user’s session."
>> >
>> > If it's not a good idea for this setting to be off, why is it off by 
>> default? Seems backwards to me.
>>
>> This looks right to me. A small breaking change for 3.0 would seem 
>> reasonable. So I'm going to Accept this. 
>>
>> BUT this has been this way forever 
>> <https://github.com/django/django/commit/45be33a6327bccae60319982254ee62f65bea11e>
>>  so 
>> I just wanted to check if there were any overriding *Whys*?
>>
>
> (The same reasoning should probably be applied to CSRF_COOKIE_SECURE.)
>
> My opinion is that this isn't a good idea. Right now it's possible to 
> always have the SecurityMiddleware in MIDDLEWARE without adding any 
> security-specific settings to the default setup. You get the following 
> benefits:
>
> - Authenticating when developing locally works (as I understand it it does 
> not with *_COOKIE_SECURE set to True because you can't authenticate anymore 
> on the http: development server)
> - You get the SecurityMiddleware's warnings if you do not enable those 
> settings when DEBUG=False
>
> I fear that more people will remove the SecurityMiddleware (which is in 
> the default setup) instead of deactivating secure cookies for local 
> development which means a net negative for security.
>
> Thanks,
> Matthias
>
>  
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/46eb57dc-6b63-4a03-8937-6c6ad731344f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Enable SESSION_COOKIE_SECURE by Default

2019-04-03 Thread Carlton Gibson
Hi all. 

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

>  Per the documentation, "Leaving this setting off isn’t a good idea 
because an attacker could capture an unencrypted session cookie with a 
packet sniffer and use the cookie to hijack the user’s session."
>
> If it's not a good idea for this setting to be off, why is it off by 
default? Seems backwards to me.

This looks right to me. A small breaking change for 3.0 would seem 
reasonable. So I'm going to Accept this. 

BUT this has been this way forever 

 so 
I just wanted to check if there were any overriding *Whys*?

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/e67ee6a2-751e-4b24-9d72-6c746a8c0178%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Django 2.2 released.

2019-04-01 Thread Carlton Gibson
Sigh... 2.1... (Sorry.)

On Monday, 1 April 2019 15:23:11 UTC+2, Carlton Gibson wrote:
>
> Oops, typo there: 
>
> > ...Django 2.0... 
>
> That should say "Django 2.0 will receive security and data loss fixes 
> until December 2019". 
> C.
>
> On Monday, 1 April 2019 15:19:20 UTC+2, Carlton Gibson wrote:
>>
>> Django 2.2, the next long-term support release, is now available:
>>
>> *https://www.djangoproject.com/weblog/2019/apr/01/django-22-released/ 
>> <https://www.djangoproject.com/weblog/2019/apr/01/django-22-released/>*
>>
>> With the release of Django 2.2, Django 2.1 has reached the end of
>> mainstream support. The final minor bug fix release, 2.1.8, was issued 
>> today. 
>> Django 2.0 will receive security and data loss fixes until December 2019. 
>> All users are
>> encouraged to upgrade before then to continue receiving fixes for
>> security issues.
>>
>> See the downloads page [1] for a table of supported versions and the
>> future release schedule.
>>
>> [1] https://www.djangoproject.com/download/#supported-versions
>>
>

-- 
You received this message because you are subscribed to the Google 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/0dbda01f-ade2-4f0f-a760-65475279f377%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Django 2.2 released.

2019-04-01 Thread Carlton Gibson
Oops, typo there: 

> ...Django 2.0... 

That should say "Django 2.0 will receive security and data loss fixes until 
December 2019". 
C.

On Monday, 1 April 2019 15:19:20 UTC+2, Carlton Gibson wrote:
>
> Django 2.2, the next long-term support release, is now available:
>
> *https://www.djangoproject.com/weblog/2019/apr/01/django-22-released/ 
> <https://www.djangoproject.com/weblog/2019/apr/01/django-22-released/>*
>
> With the release of Django 2.2, Django 2.1 has reached the end of
> mainstream support. The final minor bug fix release, 2.1.8, was issued 
> today. 
> Django 2.0 will receive security and data loss fixes until December 2019. 
> All users are
> encouraged to upgrade before then to continue receiving fixes for
> security issues.
>
> See the downloads page [1] for a table of supported versions and the
> future release schedule.
>
> [1] https://www.djangoproject.com/download/#supported-versions
>

-- 
You received this message because you are subscribed to the Google 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/a053e34d-1bdb-4819-b75b-52e15586128f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Django 2.2 released.

2019-04-01 Thread Carlton Gibson
Django 2.2, the next long-term support release, is now available:

https://www.djangoproject.com/weblog/2019/apr/01/django-22-released/ 


With the release of Django 2.2, Django 2.1 has reached the end of
mainstream support. The final minor bug fix release, 2.1.8, was issued today. 
Django 2.0 will receive security and data loss fixes until December 2019. All 
users are
encouraged to upgrade before then to continue receiving fixes for
security issues.

See the downloads page [1] for a table of supported versions and the
future release schedule.

[1] https://www.djangoproject.com/download/#supported-versions 


-- 
You received this message because you are subscribed to the Google 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/17CE6041-43DB-4D4D-B05D-0680A94AF8A1%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


Django bugfix release 2.1.8

2019-04-01 Thread Carlton Gibson
Details are available on the Django project weblog: 

https://www.djangoproject.com/weblog/2019/apr/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/7B4EF610-4CC1-4231-96AB-7CE2BFDEC0E6%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Fellow Reports -- March 2019

2019-03-31 Thread Carlton Gibson
Hi all. 



Calendar Week 12 -- ending 24 March.


Released Django v2.2rc1


Triaged:

https://code.djangoproject.com/ticket/30267 -- get_language_from_path not 
respecting i18n_patterns prefix_default_language=False (wontfix)
https://code.djangoproject.com/ticket/30275 -- Autofocus the first field in 
contrib.admin add form (worksforme)
https://code.djangoproject.com/ticket/30268 -- Django admin list_editable 
overrides changes done elsewhere (invalid)
https://code.djangoproject.com/ticket/30256 -- ManyToManyField with a 
non-list default value has different behavior in an inlined Admin vs a 
standalone Admin (invalid)
https://code.djangoproject.com/ticket/30256 -- autocomplete_fields cause 
one or two extra queries for each field wth foreign key or many to many 
relation (Accepted)
https://code.djangoproject.com/ticket/30263 -- Mention the Media.merge 
change in the release notes (Accepted)



Reviewed:

https://code.djangoproject.com/ticket/30196 -- Make FileResponse always set 
Content-Disposition header.
https://code.djangoproject.com/ticket/29956 -- Allowed overriding an order 
field widget in formsets.
https://code.djangoproject.com/ticket/30258 -- Failed to add 
CheckConstraint on IntegerRangeField



Authored:

https://github.com/django/django/pull/11093 -- Fixed #30263 -- Doc'd 
changes to form Media sorting (refs #30179).





Calendar Week 13 -- ending 31 March.


Triaged:

https://code.djangoproject.com/ticket/30289 -- ManyToManyField Admin 
Inlines do not respect user permissions (Accepted
)
https://code.djangoproject.com/ticket/30300 -- Allow migrations directories 
without __init__.py files. (Accepted)
https://code.djangoproject.com/ticket/30298 -- Search results in Google for 
Django documentation mixes up languages (Invalid)
https://code.djangoproject.com/ticket/30272 -- 
get_language_from_request(..., check_path=True) not respecting 
i18n_patterns prefix_default_language=False (Accepted)
https://code.djangoproject.com/ticket/30285 -- The domain in broken link 
emails can be spoofed (wontfix)
https://code.djangoproject.com/ticket/30296 -- Add how-to guide for 
JavaScript frameworks integration (Accepted)



Reviewed:

https://github.com/django/django/pull/11149 -- Fixed #30289 -- Prevented 
admin inlines for auto-created ManyToManyFields from being editable if the 
user only has the view permission.
https://github.com/django/django/pull/11060 -- Fixed #30241 -- Added system 
checks for translation settings.
https://code.djangoproject.com/ticket/30064 -- Admin search with a null 
character crashes with A string literal cannot contain NUL (0x00) 
characters. on PostgreSQL
https://github.com/django/django/pull/11134 -- Docd that HttpResponse 
accepts bytestrings.
https://code.djangoproject.com/ticket/29692 -- ncorrect removal of order_by 
clause created as multiline RawSQL
https://code.djangoproject.com/ticket/30294 -- HttpResponse doesnt 
handle memoryview objects
https://code.djangoproject.com/ticket/30196 -- Make FileResponse always set 
Content-Disposition header.



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/9c7d03bd-dd68-46ec-b027-773f80e4c39b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: gsoc proposal

2019-03-31 Thread Carlton Gibson
Hi Kartik. 

GSoC, for us at least, isn't for beginners. In the past students have 
already been contributors.
Maybe that's not 100% necessary but a good amount of experience with Django 
at the very least would be. 
If you get into Django maybe it's something you could consider for the 
future. 

I wish you all the best, 

Kind Regards,

Carlton

On Friday, 29 March 2019 12:38:24 UTC+1, kartik garg wrote:
>
> I am a beginner in django and wanted to apply for GSOC but I don't know 
> how to apply for that. can anybody please help me. I haven't applied for 
> gsoc before. 
>

-- 
You received this message because you are subscribed to the Google 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/214acf68-b28d-4dab-b1eb-36af55535e00%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: GSoC Proposal

2019-03-28 Thread Carlton Gibson
Hi Sage. 

Yes. It never hurts to apply. If we get two good proposals for the same 
project, we can find a way to share or another project. 
We can cross that bridge as and when we come to it. 
("Scale later" )

Kind Regards,

Carlton


On Thursday, 28 March 2019 14:58:15 UTC+1, Sage M.A. wrote:
>
> Hi everyone,
> Sorry to ask this, but can I also take a shot in this one? I've been 
> interested in this issue since early February.
>
> On Thursday, 21 March 2019 22:28:41 UTC+7, Carlton Gibson wrote:
>>
>> Also, sorry, this was the key thread here, plus links therein 
>> https://groups.google.com/d/topic/django-developers/zfred27yVPg/discussion
>>
>> On Thursday, 21 March 2019 16:27:14 UTC+1, Carlton Gibson wrote:
>>>
>>> Hey Marcio. 
>>>
>>> If you can demonstrate that your abilities are sufficient in your 
>>> proposal, I'm sure we can mentor you through the pull request bit. (It's 
>>> just "contributor" implies knowledge of the internals, and the ORM **is** 
>>> the scariest bit, so... it's a bit  this close to starting.) 
>>>
>>> You've read the contributing guide right, and had a mooch around? Jump 
>>> in! https://docs.djangoproject.com/en/dev/internals/contributing/
>>>
>>>
>>> On the Timeline 
>>> <https://summerofcode.withgoogle.com/how-it-works/#timeline> applications 
>>> go from 25/3 to 9/4 so there's time to work on a draft, but Tim's right, we 
>>> do need that effort. 
>>>
>>> Standout areas for me:
>>>
>>> 1. So we ship a JSONField. With SQLite in mind, most people can't use 
>>> it, so we need a How-To of some kind on compiling SQLite   with the json1 
>>> extension and putting it in the right place so Python can find it. 
>>> 2. For the SQLite PoC, I'd like to see a more aggressive timeline right 
>>> at the beginning. The base field with save and load shouldn't be Too Hard™ 
>>> (c.f. jsonb.py 
>>> <https://github.com/django/django/blob/0b8abd7cdf1a5bae96dd0640af10ad504f104d06/django/contrib/postgres/fields/jsonb.py#L30-L83>
>>> )
>>>
>>> The issue is (3) the lookups and how to handle integrating those with 
>>> the existing postgres ones, the MySQL package and, the Oracle example. 
>>> A decent sketch of an answer there and we have a proposal I think. 
>>>  (Maybe it's an simple as `as_sqlite()`, `as_oralce()` etc, as with the 
>>> existing functions implementations, but...) 
>>>
>>> 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/b946345f-a7c9-4653-a909-6ae4d998cc1e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Help for GSoC proposal (Formset improvements)

2019-03-28 Thread Carlton Gibson
Hi Parth, 

Yes, something along those lines will be right. 

First-off, what are the existing work-arounds (i.e. how are people handling 
this in the wild: overriding `__init__()` methods etc...) — can these be 
summarised and documented, where worth recommending?

Then, API changes to improve on that situation, like passing in request 
objects. (From experience with DRF and django-filter, making the request 
available solves **most** issues for **most** users — "But I need X! — But 
that's just `request.X`" 9 times out of 10.) 

THEN, look at open accepted issues on Forms 
.
 
There are ≈70. Begin with FormSets issues, then spread out. Which are 
related? (#10403?) Which can you target? You don't have to solve them all 
(!) but a good goal for a 12 week project would be to become a total expert 
on django.forms, and to have handled a number of issues as part of that. 

HTH.

Kind Regards,

Carlton


On Tuesday, 26 March 2019 18:56:56 UTC+1, PARTH PATIL wrote:
>
> I was planning  to do the "Formset Improvements 
> " 
> project in GSoC. I would need some more explanation on what is expected as 
> nothing was clearly mentioned there.
> You can link the related tickets or elaborate on what is needed that would 
> be helpful.
>
> I dug a little bit deeper into this. and found some related issues 1 
> 
>  
> | 2. 
> 
>
> I'm planning to add a request variable in the BaseFormSet Class 
> 
>  
> and then handle it such that it will be available within every form (not 
> completely polished till now).
>
>1. Is this a good approach?
>2. Will this solve the problem? (If not please mention the problems 
>which will not be solved
>
> I am also looking for some additional features that maybe added to formset 
> so am open for suggestions.
> I'm currently in middle of making the abstract so before moving forward i 
> would like to get some confirmation that this is correct approach. Thank you
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/739596dd-772d-42ac-808e-32c670b8b683%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Test Framework Cleanup

2019-03-22 Thread Carlton Gibson
The suggestion involves the code in django.test.

https://github.com/django/django/tree/master/django/test

In particular see runner.py there. 



On Friday, 22 March 2019 13:29:05 UTC+1, Gourav Sardana wrote:
>
> Hey,
> I am Gourav Sardana undergraduate computer science student. I am 
> interested in test framework idea. I have a good experienced with django. 
> @Mentor Can i ask you one thing? we have to build a software or you have to 
> implement this to your core code i.e it will automatically check the code ?
> Regards,
> Gourav Sardana
>

-- 
You received this message because you are subscribed to the Google 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/82992e16-8694-4dc8-8e57-0f2f0002d751%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Fellow Reports -- March 2019

2019-03-21 Thread Carlton Gibson
Hi all. 


Calendar Week 10 -- ending 10 March.


Triaged:

https://code.djangoproject.com/ticket/30238 -- Exception when saving model 
created with string for DateField (Invalid)
https://code.djangoproject.com/ticket/30233 -- Add 
get_queryset_with_parent_obj to InlineModelAdmin to support access 
parent_models instance (wontfix)



Reviewed:

https://code.djangoproject.com/ticket/30226 -- Add base authentication 
backend to ease custom backend creation.
https://code.djangoproject.com/ticket/30237 -- Admin check for 
AuthenticationMiddleware should allow subclasses
https://code.djangoproject.com/ticket/30242 -- Double spaces before 
limit/offset clause in as_sql() of SQLCompiler
https://code.djangoproject.com/ticket/30186 -- Show applied datetime in 
showmigrations
https://code.djangoproject.com/ticket/29956 -- Allow formset form widget 
override for the ORDER field
https://code.djangoproject.com/ticket/30014 -- Initialising disabled 
ModelChoiceField yields Select a valid choice-error despite 
initialised option being valid
https://code.djangoproject.com/ticket/29834 -- Union queryset with ordering 
breaks on ordering with derived querysets
https://code.djangoproject.com/ticket/30064 -- Admin search with a null 
character crashes with A string literal cannot contain NUL (0x00) 
characters. on PostgreSQL




Calendar Week 11 -- ending 17 March.


Triaged:

https://code.djangoproject.com/ticket/30249 -- Deprecate re-raising view 
exceptions from test client in tests. (wontfix)
https://code.djangoproject.com/ticket/30248 -- Implement case insensitive 
fields in Sqlite (needsinfo)
https://code.djangoproject.com/ticket/30247 -- ModelMultipleChoiceField Bug 
- Initial Values has to be in queryset, does not make sense (Invalid)
https://code.djangoproject.com/ticket/30245 -- Run tests matching a filter 
(Python 3.7 -k option) (Accepted)



Reviewed:

https://code.djangoproject.com/ticket/30172 -- Incorrect migration applying 
for new Meta.constraints/indexes and field check/unique or 
unique/index_together constraints with same fields for postgres.
https://code.djangoproject.com/ticket/30199 -- get_or_create documentation 
encourages unsafe usage
https://code.djangoproject.com/ticket/30064 -- Admin search with a null 
character crashes with A string literal cannot contain NUL (0x00) 
characters. on PostgreSQL
https://code.djangoproject.com/ticket/30014 -- Added model instance cast in 
ModelChoiceField.to_python().
https://code.djangoproject.com/ticket/30237 -- Admin check for 
AuthenticationMiddleware should allow subclasses
https://code.djangoproject.com/ticket/30237 -- admin check for 
AuthenticationMiddleware should allow subclasses



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/3c3ddbcb-0725-4068-9aab-cd18ff179ca7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: GSoC Proposal

2019-03-21 Thread Carlton Gibson
Also, sorry, this was the key thread here, plus links 
therein 
https://groups.google.com/d/topic/django-developers/zfred27yVPg/discussion

On Thursday, 21 March 2019 16:27:14 UTC+1, Carlton Gibson wrote:
>
> Hey Marcio. 
>
> If you can demonstrate that your abilities are sufficient in your 
> proposal, I'm sure we can mentor you through the pull request bit. (It's 
> just "contributor" implies knowledge of the internals, and the ORM **is** 
> the scariest bit, so... it's a bit  this close to starting.) 
>
> You've read the contributing guide right, and had a mooch around? Jump in! 
> https://docs.djangoproject.com/en/dev/internals/contributing/
>
>
> On the Timeline 
> <https://summerofcode.withgoogle.com/how-it-works/#timeline> applications 
> go from 25/3 to 9/4 so there's time to work on a draft, but Tim's right, we 
> do need that effort. 
>
> Standout areas for me:
>
> 1. So we ship a JSONField. With SQLite in mind, most people can't use it, 
> so we need a How-To of some kind on compiling SQLite   with the json1 
> extension and putting it in the right place so Python can find it. 
> 2. For the SQLite PoC, I'd like to see a more aggressive timeline right at 
> the beginning. The base field with save and load shouldn't be Too Hard™ 
> (c.f. jsonb.py 
> <https://github.com/django/django/blob/0b8abd7cdf1a5bae96dd0640af10ad504f104d06/django/contrib/postgres/fields/jsonb.py#L30-L83>
> )
>
> The issue is (3) the lookups and how to handle integrating those with the 
> existing postgres ones, the MySQL package and, the Oracle example. 
> A decent sketch of an answer there and we have a proposal I think.  (Maybe 
> it's an simple as `as_sqlite()`, `as_oralce()` etc, as with the existing 
> functions implementations, but...) 
>
> 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/0f9f5f98-a3ae-49e4-8da3-443191e56e78%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: GSoC Proposal

2019-03-21 Thread Carlton Gibson
Hey Marcio. 

If you can demonstrate that your abilities are sufficient in your proposal, 
I'm sure we can mentor you through the pull request bit. (It's just 
"contributor" implies knowledge of the internals, and the ORM **is** the 
scariest bit, so... it's a bit  this close to starting.) 

You've read the contributing guide right, and had a mooch around? Jump 
in! https://docs.djangoproject.com/en/dev/internals/contributing/


On the Timeline  
applications 
go from 25/3 to 9/4 so there's time to work on a draft, but Tim's right, we 
do need that effort. 

Standout areas for me:

1. So we ship a JSONField. With SQLite in mind, most people can't use it, 
so we need a How-To of some kind on compiling SQLite   with the json1 
extension and putting it in the right place so Python can find it. 
2. For the SQLite PoC, I'd like to see a more aggressive timeline right at 
the beginning. The base field with save and load shouldn't be Too Hard™ 
(c.f. jsonb.py 

)

The issue is (3) the lookups and how to handle integrating those with the 
existing postgres ones, the MySQL package and, the Oracle example. 
A decent sketch of an answer there and we have a proposal I think.  (Maybe 
it's an simple as `as_sqlite()`, `as_oralce()` etc, as with the existing 
functions implementations, but...) 

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/11826bbe-53cc-412c-8003-009031cbb09c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: GSoC 2019 proposal - Easy Ethereum Blockchain integration

2019-03-21 Thread Carlton Gibson
Hi Diego. 

> Do you have any suggestion for bringing this proposal into GSoC's scope?

No. Sorry. 

Django is a web framework. So stuff in that area would be in-scope. 

Likely it's just my lack of imagination but, I think blockchain is a 
totally different area of tech. 
Equally if you'd have suggested "django-tensorflow" (say) I'd guess I'd 
think, "good luck but not for Django itself". 

I hope that makes sense. 

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/cff57ad7-b351-424b-867c-3678bf06bfff%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Welcome Mariusz Felisiak to his first day as a Django Fellow

2019-03-18 Thread Carlton Gibson
 Welcome aboard Mariusz! 

-- 
You received this message because you are subscribed to the Google 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/7ec12b7d-7541-43a2-aeec-575382ffba7e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: De-assigning "Easy pickings" tickets

2019-03-18 Thread Carlton Gibson
Given no dissenting voices, I'll act on this. 

I'll deassign the stalest tickets and leave a comment for more recently 
updated ones. 


-- 
You received this message because you are subscribed to the Google 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/1fafc83a-9034-48e9-b2d4-15141b296885%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Google "Season of Docs"

2019-03-18 Thread Carlton Gibson
Hi all, 

Parallel to GSoC, Google now have this "Season of Docs" programme: 

https://developers.google.com/season-of-docs/

The idea is experienced technical writers can get funding to work with open 
source projects on their docs. 

There are a lot of open Documentation issues 

. 

As such if you have, or if you know someone with, strong writing skills and 
you 
(they) might be interested here let me know and we can look into this. 

I can't quite work out whether if we just apply we might attract a writer, 
but it would be 
awesome if already someone in the community was keen for this.

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/34c05950-079b-4d64-a4f8-6dfcbf7f624d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: GSOC 19 PROPOSAL IDEA

2019-03-18 Thread Carlton Gibson
Hi Chinmay. 

Thanks for your interest. A 13 year old ticket would certainly be a 
nice-to-close. 

Some quick thoughts: 


   1. We're close to the deadline here, so can you turn this into a final 
   proposal? (Look at the example for a previous 
   year: https://gist.github.com/chrismedrela/82cbda8d2a78a280a129 — we need 
   something like this.) 
   2. You've begun well telling us who you are. But tell us more in your 
   proposal. We don't know you already and need to be confident that you'd be 
   likely to succeed in your project. 
   3. We already use select2 for the autocomplete in the 
   admin. https://select2.org. This would integrate well with that by the 
   looks of it. 
   4. Would this take 12 weeks? If not there are lots of Admin tickets 
   

 — 
   I'm sure we can help find some, but any related target ticket you identify 
   are all for the good. 

Time is short here. :)

Kind Regards,

Carlton


On Thursday, 14 March 2019 01:03:33 UTC+1, Chinmay Relkar wrote:
>
> Hi,
>My name is Chinmay Relkar. I'm a final year undergrad from India. 
> This is about my GSOC proposal idea. 
>
>While playing with django, I've always come across the absence of 
> bidirectional ManyToMany feature ticketed at
> *code.djangoproject.com/ticket/897 
> *. 
> I would like to work on this feature as a part of the GSOC program. 
> 
>To me this feature feels a bit small for a 12 week program. So 
> here's something I would like to add on:
>
> While adding a Model item in the admin interface with a ManyToMany 
> field, we get a MultiSelectWindow to choose multiple items of the related 
> model. This UI isn't very intuitive.
> 
> Taking inspiration from the Chips Component defined in Material Design 
> Guidelines at *https://material.io/design/components/chips.html 
> * I would like to 
> implement FilterChip for the same multi select window. The example of which 
> is attached below. 
>
> This is not a final proposal. I hope I'm not too late to share this here. 
>
> I'm eagerly waiting for a response of feedback and suggestions. 
>
> About my experience with Django, I've been working with it for past 2 
> years. Completed a total of 3 projects, one of which is live at *acsinet.net 
> * with a heavily customised admin panel.
>
> Talking about my level of expertise, I'm not a master to be true. But I 
> can customise any component of Django according to the stated requirements. 
> This is a very rough sketch of the proposal. Any suggestions, remarks or 
> comments will be of great help. 
>
> Hoping to get a feedback soon. 
>
> Regards,
> Chinmay Relkar
>

-- 
You received this message because you are subscribed to the Google 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/93cfee50-72be-4068-b700-dccc5d932b88%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: GSoC 2019 proposal - Easy Ethereum Blockchain integration

2019-03-18 Thread Carlton Gibson
Hi Diego. 

Thanks for your interest. 

> So my idea falls out of scope? Did I make a mistake?

I think there's a difference in kind between e.g. South and Django Debug 
Toolbar (or even things like Django Extenstions, or Braces or Model Utils) 
which support development with Django and your proposal which is more *building 
a feature in Django*. ("with" vs "in") Hopefully that distinction is clear 
enough for here and now. 

It's not that all "in" type third-party suggestion would be out of scope — 
I could imagine a good proposal for 2FA and One-time-passwords being at 
least considered, even if preferred as a third-party app, for example — but 
I think yes, "Using Blockchain in Django" is out of scope for us for GSoC. 

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/fdf957e6-b3f2-4625-9c36-2931f5734526%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Django 2.2 release candidate 1 released

2019-03-18 Thread Carlton Gibson
We've made the final (hopefully) release on the way to Django's next 
major release, Django 2.2! Check out the blog post: 
https://www.djangoproject.com/weblog/2019/mar/18/django-22-rc1/

-- 
You received this message because you are subscribed to the Google 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/0606040C-D01D-4BFD-956C-2663DCAE7BF2%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: status of 2.2 release blockers

2019-03-15 Thread Carlton Gibson
Hi All, 

Django 2.2rc1 is scheduled for today. There's a single release blocker that 
just needs a little work: 

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

As such, I'm looking towards Monday at this point. 

Final release on April 1 should be unaffected. 

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/e40c62a4-e713-4231-8f8e-8c03bf40bcbb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Support for unittest -k option

2019-03-11 Thread Carlton Gibson
Thanks François,

Just on this, my thought is that if we don't follow `unittest` in changing 
`-k` for this, we have a steady trickle of confusion forever-more. 
I'd rather avoid that. 

C.

On Monday, 11 March 2019 13:14:01 UTC+1, François Freitag wrote:
>
> Hi Django Devs, 
>
> https://code.djangoproject.com/ticket/30245 suggests supporting Python 
> unittest `-k` option, to selectively run tests matching a keyword. 
>
> Currently, `-k` is the shorthand for `--keepdb` in Django. 
> A `--filter` flag was suggested to preserve backward compatibility. 
> Carlton suggested removing the `-k` option from `--keepdb` and reusing 
> it for unittest `-k`. That would follow unittest more closely, reduce 
> user confusion and ease maintenance. 
>
> What do you think is best? Do you see other options? 
>
> If re-taking the `-k` option for unittest `-k`, should a new shorthand 
> be introduced for `--keepdb`? 
>
> Thanks for your time, 
> François 
>

-- 
You received this message because you are subscribed to the Google 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/c54e52d2-012a-4852-9375-be37add55945%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Exposing custom views in admin index page

2019-03-09 Thread Carlton Gibson
Just an aside on this, after the ORM, the admin has the second highest 
number of open accepted tickets. If we could bring that down, adding 
features would be cool, but it's a bit "Gulp" at the moment, if you take my 
meaning. 

> Note that django-admin-views is not compatible with Django 2.1.

Are the errors not addressable — 2 to 2.1 isn't the world's biggest change 
is it? (Probably a discussion for the repo...) 
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/4233ac3c-ade7-44d0-a127-380a14afd8d6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: help regarding google summer of code

2019-03-09 Thread Carlton Gibson
Hi Muhammad.

There was a thread about this the other day: 

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

Have a read. (Check out Aymeric's blog post series linked in that thread.) 

Work around Django's staticfiles app would be good. It would ideally be 
general purpose, rather than just targeting one JS framework. (i.e. not 
just Vue.) 

Kind Regards,

Carlton


On Saturday, 9 March 2019 04:05:56 UTC+1, Muhammad Faraz wrote:
>
> i am taking part first time in any open source project using summer of 
> code and i was think would the idea of integration django with front ends 
> like vuejs will it be acceptable front end support especially  for vuejs is 
> great in laravel due to watch package so i was thinking would proposal of 
> creating module that make the integration of font end frame works with 
> django easy will it be acceptable ?
>

-- 
You received this message because you are subscribed to the Google 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/2659c56f-5374-466b-b25c-86fba4397325%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: De-assigning "Easy pickings" tickets

2019-03-08 Thread Carlton Gibson
Hi Both. 

"Two months” just picked off about half the list looking at it. No real reason. 
Could easily be less. 

> Is there a bot for such a thing?

No, but bots! We need bots. 

Mariatta’s keynote at DjangoCon went over what she’s been doing with CPython. 

https://www.youtube.com/watch?v=uOLs3QeZy7M 
<https://www.youtube.com/watch?v=uOLs3QeZy7M>

She’s even got helpers and such on GitHub...

There’s a backporting one. We could easily have that. 

One that looked on Trac and saw if a PR was for a New Feature and then left a 
comment saying. “Carlton, please remember to check for the ..versionadded 
annotations” would be very useful for me. :)

I’ll expect something by Monday. 

Have a good weekend all. 
C.


> On 8 Mar 2019, at 21:29, Tobias McNulty  wrote:
> 
> Also generally in favor. Is there a bot for such a thing? It would be nice to 
> get a reminder a week or two *before* the unassign happens, either to prompt 
> an update OR an early self-unassign (if the person is not in fact working on 
> the ticket anymore and just didn't remember it was still assigned to them).
> 
> Tobias
> 
> On Fri, Mar 8, 2019, 3:22 PM Markus Holtermann  <mailto:i...@markusholtermann.eu>> wrote:
> Hi Carlton,
> 
> my only question would be why you picked 2 months over 1 or 3. Generally in 
> favor. I think de-assigning somebody after $time of inactivity on a ticket is 
> fair, regardless of the complexity of the ticket.
> 
> /Markus
> 
> On Fri, Mar 8, 2019, at 8:30 PM, Carlton Gibson wrote:
> > Hi all. 
> > 
> > We don't have many Easy Pickings tickets, they're all assigned, and get 
> > assigned quickly, but don't often get closed. 
> > 
> > Looking at the current batch...
> > 
> > https://code.djangoproject.com/query?status=assigned=new=1=id=status=changetime=1=changetime
> >  
> > <https://code.djangoproject.com/query?status=assigned=new=1=id=status=changetime=1=changetime>
> > 
> > ... I'd like to suggest that after 2 months we de-assign them, so they 
> > can get picked up by people looking, who are likely not 
> > willing/able/whatever to take over an assigned ticket themselves. 
> > 
> > Any thoughts/objections to that as a policy? 
> > 
> > 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 
> > <mailto:django-developers%2bunsubscr...@googlegroups.com>.
> >  To post to this group, send email to 
> > django-developers@googlegroups.com 
> > <mailto:django-developers@googlegroups.com>.
> >  Visit this group at https://groups.google.com/group/django-developers 
> > <https://groups.google.com/group/django-developers>.
> >  To view this discussion on the web visit 
> > https://groups.google.com/d/msgid/django-developers/7bb67aa2-c898-4b97-a43a-eba38c00e00e%40googlegroups.com
> >  
> > <https://groups.google.com/d/msgid/django-developers/7bb67aa2-c898-4b97-a43a-eba38c00e00e%40googlegroups.com>
> >  
> > <https://groups.google.com/d/msgid/django-developers/7bb67aa2-c898-4b97-a43a-eba38c00e00e%40googlegroups.com?utm_medium=email_source=footer
> >  
> > <https://groups.google.com/d/msgid/django-developers/7bb67aa2-c898-4b97-a43a-eba38c00e00e%40googlegroups.com?utm_medium=email_source=footer>>.
> >  For more options, visit https://groups.google.com/d/optout 
> > <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 
> <mailto:django-developers%2bunsubscr...@googlegroups.com>.
> To post to this group, send email to django-developers@googlegroups.com 
> <mailto:django-developers@googlegroups.com>.
> Visit this group at https://groups.google.com/group/django-developers 
> <https://groups.google.com/group/django-developers>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/8c599482-9c8e-4335-a5ff-7ffac96e94f8%40www.fastmail.com
>  
> <https://groups.google.com/d/msgid/django-developers/8c599482-9c8e-4335-a5ff-7ffac96e94f8%40www.fastmail.com>.
> For more options, visit https://groups.google.com/d/optout 
> <h

De-assigning "Easy pickings" tickets

2019-03-08 Thread Carlton Gibson
Hi all. 

We don't have many Easy Pickings tickets, they're all assigned, and get 
assigned quickly, but don't often get closed. 

Looking at the current batch...

https://code.djangoproject.com/query?status=assigned=new=1=id=status=changetime=1=changetime

... I'd like to suggest that after 2 months we de-assign them, so they can 
get picked up by people looking, who are likely not willing/able/whatever 
to take over an assigned ticket themselves. 

Any thoughts/objections to that as a policy? 

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/7bb67aa2-c898-4b97-a43a-eba38c00e00e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: GSoC 2019 Update

2019-03-08 Thread Carlton Gibson
Hey Matthew. Good issue, yes.  Thanks. 

Hey Tim. Yes, you're probably right...

 I was going to leave GSoC, but people asked and my tick, if I've got one, 
is "widen the pool of contributors" — so it seemed worth the effort to at 
least fill in the form. 

Maybe we get an applicant. Maybe we don't. 

Regardless, I'm using it as an opportunity to pull together ideas on how 
people can get going contributing. 

This was the big take-away from DjangoCon last year for me, so, 
ever-so-slowly-as-ever-in-oss I'm trying to make moves there. 

In part, I want to keep a Project Idea list going all the time. (I'd also 
like to keep "Are you a student? We're keen on GSoC" going all year too, 
since I totally agree that the gap between new-year and now isn't long 
enough to really get to know anyone...) 

So, if people have project ideas, I still want to hear them. 

I hope that makes sense. 
(I'm quite optimistic about this stuff really.) 

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/6b1ad5c8-90f1-4e46-838b-dcc4234b5d85%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


GSoC 2019 Update

2019-03-07 Thread Carlton Gibson
Hi all.

We were accepted as an Org to GSoC, so we can accept applications from the 
end of the month. 

I've updated the Wiki page...

https://code.djangoproject.com/wiki/SummerOfCode2019

... but *if you have project ideas *it would be good if you could add them!


I keep hearing, "Django's Mature", "There are no suitable projects" but I 
look at the >1300 accepted tickets and, well... I just don't believe that 
really. 

Taking Aymeric's advice, I broke down the accepted tickets by component: 


[image: Django-Accepted-tickets-by-component.png]


The top 4 there are: 


* ORM

* Admin

* Documentation

* Migrations. 


For the *ORM*, I think the cross-DB JSONField would be a great project. 
Florian worried it was too small in scope, but if it existed by the end of 
the summer, I would call that a success. 


ORM experts: what else though? (Anything?) 


For the *Admin*, there are a whole load of "filters" tickets. (Including 
the search issue from the thread here the other day). I've added working on 
that as an idea. But anything else? 



   - What we could really do with is someone becoming an expert in a 
   component and taking on a bunch of issues — Would that count as an 
   acceptable project? 
   - Could we do that for *Documentation*? (Would require strong written 
   English. Focus on Clarity. But...) 
   

Other ideas around the *docker-box* project and *CI*? Could we take input 
there? 
Translations tooling and flow? 
And so on...? 

Last chance to speak up. 

I'm hopeful we can get a decent application (or a few…) Let's see. 

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/aaa941a3-3ea7-4219-b558-b7ba89400772%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Exposing custom views in admin index page

2019-03-06 Thread Carlton Gibson
django-admin-views was functional as recently as Django 
2.0 https://github.com/frankwiles/django-admin-views/issues/34

I'm guessing it would be pretty easy to pick up. (Frank stated he was very 
happy for someone to become steward...) 

(I appreciate that doesn't address the "should we have this in core?" 
question.) 

On Wednesday, 6 March 2019 12:40:06 UTC+1, mrts wrote:
>
> Hello!
>
> Django ModelAdmin class has a nice way to create custom admin views with 
> get_urls(). What is missing however is a way to expose them in the admin 
> index page.
>
> Frank Wiles created the (now abandoned) django-admin-views package [1] as 
> a workaround and there are many questions regarding this in StackOverflow 
> [2][3][4][5].
>
> What do you think about exposing custom views in admin index page via a 
> new ModelAdmin.extra_views attribute?
> extra_views would be a list of dictionaries/objects with 'url' and 'name' 
> fields.
>
> They would be visible in the index page with the following change to 
> django/contrib/admin/templates/admin/index.html:
>
> --- 
> ../venv/Lib/site-packages/django/contrib/admin/templates/admin/index.html  
>  2019-02-28 01:22:12.767388100 +0200
> +++ templates/admin/index.html  2019-03-06 12:57:22.070586600 +0200
> @@ -43,6 +43,15 @@
>  
>  {% endif %}
>  
> +{% if model.extra_views %}
> +  {% for view in model.extra_views %}
> +
> +{{ view.name 
> }}
> +
> +
> +
> +  {% endfor %}
> +{% endif %}
>  {% endfor %}
>  
>  
>
> Best regards,
> Mart
>
> ---
>
> [1] https://github.com/frankwiles/django-admin-views 
> [2] 
> https://stackoverflow.com/questions/37512818/how-to-add-custom-page-to-django-admin-with-custom-form-not-related-to-any-mode
> [3] 
> https://stackoverflow.com/questions/53712723/add-a-link-to-custom-django-admin-view
> [4] 
> https://stackoverflow.com/questions/5693519/django-custom-view-into-admin-page
> [5] 
> https://stackoverflow.com/questions/49176113/make-new-custom-view-at-django-admin
>

-- 
You received this message because you are subscribed to the Google 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/b1710e2e-ad4d-4503-afb8-73d992ff89ca%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Fellow Reports -- February 2019

2019-03-04 Thread Carlton Gibson
Hi all. 


Calendar Week 8 -- ending 24 February.


Triaged:

https://code.djangoproject.com/ticket/30201 -- Form with IntegerRangeField 
does not validate (Invalid)
https://code.djangoproject.com/ticket/30197 -- Template variable resolution 
with class objects (Duplicate of #15791)
https://code.djangoproject.com/ticket/30200 -- Add support for using 
indexes in update() for ArrayFields. (Accepted)
https://code.djangoproject.com/ticket/30199 -- get_or_create documentation 
encourages unsafe usage (Accepted)
https://code.djangoproject.com/ticket/30195 -- RawSQL ignores 
decimal_places property of DecimalField (wontfix)
https://code.djangoproject.com/ticket/30194 -- Documentation default 
language is Indonesian instead of English (Invalid)
https://code.djangoproject.com/ticket/30191 -- UnicodeDecodeError from 
non-FK field when using .delete() after Python 3 upgrade (Invalid)
https://code.djangoproject.com/ticket/30189 -- sqlmigrate wraps its 
outpout in BEGIN/COMMIT even if the database doesnt support 
transactional DDL (Accepted)
https://code.djangoproject.com/ticket/30190 -- json lines (jsonl) 
serializer (needsinfo)



Reviewed:

https://code.djangoproject.com/ticket/18707 -- Test client doesnt 
allow testing 500 responses content
https://code.djangoproject.com/ticket/30193 -- Changes to PostgreSQL 
ensure_timezone caused unnecessary roundtrips to the database on connection 
initialization.
https://code.djangoproject.com/ticket/28991 -- Add an admin filter with 
choices all, blank, not blank
https://code.djangoproject.com/ticket/30010 -- Add support for running the 
test suite through docker with docker-compose



Calendar Week 9 -- ending 03 March.


Triaged:

https://code.djangoproject.com/ticket/30220 -- Use headless browsers for 
selenium tests (Accepted.)
https://code.djangoproject.com/ticket/30226 -- Add base authentication 
backend to ease custom backend creation. (Accepted)
https://code.djangoproject.com/ticket/30222 -- Documentation bug for base 
managers (Invalid)
https://code.djangoproject.com/ticket/29918 -- Add support for checking 
object permissions in PermissionRequiredMixin (wontfix)
https://code.djangoproject.com/ticket/20218 -- Default authorization 
backend returns False when queried for object level permissions (wontfix)



Reviewed:

https://github.com/django/django/pull/11038 -- Tiny permission-related docs 
adjustments
https://github.com/django/django/pull/11037 -- Improve/simplify the 
permissions API
https://code.djangoproject.com/ticket/30128 -- Using database functions 
with tzinfo=datetime.timezone(datetime.timedelta(...)) results in an 
incorrect query
https://code.djangoproject.com/ticket/29408 -- Add validation of related 
fields in model Meta.ordering
https://github.com/django/django/pull/10636 -- Some authentication changes 
for improving documentation



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/aa56bca7-ead9-4999-933f-1b18d191ed4c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: GSoC 2019 Project Idea

2019-03-03 Thread Carlton Gibson
Hi Parth. 

I'm guessing this would be out of scope for Django: it's sounds like the 
sort of functionality that we prefer to live in third-party apps, rather 
than in Django itself. 
(It sounds like a good enough idea — there are plenty of Jekyll, or other 
static, sites out there, but just not something for core.) 

As I just posted elsewhere, I'm looking to work on the GSoC stuff over the 
next couple of weeks. 

Kind Regards,

Carlton


On Sunday, 3 February 2019 11:04:07 UTC+1, PARTH PATIL wrote:
>
> Hey, I had a project idea for GSoC.
> I wanted to make a tool which will help to port static projects like 
> Jekyll to Django directly.
> I am still thinking about the details of the idea.
>
> But I want to know:
>
>- is this idea feasible/useful?
>- Does there already exist a similar tool for this?
>- Is this a good idea for GSoC?
>
> I got this idea last year when I was working on my club website which was 
> written using Jekyll and I had to port it to Django framework since it was 
> going to be hosted on our college server which had Django backend.
> The problem was we constantly had to update the website with post, so I 
> was just left with the option to rewrite all the code natively in Django. 
> That's why I thought of making a tool which will take a Jekyll project and 
> convert it to Django app, with proper views and models etc.
>
>  
>

-- 
You received this message because you are subscribed to the Google 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/6552d234-0ea4-4729-a7d6-8e5688bdb736%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Google Summer of Code 2019

2019-03-03 Thread Carlton Gibson
Hi. 

In general, for GSoC, I want to look at the project ideas, the org profile, 
and such over the next couple of weeks.
I try and make the Org page the starting point. 

Kind Regards,
Carlton

On Sunday, 3 March 2019 15:01:12 UTC+1, Gaurav Agarwal wrote:
>
> Hi, I am a student from IIT Guwahati. I am familiar with Python and 
> Django. I want to contribute. How should I start?
>
>
> On Wednesday, January 16, 2019 at 8:03:55 PM UTC+5:30, Tim Graham wrote:
>>
>> Org applications for Google's Summer of Code are now open (deadline 
>> February 6). Do you think the Django Software Foundation should participate?
>>
>> We haven't had any high quality student applications that we could accept 
>> for the past two years.
>>
>> Perhaps it's partly a function of a poor ideas page (
>> https://code.djangoproject.com/wiki/SummerOfCode2018). Perhaps we don't 
>> do a great job of publicizing our involvement and attracting high quality 
>> students. Perhaps it's because the student payment isn't all that much 
>> (+/-$6000 USD, depending on student's country)* for the amount of work 
>> involved (also, students have to put in a lot of work up front in their 
>> application, with no guarantee of being accepted into the program).
>>
>> If you have any ideas about mentoring or suggesting a project, or if 
>> you're serious about being a student (you should start contributing to 
>> Django now if you don't already), please share.
>>
>> * https://developers.google.com/open-source/gsoc/help/student-stipends
>>
>

-- 
You received this message because you are subscribed to the Google 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/819dd1bf-4d62-47b7-93f7-fed20192ed37%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: GSOC 2019 proposal - Dashboard

2019-03-03 Thread Carlton Gibson
Hi Mainak. 

Initially I'm inclined to say this would fall into one or both of two 
problems: 

1. Too ambitious: phenomenally difficult to build this within the project 
time. 
2. Out of scope for Django: it's sounds like the sort of functionality that 
we prefer to live in third-party apps, rather than in Django itself. 

Do you have any kind of prototype code in place? A rough demo might give 
more insight into both these points. 

In general, for GSoC, I want to look at the project ideas, the org profile, 
and such over the next couple of weeks.

Kind Regards,

Carlton



On Sunday, 3 March 2019 16:48:43 UTC+1, Mainak Dutta wrote:
>
> On top of the existing Django extension. 
>
> On Sunday, March 3, 2019 at 9:14:51 PM UTC+5:30, Asif Saif Uddin wrote:
>>
>> How you plan to implement the features? new or on top of 
>> existing django admin extension?
>>
>> On Sunday, March 3, 2019 at 8:01:12 PM UTC+6, Mainak Dutta wrote:
>>>
>>> I have been thinking of implementing a uniform Dashboard which can be 
>>> implemented into the Django framework using just one line. Every 
>>> organization uses Dashboard. So, creating a dashboard can be very useful. 
>>>
>>> The features will include - 1] Variable no of sections and Custom 
>>> section names
>>>   2] Inclusion of links in the 
>>> section 
>>>   3] Database and table from 
>>> database we will populate the dashboard entry automatically
>>>   4] Choice of fonts
>>>   5] Choice of Color
>>>   6] Choice of height and width 
>>> of the section. 
>>>
>>> In fact ,We can extend this concept to create custom page. And give the 
>>> user the option of custom pages having variable number of entries in the 
>>> navigation bar and Variable number of sections and Presence or absence of 
>>> images in the Section. With all this ready made, users can create a running 
>>> website very very quickly.  
>>>
>>>

-- 
You received this message because you are subscribed to the Google 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/d58aeaa5-9a5a-4697-80f5-fbdfd93d0665%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Fellow Reports -- February 2019

2019-02-22 Thread Carlton Gibson
Hi all. 


Calendar Week 6 -- ending 10 February.


Triaged:

https://code.djangoproject.com/ticket/30154 -- i18n: redirects to default 
login page if LOGIN_URL = login not specified (Accepted)
https://code.djangoproject.com/ticket/30149 -- Empty value selected check 
in Admin Filter prevents subclassing (Accepted)



Reviewed:

https://code.djangoproject.com/ticket/29956 -- Allow formset form widget 
override for the ORDER field
https://code.djangoproject.com/ticket/30004 -- Set default 
FILE_UPLOAD_PERMISSION to 0o644.
https://code.djangoproject.com/ticket/29408 -- Add validation of related 
fields in model Meta.ordering
https://code.djangoproject.com/ticket/29915 -- Allow icontains lookup to 
accept uuids with or without dashes
https://code.djangoproject.com/ticket/30160 -- Added support for 
lzma-compressed tarfiles.
https://github.com/django/django/pull/10908 -- Update to logging 
documentation.



Authored:

https://github.com/django/django/pull/10928 -- Fixed #30154 -- Doc’d 
LOGIN_URL compat with i18n URLs.
https://github.com/django/django/commit/402c0caa851e265410fbcaa55318f22d2bf22ee2
--  Fixed CVE-2019-6975 -- Fixed memory exhaustion in 
utils.numberformat.format().




Calendar Week 7 -- ending 17 February.


Released Django 2.2b1, 2.1.6, 2.0.11, and 1.11.19 AND 2.17, 2.0.12 and 
1.11.20 AND 2.0.13. 
(This is a personal best, if not a project record. )


Reviewed:

https://code.djangoproject.com/ticket/12952 -- Models history doesnt 
use verbose names
https://code.djangoproject.com/ticket/11593 -- Incomplete support for 
app-level testing
https://code.djangoproject.com/ticket/30149 -- Empty value selected check 
in Admin Filter prevents subclassing
https://code.djangoproject.com/ticket/23004 -- Cleanse entries from 
request.META in debug views
https://code.djangoproject.com/ticket/29714 -- Make it easier to customise 
ExceptionReporter output.
https://code.djangoproject.com/ticket/29956 -- Allow formset form widget 
override for the ORDER field



Authored:

https://github.com/django/django/pull/10991 -- Restored use of realpath() 
in Admin script tests.



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/4b2caa48-2a73-4363-bcd1-d93f602ebe63%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Google Summer of Code 2019

2019-02-15 Thread Carlton Gibson
The timeline for GSoC is 
here: https://summerofcode.withgoogle.com/how-it-works/#timeline

Applications are ≈ a month away. 

Here's an example from a previous 
year: https://gist.github.com/chrismedrela/82cbda8d2a78a280a129

I'd suggest drafting things in more detail and starting a new thread to 
invite discussion. 

I don't know what'll be suitable: it depends on the proposal: 

- something not in core? Yeah, maybe. 
- Something for deployment? Well, seems a bit ambitious, but again maybe... 
- Bringing the two(?) community Redis cache backends into one in core? 
Reasonable idea perhaps, yes. 
- A cross-db JSONField etc. Yep, great... 

...and so on. What do you want to work on? 


-- 
You received this message because you are subscribed to the Google 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/e1e1aed4-ef58-498d-b03e-e29e0246f9c5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Google Summer of Code 2019

2019-02-14 Thread Carlton Gibson
Hmmm. I think that would be out for scope for Django. More suited to tools 
such as Ansible (and similar). I don't think adding a one step deployment 
story would really be feasible within a GSoC project. (As you say, it's 
very complex.) 

On Thursday, 14 February 2019 18:46:52 UTC+1, Shashank shet wrote:
>
> Thank you Carlton. I had in mind an idea for providing out-of-the-box 
> webserver deployment capability. In the projects I've done, one of the most 
> time consuming tasks for us was deployment on a server, mainly due to a 
> lack of experience. That's why I figured that an automated system for 
> deployment would be helpful. It would work similar to the runserver 
> command, taking essential configurations from a designated file and not 
> having to actually make changes to files in different parts of the 
> filesystem, or following a long list of instructions manually. Any 
> suggestion would be very helpful.
>
>
> On Thursday, February 14, 2019 at 6:32:17 PM UTC+5:30, Carlton Gibson 
> wrote:
>>
>> Hi Shashank. 
>>
>> "Sir"? That's my father, surely.  (Not "sir" ) 
>>
>> We've applied as an Org. Haven't heard yet whether we'll be accepted. 
>>
>> If so, proposals would be welcome. We'd then need to think about mentors. 
>> Good proposals will draw out people there. 
>>
>> If we can get all that lined up then, yes, in principle we're accepting 
>> applications. 
>>
>> Kind Regards,
>>
>> Carlton
>>
>>
>> On Thursday, 14 February 2019 13:46:57 UTC+1, Shashank shet wrote:
>>>
>>> Hello Carlton sir,
>>> I have worked on Django as a part of a project and wished to ask if the 
>>> organization is still accepting proposals for GSoC 2019. 
>>>
>>> On Monday, February 4, 2019 at 8:25:42 PM UTC+5:30, Carlton Gibson wrote:
>>>>
>>>> And thank you Tim, yes, exactly what I need. 
>>>>
>>>> To all: 
>>>>
>>>> I will put in the org application today. We'll then see about the 
>>>> proposals. 
>>>>
>>>> The main thing is that we need to know who you are, and have confidence 
>>>> in you in order to commit to the project with you. 
>>>> For people to mentor you is a big commitment of time and energy. You 
>>>> need to demonstrate that will be well invested. 
>>>>
>>>> The way to do that is to get involved and show us who you are over the 
>>>> next few months. 
>>>> Help reproduce bugs, review patches, create patches etc. 
>>>> It doesn't take much before you're visible. (Really!) 
>>>>
>>>> The best way (also) to come up with project ideas is to see where there 
>>>> are issues already. 
>>>> (Much better than us providing a list.) So again, be involved. 
>>>>
>>>> If you start now, there's still lots of time, so I'm hoping. 
>>>>
>>>> Kind Regards,
>>>>
>>>> Carlton
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Monday, 4 February 2019 15:43:39 UTC+1, Tim Graham wrote:
>>>>>
>>>>> It's a private wiki that only Django team members like Carlton can 
>>>>> access. It contains the information for Django to apply for GSoC.
>>>>>
>>>>> On Monday, February 4, 2019 at 9:07:40 AM UTC-5, Giuseppe De Marco 
>>>>> wrote:
>>>>>>
>>>>>> Hi Tim,
>>>>>>
>>>>>> It returns 404 to me
>>>>>>
>>>>>> https://github.com/django/django-team-wiki/wiki/Google-Summer-of-Code-Application-Info
>>>>>>
>>>>>> Il giorno lun 4 feb 2019 alle ore 13:05 Tim Graham <
>>>>>> timog...@gmail.com> ha scritto:
>>>>>>
>>>>>>> All answers are at 
>>>>>>> https://github.com/django/django-team-wiki/wiki/Google-Summer-of-Code-Application-Info
>>>>>>>
>>>>>>

-- 
You received this message because you are subscribed to the Google 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/87bb632d-360c-486d-92e1-431ddcb05bb2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Google Summer of Code 2019

2019-02-14 Thread Carlton Gibson
Hi Shashank. 

"Sir"? That's my father, surely.  (Not "sir" ) 

We've applied as an Org. Haven't heard yet whether we'll be accepted. 

If so, proposals would be welcome. We'd then need to think about mentors. 
Good proposals will draw out people there. 

If we can get all that lined up then, yes, in principle we're accepting 
applications. 

Kind Regards,

Carlton


On Thursday, 14 February 2019 13:46:57 UTC+1, Shashank shet wrote:
>
> Hello Carlton sir,
> I have worked on Django as a part of a project and wished to ask if the 
> organization is still accepting proposals for GSoC 2019. 
>
> On Monday, February 4, 2019 at 8:25:42 PM UTC+5:30, Carlton Gibson wrote:
>>
>> And thank you Tim, yes, exactly what I need. 
>>
>> To all: 
>>
>> I will put in the org application today. We'll then see about the 
>> proposals. 
>>
>> The main thing is that we need to know who you are, and have confidence 
>> in you in order to commit to the project with you. 
>> For people to mentor you is a big commitment of time and energy. You need 
>> to demonstrate that will be well invested. 
>>
>> The way to do that is to get involved and show us who you are over the 
>> next few months. 
>> Help reproduce bugs, review patches, create patches etc. 
>> It doesn't take much before you're visible. (Really!) 
>>
>> The best way (also) to come up with project ideas is to see where there 
>> are issues already. 
>> (Much better than us providing a list.) So again, be involved. 
>>
>> If you start now, there's still lots of time, so I'm hoping. 
>>
>> Kind Regards,
>>
>> Carlton
>>
>>
>>
>>
>>
>> On Monday, 4 February 2019 15:43:39 UTC+1, Tim Graham wrote:
>>>
>>> It's a private wiki that only Django team members like Carlton can 
>>> access. It contains the information for Django to apply for GSoC.
>>>
>>> On Monday, February 4, 2019 at 9:07:40 AM UTC-5, Giuseppe De Marco wrote:
>>>>
>>>> Hi Tim,
>>>>
>>>> It returns 404 to me
>>>>
>>>> https://github.com/django/django-team-wiki/wiki/Google-Summer-of-Code-Application-Info
>>>>
>>>> Il giorno lun 4 feb 2019 alle ore 13:05 Tim Graham  
>>>> ha scritto:
>>>>
>>>>> All answers are at 
>>>>> https://github.com/django/django-team-wiki/wiki/Google-Summer-of-Code-Application-Info
>>>>>
>>>>

-- 
You received this message because you are subscribed to the Google 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/96816957-08b6-4896-9bcf-f138e1dc06bb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Django bugfix release 2.0.13.

2019-02-12 Thread Carlton Gibson
Details are available on the Django project weblog: 

https://www.djangoproject.com/weblog/2019/feb/12/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/3DF50D9E-AF47-4EFE-A570-971CE48499D2%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Post mortem on today's packaging error.

2019-02-12 Thread Carlton Gibson
Hi All, 

Thanks for all the comments. 

Cloning to a tmp folder and checking out a specific commit is both quick 
and easy. That's not a bad idea: it should eliminate the point of failure 
that occurred here. 
(The `git clean` step should do that too, we use the `fdx` flags to 
eliminate ignored files etc, and it does remove build and dist dirs, but... 
well... something went wrong.) 

I want to add automated running of the test suite against the generated 
src-dist. That would have caught the issues too. This seems to me to be the 
most reliable way to verify that what got packaged was in fact correct. 

I don't think we need to automate any further the final actual shipping of 
the package. `twine upload -s` is pretty easy, and I do worry about us 
putting the signing keys on even a private server really. 

Grrr. Definitely sub-par yesterday. Onwards! :)
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/ac3e4168-139c-4973-a1fc-e6e1e3b3a45e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Post mortem on today's packaging error.

2019-02-11 Thread Carlton Gibson
Hi all. 

This morning I released four versions of Django. Three of which, for 2.1, 
2.0 and 1.11. (i.e. all the actually supported versions) were broken. 
In the package were additional files from `master`/2.2 which shouldn't have 
been there. 

This afternoon I have released follow-ups to correct this issue. 

First of all, sorry about that, and for any inconvenience caused. 


Then, these are process issues so, how can we do better next time? 

I'm not 100% sure what occurred. 

* The history in Git is correct. 
* I must have had the right commits checked out, because the package 
metadata is correct. (Filenames, version numbers and so on.) 

My best guess is that I've failed to `git clean` correctly before building 
each release. 
I'm not certain here because switching between branches doesn't leave the 
repos in an unclean state, and I'm pretty sure it was clean, but this seems 
the most likely error.


Q: is there a nice git command to "assert I'm at exactly this tag"?  


Steps I've taken: 

* Moved the `git clean` step into the helper script used to build the 
packages. No chance of then missing it. 
* Added a `diff`-step after building just to make sure what's in the 
`django` module matches the checkout. 
 
The second of these, whilst just a visual check, would have worked with 
what ended up in the package vs what was in my working tree when I checked 
later, but I'm not sure it would have caught the issue when the package was 
created (because presumably my working tree was wrong at that point). 

A similar issue affects the checksums, which check that nothing changed 
since it was packaged, but not that the right things were packaged...
(Similarly, pip install worked without error.) 

On the new 1.11 package, I created a virtualenv with Python 2 and ran the 
test suite. This worked so it should be good. But it would be good to 
automate this. 
(I'll look into it.) We don't ship the tests in the wheel, so we have to 
use the src-dist for this. (We could then diff the two django modules to 
make sure they were the same.) 

On the other packages I visually looked for incorrect files, but, beyond 
specific migrations (etc) that were known bad from the previous release, 
this doesn't generalise. 

"zaytsev" on IRC suggested running `makemigrations --check`, so having a 
test project to install against might also be worth it. 
(I'd guess running the test suite would be sufficient...) 


Any other thoughts very welcome. 


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/90c531fc-3d5b-4d9e-a55f-b88f2e04bb54%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Django bugfix releases: 2.1.7, 2.0.12 and 1.11.20

2019-02-11 Thread Carlton Gibson
Updated releases correcting a packaging issue from this morning are now 
available for the 2.1, 2.0 and 1.11 release branches. 

https://www.djangoproject.com/weblog/2019/feb/11/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/4FDCEA5F-D8BC-4F9C-8B0B-FB6F02DDEE59%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Django security releases issued: 2.1.6, 2.0.11, and 1.11.19

2019-02-11 Thread Carlton Gibson


On Monday, 11 February 2019 13:46:04 UTC+1, Bruno Alla wrote:
>
>  Did something go wrong during the release publication?
>

Yes. Additional files were packaged. (In all except the 2.2b1 release as 
far as I can tell.) 

I will release updated versions shortly.

I'll then publish a post-mortem.

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/1fb176e7-b477-4d47-ad8f-6d62df89865c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Django security releases issued: 2.1.6, 2.0.11, and 1.11.19

2019-02-11 Thread Carlton Gibson


On Monday, 11 February 2019 13:15:12 UTC+1, riccardo.magliocchetti wrote:
>
>
> Yeah, what i'm reporting is that the wheel pip downloaded here does not 
> match 
> the 1.11.19 tag in git. 
>

OK. Thanks. I'll have a look.  

-- 
You received this message because you are subscribed to the Google 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/0d9ef728-cd44-4754-a31a-cf604fe6afbe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Django security releases issued: 2.1.6, 2.0.11, and 1.11.19

2019-02-11 Thread Carlton Gibson
Hi Riccardo. 

Please open a Trac ticket for this. (Current test suite passes, so it looks 
like we're missing coverage somewhere.) 
Thanks.

On Monday, 11 February 2019 12:26:04 UTC+1, riccardo.magliocchetti wrote:
>
> Hello Carlton, 
>
> Il 11/02/19 12:02, Carlton Gibson ha scritto: 
> > Today the Django team issued 2.1.6, 2.0.11, and 1.11.19 as part of our 
> security process. These releases address a security issue, and we encourage 
> all users to upgrade as soon as possible: 
> > 
> > https://www.djangoproject.com/weblog/2019/feb/11/security-releases/ 
> > 
>
> 1.11.19 blew my tests on python 2.7, python3 works fine: 
>File "/usr/local/lib/python2.7/site-packages/django/template/base.py", 
> line 
> 184, in __init__ 
>  engine = Engine.get_default() 
>File 
> "/usr/local/lib/python2.7/site-packages/django/utils/lru_cache.py", line 
> 124, in wrapper 
>  result = user_function(*args, **kwds) 
>File 
> "/usr/local/lib/python2.7/site-packages/django/template/engine.py", line 
> 76, in get_default 
>  django_engines = [engine for engine in engines.all() 
>File "/usr/local/lib/python2.7/site-packages/django/template/utils.py", 
> line 
> 89, in all 
>  return [self[alias] for alias in self] 
>File "/usr/local/lib/python2.7/site-packages/django/template/utils.py", 
> line 
> 80, in __getitem__ 
>  engine = engine_cls(params) 
>File 
> "/usr/local/lib/python2.7/site-packages/django/template/backends/django.py", 
>
> line 30, in __init__ 
>  options['libraries'] = self.get_templatetag_libraries(libraries) 
>File 
> "/usr/local/lib/python2.7/site-packages/django/template/backends/django.py", 
>
> line 48, in get_templatetag_libraries 
>  libraries = get_installed_libraries() 
>File 
> "/usr/local/lib/python2.7/site-packages/django/template/backends/django.py", 
>
> line 113, in get_installed_libraries 
>  for name in get_package_libraries(pkg): 
>File 
> "/usr/local/lib/python2.7/site-packages/django/template/backends/django.py", 
>
> line 130, in get_package_libraries 
>  "trying to load '%s': %s" % (entry[1], e) 
> InvalidTemplateLibrary: Invalid template library specified. ImportError 
> raised 
> when trying to load 'django.contrib.admin.templatetags.base': cannot 
> import name 
> getfullargspec 
>
> 1.11.18 works fine for the same test. 
>
> -- 
> Riccardo Magliocchetti 
> @rmistaken 
>
> http://menodizero.it 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/2d1dcdb6-9049-4c10-8f81-ff7a159c3383%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Django 2.2 beta 1 released

2019-02-11 Thread Carlton Gibson
We've made the second release on the way to Django's next major 
release, Django 2.2! With less than two months until the final release, 
we'll need timely testing from the community to ensure a stable 
release. Check out the blog post: 

https://www.djangoproject.com/weblog/2019/feb/11/django-22-beta-1-released/


-- 
You received this message because you are subscribed to the Google 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/7A5024B3-17A8-44F6-9784-4FAE0733C1F2%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


Django security releases issued: 2.1.6, 2.0.11, and 1.11.19

2019-02-11 Thread Carlton Gibson
Today the Django team issued 2.1.6, 2.0.11, and 1.11.19 as part of our security 
process. These releases address a security issue, and we encourage all users to 
upgrade as soon as possible: 

https://www.djangoproject.com/weblog/2019/feb/11/security-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/1EB1699A-228E-4151-9726-50042904A4CE%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


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

2019-02-07 Thread Carlton Gibson
Hi Abhilasha, 

There's any number of ways you could go... 

But...

Have a look at Simon Willison's Datasette project. 
http://datasette.readthedocs.io/

In particular see the various ...-to-sqlite tools listed here: 
https://datasette.readthedocs.io/en/latest/ecosystem.html

If you can get that far then the existing `inspectdb` tool can get you to 
model files. 

No doubt you could improve the workflow but that should give you some guide 
to get started. 

Kind Regards,

Carlton


On Thursday, 7 February 2019 12:34:21 UTC+1, Abhilasha Jha wrote:
>
> Hi all,
> I was thinking if a feature could be added to Django models, such that 
> when the CSV/ text or any other commonly used data file is added to the 
> project and the models are automatically created and populated. I have not 
> tried to go through nitty-gritty of the feature, but am thinking of doing 
> this and contributing to Django, and needed some guidance on same.
>
> Thanking you
> Abhilasha
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/73aa7ec8-23ad-4f8e-84aa-bc66fb3be85b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Fix for Django Channels issue #962

2019-02-05 Thread Carlton Gibson
Hi Joonhyung.

Ah, the hardest issue in the box. Good. 
TBH I haven't had a chance to even look at that one yet, and I'll need to 
pull out the Stevens & Rago when I do...
— anyone here with serious chops, please do feel free to input. 

I think best if you comment on the issue. There's already a good discussion 
there. 

Also, there's really no harm in opening a PR to show the change. Even if 
it's not the right solution, it helps to have something to look at. 

Kind Regards,

Carlton



On Tuesday, 5 February 2019 13:15:55 UTC+1, joonhyu...@gmail.com wrote:
>
> Hello,
>
> This is my first post here. I'd like to discuss some ways of fixing the 
> issue for Django Channels.  
> Briefly 
> speaking, any test for Channels written with ChannelsLiveServerTestCase 
> freezes in MacOS.
>
> As a Mac user, I wanted to find a way to write tests, so I spent nearly 
> half a day debugging Channels, and finally got the answer. The thing was 
> that Python asyncio library does not behave very well with multiprocessing.
>
> To be specific, ChannelsLiveServerTestCase relies on DaphneProcess, which 
> again relies on asyncio. Finally, asyncio is based on Kqueue in BSD-like 
> OSes. Unfortunately, Kqueue is not inherited to a child process upon 
> fork(), while the file descriptor table does. This causes a problem when 
> the DaphneProcess of a child process tries to register event handlers for 
> sockets, because the file descriptor is still opened but the Kqueue does 
> not exist anymore. At this point, MacOS users see an error: bad file 
> descriptor. (I've checked lsof of the file descriptor, and found that it 
> points to /dev/null.)
>
> In Unix-like systems, although the above problem does not occur, the file 
> descriptor table is shared with its child, so forking while asyncio event 
> loop is opened should be avoided if possible. I suggest three ways to get 
> around this issue.
>
> 1. Close the forked loop and create a new event loop when DaphneProcess
>  runs.
> 2. Modify multiprocessing-based design to threading-based design. In other 
> words, run tests in single process, multi-thread environment.
> 3. Run tests in single process, single thread environment.
>
> The easiest way is 1, which I already committed in my own fork 
> ,
>  
> but this looks like a cheating, so I'm not very happy with this solution. 
> Nevertheless it passes all tests of Channels and Daphne, and moreover 
> Channels 
> tutorial  
> works fine with BSD-like OSes such as MacOS. (I've tested on both MacOS and 
> Linux.) If you think this is fine, then I will be happy to send a PR.
>
> Which one would be the most desirable design?
>

-- 
You received this message because you are subscribed to the Google 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/e8b58f70-f0ef-4b27-99ab-165c92643e2e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Extend FAQ with "How do I get Django and my JS framework to work together?"

2019-02-05 Thread Carlton Gibson
I think this topic is very interesting. 

Two sides of it: 

* Static files handling
* APIs

Curtis is right, there are other options but, Django REST Framework is 
(whilst not perfect) pretty solid on the API front. I think Django has a 
good story here. 
It's pretty hard not to find DRF if you follow any guide, or any searching 
at all. 

The static files story is a little different. It seems to me we don't tell 
the best story there. 

Rails has two things which we could be envious of, even if we didn't want 
to copy exactly:

* The frontend framework integration that's already been mentioned. 
* The very easy "Ajax your form", with controllers (i.e. for us "generic 
views") automatically handling ajax form submissions. 

Both these features get users further quicker in these aspects than we are 
able to offer. 

We struggle to think of areas for improvements (re GSoC for example) but 
maybe here is an area. 

This ties into Claude's proposal here: 
https://groups.google.com/d/topic/django-developers/KYmNnvwXDUI/discussion

My own story is, I've had lots of success with, and still use, Django 
Compressor.  

   - At it's simplest you just map a content type to a shell command to run 
   and then include your Sass/Less/React/Elm/whatever files in your HTML (with 
   script or link tags, almost in the old-school way). 
   - In development these are processed (& cached) per request. 
   - For deployment you just run an offline compression task (management 
   command) and then upload the files. 
   - That's it. 

It's not a coverall approach — a frontend engineer will come along and 
totally replace Compressor with whatever is this week's Top Javascript 
Build System™ BUT it is a good 80:20: it lets me do something (that 
approximates) respectable, without knowing hardly anything about the latest 
frontend hotness. (GNU Make FTW! ) 

I think if we were to offer something out-of-the-box that got as far as 
Compressor, or further, we'd:

   - satisfy most of our users, 
   - allow yet more to get off the mark quickly, 
   - and... well... those that need the full frontend toolchain would still 
   be free to use it. 
   
I worry we'd never get anything like this into core... but I think it would 
be good. (As I say, I think it's one area where we are lacking/behind the 
competition.)

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/49deee81-0230-48a0-8c2a-b12eb0956810%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Help needed on Django-Guardian.

2019-02-04 Thread Carlton Gibson
Excellent. 

The place to follow up is on the Guardian repo. (Make PRs that close issues!)

I’m sure from there you can work out with Adam the best way forward (be that as 
a collaboration or Jazzband or ...). 

Here I’m just passing on the need for help. Thanks for the positive response 
all! 

Sent from my iPhone

> On 5 Feb 2019, at 07:21, Asif Saif Uddin  wrote:
> 
> Hi Carlton,
> 
> If needed I could be a collaborator of that. I get some monthly payment for 
> my open source python works :)
> 
>> On Monday, February 4, 2019 at 3:01:38 AM UTC+6, Carlton Gibson wrote:
>> Hi all. 
>> 
>> Adam Dobrawy who runs Django-Guardian, could do with some help maintaining 
>> there. 
>> 
>> The project seems to be in good shape. (It's up to date) But needs a bit of 
>> help keeping on top of the issues, dropping old-versions, and the rest of 
>> it. 
>> 
>> I see the project has some regular contributors. If you're one of them, do 
>> you have a small amount extra to help with the maintenance?
>> 
>> If you're not a contributor but use it, would you be able to lend a hand? 
>> 
>> As ever, first step if hanging out on the repo and helping with any incoming.
>> 
>> https://github.com/django-guardian/django-guardian
>> 
>> 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/fdb10e33-ab6a-466b-b209-4cbed1bdc7df%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/94D0F687-0649-495B-B661-6300804F9898%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Fellow Reports -- January 2019

2019-02-04 Thread Carlton Gibson
Hi all. 


Calendar Week 5 -- ending 03 February.


Triaged:

https://code.djangoproject.com/ticket/30144 -- Support passing timedelta 
for cache timeout (wontfix)
https://code.djangoproject.com/ticket/30139 -- 
django.contrib.auth.forms.UserCreationForm() doesnt call default 
managers create_user() (Invalid)



Reviewed:

https://code.djangoproject.com/ticket/30004 -- Set default 
FILE_UPLOAD_PERMISSION to 0o644
https://github.com/django/django/pull/10908 -- Update to logging 
documentation.
https://code.djangoproject.com/ticket/29943 -- Document that admin 
changelist adds `pk` to ordering
https://github.com/django/django/pull/0913 -- Fixed E117 and F405 flake8 
warnings.
https://code.djangoproject.com/ticket/28905 -- Overhaul extra_requires to 
include more optional dependencies
https://code.djangoproject.com/ticket/29825 -- ngettext returns invalid 
result if msgstr is also a valid msgid in the same catalog
https://github.com/django/django/pull/10832 -- Remove naturaltime 
context for (delta) ago for Swedish.



Authored:

https://github.com/django/django/pull/10882 -- Fixed #30091 -- Documented 
middleware ordering requirements when using CSRF_USE_SESSIONS.


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/821dddea-60ba-44a2-9891-96a56c93720c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Google Summer of Code 2019

2019-02-04 Thread Carlton Gibson
And thank you Tim, yes, exactly what I need. 

To all: 

I will put in the org application today. We'll then see about the 
proposals. 

The main thing is that we need to know who you are, and have confidence in 
you in order to commit to the project with you. 
For people to mentor you is a big commitment of time and energy. You need 
to demonstrate that will be well invested. 

The way to do that is to get involved and show us who you are over the next 
few months. 
Help reproduce bugs, review patches, create patches etc. 
It doesn't take much before you're visible. (Really!) 

The best way (also) to come up with project ideas is to see where there are 
issues already. 
(Much better than us providing a list.) So again, be involved. 

If you start now, there's still lots of time, so I'm hoping. 

Kind Regards,

Carlton





On Monday, 4 February 2019 15:43:39 UTC+1, Tim Graham wrote:
>
> It's a private wiki that only Django team members like Carlton can access. 
> It contains the information for Django to apply for GSoC.
>
> On Monday, February 4, 2019 at 9:07:40 AM UTC-5, Giuseppe De Marco wrote:
>>
>> Hi Tim,
>>
>> It returns 404 to me
>>
>> https://github.com/django/django-team-wiki/wiki/Google-Summer-of-Code-Application-Info
>>
>> Il giorno lun 4 feb 2019 alle ore 13:05 Tim Graham  
>> ha scritto:
>>
>>> All answers are at 
>>> https://github.com/django/django-team-wiki/wiki/Google-Summer-of-Code-Application-Info
>>>
>>

-- 
You received this message because you are subscribed to the Google 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/5e410c5e-deb7-4dfe-9f61-0599a1bf80e2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: App static files (#29586)

2019-02-04 Thread Carlton Gibson
Hi Claude. 

Is this something you're still interested in? 

Do you think it might make a good GSoC project? 

C.

On Monday, 23 July 2018 17:36:05 UTC+2, Claude Paroz wrote:
>
> Hi, 
>
> I just created a new feature request [1] to be able to define static 
> files per application, including a POC patch [2]. 
>
> [1] https://code.djangoproject.com/ticket/29586 
> [2] https://github.com/django/django/pull/10218 
>
> Feel free to discuss it here for general discussion on the feature 
> utility, or comment on the ticket or on the pull request for 
> implementation details. 
>
> Cheers, 
>
> Claude 
> -- 
> www.2xlibre.net 
>

-- 
You received this message because you are subscribed to the Google 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/869f847f-295c-4b17-b442-abbcc43955f5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Google Summer of Code 2019

2019-02-04 Thread Carlton Gibson
Hey Tim. 

> For each year your organization has participated, provide the counts of 
successful and total students. (e.g. 2016: 3/4)

I have no idea about this, could you advise? 

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/e1bb1cc8-8628-435c-a5c6-8466ed4e8d4e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Google Summer of Code 2019

2019-02-04 Thread Carlton Gibson
Hey Parth, 

Yes, you're right: 

> Students can register and submit their applications to mentor 
organizations. All proposals must be submitted by April 9, 2019 20:00 
(CEST).

There's time. I was thinking tomorrow was the full proposal deadline. 
(That's my lack of familiarity with it.) 

I will fill do the the Organisation application today. The programme seems 
a good opportunity. 

Kind Regards,

Carlton



On Monday, 4 February 2019 09:40:32 UTC+1, PARTH PATIL wrote:
>
>
>
> Hey, I am really enthusiastic for doing GSoC with Django, I had been 
> working for a few months to get myself familiar with the code base. I have 
> quite a few unpolished ideas in my mind for projects like the one posted 
> here 
> <https://groups.google.com/d/msg/django-developers/puJ4r_hOCsk/yc6-eiFTFAAJ>
> .
>
> Though I'm unable to understand why Django is not ready to participate in 
> GSoC this year?
>
> Also, I would like to point out what *Carlton* said in his post 
> <https://groups.google.com/d/msg/django-developers/PcXfiDNwPxg/WHG8boh3FAAJ>
> .
>
>- I don't think it is justified to expect mind-blowing project 
>proposal this early. As per the GSoC's timeline, the application deadline 
>is April 9 which is like two months for now.
>- Even the discussions of ideas according to Google begins from 20 
>days from now.
>- There is also no ideas page for Django for 2019, to which students 
>can refer.
>- More importantly, as a student, I think many students will be 
>genuinely interested to take up a few good projects with Django.
>
>
>
> On Monday, February 4, 2019 at 2:41:11 AM UTC+5:30, Carlton Gibson wrote:
>>
>> Yes. GSoC wasn't at all on my radar before your post here Tim. 
>>
>> We've had a few "hello" posts but no even semi-concrete proposals from 
>> students. (Equally we don't have a list ready to go.) 
>>
>> I had a look at the process. It seems a moderate commitment, so, for me, 
>> I think I'd want to be familiar with applicants before we took that on. 
>> i.e. We need say to students to get involved months before. 
>> I'll think about messaging for that for next year because GSoC seems good 
>> overall. 
>>
>> SO unless someone is going to blow us away with an outline of a proposal 
>> TOMORROW, we'll have to pass this year. (Deadline being Tuesday.)
>>
>> On Friday, 1 February 2019 22:32:43 UTC+1, Tim Graham wrote:
>>>
>>> As of now, I haven't seen any existing Django contributors who are 
>>> planning to propose a project, therefore I don't think it's worthwhile for 
>>> the DSF to apply for this summer. The decision to apply on behalf of the 
>>> DSF is up to Carlton, Mariusz, or another potential mentor.
>>>
>>> On Thursday, January 31, 2019 at 6:24:36 AM UTC-5, gaurav jain wrote:
>>>>
>>>> One Idea i have a one command django project maker to instead having 
>>>> 1+n commands(n number of apps) and linking them in setting we can have 
>>>> command take the number of apps and app_names in ine do and then later we 
>>>> can add functionality for heroku ,docker etc
>>>>
>>>> On Wednesday, January 16, 2019 at 8:03:55 PM UTC+5:30, Tim Graham wrote:
>>>>>
>>>>> Org applications for Google's Summer of Code are now open (deadline 
>>>>> February 6). Do you think the Django Software Foundation should 
>>>>> participate?
>>>>>
>>>>> We haven't had any high quality student applications that we could 
>>>>> accept for the past two years.
>>>>>
>>>>> Perhaps it's partly a function of a poor ideas page (
>>>>> https://code.djangoproject.com/wiki/SummerOfCode2018). Perhaps we 
>>>>> don't do a great job of publicizing our involvement and attracting high 
>>>>> quality students. Perhaps it's because the student payment isn't all that 
>>>>> much (+/-$6000 USD, depending on student's country)* for the amount of 
>>>>> work 
>>>>> involved (also, students have to put in a lot of work up front in their 
>>>>> application, with no guarantee of being accepted into the program).
>>>>>
>>>>> If you have any ideas about mentoring or suggesting a project, or if 
>>>>> you're serious about being a student (you should start contributing to 
>>>>> Django now if you don't already), please share.
>>>>>
>>>>> * https://developers.google.com/open-source/gsoc/help/student-stipends
>>>>>
>>>>

-- 
You received this message because you are subscribed to the Google 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/f8a1ff9d-c5d6-48b6-b181-20ee4b68bb5f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Google Summer of Code 2019

2019-02-03 Thread Carlton Gibson
Yes. GSoC wasn't at all on my radar before your post here Tim. 

We've had a few "hello" posts but no even semi-concrete proposals from 
students. (Equally we don't have a list ready to go.) 

I had a look at the process. It seems a moderate commitment, so, for me, I 
think I'd want to be familiar with applicants before we took that on. i.e. 
We need say to students to get involved months before. 
I'll think about messaging for that for next year because GSoC seems good 
overall. 

SO unless someone is going to blow us away with an outline of a proposal 
TOMORROW, we'll have to pass this year. (Deadline being Tuesday.)

On Friday, 1 February 2019 22:32:43 UTC+1, Tim Graham wrote:
>
> As of now, I haven't seen any existing Django contributors who are 
> planning to propose a project, therefore I don't think it's worthwhile for 
> the DSF to apply for this summer. The decision to apply on behalf of the 
> DSF is up to Carlton, Mariusz, or another potential mentor.
>
> On Thursday, January 31, 2019 at 6:24:36 AM UTC-5, gaurav jain wrote:
>>
>> One Idea i have a one command django project maker to instead having 1+n 
>> commands(n number of apps) and linking them in setting we can have command 
>> take the number of apps and app_names in ine do and then later we can add 
>> functionality for heroku ,docker etc
>>
>> On Wednesday, January 16, 2019 at 8:03:55 PM UTC+5:30, Tim Graham wrote:
>>>
>>> Org applications for Google's Summer of Code are now open (deadline 
>>> February 6). Do you think the Django Software Foundation should participate?
>>>
>>> We haven't had any high quality student applications that we could 
>>> accept for the past two years.
>>>
>>> Perhaps it's partly a function of a poor ideas page (
>>> https://code.djangoproject.com/wiki/SummerOfCode2018). Perhaps we don't 
>>> do a great job of publicizing our involvement and attracting high quality 
>>> students. Perhaps it's because the student payment isn't all that much 
>>> (+/-$6000 USD, depending on student's country)* for the amount of work 
>>> involved (also, students have to put in a lot of work up front in their 
>>> application, with no guarantee of being accepted into the program).
>>>
>>> If you have any ideas about mentoring or suggesting a project, or if 
>>> you're serious about being a student (you should start contributing to 
>>> Django now if you don't already), please share.
>>>
>>> * https://developers.google.com/open-source/gsoc/help/student-stipends
>>>
>>

-- 
You received this message because you are subscribed to the Google 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/62853b9c-6201-4d13-b788-b807b5348d2f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Help needed on Django-Guardian.

2019-02-03 Thread Carlton Gibson
Hi all. 

Adam Dobrawy who runs Django-Guardian, could do with some help maintaining 
there. 

The project seems to be in good shape. (It's up to date) But needs a bit of 
help keeping on top of the issues, dropping old-versions, and the rest of 
it. 

I see the project has some regular contributors. If you're one of them, do 
you have a small amount extra to help with the maintenance?

If you're not a contributor but use it, would you be able to lend a hand? 

As ever, first step if hanging out on the repo and helping with any 
incoming.

https://github.com/django-guardian/django-guardian

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/a33b0fcd-61eb-410f-b30b-37a6234e82db%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Potential suspension of Channels development

2019-02-01 Thread Carlton Gibson
Hey Andrew. 

Thanks to Jamesie and Asif for volunteering to help. 

Some general point, I'll make publicly, because they're general purpose: 

   - Due to Andrew's great work, the repos are in a good condition. Very 
   few open issues. The main task is to keep it that way: triaging the new 
   tickets, closing those we can. 
   - Let's use the labelling system Andrew already has in place. (No issues 
   if we don't do that perfectly, but lets try.) 
   - I don't think we can keep offering support in the repo. We need to 
   guide people to support channels. (A little hint is OK if you've got one 
   immediately.)
   - I'll set up protected branch rules, so all changes via PR (with 
   approvals) so we make sure we're on the same page, and can continue 
   Andrew's high standards. 
   - Let's not ping Andrew until we've explored all other possibilities. 
   Burnout/overwhelm is rubbish and self-care is the #1 priority. 

Thanks for all your work here Andrew. Have a breather. We'll try and keep 
it going. 
(I'm sure there's other people here who can help us when we get stuck...) 

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/a1607288-f814-481d-9b8a-327b402a009a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Google Summer of Code 2019

2019-01-29 Thread Carlton Gibson
Hi Shrikrishna, 

Not so much a ticket… See the thread I linked. There’s a lot of info there. 

The first step (I think) is a proof-of-concept JSONField for SQLite — we have 
the other three DBs. 

So taking a look at the implementation of the existing fields and SQLite’s API 
for the JSON extension, should lead you to be able to put together the first 
draft of some thoughts as to how we’d go forward. 

Have a rummage in `contrib.postgres` (and the Oracle and MySQL examples). How 
do the equivalent lookups look in SQLite? (HasKey, ContainedBy, and so on.) Any 
blockers? 

A rough breakdown here would be a good starting point. 

>From there, there are lots of people here who know a lot about this stuff 
>(more that me). 

I’m wondering about Florian’s point about scope. I don’t know much about GSoC, 
so I don’t know what they’d require. 
(The other wish-list item for me is a cross-DB ArrayField, but I haven’t even 
begun to look what the support is like there, if any at 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/ADB006C1-4936-4949-83EC-4138176A27D0%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Fellow Reports -- January 2019

2019-01-27 Thread Carlton Gibson
Hi All, 

Calendar Week 4 -- ending 27 January.


Triaged:

https://code.djangoproject.com/ticket/30101 -- Recommended middleware 
syntax fails for some testing cases (when not using Client) (Invalid)
https://code.djangoproject.com/ticket/30079 -- Prefetch cache should be 
aware of database source and .using() should not always trigger a new query 
(wontfix)
https://code.djangoproject.com/ticket/30091 -- Incorrect middleware 
ordering allows invalid HTTP_HOST header to cause CsrfViewMiddleware 
failure when using CSRF_USE_SESSIONS. (Accepted)



Reviewed:

https://code.djangoproject.com/ticket/28905 -- Overhaul extra_requires to 
include more optional dependencies
https://code.djangoproject.com/ticket/29973 -- compilemessages misses 
ignore option, compiles more than needed
https://code.djangoproject.com/ticket/30111 -- AppRegistryNotReady-Error 
when having contrib.postgres in INSTALLED_APPS
https://github.com/django/django/pull/10871 -- Fixed #30115, Refs #23748 -- 
Removed legacy max_length handling for CharField on SQLite.



Authored:

https://github.com/django/django/pull/10882 -- Fixed #30091 -- Documented 
middleware ordering requirements when using CSRF_USE_SESSIONS.


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/6c3879e4-e3a7-4d60-9633-e8be54c82f1d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: revisiting the Python version support policy

2019-01-27 Thread Carlton Gibson
OK, one last email, then I'm going to bow out of this one... 

I think there are two issues here: 

* Which versions of Python should we support? 
* Which version should we guide beginners to? 

The second of these only depends on the first because we don't support all 
current versions of Python in the current stable release, but only in the 
LTS. 

There was a talk at DjangoCon US. I think on f-strings but I can't quite 
remember, and I couldn't find the video quickly. The point is that it began 
by asking "Who's on v3.6 or higher?"
It was about a quarter or a maybe a third of the room. That's it. The rest 
were on Python 3.5 (or lower). And I put it to you that we should consider 
the audience of "people going to DjangoCon" as likely ahead of the user 
base in general. (That's a priori but credible I think.) 

So by dropping Python 3.5 we're forcing these folks onto the LTS. 

I think that's sad. 

Django is a mature framework. That often gets talked about as if that makes 
it boring. But IMO it's quite the contrary. It makes it exciting. It means 
that for the vast majority of cases there is no need to be on the LTS. You 
can safely use the latest version, knowing that breaking changes will be 
few and easily manageable. You can have the bug fixes. You can have the new 
features. And the cost of that is just a day every nine-months updating. 
Grab a coffee, read the release notes and spend the rest of the day 
updating. Likely you're done by lunchtime. (If you're sensibly with your 
choices of third-party packages this is...) 

People upgrade their third-parties first, Django second, and Python last of 
all. (I'm always amazed by this on DRF. "I'm using EOL Django but NEED the 
latest DRF". This happens every time we drop a Django version.) 

If people are on Python 3.5 they'll stick on the LTS if that's the only 
version that's compatible. 

So we basically create a ghetto. When we could instead have a situation 
where being on the latest version was just the done thing. 

I don't think we should highlight the LTS version. I don't think we should 
point the docs to it by default. I don't think we should recommend that 
that's where users begin. 

I think we should build an environment where everyone™ is using the latest 
version, and is all the happier for it. 

So, again, for another (related) reason, I think we do wrong by not 
following Python's supported versions. 
(People are going to need to speak up if they agree with this though, 
because otherwise it won't change.) (Which is fine too: mine is just one 
voice.) 


So to the second topic: more or less asyncio. 

The big changes here were 3.4 to 3.5. Channels already works fine on Python 
3.5. Python 3.6 introduces async generators, which sure are nice to have, 
but are not a deal breaker. 
Supporting Python 3.5 through to end of Django 3.0 is not going to make the 
difference to whether we can add an async view layer (or whether we being) 
to Django before December 2019 (when we'd drop Python 3.5). 

If there were a serious blocker, I'd be happy to see us being pragmatic 
about it. "Supporting Python version X means we can't implement important 
advance Y, so we're dropping that ahead of schedule." Cool. But that's 
really not the case here. Continuing Python 3.5 support costs us very 
little against the benefits to Django as a whole. 

Anyway, I'm spoke out here. 


Have a good day 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/84bcd7b9-b2c5-4ab9-bbcb-7fb42c2308d4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: revisiting the Python version support policy

2019-01-26 Thread Carlton Gibson
I worry about us making this kind of decision in the rarified air of the 
developer mailing list. It's a technical question yes, but it affects the 
entire community. 

I think, here, we underplay just how hard it is for people out there. IMO 
expecting that people suffering from massive information overload to 
successfully switch docs version is already setting the bar too high. 
People really struggle. 

I'll give you one concrete example. 

Teaching DjangoGirls in Barcelona, one student—presumably for EXACTLY the 
kind of version mis-match we're talking about here—had her project created 
with a different version of the template than everybody else's. It didn't 
have contrib.staticfiles in INSTALLED_APPS. As such, where everyone else 
was able to deploy, her deployment failed. In the end there were 
instructors from three tables around here laptop trying who-knows-what in 
the shell before it was worked out and resolved. ("Try `collectstatic` 
locally" led to the answer.) 

Without those instructors present that student would have been stuck at 
that point, and lost. 

I don't have figures, and we never hear from most of these people, but I 
guess this sort of difficulty happens a lot. 
A quick scan of django-users suggests it's all the time. 

> ...there's a new test failure after a recent patch due to 
non-deterministic dict ordering in Python 3.5 which demonstrates the sort 
of minor annoyances that take time away from making useful improvements to 
Django.

It's not that I don't hear you hear. I do. 

It's just that I think of this as an accessibility issue, and accessibility 
is a feature too. 

For me, if the cost of including someone is that we have to use OrderedDict 
for a wee-bit longer, then so be it. 

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/2c23caa4-b83a-4e45-9811-a62af2b4c311%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


  1   2   3   >