Re: Proposal: Refactor Form class

['Moritz Sichert' via Django developers (Contributions to Django itself)]

Hello,

Am 05.03.2016 um 02:57 schrieb Curtis Maloney:
> Well, Widgets and Fields are involved in determining how to extract data from
> the submitted dict... but they don't actually "parse" the http form data --
> Django does that much further down the stack in the HttpRequest object.
> 
> 
> As mentioned above, Forms don't handle this parsing.  You can pass _any_
> dict-like for them to validate.  In fact, I (and many others) have used this 
> for
> a simple and effective way to import csv files, in combination with stdlib's
> csv.DictReader.
> 
> I also frequently use Forms for validating JSON data...

You are right there, I guess "parsing" is the wrong word for what I mean.
The thing is that for "simple" Widgets like TextInput getting the value out of
the data dict is as simple as data.get(add_prefix(name)) so it is reasonably
easy to just pass in a normal dict as data instead of a request.POST because you
already know how the widget will fetch its data.
However it gets way more complicated with more complex Widgets. Say you have a
DateInput widget that uses three HTML input tags that let you enter the year,
month, and day respectively. If you were to replace request.POST with your own
dict now you would have to account for how this widget layouts its data, i.e.
you would have to do something like:

my_data_dict = {'prefix-thedate-year': 2016, 'prefix-thedate-month': 3,
'prefix-thedate-day': 5}

Even though the "thedate" is only one logical value you would have to "split" it
to get the form to "parse" it correctly. Also you have to know in advance how
your DateWidget works and have to change your code every time you use another
new (complex) widget.
I believe it should be possible to provide input data in whatever format without
needing to know how the widget expects the data.

Another thing I consider part of "parsing" is how "initial" data is handled.
Let's now pretend we know how to correctly replace request.POST with our own
dict regardless of the used widgets. Let's also disregard for now that the
inital dict's format is actually not like the data dict's because it already
contains *logical* values, i.e. stripped off prefix and only one value for each
logical field.
So now we can construct an "inital" dict just like we did for the data dict.
However the thing about the inital data is that Django already has an opinion on
what it is and how it should be handled.
I had a use case were I needed an additional layer of "initial" data that was
called something like "database initial". So I then had three types of data: the
actual "data" dict, "user initial" (similar to what Django considers to be
initial) and "database initial".
Because the concept of "initial" data is ingrained so deeply in the Form class I
had to customize a large part of the Form class internals and even BoundField.

That are the reasons why I believe "parsing", or better "sourcing" as you called
it, should be customizable.


> I feel the current validation pattern is very powerful and flexible, and don't
> see much need to alter it.

I feel the same way. For this reason I want to keep the way one specifies
validators exactly the same as it is now, i.e. by specifying Field instances
declaratively and being able to write clean() and clean_*() methods.


>> - DataProvider:
>>Implements the "parsing and providing data" component. It
>>has only one method "get_value(name)" that must be
>>overwritten by subclasses and returns the data for a given
>>field name.
> 
> So that would be a "get_field_value"?

Exactly.


> This scale of backwards incompatibility might scare off a lot of people from
> supporting this project.  So be sure to provide (a) an easy migration path,
> and/or (b) a clear backward compatibility layer.

Yes, I want to emphasize again that this is an important part of my proposal.


> I'd be happy to further develop these ideas [and code] with you if you like.

I actually already have a bit of code as a proof of concept, I think I'll open a
branch on my Django fork or even a PR.
However I moved around quite a lot of code so I suspect it will be a bit messy
to review.


Moritz

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


signature.asc
Description: OpenPGP digital signature

Re: Adding "bits of entropy" argument to crypto.get_random_string

['Moritz Sichert' via Django developers (Contributions to Django itself)]

Can't you just define your own function called "get_random_string_entropy" that
calculates the length and then calls get_random_string?
What would be the benefit of doing that in Django directly?

Am 05.03.2016 um 00:15 schrieb Nick Timkovich:
> Rather than guess at the appropriate string length to get some level of
> security, I'd like to add a (minimum) bits of entropy argument to
> get_random_string, so I could say something like get_random_string(bits=256) 
> and
> have it do the math for me: math.ceil(bits / math.log2(len(allowed_chars))).
> 
> Not sure what should happen if both bits and length are specified, let bits
> override? ValueError? whichever is longer/more random/secure (maybe then call 
> it
> min_bits)?
> 
> I seem to recycle that snippet in many of my projects, and I hope it would be
> useful for others. 

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


