This file is indexed.

/usr/lib/python2.7/dist-packages/configparser-3.5.0.egg-info/PKG-INFO is in python-configparser 3.5.0-1.

This file is owned by root:root, with mode 0o644.

The actual contents of the file can be viewed below.

  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
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
Metadata-Version: 1.1
Name: configparser
Version: 3.5.0
Summary: This library brings the updated configparser from Python 3.5 to Python 2.6-3.5.
Home-page: http://docs.python.org/3/library/configparser.html
Author: Lukasz Langa
Author-email: lukasz@langa.pl
License: MIT
Description: ============
        configparser
        ============
        
        The ancient ``ConfigParser`` module available in the standard library 2.x has
        seen a major update in Python 3.2. This is a backport of those changes so that
        they can be used directly in Python 2.6 - 3.5.
        
        To use the ``configparser`` backport instead of the built-in version on both
        Python 2 and Python 3, simply import it explicitly as a backport::
        
          from backports import configparser
        
        If you'd like to use the backport on Python 2 and the built-in version on
        Python 3, use that invocation instead::
        
          import configparser
        
        For detailed documentation consult the vanilla version at
        http://docs.python.org/3/library/configparser.html.
        
        Why you'll love ``configparser``
        --------------------------------
        
        Whereas almost completely compatible with its older brother, ``configparser``
        sports a bunch of interesting new features:
        
        * full mapping protocol access (`more info
          <http://docs.python.org/3/library/configparser.html#mapping-protocol-access>`_)::
        
            >>> parser = ConfigParser()
            >>> parser.read_string("""
            [DEFAULT]
            location = upper left
            visible = yes
            editable = no
            color = blue
        
            [main]
            title = Main Menu
            color = green
        
            [options]
            title = Options
            """)
            >>> parser['main']['color']
            'green'
            >>> parser['main']['editable']
            'no'
            >>> section = parser['options']
            >>> section['title']
            'Options'
            >>> section['title'] = 'Options (editable: %(editable)s)'
            >>> section['title']
            'Options (editable: no)'
        
        * there's now one default ``ConfigParser`` class, which basically is the old
          ``SafeConfigParser`` with a bunch of tweaks which make it more predictable for
          users. Don't need interpolation? Simply use
          ``ConfigParser(interpolation=None)``, no need to use a distinct
          ``RawConfigParser`` anymore.
        
        * the parser is highly `customizable upon instantiation
          <http://docs.python.org/3/library/configparser.html#customizing-parser-behaviour>`__
          supporting things like changing option delimiters, comment characters, the
          name of the DEFAULT section, the interpolation syntax, etc.
        
        * you can easily create your own interpolation syntax but there are two powerful
          implementations built-in (`more info
          <http://docs.python.org/3/library/configparser.html#interpolation-of-values>`__):
        
          * the classic ``%(string-like)s`` syntax (called ``BasicInterpolation``)
        
          * a new ``${buildout:like}`` syntax (called ``ExtendedInterpolation``)
        
        * fallback values may be specified in getters (`more info
          <http://docs.python.org/3/library/configparser.html#fallback-values>`__)::
        
            >>> config.get('closet', 'monster',
            ...            fallback='No such things as monsters')
            'No such things as monsters'
        
        * ``ConfigParser`` objects can now read data directly `from strings
          <http://docs.python.org/3/library/configparser.html#configparser.ConfigParser.read_string>`__
          and `from dictionaries
          <http://docs.python.org/3/library/configparser.html#configparser.ConfigParser.read_dict>`__.
          That means importing configuration from JSON or specifying default values for
          the whole configuration (multiple sections) is now a single line of code. Same
          goes for copying data from another ``ConfigParser`` instance, thanks to its
          mapping protocol support.
        
        * many smaller tweaks, updates and fixes
        
        A few words about Unicode
        -------------------------
        
        ``configparser`` comes from Python 3 and as such it works well with Unicode.
        The library is generally cleaned up in terms of internal data storage and
        reading/writing files.  There are a couple of incompatibilities with the old
        ``ConfigParser`` due to that. However, the work required to migrate is well
        worth it as it shows the issues that would likely come up during migration of
        your project to Python 3.
        
        The design assumes that Unicode strings are used whenever possible [1]_.  That
        gives you the certainty that what's stored in a configuration object is text.
        Once your configuration is read, the rest of your application doesn't have to
        deal with encoding issues. All you have is text [2]_. The only two phases when
        you should explicitly state encoding is when you either read from an external
        source (e.g. a file) or write back.
        
        Versioning
        ----------
        
        This backport is intended to keep 100% compatibility with the vanilla release in
        Python 3.2+. To help maintaining a version you want and expect, a versioning
        scheme is used where:
        
        * the first two numbers indicate the version of Python 3 from which the
          backport is done
        
        * a backport release number is provided as the final number (zero-indexed)
        
        For example, ``3.5.2`` is the **third** backport release of the
        ``configparser`` library as seen in Python 3.5.  Note that ``3.5.2`` does
        **NOT** necessarily mean this backport version is based on the standard library
        of Python 3.5.2.
        
        One exception from the 100% compatibility principle is that bugs fixed before
        releasing another minor Python 3 bugfix version **will be included** in the
        backport releases done in the mean time.
        
        Maintenance
        -----------
        
        This backport is maintained on BitBucket by Ɓukasz Langa, the current vanilla
        ``configparser`` maintainer for CPython:
        
        * `configparser Mercurial repository <https://bitbucket.org/ambv/configparser>`_
        
        * `configparser issue tracker <https://bitbucket.org/ambv/configparser/issues>`_
        
        Change Log
        ----------
        
        3.5.0
        ~~~~~
        
        * a complete rewrite of the backport; now single codebase working on Python
          2.6 - 3.5. To use on Python 3 import ``from backports import configparser``
          instead of the built-in version.
        
        * compatible with 3.5.1
        
        * fixes `BitBucket issue #1
          <https://bitbucket.org/ambv/configparser/issue/1>`_: versioning non-compliant
          with PEP 386
        
        * fixes `BitBucket issue #3
          <https://bitbucket.org/ambv/configparser/issue/3>`_: ``reload(sys);
          sys.setdefaultencoding('utf8')`` in setup.py
        
        * fixes `BitBucket issue #5
          <https://bitbucket.org/ambv/configparser/issue/5>`_: Installing the backport
          on Python 3 breaks virtualenv
        
        * fixes `BitBucket issue #6
          <https://bitbucket.org/ambv/configparser/issue/6>`_: PyPy compatibility
        
        3.5.0b2
        ~~~~~~~
        
        * second beta of 3.5.0, not using any third-party futurization libraries
        
        3.5.0b1
        ~~~~~~~
        
        * first beta of 3.5.0, using python-future
        
        * for the full feature list, see `3.5.0`_
        
        3.3.0r2
        ~~~~~~~
        
        * updated the fix for `#16820 <http://bugs.python.org/issue16820>`_: parsers
          now preserve section order when using ``__setitem__`` and ``update``
        
        3.3.0r1
        ~~~~~~~
        
        * compatible with 3.3.0 + fixes for `#15803
          <http://bugs.python.org/issue15803>`_ and `#16820
          <http://bugs.python.org/issue16820>`_
        
        * fixes `BitBucket issue #4
          <https://bitbucket.org/ambv/configparser/issue/4>`_: ``read()`` properly
          treats a bytestring argument as a filename
        
        * `ordereddict <http://pypi.python.org/pypi/ordereddict>`_ dependency required
          only for Python 2.6
        
        * `unittest2 <http://pypi.python.org/pypi/unittest2>`_ explicit dependency
          dropped. If you want to test the release, add ``unittest2`` on your own.
        
        3.2.0r3
        ~~~~~~~
        
        * proper Python 2.6 support
        
          * explicitly stated the dependency on `ordereddict
            <http://pypi.python.org/pypi/ordereddict>`_
        
          * numbered all formatting braces in strings
        
        * explicitly says that Python 2.5 support won't happen (too much work necessary
          without abstract base classes, string formatters, the ``io`` library, etc.)
        
        * some healthy advertising in the README
        
        3.2.0r2
        ~~~~~~~
        
        * a backport-specific change: for convenience and basic compatibility with the
          old ConfigParser, bytestrings are now accepted as section names, options and
          values.  Those strings are still converted to Unicode for internal storage so
          in any case when such conversion is not possible (using the 'ascii' codec),
          UnicodeDecodeError is raised.
        
        3.2.0r1
        ~~~~~~~
        
        * the first public release compatible with 3.2.0 + fixes for `#11324
          <http://bugs.python.org/issue11324>`_, `#11670
          <http://bugs.python.org/issue11670>`_ and `#11858
          <http://bugs.python.org/issue11858>`_.
        
        Conversion Process
        ------------------
        
        This section is technical and should bother you only if you are wondering how
        this backport is produced. If the implementation details of this backport are
        not important for you, feel free to ignore the following content.
        
        ``configparser`` is converted using `python-future
        <http://python-future.org>`_ and free time.  Because a fully automatic
        conversion was not doable, I took the following branching approach:
        
        * the ``3.x`` branch holds unchanged files synchronized from the upstream
          CPython repository. The synchronization is currently done by manually copying
          the required files and stating from which CPython changeset they come from.
        
        * the ``default`` branch holds a version of the ``3.x`` code with some tweaks
          that make it independent from libraries and constructions unavailable on 2.x.
          Code on this branch still *must* work on the corresponding Python 3.x but
          will also work on Python 2.6 and 2.7 (including PyPy).  You can check this
          running the supplied unit tests with ``tox``.
        
        The process works like this:
        
        1. I update the ``3.x`` branch with new versions of files.  Note that the
           actual ``configparser.py`` file is now just a proxy for sources held in
           ``backports/configparser/__init__.py``.
        
        2. I check for new names in ``__all__`` and update imports in
           ``configparser.py`` accordingly. I run the tests on Python 3. Commit.
        
        3. I merge the new commit to ``default``. I run ``tox``. Commit.
        
        4. If there are necessary changes, I do them now (on ``default``). Note that
           the changes should be written in the syntax subset supported by Python
           2.6.
        
        5. I run ``tox``. If it works, I update the docs and release the new version.
           Otherwise, I go back to point 3. I might use ``pasteurize`` to suggest me
           required changes but usually I do them manually to keep resulting code in
           a nicer form.
        
        
        Footnotes
        ---------
        
        .. [1] To somewhat ease migration, passing bytestrings is still supported but
               they are converted to Unicode for internal storage anyway. This means
               that for the vast majority of strings used in configuration files, it
               won't matter if you pass them as bytestrings or Unicode. However, if you
               pass a bytestring that cannot be converted to Unicode using the naive
               ASCII codec, a ``UnicodeDecodeError`` will be raised. This is purposeful
               and helps you manage proper encoding for all content you store in
               memory, read from various sources and write back.
        
        .. [2] Life gets much easier when you understand that you basically manage
               **text** in your application.  You don't care about bytes but about
               letters.  In that regard the concept of content encoding is meaningless.
               The only time when you deal with raw bytes is when you write the data to
               a file.  Then you have to specify how your text should be encoded.  On
               the other end, to get meaningful text from a file, the application
               reading it has to know which encoding was used during its creation.  But
               once the bytes are read and properly decoded, all you have is text.  This
               is especially powerful when you start interacting with multiple data
               sources.  Even if each of them uses a different encoding, inside your
               application data is held in abstract text form.  You can program your
               business logic without worrying about which data came from which source.
               You can freely exchange the data you store between sources.  Only
               reading/writing files requires encoding your text to bytes.
        
Keywords: configparser ini parsing conf cfg configuration file
Platform: any
Classifier: Development Status :: 5 - Production/Stable
Classifier: Intended Audience :: Developers
Classifier: License :: OSI Approved :: MIT License
Classifier: Natural Language :: English
Classifier: Operating System :: OS Independent
Classifier: Programming Language :: Python
Classifier: Programming Language :: Python :: 2
Classifier: Programming Language :: Python :: 2.6
Classifier: Programming Language :: Python :: 2.7
Classifier: Programming Language :: Python :: 3
Classifier: Programming Language :: Python :: 3.4
Classifier: Programming Language :: Python :: 3.5
Classifier: Topic :: Software Development :: Libraries
Classifier: Topic :: Software Development :: Libraries :: Python Modules