#25582: Add a way to build URLs with query strings

[guettli]

>From  https://code.djangoproject.com/ticket/25582

 {{{

It is a common question on stackoverflow and other places:

How to reverse() to url including GET parameters? Example: 
.../myview?foo=bar

​
http://stackoverflow.com/questions/9585491/how-do-i-pass-get-parameters-using-django-urlresolvers-reverse

​http://stackoverflow.com/a/27641445/633961

It would be very nice if django could implement a short-cut which provides
this.
It would be useful for python code and template, too.
}}}

{{{
If we do add it, it likely needs a discussion on the DevelopersMailingList 
 to figure out 
what the API should look like. See also #10941 
 which asks for a template tag 
for creating query strings in templates.
}}}

What do you think?



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

Why passing request, *args, **kwargs in dispatch method for generic views

[Dheerendra Rathor]

Hello all,

With reference to this 
line: 
https://github.com/django/django/blob/master/django/views/generic/base.py#L61 
from django.view.generic.base
before calling self.dispatch request, args and kwargs attributes have been 
added to self. So these all are available in self in http_method handlers. 

I think this behaviour is present due to old functional views, but now 
passing these as arguments to http_method handlers look obsolete.

We can potentially remove these and make http handlers more simple just like
class CustomView(View):
def get(self):
request =self.request
# code ...



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

Re: #25582: Add a way to build URLs with query strings

[Tim Graham]

Can you make an API proposal?

On Friday, October 23, 2015 at 3:41:42 AM UTC-4, guettli wrote:
>
> From  https://code.djangoproject.com/ticket/25582
>
>  {{{
>
> It is a common question on stackoverflow and other places:
>
> How to reverse() to url including GET parameters? Example: 
> .../myview?foo=bar
>
> ​
> http://stackoverflow.com/questions/9585491/how-do-i-pass-get-parameters-using-django-urlresolvers-reverse
>
> ​http://stackoverflow.com/a/27641445/633961
>
> It would be very nice if django could implement a short-cut which provides
> this.
> It would be useful for python code and template, too.
> }}}
>
> {{{
> If we do add it, it likely needs a discussion on the DevelopersMailingList 
>  to figure out 
> what the API should look like. See also #10941 
>  which asks for a template 
> tag for creating query strings in templates.
> }}}
>
> What do you think?
>
>
>
>

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

Re: #25582: Add a way to build URLs with query strings

[guettli]

API proposal:

Add a new kwarg to reverse():

   reverse(..., get=None)


Example: reverse('my_view_name', kwargs={'pk': '1'}, get=dict(param='value')

result: /my-view/1?param=value




Am Freitag, 23. Oktober 2015 13:43:18 UTC+2 schrieb Tim Graham:
>
> Can you make an API proposal?
>
> On Friday, October 23, 2015 at 3:41:42 AM UTC-4, guettli wrote:
>>
>> From  https://code.djangoproject.com/ticket/25582
>>
>>  {{{
>>
>> It is a common question on stackoverflow and other places:
>>
>> How to reverse() to url including GET parameters? Example: 
>> .../myview?foo=bar
>>
>> ​
>> http://stackoverflow.com/questions/9585491/how-do-i-pass-get-parameters-using-django-urlresolvers-reverse
>>
>> ​http://stackoverflow.com/a/27641445/633961
>>
>> It would be very nice if django could implement a short-cut which provides
>> this.
>> It would be useful for python code and template, too.
>> }}}
>>
>> {{{
>> If we do add it, it likely needs a discussion on the 
>> DevelopersMailingList 
>>  to figure 
>> out what the API should look like. See also #10941 
>>  which asks for a template 
>> tag for creating query strings in templates.
>> }}}
>>
>> What do you think?
>>
>>
>>
>>

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

Re: #25582: Add a way to build URLs with query strings

[Dheerendra Rathor]

How about a wrapper over reverse? 
Modifying reverse will lead to multiple changes in core urlresolver. 

A class based urlresolver can be implemented which will call reverse 
internally. 


On Friday, 23 October 2015 17:29:25 UTC+5:30, guettli wrote:
>
> API proposal:
>
> Add a new kwarg to reverse():
>
>reverse(..., get=None)
>
>
> Example: reverse('my_view_name', kwargs={'pk': '1'}, get=dict(param='value')
>
> result: /my-view/1?param=value
>
>
>
>
> Am Freitag, 23. Oktober 2015 13:43:18 UTC+2 schrieb Tim Graham:
>>
>> Can you make an API proposal?
>>
>> On Friday, October 23, 2015 at 3:41:42 AM UTC-4, guettli wrote:
>>>
>>> From  https://code.djangoproject.com/ticket/25582
>>>
>>>  {{{
>>>
>>> It is a common question on stackoverflow and other places:
>>>
>>> How to reverse() to url including GET parameters? Example: 
>>> .../myview?foo=bar
>>>
>>> ​
>>> http://stackoverflow.com/questions/9585491/how-do-i-pass-get-parameters-using-django-urlresolvers-reverse
>>>
>>> ​http://stackoverflow.com/a/27641445/633961
>>>
>>> It would be very nice if django could implement a short-cut which 
>>> provides
>>> this.
>>> It would be useful for python code and template, too.
>>> }}}
>>>
>>> {{{
>>> If we do add it, it likely needs a discussion on the 
>>> DevelopersMailingList 
>>>  to figure 
>>> out what the API should look like. See also #10941 
>>>  which asks for a template 
>>> tag for creating query strings in templates.
>>> }}}
>>>
>>> What do you think?
>>>
>>>
>>>
>>>

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

Re: Why passing request, *args, **kwargs in dispatch method for generic views

[Tim Graham]

It looks like setting the request/args/kwargs attributes came after the 
original CBGV implementation. 

https://github.com/django/django/commit/ea6b95db
https://code.djangoproject.com/ticket/19316
https://groups.google.com/d/topic/django-developers/7c7aI-slGNc/discussion

I haven't looked closely to see if your proposal might cause problems (you 
could give it a try and see if you can get the Django test suite passing), 
however, changing the signature of those methods would require a 
deprecation path and could result in a lot of churn in user code which 
would probably cause some angst. I'll leave it to users of CGGVs to offer 
an opinion on whether or not it could be worthwhile.

On Friday, October 23, 2015 at 5:51:37 AM UTC-4, Dheerendra Rathor wrote:
>
> Hello all,
>
> With reference to this line: 
> https://github.com/django/django/blob/master/django/views/generic/base.py#L61 
> from django.view.generic.base
> before calling self.dispatch request, args and kwargs attributes have been 
> added to self. So these all are available in self in http_method handlers. 
>
> I think this behaviour is present due to old functional views, but now 
> passing these as arguments to http_method handlers look obsolete.
>
> We can potentially remove these and make http handlers more simple just 
> like
> class CustomView(View):
> def get(self):
> request =self.request
> # code ...
>
>
>
>

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

Re: Why passing request, *args, **kwargs in dispatch method for generic views

[Tom Christie]

Although those variables are available in both places I'd prefer to see 
them passed explicitly.
That will tend to nudge users slightly more towards passing variable around 
explicitly and slightly away from storing state on the view instance (which 
can be a bit of a gnarly practice - harder to follow the flow of where and 
when some piece of information is actually being used/modified)

On Friday, 23 October 2015 14:03:17 UTC+1, Tim Graham wrote:
>
> It looks like setting the request/args/kwargs attributes came after the 
> original CBGV implementation. 
>
> https://github.com/django/django/commit/ea6b95db
> https://code.djangoproject.com/ticket/19316
> https://groups.google.com/d/topic/django-developers/7c7aI-slGNc/discussion
>
> I haven't looked closely to see if your proposal might cause problems (you 
> could give it a try and see if you can get the Django test suite passing), 
> however, changing the signature of those methods would require a 
> deprecation path and could result in a lot of churn in user code which 
> would probably cause some angst. I'll leave it to users of CGGVs to offer 
> an opinion on whether or not it could be worthwhile.
>
> On Friday, October 23, 2015 at 5:51:37 AM UTC-4, Dheerendra Rathor wrote:
>>
>> Hello all,
>>
>> With reference to this line: 
>> https://github.com/django/django/blob/master/django/views/generic/base.py#L61
>>  
>> from django.view.generic.base
>> before calling self.dispatch request, args and kwargs attributes have 
>> been added to self. So these all are available in self in http_method 
>> handlers. 
>>
>> I think this behaviour is present due to old functional views, but now 
>> passing these as arguments to http_method handlers look obsolete.
>>
>> We can potentially remove these and make http handlers more simple just 
>> like
>> class CustomView(View):
>> def get(self):
>> request =self.request
>> # code ...
>>
>>
>>
>>

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

