path: root/python-parsing.spec

%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.aliyun.com/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
* Thu Jun 08 2023 Python_Bot <Python_Bot@openeuler.org> - 2.0.0-1
- Package Spec generated