Re: Re: humanize.ordinal is very English-specific

On Thu, Mar 25, 2010 at 8:32 AM, Sergiy Kuzmenko wrote: >> If you have any suggestions for how we could expose ungettext better >> in templates, I'm all ears. However, given the complexity of >> pluralization rules and pluralization usage in the general case, it's >> not a

Re: Re: humanize.ordinal is very English-specific

> If you have any suggestions for how we could expose ungettext better > in templates, I'm all ears. However, given the complexity of > pluralization rules and pluralization usage in the general case, it's > not a simple task. Suggestions welcome. My suggestion is to make pluralization compatible

Re: Trac Full!

On Thu, Mar 25, 2010 at 7:49 AM, Simon Meers wrote: >> I was trying to figure out why I was getting Internal Server Errors >> when attempting to upload a patch on code.djangoproject.com -- I have >> discovered that there is "no space left on the device"! > > This seems to be

Re: Re: humanize.ordinal is very English-specific

On Wed, Mar 24, 2010 at 10:31 PM, wrote: > Regarding Russ' comment on pluralization: > >>  Option 1: Spend a lifetime trying to make a single tag that can >> accommodate every possible pluralization rule scheme >> >>  Option 2: Provide a simple implementation that works for

Re: Trac Full!

> I was trying to figure out why I was getting Internal Server Errors > when attempting to upload a patch on code.djangoproject.com -- I have > discovered that there is "no space left on the device"! This seems to be fixed now (thank you webmaster). However it may be worth noting that the email

Trac Full!

I was trying to figure out why I was getting Internal Server Errors when attempting to upload a patch on code.djangoproject.com -- I have discovered that there is "no space left on the device"! Now you can't even add a comment to the database: Traceback (most recent call last): File

Re: Re: humanize.ordinal is very English-specific

Regarding Russ' comment on pluralization: Option 1: Spend a lifetime trying to make a single tag that can accommodate every possible pluralization rule scheme Option 2: Provide a simple implementation that works for a lot of cases, and encourage others to write specific template tags for

Re: Proposal - ChoiceField.choices need to accept callable, not only list or tuple

Hi George, as far as I remember, ChoiceField has a line like: self.choices = list(choices) in __init__ method. Until this is changed, there is no difference in passing a callable, a list, or a generator. So what do you suggest: To simply allow passing a callable, or to allow truly dynamic

Re: Proposal - ChoiceField.choices need to accept callable, not only list or tuple

oh wait, you're right. (though choices=my_func seems to be neater then choices=(c for c in my_func()) (for some reason i thought that choices=(c for c in my_func()) will evaluate the my_func before we'll iterate through choices, but it won't) On Mar 24, 5:48 pm, Ivan Sagalaev

Re: Proposal - ChoiceField.choices need to accept callable, not only list or tuple

Hi there, I've used a different approach to solve the problem. If of interest, here is the snippet http://gist.github.com/232372 for solving the the problem of a run-time ChoiceField. The choices argument is a generator (or the usual list of tuples). On 24 March 2010 06:48, Ivan Sagalaev

Re: Proposal - ChoiceField.choices need to accept callable, not only list or tuple

George Karpenkov wrote: Given your experience, the chances are that you're right, however, I don't see any way how we can pass a generator which will not be called until the form class is instantiated. Why should a call matter? The body of the generator is not executed until first iteration