PEP 285: Adding a bool type

[Laura Creighton]

Guido:
> Laura, you've said this over and over, and I don't buy it.
> 
> Two arguments from XP apply here:
> 
> - YAGNI (You Ain't Gonna Need It), or also "do the simplest thing that
>   can possibly work".  If all you need today is a bool, use a bool.

Aha, now I understand a large part of why we disagree.  A bool is not
simpler than an int.  'Something that can change state' is simpler than
'something that can change state and must only have one of two values'.
Do you go around making functions that return bool all the time, only
then to change them to return int every time you have the idea that 
there actually are 3 states here you want to model?  Then you will
be littered with one obsolete 2-valued function every time this happens.
They pile up, and since your wretched customers have all started using
the 2-value functions, you are stuck having to maintain these things,
even though you now hate them, and want everybody to use the 3-value
versions.

> - "Refactor mercilessly".  If you find later that an int makes more
>   sense than a bool for a particular function or variable, change it!
>   It's not the end of the world.

But we agree that refactoring is not good for its own sake, it would
be better to have not needed the refactoring because we got it correct
the first time.  Refactoring is necessary because, we make mistakes,
and we learn and grow, and because our situation changes.  But if we
are writing functions that are to be used by others in libraries someplace,
we have to try to minimize the effect of our refactoring on others.
If other people have to refactor their code, every time that we have
to refactor ours, they will get pissed.  Rightly or wrongly, they will
conclude that either a) we are fools who never get it right the
first time b) this program is in a state of flux and it would be better
to wait for a more stable version or c) we are so taken with the joys
of refactoring for its own sake that we wish this wonderful experience
on everybody, whether they want to do so or not.

If enough people decide not to buy your product (or postpone
it until the later stable release) then your company goes bankrupt and
this _is_ the end of the world.  This is why deciding when to give your
poor customers the hell of refactoring is such a difficult skill. Agile
Programming was independently invented several places, in part as a
reaction against the idea that you must _never_ make the customer refactor.
You must always stick to the published design specs, even when they are
grossly, and horribly wrong because there is nothing more important than
stability.  This stinks, but not because instability is a virtue.

One reason that XP works so much better when you have the customer on board,
and can only be approximated and guessed at when you don't have frequent
meetings with your customer, is that when the customer drives the change
process it is easier to make them refactor.  They are willing to make the
changes because they are demanding the new features that require the 
changes.  In addition, when you get to know your customer, you can find
little places to put slack in because you know the particular habits they
have of how they change their minds.  If on 2 prior occasions he has
asked for a feature that required a list, and then changed his requirement
to somehting that needs a dictionary, you can have a fruitful discussion
with him.  'Any chance you are going to soon want this, that, and some
other feature?'  When your customer says 'oh yes, we were saving that for
next month, because we don't need the feature now, but will in September'
you will be glad that you have such a close relationship with the customer.

Building for a mass audience is different.  Then end-user customers have
to refactor in order that _some_ _other_ _person_  gets the new features 
he wants even though that end-user has no need or desire for the new 
feature. This is a significant barrier to sales. 

> Have you been teaching Python all those years?  I'd like to get to the
> bottom of this, because it's so against my own intuition.  I haven't
> been teaching, but I've sure helped a lot of people who were
> struggling with programming problems -- both in C and in Python.

I only discovered Python nearly 2 years ago, alas.  I wish it could have
been longer.

Laura Creighton