Skip to content

Support Markdown tables without padding#71

Open
Synse wants to merge 2 commits intothombashi:masterfrom
Synse:markdown-no-padding
Open

Support Markdown tables without padding#71
Synse wants to merge 2 commits intothombashi:masterfrom
Synse:markdown-no-padding

Conversation

@Synse
Copy link
Copy Markdown
Contributor

@Synse Synse commented Jul 11, 2025

This PR makes it possible to render markdown tables without padding using the existing is_padding argument.

Rendering a table with a header or value that is extremely long results in an excessively padded table. While the resulting table is (potentially) easier for humans to read, it is functionally equivalent1 once the markdown is rendered.

When using the table somewhere with limited space (e.g., a GitHub issue/PR body) not having the padding allows for a "larger" table (no characters wasted on padding) or more content in addition to the table.

Note

The is_padding argument removes the padding today but the header separator row requires at least one - for proper rendering. With this change you can write a valid markdown table, without padding.

👀 Usage and Examples

Pass is_padding=False to MarkdownTableWriter to render a table without padding. The existing default behavior (table with padding) remains unchanged.

>>> from pytablewriter import MarkdownTableWriter
>>> MarkdownTableWriter(headers=["foo", "bar"], value_matrix=[["one really long string", 123456],["foo", 1381290238121]], is_padding=False).write_table()
|foo|bar|
|---|--:|
|one really long string|123456|
|foo|1381290238121|
>>> MarkdownTableWriter(headers=["foo", "bar"], value_matrix=[["one really long string", 123456],["foo", 1381290238121]]).write_table()
|         foo          |     bar     |
|----------------------|------------:|
|one really long string|       123456|
|foo                   |1381290238121|
>>> 

These two tables are equivalent when rendered:

With padding (current behavior)

|row|    a longer column name    | a |
|--:|----------------------------|---|
|  1|some long value in this cell|b  |
|  2|medium                      |c  |
Rendered
row a longer column name a
1 some long value in this cell b
2 medium c

Without padding (new behavior, with is_padding=False)

|row|a longer column name|a|
|--:|---|---|
|1|some long value in this cell|b|
|2|medium|c|
Rendered
row a longer column name a
1 some long value in this cell b
2 medium c

💭 Other thoughts

  1. Should MarkdownTableWriter default to no padding now, in a future (breaking) release, or never?
  2. Would it make sense to have a different argument for this behavior? Reference documentation doesn't appear to show parent class properties (is_padding) but it seems like it should? 🤔
  3. Would an example in the docs be valuable (e.g., md_example_without_padding.txt)?

Footnotes

  1. At least for GitHub Flavored Markdown, and I wasn't able to find anything stating that CommonMark or kramdown require padding for tables.

@Synse
Copy link
Copy Markdown
Contributor Author

Synse commented Dec 8, 2025

@thombashi could you take a look at this one? 🙇

@Synse
Copy link
Copy Markdown
Contributor Author

Synse commented Mar 13, 2026

@thombashi could you take a look at this PR? 🙇

Copy link
Copy Markdown
Owner

@thombashi thombashi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for the delay in reviewing.

  1. Should MarkdownTableWriter default to no padding now, in a future (breaking) release, or never?

I don't plan to change the default value.
This is because padding generally improves readability, and changing it would break backward compatibility.

  1. Would it make sense to have a different argument for this behavior? Reference documentation doesn't appear to show parent class properties (is_padding) but it seems like it should? 🤔

Since is_padding is declared as .. py:attribute::, it is intended that it does not appear in the subclass documentation.
Generally, users do not need to modify is_padding in individual writer classes.
Since this PR's changes affect only the MarkdownTableWriter class, it might be better to add a docstring to the Args of the MarkdownTableWriter.write_table method.

  1. Would an example in the docs be valuable (e.g., md_example_without_padding.txt)?

It would be helpful for users to include an example of using is_padding=False with MarkdownTableWriter.

padding_len = self._get_padding_len(col_dp)
# columns in a header separator row must have at least one dash
# using a minimum of three accounts for right and center alignment
padding_len = max(3, self._get_padding_len(col_dp))
Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be best to declare 3 as a constant, such as _MIN_HEADER_SEP_LEN .

Comment on lines +100 to +101
# columns in a header separator row must have at least one dash
# using a minimum of three accounts for right and center alignment
Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What I'd like to emphasize here is that, whether padding is enabled or disabled, a Markdown separator header must consist of at least 3 characters.

Suggested change
# columns in a header separator row must have at least one dash
# using a minimum of three accounts for right and center alignment
# Columns in a header separator row must contain three or more characters;
# valid examples include (---, --:, :-:).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants