RFC: Settings 'modes' or 'flavors'

Hi all, Recently I wrote a blog post (http://bit.ly/HM3hC) on my project conventions; it began by talking about how I like to maintain different settings 'modes' for debugging, staging and production, and the ways in which I do this. I've had quite a few responses from Djangonauts on how they

Re: pychecker catches IndexError exception while importing /django/db/models/base.py

I think I might be able to spot where the problem is. Try running pychecker on your app folder, rather than models.py. Let's assume your app is called myapp, so you have a directory structure something like this: myapp/ -- __init__.py -- models.py -- views.py -- tests.py (et cetera) If

Re: #3566 Aggregations: Call for testing

Just a question - how, if at all, is aggregation going to be supported or worked around on custom field types? On Jan 6, 8:14 am, "Ian Kelly" wrote: > On Mon, Jan 5, 2009 at 9:21 AM, Alex Gaynor wrote: > > The one's that are a result of Oracle not

Re: RFC: Asynchronous Signal Receivers

On Jan 5, 12:54 am, Malcolm Tredinnick <malc...@pointy-stick.com> wrote: > On Sun, 2009-01-04 at 06:19 -0800, zvoase wrote: > > On Jan 4, 11:10 am, Graham Dumpleton <graham.dumple...@gmail.com> > > wrote: > > > Not true, Apache doesn't necessarily wait for al

Re: RFC: Asynchronous Signal Receivers

On Jan 4, 11:10 am, Graham Dumpleton wrote: > Not true, Apache doesn't necessarily wait for all current requests to > complete before shutting down child worker processes. For a non > graceful restart or shutdown, Apache will give the process about 3-4 > seconds to

Re: RFC: Asynchronous Signal Receivers

On Jan 4, 10:27 am, "alex.gay...@gmail.com" wrote: > Ok, but you're original concern was that what happens if say you go to > send an email and "raises the issue that e-mail may take a while (i.e. > from a few seconds to a couple of minutes) to send;", ultimately if > you

Re: RFC: Asynchronous Signal Receivers

First, I'll address Alex's concerns. Basically, an async decorator would work fine for some things, but it helps to be able to co- ordinate the threads. Look at it this way; when something uses TCP, for example, it's going to take a certain finite amount of time for the TCP request to occur.

RFC: Asynchronous Signal Receivers

Hi Developers, Basically, I wanted to ask for some devel's opinions on something. When using the Django signals framework (which, by the way, is a very good way of decoupling reusable apps whilst allowing for deep integration), I sometimes find that a signal receiver does not need to be

Re: Django Migrations

To begin with, my first impressions are that it's a really good solution, and I'm interested to see how it shapes up in production apps :) I'm slightly concerned with having to link to it from django.contrib. This is generally regarded as a bad idea, mainly because it makes it difficult to get

Re: Nipping projects in the butt

