update doc

doc/conf.py

@@ -50,7 +50,7 @@ copyright = u'2013, tiramisu team'
 # The short X.Y version.
 version = '1'
 # The full version, including alpha/beta/rc tags.
-release = '1.0RC1'
+release = '1.0'
 
 # The language for content autogenerated by Sphinx. Refer to documentation
 # for a list of supported languages.

doc/config.txt

@@ -27,8 +27,6 @@ object is returned, and if no `Option` has been declared in the
 ::
 
     >>> gcdummy = BoolOption('dummy', 'dummy', default=False)
-    >>> gcdummy._name
-    'dummy'
     >>> gcdummy.getdefault()
     False
     >>> descr = OptionDescription('tiramisu', '', [gcdummy])

doc/consistency.txt

@@ -52,13 +52,13 @@ to carry out a dependencies calculation. For example, an option can ben
 hidden if another option has been set with some expected value. This is
 just an example, the possibilities are hudge.
 
-A requirement is a list of dictionnaries that have fairly this form::
+A requirement is a list of dictionaries that have fairly this form::
 
     [{'option': a, 'expected': False, 'action': 'disabled', 'inverse': True,
     'transitive':True, 'same_action': True}]
 
-Actually a transformation is made to this dictionnary during the validation of 
-this requires at the :class:`~option.Option()`'s init. The dictionnairy becomes 
+Actually a transformation is made to this dictionary during the validation of 
+this requires at the :class:`~option.Option()`'s init. The dictionairy becomes 
 a tuple, wich is passed to the :meth:`~setting.Settings.apply_requires()` 
 method. Take a look at the code to fully understand the exact meaning of the 
 requirements:

doc/getting-started.txt

@@ -6,7 +6,7 @@ What is options handling ?
 =================================
 
 Due to more and more available options required to set up an operating system,
-to set up compiler options, vs... it became quite annoying to hand the
+to set up compiler options, and so on. it became quite annoying to hand the
 necessary options to where they are actually used and even more annoying to add
 new options. To circumvent these problems the configuration management was
 introduced...

doc/option.txt

@@ -27,27 +27,8 @@ The `OptionDescription` class
 
 If you need to access an option object, you can do it with the OptionDescription 
 object. Not only the value of the option by attribute access, but the option 
-object itself that lives behind the scene. It can always be accessed internally
-with the `impl_descr` attribute of the `config` objects. For example, with a
-option named `name` in a `gc` group the `name` object can be accessed like
-this::
-
-    conf._impl_descr.name
-
-of sub configs with ::
-
-    conf.gc._impl_descr.name
-
-This is a binding. The option objects are in the `_children` config's attribute.
-
-Why accessing an option object ? It is possible for example freeze the
-configuration option
-
-::
-
-    conf.gc._impl_descr.dummy.freeze()
-
-or to hide it, or disable it, or... anything.
+object itself that lives behind the scene. It can always be accessed internally. 
+The option objects are in the `_children` `OptionDescription`'s attribute.
 
 The `Option` base class
 -------------------------

doc/status.txt

@@ -1,6 +1,6 @@
 .. default-role:: literal
 
-Local statuses and global setting
+Local statuses and global settings
 =====================================
 
 Available configuration statuses