signature.asc
Description: OpenPGP digital signature

Re: Django Integration

[Daniel Chimeno]

Hello,

There are more information about the project in the doc page:
https://channels.readthedocs.org/en/latest/

El sábado, 5 de marzo de 2016, 1:16:31 (UTC+1), Chad Paulson escribió:
>
> I was happy to read that part of the Mozilla Open Source Support program 
> funding that was recently awarded to the Django Software Foundation will go 
> toward integrating key components of Django REST Framework into Django.
>
> Since I haven't found any update since the initial announcement in 
> December, I was curious what the status of this integration is and, if 
> possible, how soon it might be available.
>
> https://www.djangoproject.com/weblog/2015/dec/11/django-awarded-moss-grant/
>

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

Re: Making max_length argument optional

[Shai Berger]

On Saturday 05 March 2016 02:24:17 Loïc Bistuer wrote:
> I’m not too keen on a contrib.pg field. CharField is the base class of many
> fields, a __init__ kwarg approach such as max_length=None allows us to
> reach those as well.
> 

That's a good point; Can we enable max_length=None in a mixin?

[ANNOUNCE] Django bugfix releases issued: 1.9.4 and 1.8.11

[Tim Graham]

Details are available on the Django project weblog:

https://www.djangoproject.com/weblog/2016/mar/05/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/caa14a0f-d3b4-4f29-b9e5-3ab07d4097ce%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

