Merge remote-tracking branch 'hyperspy/RELEASE_next_patch' into RELEA…

…SE_next_minor

# Conflicts:
#	hyperspy/_signals/signal1d.py

doc/dev_guide/coding_style.rst

@@ -17,7 +17,7 @@ fix the style of your code. You can install and run ``black`` by:
    black /path/to/your/file.py
 
 In Linux and MacOS you can run ``black`` automatically after each commit by
-adding a ``post-commit`` file to ``.git/hook`` with the following content:
+adding a ``post-commit`` file to ``.git/hook/`` with the following content:
 
 .. code-block:: bash
 

doc/dev_guide/git.rst

@@ -7,11 +7,11 @@ Using Git and GitHub
 
 For developing the code, the home of HyperSpy is on 
 `GitHub <https://github.com>`_, and you'll see that
-a lot of this guide boils down to properly use that platform. So, visit the
+a lot of this guide boils down to properly using that platform. So, visit the
 following link and poke around the code, issues, and pull requests: `HyperSpy
 on GitHub <https://github.com/hyperspy/hyperspy>`_.
 
-It is probably also worth visiting the `github.com <https://github.com/>`_
+It is probably also worth visiting `github.com <https://github.com/>`_
 and to go through the `"boot camp" <https://help.github
 .com/categories/bootcamp/>`_ to get a feel for the terminology.
 
@@ -55,7 +55,7 @@ asked to split it up!
 
 For personal use, before integrating things into the main HyperSpy code, you
 can merge some together for your personal use. However, make sure each new
-feature has it's own branch that is contributed through a separate pull
+feature has its own branch that is contributed through a separate pull
 request!
 
 Diagrammatically, you should be aiming for something like this:
@@ -75,13 +75,13 @@ Each number will change depending on the type of changes according to the follow
 
 The git repository of HyperSpy has 3 main branches matching the above pattern
 and depending on the type of pull request, you will need to base your pull request
-one one of the following branch:
+on one of the following branch:
 
 - ``RELEASE_next_major`` to change the API in a not backward-compatible fashion,
 - ``RELEASE_next_minor`` to add new features and improvement,
 - ``RELEASE_next_patch`` for bug fixes.
 
-The ``RELEASE_next_patch`` is merged daily in the ``RELEASE_next_minor`` by the github action
+The ``RELEASE_next_patch`` branch is merged daily into ``RELEASE_next_minor`` by the github action
 `Nightly Merge <https://github.com/hyperspy/hyperspy/actions>`_.
 
 

doc/dev_guide/lazy_computations.rst

@@ -38,7 +38,7 @@ code (assignment, etc.) you wish.
 
 The ``map`` function is flexible and should be able to handle most operations that
 operate on some signal. If you add a ``BaseSignal`` with the same navigation size
-as the signal it will be iterated alongside the mapped signal otherwise a keyword
+as the signal, it will be iterated alongside the mapped signal, otherwise a keyword
 argument is assumed to be constant and is applied to every signal.
 
 If the new method cannot be coerced into a shape suitable for ``map``, separate

doc/dev_guide/speeding_up_code.rst

@@ -17,7 +17,7 @@ Writing Numba code
 
 If you need to improve the speed of a given part of the code your first choice
 should be `Numba <https://numba.pydata.org/>`_. The motivation is that Numba
-code is very similar (when not identical) to Python code, and, therefore, it is
+code is very similar (when not identical) to Python code, and therefore, it is
 a lot easier to maintain than Cython code (see below).
 
 Numba is also a required dependency for HyperSpy, unlike Cython which

doc/dev_guide/testing.rst

@@ -14,9 +14,9 @@ for testing. The tests reside in the ``hyperspy.tests`` module.
 
 Tests are short functions, found in ``hyperspy/tests``, that call your functions
 under some known conditions and check the outputs against known values. They
-should depend on as few other features as possible so that when they break
+should depend on as few other features as possible so that when they break,
 we know exactly what caused it. Ideally, the tests should be written at the
-same time than the code itself, as they are very convenient to run to check
+same time as the code itself, as they are very convenient to run to check
 outputs when coding. Writing tests can seem laborious but you'll probably
 soon find that they are very important, as they force you to sanity-check
 all the work that you do.
@@ -34,7 +34,7 @@ all the work that you do.
   parameters of the same function without having to write to much repetitive
   code, which is often error-prone. See `pytest documentation
   <http://doc.pytest.org/en/latest/parametrize.html>`__ for more details.
-* It is good to check that the tests does not use too much memory after
+* It is good to check that the tests do not use too much memory after
   creating new tests. If you need to explicitly delete your objects and free
   memory, you can do the following to release the memory associated with the
   ``s`` object:
@@ -172,7 +172,7 @@ In case of Azure Pipelines, CI helper scripts are pulled from the
 
 The testing matrix is as follows:
 
