%global _empty_manifest_terminate_build 0
Name:		python-nine
Version:	1.1.0
Release:	1
Summary:	Python 2 / 3 compatibility, like six, but favouring Python 3
License:	Public domain
URL:		https://github.com/nandoflorestan/nine
Source0:	https://mirrors.nju.edu.cn/pypi/web/packages/ba/1f/0c7e2a1e28497df5d207199b5e70aa998e501659eeb84076a6cf78809540/nine-1.1.0.tar.gz
BuildArch:	noarch


%description
When the best Python 2/Python 3 compatibility modules -- especially the famous
`*six* library invented by Benjamin Peterson <https://pypi.python.org/pypi/six>`_
-- were created, they were written from the point of view of a Python 2
programmer starting to grok Python 3.  If you use *six*,
your code is compatible, but stuck in Python 2 idioms.
**nine** turns **six** upside down. You write your code using Python 3 idioms
-- as much as possible --, and it is the Python 2 "version" that is patched.
Needless to say, this approach is more future-proof.
When thou writeth Python, thou shalt write Python 3 and,
just for a little longer, ensure that the thing worketh on Python 2.7.
*nine* facilitates this point of view. You can write code
that is as 3ish as possible while still supporting 2.6.
For instance, you don't type ``unicode`` anymore, you type ``str``, and *nine*
makes ``str`` point to ``unicode`` on Python 2 (if you use our boilerplate).
Also, ``map``, ``zip`` and ``filter`` have Python 3 behaviour, on Python 2,
meaning they return iterators, not lists.
Honestly you should not spend one thought on Python 2.6 anymore, it is
`no longer supported <https://mail.python.org/pipermail/python-dev/2013-September/128287.html>`_
since its final release (2.6.9) in October 2013. Nobody uses 3.0 or 3.1 either.
Python 2.7 has finally met its demise on the first day of 2020.
*nine* is extremely stable and unlikely to change since it solves an old
problem that never changes.  Nobody should be surprised if *nine* isn't
updated for months or even years.
The author(s) of *nine* donate this module to the public domain.
To understand most of the intricacies involved in achieving 2&3 compatibility
in a single codebase, I recommend reading this:
http://lucumr.pocoo.org/2013/5/21/porting-to-python-3-redux/

%package -n python3-nine
Summary:	Python 2 / 3 compatibility, like six, but favouring Python 3
Provides:	python-nine
BuildRequires:	python3-devel
BuildRequires:	python3-setuptools
BuildRequires:	python3-pip
%description -n python3-nine
When the best Python 2/Python 3 compatibility modules -- especially the famous
`*six* library invented by Benjamin Peterson <https://pypi.python.org/pypi/six>`_
-- were created, they were written from the point of view of a Python 2
programmer starting to grok Python 3.  If you use *six*,
your code is compatible, but stuck in Python 2 idioms.
**nine** turns **six** upside down. You write your code using Python 3 idioms
-- as much as possible --, and it is the Python 2 "version" that is patched.
Needless to say, this approach is more future-proof.
When thou writeth Python, thou shalt write Python 3 and,
just for a little longer, ensure that the thing worketh on Python 2.7.
*nine* facilitates this point of view. You can write code
that is as 3ish as possible while still supporting 2.6.
For instance, you don't type ``unicode`` anymore, you type ``str``, and *nine*
makes ``str`` point to ``unicode`` on Python 2 (if you use our boilerplate).
Also, ``map``, ``zip`` and ``filter`` have Python 3 behaviour, on Python 2,
meaning they return iterators, not lists.
Honestly you should not spend one thought on Python 2.6 anymore, it is
`no longer supported <https://mail.python.org/pipermail/python-dev/2013-September/128287.html>`_
since its final release (2.6.9) in October 2013. Nobody uses 3.0 or 3.1 either.
Python 2.7 has finally met its demise on the first day of 2020.
*nine* is extremely stable and unlikely to change since it solves an old
problem that never changes.  Nobody should be surprised if *nine* isn't
updated for months or even years.
The author(s) of *nine* donate this module to the public domain.
To understand most of the intricacies involved in achieving 2&3 compatibility
in a single codebase, I recommend reading this:
http://lucumr.pocoo.org/2013/5/21/porting-to-python-3-redux/

%package help
Summary:	Development documents and examples for nine
Provides:	python3-nine-doc
%description help
When the best Python 2/Python 3 compatibility modules -- especially the famous
`*six* library invented by Benjamin Peterson <https://pypi.python.org/pypi/six>`_
-- were created, they were written from the point of view of a Python 2
programmer starting to grok Python 3.  If you use *six*,
your code is compatible, but stuck in Python 2 idioms.
**nine** turns **six** upside down. You write your code using Python 3 idioms
-- as much as possible --, and it is the Python 2 "version" that is patched.
Needless to say, this approach is more future-proof.
When thou writeth Python, thou shalt write Python 3 and,
just for a little longer, ensure that the thing worketh on Python 2.7.
*nine* facilitates this point of view. You can write code
that is as 3ish as possible while still supporting 2.6.
For instance, you don't type ``unicode`` anymore, you type ``str``, and *nine*
makes ``str`` point to ``unicode`` on Python 2 (if you use our boilerplate).
Also, ``map``, ``zip`` and ``filter`` have Python 3 behaviour, on Python 2,
meaning they return iterators, not lists.
Honestly you should not spend one thought on Python 2.6 anymore, it is
`no longer supported <https://mail.python.org/pipermail/python-dev/2013-September/128287.html>`_
since its final release (2.6.9) in October 2013. Nobody uses 3.0 or 3.1 either.
Python 2.7 has finally met its demise on the first day of 2020.
*nine* is extremely stable and unlikely to change since it solves an old
problem that never changes.  Nobody should be surprised if *nine* isn't
updated for months or even years.
The author(s) of *nine* donate this module to the public domain.
To understand most of the intricacies involved in achieving 2&3 compatibility
in a single codebase, I recommend reading this:
http://lucumr.pocoo.org/2013/5/21/porting-to-python-3-redux/

%prep
%autosetup -n nine-1.1.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-nine -f filelist.lst
%dir %{python3_sitelib}/*

%files help -f doclist.lst
%{_docdir}/*

%changelog
* Fri Apr 07 2023 Python_Bot <Python_Bot@openeuler.org> - 1.1.0-1
- Package Spec generated