Mercurial > repos > shellac > guppy_basecaller

comparison env/lib/python3.7/site-packages/configparser-5.0.0.dist-info/METADATA @ 5:9b1c78e6ba9c draft default tip

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
"planemo upload commit 6c0a8142489327ece472c84e558c47da711a9142"
author shellac
date Mon, 01 Jun 2020 08:59:25 -0400
parents 79f47841a781
children
comparison
equal deleted inserted replaced
4:79f47841a781 5:9b1c78e6ba9c
1 Metadata-Version: 2.1
2 Name: configparser
3 Version: 5.0.0
4 Summary: Updated configparser from Python 3.8 for Python 2.6+.
5 Home-page: https://github.com/jaraco/configparser/
6 Author: Łukasz Langa
7 Author-email: lukasz@langa.pl
8 Maintainer: Jason R. Coombs
9 Maintainer-email: jaraco@jaraco.com
10 License: UNKNOWN
11 Keywords: configparser ini parsing conf cfg configuration file
12 Platform: any
13 Classifier: Development Status :: 5 - Production/Stable
14 Classifier: Intended Audience :: Developers
15 Classifier: License :: OSI Approved :: MIT License
16 Classifier: Programming Language :: Python :: 3
17 Classifier: Programming Language :: Python :: 3 :: Only
18 Requires-Python: >=3.6
19 Provides-Extra: docs
20 Requires-Dist: sphinx ; extra == 'docs'
21 Requires-Dist: jaraco.packaging (>=3.2) ; extra == 'docs'
22 Requires-Dist: rst.linker (>=1.9) ; extra == 'docs'
23 Provides-Extra: testing
24 Requires-Dist: pytest (!=3.7.3,>=3.5) ; extra == 'testing'
25 Requires-Dist: pytest-checkdocs (>=1.2.3) ; extra == 'testing'
26 Requires-Dist: pytest-flake8 ; extra == 'testing'
27 Requires-Dist: pytest-black-multipy ; extra == 'testing'
28 Requires-Dist: pytest-cov ; extra == 'testing'
29
30 .. image:: https://img.shields.io/pypi/v/configparser.svg
31 :target: `PyPI link`_
32
33 .. image:: https://img.shields.io/pypi/pyversions/configparser.svg
34 :target: `PyPI link`_
35
36 .. _PyPI link: https://pypi.org/project/configparser
37
38 .. image:: https://dev.azure.com/jaraco/configparser/_apis/build/status/jaraco.configparser?branchName=master
39 :target: https://dev.azure.com/jaraco/configparser/_build/latest?definitionId=1&branchName=master
40
41 .. image:: https://img.shields.io/travis/jaraco/configparser/master.svg
42 :target: https://travis-ci.org/jaraco/configparser
43
44 .. image:: https://img.shields.io/badge/code%20style-black-000000.svg
45 :target: https://github.com/psf/black
46 :alt: Code style: Black
47
48 .. .. image:: https://img.shields.io/appveyor/ci/jaraco/configparser/master.svg
49 .. :target: https://ci.appveyor.com/project/jaraco/configparser/branch/master
50
51 .. image:: https://readthedocs.org/projects/configparser/badge/?version=latest
52 :target: https://configparser.readthedocs.io/en/latest/?badge=latest
53
54 .. image:: https://tidelift.com/badges/package/pypi/configparser
55 :target: https://tidelift.com/subscription/pkg/pypi-configparser?utm_source=pypi-configparser&utm_medium=readme
56
57
58 The ancient ``ConfigParser`` module available in the standard library 2.x has
59 seen a major update in Python 3.2. This is a backport of those changes so that
60 they can be used directly in Python 2.6 - 3.5.
61
62 To use the ``configparser`` backport instead of the built-in version on both
63 Python 2 and Python 3, simply import it explicitly as a backport::
64
65 from backports import configparser
66
67 If you'd like to use the backport on Python 2 and the built-in version on
68 Python 3, use that invocation instead::
69
70 import configparser
71
72 For detailed documentation consult the vanilla version at
73 http://docs.python.org/3/library/configparser.html.
74
75 Why you'll love ``configparser``
76 --------------------------------
77
78 Whereas almost completely compatible with its older brother, ``configparser``
79 sports a bunch of interesting new features:
80
81 * full mapping protocol access (`more info
82 <http://docs.python.org/3/library/configparser.html#mapping-protocol-access>`_)::
83
84 >>> parser = ConfigParser()
85 >>> parser.read_string("""
86 [DEFAULT]
87 location = upper left
88 visible = yes
89 editable = no
90 color = blue
91
92 [main]
93 title = Main Menu
94 color = green
95
96 [options]
97 title = Options
98 """)
99 >>> parser['main']['color']
100 'green'
101 >>> parser['main']['editable']
102 'no'
103 >>> section = parser['options']
104 >>> section['title']
105 'Options'
106 >>> section['title'] = 'Options (editable: %(editable)s)'
107 >>> section['title']
108 'Options (editable: no)'
109
110 * there's now one default ``ConfigParser`` class, which basically is the old
111 ``SafeConfigParser`` with a bunch of tweaks which make it more predictable for
112 users. Don't need interpolation? Simply use
113 ``ConfigParser(interpolation=None)``, no need to use a distinct
114 ``RawConfigParser`` anymore.
115
116 * the parser is highly `customizable upon instantiation
117 <http://docs.python.org/3/library/configparser.html#customizing-parser-behaviour>`__
118 supporting things like changing option delimiters, comment characters, the
119 name of the DEFAULT section, the interpolation syntax, etc.
120
121 * you can easily create your own interpolation syntax but there are two powerful
122 implementations built-in (`more info
123 <http://docs.python.org/3/library/configparser.html#interpolation-of-values>`__):
124
125 * the classic ``%(string-like)s`` syntax (called ``BasicInterpolation``)
126
127 * a new ``${buildout:like}`` syntax (called ``ExtendedInterpolation``)
128
129 * fallback values may be specified in getters (`more info
130 <http://docs.python.org/3/library/configparser.html#fallback-values>`__)::
131
132 >>> config.get('closet', 'monster',
133 ... fallback='No such things as monsters')
134 'No such things as monsters'
135
136 * ``ConfigParser`` objects can now read data directly `from strings
137 <http://docs.python.org/3/library/configparser.html#configparser.ConfigParser.read_string>`__
138 and `from dictionaries
139 <http://docs.python.org/3/library/configparser.html#configparser.ConfigParser.read_dict>`__.
140 That means importing configuration from JSON or specifying default values for
141 the whole configuration (multiple sections) is now a single line of code. Same
142 goes for copying data from another ``ConfigParser`` instance, thanks to its
143 mapping protocol support.
144
145 * many smaller tweaks, updates and fixes
146
147 A few words about Unicode
148 -------------------------
149
150 ``configparser`` comes from Python 3 and as such it works well with Unicode.
151 The library is generally cleaned up in terms of internal data storage and
152 reading/writing files. There are a couple of incompatibilities with the old
153 ``ConfigParser`` due to that. However, the work required to migrate is well
154 worth it as it shows the issues that would likely come up during migration of
155 your project to Python 3.
156
157 The design assumes that Unicode strings are used whenever possible [1]_. That
158 gives you the certainty that what's stored in a configuration object is text.
159 Once your configuration is read, the rest of your application doesn't have to
160 deal with encoding issues. All you have is text [2]_. The only two phases when
161 you should explicitly state encoding is when you either read from an external
162 source (e.g. a file) or write back.
163
164 Versioning
165 ----------
166
167 This project uses `semver <https://semver.org/spec/v2.0.0.html>`_ to
168 communicate the impact of various releases while periodically syncing
169 with the upstream implementation in CPython.
170 `The changelog <https://github.com/jaraco/configparser/blob/master/CHANGES.rst>`_
171 serves as a reference indicating which versions incorporate
172 which upstream functionality.
173
174 Prior to the ``4.0.0`` release, `another scheme
175 <https://github.com/jaraco/configparser/blob/3.8.1/README.rst#versioning>`_
176 was used to associate the CPython and backports releases.
177
178 Maintenance
179 -----------
180
181 This backport was originally authored by Łukasz Langa, the current vanilla
182 ``configparser`` maintainer for CPython and is currently maintained by
183 Jason R. Coombs:
184
185 * `configparser repository <https://github.com/jaraco/configparser>`_
186
187 * `configparser issue tracker <https://github.com/jaraco/configparser/issues>`_
188
189 Security Contact
190 ----------------
191
192 To report a security vulnerability, please use the
193 `Tidelift security contact <https://tidelift.com/security>`_.
194 Tidelift will coordinate the fix and disclosure.
195
196 Conversion Process
197 ------------------
198
199 This section is technical and should bother you only if you are wondering how
200 this backport is produced. If the implementation details of this backport are
201 not important for you, feel free to ignore the following content.
202
203 ``configparser`` is converted using `python-future
204 <http://python-future.org>`_. The project takes the following
205 branching approach:
206
207 * the ``3.x`` branch holds unchanged files synchronized from the upstream
208 CPython repository. The synchronization is currently done by manually copying
209 the required files and stating from which CPython changeset they come from.
210
211 * the ``master`` branch holds a version of the ``3.x`` code with some tweaks
212 that make it independent from libraries and constructions unavailable on 2.x.
213 Code on this branch still *must* work on the corresponding Python 3.x but
214 will also work on Python 2.6 and 2.7 (including PyPy). You can check this
215 running the supplied unit tests with ``tox``.
216
217 The process works like this:
218
219 1. In the ``3.x`` branch, run ``pip-run -- sync-upstream.py``, which
220 downloads the latest stable release of Python and copies the relevant
221 files from there into their new locations here and then commits those
222 changes with a nice reference to the relevant upstream commit hash.
223
224 2. I check for new names in ``__all__`` and update imports in
225 ``configparser.py`` accordingly. I run the tests on Python 3. Commit.
226
227 3. I merge the new commit to ``master``. I run ``tox``. Commit.
228
229 4. If there are necessary changes, I do them now (on ``master``). Note that
230 the changes should be written in the syntax subset supported by Python
231 2.6.
232
233 5. I run ``tox``. If it works, I update the docs and release the new version.
234 Otherwise, I go back to point 3. I might use ``pasteurize`` to suggest me
235 required changes but usually I do them manually to keep resulting code in
236 a nicer form.
237
238
239 Footnotes
240 ---------
241
242 .. [1] To somewhat ease migration, passing bytestrings is still supported but
243 they are converted to Unicode for internal storage anyway. This means
244 that for the vast majority of strings used in configuration files, it
245 won't matter if you pass them as bytestrings or Unicode. However, if you
246 pass a bytestring that cannot be converted to Unicode using the naive
247 ASCII codec, a ``UnicodeDecodeError`` will be raised. This is purposeful
248 and helps you manage proper encoding for all content you store in
249 memory, read from various sources and write back.
250
251 .. [2] Life gets much easier when you understand that you basically manage
252 **text** in your application. You don't care about bytes but about
253 letters. In that regard the concept of content encoding is meaningless.
254 The only time when you deal with raw bytes is when you write the data to
255 a file. Then you have to specify how your text should be encoded. On
256 the other end, to get meaningful text from a file, the application
257 reading it has to know which encoding was used during its creation. But
258 once the bytes are read and properly decoded, all you have is text. This
259 is especially powerful when you start interacting with multiple data
260 sources. Even if each of them uses a different encoding, inside your
261 application data is held in abstract text form. You can program your
262 business logic without worrying about which data came from which source.
263 You can freely exchange the data you store between sources. Only
264 reading/writing files requires encoding your text to bytes.
265
266