[Pythonmac-SIG] [ann] appscript 0.4.0 released

Michael Hudson mwh at python.net
Fri Feb 13 12:21:50 EST 2004


has <hengist.podd at virgin.net> writes:

> Michael Hudson wrote:
>
>>No.  They're control flow constructs.
>
> Hum. You mean like it's an underlying implementation issue? 

No.

> I'd simply assumed these three were operators like any others.

You can do things like

if d.has_key('thing') and d['thing'] > 0:
   ...

and not ever get KeyErrors (ok, this is a daft example, but...).

You *can* override && and so in C++ but it's a really daft idea, for
the same reason.

>>What you can do is:
>>
>>1) override the bitwise operators
>
> I've tried this (it's still supported, albeit as an undocumented
> feature, if you want to try it yourself). The problem is that the
> bitwise operators have higher precedence than the comparison
> operators, and I think it'll be too easy for users to forget to put
> parentheses around the operands. ie:
>
>     items.test((its.size > 12) & (its.color == [0,0,0])) # items whose
>     size > 12 and color = {0,0,0}

This kind of thing is I'm not a big fan of operator overloading, in
general.

> and not:
>
>     ref.test(its.size > 12 & its.color == [0,0,0])
>
> which'll cause an error when Python tries to evaluate '12 & its.color'
> instead of '<object> & <object>'.

Huh?  I think there's an __rand__ method, isn't there?

>>2) create a class-or-staticmethod Term.and_(cls,*things)
>
> Yeah. Currently the following syntax forms are all supported for
> evaluation purposes (this'll be cut down to one in the final release):
>
>     ref.test(
>           (its.size > 12) & (its.color == [0,0,0])
>     )
>
>     ref.test(
>           (its.size > 12).AND(its.color == [0,0,0])
>     )
>
>     ref.test(
>           AND(its.size > 12, its.color == [0,0,0])
>     )
>
>
> The middle one is the form that's currently documented; it
> approximates to infix syntax, avoids namespace pollution, and more or
> less ensures that folk'll use it correctly. However, it's fiddly to
> type and unpleasant to read, imo, which is a problem for ease-of-use
> (a key feature).

I think I prefer something like 3), but admittedly, I haven't used
that style for anything much...

> Probably the easiest thing's to play with all three for a bit, and see
> which you feel is least awful. Then decide which'll be easier: living
> with the kludge, or getting a 'magic method' PEP past the BDFL. :)

You have zero chance of the last, believe me.

Cheers,
mwh

-- 
  For the record, the NTL telephone voicemaze jail is almost as
  well-planned. I dialled the status recording, which is information-
  rich in much the same way as 10 Angstroms is a long way...
      -- Dan Barlow vs NTL: http://ww.telent.net/diary/2002/6/#18.8983



More information about the Pythonmac-SIG mailing list