automatic import of python-parsing

3 files changed, 315 insertions, 0 deletions

diff --git a/.gitignore b/.gitignore
index e69de29..88bd6a1 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/parsing-2.0.0.tar.gz
diff --git a/python-parsing.spec b/python-parsing.spec
new file mode 100644
index 0000000..599c661
--- /dev/null
+++ b/python-parsing.spec
@@ -0,0 +1,313 @@
+%global _empty_manifest_terminate_build 0
+Name:		python-parsing
+Version:	2.0.0
+Release:	1
+Summary:	A pure-Python module that implements an LR(1) parser generator, as well as CFSM and GLR parser drivers.
+License:	MIT
+URL:		http://www.canonware.com/Parsing/
+Source0:	https://mirrors.nju.edu.cn/pypi/web/packages/4f/4e/ed56edd1503cfd37882d67c09d00aa3c9ef7a249aabaf5840d85bda0d9ae/parsing-2.0.0.tar.gz
+
+Requires:	python3-flake8
+Requires:	python3-mypy
+
+%description
+The ``parsing`` module implements an LR(1) parser generator, as well as the
+runtime support for using a generated parser, via the Lr and Glr parser
+drivers.  There is no special parser generator input file format, but the
+parser generator still needs to know what classes/methods correspond to
+various aspects of the parser.  This information is specified via
+docstrings, which the parser generator introspects in order to generate a
+parser.  Only one parser specification can be embedded in each module, but
+it is possible to share modules between parser specifications so that, for
+example, the same token definitions can be used by multiple parser
+specifications.
+The parsing tables are LR(1), but they are generated using a fast algorithm
+that avoids creating duplicate states that result when using the generic
+LR(1) algorithm.  Creation time and table size are on par with the LALR(1)
+algorithm.  However, LALR(1) can create reduce/reduce conflicts that don't
+exist in a true LR(1) parser.  For more information on the algorithm, see::
+    A Practical General Method for Constructing LR(k) Parsers
+    David Pager
+    Acta Informatica 7, 249-268 (1977)
+Parsing table generation requires non-trivial amounts of time for large
+grammars, however it is still quite fast.  Internal pickling support makes
+it possible to cache the most recent version of the parsing table on disk,
+and use the table if the current parser specification is still compatible
+with the one that was used to generate the pickled parsing table.  Since
+the compatibility checking is quite fast, even for large grammars, this
+removes the need to use the standard code generation method that is used
+by most parser generators.
+Parser specifications are encapsulated by the ``Spec`` class.  Parser
+instances use ``Spec`` instances, but are themselves based on separate
+classes.  This allows multiple parser instances to exist simultaneously,
+without requiring multiple copies of the parsing tables.  There are two
+separate parser driver classes:
+Lr:
+    Standard Characteristic Finite State Machine (CFSM) driver, based on
+    unambiguous LR(1) parsing tables.  This driver is faster than the Glr
+    driver, but it cannot deal with all parsing tables that the Glr
+    driver can.
+Glr:
+    Generalized LR driver, capable of tracking multiple parse trees
+    simultaneously, if the %split precedence is used to mark ambiguous
+    actions.  This driver is closely based on Elkhound's design, which
+    is described in a technical report::
+        Elkhound: A Fast, Practical GLR Parser Generator
+        Scott McPeak
+        Report No. UCB/CSD-2-1214 (December 2002)
+        http://www.cs.berkeley.edu/~smcpeak/elkhound/
+Parser generator directives are embedded in docstrings, and must begin with
+a '%' character, followed immediately by one of several keywords:
+    Precedence:
+        ``%fail`` ``%nonassoc`` ``%left`` ``%right`` ``%split``
+    Token:
+        ``%token``
+    Non-terminal:
+        ``%start`` ``%nonterm``
+    Production:
+        ``%reduce``
+All of these directives are associated with classes except for %reduce.
+%reduce is associated with methods within non-terminal classes.  The Parsing
+module provides base classes from which precedences, tokens, and
+non-terminals must be derived.  This is not as restrictive as it sounds,
+since there is nothing preventing, for example, a master Token class that
+subclasses Parsing.Token, which all of the actual token types then subclass.
+Also, nothing prevents using multiple inheritance.
+Folowing are the base classes to be subclassed by parser specifications:
+  * Precedence
+  * Token
+  * Nonterm
+The Parsing module implements the following exception classes:
+  * SpecError - when there is a problem with the grammar specification
+  * ParsingException - any problem that occurs during parsing
+  * UnexpectedToken - when the input sequence contains a token that is
+    not allowed by the grammar (including end-of-input)
+In order to maintain compatibility with legacy code, the Parsing module
+defines the following aliases. New code should use the exceptions above
+that do not shadow Python's builtin exceptions.
+   * Exception - superclass for all exceptions that can be raised
+   * SyntaxError - alias for UnexpectedToken
+Additionally, trying to set private attributes may raise:
+  * AttributeError
+Author: Jason Evans jasone@canonware.com
+Github repo: http://github.com/MagicStack/parsing
+
+%package -n python3-parsing
+Summary:	A pure-Python module that implements an LR(1) parser generator, as well as CFSM and GLR parser drivers.
+Provides:	python-parsing
+BuildRequires:	python3-devel
+BuildRequires:	python3-setuptools
+BuildRequires:	python3-pip
+BuildRequires:	python3-cffi
+BuildRequires:	gcc
+BuildRequires:	gdb
+%description -n python3-parsing
+The ``parsing`` module implements an LR(1) parser generator, as well as the
+runtime support for using a generated parser, via the Lr and Glr parser
+drivers.  There is no special parser generator input file format, but the
+parser generator still needs to know what classes/methods correspond to
+various aspects of the parser.  This information is specified via
+docstrings, which the parser generator introspects in order to generate a
+parser.  Only one parser specification can be embedded in each module, but
+it is possible to share modules between parser specifications so that, for
+example, the same token definitions can be used by multiple parser
+specifications.
+The parsing tables are LR(1), but they are generated using a fast algorithm
+that avoids creating duplicate states that result when using the generic
+LR(1) algorithm.  Creation time and table size are on par with the LALR(1)
+algorithm.  However, LALR(1) can create reduce/reduce conflicts that don't
+exist in a true LR(1) parser.  For more information on the algorithm, see::
+    A Practical General Method for Constructing LR(k) Parsers
+    David Pager
+    Acta Informatica 7, 249-268 (1977)
+Parsing table generation requires non-trivial amounts of time for large
+grammars, however it is still quite fast.  Internal pickling support makes
+it possible to cache the most recent version of the parsing table on disk,
+and use the table if the current parser specification is still compatible
+with the one that was used to generate the pickled parsing table.  Since
+the compatibility checking is quite fast, even for large grammars, this
+removes the need to use the standard code generation method that is used
+by most parser generators.
+Parser specifications are encapsulated by the ``Spec`` class.  Parser
+instances use ``Spec`` instances, but are themselves based on separate
+classes.  This allows multiple parser instances to exist simultaneously,
+without requiring multiple copies of the parsing tables.  There are two
+separate parser driver classes:
+Lr:
+    Standard Characteristic Finite State Machine (CFSM) driver, based on
+    unambiguous LR(1) parsing tables.  This driver is faster than the Glr
+    driver, but it cannot deal with all parsing tables that the Glr
+    driver can.
+Glr:
+    Generalized LR driver, capable of tracking multiple parse trees
+    simultaneously, if the %split precedence is used to mark ambiguous
+    actions.  This driver is closely based on Elkhound's design, which
+    is described in a technical report::
+        Elkhound: A Fast, Practical GLR Parser Generator
+        Scott McPeak
+        Report No. UCB/CSD-2-1214 (December 2002)
+        http://www.cs.berkeley.edu/~smcpeak/elkhound/
+Parser generator directives are embedded in docstrings, and must begin with
+a '%' character, followed immediately by one of several keywords:
+    Precedence:
+        ``%fail`` ``%nonassoc`` ``%left`` ``%right`` ``%split``
+    Token:
+        ``%token``
+    Non-terminal:
+        ``%start`` ``%nonterm``
+    Production:
+        ``%reduce``
+All of these directives are associated with classes except for %reduce.
+%reduce is associated with methods within non-terminal classes.  The Parsing
+module provides base classes from which precedences, tokens, and
+non-terminals must be derived.  This is not as restrictive as it sounds,
+since there is nothing preventing, for example, a master Token class that
+subclasses Parsing.Token, which all of the actual token types then subclass.
+Also, nothing prevents using multiple inheritance.
+Folowing are the base classes to be subclassed by parser specifications:
+  * Precedence
+  * Token
+  * Nonterm
+The Parsing module implements the following exception classes:
+  * SpecError - when there is a problem with the grammar specification
+  * ParsingException - any problem that occurs during parsing
+  * UnexpectedToken - when the input sequence contains a token that is
+    not allowed by the grammar (including end-of-input)
+In order to maintain compatibility with legacy code, the Parsing module
+defines the following aliases. New code should use the exceptions above
+that do not shadow Python's builtin exceptions.
+   * Exception - superclass for all exceptions that can be raised
+   * SyntaxError - alias for UnexpectedToken
+Additionally, trying to set private attributes may raise:
+  * AttributeError
+Author: Jason Evans jasone@canonware.com
+Github repo: http://github.com/MagicStack/parsing
+
+%package help
+Summary:	Development documents and examples for parsing
+Provides:	python3-parsing-doc
+%description help
+The ``parsing`` module implements an LR(1) parser generator, as well as the
+runtime support for using a generated parser, via the Lr and Glr parser
+drivers.  There is no special parser generator input file format, but the
+parser generator still needs to know what classes/methods correspond to
+various aspects of the parser.  This information is specified via
+docstrings, which the parser generator introspects in order to generate a
+parser.  Only one parser specification can be embedded in each module, but
+it is possible to share modules between parser specifications so that, for
+example, the same token definitions can be used by multiple parser
+specifications.
+The parsing tables are LR(1), but they are generated using a fast algorithm
+that avoids creating duplicate states that result when using the generic
+LR(1) algorithm.  Creation time and table size are on par with the LALR(1)
+algorithm.  However, LALR(1) can create reduce/reduce conflicts that don't
+exist in a true LR(1) parser.  For more information on the algorithm, see::
+    A Practical General Method for Constructing LR(k) Parsers
+    David Pager
+    Acta Informatica 7, 249-268 (1977)
+Parsing table generation requires non-trivial amounts of time for large
+grammars, however it is still quite fast.  Internal pickling support makes
+it possible to cache the most recent version of the parsing table on disk,
+and use the table if the current parser specification is still compatible
+with the one that was used to generate the pickled parsing table.  Since
+the compatibility checking is quite fast, even for large grammars, this
+removes the need to use the standard code generation method that is used
+by most parser generators.
+Parser specifications are encapsulated by the ``Spec`` class.  Parser
+instances use ``Spec`` instances, but are themselves based on separate
+classes.  This allows multiple parser instances to exist simultaneously,
+without requiring multiple copies of the parsing tables.  There are two
+separate parser driver classes:
+Lr:
+    Standard Characteristic Finite State Machine (CFSM) driver, based on
+    unambiguous LR(1) parsing tables.  This driver is faster than the Glr
+    driver, but it cannot deal with all parsing tables that the Glr
+    driver can.
+Glr:
+    Generalized LR driver, capable of tracking multiple parse trees
+    simultaneously, if the %split precedence is used to mark ambiguous
+    actions.  This driver is closely based on Elkhound's design, which
+    is described in a technical report::
+        Elkhound: A Fast, Practical GLR Parser Generator
+        Scott McPeak
+        Report No. UCB/CSD-2-1214 (December 2002)
+        http://www.cs.berkeley.edu/~smcpeak/elkhound/
+Parser generator directives are embedded in docstrings, and must begin with
+a '%' character, followed immediately by one of several keywords:
+    Precedence:
+        ``%fail`` ``%nonassoc`` ``%left`` ``%right`` ``%split``
+    Token:
+        ``%token``
+    Non-terminal:
+        ``%start`` ``%nonterm``
+    Production:
+        ``%reduce``
+All of these directives are associated with classes except for %reduce.
+%reduce is associated with methods within non-terminal classes.  The Parsing
+module provides base classes from which precedences, tokens, and
+non-terminals must be derived.  This is not as restrictive as it sounds,
+since there is nothing preventing, for example, a master Token class that
+subclasses Parsing.Token, which all of the actual token types then subclass.
+Also, nothing prevents using multiple inheritance.
+Folowing are the base classes to be subclassed by parser specifications:
+  * Precedence
+  * Token
+  * Nonterm
+The Parsing module implements the following exception classes:
+  * SpecError - when there is a problem with the grammar specification
+  * ParsingException - any problem that occurs during parsing
+  * UnexpectedToken - when the input sequence contains a token that is
+    not allowed by the grammar (including end-of-input)
+In order to maintain compatibility with legacy code, the Parsing module
+defines the following aliases. New code should use the exceptions above
+that do not shadow Python's builtin exceptions.
+   * Exception - superclass for all exceptions that can be raised
+   * SyntaxError - alias for UnexpectedToken
+Additionally, trying to set private attributes may raise:
+  * AttributeError
+Author: Jason Evans jasone@canonware.com
+Github repo: http://github.com/MagicStack/parsing
+
+%prep
+%autosetup -n parsing-2.0.0
+
+%build
+%py3_build
+
+%install
+%py3_install
+install -d -m755 %{buildroot}/%{_pkgdocdir}
+if [ -d doc ]; then cp -arf doc %{buildroot}/%{_pkgdocdir}; fi
+if [ -d docs ]; then cp -arf docs %{buildroot}/%{_pkgdocdir}; fi
+if [ -d example ]; then cp -arf example %{buildroot}/%{_pkgdocdir}; fi
+if [ -d examples ]; then cp -arf examples %{buildroot}/%{_pkgdocdir}; fi
+pushd %{buildroot}
+if [ -d usr/lib ]; then
+	find usr/lib -type f -printf "/%h/%f\n" >> filelist.lst
+fi
+if [ -d usr/lib64 ]; then
+	find usr/lib64 -type f -printf "/%h/%f\n" >> filelist.lst
+fi
+if [ -d usr/bin ]; then
+	find usr/bin -type f -printf "/%h/%f\n" >> filelist.lst
+fi
+if [ -d usr/sbin ]; then
+	find usr/sbin -type f -printf "/%h/%f\n" >> filelist.lst
+fi
+touch doclist.lst
+if [ -d usr/share/man ]; then
+	find usr/share/man -type f -printf "/%h/%f.gz\n" >> doclist.lst
+fi
+popd
+mv %{buildroot}/filelist.lst .
+mv %{buildroot}/doclist.lst .
+
+%files -n python3-parsing -f filelist.lst
+%dir %{python3_sitearch}/*
+
+%files help -f doclist.lst
+%{_docdir}/*
+
+%changelog
+* Mon May 15 2023 Python_Bot <Python_Bot@openeuler.org> - 2.0.0-1
+- Package Spec generated
diff --git a/sources b/sources
new file mode 100644
index 0000000..c5b6c87
--- /dev/null
+++ b/sources
@@ -0,0 +1 @@
+f58644fa4a6e388ea263976856d7638f  parsing-2.0.0.tar.gz