Re: Why passing request, *args, **kwargs in dispatch method for generic views

[Marc Tamlyn]

This would cause too much churn for user code - there are millions of CBVs
in the wild with customised dispatch/get/post/etc methods which expect
these variables and perhaps use them directly. Unfortunately this ship has
sailed.

On 23 October 2015 at 14:45, Tom Christie  wrote:

> Although those variables are available in both places I'd prefer to see
> them passed explicitly.
> That will tend to nudge users slightly more towards passing variable
> around explicitly and slightly away from storing state on the view instance
> (which can be a bit of a gnarly practice - harder to follow the flow of
> where and when some piece of information is actually being used/modified)
>
> On Friday, 23 October 2015 14:03:17 UTC+1, Tim Graham wrote:
>>
>> It looks like setting the request/args/kwargs attributes came after the
>> original CBGV implementation.
>>
>> https://github.com/django/django/commit/ea6b95db
>> https://code.djangoproject.com/ticket/19316
>> https://groups.google.com/d/topic/django-developers/7c7aI-slGNc/discussion
>>
>> I haven't looked closely to see if your proposal might cause problems
>> (you could give it a try and see if you can get the Django test suite
>> passing), however, changing the signature of those methods would require a
>> deprecation path and could result in a lot of churn in user code which
>> would probably cause some angst. I'll leave it to users of CGGVs to offer
>> an opinion on whether or not it could be worthwhile.
>>
>> On Friday, October 23, 2015 at 5:51:37 AM UTC-4, Dheerendra Rathor wrote:
>>>
>>> Hello all,
>>>
>>> With reference to this line:
>>> https://github.com/django/django/blob/master/django/views/generic/base.py#L61
>>> from django.view.generic.base
>>> before calling self.dispatch request, args and kwargs attributes have
>>> been added to self. So these all are available in self in http_method
>>> handlers.
>>>
>>> I think this behaviour is present due to old functional views, but now
>>> passing these as arguments to http_method handlers look obsolete.
>>>
>>> We can potentially remove these and make http handlers more simple just
>>> like
>>> class CustomView(View):
>>> def get(self):
>>> request =self.request
>>> # code ...
>>>
>>>
>>>
>>> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/6fe6b37d-8ab6-4c66-b036-db480547c4fd%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: #25582: Add a way to build URLs with query strings

['Tom Evans' via Django developers (Contributions to Django itself)]

