# -*- coding: utf-8 -*-
from distutils.core import setup

packages = \
['any_case', 'any_case.contrib', 'any_case.contrib.django']

package_data = \
{'': ['*']}

setup_kwargs = {
    'name': 'any-case',
    'version': '0.1.1',
    'description': 'Snake/Camle case converter with django and rest_framework integration',
    'long_description': ".. highlight:: python\n\nany_case\n========\n\nWhen developing a web application, you often have to choose the case format (snake_case/camelCase)\nwill be used for the input and the output json data. If the backend is written in Python,\nthe easiest option is to choose snake_case. On the one hand, this is good, because we have\nan obvious consistency, but on the other hand, the main consumers of the API (mobile and browser)\nprefer to use camelCase.\n\nIf we care about our consumers, we will change the case format to camelCase. And it's good if we think\nabout it in advance, before publishing API. But if this happens in an existing application,\nit becomes much more difficult to do so because there are consumers using the existing API.\nWe have two options here:\n\n- introduce a new version of the api\n- send data in two cases at once\n\nThe second option increases the size of the data, and the first option forces us to support two\nversions of the API without serious need. These options complicate the support and development of API.\n\nThings get a little more complicated when we have consumers who natively use snake_case,\nand using camelCase for them is not an option at all.\n\nAs you can see, the use of one notation does not improve, but may worsen the situation.\n\nBut why do we have to choose for the customer which case format they use?\nWhy customers do not send and not receive data in the format, which would be more convenient to them?\n\n\nThat's what this library is for. Consumers choose in what case they expect the data.\nIf they specified an incorrect case or made a request without specifying a case,\nthe data will be given as is.\n\nThis approach allows existing consumers to work without changes with existing API, and for those\nconsumers who want to use a single format, allows granular rewriting of the application.\n\nInstallation\n============\n::\n\n    pip install any_case\n\nUsage\n=====\nFor converting dict or list use ``converts_keys`` function::\n\n    >>> from any_case import converts_keys\n    >>> data = {'camelCaseKey': 'value'}\n    >>> converts_keys(data, case='snake')\n    {'camel_case_key': 'value'}\n    >>> data = {'snake_case': 'camelCase'}\n    >>> converts_keys(data, case='camel')\n    {'snakeCase': 'camelCase'}\n    >>>\n\nFor converting ``any_case`` uses compiled regex and stack for objects traversal.\n\nTo convert text, use ``to_snake_case`` or ``to_camel_case``::\n\n    >>> from any_case import to_snake_case, to_camel_case\n    >>> to_snake_case('snakeCase')\n    'snake_case'\n    >>> to_camel_case('snake_case')\n    'snakeCase'\n\nMore examples see at tests folder.\n\nIntegrations\n============\n\nDjango\n------\n\nFor integration with the Django framework, you need to add ``any_case`` middleware::\n\n    MIDDLEWARE = [\n        'django.contrib.sessions.middleware.SessionMiddleware',\n        ...\n        'any_case.contrib.django.middleware.KeysConverterMiddleware'\n    ]\n\n\nWhen the input data is converted, it is saved in the ``json`` field of request object.\nThat is, you can access to the converted data in the view as follows::\n\n    def view(request):\n        data = request.json\n        ...\n\nrest_framework\n--------------\n\nFor integration with rest_framework, replace default json parser and renderer::\n\n    REST_FRAMEWORK = {\n        'DEFAULT_RENDERER_CLASSES': (\n            'any_case.contrib.rest_framework.AnyCaseJSONParser',\n            ...\n        ),\n        'DEFAULT_PARSER_CLASSES': (\n            'any_case.contrib.rest_framework.AnyCaseJSONRenderer',\n            ...\n        )\n    }\n\n\nSettings\n--------\n``any_case`` has the next default settings::\n\n    ANY_CASE = {\n        'HEADER_KEY': 'Accept-Json-Case',\n        'QUERY_KEY': None,\n        'BODY_KEY': None,\n        'CONVERT_INPUT_JSON': True\n    }\n\nSettings are specified in django ``settings.py``.\n\n``any_case`` can be used for converting input json data to snake_case and for converting\noutput json to snake_case or camelCase. Or only one of the above independently.\n\nYou can specify the format in the header, in the query parameters, or in the json body.\nThe preferred way is the header, because specifying in the query or in the body\nis not always possible. Specifying case format in the body also forces to parse json data that\nmay not be needed at all.\n\n\nDisable converting output data\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n::\n\n    ANY_CASE = {\n        'HEADER_KEY': None,\n        'QUERY_KEY': None,\n        'BODY_KEY': None,\n    }\n\nDisable converting input data\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\n::\n\n    ANY_CASE = {\n        'CONVERT_INPUT_JSON': False\n    }\n",
    'author': 'asduj',
    'author_email': 'asduj@ya.ru',
    'url': 'https://github.com/asduj/any_case',
    'packages': packages,
    'package_data': package_data,
    'python_requires': '>=3.6,<4.0',
}


setup(**setup_kwargs)
