Django mail.py Message-ID header
Dear django-developers, At the moment django.core.mail does not set a Message-ID header in the mails it sends. SpamAssassin spots this and says INVALID_MSGID and /or MSGID_NO_HOST. I think the Message-ID is also used for message threading, and matters when you have clustered mail servers. I suggest changing django.core.mail.send_mass_mail to include this section after it sets the 'Date' header: msg['Message-ID'] = "<[EMAIL PROTECTED]>" % ( time.time(), random.getrandbits(64), socket.getfqdn() ) (along with 'import socket, time, random' at the top). This adds a message id according to the format recommended here: http://www.jwz.org/doc/mid.html http://rfc.sunsite.dk/rfc/rfc822.html Does this sound sane ? If so I will submit a proper patch. Thanks, Graham. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Ticket spam
Ville Säävuori wrote: >> I miss the "Week In Review" blog posts from Adrian but surely he's not >> writting those to have more time for coding :) > > Yeah, me too! It's very nice to read something "digested" about ongoing > deveploment (from an insider) because following all trac changes and > dev-list is sometimes not very easy. > > Overall, I think that Django-devs are doing *great* work and > communication in general is very, very good :) > +1 for the week in review And three cheers for the Django devs. Web development has never been so much fun, and so easy ! - Graham. --~--~-~--~~~---~--~~ 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: why not a http server like mongrel?
comechao, What would be the advantage over mod_python in Apache ? Graham. comechao wrote: > Why not create a server like mongrel for Django? > > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
New faster SelectBox.js
Dear django-devs, If you have thousands of entries in a multiple select box in the Django admin interface, the Javascript in SelectBox.js which makes the nice gui widget, runs too slowly, and the browser will complain. We have re-written SelectBox.js (attached or at http://django.pastey.net/3102) to use maps/objects where it used to use lists, changing the complexity of SelectBox.move from quadratic to linear (and I thought big O notation was just for interview questions!). For example on a list of 4000 elements it now iterates 4000 times instead of up to 16 Million (4000*4000). We've had this in production for 3 days now, and all seems well. I'll open a ticket as soon as code.djangoproject.com comes back (OperationalError: database is locked). - Could someone else try this out ? It's an important part of the admin interface and it's changed a lot. I'd like confirmation that it works fine for someone else before I officially submit it for consideration. - SelectBox has a 'sort' method. This didn't seem to be called anywhere. The new version calls it prior to displaying the options in the box, so options are always sorted alphabetically. This makes sense to me, but changes current behavior. What do you think ? Thanks, Graham. PS: If you have lots of elements in your select box, and your object has a FileField (meaning multipart encoding on your form), you might run into an intermittent bug Saving, whereby in http.__init__ on this line: name_dict = parse_header(submessage['Content-Disposition'])[1] parse_header gets give None. This is, believe it or not, a Python email package bug: http://sourceforge.net/tracker/index.php?func=detail&aid=170&group_id=5470&atid=305470 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~--- SelectBox.js Description: JavaScript source
Re: django.contrib.formtools: High-level abstractions of common form tasks
Adrian Holovaty wrote: > On 12/7/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: >> Yes, something along the lines of the wizard control in ASP.NET. >> Ideally, nothing is committed to the db unless all the pages in the >> wizard are validated. Whether this is done by capturing the >> intermediate form data in the session or by rolling back a db >> transaction, I'm not sure. DB transactions seem the natural way to do >> it. > > This would be a great addition. Rather than requiring sessions, what > do you think of passing intermediate form data in hidden fields? It's > simpler, it wouldn't require cookies and I can't immediately think of > any downsides to the approach. > +1 on avoiding sessions. Stateless makes clustering servers so much easier. --~--~-~--~~~---~--~~ 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 with CherryPy 3.0
I have also run up against the 1 connection limit on the dev server. Particularly I was trying to get the server to make a connection to itself to cache the output HTML of a template, so as to serve it as a static file. +1 for anything that makes the dev server multi-threaded. I'm hoping there might be a way to do this without introducing a dependency on CherryPy. Regards, Graham noahz wrote: > > The biggest benefit of this in my case is that CherryPy handles > concurrent requests properly, making certain types of AJAX tasks > possible to develop locally, where django's built in server blocks > concurrent requests. > > It seems like the performance is worse, possibly due to the fact that > I'm still using static.serve a lot locally. But the utility is > certainly higher for heavy ajax development, and even quick and dirty > deployment. > > So I thought I might share my experiment with everyone for discussion. > > Do others see the utility in this? The patch is following, and I could > be prompted to submit it to trac... > --~--~-~--~~~---~--~~ 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 with CherryPy 3.0
Adrian Holovaty wrote: > On 1/22/07, Istvan Albert <[EMAIL PROTECTED]> wrote: >> There is an easy way to turn on multi-threading for the default server, >> see the diff below: > > Graham and/or anybody else who wants multi-threading in the > development server, can you try this patch and see whether it solves > your problem? > > Adrian > Yes, it does. I telnet to 8000 to keep a request open, and make a regular browser request. With the current dev server the browser will hang until I kill the telnet. With the patch the browser responds. +1 from me. I'm going to keep the patch on my local checkout and will report if I notice anything funny. Graham --~--~-~--~~~---~--~~ 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: Some kind of django.contrib.stats?
> > We had to consider both options: > * live stats which tail apache log to track current visitors A very simple view of what's going on right now is provided by Apache's mod_status: http://httpd.apache.org/docs/2.2/mod/mod_status.html > * long term stats which store number of access/page, incoming keywords, etc > > Maybe the second part can be done by AW stats or third party tool as > John suggests. > I also use AWstats for this, except when marketing people are involved then I tend to use Google Analytics. It provides pretty much the same information but keeps them busy longer :-) Graham --~--~-~--~~~---~--~~ 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: mysql microsecond replace error
Yes, it was that. Thank you very much for the help. Dody Suria Wijaya wrote: Your field might be a type of DateTimeField, and you passed a Date object. graham_king wrote: Dear django developers, Using the latest django from SVN with python 2.4.2 and mysql 4.1.14, when I try and save an object with a date in it I get the following error: File "test.py", line 9, in ? -- my code activity.save() -- my code File "/usr/lib64/python2.4/site-packages/django/utils/functional.py", line 3, in _curried return args[0](*(args[1:]+moreargs), **dict(kwargs.items() + morekwargs.items())) File "/usr/lib64/python2.4/site-packages/django/core/meta/__init__.py", line 1012, in method_save db_values = [f.get_db_prep_save(f.pre_save(getattr(self, f.attname), True)) for f in opts.fields if not isinstance(f, AutoField)] File "/usr/lib64/python2.4/site-packages/django/core/meta/fields.py", line 431, in get_db_prep_save value = value.replace(microsecond=0) TypeError: replace() takes no keyword arguments In django/core/meta/fields.py if I comment out these lines (430 and 431): if settings.DATABASE_ENGINE == 'mysql': value = value.replace(microsecond=0) it works fine. Am I missing something ? Thanks in advance, Graham King.
Re: Django Error Display Page
This ticket might be a part of what you're looking for: https://code.djangoproject.com/ticket/11834 It proposes to dim the django parts of the stacktrace, so the code which most likely caused the error stands out better, which is certainly something I'd love to see. There's some similar ideas discussed here: https://groups.google.com/group/django-developers/browse_frm/thread/bd43e2e040a17784/?hl=de&pli=1 On 8 June 2011 03:50, Mateusz Harasymczuk wrote: > Hi, > I have been thinking about this for quite a long time. > Can you make an error display page less verbose? > I mean not to exclude those useful information, but to initially fold (hide) > them. > Fold those items: > - Python path at the top yellow background. > - (Hide or fold) django traceback entries > When I have a problem I have to scroll down (passing django calls) few pages > until I am able to find which MY action caused an error. > I know looking at django callback may be useful, but in my case, hardly > ever, and probably for newcommers also. > I am imagining this like that: > At the top of the error page, there are tabs. > Summary, Traceback, Request, Settings, and copy-paste view (feedback view). > Summary tab, contains this yellow background information with PYTHON_PATH > initially folded, and traceback filtered out to include only information > from project not calls from django itself. > Traceback, request and settings tabs as it is right now, but separated for > easy of view. > copy-paste (feedback) - a standardize view for easy of copy-and-paste to the > Internet message boards, groups and so on... > It would need a template refactor and some more js involved, should not be a > hard thing to do. > I read that there is a plan to redesign an error page, but since then, those > modifications should do the job. > What do you think? > -- > Matt Harasymczuk > http://www.matt.harasymczuk.pl > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/django-developers/-/b0pKaV9JR2gzXzRK. > 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. > -- 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: broken pipe issue with runserver #4444
I'm +1 on this. An exception should only appear on the console if something serious is broken. --~--~-~--~~~---~--~~ 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: ACL
2009/1/7 Malcolm Tredinnick : > > I'm also thinking that requiring evidence of people walking across hot > coals in order to use an application is probably a good pre-requisite > for inclusion in django.contrib. > +1 The gmail ads are conveniently offering me 'Firewalk Teacher Training' and 'Find a Fire-Walk near you', so this shouldn't be too hard to organise :-) --~--~-~--~~~---~--~~ 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: #9344 and policy for small bug reports
Very helpful information from Karen and Russell, thanks. I have written it up for the Contributing section of the FAQ: http://code.djangoproject.com/ticket/10110 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
New in development version or versionadded
Hi, I'm writing docs for a patch (#8348), and wondering how to indicate that that feature is only available in the development version. This used to be: **New in Django development version** but now I think it should be: .. versionadded:: dev however a grep can't find either of the above in the current docs. What is the preferred syntax? Thanks, Graham --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Adding a --delete option to loaddata
I have just submitted a patch / ticket to allow loadata to remove objects that are in the database but not in the fixture. It has docs and tests. http://code.djangoproject.com/ticket/7159 This means loadata can now make an app in a database exactly match the app in the fixture. We use this to publish our staging site to our live site. It makes loadata act like a 'syncdata' command. I hope this is useful to more than just me, and very much welcome feedback on it. Best regards, Graham King --~--~-~--~~~---~--~~ 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: Rethinking silent failures in templates
'warnings' sounds like a subset of 'logging'. In a similar thread (about template tags and filters failing silently) two years ago Simon Willison (who started this thread) said: "We really need an official Django logging framework so stuff like this can be logged" http://groups.google.com/group/django-developers/browse_thread/thread/40adac6370fc195c/b1656b8e0c036c04 Maybe the right answer here is simply logging an info (or warning) message when a template can't find a value. Steven Armstrong has already mentioned it in this thread. And if Django had logging, we could have a SQL log, and I wouldn't have to start all my projects by setting up a logger, a SQL logging middleware, and an audit log of object create/update/delete. If there is support from on high for putting logging into Django, I'm more than happy to make the code changes. And I'm +1 on making tags fail loudly. 2008/5/21 Patryk Zawadzki <[EMAIL PROTECTED]>: > > On Wed, May 21, 2008 at 5:27 AM, Curtis <[EMAIL PROTECTED]> wrote: >> >> >> Has anyone considered using Python's 'warnings' module? It seems like >> it might be the perfect fit for this problem. >> >> For example, if the appropriate warn() calls were added to the >> templating system, by default, problems would be sent to sys.stderr. > > With the little exception that writing to stdout or stderr from a > fcgi/wsgi application will kill your application server with a nice > "broken pipe" when deployed on production :) > > -- > Patryk Zawadzki > PLD Linux Distribution > > > > --~--~-~--~~~---~--~~ 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: Want to have unit tests in multiple files
That seems very complicated, All I did was put this in tests/__init__.py
from myproj.tests.model_tests import *
from myproj.tests.view_tests import *
(etc)
2008/5/23 Sebastian Noack <[EMAIL PROTECTED]>:
> On Fri, 23 May 2008 13:32:45 -0500
> "Gary Wilson Jr." <[EMAIL PROTECTED]> wrote:
>> In case you haven't figured this out already, it can be done by
>> importing your unit test classes from the test/*.py modules in
>> tests/__init__.py
>
> That is exactly what I have done at my work, just a few days ago. I
> put the code below into the tests/__init__.py. You can use it as is.
>
> def get_test_modules():
>from os import path, listdir
>
>names = set()
>for f in listdir(path.dirname(__file__)):
>if f.startswith('.') or f.startswith('__'):
>continue
>names.add(f.split('.')[0])
>
>for name in names:
>yield (name, __import__('%s.%s' % (__name__, name), {}, {}, ['']))
>
> def setup_doc_tests():
>for name, module in get_test_modules():
># Try to find an API test in the current module, if it fails continue.
>try:
>api_tests = module.__test__['API_TESTS']
>except (AttributeError, TypeError, KeyError):
>continue
>
># Import possible dependecies of the API test from the current module.
>for k, v in module.__dict__.iteritems():
>if k.startswith('__'):
>continue
>globals()[k] = v
>
># Attach the API test to the __test__ dictionary if it exists or
> create it.
>try:
>globals()['__test__'][name] = api_tests
>except KeyError:
>globals()['__test__'] = {name: api_tests}
>
> def setup_unit_tests():
>import unittest
>
>for name, module in get_test_modules():
># Import each TestCase from the current module.
>for k, v in module.__dict__.iteritems():
>if not (isinstance(v, type) and issubclass(v, unittest.TestCase)):
>continue
>globals()[k] = v
>
> setup_doc_tests()
> setup_unit_tests()
>
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