On Fri, Oct 23, 2015 at 12:59 PM, guettli  wrote:
> API proposal:
>
> Add a new kwarg to reverse():
>
>reverse(..., get=None)
>
>
> Example: reverse('my_view_name', kwargs={'pk': '1'}, get=dict(param='value')

Would 'get' be a dict or a querydict? (URL parameters can be repeated,
dict keys cannot.)

Cheers

Tom

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

Re: makemigrations --exit; exit status feels backwards from conventions

[Chris Foresman]

Jon,

You proposal seems like a sane and welcome change that aligns the exit 
status of --exit with long-standing convention.


Thanks,
Chris



On Wednesday, October 21, 2015 at 10:20:09 AM UTC-5, Jon Dufresne wrote:
>
> On Tue, Oct 20, 2015 at 9:29 PM, Gavin Wahl  > wrote: 
> > In your case, successfully creating a migration indicates a failure. 
>
> Only if the --check flag is on. The --check flag indicates that one is 
> explicitly checking that all model changes have migrations. A non-zero 
> exist status indicates that migrations were missing. If you feel the 
> help text could be improved to communicate this, I can work towards 
> that. 
>
> > Why do you object to using a ! to communicate this? 
>
> With the --check flag or the --exit flag? 
>
> I think I covered this in the OP. But just to clarify: 
>
> My use case: 
>
> Continuous integration server check's developers' commits for 
> correctness. One aspect of correctness is that all model changes have 
> migrations. 
>
> In shell scripting and CI servers an exit status of 0 indicates 
> true/pass and an exit status of non-zero indicates false/failure. 
>
> Therefore, the command should return 0 when everything is OK and 
> correct and non-zero otherwise. Commits are correct when all model 
> changes are accounted for. 
>
> The current --exit behavior, returns non-zero when everything is 
> correct. To account for this in CI, one must negate the exit status 
> with !, this goes against conventional behavior. 
>
> Further, if something goes terribly wrong and there is an unhandled 
> exception, negating the exit status will make the CI stage appear to 
> pass. This is backwards! CI can't tell the difference between "all 
> changes accounted for" and "Python had an unhandled exception". 
>
>
> Cheers, 
> Jon 
>

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

Python 3.5 Support in Django 1.8.x?

[Tim Allen]

Since Django 1.9 will support Python 3.5, I was wondering if there are any 
plans to support Python 3.5 in Django 1.8, since it is an LTR.

I did a cursory search and didn't find anything stating yay or nay. I'm 
going to assume 1.8 only support 3.4 for now, as I've had issues with 
Python 3.5 (if, on the other hand, there will be support, I'll report this 
bugs in detail).

Can someone give me an answer or point me to a relevant discussion I may 
have missed? Thank you.

Regards,

Tim

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

Re: #25582: Add a way to build URLs with query strings

[Collin Anderson]

If it helps, I have a similar need in the template. My case requires 
adding, removing, or replacing one of the arguments on the fly:

In templates, I often need to change _one_ key of a GET request on the fly. 
My use case is a "filter by" sidebar on the same page as a "sort by" and 
"number per page". (Example: http://comcenter.com/category/BC020/ ).

I currently use a simple custom template tag:
@register.simple_tag
def make_query(params, key=None, value=None):
from django.utils.http import urlencode
if key:
params = params.copy()
if value:
params[key] = value
else:
params.pop(key, None)
return '?' + urlencode(params, True) if params else '.'

For previous/next pages, I simply use:


For more complicated things, in the view I collect all of the valid params 
and pass them to the template. (I don't keep the "page" key in "params", 
because I want that to reset when filtering or sorting.)



I can remove keys like so:
Show All

On Friday, October 23, 2015 at 3:41:42 AM UTC-4, guettli wrote:
>
> From  https://code.djangoproject.com/ticket/25582
>
>  {{{
>
> It is a common question on stackoverflow and other places:
>
> How to reverse() to url including GET parameters? Example: 
> .../myview?foo=bar
>
> ​
> http://stackoverflow.com/questions/9585491/how-do-i-pass-get-parameters-using-django-urlresolvers-reverse
>
> ​http://stackoverflow.com/a/27641445/633961
>
> It would be very nice if django could implement a short-cut which provides
> this.
> It would be useful for python code and template, too.
> }}}
>
> {{{
> If we do add it, it likely needs a discussion on the DevelopersMailingList 
>  to figure out 
> what the API should look like. See also #10941 
>  which asks for a template 
> tag for creating query strings in templates.
> }}}
>
> What do you think?
>
>
>
>

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

Re: Python 3.5 Support in Django 1.8.x?

[Tim Graham]

Officially Django 1.8 doesn't support Python 3.5. In practice, I think it 
probably works. See details in https://code.djangoproject.com/ticket/25502 
about why the 1.8 test suite doesn't pass with Python 3.5. We could 
probably change that if there is sufficient interest, however, I'm not 
aware of a precedent of adding Python version support in a major release 
retroactively.

On Friday, October 23, 2015 at 10:48:54 AM UTC-4, Tim Allen wrote:
>
> Since Django 1.9 will support Python 3.5, I was wondering if there are any 
> plans to support Python 3.5 in Django 1.8, since it is an LTR.
>
> I did a cursory search and didn't find anything stating yay or nay. I'm 
> going to assume 1.8 only support 3.4 for now, as I've had issues with 
> Python 3.5 (if, on the other hand, there will be support, I'll report this 
> bugs in detail).
>
> Can someone give me an answer or point me to a relevant discussion I may 
> have missed? Thank you.
>
> Regards,
>
> Tim
>

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

Re: #25582: Add a way to build URLs with query strings

[Tim Graham]

On the ticket, Luke pointed out these libraries:

1) For Python code: urlobject ​​https://github.com/zacharyvoase/urlobject/ 
and furl ​​https://github.com/gruns/furl
2) For template code: django-spurl - ​​https://github.com/j4mie/django-spurl

He doesn't see a need to include a subset of the functionality provided by 
these libraries in Django itself.

I'm okay with that if it's the consensus but this brings up the question 
about to what extent the documentation should point to or endorse 
third-party packages.

