1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
|
%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 21 2023 Python_Bot <Python_Bot@openeuler.org> - 1.1.0-1
- Package Spec generated
|
