Code

Opened 7 years ago

Closed 4 years ago

#5709 closed (wontfix)

modify forms.RegexField to support inverse matching

Reported by: Nathan Hoover <nathan@…> Owned by: twisty7867
Component: Forms Version: master
Severity: Keywords: RegexField
Cc: Triage Stage: Design decision needed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description (last modified by mtredinnick)

For conveinence, it would be nice if the RegexField supported inverse matching; i.e. the contents of the field do NOT match the regex when they're valid. I needed this in the course of using a RegexField for username signups. I have a list of undesirable usernames, like so:

INVALID_USERNAME_REGEX = '(admin|root|add|edit|administrator|service)'

Since it's not trival to make a regex that uses ^ against words rather than characters this is useful.

Attachments (4)

fields.py.diff (1.2 KB) - added by Nathan Hoover <nathan@…> 7 years ago.
diff to patch fields.py
fields.py.2.diff (1.2 KB) - added by twisty7867 7 years ago.
patch
0001-Added-reject-kwarg.diff (1.8 KB) - added by arsatiki 5 years ago.
Adds reject-parameter to RegexField
0001-Added-reject-kwarg.patch (1.8 KB) - added by arsatiki 5 years ago.
Adds reject-kwarg

Download all attachments as: .zip

Change History (12)

Changed 7 years ago by Nathan Hoover <nathan@…>

diff to patch fields.py

comment:1 Changed 7 years ago by Nathan Hoover <nathan@…>

  • Needs documentation unset
  • Needs tests unset
  • Owner changed from nobody to anonymous
  • Patch needs improvement unset
  • Status changed from new to assigned

comment:2 Changed 7 years ago by twisty7867

  • Owner changed from anonymous to twisty7867
  • Status changed from assigned to new

comment:3 Changed 7 years ago by mtredinnick

  • Description modified (diff)

(Fixed wiki formatting in description).

I'm not sure at the moment whether this is something to add to RegexField or not, but a couple of immediate things about the patch:

  1. don't compare "== None". Instead use "is None"; it's slightly more idiomatic Python and a little more efficient.
  2. Any new parameters should go at the end of the argument list so as not to introduce backwards incompatible changes (your patch breaks any code using position arguments to RegexField).

Changed 7 years ago by twisty7867

patch

comment:4 Changed 7 years ago by twisty7867

Thanks for the tips; still a python n00b here.

I changed the patch to reflect your observations.

comment:5 Changed 6 years ago by SmileyChris

  • Triage Stage changed from Unreviewed to Design decision needed

comment:6 Changed 5 years ago by arsatiki

  • Summary changed from modify newforms.RegexField to support inverse matching to modify forms.RegexField to support inverse matching

I encountered a generalized version of this problem today. Consider a case, where valid data format is almost regular, but has a couple of inconsistencies. Often it is easier to make two regexes instead of one. First one filters out "good" stuff and the other one rejects the exceptions.

For example, the lottery numbers around here are from 1 to 39. Matching that with a single regex is a pain. But consider the following:

number = RegexField(r'[123]?\d', reject='(0|40)')

Or consider a badly planned urlconf after which we can't have login and logout as usernames:

username = RegexField(<username-re>, reject=r'(login|logout)')

Certain words just aren't fit for titles:

title = RegexField('', reject='(mammaries|copulation|solids)')

Although all of the above are possible to do with some regex-magic, I feel the use of the reject-parameter conveys the intention better than three lines of line noise.

I'll attach a patch which adds the reject-parameter.

Changed 5 years ago by arsatiki

Adds reject-parameter to RegexField

Changed 5 years ago by arsatiki

Adds reject-kwarg

comment:7 Changed 5 years ago by arsatiki

Added new patch, unfortunately has different file ending. It fixes a few bugs in the original patch.

comment:8 Changed 4 years ago by russellm

  • Resolution set to wontfix
  • Status changed from new to closed

Now that we have custom validators back, this is something we can do without needing to introduce an API for a specific type of logical conjunction.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.