So does this patch seem fine ?
diff --git a/django/db/models/base.py b/django/db/models/base.py
index 3c1cb9a..f58e12b 100644
--- a/django/db/models/base.py
+++ b/django/db/models/base.py
@@ -504,7 +504,7 @@ class Model(metaclass=ModelBase):
return '<%s: %s>' % (self.__class__.__name__,
Refs: https://code.djangoproject.com/ticket/28015
Le lundi 3 avril 2017 13:35:15 UTC-4, ling-xi...@savoirfairelinux.com a
écrit :
>
> Hello,
>
> I browsed the archived emails on gettext "--add-location". The very
> original proposal was "--no-linenumbers" but it was finally implemented as
> it
I'd recommend not saying "unsaved". "new" if anything. UUID pk's may
default to generating a pk before save, so it might just be best to show
the actual current pk value
On Mon, Apr 3, 2017 at 1:06 PM, Kapil Garg wrote:
> So what should the final __str__ show: Should it
Hello,
I browsed the archived emails on gettext "--add-location". The very
original proposal was "--no-linenumbers" but it was finally implemented as
it is now. It doesn't seem to me, however, that there is much discussion on
this topic:
So what should the final __str__ show: Should it be 'ClassName object
pk=Something' and if pk is None then should it be 'ClassName object
(unsaved)' or 'ClassName object pk=None' ?
On Sunday, 2 April 2017 23:47:01 UTC+5:30, Collin Anderson wrote:
>
> Makes sense to me. Maybe still keep the
I think I proposed V as an alias back when I was writing the patch, but the
rough consensus at the time was that one letter class names are a bit of an
anti pattern (Q, F) that we shouldn't persist with. Aliasing V in the
examples was my way of sneaking the idea through for those who chose to
When writing filter expressions using database functions, one is often
forced to use django.db.models.Value to wrap raw values to avoid them being
interpreted as column references. Value is fairly cumbersome to write when
it can appear several times in a complex queryset definition, so it's
common
Hello David,
This reasoning makes sense.
You say that watchman "keeps triggering the command once an event occurs". This
is correct; as a consequence "the command" must stop the currently running
instance of the development server and start a new one. This requires
overhauling significantly