Re: Allow impossible model validation (mainly admin and generic forms)

Hi guys, to answer Tim's questions: > Would Django itself ever raise ValidationError in Model.save()? That can be possible. Currently I have no clear opinion of where IntegrityError and other errors should be changed to ValidationError. > I wonder how you propose converting something like an

Re: Make template caching a feature of the Django template engine

Yes, more or less. Although it's not strictly required to deprecate the cached template loader. However if we can deprecate the cached template loader I'd also like to deprecate the weird way of passing arguments to template loaders

Re: Allow impossible model validation (mainly admin and generic forms)

> Append form's non_field_errors with message like Given that the IntegrityError doesn't occur until the point of .save(), it's not obvious how that'd work in terms of the Forms API. You're absolutely correct that there's a class of constraints that can fail here, but it's not evident to me

Re: annoyance with Python 3.2 support in Django 1.8

2015-11-26 5:22 GMT+01:00 Asif Saifuddin : > Python 3.2 should be removed as if any one use py3 should use 3.3+ or > better the latest stable. > Hi Asif, Your email sounds like the answer is obvious. It doesn't show that you thought about the use cases, especially those you

Re: Allow impossible model validation (mainly admin and generic forms)

General flow for forms should develop to this: form = MyModelForm(data) if form.is_valid(): try: form.save() except ValidationError, error: form.add_error(None, error) else: return redirect('success') return render_failure(form) While handling such case in

Re: annoyance with Python 3.2 support in Django 1.8

Hi, Am Wed, 25 Nov 2015 16:36:52 -0800 (PST) schrieb Tim Graham : > b. Install the latest non-broken Python 3.2 release (3.2.5) > "manually" (without using deadsnakes) on the newer CI servers While it would only really hurt the people in charge with the bugfix releases, as

Re: annoyance with Python 3.2 support in Django 1.8

Hello Tim, Did you consider marking affected tests as expected failures on Python 3.2.6? I've done that on one of my projects which faced this exact issue (or a closely related one): https://github.com/aaugustin/myks-gallery/blob/master/gallery/test_admin.py#L199-L205 Best regards, --

Re: annoyance with Python 3.2 support in Django 1.8

The thing that makes me a little uncomfortable is promoting the use of possibly insecure Python 3.2 well after it's end-of-life. I guess there might be some Linux distributions that will backport security fixes to their own versions of Python 3.2, but it seems that Ubuntu 12.04's version of

Re: annoyance with Python 3.2 support in Django 1.8

> On Nov 26, 2015, at 9:50 AM, Tim Graham wrote: > > The thing that makes me a little uncomfortable is promoting the use of > possibly insecure Python 3.2 well after it's end-of-life. I guess there might > be some Linux distributions that will backport security fixes to

Code styling around URL in 404 pages shown with DEBUG = True

When you get a 404 with DEBUG = True the URL shown (look at the arrow in image below) isn't in a code box. Additionaly, it'd be helpful if the URL is root it shows (root directory) or something similar. ​ Asking for the OK before submitting as a feature request, thanks. -- You received this

Re: Code styling around URL in 404 pages shown with DEBUG = True

Hello James, This sounds reasonable. I would avoid using “root directory” to describe an URL because there isn’t usually a mapping between directories and URLs in Django projects. -- Aymeric. > On 26 nov. 2015, at 23:44, James Lu wrote: > > When you get a 404 with DEBUG