By the way, the saying is "Nipping (X) in the bud." It has to do with cutting a flower before it's grown past the bud stage. No butts I'm afraid ;-). On Dec 10, 12:09 am, "Russell Keith-Magee" <[EMAIL PROTECTED]> wrote: > On Tue, Dec 9, 2008 at 9:24 PM, Christopher Allan Webber > > > > <[EMAIL

Re: Proposal: deprecate and remove django.utils.simplejson

I think a better approach would be to have django.utils.simplejson as a sort of alias package (which is easy using Python's introspection). What would happen is this: A user imports either django.utils.simplejson, or something from inside it. We look for the 'json' package on the path (Python

Re: Dropping Python 2.3 compatibility for Django 1.1

+1 For me, too. If people want to use the cutting-edge Django release then they can at least update Python to 2.4 (which is now 4 years old anyway). --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django

Re: RequestContext rarely used (branched from Feature reviews for 1.1)

uri Baburov <[EMAIL PROTECTED]> wrote: > > > On Thu, Nov 20, 2008 at 9:47 PM, Jeremy Dunck <[EMAIL PROTECTED]> wrote: > > >> On Thu, Nov 20, 2008 at 6:19 AM, zvoase <[EMAIL PROTECTED]> wrote: > >> ... > >>> # Using RequestContext > &g

Re: RequestContext rarely used (branched from Feature reviews for 1.1)

I have an idea which may solve the issue of render_to_response using a RequestContext. Why not have render_to_response as a shortcut in django.shortcuts (as it is now), and then add a 'render' method to the request instance which would do render_to_response but with a RequestContext instead. That

Remove "old docs" message from Django docs

Hi, I think I might be speaking for a few people here who have kinda seen enough of the "olddocs" warning/message/admonition thing every time we search on the Django docs. It's been 2 and a half months since Django 1.0 was released, so if people are still following links from the old

Re: Signal Connection Decorators

I just wanted to check if there was a consensus on this; it would be nice to get it into the Django 1.1 featureset. Regards, Zack --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to

RFC: block_append Template tag

Dear devs, I'd like to add a feature proposal for the 1.1 release. Basically, at the moment the 'block' tag allows you only to override the block you point it to, and I'd like to increase this functionality by adding a 'block_append' tag which would allow you to append text to a block. An

Re: HttpResponse and file-like objects

Streaming/iterable HttpResponse instances are kind of an issue which needs sorting out. I've had problems in the past with the current implementation. Maybe a closer look is actually necessary. Regards, Zack On Oct 1, 3:41 am, David Cramer <[EMAIL PROTECTED]> wrote: > Thanks Graham, I'll check

Re: Declarative syntax for widgets in ModelForm

I understand the motivation for this, and support the idea, but I think the implementation is a little repetitive: class MyForm(forms.ModelForm): class Meta: fields = # LIST OF FIELDS widgets = # DICT OF FIELD NAMES : WIDGETS Why not do something like this: class

Status report on CPython 2.6

Hi, Just wondering if I could ask how compatible Django is with CPython 2.6. I know that it should work fine anyway, but I thought it a good idea just to check. Has anyone looked into this? Regards, Zack --~--~-~--~~~---~--~~ You received this message because you

Re: Concrete django.template Suggestions

, but it might be useful). Regards, Zack On Sep 20, 11:31 am, zvoase <[EMAIL PROTECTED]> wrote: > Probably the best thing to do, if anything, is to make something new > and get it working alongside the old system, much like "oldforms" and > "newforms" in 0.96. That w

Re: Concrete django.template Suggestions

Probably the best thing to do, if anything, is to make something new and get it working alongside the old system, much like "oldforms" and "newforms" in 0.96. That way you keep backwards compatibility but people can also leverage new features in their code. Regards, Zack On Sep 20, 3:48 am,

Re: RFC: Raise an Exception to return a Response

. Anyway, thanks for your time, Regards, Zack On Sep 18, 2:12 am, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > On Wed, 2008-09-17 at 16:29 -0700, zvoase wrote: > > Yeah, that's it, process_exception is *definitely* what I need :) > > But as for the idea, how do you feel abou

Re: RFC: django.template refactoring (#7806)

gt; If I follow you are saying that it is lispy in that flow control > statements and functions are handled just the same way(meaning you can > define your own statements if you like)? > > On Sep 17, 8:02 pm, zvoase <[EMAIL PROTECTED]> wrote: > > > I don't know if anyon

Re: RFC: django.template refactoring (#7806)

I don't know if anyone's noticed, but the templating language seems (at least from a usage standpoint) to be a lot like a Lisp interpreter. I know that sounds completely weird and random, but it's true. It's like a very small subset of Scheme or something (the small subset thing is necessary

Re: Proposal: app objects

I think the app object thing is a really good idea, but I have to say one thing; why not see if some middle ground can be met between the Django cheeseshop idea (going on in another thread in this group) and this. Maybe an app_info.py file in a Django app directory could give some info on that

Re: RFC: Raise an Exception to return a Response

> On Wed, Sep 17, 2008 at 6:30 PM, zvoase <[EMAIL PROTECTED]> wrote: > > > Sorry, here:http://dpaste.com/hold/78774/ > > > On Sep 18, 1:29 am, zvoase <[EMAIL PROTECTED]> wrote: > >> Yeah, that's it, process_exception is *definitely* what I need :) > >

Re: RFC: Raise an Exception to return a Response

Sorry, here: http://dpaste.com/hold/78774/ On Sep 18, 1:29 am, zvoase <[EMAIL PROTECTED]> wrote: > Yeah, that's it, process_exception is *definitely* what I need :) > But as for the idea, how do you feel about it? > By the way, I've just posted a better version of it (sorry for

Re: RFC: Raise an Exception to return a Response

AIL PROTECTED]> wrote: > On Wed, Sep 17, 2008 at 12:11 PM, zvoase <[EMAIL PROTECTED]> wrote: > > ... > > > I'll post soon. For the meantime, take a look > > athttp://dpaste.com/hold/78671/ > > That won't do what you want, since the "raise" on line 1

RFC: Raise an Exception to return a Response

Dear devels, I use the Http404 exception a *lot*, mainly because I call a lot of functions from within my views (I was raised in the Lisp tradition of refactoring EVERYTHING into separate functions) and it's nice sometimes to override the caller and just return a set response to the client.

Re: Signal Connection Decorators

ry, I'm not messing with stuff! Regards, Zack On Sep 14, 1:51 am, zvoase <[EMAIL PROTECTED]> wrote: > I think the "signal.decorate" form is nicer, but the name has to show > that there is some sort of connection going on; if you want to know > why I think this is, take a look

Re: Signal Connection Decorators

). It's more compact, explicit, beautiful and obvious. The thing is, can we actually change the 'connect' method, or are we going to give this a new name? Regards, Zack On Sep 14, 12:19 am, Ludvig Ericson <[EMAIL PROTECTED]> wrote: > On Sep 12, 2008, at 13:01, zvoase wrote: > > >

Re: Signal Connection Decorators

Couldn't we move this discussion to the ticket on Django's Trac? http://code.djangoproject.com/ticket/9015 On Sep 12, 1:01 pm, zvoase <[EMAIL PROTECTED]> wrote: > I think the principle of least surprise applies here. It would be very > easy just to implement __call__ as

Re: Signal Connection Decorators

I think the principle of least surprise applies here. It would be very easy just to implement __call__ as a decorator, but by the same token, the signal needs to be used from both ends, and the addition of a __call__ method may confuse some people. As with most problems in programming, we just

Re: Signal Connection Decorators

I've created a ticket: http://code.djangoproject.com/ticket/9015 I've also uploaded a patch with the suggested changes. Regards, Zack On Sep 10, 1:30 pm, Jeremy Dunck <[EMAIL PROTECTED]> wrote: > Patch or ticket, please. > > On Sep 10, 2008, at 3:52, zvoase <[EMAIL

Signal Connection Decorators

Hi Django developers, Usually, signal receivers are defined as functions and then connected to a specific signal via a function call outside of the defined function. This can cause clutter, it violates DRY, and it is not very Pythonic in style. Several examples of the current usage pattern are

Re: HttpResponse as a file-like object

I've written a patch, and I could open a bug with post-1.0 milestone, if that's OK? It's probably a good idea to have a general bug for initialising HttpResponse objects with iterators. On Aug 25, 9:33 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > On Mon, 2008-08-25 at 12:26 -070

HttpResponse as a file-like object

Devels, I've noticed in the docs that HttpResponse objects, if initialised with an iterator, cannot be used as file-like objects. This could be fixed quite easily. At the moment, if the response was not initialised with a string, then an error is raised when you try to write to it. Instead, all

Re: recent MultiValueDict.iteritems change (changeset 8399)

Wouldn't it make sense to add a keyword argument to both itervalues and iteritems, which lets you get lists instead? That would seem easier than writing new methods. Example: >>> dictionary.iteritems(as_list=True) ... --~--~-~--~~~---~--~~ You received this

HTTP PUT request

Hi, There seems to be an issue with Django in the HttpRequest class, in that I cannot access the data provided in a HTTP PUT request. I'm writing a web app which uses a RESTful interface, but at the moment I have to put together a piece of hacky middleware in order to be able to get the PUT data.

QManager - suggested inclusion in Django

Dear Developers, I've written a module which may be helpful to a lot of Django developers, and would like to suggest it for trials and testing, and possible inclusion with Django. I'm currently just looking for developers to help test and work with the module; it should be quite helpful. In