deprecating the "escape" half of django.utils.safestring (#24046)

[Tim Graham]

Aymeric raised this ticket [0] while working on multiple template engines: 


"Since any data that isn't explicitly marked as safe must be treated as 
unsafe, I don't understand why we have EscapeData and its subclasses nor 
the mark_for_escaping function. It seems to me that we could keep only the 
"safe" half of django.utils.safestring and deprecate the "escape" half. As 
a matter of fact the "escape" isn't used meaningfully anywhere in Django."


I implemented a proof of concept to show what things would look like after 
the deprecation completes: 

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


It removes usage of mark_for_escaping() and EscapeData in the template 
engine to give an idea of what the code might look like with them removed. 
It wasn't difficult to get the tests passing besides a couple modifications 
to tests in test_force_escape.py which don't seem like practical usage 
(chained usage of escape|force_escape). 


Here's a test case that demonstrates a small behavior change that would 
happen:


@setup({'chaining111': '{% autoescape off %}{{ a|escape|add:"

Re: TransactionManagementError is raised when autocommit …

[Jeremy Dunck]

I've had this scenario before - you have two interleaving units of work
(through composition of code from different sources or concerns).  You want
progress recorded for one unit of work, but perhaps not the other.  Without
django, you'd have two open connections.  In my experience the simplest way
to accommodate this is to have two DB aliases pointed at the same DB.  Set
one to be a test mirror of the other.  Use different aliased connections
for the two concerns.  Then you can use atomic (as suggested and typical).

On Fri, Mar 4, 2016 at 2:11 PM, Tore Lundqvist  wrote:

> I don't what all updates to be in one commit each so I can't wrap just the
> update with a atomic block I would need to have it over a bigger chuck of
> code. That chunk might call a subrutin that also needs a commit and if I
> wrap that update in a atomic block that atomic block is nested and results
> in a save point which is useless.
>
> Den fredag 4 mars 2016 kl. 22:46:30 UTC+1 skrev Aymeric Augustin:
>>
>> If you do what Simon and I suggest, you should get the result you just
>> described. If you don’t, please explain what happens.
>>
>> Within a transaction — and disabling autocommit means you’re within a
>> transaction — transaction.atomic() uses savepoints.
>>
>> Note that in Django 1.6, after set_autocommit(False), you couldn’t use
>> transaction.atomic(). That was fixed in 1.8 (I think).
>>
>> --
>> Aymeric.
>>
>> On 04 Mar 2016, at 21:21, Tore Lundqvist  wrote:
>>
>> Hi, Simon
>>
>> No, I would need to wrap everything i a atomic block to start the
>> transaction and it's only when that outermost atomic block exits that I
>> actually get a commit the nested ones just makes save point.
>>
>> /Tore
>>
>> Den fredag 4 mars 2016 kl. 21:09:17 UTC+1 skrev charettes:
>>>
>>> Hi Tore,
>>>
>>> Is there a reason you can't simply wrap your updates in a
>>> `transaction.atomic()` blocks?
>>>
>>> You should be able to avoid deadlocks and control exactly when data is
>>> written to disk
>>> with this construct.
>>>
>>> Simon
>>>
>>> Le vendredi 4 mars 2016 15:02:45 UTC-5, Tore Lundqvist a écrit :

 Reply to comments in ticket:
 https://code.djangoproject.com/ticket/26323#comment:10

 Hi,

 @Aagustin: I get your point but in the code I'm working on there is a
 lot of transaction.commit(), not to handle transactions but to manage when
 data is written to disk and to avoid deadlocks. Running in autocommit mode
 does not work, its slow and sometimes the commits is used to save in a
 known good state. So I disable autocommit with
 transaction.set_autocommit(False) and run the code with explicit commits in
 it and than turn autocommit on again.

 The documentation for set_autocommit says "Once you turn autocommit
 off, you get the default behavior of your database adapter, and Django
 won’t help you." That is what I want and thats way I think that
 the TransactionManagementError should not de raise if your not using atomic
 blocks.

>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-d...@googlegroups.com.
>> Visit this group at https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/a6077f33-1113-4767-828c-8b2c0c77bd78%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/79611d30-21e0-45bc-8ab7-8754a39db4fc%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 h

Re: TransactionManagementError is raised when autocommit …

[Tore Lundqvist]

Thanks for the suggestion! 
I have been thinking of workarounds with multiple db aliases and it would 
solve the problem I described but in reality the code I'm working with is 
much more complex and has around 400 explicit commits. It all worked great 
in Django 1.4 but since we upgraded to 1.8 (and got the new transaction 
management) I have been forced to make ugly workarounds and patch Django 
this time. 

Den lördag 5 mars 2016 kl. 19:41:59 UTC+1 skrev jdunck:
>
> I've had this scenario before - you have two interleaving units of work 
> (through composition of code from different sources or concerns).  You want 
> progress recorded for one unit of work, but perhaps not the other.  Without 
> django, you'd have two open connections.  In my experience the simplest way 
> to accommodate this is to have two DB aliases pointed at the same DB.  Set 
> one to be a test mirror of the other.  Use different aliased connections 
> for the two concerns.  Then you can use atomic (as suggested and typical).
>
> On Fri, Mar 4, 2016 at 2:11 PM, Tore Lundqvist  > wrote:
>
>> I don't what all updates to be in one commit each so I can't wrap just 
>> the update with a atomic block I would need to have it over a bigger chuck 
>> of code. That chunk might call a subrutin that also needs a commit and if I 
>> wrap that update in a atomic block that atomic block is nested and results 
>> in a save point which is useless.
>>
>> Den fredag 4 mars 2016 kl. 22:46:30 UTC+1 skrev Aymeric Augustin:
>>>
>>> If you do what Simon and I suggest, you should get the result you just 
>>> described. If you don’t, please explain what happens.
>>>
>>> Within a transaction — and disabling autocommit means you’re within a 
>>> transaction — transaction.atomic() uses savepoints.
>>>
>>> Note that in Django 1.6, after set_autocommit(False), you couldn’t use 
>>> transaction.atomic(). That was fixed in 1.8 (I think).
>>>
>>> -- 
>>> Aymeric.
>>>
>>> On 04 Mar 2016, at 21:21, Tore Lundqvist  wrote:
>>>
>>> Hi, Simon
>>>
>>> No, I would need to wrap everything i a atomic block to start the 
>>> transaction and it's only when that outermost atomic block exits that I 
>>> actually get a commit the nested ones just makes save point.
>>>
>>> /Tore 
>>>
>>> Den fredag 4 mars 2016 kl. 21:09:17 UTC+1 skrev charettes:

 Hi Tore,

 Is there a reason you can't simply wrap your updates in a 
 `transaction.atomic()` blocks?

 You should be able to avoid deadlocks and control exactly when data is 
 written to disk
 with this construct.

 Simon

 Le vendredi 4 mars 2016 15:02:45 UTC-5, Tore Lundqvist a écrit :
>
> Reply to comments in ticket: 
> https://code.djangoproject.com/ticket/26323#comment:10
>
> Hi, 
>
> @Aagustin: I get your point but in the code I'm working on there is a 
> lot of transaction.commit(), not to handle transactions but to manage 
> when 
> data is written to disk and to avoid deadlocks. Running in autocommit 
> mode 
> does not work, its slow and sometimes the commits is used to save in a 
> known good state. So I disable autocommit with 
> transaction.set_autocommit(False) and run the code with explicit commits 
> in 
> it and than turn autocommit on again. 
>
> The documentation for set_autocommit says "Once you turn autocommit 
> off, you get the default behavior of your database adapter, and Django 
> won’t help you." That is what I want and thats way I think that 
> the TransactionManagementError should not de raise if your not using 
> atomic 
> blocks. 
>

>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Django developers (Contributions to Django itself)" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to django-developers+unsubscr...@googlegroups.com.
>>> To post to this group, send email to django-d...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/django-developers/a6077f33-1113-4767-828c-8b2c0c77bd78%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-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@googlegroups.com 
>> .
>> Visit this group at https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-develope

Re: Django Integration

[Andrew Godwin]

Hi Chad,

The REST framework request feature integration, in particular, has not
started yet; Mozilla has been having some issues working out how to pay
their various grantees, and from my understanding we still haven't received
the grant money yet.

Channels is well underway, but that's only because I'm able to do the work
now and wait to get paid for it later; I don't expect the same of other
contributors.

Andrew

On Fri, Mar 4, 2016 at 3:58 PM, Chad Paulson  wrote:

> I was happy to read that part of the Mozilla Open Source Support program
> funding that was recently awarded to the Django Software Foundation will go
> toward integrating key components of Django REST Framework into Django.
>
> Since I haven't found any update since the initial announcement in
> December, I was curious what the status of this integration is and, if
> possible, how soon it might be available.
>
> https://www.djangoproject.com/weblog/2015/dec/11/django-awarded-moss-grant/
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/2bdf074c-5e21-48cf-a93c-ba19f7744a89%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/CAFwN1uq-BnAX8HyEQDRRnm1wg83%2BEJ4kMVgc_fVTsTu6EU8L5g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: TransactionManagementError is raised when autocommit …

[Tore Lundqvist]

Regardless of the particular problem I have got shouldn't it be possible to 
disable Djangos transactional management if you want to?

Is not transaction.set_autocommit(False) doing that?

Is it not surprising to get a TransactionManagementError when you have 
turned of the transaction management?

There is also another broken thing with set_autocommit(False) if the 
database connection has timed out and is reconnected by Django, autocommit 
is set to True again, that was kind of surprising and ugly to workaround.



Den fredag 4 mars 2016 kl. 21:02:45 UTC+1 skrev Tore Lundqvist:
>
> Reply to comments in ticket: 
> https://code.djangoproject.com/ticket/26323#comment:10
>
> Hi, 
>
> @Aagustin: I get your point but in the code I'm working on there is a lot 
> of transaction.commit(), not to handle transactions but to manage when data 
> is written to disk and to avoid deadlocks. Running in autocommit mode does 
> not work, its slow and sometimes the commits is used to save in a known 
> good state. So I disable autocommit with transaction.set_autocommit(False) 
> and run the code with explicit commits in it and than turn autocommit on 
> again. 
>
> The documentation for set_autocommit says "Once you turn autocommit off, 
> you get the default behavior of your database adapter, and Django won’t 
> help you." That is what I want and thats way I think that 
> the TransactionManagementError should not de raise if your not using atomic 
> blocks. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/52428d2f-7ebe-48eb-8c28-98b1c5c7ae69%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Intro + A few questions about Formset Improvements

[Amith Tallanki]

A little late to the party but I hope to make for lost time.

Hi,

I'm Amith, currently a fourth year student at Dayananda Sagar College Of 
Engineering. I was hoping to work with Django as my GSoC project if my 
proposal is accepted. I'll keep the intro short, here are my credentials : 
Linkedin : LinkedIn 
Resume : Resume 


I have started working on a few byte sized bugs to go along with my 
proposal after going through the required documentation. However, I do have 
the following questions : 
1. How many bugs does your average applicant solve for his/her proposal to 
considered amazing?
2. Does every project in the GSoC Ideas list page get a slot?
3. What level of documentation will you be requiring for Formset 
Improvements project? (Is a mere mixture of well commented code and pseudo 
logic okay or do you require detailed workflow diagrams?)
4. What kind of model will the mentor be expecting us to follow/implement? 
(like Scrum, Kanban any others)?
5. I'm a little embarrassed to say I haven't worked with formsets in Django 
but am taking the steps to rectify that asap, however, the project 
description has confused me a little. Does it require the formation of new 
structures that make the implementation of formset architecture simple or 
does it require new documentation to explain the current work around?

Sorry for the long winded questions. :P 

Cheers,

Amith

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

Re: Intro + A few questions about Formset Improvements

[Tim Graham]

 Hi, I'll 
answer your questions inline:

1. How many bugs does your average applicant solve for his/her proposal to 
> considered amazing?
>

The number of bugs isn't relevant as the amount of work per bug or feature 
varies greatly. The important thing is that the proposal has a reasonable 
timetable with 12 weeks worth of work.
 

> 2. Does every project in the GSoC Ideas list page get a slot?
>

In the past couple years we've been able to accept all the good proposals 
we've received.
 

> 3. What level of documentation will you be requiring for Formset 
> Improvements project? (Is a mere mixture of well commented code and pseudo 
> logic okay or do you require detailed workflow diagrams?)
>

The amount of documentation should be on par with any major feature in 
Django. Take a look through past commits and our contributing guidelines to 
get a sense for it.
 

> 4. What kind of model will the mentor be expecting us to follow/implement? 
> (like Scrum, Kanban any others)?
>

I haven't used any formal system when I mentored in the past. At least a 
weekly checkin with your mentor through email, video chat, or IRC 
discussion is common.
 

> 5. I'm a little embarrassed to say I haven't worked with formsets in 
> Django but am taking the steps to rectify that asap, however, the project 
> description has confused me a little. Does it require the formation of new 
> structures that make the implementation of formset architecture simple or 
> does it require new documentation to explain the current work around?
>

I'm not sure what the solution will look like but presumably there's some 
code to write as a project consisting solely of documentation doesn't 
qualify for Google Summer of Code under Google's guidelines.

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

Re: Django Integration

[Tim Graham]

Hi Andrew,

What's your thinking about whether or not any of this will make it into 
1.10? The alpha is scheduled for May 16.

On Saturday, March 5, 2016 at 2:40:05 PM UTC-5, Andrew Godwin wrote:
>
> Hi Chad,
>
> The REST framework request feature integration, in particular, has not 
> started yet; Mozilla has been having some issues working out how to pay 
> their various grantees, and from my understanding we still haven't received 
> the grant money yet.
>
> Channels is well underway, but that's only because I'm able to do the work 
> now and wait to get paid for it later; I don't expect the same of other 
> contributors.
>
> Andrew
>
> On Fri, Mar 4, 2016 at 3:58 PM, Chad Paulson  > wrote:
>
>> I was happy to read that part of the Mozilla Open Source Support program 
>> funding that was recently awarded to the Django Software Foundation will go 
>> toward integrating key components of Django REST Framework into Django.
>>
>> Since I haven't found any update since the initial announcement in 
>> December, I was curious what the status of this integration is and, if 
>> possible, how soon it might be available.
>>
>>
>> https://www.djangoproject.com/weblog/2015/dec/11/django-awarded-moss-grant/
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@googlegroups.com 
>> .
>> Visit this group at https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/2bdf074c-5e21-48cf-a93c-ba19f7744a89%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/dbc29625-3af4-4b73-9b60-78d269352d52%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Integration

[Andrew Godwin]

My intention is still to get it in - the external library is pretty much at
the stable point now, and I'm preparing to brand it 1.0. Once I do that,
I'll start work on the Django patch.

It's made a bit easier by the fact that the code is four repositories,
three of which (asgiref, daphne, and asgi_redis) can continue to be
separate modules. Only the code in the "channels" repository needs to go
into Django itself, and while it's the biggest repo, most of it should slot
right in; there's not really much in core itself that needs changing, more
about addition and tweaking some imports.

Andrew

On Sat, Mar 5, 2016 at 4:44 PM, Tim Graham  wrote:

> Hi Andrew,
>
> What's your thinking about whether or not any of this will make it into
> 1.10? The alpha is scheduled for May 16.
>
> On Saturday, March 5, 2016 at 2:40:05 PM UTC-5, Andrew Godwin wrote:
>>
>> Hi Chad,
>>
>> The REST framework request feature integration, in particular, has not
>> started yet; Mozilla has been having some issues working out how to pay
>> their various grantees, and from my understanding we still haven't received
>> the grant money yet.
>>
>> Channels is well underway, but that's only because I'm able to do the
>> work now and wait to get paid for it later; I don't expect the same of
>> other contributors.
>>
>> Andrew
>>
>> On Fri, Mar 4, 2016 at 3:58 PM, Chad Paulson 
>> wrote:
>>
>>> I was happy to read that part of the Mozilla Open Source Support program
>>> funding that was recently awarded to the Django Software Foundation will go
>>> toward integrating key components of Django REST Framework into Django.
>>>
>>> Since I haven't found any update since the initial announcement in
>>> December, I was curious what the status of this integration is and, if
>>> possible, how soon it might be available.
>>>
>>>
>>> https://www.djangoproject.com/weblog/2015/dec/11/django-awarded-moss-grant/
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Django developers (Contributions to Django itself)" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to django-develop...@googlegroups.com.
>>> To post to this group, send email to django-d...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-developers/2bdf074c-5e21-48cf-a93c-ba19f7744a89%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/dbc29625-3af4-4b73-9b60-78d269352d52%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/CAFwN1urzt3VjQG-LZWz0sevcLGG5S%3DpM4CEMjkf__BytC0%2BsVg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Fellow Report - March 5, 2016

[Tim Graham]

Triaged

---

https://code.djangoproject.com/ticket/26282 - db.connection.is_usable 
throws when no connection exists yet (wontfix)

https://code.djangoproject.com/ticket/26283 - SplitArrayField failed to 
validate because remove_trailing_nulls doesn't work properly (accepted)

https://code.djangoproject.com/ticket/26295 - 
LocaleMiddleware.is_language_prefix_patterns_used should be cached per 
urlconf. (accepted)

https://code.djangoproject.com/ticket/26297 - collectstatic --clear throws 
NotImplementedError, "This backend doesn't support absolute paths." 
(accepted)

https://code.djangoproject.com/ticket/26287 - SimpleLazyObject doesn't 
implement __radd__ (accepted)

https://code.djangoproject.com/ticket/26305 - Can't filter ChangeList by 
postgres-specific lookups (duplicate)

https://code.djangoproject.com/ticket/26307 - More explicit HTTPS 
deployment documentation (wontfix)

https://code.djangoproject.com/ticket/26289 - Enable shell tab completion 
on systems using libedit (accepted)

https://code.djangoproject.com/ticket/26299 - Rollback bug on Postgres for 
multidb applications (invalid)

https://code.djangoproject.com/ticket/26306 - Memory leak in cached 
template loader (accepted)

https://code.djangoproject.com/ticket/26301 - Allow to set memcached client 
socket_timeout via settings (duplicate)

https://code.djangoproject.com/ticket/26312 - Tutorial Part 5 should warn 
about possible db errors when running your first test (fixed)

https://code.djangoproject.com/ticket/26310 - Document that a query's 
default ordering is unspecified (fixed)

https://code.djangoproject.com/ticket/26314 - Filesystem Storage Class 
ignores settings changes (duplicate)

https://code.djangoproject.com/ticket/26321 - Missing "for_save" in 
examples of custom expression (fixed)

https://code.djangoproject.com/ticket/26320 - Deprecate implicit 
OneToOneField parent_link (accepted)

https://code.djangoproject.com/ticket/26317 - 
django.utils.duration.duration_string() doesn't support negative durations 
(invalid)

Reviewed/committed

--

https://github.com/django/django/commit/67b46ba7016da2d259c1ecc7d666d11f5e1cfaab
 
- Fixed CVE-2016-2513 -- Fixed user enumeration timing attack during login.

https://github.com/django/django/commit/c5544d289233f501917e25970c03ed444abbd4f0
 
- Fixed CVE-2016-2512 -- Prevented spoofing is_safe_url() with basic auth. 

https://github.com/django/django/pull/6223 - Fixed #26229 -- Improved check 
for model admin check admin.E124

https://github.com/django/django/pull/6171 - Fixed #26217 -- Added a 
warning about format strings to WeekArchiveView docs.

https://github.com/django/django/pull/6231 - Fixed #26304 -- Ignored 
unmanaged through model in table introspection.

https://github.com/django/django/pull/5936 - Refs #19527 -- Allowed 
QuerySet.bulk_create() to set the primary key of its objects.

https://github.com/django/django/pull/6234 - Fixed #26309 -- Documented 
that login URL settings no longer support dotted paths.

https://github.com/django/django/pull/6217 - Fixed #26315 -- Allowed 
call_command() to accept a Command object as the first argument and cleaned 
up usage of argparse options in commands and tests.

https://github.com/django/djangoproject.com/pull/642 - Refs #621 -- Added 
hreflang annotations to docs pages.

Reviews of core dev work



https://github.com/django/django/pull/6159 - Fixed #26226 -- Made related 
managers honor the queryset used for prefetching their results.

https://github.com/django/django/pull/6224 - Fixed #26295 -- Allowed using 
i18n_patterns() in any root URLconf. 
https://github.com/django/django/pull/6242 - Fixed #26308 -- Prevented 
crash with binary URLs in is_safe_url()

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