[Pythonmac-SIG] [ann] appscript 0.4.0 released

[Bob Ippolito]

For that case, you would need to do something pretty funny..

ref.test(lambda obj: obj.size > 12 and obj.color == [0,0,0])

It is altogether possible, I suppose... but you more or less need to 
use lambda.  It would be 'fun' to write the code, but it might be too 
confusing/magical for most people?

On Feb 13, 2004, at 12:39 PM, Chris Ryland wrote:

> You could always take some method's code and walk it like a compiler, 
> doing special things for the special forms && and || etc.
>
> On Friday, February 13, 2004, at 12:03 PM, has wrote:
>
>> Chris Ryland wrote:
>>
>>>> Only thing still bugging me is that Python doesn't have magic 
>>>> methods for overridding 'and', 'or' and 'not' operators directly, 
>>>> as writing test expressions is clumsy without it. (Do you think we 
>>>> should submit a PEP for this?)
>>>
>>> Isn't the classical solution to define your datatypes such that 
>>> and/or/not/etc. are re-mapped as appropriate?
>>
>> Unfortunately, the only magic method Python provides is 
>> __nonzero__(), which doesn't help me as I need to know which operator 
>> was used and return an object rather than a boolean. (This is what it 
>> already does with comparison operators.)
>>
>>
>>> That's what some of the relational bindings packages (and some 
>>> symbolic logic packages) do.
>>
>>
>> Yep, same idea here: sweeten an otherwise drab-n-dreary API with some 
>> tasty syntactic sugar. Downside's when you start stubbing your toes 
>> on other folk's YAGNIs. :)
>>
>> --
>>
>> Michael Hudson wrote:
>>
>>> No.  They're control flow constructs.
>>
>> Hum. You mean like it's an underlying implementation issue? I'd 
>> simply assumed these three were operators like any others.
>>
>>
>>> 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}
>>
>> 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>'.
>>
>>
>>> 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).
>>
>> 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. :)
>>
>>
>> Lemme know what you think.
>>
>> Thanks,
>>
>> has
>>
>> -- 
>> http://freespace.virgin.net/hamish.sanderson/
>>
>>
>
> Cheers!
> --Chris Ryland / Em Software, Inc. / www.emsoftware.com
>
>
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG at python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig