python开发_pprint()

python中的pprint.pprint(),类似于print()

下面是我做的demo:

 1 #python pprint
 2 
 3 '''python API中提供的Sample'''
 4 import json
 5 import pprint
 6 from urllib.request import urlopen
 7 
 8 with urlopen('http://pypi.python.org/pypi/configparser/json') as url:
 9     http_info = url.info()
10     raw_data = url.read().decode(http_info.get_content_charset())
11 project_info = json.loads(raw_data)
12 result = {'headers' : http_info.items(), 'body' : project_info}
13 
14 pprint.pprint(result)
15 
16 pprint.pprint('#' * 50)
17 pprint.pprint(result, depth=3)
18 
19 pprint.pprint('#' * 50)
20 pprint.pprint(result['headers'], width=30)
21 
22 pprint.pprint('#' * 50)
23 #自定义Demo
24 test_list = ['a', 'c', 'e', 'd', '2']
25 test_list.insert(0, test_list)
26 pprint.pprint(test_list)

运行效果:

Python 3.3.2 (v3.3.2:d047928ae3f6, May 16 2013, 00:03:43) [MSC v.1600 32 bit (Intel)] on win32
Type "copyright", "credits" or "license()" for more information.
>>> ================================ RESTART ================================
>>> 
{'body': {'info': {'_pypi_hidden': False,
                   '_pypi_ordering': 14,
                   'author': 'Łukasz Langa',
                   'author_email': 'lukasz@langa.pl',
                   'bugtrack_url': None,
                   'cheesecake_code_kwalitee_id': None,
                   'cheesecake_documentation_id': None,
                   'cheesecake_installability_id': None,
                   'classifiers': ['Development Status :: 5 - Production/Stable',
                                   'Intended Audience :: Developers',
                                   'License :: OSI Approved :: MIT License',
                                   'Natural Language :: English',
                                   'Operating System :: OS Independent',
                                   'Programming Language :: Python',
                                   'Programming Language :: Python :: 2',
                                   'Programming Language :: Python :: 2.6',
                                   'Programming Language :: Python :: 2.7',
                                   'Topic :: Software Development :: Libraries',
                                   'Topic :: Software Development :: Libraries :: Python Modules'],
                   'description': '============\nconfigparser\n============\n\nThe ancient ``ConfigParser`` module available in the standard library 2.x has\nseen a major update in Python 3.2. This is a backport of those changes so that\nthey can be used directly in Python 2.6 - 2.7.\n\nTo use ``configparser`` instead of ``ConfigParser``, simply replace::\n  \n  import ConfigParser\n\nwith::\n\n  import configparser\n\nFor detailed documentation consult the vanilla version at\nhttp://docs.python.org/3/library/configparser.html.\n\nWhy you\'ll love ``configparser``\n--------------------------------\n\nWhereas almost completely compatible with its older brother, ``configparser``\nsports a bunch of interesting new features:\n\n* full mapping protocol access (`more info\n  <http://docs.python.org/3/library/configparser.html#mapping-protocol-access>`_)::\n\n    >>> parser = ConfigParser()\n    >>> parser.read_string("""\n    [DEFAULT]\n    location = upper left\n    visible = yes\n    editable = no\n    color = blue\n\n    [main]\n    title = Main Menu\n    color = green\n\n    [options]\n    title = Options\n    """)\n    >>> parser[\'main\'][\'color\']\n    \'green\'\n    >>> parser[\'main\'][\'editable\']\n    \'no\'\n    >>> section = parser[\'options\']\n    >>> section[\'title\']\n    \'Options\'\n    >>> section[\'title\'] = \'Options (editable: %(editable)s)\'\n    >>> section[\'title\']\n    \'Options (editable: no)\'\n  \n* there\'s now one default ``ConfigParser`` class, which basically is the old\n  ``SafeConfigParser`` with a bunch of tweaks which make it more predictable for\n  users. Don\'t need interpolation? Simply use\n  ``ConfigParser(interpolation=None)``, no need to use a distinct\n  ``RawConfigParser`` anymore.\n\n* the parser is highly `customizable upon instantiation\n  <http://docs.python.org/3/library/configparser.html#customizing-parser-behaviour>`__\n  supporting things like changing option delimiters, comment characters, the\n  name of the DEFAULT section, the interpolation syntax, etc.\n\n* you can easily create your own interpolation syntax but there are two powerful\n  implementations built-in (`more info\n  <http://docs.python.org/3/library/configparser.html#interpolation-of-values>`__):\n\n  * the classic ``%(string-like)s`` syntax (called ``BasicInterpolation``)\n\n  * a new ``${buildout:like}`` syntax (called ``ExtendedInterpolation``)\n  \n* fallback values may be specified in getters (`more info\n  <http://docs.python.org/3/library/configparser.html#fallback-values>`__)::\n\n    >>> config.get(\'closet\', \'monster\',\n    ...            fallback=\'No such things as monsters\')\n    \'No such things as monsters\'\n  \n* ``ConfigParser`` objects can now read data directly `from strings\n  <http://docs.python.org/3/library/configparser.html#configparser.ConfigParser.read_string>`__\n  and `from dictionaries\n  <http://docs.python.org/3/library/configparser.html#configparser.ConfigParser.read_dict>`__.\n  That means importing configuration from JSON or specifying default values for\n  the whole configuration (multiple sections) is now a single line of code. Same\n  goes for copying data from another ``ConfigParser`` instance, thanks to its\n  mapping protocol support. \n\n* many smaller tweaks, updates and fixes\n\nA few words about Unicode\n-------------------------\n\n``configparser`` comes from Python 3 and as such it works well with Unicode.\nThe library is generally cleaned up in terms of internal data storage and\nreading/writing files.  There are a couple of incompatibilities with the old\n``ConfigParser`` due to that. However, the work required to migrate is well\nworth it as it shows the issues that would likely come up during migration of\nyour project to Python 3.\n\nThe design assumes that Unicode strings are used whenever possible [1]_.  That\ngives you the certainty that what\'s stored in a configuration object is text.\nOnce your configuration is read, the rest of your application doesn\'t have to\ndeal with encoding issues. All you have is text [2]_. The only two phases when\nyou should explicitly state encoding is when you either read from an external\nsource (e.g. a file) or write back. \n\nVersioning\n----------\n\nThis backport is intended to keep 100% compatibility with the vanilla release in\nPython 3.2+. To help maintaining a version you want and expect, a versioning\nscheme is used where:\n\n* the first three numbers indicate the version of Python 3.x from which the\n  backport is done\n\n* a backport release number is provided after the ``r`` letter\n\nFor example, ``3.3.0r1`` is the **first** release of ``configparser`` compatible\nwith the library found in Python **3.3.0**.\n\nA single exception from the 100% compatibility principle is that bugs fixed\nbefore releasing another minor Python 3.x.y version **will be included** in the\nbackport releases done in the mean time. This rule applies to bugs only.\n\nMaintenance\n-----------\n\nThis backport is maintained on BitBucket by Łukasz Langa, the current vanilla\n``configparser`` maintainer for CPython:\n\n* `configparser Mercurial repository <https://bitbucket.org/ambv/configparser>`_\n\n* `configparser issue tracker <https://bitbucket.org/ambv/configparser/issues>`_ \n\nChange Log\n----------\n\n3.3.0r2\n~~~~~~~\n\n* updated the fix for `#16820 <http://bugs.python.org/issue16820>`_: parsers\n  now preserve section order when using ``__setitem__`` and ``update``\n\n3.3.0r1\n~~~~~~~\n\n* compatible with 3.3.0 + fixes for `#15803\n  <http://bugs.python.org/issue15803>`_ and `#16820\n  <http://bugs.python.org/issue16820>`_\n\n* fixes `BitBucket issue #4\n  <https://bitbucket.org/ambv/configparser/issue/4>`_: ``read()`` properly\n  treats a bytestring argument as a filename\n\n* `ordereddict <http://pypi.python.org/pypi/ordereddict>`_ dependency required\n  only for Python 2.6\n\n* `unittest2 <http://pypi.python.org/pypi/unittest2>`_ explicit dependency\n  dropped. If you want to test the release, add ``unittest2`` on your own.\n\n3.2.0r3\n~~~~~~~\n\n* proper Python 2.6 support\n\n  * explicitly stated the dependency on `ordereddict\n    <http://pypi.python.org/pypi/ordereddict>`_\n\n  * numbered all formatting braces in strings\n\n* explicitly says that Python 2.5 support won\'t happen (too much work necessary\n  without abstract base classes, string formatters, the ``io`` library, etc.)\n\n* some healthy advertising in the README\n\n3.2.0r2\n~~~~~~~\n\n* a backport-specific change: for convenience and basic compatibility with the\n  old ConfigParser, bytestrings are now accepted as section names, options and\n  values.  Those strings are still converted to Unicode for internal storage so\n  in any case when such conversion is not possible (using the \'ascii\' codec),\n  UnicodeDecodeError is raised.\n\n3.2.0r1\n~~~~~~~\n\n* the first public release compatible with 3.2.0 + fixes for `#11324\n  <http://bugs.python.org/issue11324>`_, `#11670\n  <http://bugs.python.org/issue11670>`_ and `#11858\n  <http://bugs.python.org/issue11858>`_.\n\nConversion Process\n------------------\n\nThis section is technical and should bother you only if you are wondering how\nthis backport is produced. If the implementation details of this backport are\nnot important for you, feel free to ignore the following content.\n\n``configparser`` is converted using `3to2 <http://pypi.python.org/pypi/3to2>`_.\nBecause a fully automatic conversion was not doable, I took the following\nbranching approach:\n\n* the ``3.x`` branch holds unchanged files synchronized from the upstream\n  CPython repository. The synchronization is currently done by manually copying\n  the required files and stating from which CPython changeset they come from.\n\n* the ``3.x-clean`` branch holds a version of the ``3.x`` code with some tweaks\n  that make it independent from libraries and constructions unavailable on 2.x.\n  Code on this branch still *must* work on the corresponding Python 3.x. You\n  can check this running the supplied unit tests.\n\n* the ``default`` branch holds necessary changes which break unit tests on\n  Python 3.2.  Additional files which are used by the backport are also stored\n  here.\n\nThe process works like this:\n\n1. I update the ``3.x`` branch with new versions of files. Commit.\n\n2. I merge the new commit to ``3.x-clean``. Check unit tests. Commit.\n\n3. If there are necessary changes that can be made in a 3.x compatible manner,\n   I do them now (still on ``3.x-clean``), check unit tests and commit. If I\'m\n   not yet aware of any, no problem.\n\n4. I merge the changes from ``3.x-clean`` to ``default``. Commit.\n\n5. If there are necessary changes that *cannot* be made in a 3.x compatible\n   manner, I do them now (on ``default``). Note that the changes should still\n   be written using 3.x syntax. If I\'m not yet aware of any required changes,\n   no problem.\n\n6. I run ``./convert.py`` which is a custom ``3to2`` runner for this project.\n\n7. I run the unit tests with ``unittest2`` on Python 2.x. If the tests are OK,\n   I can prepare a new release.  Otherwise, I revert the ``default`` branch to\n   its previous state (``hg revert .``) and go back to Step 3.\n\n**NOTE:** the ``default`` branch holds unconverted code. This is because keeping\nthe conversion step as the last (after any custom changes) helps managing the\nhistory better. Plus, the merges are nicer and updates of the converter software\ndon\'t create nasty conflicts in the repository.\n\nThis process works well but if you have any tips on how to make it simpler and\nfaster, do enlighten me :)\n\nFootnotes\n---------\n\n.. [1] To somewhat ease migration, passing bytestrings is still supported but\n       they are converted to Unicode for internal storage anyway. This means\n       that for the vast majority of strings used in configuration files, it\n       won\'t matter if you pass them as bytestrings or Unicode. However, if you\n       pass a bytestring that cannot be converted to Unicode using the naive\n       ASCII codec, a ``UnicodeDecodeError`` will be raised. This is purposeful\n       and helps you manage proper encoding for all content you store in\n       memory, read from various sources and write back.\n\n.. [2] Life gets much easier when you understand that you basically manage\n       **text** in your application.  You don\'t care about bytes but about\n       letters.  In that regard the concept of content encoding is meaningless.\n       The only time when you deal with raw bytes is when you write the data to\n       a file.  Then you have to specify how your text should be encoded.  On\n       the other end, to get meaningful text from a file, the application\n       reading it has to know which encoding was used during its creation.  But\n       once the bytes are read and properly decoded, all you have is text.  This\n       is especially powerful when you start interacting with multiple data\n       sources.  Even if each of them uses a different encoding, inside your\n       application data is held in abstract text form.  You can program your\n       business logic without worrying about which data came from which source.\n       You can freely exchange the data you store between sources.  Only\n       reading/writing files requires encoding your text to bytes.',
                   'docs_url': '',
                   'download_url': 'UNKNOWN',
                   'home_page': 'http://docs.python.org/3/library/configparser.html',
                   'keywords': 'configparser ini parsing conf cfg configuration file',
                   'license': 'MIT',
                   'maintainer': None,
                   'maintainer_email': None,
                   'name': 'configparser',
                   'package_url': 'http://pypi.python.org/pypi/configparser',
                   'platform': 'any',
                   'release_url': 'http://pypi.python.org/pypi/configparser/3.3.0r2',
                   'requires_python': None,
                   'stable_version': None,
                   'summary': 'This library brings the updated configparser from Python 3.2+ to Python 2.6-2.7.',
                   'version': '3.3.0r2'},
          'urls': [{'comment_text': '',
                    'downloads': 11937,
                    'filename': 'configparser-3.3.0r2.tar.gz',
                    'has_sig': False,
                    'md5_digest': 'dda0e6a43e9d8767b36d10f1e6770f09',
                    'packagetype': 'sdist',
                    'python_version': 'source',
                    'size': 32885,
                    'upload_time': '2013-01-02T00:58:20',
                    'url': 'https://pypi.python.org/packages/source/c/configparser/configparser-3.3.0r2.tar.gz'}]},
 'headers': [('Date', 'Thu, 15 Aug 2013 06:17:52 GMT'),
             ('Content-Type', 'application/json; charset="UTF-8"'),
             ('Content-Disposition', 'inline'),
             ('Strict-Transport-Security', 'max-age=31536000'),
             ('Content-Length', '13510'),
             ('Accept-Ranges', 'bytes'),
             ('Age', '0'),
             ('Connection', 'close')]}
