Decoration of class based views

Hello I would like to ask why the class based views documentation seems so much ugly. Some developers probably are scared by these just because the decoration is ugly, the documentation offers three ways: Decorate the *Klass().dispach()* method of the class, wrapping the decorators in another

#25227 Add utility method `get_updated_model()` to `ModelForm`

Hi, I'm the author of Ticket #25227 Add utility method `get_updated_model()` to `ModelForm` and its accompanying patch. Ticket: https://code.djangoproject.com/ticket/25227 Patch: https://github.com/django/django/pull/5105 Here's the writeup to save everyone a click: Add utility method

Re: Unable save model in admin with HStoreField

There is no need to cross-post to the mailing list when you also created a ticket: https://code.djangoproject.com/ticket/25233 "Is this a bug?" questions should go to the django-users mailing list. Thanks! On Thursday, August 6, 2015 at 7:21:36 AM UTC-4, Doan Hong Phi wrote: > > f =

Re: Decoration of class based views

A few days ago, we added the ability to use @method_decorator at the class level: https://github.com/django/django/commit/3bdaaf6777804d33ee46cdb5a889b8cc544a91f1 Does it help? Is your proposal to add the reduce() syntax to the docs? On Thursday, August 6, 2015 at 7:21:36 AM UTC-4, Fabrizio

Re: How to disable system check framework?

Perhaps your monkeypatches should be moved to `AppConfig.ready()` methods so they are applied before the system check framework is invoked? Model and admin validation were part of Django 1.4 too, by the way. How many problematic checks are you running into? Can you describe them a bit more? If

Re: #25227 Add utility method `get_updated_model()` to `ModelForm`

Discouraging the use of super() seems like a bad idea that could limit flexibility in the future. I think Django's documentation describes the behavior pretty well. Perhaps the Django Girls tutorial could be improved instead. I don't recall having trouble understanding how this worked when I

Re: Help needed with Oracle GIS backend

As we approach 1.9 alpha in about a month and half, no one has stepped up to offer help fix the Oracle GIS backend. Should we use another platform like the djangoproject.com blog to make a final plea for help? On Monday, March 30, 2015 at 9:34:10 AM UTC-4, Jani Tiainen wrote: > > On Thu, 26 Mar

Ticket #25236: Remove ifequal from the template language

No modern project uses ifequal. No one recommends it. I argue it is taking up valuable bytes in the project. Let's remove it. Reference https://code.djangoproject.com/ticket/25236 In there you'll see Tim Graham mentions that older Django projects may push back on it, and suggests that a good

Re: Ticket #25236: Remove ifequal from the template language

I commented on the ticket - it's been redundant since Django 1.2 when the smart if was introduced. +1 to deprecating it. On 6 August 2015 at 17:15, Daniel Greenfeld wrote: > No modern project uses ifequal. No one recommends it. I argue it is taking > up valuable bytes in the

Re: Ticket #25236: Remove ifequal from the template language

Also +1 for its removal. And ifnotequal, too, since nobody seems to have mentioned this yet. I would imagine a simple regex find-and-replace very much enough to fix most problems this causes. And if someone *really* want those tags, it is also pretty trivial to just pull them into a

Re: Ticket #25236: Remove ifequal from the template language

On Thu, Aug 6, 2015 at 12:15 PM, Daniel Greenfeld wrote: > No modern project uses ifequal. No one recommends it. I argue it is taking > up valuable bytes in the project. Let's remove it. > I maintain (did not write) a project written last year that has ifequal and ifnotequal.

Re: #25227 Add utility method `get_updated_model()` to `ModelForm`

On Friday, 7 August 2015 01:57:46 UTC+10, Tim Graham wrote: > > Discouraging the use of super() seems like a bad idea that could limit > flexibility in the future. > Fair enough, but I'm not discouraging the use of super(). As I point out in the ticket, the recommended pattern already ignores

Re: future of QuerySet.extra()?

I've seen *extra()* misused in cases where developers came from a background of writing raw SQL and then used it rather than figuring out the (often relatively simple) ORM way of doing it. This is then a big maintenance burden, and the harsher warning against its use is a good idea. Also

Re: Ticket #25236: Remove ifequal from the template language

ifequal is technical debt in Django. It's a legacy way of doing things which we would not add now. Sure, we don't have to remove it, it isn't blocking us from doing anything else and it isn't broken, and it doesn't need much maintenance. However, as with all technical debt, it has a cost. It's

Re: #25227 Add utility method `get_updated_model()` to `ModelForm`

I agree that this is an anitpattern. I'm not fond of `get_updated_instance()` as a name, I'm not sure what the correct option is here. Arguably we should split save() into two parts - ModelForm.update_instance() and ModelForm.commit(). ModelForm.save() simply calls these two functions, with the

Re: #25227 Add utility method `get_updated_model()` to `ModelForm`

On Friday, 7 August 2015 07:19:01 UTC+10, Marc Tamlyn wrote: > > I agree that this is an anitpattern. I'm not fond of > `get_updated_instance()` as a name, I'm not sure what the correct option is > here. Arguably we should split save() into two parts - > ModelForm.update_instance() and

