Application specific middleware support

[Kapil Garg]

Hi, I am working on one django project and recently i had the requirement 
for a middleware. But i don't want this middleware to hook to every url 
served by the whole project but instead, only to one of the apps. I tried 
to look on the internet but everywhere there are hacks to implement it but 
not a in-built support from django. So i was curious why django doesn't 
provide support for app specific middleware or if it does then why there 
isn't any neat documentation about it. Thanks

-- 
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/1b8a2339-50fd-4b81-973f-9474787e3c6e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Kapil Garg]

The opened ticket is about Model.__str__ method. Should i open a new ticket
for this change ?
As i see in code, self.__class__ is used in a lot of places but will it
effect optimization if we change lookups from self.__class__ to self.cls

Because the methods where class is being used frequently, already store it
in local variable and then make references to local variable.

So should it really be changed ?

On Fri, Apr 7, 2017, 6:52 PM Marco Silva <marcosilva0...@gmail.com> wrote:

> I noticed this on the init
>
> def __init__(self, *args, **kwargs):
>  # Alias some things as locals to avoid repeat global lookups
>  cls = self.__class__
>
> maybe you should change it to self.cls??
> Try to submit a PR to the open ticket.
>
> segunda-feira, 3 de Abril de 2017 às 21:07:47 UTC+1, Kapil Garg escreveu:
>
> 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 <kapilg...@gmail.com> 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 <kapilg...@gmail.com> wrote:
>
> Ticket 27953 <https://code.djangoproject.com/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
> <https://groups.google.com/d/msgid/django-developers/c7254a96-7ee3-4262-a90b-83dcfe8fa3d4%40googlegroups.com?utm_medium=email_s

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 <kapilg...@gmail.com 
> > 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 <kapilg...@gmail.com> wrote:
>>>
>>>> Ticket 27953 <https://code.djangoproject.com/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
>>>>  
>>>> <https://groups.google.com/d/msgid/django-developers/c7254a96-7ee3-4262-a90b-83dcfe8fa3d4%40googlegroups.com?utm_medium=email_source=footer>
>>>> .
>>

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 <kapilg...@gmail.com 
> > wrote:
>
>> Ticket 27953 <https://code.djangoproject.com/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
>>  
>> <https://groups.google.com/d/msgid/django-developers/c7254a96-7ee3-4262-a90b-83dcfe8fa3d4%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> 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: Proposal: make Model __unicode__() default to self.name

[Kapil Garg]

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-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/c7254a96-7ee3-4262-a90b-83dcfe8fa3d4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.