simpleeval 1.0.2__tar.gz → 1.0.4__tar.gz

simpleeval-1.0.4/.v2/lib/python3.13/site-packages/docutils/parsers/rst/include/README.rst

@@ -0,0 +1,17 @@
+============================================
+ ``docutils/parsers/rst/include`` Directory
+============================================
+
+This directory contains standard data files intended for inclusion in
+reStructuredText documents.  To access these files, use the "include"
+directive with the special syntax for standard "include" data files,
+angle brackets around the file name::
+
+    .. include:: <isonum.txt>
+
+See the documentation for the `"include" directive`__ and
+`reStructuredText Standard Definition Files`__ for
+details.
+
+__ https://docutils.sourceforge.io/docs/ref/rst/directives.html#include
+__ https://docutils.sourceforge.io/docs/ref/rst/definitions.html

simpleeval-1.0.4/.v2/lib/python3.13/site-packages/docutils/writers/s5_html/themes/README.rst

@@ -0,0 +1,6 @@
+Except where otherwise noted, all files in this
+directory have been released into the Public Domain.
+
+These files are based on files from S5 1.1, released into the Public
+Domain by Eric Meyer.  For further details, please see
+http://www.meyerweb.com/eric/tools/s5/credits.html.

simpleeval-1.0.4/.v2/lib/python3.13/site-packages/pip/_vendor/README.rst