Re: #25227 Add utility method `get_updated_model()` to `ModelForm`

I took a look at the code, found a bug, and proposed some simplifications in https://github.com/django/django/pull/5111 The simplifications help make it clearer what get_updated_model() would do in the usual case: 1. Throw an error if the form has any errors: "The model could not be changed

Re: #25227 Add utility method `get_updated_model()` to `ModelForm`

On Friday, 7 August 2015 08:38:33 UTC+10, Tim Graham wrote: > > I took a look at the code, found a bug, and proposed some simplifications > in https://github.com/django/django/pull/5111 > Thanks, will check. The simplifications help make it clearer what get_updated_model() would do > in the

Re: #25227 Add utility method `get_updated_model()` to `ModelForm`

What I said on the tracker for #25241: Thanks for this. You're cleaning here a lot of of cruft that I left in my own #25227 because I didn't know whether it was used from other parts of Django. I assume this [#25241] is as good as merged. I'll rebase my patch on your one before continuing

Re: #25227 Add utility method `get_updated_model()` to `ModelForm`

I don't think 'get_model()' makes it any more obvious about the two things that happen as compared to the name 'super().save(commit=False)'. If we reevaluate as to whether super().save(commit=False) is needed at all, I think the forms.errors check isn't of much value (you will only hit that if

Re: #25227 Add utility method `get_updated_model()` to `ModelForm`

Hi, Tim, Thanks for taking the time to address my ticket and patch. At this point I'm aware that I might be doing this just to practice writing well-formed contributions to Django. At the very least I'll have learnt a lot about how Django works on the inside, both the code and the project.

Re: Keeping apps without migrations?

With the alpha for 1.9 coming up in 6 weeks, we need to decide whether or not to continue support for apps without migrations (currently in master no tables are created for such apps (as the deprecation timeline says), but it might be appropriate to add a warning or error message for this case

Re: #25227 Add utility method `get_updated_model()` to `ModelForm`

That sounds like a more promising proposal in my mind. So in a view instead of: if form.is_valid(): obj = form.save(commit=False) obj.author = request.user obj.save() form.save_m2m() it might look like: if form.is_valid(): form.instance.author = request.user form.save() I'm

Re: Ticket #25236: Remove ifequal from the template language

Let me open by saying I am in no way averse to the removal of these two tags... and this reminds me I need to also re-work my "remove the 'x as y' argument syntax" patch again... On 7 August 2015 at 07:08, Marc Tamlyn wrote: > However, as with all technical debt, it has a

Re: Keeping apps without migrations?

Do we know exactly what "support for apps without migrations" would consist of at this point? I have that half-done code for replicating syncdb with the autodetector stuck onto the migration executor, but it's not especially speedy and would need some work to make it a sensible speed before it

Re: #25227 Add utility method `get_updated_model()` to `ModelForm`

Just my $0.02... I quite like the idea of adding update_instance and commit, with save calling both... To me, this provides a clean and obvious place to customise updating the instance before saving... as well as a clear place to get an updated instance without saving. -- Curtis On 7 August

Re: Ticket #25236: Remove ifequal from the template language

Believe me I understand what technical debt is. In my opinion the cost of this debt in Django is not sufficient to warrant the cost to users of Django to remove it. Find and fix (or figure out if it's necessary to fix) all templates (some of which may be coming from 3rd party packages) used in a

Re: Keeping apps without migrations?

Instead of rushing to a decision if and of how we continue to support "apps w/o migrations" I would argue that, since Django's test suite does infact create tables for apps w/o migrations, we could add a commandline flag (e.g. --run-syncdb or whatever) to the migrate command and warn the user if

Re: Ticket #25236: Remove ifequal from the template language

Given the [currently] low burden, I agree with a more gradual deprecation... document against their use to help encourage people to move away from them, then we're in a better position to more painlessly remove them in the future. -- Curtis On 7 August 2015 at 11:43, Karen Tracey

Re: Ticket #25236: Remove ifequal from the template language

Can we just push the ifequal type tags through regular deprecation? As mentioned, the cost of maintaining the tags is extremely low. Remove the ifequal tags from the docs, document their deprecation, and remove in Django 2.0. On Friday, 7 August 2015 11:56:29 UTC+10, Curtis Maloney wrote: > >

Re: Ticket #25236: Remove ifequal from the template language

We certainly weren't discussing removing without deprecating, were we? I'm saying removing isn't worth the hassle to users, period. My opinion from working on a fair number of inherited sites, plus sites where I don't get to choose who contributes code I'm responsible for maintaining. I've

Re: Ticket #25236: Remove ifequal from the template language

Fair enough, I don't necessarily disagree with you. Would removing the documentation for ifequal be OK? At least that would prevent new projects from using it or being confused about multiple ways to compare values. On Friday, 7 August 2015 12:49:37 UTC+10, Karen Tracey wrote: > > We certainly

Re: Ticket #25236: Remove ifequal from the template language

I'd probably go with updating the documentation to say they're legacy tags, you're better off using {% if %} now, and warn they may be removed in a later release. This way (a) people are warned off it, and (b) we're confusing people who find it and want to check what it does [even though it's