Re: Release process suggestion: recruit platform expert install testers
Hi Karen, On Thu, Jun 26, 2008 at 12:41 PM, Karen Tracey <[EMAIL PROTECTED]> wrote: > I have a suggestion to help ensure that Django 1.0 gives a good first > impression to new users: line up some install testers for the gamut of > supported platforms, and have these testers verify (prior to release) that > the documented installation procedure works correctly on their platform. Can we add the tutorial to the mix? It's very, very good. But, we still get lots of questions. It seems somewhere along the line there's an order of events problem that trips people up. That may have been corrected, but if not it would be good for it to have some testing and feedback. Michael Trier blog.michaeltrier.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Community search [was: Django community aggregator and non-English posts]
Django Search (http://djangosearch.com/) – great aggregator and Google custom search of community blogs and projects by Alex Aster. Also check out his blog for some interesting posts. Django Blog Search (http://www.google.com/coop/cse?cx=012993260288651340677%3A3fwy29agfd4) by Kevin Fricovsky Django Search (http://timsloan.net/?page_id=42) – similar solution by Tim Sloan. Michael Trier blog.michaeltrier.com On Fri, Jun 13, 2008 at 1:32 PM, Tom Tobin <[EMAIL PROTECTED]> wrote: > > On Fri, Jun 13, 2008 at 12:25 PM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: >> >> Also for anyone interested, there's this: >> >> http://djangosearch.com/ > > Well. Damn. That looks like what we're talking about here. > > I wonder if it indexes everything the "official" aggregator does? > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: QSRF Related
> 1) order_by() resets the ordering, but select_related() does not. > Would it not make more sense to keep APIs the same? So something like > order_by(False) and a similar option for select_related? David, I asked about order_by not working generitively here (http://groups.google.com/group/django-developers/browse_thread/thread/fb195cbcda2e4b44/f85fb54382a7847a?#f85fb54382a7847a). You might want to read that thread. Michael Trier http://blog.michaeltrier.com/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Vacation... meetups?
> I thought I'd give a quick note so nobody wonders: I'll be on an > extended vacation April 21 - May 17th. I'll be checking email > sporadically, but don't really expect anything from me while I'm gone. > While I'm gone, of course, decisions and work should just go on > without me -- I can safely assume that Adrian, Malcolm, et al. will > easily be able to make decisions without my vote. Have a blast. You deserve it. Michael Trier blog.michaeltrier.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Generative values() Does not Work
> > Although, you have a point, I have to say that limitation in order_by > > bugs me as well. :) > > I think that's a case of learning to live with your disappointment. It > would lead to a lot of counter-intuitive behaviour to make order_by() > incremental, because the *first* ordering condition is the main sorting > column and then equal values are sorted by the second, etc (that's the > way SQL works). So if you *added* an extra order_by(...) constraint it > would have no effect in the current system. We'd have to say that > order_by(...) would be applied in reverse order, which will make > people's brains hurt, because it's entirely non-obvious. I apologize that my off-handed comment caused you to go into this much explanation, but I appreciate it nonetheless. I see where you're coming from, especially the idea of constraining it further. Thanks again for clarifying. Michael Trier blog.michaeltrier.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Customizable QuerySets
> In my opinion the answer is this: > 1. A BaseQuerySet that all internal Django calls could rely on staying > the same. > 2. A setting (DEFAULT_QUERYSET_CLASS for example) which, by default, > points to BaseQuerySet, but could be changed to point to any sucblass > of BaseQuerySet. > > That's it! Now projects could subclass BaseQuerySet, add any > functionality that they deemed valuable, and Django could use that > whenever any method on a QuerySet is called. FWIW, I like the idea. The more "hooks" added into the framework is a good thing. I also like how your test implementation does not disrupt current structure that is already in place. Michael Trier blog.michaeltrier.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Should manage.py startapp create a urls.py file?
Rob, If you want, check out the django-command-extensions project on Google Code (http://code.google.com/p/django-command-extensions/). I added a create_app command extension that allows you to use a --template option for specifying your app directory structure. If no template is provided a default is created for you which includes a forms.py and a urls.py. It's been on my todo list for a while now, so your discussion item prompted me to get it done. That said it has not been tested much. Michael Trier blog.michaeltrier.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Proposal: deprecated Model.__init__(*args)
> I'd like to deprecate initializing models using positional arguments > (i.e. ``p = Person(1, 'Joe Somebody')``) in favor of only allowing > keyword-argument initialization (i.e. ``p = Person(id=1, name='Joe > Somebody')``). +1 from me. I've been doing some interesting model stuff lately and the positional arguments have caused a lot of headaches. It hasn't bit me yet, but does make it difficult to do some tasks. I'm all in favor of standardizing this stuff. Michael Trier blog.michaeltrier.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Reconsider ADMIN_MEDIA_PREFIX default?
> Over-engineered? A documentation change, plus a one-line config > change? Surely not! What would be the right amount of engineering, > then? Perhaps I misunderstood your proposal. Michael Trier blog.michaeltrier.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Reconsider ADMIN_MEDIA_PREFIX default?
> http://code.djangoproject.com/ticket/2891 was marked as a wontfix by > jacob after "discussion with Malcolm". > > Neither Collin or myself (or several others on IRC) can see a reason > why that this would cause any big disruption. > > Mr Trier even mentions it on his blog today as an example of a silly > default :P > http://blog.michaeltrier.com/2007/12/18/a-kinder-gentler-django Sure blame me. :) I had not seen that ticket when I wrote the post, but I think it's a very good solution. Although I appreciate all the thought that Vinay Sajip put into it, I think the solution he proposes is over-engineered for this situation. The ticket addresses the problem well and causes the least amount of impact. Michael Trier blog.michaeltrier.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Django weekly updates?
> > On 12/8/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > > > > > The same is true of a weekly Django update message. There is > > > absolutely nothing stopping you from writing a weekly blog message and > > > publishing it somewhere. > > Just noticed this post. I'm glad to see that you're getting some stuff together. I really miss Clint's updates as well. For those that enjoy an audio dump, for a commute or something, I've put together a podcast called This Week in Django. It's a bit experimental at this point, but I'm playing around with different ideas. You can find more here: http://blog.michaeltrier.com/2007/12/14/this-week-in-django-episode-001 Michael blog.michaeltrier.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Fixing app_label
On Dec 7, 2007 7:09 AM, Forest Bond <[EMAIL PROTECTED]> wrote: > Hi, > > On Fri, Dec 07, 2007 at 07:25:03PM +1100, Malcolm Tredinnick wrote: > > (or stop using app_loader, which is something I've been tending towards more > > and more lately). > > And how does one do that? > Just remove 'django.template.loaders.app_directories.load_template_source', from the TEMPLATE_LOADERS list in your settings.py module. Then all of your templates would be found via the file system template loader. By the way, I also do not use app loader. Michael Trier blog.michaeltrier.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Reset Management Command Design Issue
> The "Django Way" is essentially to work on the assumption that > everything is as Django left it (or in a state that is compatible with > Django's requirements). We provide handles to make integrating with > legacy databases a little easier (such as allowing specification of > db_column names, etc), but the only part of Django that relies on > introspection beyond the level of "does table X exist" is the > inspectdb command. Everything else uses the model as the canonical > representation. Thanks Russ. Makes sense to me. I think I will add a custom management command to my command extensions project for those that want that sort of thing. Michael Trier blog.michaeltrier.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Django internal tests
Read this page entirely and it should help: http://www.djangoproject.com/documentation/contributing/ specifically regarding running a single test see: http://www.djangoproject.com/documentation/contributing/#running-the-unit-tests Michael Trier blog.michaeltrier.com On Dec 1, 2007 3:53 PM, Marc Fargas <[EMAIL PROTECTED]> wrote: > Hi people, > When one "newbie" wants to create a patch with tests for Django (which > are a requirement for every ticket) he/She can get a bit confused. > > Maybe one knows how to write tests for his/her own applications so the > first thing to try will be something like: > > django//tests.py > > this is only valid with ``contrib`` > (django/contrib//tests.py) > > For the "core" of Django one will go to tests/ and try to figure out how > to put his/her new test in there. > > If the test is a doctest maybe one can handle it (just appending more > text to the existing doctests!) but figuring how to create a unittest is > harder (I still haven't found how to add a new unittest!) > > Maybe docs/contributing.txt could be a bit more specific on how to add > new tests to tests/, it only points users to docs/testing.txt but it's > not "exactly the same". > > (More probably I screwed something when trying to add my unittest!). > > Also, how can one run specific tests inside tests/ ? > > Cheers, > Marc > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
