Updated PEP 335, posted 25-Oct-2011.
This commit is contained in:
Guido van Rossum
parent
faf9b4ce77
commit
5cc322ca21
64
pep-0335.txt
64
pep-0335.txt
|
|
@ -2,13 +2,13 @@ PEP: 335
|
|||
Title: Overloadable Boolean Operators
|
||||
Version: $Revision$
|
||||
Last-Modified: $Date$
|
||||
Author: Gregory Ewing <greg.ewing@canterbury.ac.nz>
|
||||
Author: Gregory Ewing <greg@cosc.canterbury.ac.nz>
|
||||
Status: Draft
|
||||
Type: Standards Track
|
||||
Content-Type: text/x-rst
|
||||
Created: 29-Aug-2004
|
||||
Python-Version: 3.3
|
||||
Post-History: 05-Sep-2004, 30-Sep-2011
|
||||
Post-History: 05-Sep-2004, 30-Sep-2011, 25-Oct-2011
|
||||
|
||||
|
||||
Abstract
|
||||
|
|
@ -66,13 +66,23 @@ inconvenient. Examples include:
|
|||
|
||||
A workaround often suggested is to use the bitwise operators '&', '|'
|
||||
and '~' in place of 'and', 'or' and 'not', but this has some
|
||||
drawbacks. The precedence of these is different in relation to the
|
||||
other operators, and they may already be in use for other purposes (as
|
||||
in example 1). There is also the aesthetic consideration of forcing
|
||||
users to use something other than the most obvious syntax for what
|
||||
they are trying to express. This would be particularly acute in the
|
||||
case of example 3, considering that boolean operations are a staple of
|
||||
SQL queries.
|
||||
drawbacks:
|
||||
|
||||
* The precedence of these is different in relation to the other operators,
|
||||
and they may already be in use for other purposes (as in example 1).
|
||||
|
||||
* It is aesthetically displeasing to force users to use something other
|
||||
than the most obvious syntax for what they are trying to express. This
|
||||
would be particularly acute in the case of example 3, considering that
|
||||
boolean operations are a staple of SQL queries.
|
||||
|
||||
* Bitwise operators do not provide a solution to the problem of
|
||||
chained comparisons such as 'a < b < c' which involve an implicit
|
||||
'and' operation. Such expressions currently cannot be used at all
|
||||
on data types such as NumPy arrays where the result of a comparison
|
||||
cannot be treated as having normal boolean semantics; they must be
|
||||
expanded into something like (a < b) & (b < c), losing a considerable
|
||||
amount of clarity.
|
||||
|
||||
|
||||
Rationale
|
||||
|
|
@ -208,7 +218,7 @@ new operations::
|
|||
PyObject *PyObject_LogicalAnd1(PyObject *);
|
||||
PyObject *PyObject_LogicalOr1(PyObject *);
|
||||
PyObject *PyObject_LogicalAnd2(PyObject *, PyObject *);
|
||||
|
||||
PyObject *PyObject_LogicalOr2(PyObject *, PyObject *);
|
||||
|
||||
|
||||
Alternatives and Optimisations
|
||||
|
|
@ -366,29 +376,29 @@ Example 1: NumPy Arrays
|
|||
return "barray(%s)" % ndarray.__str__(self)
|
||||
|
||||
def __and2__(self, other):
|
||||
return self & other
|
||||
return (self & other)
|
||||
|
||||
def __or2__(self, other):
|
||||
return self & other
|
||||
return (self & other)
|
||||
|
||||
def __not__(self):
|
||||
return self == 0
|
||||
return (self == 0)
|
||||
|
||||
def barray(*args, **kwds):
|
||||
return array(*args, **kwds).view(type=BArray)
|
||||
return array(*args, **kwds).view(type = BArray)
|
||||
|
||||
a0 = barray([0, 1, 2, 4])
|
||||
a1 = barray([1, 2, 3, 4])
|
||||
a2 = barray([5, 6, 3, 4])
|
||||
a3 = barray([5, 1, 2, 4])
|
||||
|
||||
print("a0:", a0)
|
||||
print("a1:", a1)
|
||||
print("a2:", a2)
|
||||
print("a3:", a3)
|
||||
print("not a0:", not a0)
|
||||
print("a0 == a1 and a2 == a3:", a0 == a1 and a2 == a3)
|
||||
print("a0 == a1 or a2 == a3:", a0 == a1 or a2 == a3)
|
||||
print "a0:", a0
|
||||
print "a1:", a1
|
||||
print "a2:", a2
|
||||
print "a3:", a3
|
||||
print "not a0:", not a0
|
||||
print "a0 == a1 and a2 == a3:", a0 == a1 and a2 == a3
|
||||
print "a0 == a1 or a2 == a3:", a0 == a1 or a2 == a3
|
||||
|
||||
Example 1 Output
|
||||
----------------
|
||||
|
|
@ -417,7 +427,7 @@ Example 2: Database Queries
|
|||
#
|
||||
#-----------------------------------------------------------------
|
||||
|
||||
class SQLNode:
|
||||
class SQLNode(object):
|
||||
|
||||
def __and2__(self, other):
|
||||
return SQLBinop("and", self, other)
|
||||
|
|
@ -473,7 +483,7 @@ Example 2: Database Queries
|
|||
return self
|
||||
|
||||
def __sql__(self):
|
||||
result = "SELECT %s" % ", ".join(sql(target) for target in self.targets)
|
||||
result = "SELECT %s" % ", ".join([sql(target) for target in self.targets])
|
||||
if self.where_clause:
|
||||
result = "%s WHERE %s" % (result, sql(self.where_clause))
|
||||
return result
|
||||
|
|
@ -491,10 +501,8 @@ Example 2: Database Queries
|
|||
def select(*targets):
|
||||
return SQLSelect(targets)
|
||||
|
||||
#-----------------------------------------------------------------
|
||||
|
||||
#--------------------------------------------------------------------------------
|
||||
|
||||
::
|
||||
dishes = Table("dishes")
|
||||
customers = Table("customers")
|
||||
orders = Table("orders")
|
||||
|
|
@ -503,8 +511,8 @@ Example 2: Database Queries
|
|||
customers.cust_id == orders.cust_id and orders.dish_id == dishes.dish_id
|
||||
and dishes.name == "Spam, Eggs, Sausages and Spam")
|
||||
|
||||
print(repr(query))
|
||||
print(sql(query))
|
||||
print repr(query)
|
||||
print sql(query)
|
||||
|
||||
Example 2 Output
|
||||
----------------
|
||||
|
|
|
|||
Loading…
Reference in New Issue