Merge pull request cannatag#1058 from TuringTux/patch-1

Fix a few typos in documentation

docs/manual/source/add.rst

@@ -16,7 +16,7 @@ In the ldap3 library the signature for the Add operation is::
             attributes=None,
             controls=None)
 
-* dn: distinguish name of the object to add
+* dn: distinguished name of the object to add
 
 * object_class: class name of the attribute to add, can be a string containing a single value or a list of strings
 

docs/manual/source/connection.rst

@@ -332,7 +332,7 @@ You can check the result value to know if the operation has been sucessful. The
 
 * message: a diagnostic message sent by the server (optional)
 
-* dn: a distinguish name of an entry related to the request (optional)
+* dn: a distinguished name of an entry related to the request (optional)
 
 * referrals: a list of referrals where the operation can be continued (optional)
 

docs/manual/source/installation.rst

@@ -12,7 +12,7 @@ install ldap3. Then you can download and install the ldap3 library directly from
 
     pip install ldap3
 
-This library has only one dependence on the *pyasn1* module, You can install it or let the installer do it for you.
+This library has only one dependence on the *pyasn1* module, you can install it or let the installer do it for you.
 
 If you need to access a server with the Kerberos SASL authentication mechanism you must install the *gssapi* package.
 
@@ -68,7 +68,7 @@ Library errors
 --------------
 
 You can deal with errors in two different ways. By default in synchronous strategies each LDAP operation returns a
-True/False value that specify if the operation has been successful or not. In case of failures you can check the
+True/False value that specifies if the operation has been successful or not. In case of failures you can check the
 error description in the ```last_error``` attribute of the Connection object. In some cases an exception of the custom
 hierarchy starting from the ```LDAPExceptionError``` class is raised with a description of the error condition in the *args*
 attribute.

docs/manual/source/schema.rst

@@ -1,7 +1,7 @@
 Schema
 ######
 
-An LDAP server store information about *types* it can handle in its **schema**. The schema includes all information needed by a client to correctly performs
+An LDAP server store information about *types* it can handle in its **schema**. The schema includes all information needed by a client to correctly perform
 LDAP operations. Let's examine an LDAP server schema::
 
     >>> server.schema
@@ -75,7 +75,7 @@ The LDAP server store *operational* information on each entry. This information
 available to the user via an **operational attribute** that can usually be read but not written.
 
 To request all operational attribute in a search you can use the ``+`` (PLUS) character as an attribute name. Keep in mind that the server
-may not return some operational attribute if they are not explicitly requested (because they may take a long time or many resources to be computed),
+may not return some operational attributes if they are not explicitly requested (because they may take a long time or many resources to be computed),
 so if you need a specific attribute is better to request it explicitly.
 
 Some server may not return attribute information in the schema. In this case the ldap3 library is not aware of them. This can lead to some erratic

docs/manual/source/searches.rst

@@ -226,7 +226,7 @@ while to get all the user and all the operational attributes you can use::
     attributes=[ALL_ATTRIBUTES, ALL_OPERATIONAL_ATTRIBUTES]
 
 
-Keep in mind that the server may not return some operational attribute if they are not explicitly requested
+Keep in mind that the server may not return some operational attributes if they are not explicitly requested
 (because they may take a long time or many resources to be computed), so if you need a specific attribute is better to
 request it explicitly. Also, some servers dont' return operational attributes information when reading the schema.
 

docs/manual/source/server.rst

@@ -73,11 +73,11 @@ Server Pool
    Active strategies check if the server is listening on the specified port. When the 'active' attribute is set to True the strategy tries to open and close a socket on the port. If your LDAP server has problems with the opening and closing of sockets you can set 'active' to False..
 
 Different Server objects can be grouped in a ServerPool object. A ServerPool object can be specified in the Connection object
