Re: Proposal: make Model __unicode__() default to self.name

[Kapil Garg]

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__, u)
 
 def __str__(self):
-return '%s object' % self.__class__.__name__
+return '%s object pk=%s' % (self.__class__.__name__, 
self._get_pk_val())
 
 def __eq__(self, other):
 if not isinstance(other, Model):




On Monday, 3 April 2017 23:07:56 UTC+5:30, Collin Anderson wrote:
>
> 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 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 "Transaction object" part, and 
>>> use None if no pk.
>>>
>>> On Sun, Apr 2, 2017 at 11:09 AM, Kapil Garg  wrote:
>>>
 Ticket 27953  is 
 regarding this proposal and the suggestion is about adding "pk" in Model 
 string representation if it exists. 

 On Thursday, 11 July 2013 09:16:25 UTC+5:30, Collin Anderson wrote:
>
> Hi All,
>
> Have you ever quickly set up a model, ran syncdb, and added a few 
> sample objects in the admin to only see a bunch of "MyModel object"s in 
> the 
> changelist? I always forget to add a __unicode__()/__str__() method on my 
> models.
>
> I ran "git grep -1 __unicode__" on some of my django projects and 
> noticed a lot of repeated code. In fact, it seems that in about a _third_ 
> of all my cases, I'm just returning self.name, or returning self.name 
> would have been a good default. I looked at a few 3rd party apps for 
> comparison and found similar results, though not for every app.
>
> IMHO, returning self.name (if the field or property exists) is a 
> sensible default for __unicode__. We can still return "MyModel object" if 
> there's no "name" attribute. You'll still end up adding your own 
> __unicode__ method much of the time, just like you always have.
>
> Yes, it's "magic", but we can document it.
> Yes, it's a little more confusing, but we don't have to explain it 
> during the tutorial.
> Yes, it's backwards incompatible, but only in rare cases should it be 
> a problem.
> Yes, it could look like any Model without a "name" field is "wrong", 
> but it's not.
> Yes, "title" is also very popular, but name is better. :)
>
> It has the effect of being a little more friendly in many cases, and 
> can result in more DRY code.
>
> What do your __unicode__/__str__ methods look like? Is this a bad idea?
>
> Thanks,
> Collin
>
> -- 
 You received this message because you are subscribed to the Google 
 Groups "Django developers (Contributions to Django itself)" group.
 To unsubscribe from this group and stop receiving emails from it, send 
 an email to django-develop...@googlegroups.com.
 To post to this group, send email to django-d...@googlegroups.com.
 Visit this group at https://groups.google.com/group/django-developers.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/django-developers/c7254a96-7ee3-4262-a90b-83dcfe8fa3d4%40googlegroups.com
  
 
 .
 For more options, visit https://groups.google.com/d/optout.

>>>
>>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@googlegroups.com 
>> .
>> Visit this group at https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/1a84fb1c-522f-4bc4-b214-0831a63f13ae%40googlegroups.com
>>  
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe 

Re: Feature request: django.py makemessages --add-location=full|file|never

