Re: Release 0.20

Dear Günter,

> I'd like to keep support for the default Python version of Debian/stable
> (even if this is longer than 42 months old).

Fair enough!

---------------------------------------------------------------------


>> I am content to go with option (c), but I would want to simultaneously announce
>> the version where the default would change to ``auto_encode=False`` and the
>> version where ``publish_string()`` would only support returning ``str``
>> instances.

> I suggest to do the default switch 2 versions after announcement, i.e. 0.22
> or 1.0 (announce as 0.22 or later).
> I would not announce removal of the option now (shold not be earlier than
> 3.0, maybe never).

Ok, this sounds good -- introduce the ``auto_encode`` argument now,
defaulting to ``True``, and announce that it will switch to ``False`` in
Docutils 0.22 or later. 

---------------------------------------------------------------------

>> I think that it might be possible to implement the new ``auto_encode``
>> parameter without a custom ``str`` subclass,

> The problem with exporting an output document as `str` instance
> (auto_encode=False) is that

> * The output document by default contains an "encoding indicator" (at least
>   in HTML and LaTeX) which is determined by the "output_encoding" setting
>   (depending on a set of configuration files or command line input which may
>   be "programatically overwritten").
  
> * A `str` instance has no meta-data storing the "intended encoding".
> 
>   The application calling `publish_string()` would have to re-enact the
>   configuration parsing or to grep in the string to find out the
>   right encoding.

> The old approach is to use publish_parts() and from the returned dictionary
> use the "document" and "encoding" items.

> I am open for other suggestions to solve this problem.  

I think here we should say "practicality beats purity" and go with the subclass,
viewing it as a transitional measure. You make good arguments!

---------------------------------------------------------------------

>> I think we should keep the ``publish_bytes()`` function in either case.

> I don't see a convincing use case for ``publish_bytes()`` and would
> prefer to keep the "core" interface as small as sensible.

The main use(s) here would be for publishing binary formats (e.g. ODT) to a ``bytes``
object in memory rather than writing to disk, or for when call-sites use a non-unicode
``output_encoding`` setting. If it is to be removed, perhaps we could provide a recipie
in the documentation for how to manage publishing to an in-memory byte sequence.

Thanks,
Adam