Re: Call for use cases of metrics in django core
We use django-statsd in conjunction with statsd and rely upon inserting monkey patches into the stack. Having some hooks in Django that can be used to monitor that stuff would be really useful. Currently we've got patches for redis, sql queries, cache queries, template parsing and rendering along with developer generated metrics in the code. -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: QuerySet filtering weirdness for dates with 3-digit years
>From my brief reading of the some docs (eg postgresql) it looks like
dates with less than 4 years do need to be prefixed with a zero, in
the standard date format (some databases let you set different
formats). But since python doesn't output a 0, I can see why its going
wrong:
>>> datetime(999,1,1,1).year
999
Interestingly sqlite uses standard strftime
http://www.sqlite.org/lang_datefunc.html:
%Y year: -
I thought the answer might be to use strftime but:
>>> datetime(999,1,1,1).strftime('%Y')
Traceback (most recent call last):
File "", line 1, in
ValueError: year=999 is before 1900; the datetime strftime() methods
require year >= 1900
Which is this bug: http://bugs.python.org/issue1777412
This isn't a problem that I can imagine many people have run into, so
sounds like a bug needing a patch. Good luck!
--
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
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: #6735 -- Class based generic views: call for comment
On 2010-10-01, at 3:57 PM, David P. Novakovic wrote: > I may be missing something obvious here, so please tell me if I am.. > but couldn't the resolver just check that quacks like something > OOViewish has been passed in and simply branch and init the class > before calling the view in the same way it normally would? That's what I've done on quite a few projects and its worked great. As Russell pointed out I lose decoratoring in urls.py, but that's something I don't use anyway. -- Andy McKay a...@clearwind.ca twitter: @andymckay -- 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: Error email flooding on high traffic production sites
On 2010-09-08, at 8:29 PM, David P. Novakovic wrote: > Hey dude, > > What about something like sentry or lumberjack? Or Arecibo. There's quite a few solutions to this that don't involve sending email. In fact I use the django taking down your email server as an example for Arecibo all the time. This has been discussed at least once, I found following thread, but I bet there's more. http://groups.google.com/group/django-developers/browse_thread/thread/ea8402eef79a68de/4aa93ca80287ed52?hl=en=UTF-8=error+email+production+%22django-developers%22=1 I do think a note in the docs to say that this is can be an issue on high traffic sites and you might want to investigate a plan B, would be appropriate. -- Andy McKay -- 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: Default ordering on User model
On 2010-05-21, at 6:19 AM, Reinout van Rees wrote: > Another data point: Plone has a checkbox for that: "do you have many > users/groups?". If True, several screens don't attempt to list all users, do > sorting, etc. Instead search fields are used. > > So: best of both worlds. But there's of course some extra code here and > there with "if LARGE_AMOUNT_OF_USERS... else ...". In that case for the django admin you specify "raw_id_fields" on your model that has a ForeignKey to users. http://docs.djangoproject.com/en/dev/ref/contrib/admin/#raw-id-fields -- Andy McKay, @andymckay Django Consulting, Training and Support -- 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: Syndication -- plans to add support for CSS stylesheet?
> It would be very helpful to be able to add CSS stylesheets to > syndication feeds. Are there plans for adding this feature in the > future? A search in Trac reveals one ticket added by you: http://code.djangoproject.com/ticket/12978 Adding a ticket is the right way to go. Adding in a patch for your feature is an even better way to go :) -- Andy McKay, @clearwind http://clearwind.ca/djangoski -- 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: Proposal: errors with URLs in them
On 2010-01-21, at 3:53 PM, Russell Keith-Magee wrote: > On Fri, Jan 22, 2010 at 1:35 AM, Andy McKay <a...@clearwind.ca> wrote: >> >> This is of course won't be possible for all errors or all parts of Django, >> but would work for some of the more common errors that crop up regularly. >> Would this be a course worth pursuing? > > I'd say yes - with some caveats. > > Firstly, we need to be careful about casting too wide a net in > catching errors. We don't want to accidentally catch errors and give a > solution that is wrong. We also don't want to hide useful errors under > a 'helpful' blanket (e.g., the way that Django sometimes masks import > errors). If we're going to introduce specific error messages, we need > to make sure they actually refer to a specific problem. Absolutely, this should be used sparingly. It just can be a bit frustrating because some of the start up or import errors can be a bit silent or cryptic. > I'm always hesitant to blame the user for problems like this. If the > user isn't following instructions, maybe the instructions aren't clear > enough. Maybe the error message in question is just too pithy -- > perhaps if they redirected to a single page in the docs that gave a > verbose explanation of the problem (including examples and workarounds > where appropriate), we might be able to avoid a few of these > questions. > However, in the words of Cool Hand Luke: "some folks, you just can't reach". > :-) I think it might help, you are right and we can't save everyone. But I think if we can document the error properly and in some detail somewhere, we'll at least feel good that we've done everything we can. > So - if you can produce a patch that demonstrates 5-10 examples of > patterns that would benefit from an elaborate error message, I > certainly think that patch could find it's way into trunk. Rightio, we'll give it a try a for a few and see how it lookis. Thanks for the -- Andy McKay, @clearwind http://clearwind.ca/djangoski -- 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: What The Enterprise wants from Django
On 2010-01-21, at 9:15 AM, chris.moff...@gmail.com wrote: > I agree that managing settings gets to be a bit difficult in many > environments - even non Fortune 1000 environments. One of the things > we've played with in Satchmo is a database backed solution that allows > you to define reasonable defaults - even override-able in the settings > - but allow people to edit through the admin interface. I've seen that route before and I have to say that I would be strongly against that. The only saving grace could be multi-db which could allow you to have a specific settings database that's separate from the core. Having data and settings intermingled in the same area just causes too many problems. Further, it detracts from the ability to run the project without the database around. In the scenario of a larger environment with more delineation of roles, it may not be possible. -- Andy McKay, @clearwind http://clearwind.ca/djangoski -- 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.
Proposal: errors with URLs in them
One of my favourite errors in Python is this one: File "settings.py", line 2 SyntaxError: Non-ASCII character '\xce' in file settings.py on line 2, but no encoding declared; see http://www.python.org/peps/pep-0263.html for details This is when you've declared a non-ASCII character without the encoding declared. In fact I don't even bother to look up the syntax to make it work, it's easier to put the text in, let it fail and then let python tell me the URL to the syntax. There are common errors that I see being made in putting together Django applications and I'd like to see if we can provide more helpful errors to the user. There are obviously lots of places we can't do this, but I think in some areas we can. One example from #django last night that i've seen a few times is leaving a comma out in INSTALLED_APPS so you have: INSTALLED_APPS = ( 'django.contrib.auth' 'django.contrib.contenttypes', ...) This leads to: Error: No module named authdjango.contrib.contenttypes Which is a pretty confusing error. Supposing this said: Error: No module named authdjango.contrib.contenttypes. See http://djangoproject.com/errors/32 for help. And that page gave lots of detail: This means Django can't find an app from installed apps. This could be because: - You've misspelled it - You've missed a comma in INSTALLED_APPS ... We've already got a page that seems similar to this at: http://code.djangoproject.com/wiki/BetterErrorMessages Ideally such errors would be part of the documentation. This is of course won't be possible for all errors or all parts of Django, but would work for some of the more common errors that crop up regularly. Would this be a course worth pursuing? -- Andy McKay, @clearwind http://clearwind.ca/djangoski -- 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: What The Enterprise wants from Django
On 2010-01-20, at 10:54 AM, Jacob Kaplan-Moss wrote: On Wed, Jan 20, 2010 at 12:31 PM, Luke Plant <l.plant...@cantab.net> wrote: I don't understand how avoiding the settings.py mechanism will produce *more* flexibility. The problem -- at least as I see it -- is that of a intertwingulment of "application" settings with "ops" settings. +1 -- Andy McKay, @clearwind http://clearwind.ca/djangoski -- 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: ManyRelatedManager signals
On Tue, 22 Sep 2009 19:10:19 -0700 (PDT), Stephen Sundell <stephen.sund...@gmail.com> wrote: > Is there a reason not to have a signal before and after creating an > entry into a ManyToMany table. I have a piece of code i need to call > when this relationship is created. I don't know of any signal that > exists already, so I created my own. Thought it might be an > interesting feature to add, unless theres a reason its not there. There a quite a few tickets on this in Trac eg: http://code.djangoproject.com/ticket/5390 Fingers crossed for this in 1.2 -- Andy McKay --~--~-~--~~~---~--~~ 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: ServletContext parallel in Django/wsgi app?
On 24-Jun-09, at 3:47 PM, qwcode wrote: > I didn't get an answer to the post below yet on the users group, maybe > someone here can reply. Just because someone doesn't reply to users, isn't a reason to post on django-dev. This list is not about the development of django itself. Please be patient or try rephrasing the question to django-users. --~--~-~--~~~---~--~~ 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