[ling-xiao . yang]

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 is now. It doesn't seem to me, however, that there is much discussion on 
> this topic:
>
>
> https://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=--no-linenumbers=Search%21=bug-gettext=20=normal=date%3Aearly
>
> Perhaps I'll just follow what gettext has done, as it might be easier for 
> someone who already has experience with gettext utilities. I think we may 
> let Django take both "--no-location" and "--add-location=...", and simply 
> let gettext decide which one overrides. 
>
> How do you think?
>
>
> Le mercredi 29 mars 2017 03:03:52 UTC-4, HM a écrit :
>>
>> Since no flag equals "full" and "--no-location" equals "never" maybe a 
>> new flag "--file-location" for "file" instead of "--add-location" for 
>> all three? 
>>
>> On 27 March 2017 at 23:55, Adam Johnson  wrote: 
>> > I don't see any reason against adding it. If there isn't a ticket 
>> already, 
>> > you can make one at https://code.djangoproject.com/ , then look at the 
>> > extensive contributing guide. 
>> > 
>> > On 27 March 2017 at 19:26,  wrote: 
>> >> 
>> >> Hello there, 
>> >> 
>> >> Please let me know if it is a duplicate. I would like to propose the 
>> >> support of `--add-location` of `xgettext` in Django makemessages, in 
>> order 
>> >> to provide a fine-grain control of the metadata of .po files. 
>> >> 
>> >> At present, Django makemessages support `--no-location` to completely 
>> >> suppress the `#: file:line` lines. 
>> >> 
>> >> Quote from https://www.gnu.org/software/gettext/manual/gettext.html: 
>> >> 
>> >>> ‘--add-location=type’ 
>> >>> 
>> >>> Generate ‘#: filename:line’ lines (default). 
>> >>> 
>> >>> The optional type can be either ‘full’, ‘file’, or ‘never’. If it is 
>> not 
>> >>> given or ‘full’, it generates the lines with both file name and line 
>> number. 
>> >>> If it is ‘file’, the line number part is omitted. If it is ‘never’, 
>> it 
>> >>> completely suppresses the lines (same as --no-location). 
>> >> 
>> >> 
>> >> 
>> >> After consulting the Git history of GNU gettext on Savannah, I found 
>> it 
>> >> added in March 2014: 
>> >> 
>> >> 
>> >>> commit 90c76fda268779b80c2fa969b8efddbb4aa5da1e 
>> >>> Author: Daiki Ueno  
>> >>> Date:   Mon Mar 24 18:43:01 2014 +0900 
>> >>> 
>> >>> Extend --add-location option to suppress line number output 
>> >>> 
>> >>> The --add-location option of msgattrib, msgcat, msgcomm, msgconv, 
>> >>> msgen, msgfilter, msggrep, msgmerge, msguniq, and xgettext 
>> >>> commands now takes an optional argument 'never', 'full', or 
>> >>> 'file', to control the format of "#: ..."  comments. 
>> >>> 
>> >>> The default catalog reader changed to always remember file 
>> >>> positions so the line number part can be suppressed in output 
>> >>> phase rather than input phase. 
>> >>> 
>> >> 
>> >> 
>> >> Why adding this: it will help a lot the version control of .po files. 
>> It 
>> >> will exclude many noises that can simply be triggered by a line 
>> >> addition/deletion. By keeping file names but not line numbers, this 
>> would be 
>> >> a good compromise between developers who find this metadata noisy and 
>> >> translators who may rely on this information. 
>> >> 
>> >> Please kindly comment. Thank you! 
>> >> 
>> >> -- 
>> >> You received this message because you are subscribed to the Google 
>> Groups 
>> >> "Django developers (Contributions to Django itself)" group. 
>> >> To unsubscribe from this group and stop receiving emails from it, send 
>> an 
>> >> email to django-develop...@googlegroups.com. 
>> >> To post to this group, send email to django-d...@googlegroups.com. 
>> >> Visit this group at https://groups.google.com/group/django-developers. 
>>
>> >> To view this discussion on the web visit 
>> >> 
>> https://groups.google.com/d/msgid/django-developers/f0405b21-aee9-415a-9772-296353678da6%40googlegroups.com.
>>  
>>
>> >> For more options, visit https://groups.google.com/d/optout. 
>> > 
>> > 
>> > 
>> > 
>> > -- 
>> > Adam 
>> > 
>> > -- 
>> > You received this message because you are subscribed to the Google 
>> Groups 
>> > "Django developers (Contributions to Django itself)" group. 
>> > To unsubscribe from this group and stop receiving emails from it, send 
>> an 
>> > email to django-develop...@googlegroups.com. 
>> > To post to this group, send email to django-d...@googlegroups.com. 
>> > Visit this group at https://groups.google.com/group/django-developers. 
>> > To view this discussion on the web visit 
>> > 
>> https://groups.google.com/d/msgid/django-developers/CAMyDDM2evqjYeU_%3DMqRxTNjfqeOkS3sStdSVbBR6VxcEZ3k30w%40mail.gmail.com.
>>  
>>
>> > 
>> > For more options, visit 

Re: Proposal: make Model __unicode__() default to self.name

