Re: Why is GeoDjango in core ?
The only historically-accurate answer is: "because it seemed like a good idea at the time." Remember, this was 2008. So one problem was that Django's DB APIs weren't very polished, so GeoDjango had to do a bunch of trickery. Bringing it into core gave a good way towards pushing that flexibility down into the DB layer. Further, Python packaging was in a sorry state; keeping a version of GeoDjango installed and in sync with a version of Django wasn't exactly easy (the tight coupling between GeoDjango and Django means that you really need to versions to match up.) Finally, GeoDjango was an incredibly powerful addition to Django, something that wasn't available in any other web framework. Having it available out of the box really set us ahead of all other tools, at least in the GIS space. How much of this is still true is left as an exercise to the reader. Jacob PS: I'm not exactly sure what you mean by the admin being a candidate for removal. I don't think anyone's suggesting that, at least not seriously. On Wed, Feb 6, 2013 at 1:20 PM, Maxime Haineault wrote: > I've seen lot of talk about removing the admin and many other contribs from > core. > > For some I think it make sense, for others like the admin I'm not so sure. > > However, I have not seen any talk about removing GeoDjango and I'm wondering > about the > rational of keeping this relatively huge domain specific codebase in django. > > In the last five years i worked on at least 150 django projects, every > single one of them used > the admin and only one required GeoDjango. > > I'm not advocating that it should be removed, but I can't help but wonder > why the admin would > be a good candidate for removal and not GeoDjango. > > Regards > > -- > 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-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at http://groups.google.com/group/django-developers?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > -- 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-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Why is GeoDjango in core ?
I've seen lot of talk about removing the admin and many other contribs from core. For some I think it make sense, for others like the admin I'm not so sure. However, I have not seen any talk about removing GeoDjango and I'm wondering about the rational of keeping this relatively huge domain specific codebase in django. In the last five years i worked on at least 150 django projects, every single one of them used the admin and only one required GeoDjango. I'm not advocating that it should be removed, but I can't help but wonder why the admin would be a good candidate for removal and not GeoDjango. Regards -- 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-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Maintenance on djangoproject.com tomorrow
Hi folks, We've scheduled maintenance operations on djangoproject.com tomorrow, starting at 09:00 UTC. The website and the docs may be temporarily unavailable. Please use the mirror of the docs at Read The Docs in the meantime: http://django.readthedocs.org/ Thanks, -- Aymeric. -- 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-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Problem with Custom Manage.py command and Crontab
Please ask questions about using Django on django-users. The topic of this list is the development of Django itself. Thanks, Karen -- 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-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Problem with Custom Manage.py command and Crontab
Hey guys, I need a little bit help with a custom manage.py command called *test* I am using it in a virtualenv on a shell script *script.sh*, if i execute *python manage.py script.sh * All is OK, but if the script is on the crontab give a *Unknown command: 'test'* . Here is the code: http://dpaste.org/hjaVi/ , Any help ? Thank you -- 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-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Ticket 19237
... if we're concerned about strip_tags' ability to hit this kind of edge case, why are we using regex? http://stackoverflow.com/questions/1732348/regex-match-open-tags-except-xhtml-self-contained-tags/1732454#1732454 Or more generally http://www.codinghorror.com/blog/2009/11/parsing-html-the-cthulhu-way.html. On Saturday, November 17, 2012 1:01:33 AM UTC-8, Chris Khoo wrote: > > Hi > > I was wondering if one of the core developers could have a look at ticket > #19237 and progress it forward - > https://code.djangoproject.com/ticket/19237 > > It basically makes django.utils.html.strip_tags a little smarter. > > Thanks > > Chris > -- 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-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Could prefetch_related be modified to utilize select_related for ForeignKey relations?
A better way of achieving this functionality would be the API proposed
in https://code.djangoproject.com/ticket/17001
Marc
On Wednesday, 6 February 2013 00:29:15 UTC, Michal Novotný wrote:
>
> Hey, what about this
> one: qs.prefetch_related('best_pizza__toppings__topping_type_*')
>
> It is intuitive and simple. But of course, that would mean to add wildcard
> support everywhere.
>
> On Sunday, February 19, 2012 11:18:20 PM UTC+1, Yo-Yo Ma wrote:
>>
>> Speaking with regards to the ORM method documented at
>>
>> https://docs.djangoproject.com/en/dev/ref/models/querysets/#prefetch-related
>>
>> Of course, ``prefetch_related`` uses a Pythonic join to attach reverse-
>> related objects and avoids the N+1 queries problem, which of course is
>> great. However, if you use it like this:
>>
>> >>>
>> Restaurant.objects.prefetch_related('best_pizza__toppings__topping_type')
>>
>> It doesn't seem to take advantage ``select_related`` (assuming that
>> ``topping_type`` is a ``ForeignKey`` from ``Topping``. It instead
>> sends a separate query for ``Topping`` and ``ToppingType``, joining
>> them in Python. Is it feasible to modify ``prefetch_related`` use
>> ``select_related`` when it encounters a ``ForeignKey``?
>
>
--
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
