[slightly reordered]
On 2015-02-04 18:25, Collin Anderson wrote:
> Also, did we decide if the Model-field-layer or Form-field-layer
> would be better?
I think the Form-field layer is definitely the place for it. If I do
my_model.my_text_field = " leading and trailing "
I expect that value to
I'm certainly leaning on the side of "strip by default" because, like many
others, I feel it's the expected default -- users just don't get it -- and
have been bitten by it before.
I think I'll have a PR for this later tonight...
--
Curtis
On 5 February 2015 at 14:23, charettes wrote:
> Like
Like Russ I think this should be at the form level.
Since both db.CharField and db.TextField use a form.CharField the stripping
implementation should be done there.
I commented here because I recently fixed a related bug in an application I
maintain where a trailing white-space was not striped
Hi All,
I'd be ok with a well thought-out strip-by-default.
- I think most of my problems have been with trailing whitespace on
CharFields.
- I once have seen a minor unintentional leading whitespace. I think I also
may have once used a leading whitespace for sorting purposes, but I'd be ok
wi
On Wednesday 04 February 2015 11:00:50 Tom Christie wrote:
> > it will be backwards incompatible for every Django installation out
>
> there, but also because throwing away data that the user actually entered
> should be an opt-in, not opt-out behavior.
>
> If adequately called out I think there'
On 02/04/2015 02:00 AM, Tom Christie wrote:
>> it will be backwards incompatible for every Django installation out
> there, but also because throwing away data that the user actually
> entered should be an opt-in, not opt-out behavior.
>
> If adequately called out I think there'd be a valid case t
> leaving a ticket open is a better signal for inviting discussion and
patches.
There's been over 22,000 issues raised in Django's history. It's
understandable and desirable that maintainers close off tickets
aggressively if they don't think they should be tackled.
I wouldn't get too hung up o
Russell Keith-Magee, 04 Feb 2015 08:26:
> Jacob specifically said a good patch for this feature would be considered
> when he wontfixed #6362.
for me, leaving a ticket open is a better signal for
inviting discussion and patches. when i see a wontfix
closed ticket in other projects it usually mean
> it will be backwards incompatible for every Django installation out
there, but also because throwing away data that the user actually entered
should be an opt-in, not opt-out behavior.
If adequately called out I think there'd be a valid case that the current
and future issues it'll be causing
On Wed, Feb 4, 2015 at 6:49 AM, frantisek holop wrote:
> Tom Christie, 03 Feb 2015 12:53:
> > Trimming at `request.POST` or at the `Form` layer absolutely isn't
> > sensible, and a `normalize` argument is probably just overcomplicating
> > things, but I got the impression from that ticket that no
Tom Christie, 03 Feb 2015 12:53:
> Trimming at `request.POST` or at the `Form` layer absolutely isn't
> sensible, and a `normalize` argument is probably just overcomplicating
> things, but I got the impression from that ticket that nobody would have
> any great issue with someone issuing a patch
Trimming at `request.POST` or at the `Form` layer absolutely isn't
sensible, and a `normalize` argument is probably just overcomplicating
things, but I got the impression from that ticket that nobody would have
any great issue with someone issuing a patch with a `trim_whitespace` flag
on CharFi
Hi frantisek,
I've also ran into a number of problems with extra whitespace in forms.
Pretty annoying.
I also find settings pretty annoying. :) We were just talking on another
thread [1] about the possibility of packaging packaging django.forms as a
standalone package, but global settings are
good day,
a recent technical support incident conducted remotely and
involving a lot of back and forth of "huh? but i have entered
what you sent me" left me my head scratching.
the reason turned out to be a trailing space in the username of
the django admin loginform (thank god for nginx's "$requ
14 matches
Mail list logo