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

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

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

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 t

Re: Python 3.5 Support in Django 1.8.x?

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

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

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

Re: Python 3.5 Support in Django 1.8.x?

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 tha

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

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 v

Re: contribute to google summer of code

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

Re: Python 3.5 Support in Django 1.8.x?

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

Re: Python 3.5 Support in Django 1.8.x?

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

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

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

contribute to google summer of code

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

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

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/.virtu

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

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

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

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 funct

Re: Python 3.5 Support in Django 1.8.x?

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 o

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

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 p

Python 3.5 Support in Django 1.8.x?

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,

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

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

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

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 cann

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

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 v

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

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 fo

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

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

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

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 revers

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

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,

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

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

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

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 handle

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

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