Grammer

async_v20/definitions/metaclass.py

@@ -84,12 +84,12 @@ def __new__(mcs, *args, **kwargs):
 
         # async_v20 allows camelCase and snake_case to be used when instantiating objects.
         # arguments passed in camelCase are converted to snake_case prior to attribute assignment.
-        # Signatures arguments are also snake_case.
-        # when serializing objects attributes must be converted to camelCase,
+        # Signature arguments are also snake_case.
+        # when serializing objects. Attributes must be converted to camelCase,
         # as per OANDA's specification.
         # To achieve this these two dictionary's are created:
         #   instance_attributes :- camelCase & snake_case keys -> snake_case values
-        #   json_attributes :- snake_case
+        #   json_attributes :- snake_case keys -> camelCase values
         mcs.instance_attributes.update(create_instance_attributes(class_obj))
         mcs.json_attributes.update(create_json_attributes(class_obj))
 

doc/source/beyond_getting_started.rst

@@ -100,7 +100,7 @@ each *OandaClient*. **method** defines.
 
 There is a two step process by which the response is constructed:
    - The http :term:`status` is used to look up the expected response
-   - Each JSON object is constructed into the appropriate object
+   - Each JSON object is constructed into the appropriate python object
 
 How Objects are Serialized
 __________________________
@@ -112,7 +112,7 @@ The issue here is that OANDA defines objects with :term:`camelCase` :term:`attri
 Python programs typically reserve camelCase for :term:`class` definitions.
 
 This means, in order to both satisfy python standards and OANDA,
-objects as defined in :ref:`class-definitions` need to accept `camelCase` and :term:`snake_case`
+objects (as defined in :ref:`class-definitions`) need to accept `camelCase` and :term:`snake_case`
 arguments when being constructed
 
 `objects` store there attributes as `snake_case` (as python programmers would expect),