chore: Fix spelling mistakes and add typos to pre-commit

.gitignore

@@ -26,7 +26,7 @@ doc/reference/param/generated
 .coverage
 coverage.xml
 
-# Versionning
+# Versioning
 param/_version.py
 
 # asv benchmark

.pre-commit-config.yaml

@@ -21,3 +21,7 @@ repos:
     rev: 2e6f506fab3cdfbe16bc18fd0d24e828db773b74  # frozen: v0.2.1
     hooks:
       - id: clean-notebook
+  - repo: https://github.com/crate-ci/typos
+    rev: 7b04f660f4ee4f048d18fd341887cf28dfbedfe2  # frozen: v1.46.3
+    hooks:
+      - id: typos

doc/releases.md

@@ -278,7 +278,7 @@ This minor release focuses on improving reactive expressions and support for asy
 
 Enhancements:
 
-- Improvements for synchronous and asychronous generators ([#908](https://github.com/holoviz/param/pull/908))
+- Improvements for synchronous and asynchronous generators ([#908](https://github.com/holoviz/param/pull/908))
 - Additions to the .rx namespace including `and_`, `bool`, `map`, `not_`, `or_` and `updating` ([#906](https://github.com/holoviz/param/pull/906))
 - Add support for adding asynchronous watcher to `rx` ([#917](https://github.com/holoviz/param/pull/917))
 - Make it possible to resolve reactive expressions recursively with `.rx.resolve` ([#918](https://github.com/holoviz/param/pull/918))
@@ -363,7 +363,7 @@ We would like to thank @minimav for their first contribution, and @droumis, @Hox
 - Parameter slot values that are set to mutable containers (e.g. `Selector(objects=a_list)`) will now be shallow-copied on instantiation, so that the container is no longer confusingly shared between the class and its subclasses and instances ([#826](https://github.com/holoviz/param/pull/826))
 - To further clean up the Parameterized namespace (first started in version 1.7.0), the remaining private attributes haven been collected under two private namespaces `_param__private` and `_param__parameters` ([#766](https://github.com/holoviz/param/pull/766), [#790](https://github.com/holoviz/param/pull/790))
 - You can now use `.param.update` as a context manager for applying temporary updates ([#779](https://github.com/holoviz/param/pull/779))
-- The `name` Parameter has always had special behavior dating to its use in labeling objects in a GUI context, but this behavior is now able to be overriden at the class and instance level ([#740](https://github.com/holoviz/param/pull/740))
+- The `name` Parameter has always had special behavior dating to its use in labeling objects in a GUI context, but this behavior is now able to be overridden at the class and instance level ([#740](https://github.com/holoviz/param/pull/740))
 - Improved Parameter signatures for static and dynamic code analysis ([#742](https://github.com/holoviz/param/pull/742))
 - Removed inferred Parameterized docstring signature and add basic `__signature__` support ([#802](https://github.com/holoviz/param/pull/802))
 - For speed, only generate the Parameter docstring in an IPython context ([#774](https://github.com/holoviz/param/pull/774))
@@ -643,7 +643,7 @@ Compatibility (see [#543](https://github.com/holoviz/param/pull/543) for the com
     * `.param.log()`: Subsumes .debug/verbose/message; all are logging calls. ([#556](https://github.com/holoviz/param/pull/556))
     * `.param.update()`: Dictionary-style updates to parameter values, as a drop-in replacement for `set_param` except for its optional legacy positional-arg syntax ([#558](https://github.com/holoviz/param/pull/558))
     * `.values()`: Dictionary of name:value pairs for parameter values, replacing `get_param_values` but now a dict since python3 preserves order ([#558](https://github.com/holoviz/param/pull/558))
-    * `.param.log()`: General-purpose interface to the logging module functionailty; replaces .debug, .verbose, .message ([#556](https://github.com/holoviz/param/pull/556))
+    * `.param.log()`: General-purpose interface to the logging module functionality; replaces .debug, .verbose, .message ([#556](https://github.com/holoviz/param/pull/556))
 
 ## Version 1.11.1
 

doc/roadmap.md

@@ -18,7 +18,7 @@ Other items that are not yet scheduled but would be great to have:
 
 - Follow PEP8 more strictly: PEP8 definitely wasn't written with Parameters in mind, and it typically results in badly formatted files when applied to Parameterized code. But PEP8 could be applied to Param's own code, e.g. using Black.
 
-- Triaging open issues: The Param developer team consists of volunteers typically using Param on their projects but not explicity tasked with or funded to work on Param itself. It would thus be great if the more experienced Param users could help address some of the issues that have been raised but not yet solved.
+- Triaging open issues: The Param developer team consists of volunteers typically using Param on their projects but not explicitly tasked with or funded to work on Param itself. It would thus be great if the more experienced Param users could help address some of the issues that have been raised but not yet solved.
 
 - Improve test coverage
 

doc/user_guide/Dependencies_and_Watchers.ipynb

@@ -178,7 +178,7 @@
   {
    "cell_type": "code",
    "execution_count": null,
-   "id": "77caf9c1",
+   "id": "77cax9c1",
    "metadata": {},
    "outputs": [],
    "source": [

doc/user_guide/How_Param_Works.ipynb

@@ -86,7 +86,7 @@
     "\n",
     "The `ParameterMetaclass` is fairly simple, mainly overriding docstrings so that `help(someparam)` gives the declared documentation for the Parameter instance, rather than the less-useful docstring for the underlying class that it would otherwise display. This behavior is convenient, but not essential to the operation of Param. \n",
     "\n",
-    "`ParameterizedMetaclass`, on the other hand, defines a lot of the behavior behind Param's features.  In particular, the metaclass implements the behavior for getting and setting parameter values at the class level, similar to how a descriptor controls such behavior at the instance level. Without the metaclass, setting the value of a class attribute to a scalar like `5` would wipe out the `Parameter` object rather than updating the default value. The metaclass thus performs the same role at the class level as descriptors do at the instance level. Descriptors allow setting the value of an instance attribute without overriding the `Parameter` object on that instance, and the metaclass allows setting the value of a class attribute without overridding the `Parameter` object on the class. All told, the ParameterizedMetaclass handles: \n",
+    "`ParameterizedMetaclass`, on the other hand, defines a lot of the behavior behind Param's features.  In particular, the metaclass implements the behavior for getting and setting parameter values at the class level, similar to how a descriptor controls such behavior at the instance level. Without the metaclass, setting the value of a class attribute to a scalar like `5` would wipe out the `Parameter` object rather than updating the default value. The metaclass thus performs the same role at the class level as descriptors do at the instance level. Descriptors allow setting the value of an instance attribute without overriding the `Parameter` object on that instance, and the metaclass allows setting the value of a class attribute without overriding the `Parameter` object on the class. All told, the ParameterizedMetaclass handles: \n",
     "\n",
     "- allowing Parameter default values to be set at the class level (as just described),\n",
     "- supporting inheriting Parameter objects from superclasses, \n",

doc/user_guide/Logging_and_Warnings.ipynb

@@ -101,7 +101,7 @@
   {
    "cell_type": "code",
    "execution_count": null,
-   "id": "85dbe122",
+   "id": "85dbf122",
    "metadata": {},
    "outputs": [],
    "source": [

doc/user_guide/ParameterizedFunctions.ipynb

@@ -7,7 +7,7 @@
    "source": [
     "# ParameterizedFunctions\n",
     "\n",
-    "`Parameterized` classes and objects are full-featured substitues for Python objects, providing rich support and control for how attributes behave. What if you need similar features, but for functions rather than objects?\n",
+    "`Parameterized` classes and objects are full-featured substitutes for Python objects, providing rich support and control for how attributes behave. What if you need similar features, but for functions rather than objects?\n",
     "\n",
     "Python functions don't directly support the various [language features like descriptors that Param builds on](How_Param_Works.ipynb), but you can instead make a Python class or object that _behaves_ like a function, while still supporting Parameters. To make that easier, Param provides an abstract class `ParameterizedFunction` that you can use as a superclass for any function-like object you want to write. A ParameterizedFunction automatically invokes its `__call__` method whenever it is instantiated. So, all you need to do is implement the `__call__` method with the implementation of your function. For example:"
    ]

doc/user_guide/Parameters.ipynb

@@ -380,7 +380,7 @@
    "id": "fc265dfa",
    "metadata": {},
    "source": [
-    "As you can see, parameters not specified in B are still fully usable in it, if they were declared in a superclass. **Metadata associated with that parameter is also inherited**, if not explicitly overidden in `B`.\n"
+    "As you can see, parameters not specified in B are still fully usable in it, if they were declared in a superclass. **Metadata associated with that parameter is also inherited**, if not explicitly overridden in `B`.\n"
    ]
   },
   {
@@ -867,7 +867,7 @@
     "def debug_id(cls, self, parameter):\n",
     "    global debug_id_counter\n",
     "    if self:\n",
-    "        # When the class value is overriden.\n",
+    "        # When the class value is overridden.\n",
     "        if getattr(cls, parameter.name) != cls.__name__:\n",
     "            return getattr(cls, parameter.name)\n",
     "        else:\n",

doc/user_guide/Reactive_Expressions.ipynb

@@ -1093,7 +1093,7 @@
   },
   {
    "cell_type": "markdown",
-   "id": "1272daed",
+   "id": "1272dead",
    "metadata": {},
    "source": [
     "As you can see, you can use bound functions to get reactivity if you prefer to write specific functions, or you can use reactive expressions to capture computations without writing function definitions, or you can combine the two as needed. Feel free to use the approach that best meets your needs!\n",

doc/user_guide/Serialization_and_Persistence.ipynb

@@ -145,7 +145,7 @@
     "\n",
     "2. **Skipping Parameters that should not be pickled [DEPRECATED in version 2.3.0]**: In some cases, you may not _want_ the value of a given Parameter to be pickled and restored even while other state is being serialized. For instance, a Parameter whose value is set to a particular file path might cause errors if that path is restored when the pickle is loaded on a different system or once the file no longer exists. To cover such rare but potentially important cases, the Parameter can be defined with `pickle_default_value=False` (normally `True`), so that the instantaneous value is usable but won't be saved and restored with pickle.\n",
     "\n",
-    "3. **Customizing settting and getting state**: You may find that your Parameter or Parameterized objects have other state that you need to handle specially, whether that's to save and restore data that isn't otherwise picklable, or to ignore state that should _not_ be pickled. For instance, if your object's dictionary contains some object that doesn't support pickling, then you can add code to omit that or to serialize it in some special way that allows it to be restored, e.g. by extracting a state dictionary fom it and then restoring it from the dictionary later. See the [pickle docs](https://docs.python.org/3/library/pickle.html#pickle-state) for the `__getstate__` and `__setstate__` methods that you can implement on your Parameter or Parameterized objects to override this behavior. Be sure to call `super(YourClass,self).__setstate__(state)` or the getstate equivalent so that you also store parameters and dictionary values as usual, if desired.\n",
+    "3. **Customizing setting and getting state**: You may find that your Parameter or Parameterized objects have other state that you need to handle specially, whether that's to save and restore data that isn't otherwise picklable, or to ignore state that should _not_ be pickled. For instance, if your object's dictionary contains some object that doesn't support pickling, then you can add code to omit that or to serialize it in some special way that allows it to be restored, e.g. by extracting a state dictionary from it and then restoring it from the dictionary later. See the [pickle docs](https://docs.python.org/3/library/pickle.html#pickle-state) for the `__getstate__` and `__setstate__` methods that you can implement on your Parameter or Parameterized objects to override this behavior. Be sure to call `super(YourClass,self).__setstate__(state)` or the getstate equivalent so that you also store parameters and dictionary values as usual, if desired.\n",
     "\n",
     "4. **Loading old pickle files**: If you use pickles extensively, you may find yourself wanting to support pickle files generated by an older version of your own code, even though your code has since changed (with renamed modules, classes, or parameters, or options that are no longer supported, etc.). By default, unpickling will raise an exception if it finds information in your pickle file that does not match the current Python source code, but it is possible to add custom handling to translate old definitions to match current code, discard no-longer-used options, map from a previous approach into the current approach, etc. You can use `__getstate__` and `__setstate__` on your top-level object or on specific other classes to do just about anything like this, though it can get complicated to reason about. Best practice is to store the module version number or other suitable identifier as an attribute or Parameter on the top-level object to declare what version of the code was used to create the file, and you can then read this identifier later to determine whether you need to apply such conversions on reloading."
    ]

doc/user_guide/Typing.ipynb

@@ -189,7 +189,7 @@
     "\n",
     "As discussed above, the current approach to typing in Param has limits. While the proposal is still being iterated on, the prototype [PR #1066](https://github.com/holoviz/param/pull/1066) introduces a new base class that will allow inferring parameter types from the type annotations.\n",
     "\n",
-    "This approach will align Param more closely with modern tooling such as dataclasses and pydantic, reduce boilerplate, and finally provide a fully typed signature and will be included in an upcoming Param 3.0 releaase."
+    "This approach will align Param more closely with modern tooling such as dataclasses and pydantic, reduce boilerplate, and finally provide a fully typed signature and will be included in an upcoming Param 3.0 release."
    ]
   },
   {

numbergen/__init__.py

@@ -244,21 +244,21 @@ def _rational(self, val):
         """Convert the given value to a rational, if necessary."""
         I32 = 4294967296 # Maximum 32 bit unsigned int (i.e. 'I') value
         if isinstance(val, int):
-            numer, denom = val, 1
+            numerator, denominator = val, 1
         elif isinstance(val, fractions.Fraction):
-            numer, denom = val.numerator, val.denominator
+            numerator, denominator = val.numerator, val.denominator
         elif hasattr(val, 'numerator') and hasattr(val, 'denominator'):
             # gmpy2 mpq objects have these attributes
-            numer, denom = val.numerator, val.denominator
-        elif hasattr(val, 'numer'):
+            numerator, denominator = val.numerator, val.denominator
+        elif hasattr(val, 'numer'): # typos: ignore
             # I think this branch supports gmpy (i.e. not gmpy2)
-            (numer, denom) = (int(val.numer()), int(val.denom()))
+            (numerator, denominator) = (int(val.numer()), int(val.denom()))  # typos: ignore
         else:
             param.main.param.log(param.WARNING, "Casting type '%s' to Fraction.fraction"
                                % type(val).__name__)
             frac = fractions.Fraction(str(val))
-            numer, denom = frac.numerator, frac.denominator
-        return numer % I32, denom % I32
+            numerator, denominator = frac.numerator, frac.denominator
+        return numerator % I32, denominator % I32
 
     def __getstate__(self):
         """Avoid Hashlib.md5 TypeError in deepcopy (hashlib issue)."""
@@ -279,7 +279,7 @@ def __call__(self, *vals):
         Given integer or rational inputs, generate a cross-platform,
         architecture-independent 32-bit integer hash.
         """
-        # Convert inputs to (numer, denom) pairs with integers
+        # Convert inputs to (numerator, denominator) pairs with integers
         # becoming (int, 1) pairs to match gmpy2.mpqs for int values.
         pairs = [self._rational(val) for val in vals]
         # Unpack pairs and fill struct with ints to update md5 hash

param/ipython.py

@@ -58,7 +58,7 @@ def __init__(self, metaclass=False):
 
     def get_param_info(self, obj, include_super=True):
         """
-        Get the parameter dictionary, the list of modifed parameters
+        Get the parameter dictionary, the list of modified parameters
         and the dictionary of parameter values. If include_super is
         True, parameters are also collected from the super classes.
         """