%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 `_ -- 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 `_ 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 `_ -- 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 `_ 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 `_ -- 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 `_ 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 21 2023 Python_Bot - 1.1.0-1 - Package Spec generated