A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2002-March/020787.html below:

[Python-Dev] For review: PEP 285: Adding a bool type

[Python-Dev] For review: PEP 285: Adding a bool typeDavid Ascher DavidA@ActiveState.com
Fri, 08 Mar 2002 11:04:15 -0800
Current Rationale for PEP 285:

    Most languages eventually grow a Boolean type; even C99 has one.
    It's useful to be able to tell from a function result that the
    outcome has Boolean semantics, and it helps with things like RPC
    protocols that may prefer to encode Booleans differently from
    integers.

I'd like to get a clearer understanding of the rationale of adding a new
type which would become commonly used, in view of the cost of the change
(in terms of complexity, backwards compatibility issues,
development/debugging time, outdated docs, etc.).

I think it's key to identify the ways in which the current semantics and
idioms are suboptimal.

1) "Most languages eventually grow a Boolean type; even C99 has one."

While I've often wanted a boolean (mostly for 'aesthetic reasons'), I
think it's important that the rationale for a language modification be
deeper than "everyone else does it".

2) "it helps with things like RPC protocols that may prefer to encode
Booleans differently from integers."

That is a real issue except that it seems to have been solved relatively
well by all of the language bindings so far.  IIRC, there are some
awkward situations in Jython if you explicitly want to send a boolean to
a polymorphic function, but that's an edge case.

3) "It's useful to be able to tell from a function result that the
    outcome has Boolean semantics"

This is intriguing.  I can't think of a case where the current integer
return values have caused me problems or concerns that weren't solved by
simply understanding what the function was about.  What use case did you
have in mind?

4) Booleans lead quickly to the 'memory savings' notions of packed
arrays of bits, which seems a detail of array implementation issues
different from this proposal.  I think the array folks could implement
this w/o a "core" Python datatype, just like they/we've dealt with
low-precision floats.

All in all, I'm neither for nor against at this point, but I think the
rationale for the change needs further elaboration.  And feeling
conservative today, without that I'd vote against it on complexity
grounds.

--david



RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4