@@ -0,0 +1,180 @@
+================
+Vendoring Policy
+================
+
+* Vendored libraries **MUST** not be modified except as required to
+  successfully vendor them.
+* Vendored libraries **MUST** be released copies of libraries available on
+  PyPI.
+* Vendored libraries **MUST** be available under a license that allows
+  them to be integrated into ``pip``, which is released under the MIT license.
+* Vendored libraries **MUST** be accompanied with LICENSE files.
+* The versions of libraries vendored in pip **MUST** be reflected in
+  ``pip/_vendor/vendor.txt``.
+* Vendored libraries **MUST** function without any build steps such as ``2to3``
+  or compilation of C code, practically this limits to single source 2.x/3.x and
+  pure Python.
+* Any modifications made to libraries **MUST** be noted in
+  ``pip/_vendor/README.rst`` and their corresponding patches **MUST** be
+  included ``tools/vendoring/patches``.
+* Vendored libraries should have corresponding ``vendored()`` entries in
+  ``pip/_vendor/__init__.py``.
+
+Rationale
+=========
+
+Historically pip has not had any dependencies except for ``setuptools`` itself,
+choosing instead to implement any functionality it needed to prevent needing
+a dependency. However, starting with pip 1.5, we began to replace code that was
+implemented inside of pip with reusable libraries from PyPI. This brought the
+typical benefits of reusing libraries instead of reinventing the wheel like
+higher quality and more battle tested code, centralization of bug fixes
+(particularly security sensitive ones), and better/more features for less work.
+
+However, there are several issues with having dependencies in the traditional
+way (via ``install_requires``) for pip. These issues are:
+
+**Fragility**
+   When pip depends on another library to function then if for whatever reason
+   that library either isn't installed or an incompatible version is installed
+   then pip ceases to function. This is of course true for all Python
+   applications, however for every application *except* for pip the way you fix
+   it is by re-running pip. Obviously, when pip can't run, you can't use pip to
+   fix pip, so you're left having to manually resolve dependencies and
+   installing them by hand.
+
+**Making other libraries uninstallable**
+   One of pip's current dependencies is the ``requests`` library, for which pip
+   requires a fairly recent version to run.  If pip depended on ``requests`` in
+   the traditional manner, then we'd either have to maintain compatibility with
+   every ``requests`` version that has ever existed (and ever will), OR allow
+   pip to render certain versions of ``requests`` uninstallable. (The second
+   issue, although technically true for any Python application, is magnified by
+   pip's ubiquity; pip is installed by default in Python, in ``pyvenv``, and in
+   ``virtualenv``.)
+
+**Security**
+   This might seem puzzling at first glance, since vendoring has a tendency to
+   complicate updating dependencies for security updates, and that holds true
+   for pip. However, given the *other* reasons for avoiding dependencies, the
+   alternative is for pip to reinvent the wheel itself.  This is what pip did
+   historically. It forced pip to re-implement its own HTTPS verification
+   routines as a workaround for the Python standard library's lack of SSL
+   validation, which resulted in similar bugs in the validation routine in
+   ``requests`` and ``urllib3``, except that they had to be discovered and
+   fixed independently. Even though we're vendoring, reusing libraries keeps
+   pip more secure by relying on the great work of our dependencies, *and*
+   allowing for faster, easier security fixes by simply pulling in newer
+   versions of dependencies.
+
+**Bootstrapping**
+   Currently most popular methods of installing pip rely on pip's
+   self-contained nature to install pip itself. These tools work by bundling a
+   copy of pip, adding it to ``sys.path``, and then executing that copy of pip.
+   This is done instead of implementing a "mini installer" (to reduce
+   duplication); pip already knows how to install a Python package, and is far
+   more battle-tested than any "mini installer" could ever possibly be.
+
+Many downstream redistributors have policies against this kind of bundling, and
+instead opt to patch the software they distribute to debundle it and make it
+rely on the global versions of the software that they already have packaged
+(which may have its own patches applied to it). We (the pip team) would prefer
+it if pip was *not* debundled in this manner due to the above reasons and
+instead we would prefer it if pip would be left intact as it is now.
+
+In the longer term, if someone has a *portable* solution to the above problems,
+other than the bundling method we currently use, that doesn't add additional
+problems that are unreasonable then we would be happy to consider, and possibly
+switch to said method. This solution must function correctly across all of the
+situation that we expect pip to be used and not mandate some external mechanism
+such as OS packages.
+
+
+Modifications
+=============
+
+* ``setuptools`` is completely stripped to only keep ``pkg_resources``.
+* ``pkg_resources`` has been modified to import its dependencies from
+  ``pip._vendor``, and to use the vendored copy of ``platformdirs``
+  rather than ``appdirs``.
+* ``packaging`` has been modified to import its dependencies from
+  ``pip._vendor``.
+* ``CacheControl`` has been modified to import its dependencies from
+  ``pip._vendor``.
+* ``requests`` has been modified to import its other dependencies from
+  ``pip._vendor`` and to *not* load ``simplejson`` (all platforms) and
+  ``pyopenssl`` (Windows).
+* ``platformdirs`` has been modified to import its submodules from ``pip._vendor.platformdirs``.
+
+Automatic Vendoring
+===================
+
+Vendoring is automated via the `vendoring <https://pypi.org/project/vendoring/>`_ tool from the content of
+``pip/_vendor/vendor.txt`` and the different patches in
+``tools/vendoring/patches``.
+Launch it via ``vendoring sync . -v`` (requires ``vendoring>=0.2.2``).
+Tool configuration is done via ``pyproject.toml``.
+
+To update the vendored library versions, we have a session defined in ``nox``.
+The command to upgrade everything is::
+
+    nox -s vendoring -- --upgrade-all --skip urllib3 --skip setuptools
+
+At the time of writing (April 2025) we do not upgrade ``urllib3`` because the
+next version is a major upgrade and will be handled as an independent PR. We also
+do not upgrade ``setuptools``, because we only rely on ``pkg_resources``, and
+tracking every ``setuptools`` change is unnecessary for our needs.
+
+
+Managing Local Patches
+======================
+
+The ``vendoring`` tool automatically applies our local patches, but updating,
+the patches sometimes no longer apply cleanly. In that case, the update will
+fail. To resolve this, take the following steps:
+
+1. Revert any incomplete changes in the revendoring branch, to ensure you have
+   a clean starting point.
+2. Run the revendoring of the library with a problem again: ``nox -s vendoring
+   -- --upgrade <library_name>``.
+3. This will fail again, but you will have the original source in your working
+   directory. Review the existing patch against the source, and modify the patch
+   to reflect the new version of the source. If you ``git add`` the changes the
+   vendoring made, you can modify the source to reflect the patch file and then
+   generate a new patch with ``git diff``.
+4. Now, revert everything *except* the patch file changes. Leave the modified
+   patch file unstaged but saved in the working tree.
+5. Re-run the vendoring. This time, it should pick up the changed patch file
+   and apply it cleanly. The patch file changes will be committed along with the
+   revendoring, so the new commit should be ready to test and publish as a PR.
+
+
+Debundling
+==========
+
+As mentioned in the rationale, we, the pip team, would prefer it if pip was not
+debundled (other than optionally ``pip/_vendor/requests/cacert.pem``) and that
+pip was left intact. However, if you insist on doing so, we have a
+semi-supported method (that we don't test in our CI) and requires a bit of
+extra work on your end in order to solve the problems described above.
+
+1. Delete everything in ``pip/_vendor/`` **except** for
+   ``pip/_vendor/__init__.py`` and ``pip/_vendor/vendor.txt``.
+2. Generate wheels for each of pip's dependencies (and any of their
+   dependencies) using your patched copies of these libraries. These must be
+   placed somewhere on the filesystem that pip can access (``pip/_vendor`` is
+   the default assumption).
+3. Modify ``pip/_vendor/__init__.py`` so that the ``DEBUNDLED`` variable is
+   ``True``.
+4. Upon installation, the ``INSTALLER`` file in pip's own ``dist-info``
+   directory should be set to something other than ``pip``, so that pip
+   can detect that it wasn't installed using itself.
+5. *(optional)* If you've placed the wheels in a location other than
+   ``pip/_vendor/``, then modify ``pip/_vendor/__init__.py`` so that the
+   ``WHEEL_DIR`` variable points to the location you've placed them.
+6. *(optional)* Update the ``pip_self_version_check`` logic to use the
+   appropriate logic for determining the latest available version of pip and
+   prompt the user with the correct upgrade message.
+
+Note that partial debundling is **NOT** supported. You need to prepare wheels
+for all dependencies for successful debundling.

