On Fri, Dec 25, 2009 at 3:55 AM, James Bennett wrote:
> On Thu, Dec 24, 2009 at 5:22 AM, Russell Keith-Magee
> wrote:
>> My concern with having two fields is that it introduces a false
>> dichotomy. There aren't just 2 options here - potentially any
>> permutation of the following list is possibl
On Thu, Dec 24, 2009 at 5:22 AM, Russell Keith-Magee
wrote:
> My concern with having two fields is that it introduces a false
> dichotomy. There aren't just 2 options here - potentially any
> permutation of the following list is possible:
While this is true, there are three common cases, which ca
On Thu, Dec 24, 2009 at 4:49 PM, James Bennett wrote:
> On Wed, Dec 23, 2009 at 9:44 PM, Russell Keith-Magee
> wrote:
>> I could live with either approach existing in the codebase. I won't
>> express a preference, though - I'll leave the decision of which
>> approach is preferable to those that w
On Thu, Dec 24, 2009 at 3:30 PM, Richard Laager wrote:
> On Thu, 2009-12-24 at 11:44 +0800, Russell Keith-Magee wrote:
>> This is completely backwards compatible as long as we keep
>> "STATE_CHOICES" to the same subset that exists today.
>
> Yikes, that's really restrictive. You want that list to
On Wed, Dec 23, 2009 at 9:44 PM, Russell Keith-Magee
wrote:
> I could live with either approach existing in the codebase. I won't
> express a preference, though - I'll leave the decision of which
> approach is preferable to those that will actually have to use it.
Honestly, given both the controv
On Thu, 2009-12-24 at 11:44 +0800, Russell Keith-Magee wrote:
> This is completely backwards compatible as long as we keep
> "STATE_CHOICES" to the same subset that exists today.
Yikes, that's really restrictive. You want that list to remain static
until Django 2.0?
I ask because the Canadian pro
On Wed, Dec 23, 2009 at 1:29 AM, James Bennett wrote:
> I've previously brought up some issues with the removal of certain
> options from the choices on localflavor's USStateField[1] as a result
> of ticket #8425[2] and, with feature freeze for 1.2 approaching and
> perhaps more time soon to be av
I've previously brought up some issues with the removal of certain
options from the choices on localflavor's USStateField[1] as a result
of ticket #8425[2] and, with feature freeze for 1.2 approaching and
perhaps more time soon to be available for such things, I'd like to
call attention to it again
On Tue, Aug 25, 2009 at 11:08 AM,
ch...@moffitts.net wrote:
>
>
>
> On Aug 22, 8:12 am, Russell Keith-Magee
> wrote:
>> On Sat, Aug 22, 2009 at 7:49 PM, Tim
>>
>> Chase wrote:
>>
>> > James Bennett wrote:
>> >> The current proposal is for a "USPostalCodeField" which
>> >> corresponds to the US Po
On Aug 22, 8:12 am, Russell Keith-Magee
wrote:
> On Sat, Aug 22, 2009 at 7:49 PM, Tim
>
> Chase wrote:
>
> > James Bennett wrote:
> >> The current proposal is for a "USPostalCodeField" which
> >> corresponds to the US Postal Service's list of postal codes:
>
> >>http://www.usps.com/ncsc/lookups
On Sat, Aug 22, 2009 at 7:49 PM, Tim
Chase wrote:
>
> James Bennett wrote:
>> The current proposal is for a "USPostalCodeField" which
>> corresponds to the US Postal Service's list of postal codes:
>>
>> http://www.usps.com/ncsc/lookups/abbr_state.txt
>>
>> [snip] Based on the various arguments up
James Bennett wrote:
> The current proposal is for a "USPostalCodeField" which
> corresponds to the US Postal Service's list of postal codes:
>
> http://www.usps.com/ncsc/lookups/abbr_state.txt
>
> [snip] Based on the various arguments up to this point, it
> seems like no single field is going
So, the USStateField in contrib.localflavor got neutered a while back,
removing a number of items from its choices list which -- while not
actually US states -- are valid postal codes which the US Postal
Service recognizes and considers as "US" addresses. When this
happened, Django lost useful fun
13 matches
Mail list logo
