[web2py] Re: IS_MATCH() changing a valid value ?
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 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 value, it should return an error.
>
> > Ken
>
> > On Feb 3, 6:35 pm, Jonathan Lundell wrote:
>
> > > 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 an error. That is, in the
> > > > IS_MATCH.__call__ definition, "if match:" should be "if match and
> > > > (value == match.group():". That change would raise an error that would
> > > > force a user like me to correct a regex that was matching in an
> > > > unexpected way. I would never want IS_MATCH to silently change data
> > > > between a form and insertion into a database.
>
> > > IS_MATCH is already implicitly anchored at the beginning of the field,
> > > since it uses re.match. I think it'd make sense to implicitly anchor at
> > > the end as well.
>
> > > We could change this:
>
> > > self.regex = re.compile(expression)
>
> > > to this:
>
> > > self.regex = re.compile('(%s)$' % expression)
>
> > > > Ken
>
> > > > On Feb 2, 9:13 pm, Massimo Di Pierro
> > > > wrote:
> > > >> 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_MATCH() validator, which was
> > > >>> truncating a valid value to return a shorter valid value. I'm not sure
> > > >>> whether to call this a bug or just unexpected behavior, but if I had
> > > >>> trouble with it, someone else may.
>
> > > >>> The data in question were spreadsheet-style coordinate values with
> > > >>> letters for rows and numbers for columns, in the range A1 to J10.
> > > >>> Initially, I used a validator like IS_MATCH('^[A-J][1-9]|[A-J]10$').
> > > >>> This checks first for the two-character combinations A1 to J9, then
> > > >>> checks for A10 to J10. If I test this in a web2py shell, it accepts
> > > >>> and returns the two-character combinations, but it accepts and
> > > >>> truncates any values ending in 10.
>
> > > >>> In [1] : vdtr = IS_MATCH('^[A-J][1-9]|[A-J]10$')
>
> > > >>> In [2] : vdtr('A1')
> > > >>> ('A1', None)
>
> > > >>> In [3] : vdtr('J1')
> > > >>> ('J1', None)
>
> > > >>> In [4] : vdtr('A10')
> > > >>> ('A1', None)
>
> > > >>> In [5] : vdtr('J10')
> > > >>> ('J1', None)
>
> > > >>> It seems to me that A1 and J1 are not proper matches because the '1'
> > > >>> does not appear at the end of the validated string. In any case, I am
> > > >>> surprised that IS_MATCH() would modify a value under any
> > > >>> circumstances.
>
> > > >>> If I turn the regex around, so that it tests for the three-character
> > > >>> combinations first, like IS_MATCH('^[A-J]10|[A-J][1-9]$'), then things
> > > >>> work better.
>
> > > >>> In [6] : vdtr = IS_MATCH('^[A-J]10|[A-J][1-9]$')
>
> > > >>> In [7] : vdtr('A1')
> > > >>> ('A1', None)
>
> > > >>> In [8] : vdtr('J1')
> > > >>> ('J1', None)
>
> > > >>> In [9] : vdtr('A10')
> > > >>> ('A10', None)
>
> > > >>> In [10] : vdtr('J10')
> > > >>> ('J10', None)
>
>
[web2py] Re: IS_MATCH() changing a valid value ?
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 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 value, it should return an error.
>
> Ken
>
> On Feb 3, 6:35 pm, Jonathan Lundell wrote:
>
>
>
>
>
>
>
> > 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 an error. That is, in the
> > > IS_MATCH.__call__ definition, "if match:" should be "if match and
> > > (value == match.group():". That change would raise an error that would
> > > force a user like me to correct a regex that was matching in an
> > > unexpected way. I would never want IS_MATCH to silently change data
> > > between a form and insertion into a database.
>
> > IS_MATCH is already implicitly anchored at the beginning of the field,
> > since it uses re.match. I think it'd make sense to implicitly anchor at the
> > end as well.
>
> > We could change this:
>
> > self.regex = re.compile(expression)
>
> > to this:
>
> > self.regex = re.compile('(%s)$' % expression)
>
> > > Ken
>
> > > On Feb 2, 9:13 pm, Massimo Di Pierro
> > > wrote:
> > >> 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_MATCH() validator, which was
> > >>> truncating a valid value to return a shorter valid value. I'm not sure
> > >>> whether to call this a bug or just unexpected behavior, but if I had
> > >>> trouble with it, someone else may.
>
> > >>> The data in question were spreadsheet-style coordinate values with
> > >>> letters for rows and numbers for columns, in the range A1 to J10.
> > >>> Initially, I used a validator like IS_MATCH('^[A-J][1-9]|[A-J]10$').
> > >>> This checks first for the two-character combinations A1 to J9, then
> > >>> checks for A10 to J10. If I test this in a web2py shell, it accepts
> > >>> and returns the two-character combinations, but it accepts and
> > >>> truncates any values ending in 10.
>
> > >>> In [1] : vdtr = IS_MATCH('^[A-J][1-9]|[A-J]10$')
>
> > >>> In [2] : vdtr('A1')
> > >>> ('A1', None)
>
> > >>> In [3] : vdtr('J1')
> > >>> ('J1', None)
>
> > >>> In [4] : vdtr('A10')
> > >>> ('A1', None)
>
> > >>> In [5] : vdtr('J10')
> > >>> ('J1', None)
>
> > >>> It seems to me that A1 and J1 are not proper matches because the '1'
> > >>> does not appear at the end of the validated string. In any case, I am
> > >>> surprised that IS_MATCH() would modify a value under any
> > >>> circumstances.
>
> > >>> If I turn the regex around, so that it tests for the three-character
> > >>> combinations first, like IS_MATCH('^[A-J]10|[A-J][1-9]$'), then things
> > >>> work better.
>
> > >>> In [6] : vdtr = IS_MATCH('^[A-J]10|[A-J][1-9]$')
>
> > >>> In [7] : vdtr('A1')
> > >>> ('A1', None)
>
> > >>> In [8] : vdtr('J1')
> > >>> ('J1', None)
>
> > >>> In [9] : vdtr('A10')
> > >>> ('A10', None)
>
> > >>> In [10] : vdtr('J10')
> > >>> ('J10', None)
Re: [web2py] Re: IS_MATCH() changing a valid value ?
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 that it has accepted
> something that is not the input value, it should return an error.
I think it guarantees that, yes, since the match will fail if it doesn't match
the whole thing.
>
> Ken
>
> On Feb 3, 6:35 pm, Jonathan Lundell wrote:
>> 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 an error. That is, in the
>>> IS_MATCH.__call__ definition, "if match:" should be "if match and
>>> (value == match.group():". That change would raise an error that would
>>> force a user like me to correct a regex that was matching in an
>>> unexpected way. I would never want IS_MATCH to silently change data
>>> between a form and insertion into a database.
>>
>> IS_MATCH is already implicitly anchored at the beginning of the field, since
>> it uses re.match. I think it'd make sense to implicitly anchor at the end as
>> well.
>>
>> We could change this:
>>
>> self.regex = re.compile(expression)
>>
>> to this:
>>
>> self.regex = re.compile('(%s)$' % expression)
>>
>>
>>
>>> Ken
>>
>>> On Feb 2, 9:13 pm, Massimo Di Pierro
>>> wrote:
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_MATCH() validator, which was
> truncating a valid value to return a shorter valid value. I'm not sure
> whether to call this a bug or just unexpected behavior, but if I had
> trouble with it, someone else may.
>>
> The data in question were spreadsheet-style coordinate values with
> letters for rows and numbers for columns, in the range A1 to J10.
> Initially, I used a validator like IS_MATCH('^[A-J][1-9]|[A-J]10$').
> This checks first for the two-character combinations A1 to J9, then
> checks for A10 to J10. If I test this in a web2py shell, it accepts
> and returns the two-character combinations, but it accepts and
> truncates any values ending in 10.
>>
> In [1] : vdtr = IS_MATCH('^[A-J][1-9]|[A-J]10$')
>>
> In [2] : vdtr('A1')
> ('A1', None)
>>
> In [3] : vdtr('J1')
> ('J1', None)
>>
> In [4] : vdtr('A10')
> ('A1', None)
>>
> In [5] : vdtr('J10')
> ('J1', None)
>>
> It seems to me that A1 and J1 are not proper matches because the '1'
> does not appear at the end of the validated string. In any case, I am
> surprised that IS_MATCH() would modify a value under any
> circumstances.
>>
> If I turn the regex around, so that it tests for the three-character
> combinations first, like IS_MATCH('^[A-J]10|[A-J][1-9]$'), then things
> work better.
>>
> In [6] : vdtr = IS_MATCH('^[A-J]10|[A-J][1-9]$')
>>
> In [7] : vdtr('A1')
> ('A1', None)
>>
> In [8] : vdtr('J1')
> ('J1', None)
>>
> In [9] : vdtr('A10')
> ('A10', None)
>>
> In [10] : vdtr('J10')
> ('J10', None)
>>
>>
[web2py] Re: IS_MATCH() changing a valid value ?
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 exist).
There is no reason why IS_MATH should not be allowed to transform the
input.
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 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 value, it should return an error.
>
> Ken
>
> On Feb 3, 6:35 pm, Jonathan Lundell wrote:
>
>
>
>
>
>
>
> > 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 an error. That is, in the
> > > IS_MATCH.__call__ definition, "if match:" should be "if match and
> > > (value == match.group():". That change would raise an error that would
> > > force a user like me to correct a regex that was matching in an
> > > unexpected way. I would never want IS_MATCH to silently change data
> > > between a form and insertion into a database.
>
> > IS_MATCH is already implicitly anchored at the beginning of the field,
> > since it uses re.match. I think it'd make sense to implicitly anchor at the
> > end as well.
>
> > We could change this:
>
> > self.regex = re.compile(expression)
>
> > to this:
>
> > self.regex = re.compile('(%s)$' % expression)
>
> > > Ken
>
> > > On Feb 2, 9:13 pm, Massimo Di Pierro
> > > wrote:
> > >> 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_MATCH() validator, which was
> > >>> truncating a valid value to return a shorter valid value. I'm not sure
> > >>> whether to call this a bug or just unexpected behavior, but if I had
> > >>> trouble with it, someone else may.
>
> > >>> The data in question were spreadsheet-style coordinate values with
> > >>> letters for rows and numbers for columns, in the range A1 to J10.
> > >>> Initially, I used a validator like IS_MATCH('^[A-J][1-9]|[A-J]10$').
> > >>> This checks first for the two-character combinations A1 to J9, then
> > >>> checks for A10 to J10. If I test this in a web2py shell, it accepts
> > >>> and returns the two-character combinations, but it accepts and
> > >>> truncates any values ending in 10.
>
> > >>> In [1] : vdtr = IS_MATCH('^[A-J][1-9]|[A-J]10$')
>
> > >>> In [2] : vdtr('A1')
> > >>> ('A1', None)
>
> > >>> In [3] : vdtr('J1')
> > >>> ('J1', None)
>
> > >>> In [4] : vdtr('A10')
> > >>> ('A1', None)
>
> > >>> In [5] : vdtr('J10')
> > >>> ('J1', None)
>
> > >>> It seems to me that A1 and J1 are not proper matches because the '1'
> > >>> does not appear at the end of the validated string. In any case, I am
> > >>> surprised that IS_MATCH() would modify a value under any
> > >>> circumstances.
>
> > >>> If I turn the regex around, so that it tests for the three-character
> > >>> combinations first, like IS_MATCH('^[A-J]10|[A-J][1-9]$'), then things
> > >>> work better.
>
> > >>> In [6] : vdtr = IS_MATCH('^[A-J]10|[A-J][1-9]$')
>
> > >>> In [7] : vdtr('A1')
> > >>> ('A1', None)
>
> > >>> In [8] : vdtr('J1')
> > >>> ('J1', None)
>
> > >>> In [9] : vdtr('A10')
> > >>> ('A10', None)
>
> > >>> In [10] : vdtr('J10')
> > >>> ('J10', None)
[web2py] Re: IS_MATCH() changing a valid value ?
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 value, it should return an error.
Ken
On Feb 3, 6:35 pm, Jonathan Lundell wrote:
> 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 an error. That is, in the
> > IS_MATCH.__call__ definition, "if match:" should be "if match and
> > (value == match.group():". That change would raise an error that would
> > force a user like me to correct a regex that was matching in an
> > unexpected way. I would never want IS_MATCH to silently change data
> > between a form and insertion into a database.
>
> IS_MATCH is already implicitly anchored at the beginning of the field, since
> it uses re.match. I think it'd make sense to implicitly anchor at the end as
> well.
>
> We could change this:
>
> self.regex = re.compile(expression)
>
> to this:
>
> self.regex = re.compile('(%s)$' % expression)
>
>
>
> > Ken
>
> > On Feb 2, 9:13 pm, Massimo Di Pierro
> > wrote:
> >> 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_MATCH() validator, which was
> >>> truncating a valid value to return a shorter valid value. I'm not sure
> >>> whether to call this a bug or just unexpected behavior, but if I had
> >>> trouble with it, someone else may.
>
> >>> The data in question were spreadsheet-style coordinate values with
> >>> letters for rows and numbers for columns, in the range A1 to J10.
> >>> Initially, I used a validator like IS_MATCH('^[A-J][1-9]|[A-J]10$').
> >>> This checks first for the two-character combinations A1 to J9, then
> >>> checks for A10 to J10. If I test this in a web2py shell, it accepts
> >>> and returns the two-character combinations, but it accepts and
> >>> truncates any values ending in 10.
>
> >>> In [1] : vdtr = IS_MATCH('^[A-J][1-9]|[A-J]10$')
>
> >>> In [2] : vdtr('A1')
> >>> ('A1', None)
>
> >>> In [3] : vdtr('J1')
> >>> ('J1', None)
>
> >>> In [4] : vdtr('A10')
> >>> ('A1', None)
>
> >>> In [5] : vdtr('J10')
> >>> ('J1', None)
>
> >>> It seems to me that A1 and J1 are not proper matches because the '1'
> >>> does not appear at the end of the validated string. In any case, I am
> >>> surprised that IS_MATCH() would modify a value under any
> >>> circumstances.
>
> >>> If I turn the regex around, so that it tests for the three-character
> >>> combinations first, like IS_MATCH('^[A-J]10|[A-J][1-9]$'), then things
> >>> work better.
>
> >>> In [6] : vdtr = IS_MATCH('^[A-J]10|[A-J][1-9]$')
>
> >>> In [7] : vdtr('A1')
> >>> ('A1', None)
>
> >>> In [8] : vdtr('J1')
> >>> ('J1', None)
>
> >>> In [9] : vdtr('A10')
> >>> ('A10', None)
>
> >>> In [10] : vdtr('J10')
> >>> ('J10', None)
>
>
Re: [web2py] Re: IS_MATCH() changing a valid value ?
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 an error. That is, in the
> IS_MATCH.__call__ definition, "if match:" should be "if match and
> (value == match.group():". That change would raise an error that would
> force a user like me to correct a regex that was matching in an
> unexpected way. I would never want IS_MATCH to silently change data
> between a form and insertion into a database.
IS_MATCH is already implicitly anchored at the beginning of the field, since it
uses re.match. I think it'd make sense to implicitly anchor at the end as well.
We could change this:
self.regex = re.compile(expression)
to this:
self.regex = re.compile('(%s)$' % expression)
>
> Ken
>
> On Feb 2, 9:13 pm, Massimo Di Pierro
> wrote:
>> 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_MATCH() validator, which was
>>> truncating a valid value to return a shorter valid value. I'm not sure
>>> whether to call this a bug or just unexpected behavior, but if I had
>>> trouble with it, someone else may.
>>
>>> The data in question were spreadsheet-style coordinate values with
>>> letters for rows and numbers for columns, in the range A1 to J10.
>>> Initially, I used a validator like IS_MATCH('^[A-J][1-9]|[A-J]10$').
>>> This checks first for the two-character combinations A1 to J9, then
>>> checks for A10 to J10. If I test this in a web2py shell, it accepts
>>> and returns the two-character combinations, but it accepts and
>>> truncates any values ending in 10.
>>
>>> In [1] : vdtr = IS_MATCH('^[A-J][1-9]|[A-J]10$')
>>
>>> In [2] : vdtr('A1')
>>> ('A1', None)
>>
>>> In [3] : vdtr('J1')
>>> ('J1', None)
>>
>>> In [4] : vdtr('A10')
>>> ('A1', None)
>>
>>> In [5] : vdtr('J10')
>>> ('J1', None)
>>
>>> It seems to me that A1 and J1 are not proper matches because the '1'
>>> does not appear at the end of the validated string. In any case, I am
>>> surprised that IS_MATCH() would modify a value under any
>>> circumstances.
>>
>>> If I turn the regex around, so that it tests for the three-character
>>> combinations first, like IS_MATCH('^[A-J]10|[A-J][1-9]$'), then things
>>> work better.
>>
>>> In [6] : vdtr = IS_MATCH('^[A-J]10|[A-J][1-9]$')
>>
>>> In [7] : vdtr('A1')
>>> ('A1', None)
>>
>>> In [8] : vdtr('J1')
>>> ('J1', None)
>>
>>> In [9] : vdtr('A10')
>>> ('A10', None)
>>
>>> In [10] : vdtr('J10')
>>> ('J10', None)
>>
>>
[web2py] Re: IS_MATCH() changing a valid value ?
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__ definition, "if match:" should be "if match and
(value == match.group():". That change would raise an error that would
force a user like me to correct a regex that was matching in an
unexpected way. I would never want IS_MATCH to silently change data
between a form and insertion into a database.
Ken
On Feb 2, 9:13 pm, Massimo Di Pierro
wrote:
> 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_MATCH() validator, which was
> > truncating a valid value to return a shorter valid value. I'm not sure
> > whether to call this a bug or just unexpected behavior, but if I had
> > trouble with it, someone else may.
>
> > The data in question were spreadsheet-style coordinate values with
> > letters for rows and numbers for columns, in the range A1 to J10.
> > Initially, I used a validator like IS_MATCH('^[A-J][1-9]|[A-J]10$').
> > This checks first for the two-character combinations A1 to J9, then
> > checks for A10 to J10. If I test this in a web2py shell, it accepts
> > and returns the two-character combinations, but it accepts and
> > truncates any values ending in 10.
>
> > In [1] : vdtr = IS_MATCH('^[A-J][1-9]|[A-J]10$')
>
> > In [2] : vdtr('A1')
> > ('A1', None)
>
> > In [3] : vdtr('J1')
> > ('J1', None)
>
> > In [4] : vdtr('A10')
> > ('A1', None)
>
> > In [5] : vdtr('J10')
> > ('J1', None)
>
> > It seems to me that A1 and J1 are not proper matches because the '1'
> > does not appear at the end of the validated string. In any case, I am
> > surprised that IS_MATCH() would modify a value under any
> > circumstances.
>
> > If I turn the regex around, so that it tests for the three-character
> > combinations first, like IS_MATCH('^[A-J]10|[A-J][1-9]$'), then things
> > work better.
>
> > In [6] : vdtr = IS_MATCH('^[A-J]10|[A-J][1-9]$')
>
> > In [7] : vdtr('A1')
> > ('A1', None)
>
> > In [8] : vdtr('J1')
> > ('J1', None)
>
> > In [9] : vdtr('A10')
> > ('A10', None)
>
> > In [10] : vdtr('J10')
> > ('J10', None)
>
>
[web2py] Re: IS_MATCH() changing a valid value ?
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_MATCH() validator, which was
> truncating a valid value to return a shorter valid value. I'm not sure
> whether to call this a bug or just unexpected behavior, but if I had
> trouble with it, someone else may.
>
> The data in question were spreadsheet-style coordinate values with
> letters for rows and numbers for columns, in the range A1 to J10.
> Initially, I used a validator like IS_MATCH('^[A-J][1-9]|[A-J]10$').
> This checks first for the two-character combinations A1 to J9, then
> checks for A10 to J10. If I test this in a web2py shell, it accepts
> and returns the two-character combinations, but it accepts and
> truncates any values ending in 10.
>
> In [1] : vdtr = IS_MATCH('^[A-J][1-9]|[A-J]10$')
>
> In [2] : vdtr('A1')
> ('A1', None)
>
> In [3] : vdtr('J1')
> ('J1', None)
>
> In [4] : vdtr('A10')
> ('A1', None)
>
> In [5] : vdtr('J10')
> ('J1', None)
>
> It seems to me that A1 and J1 are not proper matches because the '1'
> does not appear at the end of the validated string. In any case, I am
> surprised that IS_MATCH() would modify a value under any
> circumstances.
>
> If I turn the regex around, so that it tests for the three-character
> combinations first, like IS_MATCH('^[A-J]10|[A-J][1-9]$'), then things
> work better.
>
> In [6] : vdtr = IS_MATCH('^[A-J]10|[A-J][1-9]$')
>
> In [7] : vdtr('A1')
> ('A1', None)
>
> In [8] : vdtr('J1')
> ('J1', None)
>
> In [9] : vdtr('A10')
> ('A10', None)
>
> In [10] : vdtr('J10')
> ('J10', None)
