Speed testing Django
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 should expose performance problems early, so
that design of features can be changed before the feature goes into a
release.
If there is no continuous benchmarking done at the moment, maybe using
Codespeed (http://wiki.github.com/tobami/codespeed/) could be
considered. It is the framework used for http://speed.pypy.org, and it
is built using Django.
If there is need for this kind of work, I am volunteering to do some
work. That is, set up Codespeed and do some simple tests. I haven't
tested integrating Codespeed with Django yet, so it is possible that
Codespeed is not useful in this set up. I would like to integrate it
with git, so that it would be easy to do speed testing of your own
development branches. In SVN this is hard to do, if I am not
mistaken...
I am thinking of implementing the following tests (as time permits):
Template rendering, simple case: build a table of, say 1000 x 10 cells
using for loops.
Template rendering, forms: build a large form (possibly with FormSets)
and use that in a template. Maybe both with {{ form.as_table }} and
iterating through the form. This would test form rendering, not
initialization.
Template rendering, real world case: Use {% extends %}, {% include %},
{% trans %}... blocks, that is, build a simple template that reflects
real world usage.
QuerySet building: Simple QuerySet building:
Foo.objects.filter(pk=id). Complex QuerySet building (couple of filter
operations, with some joins), maybe order by etc.
Object creation: Just create a bunch of Model objects. A few cases
here, simple object (only id) creation, complex object (many fields)
creation, objects with foreign keys, inheritance and deferred fields
object creation.
Realistic use case: Make a request to the framework and go through all
the parts of building the response, that is, make a request to
runserver. However, do not use database queries.
Regression tests: Go through trac and look for speed tests attached to
tickets.
This is probably a lot of work, but I would like to give it a try.
Comments?
- Anssi
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Speed testing Django
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 the framework would be useful. In
> general, speed testing should expose performance problems early, so
> that design of features can be changed before the feature goes into a
> release.
>
> If there is no continuous benchmarking done at the moment, maybe using
> Codespeed (http://wiki.github.com/tobami/codespeed/) could be
> considered. It is the framework used for http://speed.pypy.org, and it
> is built using Django.
>
> If there is need for this kind of work, I am volunteering to do some
> work. That is, set up Codespeed and do some simple tests. I haven't
> tested integrating Codespeed with Django yet, so it is possible that
> Codespeed is not useful in this set up. I would like to integrate it
> with git, so that it would be easy to do speed testing of your own
> development branches. In SVN this is hard to do, if I am not
> mistaken...
>
> I am thinking of implementing the following tests (as time permits):
>
> Template rendering, simple case: build a table of, say 1000 x 10 cells
> using for loops.
>
> Template rendering, forms: build a large form (possibly with FormSets)
> and use that in a template. Maybe both with {{ form.as_table }} and
> iterating through the form. This would test form rendering, not
> initialization.
>
> Template rendering, real world case: Use {% extends %}, {% include %},
> {% trans %}... blocks, that is, build a simple template that reflects
> real world usage.
>
> QuerySet building: Simple QuerySet building:
> Foo.objects.filter(pk=id). Complex QuerySet building (couple of filter
> operations, with some joins), maybe order by etc.
>
> Object creation: Just create a bunch of Model objects. A few cases
> here, simple object (only id) creation, complex object (many fields)
> creation, objects with foreign keys, inheritance and deferred fields
> object creation.
>
> Realistic use case: Make a request to the framework and go through all
> the parts of building the response, that is, make a request to
> runserver. However, do not use database queries.
>
> Regression tests: Go through trac and look for speed tests attached to
> tickets.
>
> This is probably a lot of work, but I would like to give it a try.
> Comments?
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 earlier this year that started developing a
benchmark set that could be used; results so far can be found here:
http://github.com/jacobian/djangobench
However, there's still a lot of work to do to build up the benchmark
set and deploy it in a continuous integration environment. I'm not
aware of anyone specifically coordinating this benchmark work at the
moment, so if you want to step up and make this your contribution,
feel free to do so!
Yours,
Russ Magee %-)
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
backend usage ?
('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 is provided here for '
'backwards-compatibility, but will be removed in 1.3.')
What will be for django.contrib.gis.geometry.backend ?
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Speed testing Django
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 earlier this year that started developing a > benchmark set that could be used; results so far can be found here: > > http://github.com/jacobian/djangobench > > However, there's still a lot of work to do to build up the benchmark > set and deploy it in a continuous integration environment. I'm not > aware of anyone specifically coordinating this benchmark work at the > moment, so if you want to step up and make this your contribution, > feel free to do so! > > Yours, > Russ Magee %-) That looks to be a good base to start the work from. I hope I will have time to do this, but this might be bigger problem than I can handle. I will check if it is possible to integrate Codespeed with the benchmarks in djangobench. I will post status updates to ticket #8949, once I have better understanding of the problem. - Anssi -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: ModelForm possible validation bug
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 opened a ticket to track this > [http://code.djangoproject.com/ticket/14234]. I'd be happy to work up a > patch, but would appreciate some advice on where it is best to fix it. > > Would it make sense for the ModelForm to unset instanace._adding once a save > has been executed, or is there some other place that would be better suited > for the fix? > > I would also appreciate advice on where to add a test for this issue. > > Thanks, > > David > > -- > David Reynolds > da...@reynoldsfamily.org.uk > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > -- David Reynolds da...@reynoldsfamily.org.uk -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Inclusion of easy-thumbnails into Django Contrib
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's not to say that we don't need "contrib.comments", just that I wouldn't want to lose easy_thumbnails. On Sep 15, 11:32 pm, "David P. Novakovic" wrote: > Actually, that really did sound negative. Sorry :) > > Is there a trac ticket open to address this issue? Generally it'd be > better to get discussion happening over a ticket and if there are > serious issues that need to be addressed then they can be discussed > here. > > I know it'd be nice to get things like easy-thumbnails accepted into > django.contrib , but the truth is that this probably falls outside of > things that that should be in contrib. Contrib isn't really an easier > way to get stuff into django, it still has to satisfy a bunch of > conditions like the rest of the code in the core. > > The real question is not "can it be included?" but why is it a problem > that this is a third party lib at the moment? Is there a strong case > that it be better if it was part of django core or does it do its job > just fine the way it is now? > > David > > On Thu, Sep 16, 2010 at 3:09 PM, David P. Novakovic > > wrote: > > I don't want to sound negative, but answering your own question before > > anyone else can doesn't change the answer ;) > > > D > > > On Thu, Sep 16, 2010 at 3:00 PM, Yo-Yo Ma wrote: > >> Is there any plans to > >> incorporatehttp://github.com/SmileyChris/easy-thumbnails/ > >> into django.contrib? I have seen so many apps/libraries come into and > >> go out of existence (http://code.djangoproject.com/wiki/ThumbNailsfor > >> instance mentions sorl-thumbnails which is no longer being developed). > >> I just turned the key with easy-thumbnails and voila. It's like magic, > >> but not. It's easy enough to see what's going on behind the scenes. > > >> This is something that, with the help of the core and other > >> contributors, could be really great. It works for me as it it is, but > >> it may not work for a more "enterprise" application that uses S3, etc. > >> It might not be highly efficient (I wouldn't know). It might have bugs > >> that I just haven't noticed yet. I'm mentioning all of this because I > >> know somebody will say, "Why move it into Django if it's doing just > >> fine as a separate project?". After experiencing the bliss I thought > >> I'd drop a line here about it, and see what you guys thought. > > >> -- > >> You received this message because you are subscribed to the Google Groups > >> "Django developers" group. > >> To post to this group, send email to django-develop...@googlegroups.com. > >> To unsubscribe from this group, send email to > >> django-developers+unsubscr...@googlegroups.com. > >> For more options, visit this group > >> athttp://groups.google.com/group/django-developers?hl=en. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Inclusion of easy-thumbnails into Django Contrib
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 was the de facto standard for getting thumbnails in to Django, and I think it has just as much of a place in Django contrib as some of the other contrib apps do. I don't think it belongs in the core, but contrib seems like an excellent place for it to go along with the other batteries in the pack. On Thu, Sep 16, 2010 at 12:24 PM, Yo-Yo Ma wrote: > 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's not to say that we don't need > "contrib.comments", just that I wouldn't want to lose easy_thumbnails. > > > On Sep 15, 11:32 pm, "David P. Novakovic" > wrote: > > Actually, that really did sound negative. Sorry :) > > > > Is there a trac ticket open to address this issue? Generally it'd be > > better to get discussion happening over a ticket and if there are > > serious issues that need to be addressed then they can be discussed > > here. > > > > I know it'd be nice to get things like easy-thumbnails accepted into > > django.contrib , but the truth is that this probably falls outside of > > things that that should be in contrib. Contrib isn't really an easier > > way to get stuff into django, it still has to satisfy a bunch of > > conditions like the rest of the code in the core. > > > > The real question is not "can it be included?" but why is it a problem > > that this is a third party lib at the moment? Is there a strong case > > that it be better if it was part of django core or does it do its job > > just fine the way it is now? > > > > David > > > > On Thu, Sep 16, 2010 at 3:09 PM, David P. Novakovic > > > > wrote: > > > I don't want to sound negative, but answering your own question before > > > anyone else can doesn't change the answer ;) > > > > > D > > > > > On Thu, Sep 16, 2010 at 3:00 PM, Yo-Yo Ma > wrote: > > >> Is there any plans to incorporatehttp:// > github.com/SmileyChris/easy-thumbnails/ > > >> into django.contrib? I have seen so many apps/libraries come into and > > >> go out of existence (http://code.djangoproject.com/wiki/ThumbNailsfor > > >> instance mentions sorl-thumbnails which is no longer being developed). > > >> I just turned the key with easy-thumbnails and voila. It's like magic, > > >> but not. It's easy enough to see what's going on behind the scenes. > > > > >> This is something that, with the help of the core and other > > >> contributors, could be really great. It works for me as it it is, but > > >> it may not work for a more "enterprise" application that uses S3, etc. > > >> It might not be highly efficient (I wouldn't know). It might have bugs > > >> that I just haven't noticed yet. I'm mentioning all of this because I > > >> know somebody will say, "Why move it into Django if it's doing just > > >> fine as a separate project?". After experiencing the bliss I thought > > >> I'd drop a line here about it, and see what you guys thought. > > > > >> -- > > >> You received this message because you are subscribed to the Google > Groups "Django developers" group. > > >> To post to this group, send email to > django-develop...@googlegroups.com. > > >> To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > . > > >> For more options, visit this group athttp:// > groups.google.com/group/django-developers?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- Brian O'Connor -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Inclusion of easy-thumbnails into Django Contrib
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, 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 was the de facto standard for > getting thumbnails in to Django, and I think it has just as much of a place > in Django contrib as some of the other contrib apps do. I don't think it > belongs in the core, but contrib seems like an excellent place for it to go > along with the other batteries in the pack. > > > > On Thu, Sep 16, 2010 at 12:24 PM, Yo-Yo Ma wrote: > > 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's not to say that we don't need > > "contrib.comments", just that I wouldn't want to lose easy_thumbnails. > > > On Sep 15, 11:32 pm, "David P. Novakovic" > > wrote: > > > Actually, that really did sound negative. Sorry :) > > > > Is there a trac ticket open to address this issue? Generally it'd be > > > better to get discussion happening over a ticket and if there are > > > serious issues that need to be addressed then they can be discussed > > > here. > > > > I know it'd be nice to get things like easy-thumbnails accepted into > > > django.contrib , but the truth is that this probably falls outside of > > > things that that should be in contrib. Contrib isn't really an easier > > > way to get stuff into django, it still has to satisfy a bunch of > > > conditions like the rest of the code in the core. > > > > The real question is not "can it be included?" but why is it a problem > > > that this is a third party lib at the moment? Is there a strong case > > > that it be better if it was part of django core or does it do its job > > > just fine the way it is now? > > > > David > > > > On Thu, Sep 16, 2010 at 3:09 PM, David P. Novakovic > > > > wrote: > > > > I don't want to sound negative, but answering your own question before > > > > anyone else can doesn't change the answer ;) > > > > > D > > > > > On Thu, Sep 16, 2010 at 3:00 PM, Yo-Yo Ma > > wrote: > > > >> Is there any plans to incorporatehttp:// > > github.com/SmileyChris/easy-thumbnails/ > > > >> into django.contrib? I have seen so many apps/libraries come into and > > > >> go out of existence (http://code.djangoproject.com/wiki/ThumbNailsfor > > > >> instance mentions sorl-thumbnails which is no longer being developed). > > > >> I just turned the key with easy-thumbnails and voila. It's like magic, > > > >> but not. It's easy enough to see what's going on behind the scenes. > > > > >> This is something that, with the help of the core and other > > > >> contributors, could be really great. It works for me as it it is, but > > > >> it may not work for a more "enterprise" application that uses S3, etc. > > > >> It might not be highly efficient (I wouldn't know). It might have bugs > > > >> that I just haven't noticed yet. I'm mentioning all of this because I > > > >> know somebody will say, "Why move it into Django if it's doing just > > > >> fine as a separate project?". After experiencing the bliss I thought > > > >> I'd drop a line here about it, and see what you guys thought. > > > > >> -- > > > >> You received this message because you are subscribed to the Google > > Groups "Django developers" group. > > > >> To post to this group, send email to > > django-develop...@googlegroups.com. > > > >> To unsubscribe from this group, send email to > > django-developers+unsubscr...@googlegroups.com > > . > > > >> For more options, visit this group athttp:// > > groups.google.com/group/django-developers?hl=en. > > > -- > > You received this message because you are subscribed to the Google Groups > > "Django developers" group. > > To post to this group, send email to django-develop...@googlegroups.com. > > To unsubscribe from this group, send email to > > django-developers+unsubscr...@googlegroups.com > > . > > For more options, visit this group at > >http://groups.google.com/group/django-developers?hl=en. > > -- > Brian O'Connor -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Inclusion of easy-thumbnails into Django Contrib
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 allow people to use another package if they don't like it. On Thu, Sep 16, 2010 at 12:37 PM, Yo-Yo Ma wrote: > 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, 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 was the de facto standard for > > getting thumbnails in to Django, and I think it has just as much of a > place > > in Django contrib as some of the other contrib apps do. I don't think it > > belongs in the core, but contrib seems like an excellent place for it to > go > > along with the other batteries in the pack. > > > > > > > > On Thu, Sep 16, 2010 at 12:24 PM, Yo-Yo Ma > wrote: > > > 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's not to say that we don't need > > > "contrib.comments", just that I wouldn't want to lose easy_thumbnails. > > > > > On Sep 15, 11:32 pm, "David P. Novakovic" > > > wrote: > > > > Actually, that really did sound negative. Sorry :) > > > > > > Is there a trac ticket open to address this issue? Generally it'd be > > > > better to get discussion happening over a ticket and if there are > > > > serious issues that need to be addressed then they can be discussed > > > > here. > > > > > > I know it'd be nice to get things like easy-thumbnails accepted into > > > > django.contrib , but the truth is that this probably falls outside of > > > > things that that should be in contrib. Contrib isn't really an easier > > > > way to get stuff into django, it still has to satisfy a bunch of > > > > conditions like the rest of the code in the core. > > > > > > The real question is not "can it be included?" but why is it a > problem > > > > that this is a third party lib at the moment? Is there a strong case > > > > that it be better if it was part of django core or does it do its job > > > > just fine the way it is now? > > > > > > David > > > > > > On Thu, Sep 16, 2010 at 3:09 PM, David P. Novakovic > > > > > > wrote: > > > > > I don't want to sound negative, but answering your own question > before > > > > > anyone else can doesn't change the answer ;) > > > > > > > D > > > > > > > On Thu, Sep 16, 2010 at 3:00 PM, Yo-Yo Ma < > baxterstock...@gmail.com> > > > wrote: > > > > >> Is there any plans to incorporatehttp:// > > > github.com/SmileyChris/easy-thumbnails/ > > > > >> into django.contrib? I have seen so many apps/libraries come into > and > > > > >> go out of existence ( > http://code.djangoproject.com/wiki/ThumbNailsfor > > > > >> instance mentions sorl-thumbnails which is no longer being > developed). > > > > >> I just turned the key with easy-thumbnails and voila. It's like > magic, > > > > >> but not. It's easy enough to see what's going on behind the > scenes. > > > > > > >> This is something that, with the help of the core and other > > > > >> contributors, could be really great. It works for me as it it is, > but > > > > >> it may not work for a more "enterprise" application that uses S3, > etc. > > > > >> It might not be highly efficient (I wouldn't know). It might have > bugs > > > > >> that I just haven't noticed yet. I'm mentioning all of this > because I > > > > >> know somebody will say, "Why move it into Django if it's doing > just > > > > >> fine as a separate project?". After experiencing the bliss I > thought > > > > >> I'd drop a line here about it, and see what you guys thought. > > > > > > >> -- > > > > >> You received this message because you are subscribed to the Google > > > Groups "Django developers" group. > > > > >> To post to this group, send email to > > > django-develop...@googlegroups.com. > > > > >> To unsubscribe from this group, send email to > > > django-developers+unsubscr...@googlegroups.com > > > > > > . > > > > >> For more options, visit this group athttp:// > > > groups.google.com/group/django-developers?hl=en. > > > > > -- > > > You received this message because you are subscribed to the Google > Groups > > > "Django developers" group. > > > To post to this group, send email to > django-devel
Re: Inclusion of easy-thumbnails into Django Contrib
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 that is pluggable. The reasoning behind this opinion is that it leaves the surface area in the project smaller to maintain and it's really not that hard to add a sorl-thumbnail external app to a Django project. Furthermore, it provides more freedom for these apps to mature and develop at their own pace. I realize I could very well be in a minority opinion here, but thought I'd throw it into the mix nonetheless. On Sep 16, 2010, at 11:33 AM, Brian O'Connor wrote: > 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 was the de facto standard for getting > thumbnails in to Django, and I think it has just as much of a place in Django > contrib as some of the other contrib apps do. I don't think it belongs in > the core, but contrib seems like an excellent place for it to go along with > the other batteries in the pack. > > On Thu, Sep 16, 2010 at 12:24 PM, Yo-Yo Ma wrote: > 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's not to say that we don't need > "contrib.comments", just that I wouldn't want to lose easy_thumbnails. > > > On Sep 15, 11:32 pm, "David P. Novakovic" > wrote: > > Actually, that really did sound negative. Sorry :) > > > > Is there a trac ticket open to address this issue? Generally it'd be > > better to get discussion happening over a ticket and if there are > > serious issues that need to be addressed then they can be discussed > > here. > > > > I know it'd be nice to get things like easy-thumbnails accepted into > > django.contrib , but the truth is that this probably falls outside of > > things that that should be in contrib. Contrib isn't really an easier > > way to get stuff into django, it still has to satisfy a bunch of > > conditions like the rest of the code in the core. > > > > The real question is not "can it be included?" but why is it a problem > > that this is a third party lib at the moment? Is there a strong case > > that it be better if it was part of django core or does it do its job > > just fine the way it is now? > > > > David > > > > On Thu, Sep 16, 2010 at 3:09 PM, David P. Novakovic > > > > wrote: > > > I don't want to sound negative, but answering your own question before > > > anyone else can doesn't change the answer ;) > > > > > D > > > > > On Thu, Sep 16, 2010 at 3:00 PM, Yo-Yo Ma > > > wrote: > > >> Is there any plans to > > >> incorporatehttp://github.com/SmileyChris/easy-thumbnails/ > > >> into django.contrib? I have seen so many apps/libraries come into and > > >> go out of existence (http://code.djangoproject.com/wiki/ThumbNailsfor > > >> instance mentions sorl-thumbnails which is no longer being developed). > > >> I just turned the key with easy-thumbnails and voila. It's like magic, > > >> but not. It's easy enough to see what's going on behind the scenes. > > > > >> This is something that, with the help of the core and other > > >> contributors, could be really great. It works for me as it it is, but > > >> it may not work for a more "enterprise" application that uses S3, etc. > > >> It might not be highly efficient (I wouldn't know). It might have bugs > > >> that I just haven't noticed yet. I'm mentioning all of this because I > > >> know somebody will say, "Why move it into Django if it's doing just > > >> fine as a separate project?". After experiencing the bliss I thought > > >> I'd drop a line here about it, and see what you guys thought. > > > > >> -- > > >> You received this message because you are subscribed to the Google > > >> Groups "Django developers" group. > > >> To post to this group, send email to django-develop...@googlegroups.com. > > >> To unsubscribe from this group, send email to > > >> django-developers+unsubscr...@googlegroups.com. > > >> For more options, visit this group > > >> athttp://groups.google.com/group/django-developers?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-d
Re: Inclusion of easy-thumbnails into Django Contrib
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 included to contrib, you'll need to make a compelling case that the community will gain by its inclusion in contrib. Yes, easy-thumbnails is great, but the only argument you've provided is that you don't want development to die, as it did on sorl_thumbnails (which is still a functional piece of software, by the way). That's a legitimate fear, but where do you draw the line? What about django-registration? Or django-taggit? Further discussion from DjangoCon (skip ahead to 22:12 for discussion on contrib, though I recommend the entire talk): http://djangocon.blip.tv/file/4112452/ On Thu, Sep 16, 2010 at 12:41 PM, Brian O'Connor wrote: > 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 allow people to use another package if they don't like it. > > > On Thu, Sep 16, 2010 at 12:37 PM, Yo-Yo Ma wrote: > >> 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, 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 was the de facto standard >> for >> > getting thumbnails in to Django, and I think it has just as much of a >> place >> > in Django contrib as some of the other contrib apps do. I don't think >> it >> > belongs in the core, but contrib seems like an excellent place for it to >> go >> > along with the other batteries in the pack. >> > >> > >> > >> > On Thu, Sep 16, 2010 at 12:24 PM, Yo-Yo Ma >> wrote: >> > > 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's not to say that we don't need >> > > "contrib.comments", just that I wouldn't want to lose easy_thumbnails. >> > >> > > On Sep 15, 11:32 pm, "David P. Novakovic" >> > > wrote: >> > > > Actually, that really did sound negative. Sorry :) >> > >> > > > Is there a trac ticket open to address this issue? Generally it'd be >> > > > better to get discussion happening over a ticket and if there are >> > > > serious issues that need to be addressed then they can be discussed >> > > > here. >> > >> > > > I know it'd be nice to get things like easy-thumbnails accepted into >> > > > django.contrib , but the truth is that this probably falls outside >> of >> > > > things that that should be in contrib. Contrib isn't really an >> easier >> > > > way to get stuff into django, it still has to satisfy a bunch of >> > > > conditions like the rest of the code in the core. >> > >> > > > The real question is not "can it be included?" but why is it a >> problem >> > > > that this is a third party lib at the moment? Is there a strong case >> > > > that it be better if it was part of django core or does it do its >> job >> > > > just fine the way it is now? >> > >> > > > David >> > >> > > > On Thu, Sep 16, 2010 at 3:09 PM, David P. Novakovic >> > >> > > > wrote: >> > > > > I don't want to sound negative, but answering your own question >> before >> > > > > anyone else can doesn't change the answer ;) >> > >> > > > > D >> > >> > > > > On Thu, Sep 16, 2010 at 3:00 PM, Yo-Yo Ma < >> baxterstock...@gmail.com> >> > > wrote: >> > > > >> Is there any plans to incorporatehttp:// >> > > github.com/SmileyChris/easy-thumbnails/ >> > > > >> into django.contrib? I have seen so many apps/libraries come into >> and >> > > > >> go out of existence ( >> http://code.djangoproject.com/wiki/ThumbNailsfor >> > > > >> instance mentions sorl-thumbnails which is no longer being >> developed). >> > > > >> I just turned the key with easy-thumbnails and voila. It's like >> magic, >> > > > >> but not. It's easy enough to see what's going on behind the >> scenes. >> > >> > > > >> This is something that, with the help of the core and other >> > > > >> contributors, could be really great. It works for me as it it is, >> but >> > > > >> it may not work for a more "enterprise" application that uses S3, >> etc.
Re: Inclusion of easy-thumbnails into Django Contrib
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 being fully supported. To be honest, I'm even on the fence myself, but it's worth mentioning for others to weigh in. On Sep 16, 10:55 am, Chuck Harmston wrote: > 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 included to contrib, you'll need to make a > compelling case that the community will gain by its inclusion in contrib. > Yes, easy-thumbnails is great, but the only argument you've provided is that > you don't want development to die, as it did on sorl_thumbnails (which is > still a functional piece of software, by the way). That's a legitimate fear, > but where do you draw the line? What about django-registration? Or > django-taggit? > > Further discussion from DjangoCon (skip ahead to 22:12 for discussion on > contrib, though I recommend the entire > talk):http://djangocon.blip.tv/file/4112452/ > > On Thu, Sep 16, 2010 at 12:41 PM, Brian O'Connor wrote: > > > > > 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 allow people to use another package if they don't like it. > > > On Thu, Sep 16, 2010 at 12:37 PM, Yo-Yo Ma wrote: > > >> 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, 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 was the de facto standard > >> for > >> > getting thumbnails in to Django, and I think it has just as much of a > >> place > >> > in Django contrib as some of the other contrib apps do. I don't think > >> it > >> > belongs in the core, but contrib seems like an excellent place for it to > >> go > >> > along with the other batteries in the pack. > > >> > On Thu, Sep 16, 2010 at 12:24 PM, Yo-Yo Ma > >> wrote: > >> > > 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's not to say that we don't need > >> > > "contrib.comments", just that I wouldn't want to lose easy_thumbnails. > > >> > > On Sep 15, 11:32 pm, "David P. Novakovic" > >> > > wrote: > >> > > > Actually, that really did sound negative. Sorry :) > > >> > > > Is there a trac ticket open to address this issue? Generally it'd be > >> > > > better to get discussion happening over a ticket and if there are > >> > > > serious issues that need to be addressed then they can be discussed > >> > > > here. > > >> > > > I know it'd be nice to get things like easy-thumbnails accepted into > >> > > > django.contrib , but the truth is that this probably falls outside > >> of > >> > > > things that that should be in contrib. Contrib isn't really an > >> easier > >> > > > way to get stuff into django, it still has to satisfy a bunch of > >> > > > conditions like the rest of the code in the core. > > >> > > > The real question is not "can it be included?" but why is it a > >> problem > >> > > > that this is a third party lib at the moment? Is there a strong case > >> > > > that it be better if it was part of django core or does it do its > >> job > >> > > > just fine the way it is now? > > >> > > > David > > >> > > > On Thu, Sep 16, 2010 at 3:09 PM, David P. Novakovic > > >> > > > wrote: > >> > > > > I don't want to sound negative, but answering your own question > >> before > >> > > > > anyone else can doesn't change the answer ;) > > >> > > > > D > > >> > > > > On Thu, Sep 16, 2010 at 3:00 PM, Yo-Yo Ma < > >> baxterstock...@gmail.com> > >> > > wrote: > >> > > > >> Is there any plans to incorporatehttp:// > >> > > github.com/SmileyChris/easy-thumbnails/ > >> > > > >> into django.contrib? I have seen so many apps/libraries come into > >> and > >
re: Allow context processors access to current version of context
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 be easily > done with another argument, context, and also backwards compatible. > Functions would only get additional argument if they are defined to > get two arguments and whatever they would return would override that > in the context. > > http://code.djangoproject.com/ticket/13841 > > Mitar I came upon your ticket whilst triaging and feel that the best way to advance your issue is to present a clear and concise use case of where modifying a context is useful. The design of the context is such that it is a list of dictionaries, while I'm new to the internals - someone else could speak as to why the the original design is such that the last line of RequestContext is: self.update(processor(request)) instead of: processor(request, self) in otherwords why contexts are passed around for modification - and instead are updated. I think the patch for your ticket would be as simple as changing it to: self.update(processor(request,context=self)) Again - being new to internals I'm not sure what ramifications that would have. But in attempting to triage your ticket, maybe this post will act as a foil for discussion. -Preston -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Inclusion of easy-thumbnails into Django Contrib
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 and promote auth and sessions to core but > done in a way that is pluggable. The reasoning behind this opinion is that > it leaves the surface area in the project smaller to maintain and it's really > not that hard to add a sorl-thumbnail external app to a Django project. > Furthermore, it provides more freedom for these apps to mature and develop at > their own pace. > > I realize I could very well be in a minority opinion here, but thought I'd > throw it into the mix nonetheless. Another vote for evolving away from contrib. My hope is that one day http://djangopackages.com/ will become packages.djangoproject.com (and along with that a management command startapp-dist which starts a distributable skeleton) -Preston > > On Sep 16, 2010, at 11:33 AM, Brian O'Connor wrote: > > > > > 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 was the de facto standard for > > getting thumbnails in to Django, and I think it has just as much of a place > > in Django contrib as some of the other contrib apps do. I don't think it > > belongs in the core, but contrib seems like an excellent place for it to go > > along with the other batteries in the pack. > > > On Thu, Sep 16, 2010 at 12:24 PM, Yo-Yo Ma wrote: > > 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's not to say that we don't need > > "contrib.comments", just that I wouldn't want to lose easy_thumbnails. > > > On Sep 15, 11:32 pm, "David P. Novakovic" > > wrote: > > > Actually, that really did sound negative. Sorry :) > > > > Is there a trac ticket open to address this issue? Generally it'd be > > > better to get discussion happening over a ticket and if there are > > > serious issues that need to be addressed then they can be discussed > > > here. > > > > I know it'd be nice to get things like easy-thumbnails accepted into > > > django.contrib , but the truth is that this probably falls outside of > > > things that that should be in contrib. Contrib isn't really an easier > > > way to get stuff into django, it still has to satisfy a bunch of > > > conditions like the rest of the code in the core. > > > > The real question is not "can it be included?" but why is it a problem > > > that this is a third party lib at the moment? Is there a strong case > > > that it be better if it was part of django core or does it do its job > > > just fine the way it is now? > > > > David > > > > On Thu, Sep 16, 2010 at 3:09 PM, David P. Novakovic > > > > wrote: > > > > I don't want to sound negative, but answering your own question before > > > > anyone else can doesn't change the answer ;) > > > > > D > > > > > On Thu, Sep 16, 2010 at 3:00 PM, Yo-Yo Ma > > > > wrote: > > > >> Is there any plans to > > > >> incorporatehttp://github.com/SmileyChris/easy-thumbnails/ > > > >> into django.contrib? I have seen so many apps/libraries come into and > > > >> go out of existence (http://code.djangoproject.com/wiki/ThumbNailsfor > > > >> instance mentions sorl-thumbnails which is no longer being developed). > > > >> I just turned the key with easy-thumbnails and voila. It's like magic, > > > >> but not. It's easy enough to see what's going on behind the scenes. > > > > >> This is something that, with the help of the core and other > > > >> contributors, could be really great. It works for me as it it is, but > > > >> it may not work for a more "enterprise" application that uses S3, etc. > > > >> It might not be highly efficient (I wouldn't know). It might have bugs > > > >> that I just haven't noticed yet. I'm mentioning all of this because I > > > >> know somebody will say, "Why move it into Django if it's doing just > > > >> fine as a separate project?". After experiencing the bliss I thought > > > >> I'd drop a line here about it, and see what you guys thought. > > > > >> -- > > > >> You received this message because you are subscribed to the Google > > > >> Groups "Django developers" group. > > > >> To post to this group, send email to > > > >> django-develop...@googlegroups.com. > > > >> To unsubscribe from this group, send email to > > > >> django-developers+unsubscr...@googlegroups.com. > > > >> For more options, visit this group > > >
Re: ModelForm possible validation bug
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 the ticket. http://code.djangoproject.com/ticket/14234 -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Inclusion of easy-thumbnails into Django Contrib
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 processing backends, it may make a bit more sense for inclusion, but as it stands, I'm -1. -justin [0]: http://jacobian.org/writing/what-is-django-contrib/ On Thu, Sep 16, 2010 at 1:26 PM, ptone wrote: > > > 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 and promote auth and sessions to core but >> done in a way that is pluggable. The reasoning behind this opinion is that >> it leaves the surface area in the project smaller to maintain and it's >> really not that hard to add a sorl-thumbnail external app to a Django >> project. Furthermore, it provides more freedom for these apps to mature and >> develop at their own pace. >> >> I realize I could very well be in a minority opinion here, but thought I'd >> throw it into the mix nonetheless. > > Another vote for evolving away from contrib. > > My hope is that one day http://djangopackages.com/ will become > packages.djangoproject.com > > (and along with that a management command startapp-dist which starts a > distributable skeleton) > > -Preston > >> >> On Sep 16, 2010, at 11:33 AM, Brian O'Connor wrote: >> >> >> >> > 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 was the de facto standard for >> > getting thumbnails in to Django, and I think it has just as much of a >> > place in Django contrib as some of the other contrib apps do. I don't >> > think it belongs in the core, but contrib seems like an excellent place >> > for it to go along with the other batteries in the pack. >> >> > On Thu, Sep 16, 2010 at 12:24 PM, Yo-Yo Ma >> > wrote: >> > 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's not to say that we don't need >> > "contrib.comments", just that I wouldn't want to lose easy_thumbnails. >> >> > On Sep 15, 11:32 pm, "David P. Novakovic" >> > wrote: >> > > Actually, that really did sound negative. Sorry :) >> >> > > Is there a trac ticket open to address this issue? Generally it'd be >> > > better to get discussion happening over a ticket and if there are >> > > serious issues that need to be addressed then they can be discussed >> > > here. >> >> > > I know it'd be nice to get things like easy-thumbnails accepted into >> > > django.contrib , but the truth is that this probably falls outside of >> > > things that that should be in contrib. Contrib isn't really an easier >> > > way to get stuff into django, it still has to satisfy a bunch of >> > > conditions like the rest of the code in the core. >> >> > > The real question is not "can it be included?" but why is it a problem >> > > that this is a third party lib at the moment? Is there a strong case >> > > that it be better if it was part of django core or does it do its job >> > > just fine the way it is now? >> >> > > David >> >> > > On Thu, Sep 16, 2010 at 3:09 PM, David P. Novakovic >> >> > > wrote: >> > > > I don't want to sound negative, but answering your own question before >> > > > anyone else can doesn't change the answer ;) >> >> > > > D >> >> > > > On Thu, Sep 16, 2010 at 3:00 PM, Yo-Yo Ma >> > > > wrote: >> > > >> Is there any plans to >> > > >> incorporatehttp://github.com/SmileyChris/easy-thumbnails/ >> > > >> into django.contrib? I have seen so many apps/libraries come into and >> > > >> go out of existence (http://code.djangoproject.com/wiki/ThumbNailsfor >> > > >> instance mentions sorl-thumbnails which is no longer being developed). >> > > >> I just turned the key with easy-thumbnails and voila. It's like magic, >> > > >> but not. It's easy enough to see what's going on behind the scenes. >> >> > > >> This is something that, with the help of the core and other >> > > >> contributors, could be really great. It works for me as it it is, but >> > > >> it may not work for a more "enterprise" application that uses S3, etc. >> > > >> It might not be highly efficient (I wouldn't know). It might have bugs >> > > >> that I just haven't noticed yet. I'm mentioning all of this because I >> > >
Re: Speed testing Django
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 earlier this year that started developing a > benchmark set that could be used; results so far can be found here: > > http://github.com/jacobian/djangobench > > However, there's still a lot of work to do to build up the benchmark > set and deploy it in a continuous integration environment. I'm not > aware of anyone specifically coordinating this benchmark work at the > moment, so if you want to step up and make this your contribution, > feel free to do so! the benchmarks project seems mostly like a high level comparison of x is faster or slower than y It is not so much about profiling. The problem with some profiling approaches, is it involves going in and adding profiling code to cover the whole project analogous to testing. enter Dtrace - which can expose profiling hooks at a very low level. Since the test suite is a pretty good coverage python, I started there. But this could be used to watch a test server with a faux site being hammered by test clients to give a real world performance view. So I did a quick experiment using a Dtrace recipe from the Dtrace toolkit [1] called py_cputime.d I ran the current trunk test suite while probing. I made no effort to exclude setup and teardown. There seems to be some limitations of the Dtrace support in the Python I was using (OSX 10.6.3) in that I was getting some reports of dynamic variable drops to stderr. However I think the results are still very interesting and as a technique, show a lot of promise: http://ptone.com/misc/django-dtrace.txt The report shows for each function a count, an Exclusive function on- CPU time, and Inclusive function on-CPU time At a glance - this shows you where Django is spending most of its time. It doesn't say anything about whether that time is unavoidable or required - just where to look for some possible lower hanging performance fruit. -Preston [1] http://hub.opensolaris.org/bin/view/Community+Group+dtrace/dtracetoolkit > > Yours, > Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Inclusion of easy-thumbnails into Django Contrib
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 %} tag, but why it doesn't provide {%
thumbnail %} tag?
Thumbnails are very common pattern.
Maybe this application (easy_thumbnails) is not the best choice, but
the general idea of having good and popular reusable thumbnail
solution distributed with django is very attractive to me.
On Fri, Sep 17, 2010 at 12:35 AM, Justin Lilly wrote:
> 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 processing backends, it may make a bit more sense
> for inclusion, but as it stands, I'm -1.
>
> -justin
>
> [0]: http://jacobian.org/writing/what-is-django-contrib/
>
> On Thu, Sep 16, 2010 at 1:26 PM, ptone wrote:
>>
>>
>> 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 and promote auth and sessions to core but
>>> done in a way that is pluggable. The reasoning behind this opinion is that
>>> it leaves the surface area in the project smaller to maintain and it's
>>> really not that hard to add a sorl-thumbnail external app to a Django
>>> project. Furthermore, it provides more freedom for these apps to mature
>>> and develop at their own pace.
>>>
>>> I realize I could very well be in a minority opinion here, but thought I'd
>>> throw it into the mix nonetheless.
>>
>> Another vote for evolving away from contrib.
>>
>> My hope is that one day http://djangopackages.com/ will become
>> packages.djangoproject.com
>>
>> (and along with that a management command startapp-dist which starts a
>> distributable skeleton)
>>
>> -Preston
>>
>>>
>>> On Sep 16, 2010, at 11:33 AM, Brian O'Connor wrote:
>>>
>>>
>>>
>>> > 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 was the de facto
>>> > standard for getting thumbnails in to Django, and I think it has just as
>>> > much of a place in Django contrib as some of the other contrib apps do.
>>> > I don't think it belongs in the core, but contrib seems like an excellent
>>> > place for it to go along with the other batteries in the pack.
>>>
>>> > On Thu, Sep 16, 2010 at 12:24 PM, Yo-Yo Ma
>>> > wrote:
>>> > 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's not to say that we don't need
>>> > "contrib.comments", just that I wouldn't want to lose easy_thumbnails.
>>>
>>> > On Sep 15, 11:32 pm, "David P. Novakovic"
>>> > wrote:
>>> > > Actually, that really did sound negative. Sorry :)
>>>
>>> > > Is there a trac ticket open to address this issue? Generally it'd be
>>> > > better to get discussion happening over a ticket and if there are
>>> > > serious issues that need to be addressed then they can be discussed
>>> > > here.
>>>
>>> > > I know it'd be nice to get things like easy-thumbnails accepted into
>>> > > django.contrib , but the truth is that this probably falls outside of
>>> > > things that that should be in contrib. Contrib isn't really an easier
>>> > > way to get stuff into django, it still has to satisfy a bunch of
>>> > > conditions like the rest of the code in the core.
>>>
>>> > > The real question is not "can it be included?" but why is it a problem
>>> > > that this is a third party lib at the moment? Is there a strong case
>>> > > that it be better if it was part of django core or does it do its job
>>> > > just fine the way it is now?
>>>
>>> > > David
>>>
>>> > > On Thu, Sep 16, 2010 at 3:09 PM, David P. Novakovic
>>>
>>> > > wrote:
>>> > > > I don't want to sound negative, but answering your own question before
>>> > > > anyone else can doesn't change the answer ;)
>>>
>>> > > > D
>>>
>>> > > > On Thu, Sep 16, 2010 at 3:00 PM, Yo-Yo Ma
>>> > > > wrote:
>>> > > >> Is there any plans to
>>> > > >> incorporatehttp://github.com/SmileyChris/easy-thumbnails/
>>> > > >> into django.contrib? I have seen so many apps/l
Re: Inclusion of easy-thumbnails into Django Contrib
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.com wrote:
> 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 %} tag, but why it doesn't provide {%
> thumbnail %} tag?
>
> Thumbnails are very common pattern.
>
> Maybe this application (easy_thumbnails) is not the best choice, but
> the general idea of having good and popular reusable thumbnail
> solution distributed with django is very attractive to me.
>
> On Fri, Sep 17, 2010 at 12:35 AM, Justin Lilly wrote:
>> 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 processing backends, it may make a bit more sense
>> for inclusion, but as it stands, I'm -1.
>>
>> -justin
>>
>> [0]: http://jacobian.org/writing/what-is-django-contrib/
>>
>> On Thu, Sep 16, 2010 at 1:26 PM, ptone wrote:
>>>
>>>
>>> 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 and promote auth and sessions to core
but done in a way that is pluggable. The reasoning behind this opinion is
that it leaves the surface area in the project smaller to maintain and
it's really not that hard to add a sorl-thumbnail external app to a Django
project. Furthermore, it provides more freedom for these apps to mature
and develop at their own pace.
I realize I could very well be in a minority opinion here, but thought I'd
throw it into the mix nonetheless.
>>>
>>> Another vote for evolving away from contrib.
>>>
>>> My hope is that one day http://djangopackages.com/ will become
>>> packages.djangoproject.com
>>>
>>> (and along with that a management command startapp-dist which starts a
>>> distributable skeleton)
>>>
>>> -Preston
>>>
On Sep 16, 2010, at 11:33 AM, Brian O'Connor wrote:
> 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 was the de facto
> standard for getting thumbnails in to Django, and I think it has just as
> much of a place in Django contrib as some of the other contrib apps do.
> I don't think it belongs in the core, but contrib seems like an
> excellent place for it to go along with the other batteries in the pack.
> On Thu, Sep 16, 2010 at 12:24 PM, Yo-Yo Ma
> wrote:
> 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's not to say that we don't need
> "contrib.comments", just that I wouldn't want to lose easy_thumbnails.
> On Sep 15, 11:32 pm, "David P. Novakovic"
> wrote:
> > Actually, that really did sound negative. Sorry :)
> > Is there a trac ticket open to address this issue? Generally it'd be
> > better to get discussion happening over a ticket and if there are
> > serious issues that need to be addressed then they can be discussed
> > here.
> > I know it'd be nice to get things like easy-thumbnails accepted into
> > django.contrib , but the truth is that this probably falls outside of
> > things that that should be in contrib. Contrib isn't really an easier
> > way to get stuff into django, it still has to satisfy a bunch of
> > conditions like the rest of the code in the core.
> > The real question is not "can it be included?" but why is it a problem
> > that this is a third party lib at the moment? Is there a strong case
> > that it be better if it was part of django core or does it do its job
> > just fine the way it is now?
> > David
> > On Thu, Sep 16, 2010 at 3:09 PM
Re: Inclusion of easy-thumbnails into Django Contrib
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 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.com
> wrote:
> > 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 %} tag, but why it doesn't provide {%
> > thumbnail %} tag?
> >
> > Thumbnails are very common pattern.
> >
> > Maybe this application (easy_thumbnails) is not the best choice, but
> > the general idea of having good and popular reusable thumbnail
> > solution distributed with django is very attractive to me.
> >
> > On Fri, Sep 17, 2010 at 12:35 AM, Justin Lilly
> wrote:
> >> 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 processing backends, it may make a bit more sense
> >> for inclusion, but as it stands, I'm -1.
> >>
> >> -justin
> >>
> >> [0]: http://jacobian.org/writing/what-is-django-contrib/
> >>
> >> On Thu, Sep 16, 2010 at 1:26 PM, ptone wrote:
> >>>
> >>>
> >>> 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 and promote auth and sessions to
> core but done in a way that is pluggable. The reasoning behind this opinion
> is that it leaves the surface area in the project smaller to maintain and
> it's really not that hard to add a sorl-thumbnail external app to a Django
> project. Furthermore, it provides more freedom for these apps to mature and
> develop at their own pace.
>
> I realize I could very well be in a minority opinion here, but thought
> I'd throw it into the mix nonetheless.
> >>>
> >>> Another vote for evolving away from contrib.
> >>>
> >>> My hope is that one day http://djangopackages.com/ will become
> >>> packages.djangoproject.com
> >>>
> >>> (and along with that a management command startapp-dist which starts a
> >>> distributable skeleton)
> >>>
> >>> -Preston
> >>>
>
> On Sep 16, 2010, at 11:33 AM, Brian O'Connor wrote:
>
>
>
> > 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 was the de facto standard
> for getting thumbnails in to Django, and I think it has just as much of a
> place in Django contrib as some of the other contrib apps do. I don't think
> it belongs in the core, but contrib seems like an excellent place for it to
> go along with the other batteries in the pack.
>
> > On Thu, Sep 16, 2010 at 12:24 PM, Yo-Yo Ma <
> baxterstock...@gmail.com> wrote:
> > 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's not to say that we don't need
> > "contrib.comments", just that I wouldn't want to lose
> easy_thumbnails.
>
> > On Sep 15, 11:32 pm, "David P. Novakovic" >
> > wrote:
> > > Actually, that really did sound negative. Sorry :)
>
> > > Is there a trac ticket open to address this issue? Generally it'd
> be
> > > better to get discussion happening over a ticket and if there are
> > > serious issues that need to be addressed then they can be
> discussed
> > > here.
>
> > > I know it'd be nice to get things like easy-thumbnails accepted
> into
> > > django.contrib , but the truth is that this probably falls outside
> of
> > > things that that should be in contrib. Contrib isn't really an
> easier
> > > way to get stuff into django, it still has to satisfy a bunch of
> > > conditions like the rest of the code i
Re: Inclusion of easy-thumbnails into Django Contrib
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 developing your own plugins easier, and leaving
those plugins out of the core or contrib. That's not to say I would
like to have thumbnailing built in still, but in the interest of the
greater good I now officially "flip flop". I think Alex made some
really compelling arguments. If Django as a core web framework worked
way better (It's excellent now, but it could be better performing,
upgraded quicker, easier to plug things into (more modularity at some
levels), and acted only as an ORM / Template / Sessions framework at
some future point, perhaps the satelite projects (such as "easy-
thumbnails") would be more plentiful and better. More competition
equals better quality (or price fixing, but I digress). Today I
visited http://djangopackages.com/ (linked above) for the first time.
This sort of things is excellent and promotes progress, without
halting evolution just to make the whiners (ie, me 1 hour ago) happy
with cheap built-ins. Gosh, I really pulled a John Kerry on this one;
sorry.
My vote on my own idea is -2 (one to reverse the initial proposal)
On Sep 16, 3:39 pm, "David P. Novakovic"
wrote:
> 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.com wrote:
> > 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 %} tag, but why it doesn't provide {%
> > thumbnail %} tag?
>
> > Thumbnails are very common pattern.
>
> > Maybe this application (easy_thumbnails) is not the best choice, but
> > the general idea of having good and popular reusable thumbnail
> > solution distributed with django is very attractive to me.
>
> > On Fri, Sep 17, 2010 at 12:35 AM, Justin Lilly
> > wrote:
> >> 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 processing backends, it may make a bit more sense
> >> for inclusion, but as it stands, I'm -1.
>
> >> -justin
>
> >> [0]:http://jacobian.org/writing/what-is-django-contrib/
>
> >> On Thu, Sep 16, 2010 at 1:26 PM, ptone wrote:
>
> >>> 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 and promote auth and sessions
> to core but done in a way that is pluggable. The reasoning behind this
> opinion is that it leaves the surface area in the project smaller to
> maintain and it's really not that hard to add a sorl-thumbnail external
> app to a Django project. Furthermore, it provides more freedom for
> these apps to mature and develop at their own pace.
>
> I realize I could very well be in a minority opinion here, but thought
> I'd throw it into the mix nonetheless.
>
> >>> Another vote for evolving away from contrib.
>
> >>> My hope is that one dayhttp://djangopackages.com/will become
> >>> packages.djangoproject.com
>
> >>> (and along with that a management command startapp-dist which starts a
> >>> distributable skeleton)
>
> >>> -Preston
>
> On Sep 16, 2010, at 11:33 AM, Brian O'Connor wrote:
>
> > 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 was the de facto
> > standard for getting thumbnails in to Django, and I think it has just
> > as much of a place in Django contrib as some of the other contrib apps
> > do. I don't think it belongs in the core, but contrib seems like an
> > excellent place for it to go along with the other batteries in the
> > pack.
>
> > On Thu, Sep 16, 2010 at 12:24 PM, Yo-Yo Ma
> > wrote:
> > I have no data to support the foll
Re: Inclusion of easy-thumbnails into Django Contrib
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 template tag? Is it a specially crafted URL with GET params, or maybe REST? - The storage for the thumbnails. Local files? S3 storage? Rackspace Cloud Files? Maybe a cache backend? Something weird? And how to invalidate cache images? Clean the cache if the original is gone? As such, IMO is too hard to ship something so big and so opinionated as a thumbnails solution on contrib. It's also so decoupled from Django internals (it should depend just on a File object, and maybe provide template tags) that it can live as a separate module just fine. Please consider Django aim is to be a framework, not a generic turn- key solution for making sites (although it's easy to get started). On Sep 16, 2:00 am, Yo-Yo Ma wrote: > Is there any plans to > incorporatehttp://github.com/SmileyChris/easy-thumbnails/ > into django.contrib? I have seen so many apps/libraries come into and > go out of existence (http://code.djangoproject.com/wiki/ThumbNailsfor > instance mentions sorl-thumbnails which is no longer being developed). > I just turned the key with easy-thumbnails and voila. It's like magic, > but not. It's easy enough to see what's going on behind the scenes. > > This is something that, with the help of the core and other > contributors, could be really great. It works for me as it it is, but > it may not work for a more "enterprise" application that uses S3, etc. > It might not be highly efficient (I wouldn't know). It might have bugs > that I just haven't noticed yet. I'm mentioning all of this because I > know somebody will say, "Why move it into Django if it's doing just > fine as a separate project?". After experiencing the bliss I thought > I'd drop a line here about it, and see what you guys thought. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
