Or alternatively:
IS_MATCH('server', 'You must provide a valid location')
but don't do that. ;-)
For more details, see
http://docs.python.org/2/howto/regex.html#the-backslash-plague.
Anthony
On Thursday, July 11, 2013 8:15:56 PM UTC-4, Anthony wrote:
>
> Maybe try:
>
> IS_MATCH(r'
Maybe try:
IS_MATCH(r'server\\', 'You must provide a valid location')
Anthony
On Thursday, July 11, 2013 6:00:46 PM UTC-4, Josh Grigonis wrote:
>
> I have a form with a text input, and I want to make sure the user entry is
> prefixed with a specific UNC path.
>
> For example:
>
> \\server\b
Jonathan,
Thanks for your explanation.
Kind regards,
Annet.
On Nov 11, 2011, at 9:12 AM, annet wrote:
> Thanks for your reply. What do you mean by anchoring the search?
In a regular expression, ^ matches the beginning of the string, and $ matches
the end; I'm referring to those as anchors. So ^xyz$ matches only "xyz", but
the pattern xyz matches (for ex
Hi Jonathan,
Thanks for your reply. What do you mean by anchoring the search?
Kind regards,
Annet
Thank you! I am pleased with this resolution.
On Feb 6, 1:22 am, Massimo Di Pierro
wrote:
> In trunk
>
> IS_MATCH(...,strict=True) # true is default now and it does append
> the '$' is missing.
>
> On Feb 4, 8:17 pm, Ken wrote:
>
> > That change would have prevented my problem. However, would i
In trunk
IS_MATCH(...,strict=True) # true is default now and it does append
the '$' is missing.
On Feb 4, 8:17 pm, Ken wrote:
> That change would have prevented my problem. However, would it
> guaranty that the returned (accepted) match.group() value would never
> differ from the input value? I
On Feb 4, 2011, at 6:17 PM, Ken wrote:
>
> That change would have prevented my problem. However, would it
> guaranty that the returned (accepted) match.group() value would never
> differ from the input value? I am worried about more complex queries
> now. I still think that if IS_MATCH() finds tha
Validators are filters. They do not always return what is passed as
input. It is a feature. For example IS_INT_IN_RANGE() takes a string
and returns an int. IS_DATE, takes a string in the
internationalization format and returns a datetime.date(). IS_SLUG(),
sluggifies (probably the verb does not ex
That change would have prevented my problem. However, would it
guaranty that the returned (accepted) match.group() value would never
differ from the input value? I am worried about more complex queries
now. I still think that if IS_MATCH() finds that it has accepted
something that is not the input
On Feb 3, 2011, at 3:03 PM, Ken wrote:
>
> You are right. Having (re)read the documentation for re, I find that
> it is working as advertised. My original regex was wrong. However, I
> would argue that if the match found by regex.match() is different from
> the input value, IS_MATCH should return
You are right. Having (re)read the documentation for re, I find that
it is working as advertised. My original regex was wrong. However, I
would argue that if the match found by regex.match() is different from
the input value, IS_MATCH should return an error. That is, in the
IS_MATCH.__call__ defini
This is the correct behavio of regular expressions. Anyway, good that
you are pointing this out since others may find it counter intuitive.
Massimo
On Feb 2, 6:33 pm, Ken wrote:
> I have been having trouble with truncation of data from one field of a
> form. The culprit turned out to be the IS_M
13 matches
Mail list logo
