The nginx documentation points to a reason:
https://nginx.org/en/docs/http/ngx_http_core_module.html#merge_slashes
Note that compression is essential for the correct matching of prefix
> string and regular expression locations. Without it, the
> “//scripts/one.php” request would not match
>
>
Hi Adam,
APPEND_SLASH only adds a slash at the end of the path
I'm more concerned about having multiple slashes in the middle of the path
I get your point about canonical URLs - I'm just confused why other major
HTTP servers are handling this different
On Wednesday, 4 March 2020 14:27:19 UTC-5,
I'd be against this
Merging multiple slashes is a way of duplicating canonical URL's for
things, something Django actively tries to avoid with APPEND_SLASHES.
If you want this functionality you should be able to create it yourself
with a custom URL converter or URLPattern subclass.
On Wed, 4 Mar
Hi,
I'd like to start a discussion about how django handles multiple slashes.
see: https://code.djangoproject.com/ticket/31319#comment:1
So far I can confirm that nginx, apache and unix folders handle multiple
slashes the same way (-> they get merged)
What's your (dev) opinion on this?
Cheers
B
ranch after 1.9 alpha around September 21). In the meantime, if you want
>> take a look for some simpler tickets to tackle to get a feel for our
>> contribution process, I think that would be helpful.
>>
>> On Tuesday, August 25, 2015 at 2:25:07 PM UTC-4, James Addison wrote:
ay, August 25, 2015 at 2:25:07 PM UTC-4, James Addison wrote:
>>
>> In the interests of keeping the excellent work done by Marten Kenbeek
>> (knbk on IRC/Github) on the GSOC 2015 URL Dispatcher project [1] current
>> and moving along, I've created a new branch [2]
some simpler tickets to tackle to get a feel for our contribution
process, I think that would be helpful.
On Tuesday, August 25, 2015 at 2:25:07 PM UTC-4, James Addison wrote:
>
> In the interests of keeping the excellent work done by Marten Kenbeek
> (knbk on IRC/Github) on the
In the interests of keeping the excellent work done by Marten Kenbeek (knbk
on IRC/Github) on the GSOC 2015 URL Dispatcher project [1] current and
moving along, I've created a new branch [2] and rebased it against current
master. (I am doing this because it seems like Marten is no longer
You would have to take a look at the pull request and figure out the
status. As far as I know, there aren't any status updates elsewhere.
On Monday, August 24, 2015 at 11:52:49 AM UTC-4, James Addison wrote:
>
> Assuming
> https://www.google-melange.com/gsoc/project/details/google/gsoc2015/knbk/
Assuming
https://www.google-melange.com/gsoc/project/details/google/gsoc2015/knbk/5668600916475904
is the canonical source for the project details, what is the status of each
of its goals? From a high level, the project seems well described on that
page, but everything after (ie. status) seems
I don't think so. Marten has been MIA unfortunately. Someone else could try
to pick it up, but it seems a bit ambitious to complete in the time
remaining before alpha.
On Monday, August 24, 2015 at 10:02:38 AM UTC-4, James Addison wrote:
>
> Hi Marten,
>
> I'm just curious if this is still on tr
Hi Marten,
I'm just curious if this is still on track for inclusion within the Sept 21
Apha feature deadline? I've been using your Django `dispatcher_api` branch
for a new project since I learned of your proposed changes and am excited
to see them in stable Django. There hasn't been any changes
+100 for django.urls. resolving and reversing functions should be located
in the same namespace.
M
On 10 Jul 2015 15:55, "Marten Kenbeek" wrote:
> Hi James,
>
> Thanks for taking a look at this, I really appreciate it.
>
> *Major bug:* the `request` object needs to be passed into `resolve()`
>>
Hi James,
Thanks for taking a look at this, I really appreciate it.
*Major bug:* the `request` object needs to be passed into `resolve()` here:
> https://github.com/knbk/django/blob/4a9d2a05bb76c9ad996921b9efadd8dad877540e/django/core/handlers/base.py#L134
>
> - otherwise host and scheme cons
Marten, did you consider putting the new API in `django.urls` instead of
`django.core.urls`? I don't need there's a need to namespace it under
"core", but others might be able to confirm the philosophy behind this.
On Thursday, July 9, 2015 at 7:19:11 AM UTC-4, James Addison wrote:
>
> Marten,
>
Marten,
Using your *dispatcher_api* branch, I found a few issues - I believe this
is an acceptable place to post them. My apologies if this is not the case.
My use case is this: Using a single Django codebase, I plan to have
www.example.com and my.example.com. 'my' will be https, while 'www' wi
nt API?
>
>
> Domain-based resolving, for one. Another, non-obvious advantage is that a
> Resolver subclass can dynamically resolve or reverse patterns. A lot of
> apps (think flatpages, a CMS, or the sitemaps app) have a semi-static set
> of urls. The current approaches are li
rns. A lot of
apps (think flatpages, a CMS, or the sitemaps app) have a semi-static set
of urls. The current approaches are limited to a catch-all pattern that
further resolves in the view, or a static url for each option. The first
approach has the obvious disadvantage that it can only ever b
gt;
> - Anssi
>
>
> On Monday, May 4, 2015, Marten Kenbeek wrote:
>
>> Hi all,
>>
>> I'd like to discuss the API I'm proposing for the new url dispatcher I'm
>> working on. I'll try to explain the API and some of the rationale behind it.
scuss the API I'm proposing for the new url dispatcher I'm
> working on. I'll try to explain the API and some of the rationale behind it.
>
> There is a working proof-of-concept at
> https://github.com/knbk/django/tree/url_dispatcher. Currently, all the
> names are chosen
5, at 23:04, Carl Meyer wrote:
>
> Hi Marten,
>
> On 05/04/2015 01:45 PM, Marten Kenbeek wrote:
>> I'd like to discuss the API I'm proposing for the new url dispatcher I'm
>> working on. I'll try to explain the API and some of the rationale behind it
Hi Marten,
On 05/04/2015 01:45 PM, Marten Kenbeek wrote:
> I'd like to discuss the API I'm proposing for the new url dispatcher I'm
> working on. I'll try to explain the API and some of the rationale behind it.
Thanks for seeking comment early, and providing working P
Hi all,
I'd like to discuss the API I'm proposing for the new url dispatcher I'm
working on. I'll try to explain the API and some of the rationale behind it.
There is a working proof-of-concept
at https://github.com/knbk/django/tree/url_dispatcher. Currently, all the
nam
create a separate thread for those.
Thanks,
Marten
Op maandag 2 maart 2015 17:57:24 UTC+1 schreef Marten Kenbeek:
>
> Hey all,
>
> I'm working on a proposal to extend the URL dispatcher. Here, I'd like to
> provide a quick overview of the features I propose.
>
> I
menting some of them.
>
> One interesting note is how content management systems try to work with
> the url dispatcher. Most systems simply use a catch-all pattern. This often
> includes custom machinery to resolve and reverse url patterns for pages,
> blog posts, and other content types
nd creating a public
API. I'll keep in mind the other features and in general the extendibility of
the new dispatcher, and if there is time left I'll start implementing some of
them.
One interesting note is how content management systems try to work with the url
dispatcher. Most systems s
7;ll start
implementing some of them.
One interesting note is how content management systems try to work with the
url dispatcher. Most systems simply use a catch-all pattern. This often
includes custom machinery to resolve and reverse url patterns for pages,
blog posts, and other content types
> E.g., flask uses a simple `` to match an integer and capture it
in the `id` parameter. Support to check for conflicts would be a lot
simpler with those patterns. It would definitely be a best-effort feature.
>From my point of view, this by itself would make for a really nicely-scoped
GSoC pro
d to your ideas from which
> you could draw inspiration?
>
There isn't too much out there for Django, the few apps that are out there
usually work around the url dispatcher, e.g. with additional middleware.
I've mostly looked at other frameworks like flask and ruby-on-rails for
f
ted
decorators (reorder mostly because of csrf_exempt).
That's it for today.
Marten
On Tuesday, March 3, 2015 at 2:56:39 AM UTC+1, Curtis Maloney wrote:
>
>
>
> On 3 March 2015 at 03:57, Marten Kenbeek
> > wrote:
>
>> Hey all,
>>
>> I'm working on a p
On 3 March 2015 at 03:57, Marten Kenbeek wrote:
> Hey all,
>
> I'm working on a proposal to extend the URL dispatcher. Here, I'd like to
> provide a quick overview of the features I propose.
>
> I'd like to:
> - Allow matching based on request attributes such
A collection of thoughts:
I think allowing the url dispatcher to inspect the database for the
existence of certain objects is potentially somewhat dangerous. However,
good support for a view raising a "continue resolving" exception along the
lines of https://github.com/jacobian-arch
:57:24 AM UTC-5, Marten Kenbeek wrote:
>
> Hey all,
>
> I'm working on a proposal to extend the URL dispatcher. Here, I'd like to
> provide a quick overview of the features I propose.
>
> I'd like to:
> - Allow matching based on request attributes such as the
Hey all,
I'm working on a proposal to extend the URL dispatcher. Here, I'd like to
provide a quick overview of the features I propose.
I'd like to:
- Allow matching based on request attributes such as the subdomain or
protocol, and business logic such as the existence of a
I think it's esoteric enough that mentioning it in the docs doesn't
seem like it's worth the distraction. But the wiki's, um, a wiki... so
feel free to edit!
Jacob
On Wed, Apr 3, 2013 at 9:07 AM, Felipe Prenholato wrote:
> Jacob, I know that Django don't refer to third party packages in docs, bu
Jacob, I know that Django don't refer to third party packages in docs, but
is possible to have something in doc or wiki (and doc linking to wiki)
about this url helper (and possible others)? I ask because I see
functionality proposed by this thread and by your app good enough to be
cited in some pl
On Tue, Apr 2, 2013 at 4:49 AM, David Danier wrote:
> This is somethign that does not need to be inside Django core. So why
> not just start an thirt party app implementing the proposal?
I did just that: https://pypi.python.org/pypi/django-multiurl.
Turns out it takes a fair bit of spelunking in
> David: The slugs wouldn't be overlapping if they inherited from some
> sort of "Organization" model with unique slug. The user could also add
> validation code to prevent company and schools having same slugs.
If you have a common base model this sounds like some polymorphic model
problem, which
uring the middleware process_request phase, any previously matched request
is immediately processed by the middleware. This short circuits the URL
dispatcher and reduces the overall response time for handling the request.
On our system, users are able to arbitrarily place assets in the URL
structure and
In this mailing list alone, Michael, Tom, David, Felipe, julianb, Ian and I
have all proposed different solutions. 7 different solutions to what
appears to be a very common problem. :(
Tom:
As you said the get_instance_or_404 only works for simple cases.
The switcher view only works if the de
On Thu, Mar 28, 2013 at 8:21 AM, Loic Bistuer wrote:
> What I would like to see:
>
> urlpatterns = patterns('',
> # Standard patterns
> url(r'^admin/', include(admin.site.urls)),
>
> # Fallthrough patterns
> url('', include('myapp.urls'),
> url('', include(
I'm with Tom here, this just feels wrong. The whole point of urls.py is
to have a clean mapping of URLs to views.
Of course I understand your problem, so let's look at the details.
> // # front page for country
> // / # list of schools and companies with activities
> in that industry, in that co
.urls'),
)
Each app minds its own business and no more middleware that juggle with Http404.
> The view middleware question seems like another really good argument against
> the proposed change...
As far as I'm concerned, Django middleware should have been deprecated
altoge
>
> What is the reasonable alternative? The only way I can think how a
> wrapping view will be able to handle this case, is to write your own
> router...
>
...In each case you'll have lots of ifs, try..excepts, for each model, and
> then to appropriate view. For the second and third router_v
Tom, you're right about the second and third points though. If the user
perform any operation with side effect that requires writing to the
database before the view checks whether the keyword arguments are
appropriate and decide to raise DoesNotResolve, it can definitely be a
source of non-obvi
Hi Tom, interested to see why you think a single wrapping view is a
reasonable alternative for the example I showed above, where you have
following list of URLs:
// # front page for country
// / # list of schools and companies with activities in
that industry, in that country
/// # list of ind
o IGNORABLE_404_URLS
>
> Val
>
>
> On Tue, Mar 26, 2013 at 1:25 PM, Loic Bistuer
> >
> wrote:
> > +1 for me.
> >
> > Having a catchall view under a single URL pattern is a tightly coupled
> > system, more so than allowing independent views to &q
a tightly coupled
> system, more so than allowing independent views to "test the water".
>
> Django core relies on middleware hacks because the URL dispatcher is missing
> this very feature. Having this in core would allow a cleaner implementation
> of the fallback m
+1 for me.
Having a catchall view under a single URL pattern is a tightly coupled system,
more so than allowing independent views to "test the water".
Django core relies on middleware hacks because the URL dispatcher is missing
this very feature. Having this in core would allow
On Tue, Mar 26, 2013 at 10:44 AM, meric wrote:
> Thinking through Adrian's post and mine above, it appears to be a trade
> off between coupling in the framework and increased responsibility for user
> views code. Personally I would opt for the former, because IMHO the idea of
> a framework is to
Thinking through Adrian's post and mine above, it appears to be a trade off
between coupling in the framework and increased responsibility for user views
code. Personally I would opt for the former, because IMHO the idea of a
framework is to reduce responsibility of user code and promoting same
Previous discussion (which I've read before):
https://code.djangoproject.com/ticket/16774
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developer
I've previously raised this idea and created a pull request.
https://github.com/django/django/pull/378
The problem with creating with a catch all view:
You have following models:
Country, Industry, Company, School.
You want to have the following kinds of urls:
//
// /
///
///
/ /
//
Hi Daniele,
On 03/21/2013 02:07 AM, Daniele Procida wrote:
> I think it would at minimum require hooks so that the URL dispatcher
> could call other functions, not just views.
>
> So:
>
> * the URL dispatcher could be invoked with a special argument when
> you want it
l-resolver code,
>for a couple reasons
>If you work on implementing this outside Django and find that you need
>hooks that are not currently available, those hooks would making
>interesting feature proposals for Django.
Thanks for the feedback.
I think it would at minimum require hoo
Hi Daniele,
On 03/20/2013 05:46 AM, Daniele Procida wrote:
> I have an idea for the URL dispatcher, and I'd like to know what your
> thoughts are.
>
> Often - not always but often - a Django URL will map to a model
> instance via a URLconf and a view.
>
> I can think o
I have an idea for the URL dispatcher, and I'd like to know what your thoughts
are.
Often - not always but often - a Django URL will map to a model instance via a
URLconf and a view.
I can think of a few uses for a feature that used Django's URLconfs to return
the model instance, i
On Tue, Mar 19, 2013 at 12:26 PM, Felipe Prenholato
wrote:
> Hi Julian. My 2 cents.
>
> What you want is:
>
> urlpatterns = patterns('',
> url_fallthrought(r'^(?P[-\w]+)$',
> views=[(ProductView.as_view(),
>CategorView.as_view(),
>OccasionView.as
Hi Julian. My 2 cents.
What you want is:
urlpatterns = patterns('',
url_fallthrought(r'^(?P[-\w]+)$',
views=[(ProductView.as_view(),
CategorView.as_view(),
OccasionView.as_view())], name="my_super_url"),)
But you know that we don't have it. To ma
On Mon, Mar 18, 2013 at 10:23 AM, julianb wrote:
> Well, at the moment, as far as I am aware, you can't. The first URL will
> match everything all the time, not giving the other views a chance to kick
> in.
>
> So I propose some kind of URL fallthrough. The view could do
>
> raise UrlNotMatched
>
On Mon, Mar 18, 2013 at 3:23 PM, julianb wrote:
> Hi,
>
> imagine the following use case:
>
> You build an online store where you have sorted products into several
> categories and maybe associated an occasion. Now you want to build URLs. So
> the URL schema that all of the store's owners agree on
A single pattern with a catchall view is certainly a way to go. However, I
really does not help to see what the views do. And if you have different
views with different arguments, you cannot do your regex explicitly.
You are right that it is non-obvious when the view itself has to invoke the
fal
Hi Julian,
On Mon, 18 Mar 2013, julianb wrote:
imagine the following use case:
You build an online store where you have sorted products into several
categories and maybe associated an occasion. Now you want to build URLs. So the
URL schema that all of the
store's owners agree on is:
//
//
/
Hi, Julian
I think this problem can already be addressed by having a single catchall
// URL pattern, and writing a SlugHandlerView which would try
different options within the view code, rather than in the URL dispatching.
Then it would just be a matter or catching exceptions for your .get()
met
The approach we take at work is to have a view that wraps around the
product, category and occasion views and takes care of the fallthrough
logic. I'm not a fan of this approach, because it means that you can't just
look at the urlconf and see which pattern maps to which view function. On
the other
Hi,
imagine the following use case:
You build an online store where you have sorted products into several
categories and maybe associated an occasion. Now you want to build URLs. So
the URL schema that all of the store's owners agree on is:
//
//
//
Look simple.
Because product slugs should
static[0]
138017 function calls in 0.818 seconds
Ordered by: internal time
List reduced from 79 to 10 due to restriction <10>
ncalls tottime percall cumtime percall filename:lineno(function)
10000.0620.0000.4900.000 base.py:72(get_response)
2000
On Thu, Oct 11, 2012 at 10:58 PM, Łukasz Rekucki wrote:
> On 11 October 2012 10:20, Russell Keith-Magee wrote:
>>
>> And don't just say "Why are Django's URL resolvers slow?". Do some
>> profiling, and come back with an analysis of where the time is being
>> spent and/or wasted.
>
> FWIW, here's
> FWIW, here's a link to a cProfile result for the mentioned
> benchmark[1] on Django 1.4.1 and CPython 2.7.3. A quick look shows
> that we're calling get_language() 1.5mln times (read: for every
> pattern), so that's definitely going to slow down things.
>
Happy to see we moved it a bit for
On Thu, Oct 11, 2012 at 2:53 PM, Tom Evans wrote:
> On Wed, Oct 10, 2012 at 7:52 AM, Moonlight wrote:
>> Here is an article comparing various URL dispatchers:
>>
>> http://mindref.blogspot.com/2012/10/python-web-routing-benchmark.html
>>
>> What cause django
On 11 October 2012 10:20, Russell Keith-Magee wrote:
>
> And don't just say "Why are Django's URL resolvers slow?". Do some
> profiling, and come back with an analysis of where the time is being
> spent and/or wasted.
FWIW, here's a link to a cProfile result for the mentioned
benchmark[1] on Djan
JKM, I'm wondering if it would benefit the community to house
djangobench under https://github.com/django to give it more
visibility. Just a thought.
On Thu, Oct 11, 2012 at 9:45 AM, ptone wrote:
>
>
> On Thursday, October 11, 2012 1:21:09 AM UTC-7, Russell Keith-Magee wrote:
>>
>>
>> That said
On Thursday, October 11, 2012 1:21:09 AM UTC-7, Russell Keith-Magee wrote:
>
>
> That said - could Django be faster? Sure. *Anything* can be improved.
>
> So, if you've got a suggestion, make it. If you think URL resolving is
> the source of the problem, propose a way to improve the speed of UR
On 11/10/2012 15:53, Tom Evans wrote:
On Wed, Oct 10, 2012 at 7:52 AM, Moonlight wrote:
Here is an article comparing various URL dispatchers:
http://mindref.blogspot.com/2012/10/python-web-routing-benchmark.html
What cause django URL dispatcher that much... slow?
Now that I've look
2012/10/11 Tom Evans
> Now that I've looked in detail at the test, it is because the test is
> nonsensical. Each time it tests the URLs, it constructs a fresh WSGI
> application. Each fresh application has to compile each URL in the
> urlconf before using it. It then destroys the application, and
This conversation is getting nasty. Django's URL dispatcher is what it is.
If you can get the flexibility that the current URL dispatcher provides
while making it faster, I imagine everyone on this thread would be
impressed.
There is no reason to use Django's URL dispatcher. It is qui
Was that necessary? I am tuning out of this conversion, it is becoming
hostile.
From: Alex Gaynor
Sent: Thursday, October 11, 2012 10:01 AM
To: django-developers@googlegroups.com
Subject: Re: URL dispatcher slow?
On Thu, Oct 11, 2012 at 6:52 AM, Daniel Sokolowski
wrote:
I absolutely
On Thu, Oct 11, 2012 at 6:52 AM, Daniel Sokolowski <
daniel.sokolow...@klinsight.com> wrote:
> I absolutely agree with: if we were looking for speed we wouldn't use
> python at all (period).
>
>
Speak for yourself.
Alex
--
"I disapprove of what you say, but I will defend to the death your rig
On Wed, Oct 10, 2012 at 7:52 AM, Moonlight wrote:
> Here is an article comparing various URL dispatchers:
>
> http://mindref.blogspot.com/2012/10/python-web-routing-benchmark.html
>
> What cause django URL dispatcher that much... slow?
>
Now that I've looked in detail at
I absolutely agree with: if we were looking for speed we wouldn't use python at
all (period).
From: Florian Apolloner
Sent: Wednesday, October 10, 2012 6:29 PM
To: django-developers@googlegroups.com
Subject: Re: URL dispatcher slow?
Oh cmon,
please stop playing a socket puppet fo
I only now realized that this thread had started in a bit of a trolling
fashion, and that there was a similar thread this week. That helps to explain
the slightly more defensive stance.
Django can survive (and thrive) just fine in its current, reasonably performant
state, but performance should
nce that much I want to see which features cause that. Let
itemize the list. Honesty I tried... but just can not related them to the facts
faced.
From: Tom Evans
To: Moonlight
Sent: Thursday, October 11, 2012 3:46 PM
Subject: Re: URL dispatcher slow?
>
> So, the benchmarks are interesting. They tell us which stacks are
> fully featured, and which stacks are very lightweight. Apart from
> that, they don't tell us much at all - is Django's template engine
> slow, or is it about right for the work it does? This benchmark
> doesn't tell us tha
Well I am not that good to get it fixed it django... it quite easy get
lost there. But I definitely would appreciate if someone from core team I
guess or in the community finally have a look there...
That said, if you really think Django's urlresolver is to slow, go ahead,
> profile it and
On Thu, Oct 11, 2012 at 7:02 AM, Yo-Yo Ma wrote:
> Why does every conversation about Django's performance met with "GTFO we
> don't care"? (that was a rhetorical question :). I'd venture to guess that
> most "It's fast enough for me!" responses are predicated on experiences that
> can be likene
On Thu, Oct 11, 2012 at 2:02 PM, Yo-Yo Ma wrote:
> Why does every conversation about Django's performance met with "GTFO we
> don't care"? (that was a rhetorical question :).
Ok - If this is where the conversation is starting, it's going to go
downhill *very* fast.
Consider this a warning to *e
Hi,
I won't answer your rheotircal questions ;)
On Thursday, October 11, 2012 8:02:19 AM UTC+2, Yo-Yo Ma wrote:
>
> BUT... Django is NOT that fast.
>
We do know that (you know that and probably everyone else too) and I
already said in my post that Django isn't the fastest framework out there.
On Wed, Oct 10, 2012 at 6:29 PM, Florian Apolloner wrote:
> That said, if you really think Django's urlresolver is to slow, go ahead,
> profile it and improve it, we certainly won't say no to speed improvements…
>
That's not really fair. Django core *will* say no to speed improvements if
they nec
Why does every conversation about Django's performance met with "GTFO we don't
care"? (that was a rhetorical question :). I'd venture to guess that most "It's
fast enough for me!" responses are predicated on experiences that can be
likened to personal blog development, rather than large scale, 1
Oh cmon,
please stop playing a socket puppet for the wheezy.web author. A web
framework consists of more than just a win in speed (an the author of
wheezy.web can argue whatever he wants that "basic" stuff stuff should be
fast) -- if we were looking for speed we wouldn't use python at all
(per
Yes, wheezy.web is much more bare metal compared to Django :
http://packages.python.org/wheezy.web/tutorial.html
From: Daniel Sokolowski
Sent: Wednesday, October 10, 2012 10:32 AM
To: django-developers@googlegroups.com
Subject: Re: URL dispatcher slow?
The middlewares appear to be disabled
take convenience as speed has not been a issue to me,
but one thing though is that these benchmarks are transparent enough to give
them some validity.
From: Aymeric Augustin
Sent: Wednesday, October 10, 2012 9:30 AM
To: django-developers@googlegroups.com
Subject: Re: URL dispatcher slow
2012/10/10 Moonlight
> Here is an article comparing various URL dispatchers:
>
> http://mindref.blogspot.com/2012/10/python-web-routing-benchmark.html
>
> What cause django URL dispatcher that much... slow?
Django's URL dispatcher is more complex than others. It provides ad
Here is an article comparing various URL dispatchers:
http://mindref.blogspot.com/2012/10/python-web-routing-benchmark.html
What cause django URL dispatcher that much... slow?
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To
94 matches
Mail list logo