[Collin Anderson]

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 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 "Transaction object" part, and
>> use None if no pk.
>>
>> On Sun, Apr 2, 2017 at 11:09 AM, Kapil Garg  wrote:
>>
>>> Ticket 27953  is regarding
>>> this proposal and the suggestion is about adding "pk" in Model string
>>> representation if it exists.
>>>
>>> On Thursday, 11 July 2013 09:16:25 UTC+5:30, Collin Anderson wrote:

 Hi All,

 Have you ever quickly set up a model, ran syncdb, and added a few
 sample objects in the admin to only see a bunch of "MyModel object"s in the
 changelist? I always forget to add a __unicode__()/__str__() method on my
 models.

 I ran "git grep -1 __unicode__" on some of my django projects and
 noticed a lot of repeated code. In fact, it seems that in about a _third_
 of all my cases, I'm just returning self.name, or returning self.name
 would have been a good default. I looked at a few 3rd party apps for
 comparison and found similar results, though not for every app.

 IMHO, returning self.name (if the field or property exists) is a
 sensible default for __unicode__. We can still return "MyModel object" if
 there's no "name" attribute. You'll still end up adding your own
 __unicode__ method much of the time, just like you always have.

 Yes, it's "magic", but we can document it.
 Yes, it's a little more confusing, but we don't have to explain it
 during the tutorial.
 Yes, it's backwards incompatible, but only in rare cases should it be a
 problem.
 Yes, it could look like any Model without a "name" field is "wrong",
 but it's not.
 Yes, "title" is also very popular, but name is better. :)

 It has the effect of being a little more friendly in many cases, and
 can result in more DRY code.

 What do your __unicode__/__str__ methods look like? Is this a bad idea?

 Thanks,
 Collin

 --
>>> You received this message because you are subscribed to the Google
>>> Groups "Django developers (Contributions to Django itself)" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to django-develop...@googlegroups.com.
>>> To post to this group, send email to django-d...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit https://groups.google.com/d/ms
>>> gid/django-developers/c7254a96-7ee3-4262-a90b-83dcfe8fa3d4%
>>> 40googlegroups.com
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-developers/1a84fb1c-522f-4bc4-b214-
> 0831a63f13ae%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFO84S76_%3DB_7kuLj0DbXZ%2BZw78J7nGWdKnGM57qFtEVDb4BfA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature request: django.py makemessages --add-location=full|file|never

[ling-xiao . yang]

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:

https://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=--no-linenumbers=Search%21=bug-gettext=20=normal=date%3Aearly

Perhaps I'll just follow what gettext has done, as it might be easier for 
someone who already has experience with gettext utilities. I think we may 
let Django take both "--no-location" and "--add-location=...", and simply 
let gettext decide which one overrides. 

How do you think?