'##################################################'
{'body': {'info': {'_pypi_hidden': False,
                   '_pypi_ordering': 14,
                   'author': 'Łukasz Langa',
                   'author_email': 'lukasz@langa.pl',
                   'bugtrack_url': None,
                   'cheesecake_code_kwalitee_id': None,
                   'cheesecake_documentation_id': None,
                   'cheesecake_installability_id': None,
                   'classifiers': [...],
                   'description': '============\nconfigparser\n============\n\nThe ancient ``ConfigParser`` module available in the standard library 2.x has\nseen a major update in Python 3.2. This is a backport of those changes so that\nthey can be used directly in Python 2.6 - 2.7.\n\nTo use ``configparser`` instead of ``ConfigParser``, simply replace::\n  \n  import ConfigParser\n\nwith::\n\n  import configparser\n\nFor detailed documentation consult the vanilla version at\nhttp://docs.python.org/3/library/configparser.html.\n\nWhy you\'ll love ``configparser``\n--------------------------------\n\nWhereas almost completely compatible with its older brother, ``configparser``\nsports a bunch of interesting new features:\n\n* full mapping protocol access (`more info\n  <http://docs.python.org/3/library/configparser.html#mapping-protocol-access>`_)::\n\n    >>> parser = ConfigParser()\n    >>> parser.read_string("""\n    [DEFAULT]\n    location = upper left\n    visible = yes\n    editable = no\n    color = blue\n\n    [main]\n    title = Main Menu\n    color = green\n\n    [options]\n    title = Options\n    """)\n    >>> parser[\'main\'][\'color\']\n    \'green\'\n    >>> parser[\'main\'][\'editable\']\n    \'no\'\n    >>> section = parser[\'options\']\n    >>> section[\'title\']\n    \'Options\'\n    >>> section[\'title\'] = \'Options (editable: %(editable)s)\'\n    >>> section[\'title\']\n    \'Options (editable: no)\'\n  \n* there\'s now one default ``ConfigParser`` class, which basically is the old\n  ``SafeConfigParser`` with a bunch of tweaks which make it more predictable for\n  users. Don\'t need interpolation? Simply use\n  ``ConfigParser(interpolation=None)``, no need to use a distinct\n  ``RawConfigParser`` anymore.\n\n* the parser is highly `customizable upon instantiation\n  <http://docs.python.org/3/library/configparser.html#customizing-parser-behaviour>`__\n  supporting things like changing option delimiters, comment characters, the\n  name of the DEFAULT section, the interpolation syntax, etc.\n\n* you can easily create your own interpolation syntax but there are two powerful\n  implementations built-in (`more info\n  <http://docs.python.org/3/library/configparser.html#interpolation-of-values>`__):\n\n  * the classic ``%(string-like)s`` syntax (called ``BasicInterpolation``)\n\n  * a new ``${buildout:like}`` syntax (called ``ExtendedInterpolation``)\n  \n* fallback values may be specified in getters (`more info\n  <http://docs.python.org/3/library/configparser.html#fallback-values>`__)::\n\n    >>> config.get(\'closet\', \'monster\',\n    ...            fallback=\'No such things as monsters\')\n    \'No such things as monsters\'\n  \n* ``ConfigParser`` objects can now read data directly `from strings\n  <http://docs.python.org/3/library/configparser.html#configparser.ConfigParser.read_string>`__\n  and `from dictionaries\n  <http://docs.python.org/3/library/configparser.html#configparser.ConfigParser.read_dict>`__.\n  That means importing configuration from JSON or specifying default values for\n  the whole configuration (multiple sections) is now a single line of code. Same\n  goes for copying data from another ``ConfigParser`` instance, thanks to its\n  mapping protocol support. \n\n* many smaller tweaks, updates and fixes\n\nA few words about Unicode\n-------------------------\n\n``configparser`` comes from Python 3 and as such it works well with Unicode.\nThe library is generally cleaned up in terms of internal data storage and\nreading/writing files.  There are a couple of incompatibilities with the old\n``ConfigParser`` due to that. However, the work required to migrate is well\nworth it as it shows the issues that would likely come up during migration of\nyour project to Python 3.\n\nThe design assumes that Unicode strings are used whenever possible [1]_.  That\ngives you the certainty that what\'s stored in a configuration object is text.\nOnce your configuration is read, the rest of your application doesn\'t have to\ndeal with encoding issues. All you have is text [2]_. The only two phases when\nyou should explicitly state encoding is when you either read from an external\nsource (e.g. a file) or write back. \n\nVersioning\n----------\n\nThis backport is intended to keep 100% compatibility with the vanilla release in\nPython 3.2+. To help maintaining a version you want and expect, a versioning\nscheme is used where:\n\n* the first three numbers indicate the version of Python 3.x from which the\n  backport is done\n\n* a backport release number is provided after the ``r`` letter\n\nFor example, ``3.3.0r1`` is the **first** release of ``configparser`` compatible\nwith the library found in Python **3.3.0**.\n\nA single exception from the 100% compatibility principle is that bugs fixed\nbefore releasing another minor Python 3.x.y version **will be included** in the\nbackport releases done in the mean time. This rule applies to bugs only.\n\nMaintenance\n-----------\n\nThis backport is maintained on BitBucket by Łukasz Langa, the current vanilla\n``configparser`` maintainer for CPython:\n\n* `configparser Mercurial repository <https://bitbucket.org/ambv/configparser>`_\n\n* `configparser issue tracker <https://bitbucket.org/ambv/configparser/issues>`_ \n\nChange Log\n----------\n\n3.3.0r2\n~~~~~~~\n\n* updated the fix for `#16820 <http://bugs.python.org/issue16820>`_: parsers\n  now preserve section order when using ``__setitem__`` and ``update``\n\n3.3.0r1\n~~~~~~~\n\n* compatible with 3.3.0 + fixes for `#15803\n  <http://bugs.python.org/issue15803>`_ and `#16820\n  <http://bugs.python.org/issue16820>`_\n\n* fixes `BitBucket issue #4\n  <https://bitbucket.org/ambv/configparser/issue/4>`_: ``read()`` properly\n  treats a bytestring argument as a filename\n\n* `ordereddict <http://pypi.python.org/pypi/ordereddict>`_ dependency required\n  only for Python 2.6\n\n* `unittest2 <http://pypi.python.org/pypi/unittest2>`_ explicit dependency\n  dropped. If you want to test the release, add ``unittest2`` on your own.\n\n3.2.0r3\n~~~~~~~\n\n* proper Python 2.6 support\n\n  * explicitly stated the dependency on `ordereddict\n    <http://pypi.python.org/pypi/ordereddict>`_\n\n  * numbered all formatting braces in strings\n\n* explicitly says that Python 2.5 support won\'t happen (too much work necessary\n  without abstract base classes, string formatters, the ``io`` library, etc.)\n\n* some healthy advertising in the README\n\n3.2.0r2\n~~~~~~~\n\n* a backport-specific change: for convenience and basic compatibility with the\n  old ConfigParser, bytestrings are now accepted as section names, options and\n  values.  Those strings are still converted to Unicode for internal storage so\n  in any case when such conversion is not possible (using the \'ascii\' codec),\n  UnicodeDecodeError is raised.\n\n3.2.0r1\n~~~~~~~\n\n* the first public release compatible with 3.2.0 + fixes for `#11324\n  <http://bugs.python.org/issue11324>`_, `#11670\n  <http://bugs.python.org/issue11670>`_ and `#11858\n  <http://bugs.python.org/issue11858>`_.\n\nConversion Process\n------------------\n\nThis section is technical and should bother you only if you are wondering how\nthis backport is produced. If the implementation details of this backport are\nnot important for you, feel free to ignore the following content.\n\n``configparser`` is converted using `3to2 <http://pypi.python.org/pypi/3to2>`_.\nBecause a fully automatic conversion was not doable, I took the following\nbranching approach:\n\n* the ``3.x`` branch holds unchanged files synchronized from the upstream\n  CPython repository. The synchronization is currently done by manually copying\n  the required files and stating from which CPython changeset they come from.\n\n* the ``3.x-clean`` branch holds a version of the ``3.x`` code with some tweaks\n  that make it independent from libraries and constructions unavailable on 2.x.\n  Code on this branch still *must* work on the corresponding Python 3.x. You\n  can check this running the supplied unit tests.\n\n* the ``default`` branch holds necessary changes which break unit tests on\n  Python 3.2.  Additional files which are used by the backport are also stored\n  here.\n\nThe process works like this:\n\n1. I update the ``3.x`` branch with new versions of files. Commit.\n\n2. I merge the new commit to ``3.x-clean``. Check unit tests. Commit.\n\n3. If there are necessary changes that can be made in a 3.x compatible manner,\n   I do them now (still on ``3.x-clean``), check unit tests and commit. If I\'m\n   not yet aware of any, no problem.\n\n4. I merge the changes from ``3.x-clean`` to ``default``. Commit.\n\n5. If there are necessary changes that *cannot* be made in a 3.x compatible\n   manner, I do them now (on ``default``). Note that the changes should still\n   be written using 3.x syntax. If I\'m not yet aware of any required changes,\n   no problem.\n\n6. I run ``./convert.py`` which is a custom ``3to2`` runner for this project.\n\n7. I run the unit tests with ``unittest2`` on Python 2.x. If the tests are OK,\n   I can prepare a new release.  Otherwise, I revert the ``default`` branch to\n   its previous state (``hg revert .``) and go back to Step 3.\n\n**NOTE:** the ``default`` branch holds unconverted code. This is because keeping\nthe conversion step as the last (after any custom changes) helps managing the\nhistory better. Plus, the merges are nicer and updates of the converter software\ndon\'t create nasty conflicts in the repository.\n\nThis process works well but if you have any tips on how to make it simpler and\nfaster, do enlighten me :)\n\nFootnotes\n---------\n\n.. [1] To somewhat ease migration, passing bytestrings is still supported but\n       they are converted to Unicode for internal storage anyway. This means\n       that for the vast majority of strings used in configuration files, it\n       won\'t matter if you pass them as bytestrings or Unicode. However, if you\n       pass a bytestring that cannot be converted to Unicode using the naive\n       ASCII codec, a ``UnicodeDecodeError`` will be raised. This is purposeful\n       and helps you manage proper encoding for all content you store in\n       memory, read from various sources and write back.\n\n.. [2] Life gets much easier when you understand that you basically manage\n       **text** in your application.  You don\'t care about bytes but about\n       letters.  In that regard the concept of content encoding is meaningless.\n       The only time when you deal with raw bytes is when you write the data to\n       a file.  Then you have to specify how your text should be encoded.  On\n       the other end, to get meaningful text from a file, the application\n       reading it has to know which encoding was used during its creation.  But\n       once the bytes are read and properly decoded, all you have is text.  This\n       is especially powerful when you start interacting with multiple data\n       sources.  Even if each of them uses a different encoding, inside your\n       application data is held in abstract text form.  You can program your\n       business logic without worrying about which data came from which source.\n       You can freely exchange the data you store between sources.  Only\n       reading/writing files requires encoding your text to bytes.',
                   'docs_url': '',
                   'download_url': 'UNKNOWN',
                   'home_page': 'http://docs.python.org/3/library/configparser.html',
                   'keywords': 'configparser ini parsing conf cfg configuration file',
                   'license': 'MIT',
                   'maintainer': None,
                   'maintainer_email': None,
                   'name': 'configparser',
                   'package_url': 'http://pypi.python.org/pypi/configparser',
                   'platform': 'any',
                   'release_url': 'http://pypi.python.org/pypi/configparser/3.3.0r2',
                   'requires_python': None,
                   'stable_version': None,
                   'summary': 'This library brings the updated configparser from Python 3.2+ to Python 2.6-2.7.',
                   'version': '3.3.0r2'},
          'urls': [{...}]},
 'headers': [('Date', 'Thu, 15 Aug 2013 06:17:52 GMT'),
             ('Content-Type', 'application/json; charset="UTF-8"'),
             ('Content-Disposition', 'inline'),
             ('Strict-Transport-Security', 'max-age=31536000'),
             ('Content-Length', '13510'),
             ('Accept-Ranges', 'bytes'),
             ('Age', '0'),
             ('Connection', 'close')]}