On Friday, October 23, 2015 at 11:18:38 AM UTC-4, Collin Anderson wrote:
>
> If it helps, I have a similar need in the template. My case requires 
> adding, removing, or replacing one of the arguments on the fly:
>
> In templates, I often need to change _one_ key of a GET request on the 
> fly. My use case is a "filter by" sidebar on the same page as a "sort by" 
> and "number per page". (Example: http://comcenter.com/category/BC020/ ).
>
> I currently use a simple custom template tag:
> @register.simple_tag
> def make_query(params, key=None, value=None):
> from django.utils.http import urlencode
> if key:
> params = params.copy()
> if value:
> params[key] = value
> else:
> params.pop(key, None)
> return '?' + urlencode(params, True) if params else '.'
>
> For previous/next pages, I simply use:
> 
>
> For more complicated things, in the view I collect all of the valid params 
> and pass them to the template. (I don't keep the "page" key in "params", 
> because I want that to reset when filtering or sorting.)
> 
> 
>
> I can remove keys like so:
> Show All
>
> On Friday, October 23, 2015 at 3:41:42 AM UTC-4, guettli wrote:
>>
>> From  https://code.djangoproject.com/ticket/25582
>>
>>  {{{
>>
>> It is a common question on stackoverflow and other places:
>>
>> How to reverse() to url including GET parameters? Example: 
>> .../myview?foo=bar
>>
>> ​
>> http://stackoverflow.com/questions/9585491/how-do-i-pass-get-parameters-using-django-urlresolvers-reverse
>>
>> ​http://stackoverflow.com/a/27641445/633961
>>
>> It would be very nice if django could implement a short-cut which provides
>> this.
>> It would be useful for python code and template, too.
>> }}}
>>
>> {{{
>> If we do add it, it likely needs a discussion on the 
>> DevelopersMailingList 
>>  to figure 
>> out what the API should look like. See also #10941 
>>  which asks for a template 
>> tag for creating query strings in templates.
>> }}}
>>
>> What do you think?
>>
>>
>>
>>

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

Re: Why passing request, *args, **kwargs in dispatch method for generic views

[Dheerendra Rathor]

On Friday, 23 October 2015 19:31:07 UTC+5:30, Marc Tamlyn wrote:
>
> This would cause too much churn for user code - there are millions of CBVs 
> in the wild with customised dispatch/get/post/etc methods which expect 
> these variables and perhaps use them directly. Unfortunately this ship has 
> sailed.
>
> Yeah I am also thinking that it is probably too late to make changes in 
CBGVs. But one this we certainly do is add request in args tuple in 
dispatch method. This way backward compatibility can be ensured pretty 
easily. 

Currently many decorators have been written keeping these signatures in 
mind. Changing the whole signature will definitely break many of third 
party applications. I didn't get much time to try changing this signature, 
but I am pretty much certain about the destruction it will cause!
 

> On 23 October 2015 at 14:45, Tom Christie  > wrote:
>
>> Although those variables are available in both places I'd prefer to see 
>> them passed explicitly.
>> That will tend to nudge users slightly more towards passing variable 
>> around explicitly and slightly away from storing state on the view instance 
>> (which can be a bit of a gnarly practice - harder to follow the flow of 
>> where and when some piece of information is actually being used/modified)
>>
>> On Friday, 23 October 2015 14:03:17 UTC+1, Tim Graham wrote:
>>>
>>> It looks like setting the request/args/kwargs attributes came after the 
>>> original CBGV implementation. 
>>>
>>> https://github.com/django/django/commit/ea6b95db
>>> https://code.djangoproject.com/ticket/19316
>>>
>>> https://groups.google.com/d/topic/django-developers/7c7aI-slGNc/discussion
>>>
>>> I haven't looked closely to see if your proposal might cause problems 
>>> (you could give it a try and see if you can get the Django test suite 
>>> passing), however, changing the signature of those methods would require a 
>>> deprecation path and could result in a lot of churn in user code which 
>>> would probably cause some angst. I'll leave it to users of CGGVs to offer 
>>> an opinion on whether or not it could be worthwhile.
>>>
>>> On Friday, October 23, 2015 at 5:51:37 AM UTC-4, Dheerendra Rathor wrote:

 Hello all,

 With reference to this line: 
 https://github.com/django/django/blob/master/django/views/generic/base.py#L61
  
 from django.view.generic.base
 before calling self.dispatch request, args and kwargs attributes have 
 been added to self. So these all are available in self in http_method 
 handlers. 

 I think this behaviour is present due to old functional views, but now 
 passing these as arguments to http_method handlers look obsolete.

 We can potentially remove these and make http handlers more simple just 
 like
 class CustomView(View):
 def get(self):
 request =self.request
 # code ...



 -- 
>> You received this message because you are subscribed to the Google 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 http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/6fe6b37d-8ab6-4c66-b036-db480547c4fd%40googlegroups.com
>>  
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
On Friday, 23 October 2015 19:31:07 UTC+5:30, Marc Tamlyn wrote:
>
> This would cause too much churn for user code - there are millions of CBVs 
> in the wild with customised dispatch/get/post/etc methods which expect 
> these variables and perhaps use them directly. Unfortunately this ship has 
> sailed.
>
> On 23 October 2015 at 14:45, Tom Christie  > wrote:
>
>> Although those variables are available in both places I'd prefer to see 
>> them passed explicitly.
>> That will tend to nudge users slightly more towards passing variable 
>> around explicitly and slightly away from storing state on the view instance 
>> (which can be a bit of a gnarly practice - harder to follow the flow of 
>> where and when some piece of information is actually being used/modified)
>>
>> On Friday, 23 October 2015 14:03:17 UTC+1, Tim Graham wrote:
>>>
>>> It looks like setting the request/args/kwargs attributes came after the 
>>> original CBGV implementation. 
>>>
>>> https://github.com/django/django/commit/ea6b95db
>>> https://code.djangoproject.com/ticket/19316
>>>
>>> https://groups.google.com/d/topic/django-developers/7c7aI-slGNc/discussion
>>>
>>> I haven't looked closely to see if your proposal might cause problems 
>>> (you could give it a try and see if you c

Django 1.9: default='' no longer permitted on model field (with blank=False)

[James Addison]

I have a model like so:

class Provider(models.Model):
description = models.TextField(default='')


In recent Django 1.9 changes (this did not occur with 1.8.x), this causes 
the following traceback:

Performing system checks...


Traceback (most recent call last):
  File 
"/home/vagrant/.virtualenvs/myproject/lib/python3.4/site-packages/gevent/greenlet.py"
, line 523, in run
result = self._run(*self.args, **self.kwargs)
  File 
"/home/vagrant/.virtualenvs/myproject/src/django/django/utils/autoreload.py"
, line 226, in wrapper
fn(*args, **kwargs)
  File 
"/home/vagrant/.virtualenvs/myproject/src/django/django/core/management/commands/runserver.py"
, line 116, in inner_run
self.check(display_num_errors=True)
  File 
"/home/vagrant/.virtualenvs/myproject/src/django/django/core/management/base.py"
, line 472, in check
raise SystemCheckError(msg)
django.core.management.base.SystemCheckError: SystemCheckError: System 
check identified some issues:


ERRORS:
businesses.Provider.description: (fields.E008) Invalid 'default' value: This 
field cannot be blank.
images.ImageSet.hash: (fields.E008) Invalid 'default' value: This field 
cannot be blank.
users.User.gender: (fields.E008) Invalid 'default' value: This field cannot 
be blank.


System check identified 3 issues (0 silenced).

Why is it that this was perfectly allowable before but not now? I have a 
data processing script that's pulling in data from an external source and 
creating instances with blank 'descriptions', it now doesn't work.  I have 
to set `blank=True` on fields having this error, which I don't want to do 
(for form validation reasons).

I believe the following links are pertinent:

https://code.djangoproject.com/ticket/25417
https://github.com/django/django/pull/5303

James

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

contribute to google summer of code

[yash . nisar]

Hi Tim, 
   I want to participate and contribute to the google summer of 
code 2k16. How do I get myself started ?

-- 

   
   
 

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

Re: Django 1.9: default='' no longer permitted on model field (with blank=False)

[Marc Tamlyn]

I disagree with this system check and I would like to see it reverted
before 1.9 final.

I admit that my opinions here are skewed by the fact that I think model
level validation is fundamentally not well implemented by Django at all. I
work to a philosophy that there are two places where validation happens -
once at the entry point to the system (form or serialiser) and once at the
database level to ensure integrity of the data.

I view model level validators, custom clean methods, and the editable and
blank flags as merely hints to automatic ModelForm creation and other
similar objects. I can't think of a single time I have explicitly called
model.clean(). Now, I can see the merits of a good model level validation
system, Django's model level validation is trivial to bypass and I consider
relying on it to be bad practice.

This check implies that you must use model level validation. I don't agree
it should be that unavoidable a feature. The docs for `blank` in fact only
reference form validation
https://docs.djangoproject.com/en/1.8/ref/models/fields/#blank.

The system check framework is supposed to be there to stop easy mistakes.
However:
- The original error reported by the OP of the ticket was in fact not able
to accidentally deploy the code in question because it did not run.
- It is common practice to not be use or at least be perfect about your
model level validation. I certainly have created many fields which are
system level but do not have `editable=False` on them because I explicitly
make sure all of my forms do not include this field. They are likely hidden
away in the admin as well because they are only used by some internal code.
Best practices such as the requirement for model forms to have fields
specified make sure that I am being explicit.
- If we are going to make it required that your model level validation is
correct, then we need to do so in a much more complete way than just
checking default values. In particular, code such as Manager.create()
should check validation rules. This would be a hugely breaking change for
Django.

I can of course easily bypass this change, add it to ignored checks or
similar. However as a beginner developer I would see this check, think
model level validation is important and reliable.

Marc

On 23 October 2015 at 21:51, James Addison  wrote:

> I have a model like so:
>
> class Provider(models.Model):
> description = models.TextField(default='')
>
>
> In recent Django 1.9 changes (this did not occur with 1.8.x), this causes
> the following traceback:
>
> Performing system checks...
>
>
> Traceback (most recent call last):
>   File
> "/home/vagrant/.virtualenvs/myproject/lib/python3.4/site-packages/gevent/greenlet.py"
> , line 523, in run
> result = self._run(*self.args, **self.kwargs)
>   File
> "/home/vagrant/.virtualenvs/myproject/src/django/django/utils/autoreload.py"
> , line 226, in wrapper
> fn(*args, **kwargs)
>   File
> "/home/vagrant/.virtualenvs/myproject/src/django/django/core/management/commands/runserver.py"
> , line 116, in inner_run
> self.check(display_num_errors=True)
>   File
> "/home/vagrant/.virtualenvs/myproject/src/django/django/core/management/base.py"
> , line 472, in check
> raise SystemCheckError(msg)
> django.core.management.base.SystemCheckError: SystemCheckError: System
> check identified some issues:
>
>
> ERRORS:
> businesses.Provider.description: (fields.E008) Invalid 'default' value:
> This field cannot be blank.
> images.ImageSet.hash: (fields.E008) Invalid 'default' value: This field
> cannot be blank.
> users.User.gender: (fields.E008) Invalid 'default' value: This field
> cannot be blank.
>
>
> System check identified 3 issues (0 silenced).
>
> Why is it that this was perfectly allowable before but not now? I have a
> data processing script that's pulling in data from an external source and
> creating instances with blank 'descriptions', it now doesn't work.  I have
> to set `blank=True` on fields having this error, which I don't want to do
> (for form validation reasons).
>
> I believe the following links are pertinent:
>
> https://code.djangoproject.com/ticket/25417
> https://github.com/django/django/pull/5303
>
> James
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/c6ffdd4b-6147-43ff-be73-daef2e8149fe%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout

Re: Python 3.5 Support in Django 1.8.x?

[Marc Tamlyn]

FWIW, I think we should add 3.5 support to 1.8.

On 23 October 2015 at 17:08, Tim Graham  wrote:

> Officially Django 1.8 doesn't support Python 3.5. In practice, I think it
> probably works. See details in https://code.djangoproject.com/ticket/25502
> about why the 1.8 test suite doesn't pass with Python 3.5. We could
> probably change that if there is sufficient interest, however, I'm not
> aware of a precedent of adding Python version support in a major release
> retroactively.
>
> On Friday, October 23, 2015 at 10:48:54 AM UTC-4, Tim Allen wrote:
>>
>> Since Django 1.9 will support Python 3.5, I was wondering if there are
>> any plans to support Python 3.5 in Django 1.8, since it is an LTR.
>>
>> I did a cursory search and didn't find anything stating yay or nay. I'm
>> going to assume 1.8 only support 3.4 for now, as I've had issues with
>> Python 3.5 (if, on the other hand, there will be support, I'll report this
>> bugs in detail).
>>
>> Can someone give me an answer or point me to a relevant discussion I may
>> have missed? Thank you.
>>
>> Regards,
>>
>> Tim
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/eb6e94aa-eedf-4fff-9d3b-f7ba424c0a71%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Python 3.5 Support in Django 1.8.x?

[Dheerendra Rathor]

In my opinion adding 3.5 support to 1.8 makes sense since 1.8 is LTS and by
the end of 2018 we'll have python 3.6 and 3.7 as well

On Sat, 24 Oct 2015 at 03:28 Marc Tamlyn  wrote:

> FWIW, I think we should add 3.5 support to 1.8.
>
> On 23 October 2015 at 17:08, Tim Graham  wrote:
>
>> Officially Django 1.8 doesn't support Python 3.5. In practice, I think it
>> probably works. See details in
>> https://code.djangoproject.com/ticket/25502 about why the 1.8 test suite
>> doesn't pass with Python 3.5. We could probably change that if there is
>> sufficient interest, however, I'm not aware of a precedent of adding Python
>> version support in a major release retroactively.
>>
>> On Friday, October 23, 2015 at 10:48:54 AM UTC-4, Tim Allen wrote:
>>>
>>> Since Django 1.9 will support Python 3.5, I was wondering if there are
>>> any plans to support Python 3.5 in Django 1.8, since it is an LTR.
>>>
>>> I did a cursory search and didn't find anything stating yay or nay. I'm
>>> going to assume 1.8 only support 3.4 for now, as I've had issues with
>>> Python 3.5 (if, on the other hand, there will be support, I'll report this
>>> bugs in detail).
>>>
>>> Can someone give me an answer or point me to a relevant discussion I may
>>> have missed? Thank you.
>>>
>>> Regards,
>>>
>>> Tim
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/eb6e94aa-eedf-4fff-9d3b-f7ba424c0a71%40googlegroups.com
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAMwjO1GkMrKnJn9J0HHTqcauMF4gSMH-Bwd-n2beSrCCr9rixg%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAByqUghkG5FqfMWCLmxpdVMxcD%3DnfvXtDT6DH%3Db7TKGQVyLoSA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: contribute to google summer of code

[Russell Keith-Magee]

Hi Yash,

The Google Summer of Code 2016 hasn’t even been announced yet. Django
hasn’t applied to be a mentor organization, and it’s not yet certain that
we’ll even apply.

However, assuming that we do - the best thing you can do to improve your
chances to be accepted as a Django GSoC student is to start contributing
now. Read up on Django’s contribution documentation [1], and make yourself
known to the core team by your contributions. That way, when it comes time
to evaluate student applications, you’ll be a known individual, and more
likely to be able to get the attention you need to develop a proposal.

[1] https://docs.djangoproject.com/en/dev/internals/contributing/

Yours,
Russ Magee %-)

On Sat, Oct 24, 2015 at 5:29 AM,  wrote:

> Hi Tim,
>I want to participate and contribute to the google summer of
> code 2k16. How do I get myself started ?
>
>  
>  
>  
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/bd231813-cd1f-45ee-9fd0-a39a2862f40f%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Django 1.9: default='' no longer permitted on model field (with blank=False)

[Russell Keith-Magee]

On Sat, Oct 24, 2015 at 5:42 AM, Marc Tamlyn  wrote:

> I disagree with this system check and I would like to see it reverted
> before 1.9 final.
>

I agree - I’d argue that this check is demonstrably *incorrect*.


> I admit that my opinions here are skewed by the fact that I think model
> level validation is fundamentally not well implemented by Django at all. I
> work to a philosophy that there are two places where validation happens -
> once at the entry point to the system (form or serialiser) and once at the
> database level to ensure integrity of the data.
>

I don’t think you even need to bring model validation into this discussion
- the two keywords in play here (blank and default) are for entirely
different parts of Django. blank is display/form logic. default is model
logic. There’s some crossover to be sure, but the use case presented by
James is entirely legal and valid for exactly that reason.

So, +1 - this should be reverted. As far as I can make out, it’s not even
correct to say that this is a warning - the model description makes perfect
sense as-is. The only way I can see that this check would be valid is a
confirmation of blank=False and a model-level non-zero length validator -
but that’s getting sufficiently eclectic that I don’t think it warrants
inclusion.

Yours,
Russ Magee %-)

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

