Thank you for envparse. I liked its API so much that I implemented a successor library, environs, which uses marshmallow to do the heavy lifting for casting, validation, and serialization.

environ's API is near-identical to envparse, with a few differences:

• environs supports a few more cast types, including decimal, datetime, date, timedelta, and uuid
• environs adds validation. https://github.com/sloria/environs#validation
• environs implements serialization: https://github.com/sloria/environs#serialization
• environs allows the user to register custom parser methods: https://github.com/sloria/environs#defining-custom-parser-behavior . This makes it easy to create plugins; see https://github.com/sloria/environs/blob/master/examples/plugin_example.py
• environs handles prefixes: https://github.com/sloria/environs#handling-prefixes
• You cannot pass a schema to the Env constructor. (Env(FOO=bool)). This was intentional; I did not see an advantage in having the redundant API.
• environs does not implement env('VARNAME', cast=str); you must do env.str('VARNAME'). Again, the intention was to avoid redundant API.
• preprocessor and postprocessor are not supported. Any pre- or post-processing can happen in a custom parser function
• environs cannot read .env files (yet). Up for discussion here: Read .env files sloria/environs#1
• environs does not support proxied variables (yet)

environs was mostly written as a proof-of-concept, though at this point it is stable enough to use (it's only ~100SLOC after all).

I wonder if we could reduce duplication of effort by merging these two libraries. I haven't yet thought about the particulars; just wanted to open the table for discussion first.

Thoughts?