Le mercredi 29 mars 2017 03:03:52 UTC-4, HM a écrit :
>
> Since no flag equals "full" and "--no-location" equals "never" maybe a 
> new flag "--file-location" for "file" instead of "--add-location" for 
> all three? 
>
> On 27 March 2017 at 23:55, Adam Johnson  
> wrote: 
> > I don't see any reason against adding it. If there isn't a ticket 
> already, 
> > you can make one at https://code.djangoproject.com/ , then look at the 
> > extensive contributing guide. 
> > 
> > On 27 March 2017 at 19:26,  > wrote: 
> >> 
> >> Hello there, 
> >> 
> >> Please let me know if it is a duplicate. I would like to propose the 
> >> support of `--add-location` of `xgettext` in Django makemessages, in 
> order 
> >> to provide a fine-grain control of the metadata of .po files. 
> >> 
> >> At present, Django makemessages support `--no-location` to completely 
> >> suppress the `#: file:line` lines. 
> >> 
> >> Quote from https://www.gnu.org/software/gettext/manual/gettext.html: 
> >> 
> >>> ‘--add-location=type’ 
> >>> 
> >>> Generate ‘#: filename:line’ lines (default). 
> >>> 
> >>> The optional type can be either ‘full’, ‘file’, or ‘never’. If it is 
> not 
> >>> given or ‘full’, it generates the lines with both file name and line 
> number. 
> >>> If it is ‘file’, the line number part is omitted. If it is ‘never’, it 
> >>> completely suppresses the lines (same as --no-location). 
> >> 
> >> 
> >> 
> >> After consulting the Git history of GNU gettext on Savannah, I found it 
> >> added in March 2014: 
> >> 
> >> 
> >>> commit 90c76fda268779b80c2fa969b8efddbb4aa5da1e 
> >>> Author: Daiki Ueno  
> >>> Date:   Mon Mar 24 18:43:01 2014 +0900 
> >>> 
> >>> Extend --add-location option to suppress line number output 
> >>> 
> >>> The --add-location option of msgattrib, msgcat, msgcomm, msgconv, 
> >>> msgen, msgfilter, msggrep, msgmerge, msguniq, and xgettext 
> >>> commands now takes an optional argument 'never', 'full', or 
> >>> 'file', to control the format of "#: ..."  comments. 
> >>> 
> >>> The default catalog reader changed to always remember file 
> >>> positions so the line number part can be suppressed in output 
> >>> phase rather than input phase. 
> >>> 
> >> 
> >> 
> >> Why adding this: it will help a lot the version control of .po files. 
> It 
> >> will exclude many noises that can simply be triggered by a line 
> >> addition/deletion. By keeping file names but not line numbers, this 
> would be 
> >> a good compromise between developers who find this metadata noisy and 
> >> translators who may rely on this information. 
> >> 
> >> Please kindly comment. Thank you! 
> >> 
> >> -- 
> >> You received this message because you are subscribed to the Google 
> Groups 
> >> "Django developers (Contributions to Django itself)" group. 
> >> To unsubscribe from this group and stop receiving emails from it, send 
> an 
> >> email to django-develop...@googlegroups.com . 
> >> To post to this group, send email to django-d...@googlegroups.com 
> . 
> >> Visit this group at https://groups.google.com/group/django-developers. 
> >> To view this discussion on the web visit 
> >> 
> https://groups.google.com/d/msgid/django-developers/f0405b21-aee9-415a-9772-296353678da6%40googlegroups.com.
>  
>
> >> For more options, visit https://groups.google.com/d/optout. 
> > 
> > 
> > 
> > 
> > -- 
> > Adam 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups 
> > "Django developers (Contributions to Django itself)" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an 
> > email to django-develop...@googlegroups.com . 
> > To post to this group, send email to django-d...@googlegroups.com 
> . 
> > Visit this group at https://groups.google.com/group/django-developers. 
> > To view this discussion on the web visit 
> > 
> https://groups.google.com/d/msgid/django-developers/CAMyDDM2evqjYeU_%3DMqRxTNjfqeOkS3sStdSVbBR6VxcEZ3k30w%40mail.gmail.com.
>  
>
> > 
> > For more options, visit https://groups.google.com/d/optout. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 

Re: Proposal: make Model __unicode__() default to self.name

[Kapil Garg]

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 "Transaction object" part, and use 
> None if no pk.
>
> On Sun, Apr 2, 2017 at 11:09 AM, Kapil Garg  > wrote:
>
>> Ticket 27953  is regarding 
>> this proposal and the suggestion is about adding "pk" in Model string 
>> representation if it exists. 
>>
>> On Thursday, 11 July 2013 09:16:25 UTC+5:30, Collin Anderson wrote:
>>>
>>> Hi All,
>>>
>>> Have you ever quickly set up a model, ran syncdb, and added a few sample 
>>> objects in the admin to only see a bunch of "MyModel object"s in the 
>>> changelist? I always forget to add a __unicode__()/__str__() method on my 
>>> models.
>>>
>>> I ran "git grep -1 __unicode__" on some of my django projects and 
>>> noticed a lot of repeated code. In fact, it seems that in about a _third_ 
>>> of all my cases, I'm just returning self.name, or returning self.name 
>>> would have been a good default. I looked at a few 3rd party apps for 
>>> comparison and found similar results, though not for every app.
>>>
>>> IMHO, returning self.name (if the field or property exists) is a 
>>> sensible default for __unicode__. We can still return "MyModel object" if 
>>> there's no "name" attribute. You'll still end up adding your own 
>>> __unicode__ method much of the time, just like you always have.
>>>
>>> Yes, it's "magic", but we can document it.
>>> Yes, it's a little more confusing, but we don't have to explain it 
>>> during the tutorial.
>>> Yes, it's backwards incompatible, but only in rare cases should it be a 
>>> problem.
>>> Yes, it could look like any Model without a "name" field is "wrong", but 
>>> it's not.
>>> Yes, "title" is also very popular, but name is better. :)
>>>
>>> It has the effect of being a little more friendly in many cases, and can 
>>> result in more DRY code.
>>>
>>> What do your __unicode__/__str__ methods look like? Is this a bad idea?
>>>
>>> Thanks,
>>> Collin
>>>
>>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@googlegroups.com 
>> .
>> Visit this group at https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/c7254a96-7ee3-4262-a90b-83dcfe8fa3d4%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1a84fb1c-522f-4bc4-b214-0831a63f13ae%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Provide 'V' as alias for 'Value'?

