The main problem with the "undefined" encoding is that it actually *fails* the application, rather than allowing it to continue, but providing a warning at each new point where it encounters implicit encoding or decoding. This means the parts of the standard library that actually rely on implicit coercion fail outright, rather than just generate warning noise that you can filter out as irrelevant to your particular application.

You raise a good point about `sitecustomize.py` though - I always forget about that feature myself, and it didn't come up in any of the Google results I looked at either.

The existing "undefined" option also at least allows you to categorically ensure you're not relying on implicit conversions at all, so the Python 3 porting guide could be updated to explicitly cover:

1. Finding the site customization path for your active virtual environment:

    python -c 'import os.path, sysconfig; print(os.path.join(sysconfig.get_path("purelib"), "sitecustomize.py"))'

2. What to write to that location to disable implicit Unicode conversions:

    import sys
    sys.setdefaultencoding('undefined')

Giving folks the following tiered path to Python 3 support:

- get "pylint --py3k" passing (e.g. via python-modernize)
- eliminate "python -3" warnings under Python 2
- (optional) support running with the above site customizations
- actually run under Python 3

Brett, does the above approach sound reasonable to you? If so, then I'll do that as a pure documentation change in the Py3k porting guide with a "See Also" to the above blog post, and then mark this as closed/postponed (given the `sitecustomize` approach to enable it, the 3rd party codec should be fine for folks that want the warning behaviour instead)