-to obtain an high availability (HA) connection. This is useful for long standing connections (for example an LDAP authenticator
+to obtain a high availability (HA) connection. This is useful for long standing connections (for example an LDAP authenticator
 module in an application server) or when you have a multi replica LDAP server infrastructure. The ``active`` and ``exhaust``
 parameter accept either a boolean or a number: if you set ``active=True`` while defining the ServerPool the strategy will check
 for server availability, you can also set this attribute to the maximum number of cycles to try before giving up with an
-LDAPServerPoolExhaustedError exception. With ``exhaust=True`` if a server is not active it will be removed by the pool, if you set it
+LDAPServerPoolExhaustedError exception. With ``exhaust=True`` if a server is not active it will be removed from the pool, if you set it
 to a number this will be the number of seconds an unreachable server is considered offline. When this timout expires the server
 is reinserted in the pool and checked again for availability.
 The pool keeps a single state for all connections that use it. If you want a different state for each connection you must set ``single=False`` while defining the ServerPool.

docs/manual/source/tutorial_abstraction_basic.rst

@@ -118,7 +118,7 @@ A Writable Entry in a Writer cursor acquires the following statuses in its lifet
 * **Missing mandatory attributes**: some mandatory Attribute values are missing, the Entry cannot be committed.
 
 
-There are three global events (delete, move, rename) that locks a Writable Entry until committed (or discarded). In this case the
+There are three global events (delete, move, rename) that lock a Writable Entry until committed (or discarded). In this case the
 status can be one of the following:
 
 * **Ready for deletion**: Entry is flagged for deletion.

docs/manual/source/tutorial_abstraction_writer.rst

@@ -34,7 +34,7 @@ Let's obtain a Writer cursor from the inetOrgPerson Reader we used in the previo
     ATTRS  : ['audio', 'businessCategory', 'carLicense', 'cn', 'departmentNumber', 'description', 'destinationIndicator', 'displayName', 'employeeNumber', 'employeeType', 'facsimileTelephoneNumber', 'givenName', 'homePhone', 'homePostalAddress', 'initials', 'internationalISDNNumber', 'jpegPhoto', 'l', 'labeledURI', 'mail', 'manager', 'mobile', 'o', 'objectClass', 'ou', 'pager', 'photo', 'physicalDeliveryOfficeName', 'postOfficeBox', 'postalAddress', 'postalCode', 'preferredDeliveryMethod', 'preferredLanguage', 'registeredAddress', 'roomNumber', 'secretary', 'seeAlso', 'sn', 'st', 'street', 'telephoneNumber', 'teletexTerminalIdentifier', 'telexNumber', 'title', 'uid', 'userCertificate', 'userPKCS12', 'userPassword', 'userSMIMECertificate', 'x121Address', 'x500UniqueIdentifier']
     ENTRIES: 3 [executed at: 2016-11-09T14:24:49.374675]
 
-Entries in a Writer cursor are standard Python object, so you can modify them with standard Python code::
+Entries in a Writer cursor are standard Python objects, so you can modify them with standard Python code::
 
     >>> w[0]
     DN: cn=b.young,ou=ldap3-tutorial,dc=demo1,dc=freeipa,dc=org - STATUS: Writable - READ TIME: 2016-11-09T14:26:03.866351

docs/manual/source/tutorial_operations.rst

@@ -261,7 +261,7 @@ let you use standard Python objects to perform the CRUD (Create, Read, Update, D
 decent database interface. It uses an **ORM** (*Object Relational Mapper*) to link entries in the DIT with standard Python objects and
 let you operate on this object in a pythonic way.
 
-Let's move back the 'b.smith* entry to its original context and values and let's create a few more entries in that context::
+Let's move back the 'b.smith' entry to its original context and values and let's create a few more entries in that context::
 
     >>> conn.modify_dn('cn=b.smith,ou=moved,ou=ldap3-tutorial,dc=demo1,dc=freeipa,dc=org', 'cn=b.smith', new_superior='ou=ldap3-tutorial,dc=demo1,dc=freeipa,dc=org')
     True

docs/manual/source/tutorial_searches.rst

@@ -230,7 +230,7 @@ ldap3 hides all this machinery in the ``paged_search()`` function of the **exten
     >>> for entry in entries:
     >>>     print(entry)
 
-Entries are returned in a generator, which can be useful when you have very long list of entries or have memory limitations. Also, it sends the requests to the LDAP server only when entries are consumed in the generator. Remember, a generator can be used only one time, so you must elaborate the results in a sequential way. If you don't want the entries returned in a generator, you can pass the
+Entries are returned in a generator, which can be useful when you have very long list of entries or have memory limitations. Also, it sends the requests to the LDAP server only when entries are consumed in the generator. Remember, a generator can be used only one time, so you must iterate over the results in a sequential way. If you don't want the entries returned in a generator, you can pass the
 ``generator=False`` parameter to get all the entries in a list. In this case all the paged searches are performed by the ``paged_search()``
 function and the set of entries found are queued in a list.