'##################################################'
[('Date',
  'Thu, 15 Aug 2013 06:17:52 GMT'),
 ('Content-Type',
  'application/json; charset="UTF-8"'),
 ('Content-Disposition',
  'inline'),
 ('Strict-Transport-Security',
  'max-age=31536000'),
 ('Content-Length', '13510'),
 ('Accept-Ranges', 'bytes'),
 ('Age', '0'),
 ('Connection', 'close')]
'##################################################'
[<Recursion on list with id=39183984>, 'a', 'c', 'e', 'd', '2']
>>> 

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏微信公众号:Java团长

自己手写一个SpringMVC框架

前端框架很多,但没有一个框架称霸,后端框架现在Spring已经完成大一统。所以学习Spring是Java程序员的必修课。

1012
来自专栏人工智能LeadAI

使用强大的 Mockito 来测试你的代码

这篇教程介绍了如何使用 Mockito 框架来给软件写测试用例。 1、预备知识 如果需要往下学习,你需要先理解 Junit 框架中的单元测试。 如果你不熟悉 J...

2.3K6
来自专栏java技术学习之道

事物在Controller层的探索

1173
来自专栏猿天地

高性能NIO框架Netty-对象传输

上篇文章高性能NIO框架Netty入门篇我们对Netty做了一个简单的介绍,并且写了一个入门的Demo,客户端往服务端发送一个字符串的消息,服务端回复一个字符串...

