Merge pull request #201 from michaelosthege/fix-94

Refactor config code

Author: brandonwillard

.github/workflows/test.yml

@@ -132,7 +132,7 @@ jobs:
           pip install -q -r requirements.txt
           mamba list && pip freeze
           python -c 'import theano; print(theano.config.__str__(print_doc=False))'
-          python -c 'import theano; assert(theano.config.blas.ldflags != "")'
+          python -c 'import theano; assert(theano.config.blas__ldflags != "")'
         env:
           PYTHON_VERSION: ${{ matrix.python-version }}
 

conftest.py

@@ -7,7 +7,7 @@ def pytest_sessionstart(session):
     os.environ["THEANO_FLAGS"] = ",".join(
         [
             os.environ.setdefault("THEANO_FLAGS", ""),
-            "warn.ignore_bug_before=all,on_opt_error=raise,on_shape_error=raise",
+            "warn__ignore_bug_before=all,on_opt_error=raise,on_shape_error=raise",
         ]
     )
 

doc/acknowledgement.txt

@@ -15,10 +15,6 @@ Acknowledgements
 * All Theano users that have given us feedback.
 * The GPU implementation of tensordot is based on code from Tijmen
   Tieleman's `gnumpy <http://www.cs.toronto.edu/~tijmen/gnumpy.html>`_
-* The original version of the function ``cpuCount()`` in the file
-  `theano/misc/cpucount.py` come from the project `pyprocessing
-  <http://pyprocessing.berlios.de/>`_. It is available under the same license
-  as Theano.
 * Our random number generator implementation on CPU and GPU uses the MRG31k3p algorithm that is described in:
 
     P. L'Ecuyer and R. Touzin, `Fast Combined Multiple Recursive Generators with Multipliers of the form a = +/- 2^d +/- 2^e <http://www.informs-sim.org/wsc00papers/090.PDF>`_, Proceedings of the 2000 Winter Simulation Conference, Dec. 2000, 683--689.

doc/extending/extending_theano.txt

@@ -580,7 +580,7 @@ returns the right answer. If you detect an error, you must raise an
 We call ``utt.assert_allclose(expected_value, value)`` to compare
 NumPy ndarray.This raise an error message with more information. Also,
 the default tolerance can be changed with the Theano flags
-``config.tensor.cmp_sloppy`` that take values in 0, 1 and 2. The
+``config.tensor__cmp_sloppy`` that take values in 0, 1 and 2. The
 defaul value do the most strict comparison, 1 and 2 make less strict
 comparison.
 

doc/extending/extending_theano_c.txt

@@ -1034,7 +1034,7 @@ Using GDB to debug Op's C code
 When debugging C code, it can be useful to use GDB for code compiled
 by Theano.
 
-For this, you must enable this Theano: `cmodule.remove_gxx_opt=True`.
+For this, you must enable this Theano: `cmodule__remove_gxx_opt=True`.
 For the GPU, you must add in this second flag `nvcc.flags=-g` (it slow
 down computation on the GPU, but it is enabled by default on the CPU).
 

doc/extending/pipeline.txt

@@ -108,7 +108,7 @@ case if ``borrow`` was True, the thunk would be allowed to reuse (or
 
     The compile cache is based upon the C++ code of the graph to be compiled.
     So, if you change compilation configuration variables, such as
-    :attr:`config.blas.ldflags`, you will need to manually remove your compile cache,
+    :attr:`config.blas__ldflags`, you will need to manually remove your compile cache,
     using ``Theano/bin/theano-cache clear``
 
     Theano also implements a lock mechanism that prevents

doc/extending/unittest.txt

@@ -258,9 +258,9 @@ The behaviour of ``seed_rng`` is as follows:
 
 * If an explicit seed is given, it will be used for seeding numpy's rng.
 
-* If not, it will use ``config.unittests.rseed`` (its default value is ``666``).
+* If not, it will use ``config.unittests__rseed`` (its default value is ``666``).
 
-* If ``config.unittests.rseed`` is set to ``"random"``, it will seed the rng with
+* If ``config.unittests__rseed`` is set to ``"random"``, it will seed the rng with
   None, which is equivalent to seeding with a random seed.
 
 
@@ -272,7 +272,7 @@ a higher confidence that the variables are correct), while still
 making sure unittests are deterministic.
 
 Users who prefer their unittests to be random (when run on their local
-machine) can simply set ``config.unittests.rseed`` to ``'random'`` (see
+machine) can simply set ``config.unittests__rseed`` to ``'random'`` (see
 :mod:`config`).
 
 Similarly, to provide a seed to ``numpy.random.RandomState``, simply use:

doc/faq.txt

@@ -97,7 +97,7 @@ correct shape. The shape could change if the shapes of the inputs change.
 
 .. note::
 
-   With :attr:`preallocate <config.gpuarray.preallocate>`, this isn't
+   With :attr:`preallocate <config.gpuarray__preallocate>`, this isn't
    very useful with GPU anymore.
 
 .. _unsafe_optimization:
@@ -176,7 +176,7 @@ but requires that all nodes in the graph have a C implementation:
 New GPU backend using libgpuarray
 ---------------------------------
 
-The new theano GPU backend (:ref:`gpuarray`) uses ``config.gpuarray.preallocate`` for GPU memory allocation. 
+The new theano GPU backend (:ref:`gpuarray`) uses ``config.gpuarray__preallocate`` for GPU memory allocation. 
 
 Related Projects
 ----------------

doc/internal/how_to_release.txt

@@ -42,7 +42,7 @@ Update the fallback version in ``theano/version.py``.
 Update the version in ``doc/install_generic.inc``.
 
 Update the code and the documentation for the theano flags
-``warn.ignore_bug_before`` to accept the new version. You must modify the
+``warn__ignore_bug_before`` to accept the new version. You must modify the
 file ``theano/configdefaults.py`` and ``doc/library/config.txt``.
 
 Tag the release

doc/library/compile/debugmode.txt

@@ -89,36 +89,36 @@ Reference
 
     If there are internal errors, this mode will raise an `DebugModeError` exception.
 
-    .. attribute:: stability_patience = config.DebugMode.patience
+    .. attribute:: stability_patience = config.DebugMode__patience
 
         When checking for the stability of optimization, recompile the graph this many times.
         Default 10.
 
-    .. attribute:: check_c_code = config.DebugMode.check_c
+    .. attribute:: check_c_code = config.DebugMode__check_c
 
         Should we evaluate (and check) the `c_code` implementations?
 
         ``True`` -> yes, ``False`` -> no.
 
         Default yes.
 
-    .. attribute:: check_py_code = config.DebugMode.check_py
+    .. attribute:: check_py_code = config.DebugMode__check_py
 
     Should we evaluate (and check) the `perform` implementations?
 
         ``True`` -> yes, ``False`` -> no.
 
         Default yes.
 
-    .. attribute:: check_isfinite = config.DebugMode.check_finite
+    .. attribute:: check_isfinite = config.DebugMode__check_finite
 
         Should we check for (and complain about) ``NaN``/``Inf`` ndarray elements?
 
         ``True`` -> yes, ``False`` -> no.
 
         Default yes.
 
-    .. attribute:: require_matching_strides = config.DebugMode.check_strides
+    .. attribute:: require_matching_strides = config.DebugMode__check_strides
 
         Check for (and complain about) Ops whose python and C
         outputs are ndarrays with different strides. (This can catch bugs, but