not safe at all

Tim Peters tim.one at home.com
Sat Jul 14 16:34:09 EDT 2001


[Alex Martelli]
> ...
> Actually, I wouldn't mind an 'assertion language' that's not even
> truly checkable (fast enough to be useful) at runtime -- one where
> I could use existential and universal quantifiers, because those are
> so often the things I *WANT* to express in a formal, unambiguous
> way.  Consider the predicate parameter P I can pass to many of
> the containers and algorithms in the standard C++ library.  What
> I often want to assert about the type of P is: for all X, not P(X,X);
> for all X and Y, P(X,Y) implies not P(Y,X); for all X, Y and Z,
> P(X,Y) and P(Y,Z) imply P(X,Z).  I.e., the crucial facts about P's
> type is that it's antireflexive, antisymmetric, transitive.  What I
> _can_ assert that's static-type-checkable is that P accepts two
> "foo" arguments and returns a boolean.  Pish and tush -- that's
> close to saying NOTHING about the known type constraints on P!!!

LOL -- "pish and tush" is exactly on-target.

ABC (Python's predecessor) had quantified boolean expressions, of the forms

1.  each x in s has expression_involving_x
2.  no x in s has expression_involving_x
3.  some x in s has expression_involving_x

The keywords there are "each", "no", "some", "in" and "has".  They had a
very nice twist:  if an expression of form #1 was false, it left x bound to
"the first" counterexample (i.e., "the first" x in s that did not satisfy
the predicate expression); similarly if #2 was false, it left x bound to the
first witness (the first x in s that did satisfy the predicate); and if #3
was true, to the first witness.  For example,

    if some i in xrange(2, int(sqrt(n))+1) has n % i == 0:
        print n, "isn't prime -- it's divisible by", i

or

    assert no x in xrange(2, int(sqrt(n))+1) has n % i == 0, "n not prime"

According to Guido, Lambert Meertens (ABC's chief designer) spent a
sabbatical year in New York City working with some of the SETL people, and I
speculate that's where this cool little ABC subsystem came from.  I would
like it in Python too, but it's a lot of new keywords to support one
conceptual gimmick.  It's still a pleasant pseudo-code notation to use in
comments, though.

uncommonly-fond-of-constructs-that-capture-common-loops-ly y'rs  - tim





More information about the Python-list mailing list