rpm/python-yapf
SHA256
1
0
Fork 0
forked from pool/python-yapf
Code Pull Requests Activity

Accepting request 582349 from home:jengelh:branches:devel:languages:python

Browse Source 
- Trim description and focus on the package, not the process.

OBS-URL: https://build.opensuse.org/request/show/582349
OBS-URL: https://build.opensuse.org/package/show/devel:languages:python/python-yapf?expand=0&rev=2
This commit is contained in:
Tomáš Chvátal 2018-03-04 11:10:46 +00:00 committed by Git OBS Bridge
parent 6789e7c807
commit 84a20ed3dc
2 changed files with 16 additions and 19 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
python-yapf.changes
View File

@ -1,3 +1,8 @@
-------------------------------------------------------------------
Sun Mar 4 11:06:23 UTC 2018 - jengelh@inai.de
- Trim description and focus on the package, not the process.
------------------------------------------------------------------- -------------------------------------------------------------------
Fri Oct 20 16:19:54 UTC 2017 - toddrme2178@gmail.com Fri Oct 20 16:19:54 UTC 2017 - toddrme2178@gmail.com

30
python-yapf.spec
View File

@ -1,7 +1,7 @@
# #
# spec file for package python-yapf # spec file for package python-yapf
# #
# Copyright (c) 2017 SUSE LINUX GmbH, Nuernberg, Germany. # Copyright (c) 2018 SUSE LINUX GmbH, Nuernberg, Germany.
# #
# All modifications and additions to the file contributed by third parties # All modifications and additions to the file contributed by third parties
# remain the property of their copyright owners, unless otherwise agreed # remain the property of their copyright owners, unless otherwise agreed
@ -13,6 +13,7 @@
# published by the Open Source Initiative. # published by the Open Source Initiative.
# Please submit bugfixes or comments via http://bugs.opensuse.org/ # Please submit bugfixes or comments via http://bugs.opensuse.org/
#
%{?!python_module:%define python_module() python-%{**} python3-%{**}} %{?!python_module:%define python_module() python-%{**} python3-%{**}}
@ -20,10 +21,10 @@
Name: python-yapf Name: python-yapf
Version: 0.19.0 Version: 0.19.0
Release: 0 Release: 0
License: Apache-2.0
Summary: A formatter for Python code Summary: A formatter for Python code
Url: https://github.com/google/yapf License: Apache-2.0
Group: Development/Languages/Python Group: Development/Languages/Python
Url: https://github.com/google/yapf
Source: https://files.pythonhosted.org/packages/source/y/yapf/yapf-%{version}.tar.gz Source: https://files.pythonhosted.org/packages/source/y/yapf/yapf-%{version}.tar.gz
BuildRequires: %{python_module devel} BuildRequires: %{python_module devel}
BuildRequires: %{python_module setuptools} BuildRequires: %{python_module setuptools}
@ -43,23 +44,14 @@ Requires(postun): update-alternatives
%python_subpackages %python_subpackages
%description %description
Most of the current formatters for Python --- e.g., autopep8, and pep8ify --- YAPF is based off clang-format and reformats it to the closest
are made to remove lint errors from code. This has some obvious limitations. formatting that conforms to the style guide, even if the original
For instance, code that conforms to the PEP 8 guidelines may not be code did not violate the style guide.
reformatted. But it doesn't mean that the code looks good.
YAPF takes a different approach. It's based off of 'clang-format', developed by This is in contrast to other formatters like autopep8 and pep8ify
Daniel Jasper. In essence, the algorithm takes the code and reformats it to the which are made to only remove lint errors from code, which has some
best formatting that conforms to the style guide, even if the original code limitations, like, code that conforms to the PEP 8 guidelines may not
didn't violate the style guide. The idea is also similar to the 'gofmt' tool for be reformatted.
the Go programming language: end all holy wars about formatting - if the whole
codebase of a project is simply piped through YAPF whenever modifications are
made, the style remains consistent throughout the project and there's no point
arguing about style in every code review.
The ultimate goal is that the code YAPF produces is as good as the code that a
programmer would write if they were following the style guide. It takes away
some of the drudgery of maintaining your code.
%prep %prep
%setup -q -n yapf-%{version} %setup -q -n yapf-%{version}