[Josh Smeaton]

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 act 
similarly. I'd be ok with providing an alias, but I think examples should 
still import the Value name to make the code more clear what V actually 
refers to. 

On Monday, 3 April 2017 17:58:43 UTC+10, Adam Johnson wrote:
>
> 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 to alias it as V when importing. In fact, the database 
> function docs do this exclusively 
> .
>
> Because import as is sometimes considered bad style, but the V alias is 
> useful, I'd like to propose django.db.models having a documented internal 
> alias like V = Value. I'm writing here because I can't think of a 
> precedent in Django, except for backwards compatibility reasons.
>
> -- 
> Adam
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1e4d267e-7441-489f-a2ac-c23f34cd246c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Provide 'V' as alias for 'Value'?

[Adam Johnson]

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 to alias it as V when importing. In fact, the database function docs do
this exclusively
.

Because import as is sometimes considered bad style, but the V alias is
useful, I'd like to propose django.db.models having a documented internal
alias like V = Value. I'm writing here because I can't think of a precedent
in Django, except for backwards compatibility reasons.

-- 
Adam

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM1v%3D4DH0bMccPpJNjd%2BCQ5UACBxnLO14bd0a7QQBfuv6g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: A proposal for a new auto-reloader in Django

[Aymeric Augustin]

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 the current implementation of the development server.

You need to understand the two-process structure of the current autoreloader 
and the workarounds for allowing runserver to start with invalid settings to 
get a good grasp on the requirements for a good developer experience. I hope we 
can do away with these workarounds with a better architecture.

Best regards,

-- 
Aymeric.



> On 3 Apr 2017, at 03:36, qingnian...@gmail.com wrote:
> 
> Hi Aymeric,
>   I feel like using Watchman might be the easiest solution. It keeps 
> triggering the command once an event occurs, so autoreload.py does not need 
> to restart the server in case of a syntax error. Pywatchman does not work on 
> Python 3 and has some dependency problems, so I'm planning to use the command 
> line interface of the Watchman library. Watchdog only triggers the given 
> command once, so it cannot survive a syntax error and requires the 
> auto-reloader to deal with multi-threading, the most challenging part in this 
> project (likely to enter the same problem described in #2330 
> .) Therefore, I'd start with 
> Watchman and see how to implement this with Watchdog later. How do you feel 
> about this plan? 
> 
> Cheers,
> David Ma
> 
> On Sunday, April 2, 2017 at 6:33:38 AM UTC-7, Aymeric Augustin wrote:
> Hello,
> 
> On 1 Apr 2017, at 05:52, qingn...@gmail.com  wrote:
> 
>> For the pure-Python solution, I might implement a standalone autoreloader 
>> based on Carl's work and replace the current one. Does this look good to you?
> 
> 
> Perhaps.
> 
> It depends on the details (features, installation requirements, cross 
> platform support, etc.).
> 
> It's up to you to argument in your proposal why this would be a good solution.
> 
> Best regards,
> 
> -- 
> Aymeric.
> 
> 
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com 
> .
> To post to this group, send email to django-developers@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/django-developers 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/3c284301-15e9-44d9-9b7c-2d866b7f7d13%40googlegroups.com
>  
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/E4AB822D-B4FF-44CD-972C-DBB3CCD6EC22%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.