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
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
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
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:
>
>
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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 =
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
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
33 matches
Mail list logo