Re: #2406: [patch] new command for management -- runjobs
Michael Radziej wrote: > Adrian Holovaty wrote: > > If your goal is to cut crontab entries from five to one, just create a > > single script that does the five things you need it to do; then point > > crontab at it. :) > > But it would be fine for pluggable applications to make this > automatically! (I'm +1) > > Michael +1 for periodic job running abilities Yes, let's move towards more modular applications, please. Session clean up should be, gasp, in the session application. Django should be making my server admin life easier, not harder. Gary Wilson --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Proposal: manipulator-aware validators in post-MR
After two far too-long days at work, far too much head-to-desk banging at home, and a rather stupid aha-I've-got-it, oh-wait-I-don't, I-need-sleep on Django-users, I've come to the conclusion that post-MR Django doesn't support manipulator-aware validators. This was possible in pre-MR-removal versions of Django by defining a method on a model starting with ``_manipulator_validator``; one could then access the original object via ``self.original_object`` in the method. I'd like to restore this ability to Django trunk; there are a couple of ways I could go about this, and I'd like input as to which would be cleaner: 1) Have a do-nothing ``ManipulatorValidator`` class to subclass from; ``django.fields.Field.get_manipulator_fields`` would then set a ``manipulator`` attribute on instances derived from this class, enabling the __call__ method to access the manipulator. 2) Write manipulator-aware functions with arguments ``(manipulator, field_data, all_data)`` instead of the standard ``(field_data, all_data)``, and set a ``takes_manipulator`` attribute on the validator (which could be a class attribute or a function decoration); test for this attribute in ``django.fields.Field.get_manipulator_fields``, and if it exists and evaluates to True, wrap the function with the manipulator passed in and expose only ``(field_data, all_data)``. I've already gotten the first case working, and I'll tackle the second after work tomorrow; I'll report back with my thoughts after comparing the two. Thoughts? --~--~-~--~~~---~--~~ 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: django unicode-conversion, beginning
Hey Gabor, On Wed, 2006-08-09 at 01:03 +0200, gabor wrote: > today i experimented a little with the django source code, > and here are the results. > > if you apply a very small patch (65lines, attached), you can write a view > completely in unicode. > means: > - GET/POST contains unicode data > - request.META contains unicode data > - you can put unicode text into the HttpResponse (this was already possible > without the patch) > > of course, this patch is a demonstration only. the charset is hardcoded > to UTF-8 (should be settings.DEFAULT_CHARSET), and it only handles the > WSGI way (the mod_python one is not handled). also templating and ORM > are not touched. (not to mention the ugliness of the code) > > but still, i was quite surprised that with such small changes so much > can be done. The low-hanging fruit are definitely the place to start for this sort of thing. > > i think unicodizing django can be done in 4 easily separated steps/parts: > > 1. request/response > 2. templating-system > 3. database-system > 4. "overall unicode-conversion". this is mostly about replacing > bytestrings with u"bla" in the code, and switching __str__ to __unicode__ > > my biggest problem currently is, that i do not know how to continue... > should i just write more and more patches to increase the > "unicode-coverage" to more parts of django? or maybe a more coordinated > approach would be better? Ultimately, getting you a svn branch to work in will probably be easiest. Maintaining a bunch of separate patches against a rapidly changing tree can be fairly time consuming. I'm not sure what the procedure is for that. Adrian? Keeping the changes as reasonably independent as possible is a great idea as far as you can take it. It will make review and testing a lot easier, as well as keeping you saner because you will only have to be looking at one layer at a time. A couple of comments on the patch itself. I realise it's only a proof of concept at the moment, so take as more things to think about when you want to tidy it up: (1) A docstring like """needed to workaround the cgi.parse_sql unicode-problem""" is not very future-proof. *What* parse_sql unicode problem? How will we know if/when it goes away? Either a quick description of the problem or a URL if it's tricky and explained elsewhere will help people who need to read this code in six months time. (2) You can't necessarily assume the environment is always in ASCII (or maybe you can; see below). For example, my current locale is set to en_AU.UTF-8 and I can do export foo="€50,00" If I'm not careful when parsing os.environ['foo'] this comes out as rubbish (I need to do unicode(os.environ['foo'], 'utf-8') or similar). Probably some playing around with the locale module to work out the right behaviour and getting a few people to test things (e.g. Windows vs. Linux vs. Macs, etc) will be necessary. It's also important not to go too overboard here, but since arbitrary environment variables can be set through Apache, we need to be able to work with that to be "correct". Hmm ... what are the restrictions on what webservers can put in their config files? Maybe ASCII-only is reasonable. *shrug* Maybe more investigation needed here. (3) I know there are some software projects apparently using unicodize as a word, but ... *shudder*. Using "code" as an analogy, "unicodify" would be nicer (nobody uses "codize", I would hope). (4) As you go through this process, keep a list somewhere of what people need to do to port existing applications across to using this functionality. Ideally, the answer would be "not much" and we can cast from the default encoding to unicode internally where necessary. But I'm sure there will be some changes required, so keeping a list of things to watch out for as you go will help people test this for you. Good to see somebody working on this. :-) Regards, Malcolm --~--~-~--~~~---~--~~ 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: Proposal: Saving SECRET_KEY in a seperate file
On 08/08/06 02:46, Malcolm Tredinnick wrote: > On Mon, 2006-08-07 at 14:22 -0400, Kevin Menard wrote: >> On 8/7/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: >> >> > We don't need a default solution for this. It's not within the scope >> > of this project to tell people how they should organize their settings >> > files. Take that opportunity to showcase your individualism. >> >> With the lack of an endorsed convention, I expect to see this question >> to continue to come up. IMHO, this is a common enough scenario to >> warrant more than a simple write-off. > > Add your favourite ideas to > http://code.djangoproject.com/wiki/DosAndDontsForApplicationWriters and > see if they work for other people. > > Adrian's point is quite valid. Setting policy is something you do when > there are real benefits to it and few or no other options. In this case, > you have a full Turing-complete language available to do whatever meets > your needs and (important point) is has zero maintenance cost for the > developers (my favourite kind of flexibility). > I've created a wiki page [1] with the different ideas from this thread and linked to it from the DosAndDonts page [2]. I hope that's ok for everybody who has posted their ideas/solutions here. Please add to that page if you have other ideas. Steven [1] http://code.djangoproject.com/wiki/SplitSettings [2] http://code.djangoproject.com/wiki/DosAndDontsForApplicationWriters --~--~-~--~~~---~--~~ 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: Proposal: Can custom tag use namespace
It would be nice mechanism to fully qualify a particular tag.so for example if I had a 'calendar' tag, and hugo also had one, and I needed to use another templatetag of his in the same file I could specify{% ian.calendar %} instead of {% calendar %} so the template would know which one I was referring to.On 08/08/2006, at 3:36 AM, limodou wrote:How to use namespace? For example,{% load example %}{% example.testtag %}And I think if the namespace can be optional is better. I don't knowif it's useful, but sometimes I read others projects, and as I readingthe template, I don't know which tag is in which file. So find thecorrect tag definition file is somewhat diffcult. If I can addnamespace in the front of a custom tag name, it'll be easy to locatethe source file.If it's not useful, just put it away. That's ok.-- I like python!My Blog: http://www.donews.net/limodouMy Django Site: http://www.djangocn.orgNewEdit Maillist: http://groups.google.com/group/NewEdit
--~--~-~--~~~---~--~~
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 -~--~~~~--~~--~--~---
