| 2010-07-10 11:25:07 |
Eike |
bug |
|
|
added bug |
| 2010-07-10 11:26:23 |
Eike |
freeode: importance |
Undecided |
Wishlist |
|
| 2010-07-10 16:23:11 |
Eike |
tags |
|
interpreter |
|
| 2011-06-10 22:22:16 |
Eike |
description |
Currently both arguments of the boolean operators "and" and "or" are evaluated at compile time. impement short cut semantics because everybody expects this.
Possible solutions:
- Follow Python's implementation closely:
- At compile time call argument.__bool__() and decide in special purpose code.
- For generated code use special function which is converted by code generator back into shortcut
operator. (Similar to current implementation.)
- Implement idea from Greg Ewing (PEP 335: http://www.python.org/dev/peps/pep-0335/):
-Special methods for boolean operators 'and', 'or'
To retain the shortcut semantics split the execution of the
operator into two phases:
- first call __and1__(self), __or1__(self) if these operators
can compute the result they return True/False; otherwise they
return the special value NeedOtherOperand.
- if NeedOtherOperand was returned call:
__and2__(self, other), __rand2__(self, other)
__or2__(self, other), __ror2__(self, other)
- Calls with unknown arguments always end up as: __xx2__
(this is implemented) |
Currently both arguments of the boolean operators "and" and "or" are evaluated at compile time. impement short cut semantics because everybody expects this.
Possible solutions:
- Follow Python's implementation closely:
- At compile time call argument.__bool__() and decide in special purpose code.
- For generated code use special function which is converted by code generator back into shortcut
operator. (Similar to current implementation.)
- Implement idea from Greg Ewing (PEP 335: http://www.python.org/dev/peps/pep-0335/):
-Special methods for boolean operators 'and', 'or'
To retain the shortcut semantics split the execution of the
operator into two phases:
- first call __and1__(self), __or1__(self) if these operators
can compute the result they return True/False; otherwise they
return the special value NeedOtherOperand.
- if NeedOtherOperand was returned call:
__and2__(self, other), __rand2__(self, other)
__or2__(self, other), __ror2__(self, other)
- Calls with unknown arguments always end up as: __xx2__
(this is implemented)
https://sourceforge.net/apps/trac/freeode/ticket/37 |
|
| 2012-02-29 20:49:30 |
Eike |
description |
Currently both arguments of the boolean operators "and" and "or" are evaluated at compile time. impement short cut semantics because everybody expects this.
Possible solutions:
- Follow Python's implementation closely:
- At compile time call argument.__bool__() and decide in special purpose code.
- For generated code use special function which is converted by code generator back into shortcut
operator. (Similar to current implementation.)
- Implement idea from Greg Ewing (PEP 335: http://www.python.org/dev/peps/pep-0335/):
-Special methods for boolean operators 'and', 'or'
To retain the shortcut semantics split the execution of the
operator into two phases:
- first call __and1__(self), __or1__(self) if these operators
can compute the result they return True/False; otherwise they
return the special value NeedOtherOperand.
- if NeedOtherOperand was returned call:
__and2__(self, other), __rand2__(self, other)
__or2__(self, other), __ror2__(self, other)
- Calls with unknown arguments always end up as: __xx2__
(this is implemented)
https://sourceforge.net/apps/trac/freeode/ticket/37 |
Currently both arguments of the boolean operators "and" and "or" are evaluated at compile time. impement short cut semantics because everybody expects this.
Possible solutions:
- Follow Python's implementation closely:
- At compile time call argument.__bool__() and decide in special purpose code.
- At compile time call argument.__bool__() and decide in special purpose code.
- For generated code use special function which is converted by code generator back into shortcut
- For generated code use special function which is converted by code generator back into shortcut
operator. (Similar to current implementation.)
operator. (Similar to current implementation.)
- Implement idea from Greg Ewing (PEP 335: http://www.python.org/dev/peps/pep-0335/):
-Special methods for boolean operators 'and', 'or'
-Special methods for boolean operators 'and', 'or'
To retain the shortcut semantics split the execution of the
To retain the shortcut semantics split the execution of the
operator into two phases:
operator into two phases:
- first call __and1__(self), __or1__(self) if these operators
- first call __and1__(self), __or1__(self) if these operators
can compute the result they return True/False; otherwise they
can compute the result they return True/False; otherwise they
return the special value !NeedOtherOperand.
- if !NeedOtherOperand was returned call:
__and2__(self, other), __rand2__(self, other)
__or2__(self, other), __ror2__(self, other)
return the special value NeedOtherOperand.
- if NeedOtherOperand was returned call:
__and2__(self, other), __rand2__(self, other)
__or2__(self, other), __ror2__(self, other)
- Calls with unknown arguments always end up as: __xx2__
- Calls with unknown arguments always end up as: __xx2__
(this is implemented)
(this is implemented)
https://sourceforge.net/apps/trac/freeode/ticket/37 |
|
| 2012-02-29 22:31:24 |
Eike |
freeode: milestone |
|
0.4.2 |
|
| 2012-02-29 22:31:26 |
Eike |
description |
Currently both arguments of the boolean operators "and" and "or" are evaluated at compile time. impement short cut semantics because everybody expects this.
Possible solutions:
- Follow Python's implementation closely:
- At compile time call argument.__bool__() and decide in special purpose code.
- At compile time call argument.__bool__() and decide in special purpose code.
- For generated code use special function which is converted by code generator back into shortcut
- For generated code use special function which is converted by code generator back into shortcut
operator. (Similar to current implementation.)
operator. (Similar to current implementation.)
- Implement idea from Greg Ewing (PEP 335: http://www.python.org/dev/peps/pep-0335/):
-Special methods for boolean operators 'and', 'or'
-Special methods for boolean operators 'and', 'or'
To retain the shortcut semantics split the execution of the
To retain the shortcut semantics split the execution of the
operator into two phases:
operator into two phases:
- first call __and1__(self), __or1__(self) if these operators
- first call __and1__(self), __or1__(self) if these operators
can compute the result they return True/False; otherwise they
can compute the result they return True/False; otherwise they
return the special value !NeedOtherOperand.
- if !NeedOtherOperand was returned call:
__and2__(self, other), __rand2__(self, other)
__or2__(self, other), __ror2__(self, other)
return the special value NeedOtherOperand.
- if NeedOtherOperand was returned call:
__and2__(self, other), __rand2__(self, other)
__or2__(self, other), __ror2__(self, other)
- Calls with unknown arguments always end up as: __xx2__
- Calls with unknown arguments always end up as: __xx2__
(this is implemented)
(this is implemented)
https://sourceforge.net/apps/trac/freeode/ticket/37 |
Currently both arguments of the boolean operators "and" and "or" are evaluated at compile time. impement short cut semantics because everybody expects this.
Possible solutions:
- Follow Python's implementation closely:
- At compile time call `argument.__bool__()` and decide in special purpose code.
- For generated code use special function which is converted by code generator back into shortcut
operator. (Similar to current implementation.)
- Implement idea from Greg Ewing (PEP 335: http://www.python.org/dev/peps/pep-0335/):
- Special methods for boolean operators `and`, `or`.
To retain the shortcut semantics split the execution of the
operator into two phases:
- first call `__and1__(self)`, `__or1__(self)` if these operators
can compute the result they return `True`/`False`; otherwise they
return the special value !NeedOtherOperand.
- if !NeedOtherOperand was returned call:
`__and2__(self, other)`, `__rand2__(self, other)`
return the special value `NeedOtherOperand`.
- if `NeedOtherOperand` was returned call:
`__and2__(self, other)`, `__rand2__(self, other)`
- Calls with unknown arguments always end up as: `__xx2__`
(this is implemented)
https://sourceforge.net/apps/trac/freeode/ticket/37 |
|