Re: Python 3.5 Support in Django 1.8.x?

[Russell Keith-Magee]

Agreed. This didn’t really affect 1.4 because 2.7 was in a very stable
place, and we didn’t support Python 3. Now that we’re Py3 focussed, and
Python has a similar backwards compatibility policy to Django (i.e., Python
3.7 isn’t going to break all Python 3.6 code in subtle ways), it makes
sense that our LTS will be officially supported.

Russ %-)

On Sat, Oct 24, 2015 at 5:57 AM, Marc Tamlyn  wrote:

> FWIW, I think we should add 3.5 support to 1.8.
>
> On 23 October 2015 at 17:08, Tim Graham  wrote:
>
>> Officially Django 1.8 doesn't support Python 3.5. In practice, I think it
>> probably works. See details in
>> https://code.djangoproject.com/ticket/25502 about why the 1.8 test suite
>> doesn't pass with Python 3.5. We could probably change that if there is
>> sufficient interest, however, I'm not aware of a precedent of adding Python
>> version support in a major release retroactively.
>>
>> On Friday, October 23, 2015 at 10:48:54 AM UTC-4, Tim Allen wrote:
>>>
>>> Since Django 1.9 will support Python 3.5, I was wondering if there are
>>> any plans to support Python 3.5 in Django 1.8, since it is an LTR.
>>>
>>> I did a cursory search and didn't find anything stating yay or nay. I'm
>>> going to assume 1.8 only support 3.4 for now, as I've had issues with
>>> Python 3.5 (if, on the other hand, there will be support, I'll report this
>>> bugs in detail).
>>>
>>> Can someone give me an answer or point me to a relevant discussion I may
>>> have missed? Thank you.
>>>
>>> Regards,
>>>
>>> Tim
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/eb6e94aa-eedf-4fff-9d3b-f7ba424c0a71%40googlegroups.com
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAMwjO1GkMrKnJn9J0HHTqcauMF4gSMH-Bwd-n2beSrCCr9rixg%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAJxq84_bc%3DUD0w8zwoF6%3D5R4dc3%3DKOODG2DWDaZv3YusYSY5ag%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django 1.9: default='' no longer permitted on model field (with blank=False)

[Tim Graham]

Maybe it would be enough to ignore ValidationErrors with code='blank' 
and/or code='null' in the check? That's been the only "false positive" with 
this check as far as I can tell.

On Friday, October 23, 2015 at 8:08:57 PM UTC-4, Russell Keith-Magee wrote:
>
> On Sat, Oct 24, 2015 at 5:42 AM, Marc Tamlyn  > wrote:
>
>> I disagree with this system check and I would like to see it reverted 
>> before 1.9 final.
>>
>
> I agree - I’d argue that this check is demonstrably *incorrect*. 
>  
>
>> I admit that my opinions here are skewed by the fact that I think model 
>> level validation is fundamentally not well implemented by Django at all. I 
>> work to a philosophy that there are two places where validation happens - 
>> once at the entry point to the system (form or serialiser) and once at the 
>> database level to ensure integrity of the data.
>>
>
> I don’t think you even need to bring model validation into this discussion 
> - the two keywords in play here (blank and default) are for entirely 
> different parts of Django. blank is display/form logic. default is model 
> logic. There’s some crossover to be sure, but the use case presented by 
> James is entirely legal and valid for exactly that reason.
>
> So, +1 - this should be reverted. As far as I can make out, it’s not even 
> correct to say that this is a warning - the model description makes perfect 
> sense as-is. The only way I can see that this check would be valid is a 
> confirmation of blank=False and a model-level non-zero length validator - 
> but that’s getting sufficiently eclectic that I don’t think it warrants 
> inclusion.
>
> Yours,
> Russ Magee %-)
>

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

