[Python-3000] Builtin iterator type

[George Sakkis]

On 11/15/06, Josiah Carlson <jcarlson at uci.edu> wrote:
>
> "George Sakkis" <gsakkis at rutgers.edu> wrote:
> > You missed my point; I wasn't seriously suggesting that there should
> > be more checks (hence the quotes), but rather the contrary, that
> > checking whether len() returns a non-negative integer does very little
> > to the overall consistency scheme of things.
> >
> > Pre-conditions, post-conditions, invariants are a stricter form of API
> > conformance than just checking whether a method with a specific name
> > is there, and Python is unwilling to check even that.
>
> No, it's not that Python is unwilling, we just haven't found the need.
> For people who want/need to _enforce_ preconditions, postconditions,
> invariants, etc., Python 2.4 introduced a decorator syntax that makes it
> (arguably) trivial to declare such things...
>
> @typecheck((int, long), (int, long), (int, long, float))
> @precondition(ARG > 0, 0 < ARG < 10, NOTIN(inf, NaN, -inf))
> @postcondition(NOTIN(inf, NaN, -inf))
> def fcn(a, b, c):
>     ...
>
> Given proper definitions of typecheck, precondition, postcondition, ARG
> and NOTIN.
>
> For the rest of us who document, use unit testing (with or without the
> unittest framework), etc., thinking of development in terms of what we
> learned in school for developing C, C++, or Java seems backwards (at
> least in my opinion).  I can spend days writing all of that crap, or I
> can spend a few hours writing the software with unittests in Python.

To avoid leading this to a digression about optional typing, my point
was that what len() does is a builtin postcondition, and if, for some
perverse reason, someone wants to define negative or complex lengths
for his perverse class, he'll hit into a wall. Is this yet another
case of practicality beating purity hands down ?

George