Skip to main content

Simple python module for loading and dumping structures in req format, a very simple {string: (string|list(string))} format.

Parses a structure like this:

Foo|Bar
Baz_1|alpha
Baz_2|beta
Baz_3|gamma

into:

{
    'Foo': 'Bar',
    'Baz': [
        'alpha',
        'beta',
        'gamma',
    ],
}

The load and dump methods will maintain the encoding given and will not correct on errors. If you pass a utf-8 filehandle to load, you’ll get unicode output. If you pass a bytestring filehandle to load, you’ll get bytestring output. loads is the same, but with either a unicode or bytestring input. dump will try to do the same, and dumps will attempt to determine the type. All dicts and arrays are expected to be entirely homogeneous (either entirely composed of unicode strings or entirely composed of byte strings). To not enforce this in the client side is undefined, and may be an explicit error in the future. Another undefined action is to embed newlines in any strings.

The only truly ambiguous case is dumps when given an empty dict. In this case, dumps will return an empty str object.

For structures parsed into lists, the logic is as such:

  • Any underscore and non-negative integer ending a key will automatically coerce into an list.

  • The actual values of the integers aren’t important. They will be ordered based on their decimal order. Holes and starting index aren’t bothered with.

  • If a field has an integer index given, but also has a non-indexed field of the same name, the non-indexed field will be given top precedence (essentially an index of -1)

  • Output of lists is 1-indexed by default, but this may be changed via a kwarg. If you need holes for whatever reason, you should pre-process the arrays into regular dict mappings.

This format is order-independent by default, but you may use an OrderedDict or something to maintain order on reading and writing. This does mean that dumping and loading an object (or vice versa) aren’t guaranteed to yield the exact same representation, but doing any 3 alternating operations in a row usually should.

Release files for ucbreq 2.0.5

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for ucbreq 2.0.5
File Size Uploaded
ucbreq-2.0.5.tar.gz 9.1 kB Details

Built distribution (wheel)

Table of built distributions (wheels) for ucbreq 2.0.5
File Interpreter ABI Platform
ucbreq-2.0.5-py3-none-any.whl Python 3 none any Details

Total release size: 14.2 kB

Release files / ucbreq-2.0.5.tar.gz

Download URL ucbreq-2.0.5.tar.gz
Size 9.1 kB
Tags Source
SHA-256 checksum
How to use checksums
6f838d02ebb68eadd7665c32d06c96898dced8d2cd7d4955a2e33db8dc1e921c
BLAKE2b-256 checksum
How to use checksums
849dc2c2a801251e8830c5289841dfb91556e88a2062eec472879024e451214e
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
No
Uploaded via python-requests/2.31.0

Release files / ucbreq-2.0.5-py3-none-any.whl

Download URL ucbreq-2.0.5-py3-none-any.whl
Size 5.1 kB
Tags Python 3
SHA-256 checksum
How to use checksums
8582a5fa1c324b36bee8c17e0a90c6490c65fe09c840c2533206bc966f61d562
BLAKE2b-256 checksum
How to use checksums
92d1255601156e1f763369f0a50b60787d281d0be82ce4ed94016b3cf285926f
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
No
Uploaded via python-requests/2.31.0

Release history Release notifications | RSS feed

This release

2.0.5 This release

2 release files

2.0.4

2 release files

2.0.3

2 release files

2.0.2

2 release files

2.0.1

2 release files

2.0.0

2 release files

1.0.1

1 release file

1.0.0

1 release file

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page