3118
来自专栏Golang语言社区

Golang Stub初体验

序言 对于领域对象的UT测试来说,基础设施层(infra)的操作函数都应该被打桩。对于Golang来说,大家通常会想到GoMock。GoMock是由Golang...

4189
来自专栏开发与安全

linux网络编程之POSIX 共享内存和 系列函数

在前面介绍了system v 共享内存的相关知识,现在来稍微看看posix 共享内存 和系列函数。 共享内存简单来说就是一块真正的物理内存区域,可以使用一些函数...

2270
来自专栏IT笔记

Grafana+Prometheus系统监控之SpringBoot

前言 前一段时间使用SpringBoot创建了一个webhook项目,由于近期项目中也使用了不少SpringBoot相关的项目,趁着周末,配置一下使用prome...

1.5K7
来自专栏微信公众号:Java团长

SpringMVC常用注解标签详解

在SpringMVC 中,控制器Controller 负责处理由DispatcherServlet 分发的请求,它把用户请求的数据经过业务处理层处理之后封装成一...

1552
来自专栏闻道于事

深入分析Spring Boot2,解决 java.lang.ArrayStoreException异常

将某个项目从Spring Boot1升级Spring Boot2之后出现如下报错,查了很多不同的解决方法都没有解决:

1.1K2
来自专栏Java后端技术

五种方式让你在java中读取properties文件内容不再是难题

  最近,在项目开发的过程中,遇到需要在properties文件中定义一些自定义的变量,以供java程序动态的读取,修改变量,不再需要修改代码的问题。就借此机会...

1602

扫码关注云+社区

领取腾讯云代金券