diff --git a/PythonStyleGuide.wiki b/PythonStyleGuide.wiki
index 318b583..d42e0e5 100644
--- a/PythonStyleGuide.wiki
+++ b/PythonStyleGuide.wiki
@@ -31,11 +31,6 @@
 
  # [PythonStyleGuide#Imports Imports]: _Import only modules and only by name *(no wildcard imports)*_
  # [PythonStyleGuide#Function_Arguments Function Arguments]: _Yes_
- # [PythonStyleGuide#Properties Properties]: _Yes_
- # [PythonStyleGuide#True_False_evaluations True/False evaluations]: _Yes_
- # [PythonStyleGuide#Boolean_built_in_type Boolean built-in type]: _Yes_
- # [PythonStyleGuide#String_Methods String Methods]: _Yes_
- # [PythonStyleGuide#Lexical_Scoping Lexical Scoping]: _Yes_
  # [PythonStyleGuide#Function_and_Method_Decorators Function and Method Decorators]: _Yes, *in moderation*_
  # [PythonStyleGuide#Threading Threading]: _*do not use* (not available in [http://code.google.com/appengine/kb/general.html#libraries Google App Engine])_
  # [PythonStyleGuide#Power_features Power features]: _*No*_
@@ -114,159 +109,6 @@
 *Decision:* Always pass positional arguments positionally and keyword
 arguments by keyword.
 
-== Properties ==
-
-*What they are:* A way to wrap method calls for getting and setting an
-attribute as a standard attribute access when the computation is lightweight.
-
-*Pros:* Readability is increased by eliminating explicit `get` and `set`
-method calls for simple attribute access. Allows calculations to be lazy.
-Considered the Pythonic way to maintain the interface of a class. In terms
-of performance, allowing properties bypasses needing trivial accessor
-methods when a direct variable access is reasonable while allowing future
-accessor methods to be possible without breaking the interface.
-
-*Cons:* Properties are specified after the getter and setter methods are
-declared, requiring one to notice they are used for properties farther down
-in the code (except for read-only properties created with the `@property`
-decorator - see below). Must inherit from object. Can hide side-effects
-much like operator overloading. Can be confusing for subclasses.
-
-*Decision:* Use properties in code where you are accessing or setting
-data where you would normally have used simple, lightweight accessor or
-setter methods. Read-only properties should be created with the
-`@property` [PythonStyleGuide#Function_and_Method_Decorators decorator].
-
-Inheritance with properties can be non-obvious if the property itself
-is not overridden. Thus one must make sure that accessor methods are
-called indirectly to ensure methods overridden in subclasses are called
-by the property (using the Template Method design pattern).
-
-*Yes:*
-
-{{{
-import math
-
-class Square(object):
-  """Basic square with writable 'area' property, read-only 'perimeter' property.
-
-  To use:
-  >>> sq = Square(3)
-  >>> sq.area
-  9
-  >>> sq.perimeter
-  12
-  >>> sq.area = 16
-  >>> sq.side
-  4
-  >>> sq.perimeter
-  16
-  """
-
-  def __init__(self, side):
-    self.side = side
-
-  def _getArea(self):
-    """Calculation for 'area' property"""
-    return self.side ** 2
-
-  def __getArea(self):
-    """Indirect accessor for 'area' property"""
-    return self._getArea()
-
-  def _setArea(self, area):
-    """Setter for 'area' property"""
-    self.side = math.sqrt(area)
-
-  def __setArea(self, area):
-    """Indirect setter for 'area' property"""
-    self._setArea(area)
-
-  area = property(__getArea, __setArea,
-                  doc="""Get or set the area of the square""")
-
-  @property
-  def perimeter(self):
-    return self.side * 4
-}}}     
-
-== True False evaluations ==
-
-*What it is:* Python evaluates certain values as "false" when in a boolean
-context. A quick "rule of thumb" is that all "empty" values are considered
-"false" so `0`, `None`, `[]`,` {}`, `""` all evaluate as "false" in a
-boolean context.
-
-*Pros:* Conditions using Python booleans are easier to read and less
-error-prone. In most cases, it's also faster.
-
-*Cons:* May look strange to C/C++ developers.
-
-*Decision:* Use the "implicit" false if at all possible, e.g.,
-`if foo:` rather than `if foo != []:`. There are a few caveats that you
-should keep in mind though:
-
- * Comparisons to singletons like `None` should always be done with `is` or `is not`. Also, beware of writing `if x:` when you really mean `if x is not None:` -e.g., when testing whether a variable or argument that defaults to `None` was set to some other value. The other value might be a value that's false in a boolean context!
- * For sequences (strings, lists, tuples), use the fact that empty sequences are false, so `if not seq:` or `if seq:` is preferable to `if len(seq):` or `if not len(seq):`.
- * Note that `'0'` (i.e., 0 as string) evaluates to true. 
-
-== Boolean built in type ==
-
-*What it is:* A boolean type has been available in Python since version 2.3.
-Two new built-in constants were added: `True` and `False`.
-
-*Pros:* It makes code easier to read and is backward-compatible with the
-use of integers as boolean in previous versions.
-
-*Cons:* None.
-
-*Decision:* Use booleans.
-
-== String Methods ==
-
-*What they are:* String objects include methods for functions that used to
-be in the `string` module.
-
-*Pros:* No need to import the `string` module; methods work with both
-regular byte-strings and unicode-strings.
-
-*Cons:* None.
-
-*Decision:* Use them. The `string` module is deprecated in favor of
-string methods.
-
-*No:* `words = string.split(foo, ':')`
-
-*Yes:* `words = foo.split(':')`
-
-== Lexical Scoping ==
-
-*What it is:* A nested Python function can refer to variables defined
-in enclosing functions, but can not assign to them. Variable bindings are
-resolved using lexical scoping, that is, based on the static program text.
-Any assignment to a name in a block will cause Python to treat all
-references to that name as a local variable, even if the use precedes
-the assignment. If a global declaration occurs, the name is treated as a
-global variable.
-
-An example of the use of this feature is:
-
-{{{
-def getAdder(summand1):
-  """getAdder returns a function that adds numbers to a given number."""
-  def anAdder(summand2):
-    return summand1 + summand2
-
-  return anAdder
-}}}
-
-*Pros:* Often results in clearer, more elegant code. Especially comforting
-to experienced Lisp and Scheme (and Haskell and ML and ...) programmers.
-
-*Cons:* None.
-
-*Decision:* Okay to use.
-
 == Function and Method Decorators ==
 
 *What they are:* Decorators for Functions and Methods, added in Python 2.4