-- **Github Actions**: test a range of Pythons version on Linux, MacOS and Windows;
+- **Github Actions**: test a range of Python versions on Linux, MacOS and Windows;
   all dependencies are installed from `PyPI <https://pypi.org>`_.
   See ``.github/workflows/tests.yml`` in the HyperSpy repository for further details.
 - **Azure Pipeline**: test a range of Python versions on Linux, MacOS and Windows;
@@ -258,7 +258,7 @@ variable and accordingly set the backend.
 
 Exporting pytest results as HTML
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-With ``pytest-html`` it is possible to export the results of running pytest
+With ``pytest-html``, it is possible to export the results of running pytest
 for easier viewing. It can be installed by conda:
 
 .. code:: bash

doc/dev_guide/useful_information.rst

@@ -43,16 +43,16 @@ github: `conda-forge/hyperspy-feedstock <https://github.com/conda-forge/hyperspy
 Monitoring version distribution
 -------------------------------
 
-Download metrics are available from pypi and Anaconda cloud but the reliability
+Download metrics are available from pypi and Anaconda cloud, but the reliability
 of these numbers is poor for the following reason:
 
 * hyperspy is distributed by other means: the
   `hyperspy-bundle <https://github.com/hyperspy/hyperspy-bundle>`_, or by
   various linux distribution (Arch-Linux, openSUSE)
 * these packages may be used by continuous integration of other python libraries
 
-However, distribution of download version can be useful to identify
-issues, such as version pinning or library incompatibilities. Various service
+However, distribution of downloaded versions can be useful to identify
+issues, such as version pinning or library incompatibilities. Various services
 processing the `pypi data <https://packaging.python.org/guides/analyzing-pypi-package-downloads/>`_
 are available online:
 

doc/dev_guide/writing_docs.rst

@@ -10,7 +10,7 @@ Documentation comes in two parts: docstrings and user-guide documentation.
 Docstrings
 ^^^^^^^^^^
 
-Written at the start of a function and give essential information
+Written at the start of a function, they give essential information
 about how it should be used, such as which arguments can be passed to it and
 what the syntax should be. The docstrings need to follow the `numpy
 specification <https://github.com/numpy/numpy/blob/master/doc/HOWTO_DOCUMENT

doc/dev_guide/writing_extensions.rst

@@ -319,12 +319,12 @@ Equivalently, to add a new component 2D:
 Creating and registering new widgets and toolkeys
 -------------------------------------------------
 
-To generate GUIs of specific methods and functions, HyperSpy use widgets and
+To generate GUIs of specific methods and functions, HyperSpy uses widgets and
 toolkeys:
 
 * *widgets* (typically ipywidgets or traitsui objects) generate GUIs,
-* *toolkeys* are functions using which it is possible to associate widgets to
-  a signal method or to a module function.
+* *toolkeys* are functions which associate widgets to a signal method 
+  or to a module function.
 
 An extension can declare new toolkeys and widgets. For example, the
 `hyperspy-gui-traitsui <https://github.com/hyperspy/hyperspy_gui_traitsui>`_ and
@@ -379,7 +379,7 @@ Integration test suite
 ----------------------
 
 The `integration test suite <https://github.com/hyperspy/hyperspy-extensions-list/actions>`__
-runs the test suite of hyperspy and hyperspy extension on a daily basis against both the
+runs the test suite of HyperSpy and of all registered HyperSpy extensions on a daily basis against both the
 release and development versions. The build matrix is as follows:
 
 .. list-table:: Build matrix of the integration test suite
@@ -418,8 +418,8 @@ The development packages of the dependencies are provided by the
 `scipy-wheels-nightly <https://pypi.anaconda.org/scipy-wheels-nightly/simple>`_
 repository, which provides ``scipy``, ``numpy``, ``scikit-learn`` and ``scikit-image``
 at the time of writing.
-The pre-release packages are obtained from `pypi <https://pypi.org>`_ and these
-will be used for any dependency which provides a pre-release package on pypi.
+The pre-release packages are obtained from `PyPI <https://pypi.org>`_ and these
+will be used for any dependency which provides a pre-release package on PyPI.
 
 A similar `Integration test  <https://github.com/hyperspy/hyperspy/actions/workflows/tests_extension.yml>`__
 workflow can run from pull requests (PR) to the

hyperspy/_signals/signal1d.py

@@ -25,7 +25,7 @@
 import dask.array as da
 from scipy import interpolate
 from scipy.signal import savgol_filter, medfilt
-from scipy.ndimage.filters import gaussian_filter1d
+from scipy.ndimage import gaussian_filter1d
 
 from hyperspy.signal import BaseSignal
 from hyperspy._signals.common_signal1d import CommonSignal1D