PEP 285: Adding a bool type

Arthur Siegel ajs at ix.netcom.com
Wed May 1 11:11:46 EDT 2002


>From some code of mine:

(colors is an x by 3 Numeric array):

u = 0 in [colors[0] == c for c in colors]

if u:
  etc, etc,
else:
  etc, etc.

Let's assume its bad code in the sense of not
being the best way of accomplishing what I am trying
to accomplish.  But it seems to work,  it took me long enough
to figure it out, and once I got to something that seemed to work, I was
content to go on. Happens to be in an
export routine and is essentially performance non-sensitive.

There are 2 possibilities:


1) this will break under the bool implementation.

or the one I suspect to be true:

2) this will continue to work under the bool implementation.

The problem with possibility 1 is obvious.

The problem with 2 is also pretty obvious.
To the extent the boolean PEP is concerned about
suggesting a standard way of doing something
but not enforcing it, it defeats its own purpose.
The practical effect is that someone new to
Python will never be forced to confront the
0 = false idiom, and will mystified by code
(and if 2. above is true, I am confident that will
be common) that is written by folk who choose
not to conform to it.

The trade-off between these concerns and the milli-second
recognition factor mentioned in the PEP is clear, IMO.

And the line of thinking as to novices continues to concern
me.

How many novices trip up on '=' versus
'= ='.  A usability study - depending on how
it is conducted - could well conclude that
some change is necessary.  The interpreter
needs to determine the context of the = and
act accordingly.  Is this where we are
going?

Holding out the ever present possibility that I
am missing something essential here,
I am a -1.

Art





More information about the Python-list mailing list