PEP 285: Adding a bool type (partially OT)

[Ype Kingma]

Alex,

Alex Martelli wrote:
> 
> Ype Kingma wrote:
>         ...
> >> Even if having to modify the __getitem__, __setitem__, __delitem__ (at
> >> the least) of a zillion user-defined types out there was feasible (and
> >> it's not), I think this would not fully exhaust, as I indicated.
> >
> > The users writing such code were knowingly taking a risk by using
> > a name that starts with a double underscore. For these cases I think
> > deprecation is quite acceptable.
> 
> You completely misunderstand the role of special names in Python.
> It doesn't mean "I'm taking a risk": it means "I'm following fully
> documented, STABLE interfaces".

The language spec does not specify the type of the index or key
argument to __getitem__.
As for the possible types of this argument you are at the mercy
of the possible types and the program doing the indexing.
So indeed, the double underscore does not matter: this is also
the case for normal methods in user code.

<snip>

> > When the object passed to your __getitem__ method does not
> > have .start and .stop attributes you could simply call int()
> > on it from within your __getitem__ implementation.
> 
> Incompatible with built-in lists, which raise an exception when
> indexed with complex or float numbers for example.  There are
> good reasons for that, and it's unwise to suggest breaking the
> mold with as little understanding of those reasons as your posts
> are consistently suggesting.

You didn't mention before that you need compatibility with built-in
lists. I did wonder what your indexable objects would be doing, but
I preferred not to speculate on that.
 
> > But you would only need to do this in certain cases, see below.
> 
> In fact, doing it in most other cases would be very unadvisable.

Surprise, surprise: a bit of agreement.

> >> > Indexing a dict with both int and bool keys might involve some
> >> > confusion when True is not 1 anymore. This case should be rare,
> >> > however.
> >>
> >> Why should it be rare?  All hashables are used uniformly as keys
> >> into dictionaries.
> >
> > It should be rare because the confusion would only occur when both
> > True and 1 are used as keys and they are intended to be the same key.
> 
> Any existing code doesn't know about any distinction between True and 1.
> There is no distinction between them up to the current release.  Therefore,
> any existing code will become utterly fragile if and when a distinction
> should suddenly appear out of the blue.  From the point of view of code
> implementing a mapping, there's no "intended to be the same" -- as there
> is no notion of any distinction between two cases (there is only one case
> today).  Similarly for client-code, code that USES a mapping (most often
> polymorphically).  What "intended to be" can it mean (or fail to mean)
> between objects that's always been identical?  For example, using a dict
> as a set has always yielded identical results for:
>     - testing membership with aset.has_key(item),
> or:
>     - indicating membership with aset[item] = 1, then
>     - testing membership with aset.get(item, 0)
> 
> Why would you think this is "rare"?  It's common currency.  How many tens
> of thousands of lines of python have you written, reviewed, or maintained,
> that you presume to teach me what is common and what is rare in python
> "as she is spoken", pray?

In how many of these cases would the 'item' key actually be confused
when it could be either a bool or an int? So far you failed to convince me
that this is not a rare case.

Even though I don't see the relevance of the second question
the answer is: a few, and I'm not teaching here, I'm explaining
my opinion.

> > That should only happen when True and 1 are used interchangeably,
> > which might happen by programmer mistake or by using
> > old (1/0) and new (True/False) style code together.
> 
> Old-style only will do perfectly well, since lots of extremely common
> idioms therein (a<b, d.has_key(k), x in y, and so on) change return
> values silently.  Neither any mistake nor any 'together' is needed,
> unless you're somehow trying to imply that anybody coding some kind
> of "advanced" (?!) construct such as "a<b" was using "new style code"
> unwittingly years ago...

By new style I meant explicit use of True/False. As for "advanced (?!):
I don't have a time machine.
 
> > The slowdown would be there for backwards compatibility only.
> 
> In yoyr proposal the slowdown would be there in every dict access.
> 
> > In the pure case an int() call would not be needed at all:
> 
> But to check whether it's needed or not, a type-check would be
> needed, and that IS a substantial slow-down.  You don't seem to

If it's not needed at all, there is also no need for the check.

<snipped some irrelevant rank pulling>

> > When adding the int() call to the __setitem__ method of the standard
> > dicts for backward compatibility the dict shown above would only a have
> > a single key 1 and the value would be the last value put there.
> 
> ...and pystones would become...?
> 
> >> "only hope" is not acceptable in this context.  Fortunately, we can
> >> do better than that (and I'm confident that the unacceptability of
> >> slowing down dictionaries and lists is quite obvious to decision
> >> makers in this case, so I don't fear it will happen).
> >
> > I'm still putting my hopes on deprecation (as above) after PEP 285 enters
> > into force. During the deprecation phase with non int bools such cases
> > could be warned for eg. by a special verion of int() that would also cause
> > a slowdown, and after the deprecation a pure version with normal speed
> > would remain.

And now for some fine gorgheggio:

> We have a saying in Italy -- "chi vive sperando muore cantando".  "He
> who lives hoping, dies singing".  I suggest you practice gorgheggio -- not
> a popular singing technique any more, alas, but should you ever find
> yourself cast in some (e.g.) Salieri or Gluck (Italian-style) it might come
> in handy.  And if you don't understand a word I'm saying, may I suggest
> remedying that with a course in opera buffa -- its 17-th century and
> earlier roots, its 18-th century apogee (you'll find debate on that timing,
> but that's the school I subscribe to), its 19-th century long, slow decline
> (ditto).  With any luck, such a course might just happen to show you the
> career you were always destined to, and distract you from subjects you
> appear to be unsuited for, such as programming language design and
> implementation.  One can always hope (recursive call to the beginning of
> this paragraph).

End of fine gorgheggio. Applause.

As it happens I have enjoyed an opera buffa from the 18th century live
towards the end of the previous century. So, I guess there is still hope.
Moreover the BDFL today called the new bool type 'impure' on c.l.p.,
giving me even more hope.

> > P.S. I havn't followed the change of behaviour of the / operator in
> > detail, but wasn't/isn't this done using a deprecation period with
> > warnings, too?
> 
> And commandline switches (see -Q, still alive and kicking) and so
> on.  It's not a matter of "following the change", you just need some
> modest amount of studying the current Python release.
> 
> Now a surprise-test: how many divisions are there in a typical piece
> of Python, versus, how many dictionary lookups...?  Fair warning: this
> IS a trick question.  Only sensible way to answer it is, instrument the
> Python compiler.  If you find this a problem, then you're not very

Instrumenting the compiler would only give you the number of times
these operations are present in the source code.
To measure the more relevant actual numbers of executed operations I'd
rather instrument the python byte code. In case these operations can be
deduced from the byte codes, it might be easier to instrument the
byte code interpreter.

> qualified to comment on language implementation strategy, are you...?

I am posting on c.l.p, not on python-dev. 
I am not talking about an actual implementation.
I'm talking about a specification, while trying to keep an eye on
implementABILITY.
Since you didn't say it cannot be done, I'm actually encouraged.


Ype

-- 
email at xs4all.nl