Middleware Old-Style Classes
10 views
Skip to first unread message
Andreas Stuhlmüller
Oct 13, 2005, 4:08:22 AM10/13/05
to Django users
Is there a reason for the middleware being old-style classes? If
middleware was defined as Middleware(object) we could extend it like
this without modifying Django's source:
middleware was defined as Middleware(object) we could extend it like
this without modifying Django's source:
class MyCacheMiddleware(CacheMiddleware):
def process_request(self, request):
if check_request(request):
request._cache_update_cache = False
return None
return super(MyCacheMiddleware, self).process_request(request)
Andreas
Sune Kirkeby
Oct 13, 2005, 7:29:47 AM10/13/05
to django...@googlegroups.com
On 10/13/05, Andreas Stuhlmüller <and...@mindpicnic.com> wrote:
> Is there a reason for the middleware being old-style classes?
Speaking for my own code: No, there is no reason, I am just not in
> Is there a reason for the middleware being old-style classes?
the habit of writing new-style classes. And I don't think there is
a reason for the other middlewares being old-style either.
/s
Adrian Holovaty
Oct 13, 2005, 9:53:14 AM10/13/05
to django...@googlegroups.com
On 10/13/05, Andreas Stuhlmüller <and...@mindpicnic.com> wrote:
> Is there a reason for the middleware being old-style classes? If
> middleware was defined as Middleware(object) we could extend it like
> this without modifying Django's source:
Nope, no reason. Generally throughout the Django code, we use
> middleware was defined as Middleware(object) we could extend it like
> this without modifying Django's source:
new-style classes only when there's a specific need to do so -- like
when we want to use properties.
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.com | chicagocrime.org
Shaleh
Oct 17, 2005, 3:57:56 PM10/17/05
to Django users
Why is that? Moving forward the Python people expect all classes to be
defined as "new-style". Support for old-style is there simply to allow
for backwards compatibility.
defined as "new-style". Support for old-style is there simply to allow
for backwards compatibility.
Adrian Holovaty
Oct 17, 2005, 4:32:36 PM10/17/05
to django...@googlegroups.com
Carlo C8E Miron
Oct 24, 2005, 9:15:46 AM10/24/05
to django...@googlegroups.com
2005/10/17, Adrian Holovaty <holo...@gmail.com>:
5)15:05:20 eura@ac8er:~/src/django/svn/django/trunk/django
0$ grep -R "class[^(]*:" $(find . -name "*.py")|grep -v \.svn|wc -l
100
seems to reveal that there are only 100 old style classes on [1006].
Adrian are you interested in a patch about that trivial task?
--
Carlo C8E Miron, ICQ #26429731
--
Disclaimer:
If I receive a message from you, you are agreeing that:
1. I am by definition, "the intended recipient".
2. All information in the email is mine to do with as I see fit and
make such financial profit, political mileage, or good joke as it
lends itself to. In particular, I may quote it on USENET or the WWW.
3. I may take the contents as representing the views of your company.
4. This overrides any disclaimer or statement of confidentiality that
may be included on your message.
>
> On 10/17/05, Shaleh <sean....@xensource.com> wrote:
> > Why is that? Moving forward the Python people expect all classes to be
> > defined as "new-style". Support for old-style is there simply to allow
> > for backwards compatibility.
>
> Because we haven't taken the time to subclass "object" in class definitions?
A quick investigation
> On 10/17/05, Shaleh <sean....@xensource.com> wrote:
> > Why is that? Moving forward the Python people expect all classes to be
> > defined as "new-style". Support for old-style is there simply to allow
> > for backwards compatibility.
>
> Because we haven't taken the time to subclass "object" in class definitions?
5)15:05:20 eura@ac8er:~/src/django/svn/django/trunk/django
0$ grep -R "class[^(]*:" $(find . -name "*.py")|grep -v \.svn|wc -l
100
seems to reveal that there are only 100 old style classes on [1006].
Adrian are you interested in a patch about that trivial task?
--
Carlo C8E Miron, ICQ #26429731
--
Disclaimer:
If I receive a message from you, you are agreeing that:
1. I am by definition, "the intended recipient".
2. All information in the email is mine to do with as I see fit and
make such financial profit, political mileage, or good joke as it
lends itself to. In particular, I may quote it on USENET or the WWW.
3. I may take the contents as representing the views of your company.
4. This overrides any disclaimer or statement of confidentiality that
may be included on your message.
Carlo C8E Miron
Oct 24, 2005, 9:35:44 AM10/24/05
to django...@googlegroups.com
2005/10/24, Carlo C8E Miron <carlo...@gmail.com>:
0$ grep "^[[:space:]]*class[^(]*:" $(find . -name "*.py")|wc -l
84
reveals that the number is 84. Ant that there is only one
__metaclass__ assignation in ./core/meta/__init__.py
> A quick investigation
>
> 5)15:05:20 eura@ac8er:~/src/django/svn/django/trunk/django
> 0$ grep -R "class[^(]*:" $(find . -name "*.py")|grep -v \.svn|wc -l
> 100
>
> seems to reveal that there are only 100 old style classes on [1006].
A little less quick investigation ;)
>
> 5)15:05:20 eura@ac8er:~/src/django/svn/django/trunk/django
> 0$ grep -R "class[^(]*:" $(find . -name "*.py")|grep -v \.svn|wc -l
> 100
>
> seems to reveal that there are only 100 old style classes on [1006].
0$ grep "^[[:space:]]*class[^(]*:" $(find . -name "*.py")|wc -l
84
reveals that the number is 84. Ant that there is only one
__metaclass__ assignation in ./core/meta/__init__.py
Reply all
Reply to author
Forward
0 new messages