[Python-ideas] Break the dominance of boolean values in boolean context

Guido van Rossum guido at python.org
Thu Sep 15 16:59:58 CEST 2011

On Wed, Sep 14, 2011 at 9:22 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> On 14/09/11 05:56, Guido van Rossum wrote:
>> I think I just mentioned one (turning 'if not' into a jump). Anyway,
>> I'm glad to reject the PEP for the reason that I like the status quo
>> just fine.
> Did you see the comment I made concerning jump optimizations?
> (Briefly, I don't think it would do any harm to keep performing
> this optimization, since it wouldn't affect any of my intended
> use cases.)
>> Also, after reading the PEP from beginning to end ... I think the
>> offered API is too complicated to be of much use.
> There's a bit more machinery involved than there is with the
> other operators, but I believe that any given use cases will
> usually only *use* part of it. In particular, a system for
> building parse trees only needs to implement the 2-operand
> methods, which is no more complicated than overriding any of
> the existing operators.
> If it would help, I could provide a couple of fully-worked
> examples, so you can see how complicated (or not) it would be
> to use in practice.
> There's also the possibility of simplifying the API if it's
> considered that some of it will *never* be used, e.g. by
> eliminating the machinery for custom short-circuiting.
>> Certainly the NumPy folks have
>> repeatedly claimed that they are fine with the status quo.
> NumPy is not the only use case by a long shot. The main reason
> I want it is for expressing database queries. You only have to
> look at the contortions that things like Django have to go
> through to wonder whether there's a better way.
> Apologies if I appear to be flogging a resting equine here. If
> you really don't want to think about it any more, I'll shut up.
> But if it's going to be rejected, I'd prefer it to be rejected
> for genuine reasons rather than FUD.

Actually, accepting or rejecting a PEP is always a matter of gut
feelings. Usually there's no hard argument that can be made about the
benefits for the language (a few use cases are easier to write, some
bugs are avoided) vs. the downsides (some users will be confused, some
bugs will occur, docs have to be updated, the compiler and runtime
will be a little more complex, the generated code may be a little bit
bulkier, etc.).

It's hard to weigh these, so please don't call it FUD, and be glad
it's not your responsibility to decide.

That said, having just implemented a query engine
I appreciate the pain for that particular use case and will hold off
until I've seen your examples.

--Guido van Rossum (python.org/~guido)

More information about the Python-ideas mailing list