Fixed a couple of typos in the Python API docs
authorHoward Trickey <howard.trickey@gmail.com>
Fri, 23 Mar 2012 14:29:59 +0000 (14:29 +0000)
committerHoward Trickey <howard.trickey@gmail.com>
Fri, 23 Mar 2012 14:29:59 +0000 (14:29 +0000)
doc/python_api/rst/include__bmesh.rst
doc/python_api/rst/info_best_practice.rst
doc/python_api/rst/info_gotcha.rst

index 025788ae9f4d43acc9a4f0cee3f18757697e9ee3..a8d299a5894ff79a5314545e81ea5fc1461cf12c 100644 (file)
@@ -110,10 +110,10 @@ Keeping a Correct State
 When modeling in blender there are certain assumptions made about the state of the mesh.
 
 * hidden geometry isn't selected.
-* when an edge is selected, its vertices's are selected too.
-* when a face is selected, its edges and vertices's are selected.
+* when an edge is selected, its vertices are selected too.
+* when a face is selected, its edges and vertices are selected.
 * duplicate edges / faces don't exist.
-* faces have at least 3 vertices's.
+* faces have at least 3 vertices.
 
 To give developers flexibility these conventions are not enforced,
 however tools must leave the mesh in a valid state else other tools may behave incorrectly.
index 1f0f81f7d14a10508183c4cf921d25fafc9a6c56..481555d412a8e186d71597f2ef6d0e9913f8d171 100644 (file)
@@ -268,7 +268,7 @@ The **try** statement is useful to save time writing error checking code.
 
 However **try** is significantly slower then an **if** since an exception has to be set each time, so avoid using **try** in areas of your code that execute in a loop and runs many times.
 
-There are cases where using **try** is faster than checking weather the condition will raise an error, so it is worth experimenting.
+There are cases where using **try** is faster than checking whether the condition will raise an error, so it is worth experimenting.
 
 
 Value Comparison
index 1d94d68e15ef481f60594ef59145cebe5176d27c..25ef5175976fa90c5f899bf7ad127984d92ccbc2 100644 (file)
@@ -155,7 +155,7 @@ Support Overview
 +==============+==============================+================================+================================+
 |Import/Create |Bad (inflexible)              |Fine (supported as upgrade path)|Best                            |
 +--------------+------------------------------+--------------------------------+--------------------------------+
-|Manipulate    |Bad (inflexible)              |Bad (looses ngons)              |Best                            |
+|Manipulate    |Bad (inflexible)              |Bad (loses ngons)               |Best                            |
 +--------------+------------------------------+--------------------------------+--------------------------------+
 |Export/Output |Good (ngons)                  |Good (When ngons can't be used) |Good (ngons, memory overhead)   |
 +--------------+------------------------------+--------------------------------+--------------------------------+
@@ -188,7 +188,7 @@ Editing is where the 3 data types vary most.
 Exporting
 ---------
 
-All 3 data types can be used for exporting, the choice mostly depends on weather the target format supports ngons or not.
+All 3 data types can be used for exporting, the choice mostly depends on whether the target format supports ngons or not.
 
 * polygons are the most direct & efficient way to export providing they convert into the output format easily enough.
 * tessfaces work well for exporting to formats which dont support ngons, in fact this is the only place where their use is encouraged.