Even though expecting the NUL-terminator is legacy behaviour, newer versions of the syslog daemons presumably follow Postel's rule of "be conservative in what you do, be liberal in what you accept from others". Can flume not be changed to follow this principle, given that ordinarily you wouldn't expect a NUL terminator byte on syslog messages?

When the implementation of SysLogHandler was changed to comply (more closely) with RFC5424, the log_format_string value was inadvertently left behind in Python 2.x, and it makes sense to remove it since changing it doesn't do anything useful.

Having an append_nul parameter to control NUL-termination is certainly doable, and this approach will keep the 2.x and 3.x implementations more or less the same (as 3.x doesn't have a log_format_string attribute). I suggest "nul" rather than "null" since we're talking about appending a NUL byte to the message.

However, having it as an additional keyword parameter to the constructor could cause dictConfig failures if configurations specifying it are used with an old version of Python (e.g. 3.2.0) which doesn't have the parameter. For this reason, it might be better to have an append_nul class attribute (defaulting to True) which can be overridden with an instance attribute set to False. (This approach can still be used with dictConfig, as you can use a factory function other than the SysLogHandler class to construct a SysLogHandler instance.)