Is there any continuous speed testing done for Django? It would be
nice to see how performance of Django is evolving. For example while
working on ticket #14290, seeing how my changes to utils/translation/
__init__.py affect other parts of the framework would be useful. In
general, speed testing sh
On Thu, Sep 16, 2010 at 3:05 PM, akaariai wrote:
> Is there any continuous speed testing done for Django? It would be
> nice to see how performance of Django is evolving. For example while
> working on ticket #14290, seeing how my changes to utils/translation/
> __init__.py affect other parts of t
('The `django.contrib.gis.db.backend` module was refactored and '
'renamed to `django.contrib.gis.db.backends` in 1.2. '
'All functionality of `SpatialBackend` '
'has been moved to the `ops` attribute of the spatial
database '
'backend. A `SpatialBackend` alias
On Sep 16, 10:43 am, Russell Keith-Magee
wrote:
> Do we have a continuous performance benchmark at present? No.
>
> Would it be worth having one? Certainly.
>
> There's a long standing ticket proposing just such a change:
>
> http://code.djangoproject.com/ticket/8949
>
> And there was a sprint ea
Hi,
I would really appreciate some feedback on this.
Thanks,
David
On 8 Sep 2010, at 09:39, David Reynolds wrote:
>
> On 7 Sep 2010, at 16:48, David Reynolds wrote:
>
>> Hi folks,
>>
>> I am running into a validation problem with ModelForms - here is a quick
>> summary of what is happening
I have no data to support the following assertion, but it's not too
unreasonable: More people probably need thumbnail images than they
need comments. Comments are most used on blogs, whereas thumbnails can
be used on blogs, e-commerce, photo hosting, social networking,
project management, et al. It
I have absolutely no pull in decision making, but maybe my message will
count towards a "community voice".
I think that including an image thumbnail package that integrates into the
database as easily as sorl.thumbnail and easy_thumbnail are is a great
idea. From what I can tell, sorl.thumbnail w
sorl-thumbnails is over. The two developers who were maintaining it
have started to different projects. One relies on ImageMagik and is
probably not as easy for the crowds. The other is "easy-thumbnails".
On Sep 16, 10:33 am, "Brian O'Connor" wrote:
> I have absolutely no pull in decision making,
Yeah, I'm aware, that's why I said '_was_ the de facto standard' :)
easy-thumbnails is what I had in mind when I was agreeing with you. I think
it's a great piece of software that satisfies most people's needs for image
manipulation within a web development environment, and being in contrib will
Another "community voice" contribution on this thread...
I am of the opposite opinion. I think it would be better for Django as a whole
if django.contrib approached zero. In fact, I would have no problem with
seeing it go away completely and promote auth and sessions to core but done in
a way
There's a negative side to contrib: once an app is included, it stifles
innovation on that particular app (because it is tied to release cycles and
must maintain full backwards compatibility) and discourages other developers
from innovating in that same area.
In order to get an application include
I see what you're saying Chuck. It's almost like you stop evolution
(natural selection, if you will) when you accept a "winner" for the
trunk. The positive to weigh against is that you remove instability
form external projects like this. It's a great project, but it could
turn south quickly without
On Jul 4, 2:17 pm, Mitar wrote:
> Hi!
>
> I have opened a ticket and would like some feedback on it. Do you
> think it is a good idea?
>
> Ticket description:
>
> Allow context processors access to current version of context so that
> they can change values and not just override them. This can b
On Sep 16, 9:43 am, Patrick Altman wrote:
> Another "community voice" contribution on this thread...
>
> I am of the opposite opinion. I think it would be better for Django as a
> whole if django.contrib approached zero. In fact, I would have no problem
> with seeing it go away completely an
On Thu, Sep 16, 2010 at 6:36 AM, David Reynolds
wrote:
> Hi,
>
> I would really appreciate some feedback on this.
David, thanks for following up on this. You were unlucky in reporting
this issue during DjangoCon, so most attention has been elsewhere.
I've left comments (and a couple patches) on
One of the criteria for django.contrib is that the item for inclusion
is a "de facto standard implementation of common patterns"[0]. From
your own admittance there are conflicting views about how this should
be handled. Perhaps if someone abstracts this out a bit and has
something like image proces
On Sep 16, 12:43 am, Russell Keith-Magee
wrote:
> Do we have a continuous performance benchmark at present? No.
>
> Would it be worth having one? Certainly.
>
> There's a long standing ticket proposing just such a change:
>
> http://code.djangoproject.com/ticket/8949
>
> And there was a sprint
Hi everyone,
I think thumbnailing functionality is much closer to django core
rather than to django.contrib, and that is the most important reason
for inclusion.
Django provides ImageField out of the box, but why it doesn't provide
ThumbnailImageField out of the box?
Django provides {% lorem %}
FWIW +1 for moving away from contrib for me.
Let the core focus on core functionality and people who both more
qualified and passionate about "contrib" pieces to manage that
functionality without being burdened by the core release cycle
patterns.
D
On Fri, Sep 17, 2010 at 5:53 AM, burc...@gmail.
I also agree moving away from contrib. Even comments aren't actually
necessary and could be a third party project.
Benoit
On Thu, Sep 16, 2010 at 5:39 PM, David P. Novakovic <
davidnovako...@gmail.com> wrote:
> FWIW +1 for moving away from contrib for me.
>
> Let the core focus on core function
I have to pull out my flip flops. Last week I read the slides from the
orange haired guy (Alex I believe), "Why Django sucks...", and found
it interesting. Today I watched it, and maybe I'm just an audio
learning sort of guy, but I am truly sold on the idea of focusing on
the core APIs to make deve
Although thumbnails are something *many* sites do, everyone have
wildly different requirements, and therefore, different solutions. Two
simple requirements that vary so much that makes impossible to have a
"standard" for thumbnails:
- The API for making thumbnails. Is it a backend class? Is it a
t
22 matches
Mail list logo