{simpleeval-1.0.2 → simpleeval-1.0.4/.v314/lib/python3.14/site-packages}/simpleeval.py

@@ -129,7 +129,7 @@ DISALLOW_METHODS = [
 ]
 
 # Disallow functions:
-# This, strictly speaking, is not necessary.  These /should/ never be accessable anyway,
+# This, strictly speaking, is not necessary.  These /should/ never be accessible anyway,
 # if DISALLOW_PREFIXES and DISALLOW_METHODS are all right.  This is here to try and help
 # people not be stupid.  Allowing these functions opens up all sorts of holes - if any of
 # their functionality is required, then please wrap them up in a safe container.  And think
@@ -254,9 +254,9 @@ def safe_mult(a, b):  # pylint: disable=invalid-name
     """limit the number of times an iterable can be repeated..."""
 
     if hasattr(a, "__len__") and b * len(a) > MAX_STRING_LENGTH:
-        raise IterableTooLong("Sorry, I will not evalute something that long.")
+        raise IterableTooLong("Sorry, I will not evaluate something that long.")
     if hasattr(b, "__len__") and a * len(b) > MAX_STRING_LENGTH:
-        raise IterableTooLong("Sorry, I will not evalute something that long.")
+        raise IterableTooLong("Sorry, I will not evaluate something that long.")
 
     return a * b
 
@@ -386,13 +386,13 @@ class SimpleEval(object):  # pylint: disable=too-few-public-methods
             warnings.simplefilter("ignore")
             # py3.12 deprecated ast.Num, ast.Str, ast.NameConstant
             # https://docs.python.org/3.12/whatsnew/3.12.html#deprecated
-            if Num := getattr(ast, "Num"):
+            if Num := getattr(ast, "Num", None):
                 self.nodes[Num] = self._eval_num
 
-            if Str := getattr(ast, "Str"):
+            if Str := getattr(ast, "Str", None):
                 self.nodes[Str] = self._eval_str
 
-            if NameConstant := getattr(ast, "NameConstant"):
+            if NameConstant := getattr(ast, "NameConstant", None):
                 self.nodes[NameConstant] = self._eval_constant
 
         # Defaults:
@@ -424,7 +424,7 @@ class SimpleEval(object):  # pylint: disable=too-few-public-methods
         return parsed.body[0]
 
     def eval(self, expr, previously_parsed=None):
