diff options
-rw-r--r-- | .gitignore | 1 | ||||
-rw-r--r-- | python-combomethod.spec | 162 | ||||
-rw-r--r-- | sources | 1 |
3 files changed, 164 insertions, 0 deletions
@@ -0,0 +1 @@ +/combomethod-1.0.12.zip diff --git a/python-combomethod.spec b/python-combomethod.spec new file mode 100644 index 0000000..52b2b2c --- /dev/null +++ b/python-combomethod.spec @@ -0,0 +1,162 @@ +%global _empty_manifest_terminate_build 0 +Name: python-combomethod +Version: 1.0.12 +Release: 1 +Summary: Decorator indicating a method is both a class and an instance method +License: Apache License 2.0 +URL: https://bitbucket.org/jeunice/combomethod +Source0: https://mirrors.nju.edu.cn/pypi/web/packages/ae/02/5266113d7f2057ff11a8a75018380091a1189e693c3bb9a5f62e4e8e0abc/combomethod-1.0.12.zip +BuildArch: noarch + + +%description +In some cases, you can fake ``@combomethod`` with ``@classmethod``. In +the code above, for example, there is no real reference to the class +or instance, and ``either`` could have been designated a ``@classmethod``, +since they can be called with either classes or instances. But, there's a +problem: Class methods *always* pass the class to the method, even if they're +called with an instance. With this approach, you can never access the +instance variables. Ouch! +Alternatively, ``either`` could have been designated a ``@staticmethod``, +had its ``receiver`` parameter been removed. But while it would then be +callable from either an instance or a class, in neither case would it pass +the object the method was called from. There'd never be a way to access +either the class or instance variables. Ouch again! +As useful as ``@classmethod`` and ``@staticmethod`` are, they don't handle the +(occasionally important) corner case where you need to call with either the +class or an instance *and* you need genuine access to the object doing the +call. Here's an example that needs this:: + class Above(object): + base = 10 + def __init__(self, base=100): + self.base = base + @combomethod + def above_base(receiver, x): + return receiver.base + x + a = Above() + assert a.above_base(5) == 105 + assert Above.above_base(5) == 15 + aa = Above(12) + assert aa.above_base(5) == 17 + assert Above.above_base(5) == 15 +When you need to call with either an instance or a class, and you also care +about the object doing the calling, ``@combomethod`` rocks and rolls. + +%package -n python3-combomethod +Summary: Decorator indicating a method is both a class and an instance method +Provides: python-combomethod +BuildRequires: python3-devel +BuildRequires: python3-setuptools +BuildRequires: python3-pip +%description -n python3-combomethod +In some cases, you can fake ``@combomethod`` with ``@classmethod``. In +the code above, for example, there is no real reference to the class +or instance, and ``either`` could have been designated a ``@classmethod``, +since they can be called with either classes or instances. But, there's a +problem: Class methods *always* pass the class to the method, even if they're +called with an instance. With this approach, you can never access the +instance variables. Ouch! +Alternatively, ``either`` could have been designated a ``@staticmethod``, +had its ``receiver`` parameter been removed. But while it would then be +callable from either an instance or a class, in neither case would it pass +the object the method was called from. There'd never be a way to access +either the class or instance variables. Ouch again! +As useful as ``@classmethod`` and ``@staticmethod`` are, they don't handle the +(occasionally important) corner case where you need to call with either the +class or an instance *and* you need genuine access to the object doing the +call. Here's an example that needs this:: + class Above(object): + base = 10 + def __init__(self, base=100): + self.base = base + @combomethod + def above_base(receiver, x): + return receiver.base + x + a = Above() + assert a.above_base(5) == 105 + assert Above.above_base(5) == 15 + aa = Above(12) + assert aa.above_base(5) == 17 + assert Above.above_base(5) == 15 +When you need to call with either an instance or a class, and you also care +about the object doing the calling, ``@combomethod`` rocks and rolls. + +%package help +Summary: Development documents and examples for combomethod +Provides: python3-combomethod-doc +%description help +In some cases, you can fake ``@combomethod`` with ``@classmethod``. In +the code above, for example, there is no real reference to the class +or instance, and ``either`` could have been designated a ``@classmethod``, +since they can be called with either classes or instances. But, there's a +problem: Class methods *always* pass the class to the method, even if they're +called with an instance. With this approach, you can never access the +instance variables. Ouch! +Alternatively, ``either`` could have been designated a ``@staticmethod``, +had its ``receiver`` parameter been removed. But while it would then be +callable from either an instance or a class, in neither case would it pass +the object the method was called from. There'd never be a way to access +either the class or instance variables. Ouch again! +As useful as ``@classmethod`` and ``@staticmethod`` are, they don't handle the +(occasionally important) corner case where you need to call with either the +class or an instance *and* you need genuine access to the object doing the +call. Here's an example that needs this:: + class Above(object): + base = 10 + def __init__(self, base=100): + self.base = base + @combomethod + def above_base(receiver, x): + return receiver.base + x + a = Above() + assert a.above_base(5) == 105 + assert Above.above_base(5) == 15 + aa = Above(12) + assert aa.above_base(5) == 17 + assert Above.above_base(5) == 15 +When you need to call with either an instance or a class, and you also care +about the object doing the calling, ``@combomethod`` rocks and rolls. + +%prep +%autosetup -n combomethod-1.0.12 + +%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-combomethod -f filelist.lst +%dir %{python3_sitelib}/* + +%files help -f doclist.lst +%{_docdir}/* + +%changelog +* Tue Apr 11 2023 Python_Bot <Python_Bot@openeuler.org> - 1.0.12-1 +- Package Spec generated @@ -0,0 +1 @@ +e5c0210e774f5c64b4cc8d5b06e4a5eb combomethod-1.0.12.zip |