2005/10/24, Carlo C8E Miron <[EMAIL PROTECTED]>:
> A quick investigation
>
> 5)15:05:20 [EMAIL PROTECTED]:~/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 lit
2005/10/17, Adrian Holovaty <[EMAIL PROTECTED]>:
>
> On 10/17/05, Shaleh <[EMAIL PROTECTED]> 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
On 10/17/05, Shaleh <[EMAIL PROTECTED]> 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 definitio
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.
On 10/13/05, Andreas Stuhlmüller <[EMAIL PROTECTED]> 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
On 10/13/05, Andreas Stuhlmüller <[EMAIL PROTECTED]> 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
the habit of writing new-style classes. And I don't think there is
a reason for the other middlewares bein
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:
class MyCacheMiddleware(CacheMiddleware):
def process_request(self, request):
if check_request(request):
7 matches
Mail list logo