-        """evaluate an expresssion, using the operators, functions and
+        """evaluate an expression, using the operators, functions and
         names previously set up."""
 
         # set a copy of the expression aside, so we can give nice errors...
@@ -763,6 +763,6 @@ class EvalWithCompoundTypes(SimpleEval):
 
 
 def simple_eval(expr, operators=None, functions=None, names=None):
-    """Simply evaluate an expresssion"""
+    """Simply evaluate an expression"""
     s = SimpleEval(operators=operators, functions=functions, names=names)
     return s.eval(expr)

simpleeval-1.0.4/LICENCE

@@ -0,0 +1,21 @@
+simpleeval - Copyright (c) 2013-2026 Daniel Fairhead
+
+(MIT Licence)
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in
+all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+THE SOFTWARE.

{simpleeval-1.0.2 → simpleeval-1.0.4}/PKG-INFO

@@ -1,11 +1,11 @@
 Metadata-Version: 2.3
 Name: simpleeval
-Version: 1.0.2
+Version: 1.0.4
 Summary: A simple, safe single expression evaluator library.
 Project-URL: Source code, https://github.com/danthedeckie/simpleeval
 Author-email: Daniel Fairhead <danthedeckie@gmail.com>
 Maintainer-email: Daniel Fairhead <danthedeckie@gmail.com>
-License-File: LICENCE
+License: MIT
 Keywords: ast,eval,expression,parse,simple
 Classifier: Development Status :: 5 - Production/Stable
 Classifier: Intended Audience :: Developers
@@ -239,7 +239,7 @@ which, of course, can be nested:
 Functions
 ---------
 
-You can define functions which you'd like the expresssions to have access to:
+You can define functions which you'd like the expressions to have access to:
 
 .. code-block:: pycon
 
@@ -356,7 +356,7 @@ cases):
     # and so on...
 
 One useful feature of using the ``SimpleEval`` object is that you can parse an expression
-once, and then evaluate it mulitple times using different ``names``:
+once, and then evaluate it multiple times using different ``names``:
 
 .. code-block:: python
 
@@ -449,10 +449,8 @@ version that disallows method invocation on objects:
 
 and then use ``EvalNoMethods`` instead of the ``SimpleEval`` class.
 
-Other...
---------
-
-The library supports Python 3.9 and higher.
+Limiting Attribute Access
+-------------------------
 
 Object attributes that start with ``_`` or ``func_`` are disallowed by default.
 If you really need that (BE CAREFUL!), then modify the module global
@@ -462,6 +460,51 @@ A few builtin functions are listed in ``simpleeval.DISALLOW_FUNCTIONS``.  ``type
 If you need to give access to this kind of functionality to your expressions, then be very
 careful.  You'd be better wrapping the functions in your own safe wrappers.
 
+There is an additional layer of protection you can add in by passing in ``allowed_attrs``, which
+makes all attribute access based opt-in rather than opt-out - which is a lot safer design:
+
+.. code-block:: pycon
+
+    >>> simpleeval("' hello   '.strip()", allowed_attrs={})
+
+will throw FeatureNotAvailable - as we've now disabled all attribute access.  You can enable some
+reasonably sensible defaults with BASIC_ALLOWED_ATTRS:
+
+.. code-block:: pycon
+
+    >>> from simpleeval import simpleeval, BASIC_ALLOWED_ATTRS
+    >>> simpleeval("'  hello   '.strip()", allowed_attrs=BASIC_ALLOWED_ATTRS)
+
+is fine - ``strip()`` should be safe on strings.
+
+It is recommended to add ``allowed_attrs=BASIC_ALLOWED_ATTRS``  whenever possible, and it will
+be the default for 2.x.
+
+You can add your own classes & limit access to attrs:
+
+.. code-block:: pycon
+
+    >>> from simpleeval import simpleeval, BASIC_ALLOWED_ATTRS
+    >>> class Foo:
+    >>>     bar = 42
+    >>>     hidden = "secret"
+    >>>
+    >>> our_attributes = BASIC_ALLOWED_ATTRS.copy()
+    >>> our_attributes[Foo] = {'bar'}
+    >>> simpleeval("foo.bar", names={"foo": Foo()}, allowed_attrs=our_attributes)
+    42
+
+    >>> simpleeval("foo.hidden", names={"foo": Foo()}, allowed_attrs=our_attributes)
+    simpleeval.FeatureNotAvailable: Sorry, 'hidden' access not allowed on 'Foo'
+
+will now allow access to `foo.bar` but not allow anything else.
+
+
+Other...
+--------
+
+The library supports Python 3.9 and higher.
+
 The initial idea came from J.F. Sebastian on Stack Overflow
 ( http://stackoverflow.com/a/9558001/1973500 ) with modifications and many improvements,
 see the head of the main file for contributors list.
@@ -498,3 +541,8 @@ BEWARE
 I've done the best I can with this library - but there's no warranty, no guarantee, nada.  A lot of
 very clever people think the whole idea of trying to sandbox CPython is impossible.  Read the code
 yourself, and use it at your own risk.
+
+The sandboxing / safety features of simpleeval *only apply to the expression* that is passed in to
+be evaluated, and rely on the python interpreter working as normal.  If you have monkey-patched
+the interpreter, or pass in objects/classes/functions with unsafe code in them, simpleeval cannot
+protect you.

{simpleeval-1.0.2 → simpleeval-1.0.4}/README.rst

@@ -222,7 +222,7 @@ which, of course, can be nested:
 Functions
 ---------
 
-You can define functions which you'd like the expresssions to have access to:
+You can define functions which you'd like the expressions to have access to:
 
 .. code-block:: pycon
 
@@ -339,7 +339,7 @@ cases):
     # and so on...
 
 One useful feature of using the ``SimpleEval`` object is that you can parse an expression
-once, and then evaluate it mulitple times using different ``names``:
+once, and then evaluate it multiple times using different ``names``:
 
 .. code-block:: python
 
@@ -432,10 +432,8 @@ version that disallows method invocation on objects:
 
 and then use ``EvalNoMethods`` instead of the ``SimpleEval`` class.
 
-Other...
---------
-
-The library supports Python 3.9 and higher.
+Limiting Attribute Access
+-------------------------
 
 Object attributes that start with ``_`` or ``func_`` are disallowed by default.
 If you really need that (BE CAREFUL!), then modify the module global
@@ -445,6 +443,51 @@ A few builtin functions are listed in ``simpleeval.DISALLOW_FUNCTIONS``.  ``type
 If you need to give access to this kind of functionality to your expressions, then be very
 careful.  You'd be better wrapping the functions in your own safe wrappers.
 
+There is an additional layer of protection you can add in by passing in ``allowed_attrs``, which
+makes all attribute access based opt-in rather than opt-out - which is a lot safer design:
+
+.. code-block:: pycon
+
+    >>> simpleeval("' hello   '.strip()", allowed_attrs={})
+
+will throw FeatureNotAvailable - as we've now disabled all attribute access.  You can enable some
+reasonably sensible defaults with BASIC_ALLOWED_ATTRS:
+
+.. code-block:: pycon
+
+    >>> from simpleeval import simpleeval, BASIC_ALLOWED_ATTRS
+    >>> simpleeval("'  hello   '.strip()", allowed_attrs=BASIC_ALLOWED_ATTRS)
+
+is fine - ``strip()`` should be safe on strings.
+
+It is recommended to add ``allowed_attrs=BASIC_ALLOWED_ATTRS``  whenever possible, and it will
+be the default for 2.x.
+
+You can add your own classes & limit access to attrs:
+
+.. code-block:: pycon
+
+    >>> from simpleeval import simpleeval, BASIC_ALLOWED_ATTRS
+    >>> class Foo:
+    >>>     bar = 42
+    >>>     hidden = "secret"
+    >>>
+    >>> our_attributes = BASIC_ALLOWED_ATTRS.copy()
+    >>> our_attributes[Foo] = {'bar'}
+    >>> simpleeval("foo.bar", names={"foo": Foo()}, allowed_attrs=our_attributes)
+    42
+
+    >>> simpleeval("foo.hidden", names={"foo": Foo()}, allowed_attrs=our_attributes)
+    simpleeval.FeatureNotAvailable: Sorry, 'hidden' access not allowed on 'Foo'
+
+will now allow access to `foo.bar` but not allow anything else.
+
+
+Other...
+--------
+
+The library supports Python 3.9 and higher.
+
 The initial idea came from J.F. Sebastian on Stack Overflow
 ( http://stackoverflow.com/a/9558001/1973500 ) with modifications and many improvements,
 see the head of the main file for contributors list.
@@ -481,3 +524,8 @@ BEWARE
 I've done the best I can with this library - but there's no warranty, no guarantee, nada.  A lot of
 very clever people think the whole idea of trying to sandbox CPython is impossible.  Read the code
 yourself, and use it at your own risk.
+
+The sandboxing / safety features of simpleeval *only apply to the expression* that is passed in to
+be evaluated, and rely on the python interpreter working as normal.  If you have monkey-patched
+the interpreter, or pass in objects/classes/functions with unsafe code in them, simpleeval cannot
+protect you.

{simpleeval-1.0.2 → simpleeval-1.0.4}/pyproject.toml

@@ -1,10 +1,10 @@
 [project]
 name = "simpleeval"
-version = "1.0.2"
+version = "1.0.4"
 requires-python = ">=3.9"
 readme = "README.rst"
 description = "A simple, safe single expression evaluator library."
-licence = "MIT"
+license = "MIT"
 authors = [
     { name = "Daniel Fairhead", email = "danthedeckie@gmail.com" }
 ]
@@ -41,10 +41,15 @@ include = [
     "README.rst",
     "LICENCE",
 ]
+core-metadata-version = "2.3"
 
 [tool.hatch.version]
 path = "simpleeval.py"
 
+[tool.hatch.build.targets.wheel]
+packages = ["simpleeval.py"]
+core-metadata-version = "2.3"
+
 [tool.hatch.envs.hatch-test]
 default-args = ["test_simpleeval.py"]