Proposal: runtime validation statement

[Ville Vainio]

>>>>> "Paul" == Paul Rubin <http://phr.cx@NOSPAM.invalid> writes:

    Paul> I can sympathize with the notion that print and assert are
    Paul> warts, but I think they're considered to be important to
    Paul> Python's newbie-friendliness or something like that.  As
    Paul> such, "validate" ought to be considered about the same way.

How is 

print("hello",42)

less newbie friendly than

print "hello",42?

To me, the former actually seems *more* newbie friendly because there
is nothing special about it. The same applies for assert, validate and
other statements that don't need to be statements.

    >> Any specific reason not to make [validate] a builtin function
    >> instead of statement?

    Paul> It's similar enough to assert that for consistency in the
    Paul> language I think it ought to be done the same way.  But a
    Paul> builtin function would be ok.

"foolish consistency..." ;-).

    >> validate((x,int), (y,str), x > int(y))

    Paul> If the compiler is going to rely on something like that,
    Paul> then it should definitely be a statement, rather than a
    Paul> function that the user

Of course the compiler wouldn't rely on it. I was thinking of an
interim solution for auxiliary tools like doc generators - but then I
remembered we are going to get decorators soon, and they are better
for this purpose.

    >> (validate checks every tuple with isinstance(t[0],t[1]), every arg to
    >> validate that is "false" in the pythonic falsehoos sense2 fails the
    >> validation)

    Paul> This is a little bit bogus: first of all, data validation should be

Yes, it is - as I said, decorators will work better. My bad.

-- 
Ville Vainio   http://tinyurl.com/2prnb