Re: Python 3.5 Support in Django 1.8.x?

[Tim Graham]

You might be surprised at the number of fixes needed for Python 3.5 support 
(and to silence all deprecation warnings). They're tracked at 
https://code.djangoproject.com/ticket/23763.

I backported most of them to 1.8 during the 1.8 release cycle, but stopped 
doing so once 1.8 went final. I don't mind putting together a branch with 
the rest of the changes to get the build passing on Django 1.8/Python 3.5, 
but I'm not so sure we'll want to continue this with Python 3.6 and beyond.

On Friday, October 23, 2015 at 8:14:06 PM UTC-4, Russell Keith-Magee wrote:
>
>
> Agreed. This didn’t really affect 1.4 because 2.7 was in a very stable 
> place, and we didn’t support Python 3. Now that we’re Py3 focussed, and 
> Python has a similar backwards compatibility policy to Django (i.e., Python 
> 3.7 isn’t going to break all Python 3.6 code in subtle ways), it makes 
> sense that our LTS will be officially supported.
>
> Russ %-)
>
> On Sat, Oct 24, 2015 at 5:57 AM, Marc Tamlyn  > wrote:
>
>> FWIW, I think we should add 3.5 support to 1.8.
>>
>> On 23 October 2015 at 17:08, Tim Graham 
>> > wrote:
>>
>>> Officially Django 1.8 doesn't support Python 3.5. In practice, I think 
>>> it probably works. See details in 
>>> https://code.djangoproject.com/ticket/25502 about why the 1.8 test 
>>> suite doesn't pass with Python 3.5. We could probably change that if there 
>>> is sufficient interest, however, I'm not aware of a precedent of adding 
>>> Python version support in a major release retroactively.
>>>
>>> On Friday, October 23, 2015 at 10:48:54 AM UTC-4, Tim Allen wrote:

 Since Django 1.9 will support Python 3.5, I was wondering if there are 
 any plans to support Python 3.5 in Django 1.8, since it is an LTR.

 I did a cursory search and didn't find anything stating yay or nay. I'm 
 going to assume 1.8 only support 3.4 for now, as I've had issues with 
 Python 3.5 (if, on the other hand, there will be support, I'll report this 
 bugs in detail).

 Can someone give me an answer or point me to a relevant discussion I 
 may have missed? Thank you.

 Regards,

 Tim

>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> 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 http://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/django-developers/eb6e94aa-eedf-4fff-9d3b-f7ba424c0a71%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 http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/CAMwjO1GkMrKnJn9J0HHTqcauMF4gSMH-Bwd-n2beSrCCr9rixg%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6ef88692-81e3-40ab-9cef-75db2d344751%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django 1.9: default='' no longer permitted on model field (with blank=False)

[Tim Graham]

In addition, downgrading it from "error" to "warning" would be okay with 
me, too).  If we had some sort of "# NOQA" mechanism like flake8 has to 
more granularly ignore system check warnings, that could be nifty too.

I'll admit I might be overly enthusiastic about using the checks framework 
to try to prevent invalid tickets from newbies making mistakes. It's 
difficult to anticipate the universe of valid use cases, so thanks for 
testing the prerelease and offering your feedback.

