sprockets / sprockets.mixins.mediatype

Handles Content-Type & Accept header serialization and deserialization for you

Sprockets

A loosely coupled framework built on top of Tornado. Take what you need to build awesome applications.

The core sprockets packages offers only the command line application for invoking Sprockets controllers such as the HTTP and AMQP controllers.

CLI Usage

usage: sprockets [-h] [-l] [-d] [-s] [-v] [--version]

{http,amqp} ... application

positional arguments:

{http,amqp} Available sprockets application controllers

http HTTP Application Controller amqp RabbitMQ Worker Controller

application The sprockets app to run

optional arguments:

-h, --help	show this help message and exit
-l, --list	List installed sprockets apps
-s, --syslog	Log to syslog
-v, --verbose	Verbose logging output, use -vv for DEBUG level logging
--version	show program's version number and exit

sprockets.mixins.mediatype's Issues

Support context suffixes (RFC6839)

ietfparse 1.5.0 introduced breaking behavior that alters the behavior of this module.

For example:

content.add_transcoder(
    self, transcoders.JSONTranscoder(),
    content_type='application/vnd.some.app+json')
content.add_transcoder(
    self, transcoders.MsgPackTranscoder(),
    content_type='application/vnd.some.app+msgpack')

With ietfparse < 1.5, this module will see each content type + suffix as a distinct content type.

With ietfparse >= 1.5, this module's usage of ietfparse will result in the suffix being stripped before registering the transcoder.

`get_request_body` should catch `TypeError` in addition to `ValueError`

sprockets.mixins.mediatype/sprockets/mixins/mediatype/content.py

Lines 367 to 371 in 4dbc740

	try:
	content_type_header = headers.parse_content_type(content_type)
	except ValueError:
	raise web.HTTPError(400, 'failed to parse content type %s',
	content_type)

If the default content type is unset, then content_type will be None and parse_content_type will raise a TypeError instead of a ValueError. In either case, we should be responding with a "client error".

Support serialization of more types

• add serialization support for decimal.Decimal and figure out how to best represent it for interop in the case of JSON
• add serialization support for dataclasses_ by guarding with dataclasses.is_dataclass and calling dataclasses.asdict
• add serialization support for stuff from the ipaddress module
• maybe add duck-typed serialization support for pydantic models -- detect the dict method and call it?
• others?

Add typing support

I started an effort to do this a few years ago (see #23) but it fizzled since the typing SIG was still changing things. Now that things have settled done in the part of the ecosystem, I'd like to reboot it. I still like the approach that I took in my original branch:

• represent expectations using structural sub-typing and typing.Protocol sub-classes explicitly
• add type definitions for precisely we know how to serialize -- IOW, define a union type like SerializableTypes
• document the definitions and expected usage
• pull mypy (maybe pyright?) into the build chain

The one downside is that typing.Protocol was added in 3.8 and we still support 3.7. We can use the typing.extensions package as a backport. For this reason, I would isolate the typing-related classes into a module named sprockets.mixins.mediatype.type_info and use it in conjunction with typing. The goal is to not let the non-3.7 compatibility stuff leak out of the module.

Feel free to steal, adopt, and/or ignore portions of my original branch.

Add pre-commit hook suggestion

Having a pre-commit hook set up to verify style would be a nice benefit. I don't want to go to the extreme of using a framework for this. Let's start by including one in the docs directory that is pulled into docs/contributing.rst via a literalinclude directive.

Deploy pipeline is broken

I added the testing pipeline components but we are still lacking the distirbution/upload portion of the pipeline. This has been broken since travis-ci.org went away on June 15, 2021.

Enforce code formatting

Either yapf or black ... in any case:

• line length is 79 chars
• single-quotes are preferred over double quotes except in docstrings
• CI pipeline fails if there are formatting violations
• tox.ini is updated with a "lint" target that checks style
• expectations are documented in docs/contributing.rst

My vote would be for yapf since it has fewer dependencies and generally creates code that my eyes like.