Thread: [FE-discuss] patch for StringBoolean

Because of the if_empty parameter, the StringBoolean validator in svn
was returning False (not 'false') for from_python(False). This change
fixes that:

Index: formencode/validators.py
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- formencode/validators.py    (revision 1077)
+++ formencode/validators.py    (working copy)
@@ -1487,7 +1487,6 @@

     true_values =3D ['true', 't', 'yes', 'y', 'on']
     false_values =3D ['false', 'f', 'no', 'n', 'off']
-    if_empty =3D False

     messages =3D { "string" : "Value should be %(true)r or %(false)r" }

@@ -1496,7 +1495,7 @@
             value =3D value.strip().lower()
             if value in self.true_values:
                 return True
-            if value in self.false_values:
+            if not value or value in self.false_values:
                 return False
             raise Invalid(self.message("string", state,
                                        true=3Dself.true_values[0],


--
Kevin Dangoor
Author of the Zesty News RSS newsreader

email: ki...@bl...
company: http://www.BlazingThings.com
blog: http://www.BlueSkyOnMars.com

Kevin Dangoor wrote:
> Because of the if_empty parameter, the StringBoolean validator in svn
> was returning False (not 'false') for from_python(False). This change
> fixes that:

I wonder if 0/False should really be considered "empty"?  I.e., maybe 
those values should be special-cased not to be empty.

I think so.  But also if_empty applied to from_python seems a little 
fishy as well.  I suspect it should not be at all.  I also suspect that 
FancyValidator.attempt_convert is not a very helpful abstraction.

-- 
Ian Bicking  /  ia...@co...  /  http://blog.ianbicking.org

On 10/5/05, Ian Bicking <ia...@co...> wrote:
> Kevin Dangoor wrote:
> > Because of the if_empty parameter, the StringBoolean validator in svn
> > was returning False (not 'false') for from_python(False). This change
> > fixes that:
>
> I wonder if 0/False should really be considered "empty"?  I.e., maybe
> those values should be special-cased not to be empty.

I don't think of those as empty. "Empty" implies a void. "", [], (),
None are all empty. 0 and False are actual values.

> I think so.  But also if_empty applied to from_python seems a little
> fishy as well.  I suspect it should not be at all.  I also suspect that
> FancyValidator.attempt_convert is not a very helpful abstraction.

I agree that if_empty does seem a little fishy applied to from_python.

Kevin

--
Kevin Dangoor
Author of the Zesty News RSS newsreader

email: ki...@bl...
company: http://www.BlazingThings.com
blog: http://www.BlueSkyOnMars.com

Kevin Dangoor wrote:
> On 10/5/05, Ian Bicking <ia...@co...> wrote:
> 
>>Kevin Dangoor wrote:
>>
>>>Because of the if_empty parameter, the StringBoolean validator in svn
>>>was returning False (not 'false') for from_python(False). This change
>>>fixes that:
>>
>>I wonder if 0/False should really be considered "empty"?  I.e., maybe
>>those values should be special-cased not to be empty.
> 
> 
> I don't think of those as empty. "Empty" implies a void. "", [], (),
> None are all empty. 0 and False are actual values.
> 
> 
>>I think so.  But also if_empty applied to from_python seems a little
>>fishy as well.  I suspect it should not be at all.  I also suspect that
>>FancyValidator.attempt_convert is not a very helpful abstraction.
> 
> 
> I agree that if_empty does seem a little fishy applied to from_python.

Both these are applied now, plus there is a validate_python setting 
which, if set to False, will let otherwise Invalid-seeming values get 
through (which is usually what I find I want, since I can't give errors 
to the client about data they don't yet have access to).

Hmm... I wonder if validate_python should be False by default. 
Conversions are still applied regardless.

-- 
Ian Bicking  /  ia...@co...  /  http://blog.ianbicking.org

On 10/5/05, Ian Bicking <ia...@co...> wrote:
> Both these are applied now, plus there is a validate_python setting
> which, if set to False, will let otherwise Invalid-seeming values get
> through (which is usually what I find I want, since I can't give errors
> to the client about data they don't yet have access to).

Sounds like a good addition, and I agree that it makes sense as a
default. Generally, the Python side will know what it's doing...

Kevin