On Friday, October 23, 2015 at 8:16:58 PM UTC-4, Tim Graham wrote:
>
> Maybe it would be enough to ignore ValidationErrors with code='blank' 
> and/or code='null' in the check? That's been the only "false positive" with 
> this check as far as I can tell.
>
> On Friday, October 23, 2015 at 8:08:57 PM UTC-4, Russell Keith-Magee wrote:
>>
>> On Sat, Oct 24, 2015 at 5:42 AM, Marc Tamlyn  wrote:
>>
>>> I disagree with this system check and I would like to see it reverted 
>>> before 1.9 final.
>>>
>>
>> I agree - I’d argue that this check is demonstrably *incorrect*. 
>>  
>>
>>> I admit that my opinions here are skewed by the fact that I think model 
>>> level validation is fundamentally not well implemented by Django at all. I 
>>> work to a philosophy that there are two places where validation happens - 
>>> once at the entry point to the system (form or serialiser) and once at the 
>>> database level to ensure integrity of the data.
>>>
>>
>> I don’t think you even need to bring model validation into this 
>> discussion - the two keywords in play here (blank and default) are for 
>> entirely different parts of Django. blank is display/form logic. default is 
>> model logic. There’s some crossover to be sure, but the use case presented 
>> by James is entirely legal and valid for exactly that reason.
>>
>> So, +1 - this should be reverted. As far as I can make out, it’s not even 
>> correct to say that this is a warning - the model description makes perfect 
>> sense as-is. The only way I can see that this check would be valid is a 
>> confirmation of blank=False and a model-level non-zero length validator - 
>> but that’s getting sufficiently eclectic that I don’t think it warrants 
>> inclusion.
>>
>> Yours,
>> Russ Magee %-)
>>
>

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

Re: Django 1.9: default='' no longer permitted on model field (with blank=False)

[charettes]

Hi everyone I'm the author of this change.

I'm not a big fan of the model validation layer myself but I assumed basing 
a model level check on it would make sense. I was not aware there was such 
a bad feeling about the model level validation, if I had I wouldn't have 
based this check on it.

It was a controversial change from the beginning and the process of adding 
this check should have taken place in it's own ticket.

I also think this check could be adjusted to ignore code='blank' and 'null' 
and turned into a warning, I don't believe it is entirely flawed as report 
have shown (https://code.djangoproject.com/ticket/25480#comment:3). It 
wouldn't be the first time a newly added check requires adjustments.

I submitted a PR (https://github.com/django/django/pull/5471) to completely 
revert this change given suggest adjustments don't get enough support.

Thanks for your feedback on this prerelease,

Simon

Le vendredi 23 octobre 2015 17:42:44 UTC-4, Marc Tamlyn a écrit :
>
> I disagree with this system check and I would like to see it reverted 
> before 1.9 final.
>
> I admit that my opinions here are skewed by the fact that I think model 
> level validation is fundamentally not well implemented by Django at all. I 
> work to a philosophy that there are two places where validation happens - 
> once at the entry point to the system (form or serialiser) and once at the 
> database level to ensure integrity of the data.
>
> I view model level validators, custom clean methods, and the editable and 
> blank flags as merely hints to automatic ModelForm creation and other 
> similar objects. I can't think of a single time I have explicitly called 
> model.clean(). Now, I can see the merits of a good model level validation 
> system, Django's model level validation is trivial to bypass and I consider 
> relying on it to be bad practice.
>
> This check implies that you must use model level validation. I don't agree 
> it should be that unavoidable a feature. The docs for `blank` in fact only 
> reference form validation 
> https://docs.djangoproject.com/en/1.8/ref/models/fields/#blank.
>
> The system check framework is supposed to be there to stop easy mistakes. 
> However:
> - The original error reported by the OP of the ticket was in fact not able 
> to accidentally deploy the code in question because it did not run.
> - It is common practice to not be use or at least be perfect about your 
> model level validation. I certainly have created many fields which are 
> system level but do not have `editable=False` on them because I explicitly 
> make sure all of my forms do not include this field. They are likely hidden 
> away in the admin as well because they are only used by some internal code. 
> Best practices such as the requirement for model forms to have fields 
> specified make sure that I am being explicit.
> - If we are going to make it required that your model level validation is 
> correct, then we need to do so in a much more complete way than just 
> checking default values. In particular, code such as Manager.create() 
> should check validation rules. This would be a hugely breaking change for 
> Django.
>
> I can of course easily bypass this change, add it to ignored checks or 
> similar. However as a beginner developer I would see this check, think 
> model level validation is important and reliable.
>
> Marc
>
> On 23 October 2015 at 21:51, James Addison 
> > wrote:
>
>> I have a model like so:
>>
>> class Provider(models.Model):
>> description = models.TextField(default='')
>>
>>
>> In recent Django 1.9 changes (this did not occur with 1.8.x), this causes 
>> the following traceback:
>>
>> Performing system checks...
>>
>>
>> Traceback (most recent call last):
>>   File 
>> "/home/vagrant/.virtualenvs/myproject/lib/python3.4/site-packages/gevent/greenlet.py"
>> , line 523, in run
>> result = self._run(*self.args, **self.kwargs)
>>   File 
>> "/home/vagrant/.virtualenvs/myproject/src/django/django/utils/autoreload.py"
>> , line 226, in wrapper
>> fn(*args, **kwargs)
>>   File 
>> "/home/vagrant/.virtualenvs/myproject/src/django/django/core/management/commands/runserver.py"
>> , line 116, in inner_run
>> self.check(display_num_errors=True)
>>   File 
>> "/home/vagrant/.virtualenvs/myproject/src/django/django/core/management/base.py"
>> , line 472, in check
>> raise SystemCheckError(msg)
>> django.core.management.base.SystemCheckError: SystemCheckError: System 
>> check identified some issues:
>>
>>
>> ERRORS:
>> businesses.Provider.description: (fields.E008) Invalid 'default' value: 
>> This field cannot be blank.
>> images.ImageSet.hash: (fields.E008) Invalid 'default' value: This field 
>> cannot be blank.
>> users.User.gender: (fields.E008) Invalid 'default' value: This field 
>> cannot be blank.
>>
>>
>> System check identified 3 issues (0 silenced).
>>
>> Why is it that this was perfectly allowable before but not now? I have a 
>> data processing script that's pulling i