Add binary_display configuration option

[rolandwalker]

Description

This is the rough equivalent of the vendor --skip-binary-as-text CLI option, which has the effect of reversing

• Better solution for binary value rendering #1483

when set to "utf8".

I'm still not sure how to write tests for non-default myclirc options, though there may have been a recent example. Tests incorporated thanks to @scottnemes .

Fixes #1511.

Checklist

• I added this contribution to the changelog.md file.
• I added my name to the AUTHORS file (or it's already there).
• To lint and format the code, I ran

  uv run ruff check && uv run ruff format && uv run mypy --install-types .

[rolandwalker]

Maybe the configuration option should be non-boolean, like

binary_display = hex

Edit: updated the PR to be a non-boolean binary_display as above. This way there could be more choices in the future.

[scottnemes]

Got some tests that should work:

@dbtest
def test_binary_display_hex(executor, capsys):
    m = MyCli()
    m.sqlexecute = SQLExecute(
        None,
        USER,
        PASSWORD,
        HOST,
        PORT,
        None,
        None,
        None,
        None,
        None,
        None,
        None,
        None,
        None,
        None,
    )
    m.explicit_pager = False
    sqlresult = next(m.sqlexecute.run("select b'01101010' AS binary_test"))
    formatted = m.format_output(
        sqlresult.title,
        sqlresult.results,
        sqlresult.headers,
        False,
        False,
        "<nope>",
        "right",
        "hex",
        None,
    )
    m.output(formatted, sqlresult.status)
    expected = "+-------------+\n| binary_test |\n+-------------+\n| 0x6a        |\n+-------------+\n1 row in set\n"
    stdout = capsys.readouterr().out
    assert expected in stdout


@dbtest
def test_binary_display_utf8(executor, capsys):
    m = MyCli()
    m.sqlexecute = SQLExecute(
        None,
        USER,
        PASSWORD,
        HOST,
        PORT,
        None,
        None,
        None,
        None,
        None,
        None,
        None,
        None,
        None,
        None,
    )
    m.explicit_pager = False
    sqlresult = next(m.sqlexecute.run("select b'01101010' AS binary_test"))
    formatted = m.format_output(
        sqlresult.title,
        sqlresult.results,
        sqlresult.headers,
        False,
        False,
        "<nope>",
        "right",
        "utf8",
        None,
    )
    m.output(formatted, sqlresult.status)
    expected = "+-------------+\n| binary_test |\n+-------------+\n| j           |\n+-------------+\n1 row in set\n"
    stdout = capsys.readouterr().out
    assert expected in stdout

[rolandwalker]

When I incorporate the tests, the new tests pass, but then the behave suite fails

• https://github.com/dbcli/mycli/actions/runs/21746270111/job/62732789810

and only in CI, not on my local.

[scottnemes]

When I incorporate the tests, the new tests pass, but then the behave suite fails

• https://github.com/dbcli/mycli/actions/runs/21746270111/job/62732789810

and only in CI, not on my local.

Yeah the whole test suite works fine for me as well. Weird! I'll look at it more later to see if I can find anything. No idea how it would affect other tests though, especially the entirely different test suite.

[scottnemes]

When I incorporate the tests, the new tests pass, but then the behave suite fails

• https://github.com/dbcli/mycli/actions/runs/21746270111/job/62732789810

and only in CI, not on my local.

Testing this out on another PR, and it is working. I based my branch off of main, so guessing there is some combo of other stuff your branch has (or doesn't have). See my PR for the diffs:
#1514

I did notice that the mycli/myclirc has the option null_string=<null> while the test/myclirc has null_string=<nope>. The test is looking for the <nope> value, but that was working previously. So guessing there is something to do with recent config changes that there is some combo of changes where it is now using the null_string value from mycli/myclirc instead of the test one perhaps.

Edit:

Don't think I had your latest changes on my last test, so I did it again (less diffs this time), but tests all passed again. So seems something is/was going on when you pushed the tests the first time.

#1515