Skip to content

Document IMAP4.append() message type and optional arguments #149962

Description

@savagemechanic

The IMAP4.append() documentation currently says only:

Append message to named mailbox.

It now documents the flags argument, but the remaining argument behavior is still easier to discover from Lib/imaplib.py than from the library docs.

In the implementation:

  • mailbox is treated as optional in practice: a false value is replaced with 'INBOX'.
  • flags and date_time may be None, in which case they are omitted from the command.
  • message is not optional. It is passed to MapCRLF.sub(CRLF, message), where MapCRLF is a bytes regular expression, so message must be a bytes-like object. Passing a str raises TypeError before the command is sent.

The method docstring already hints at this by saying "All args except 'message' can be None", but that detail is not in Doc/library/imaplib.rst.

This is related to the broader documentation issue in #68215, but this issue is intentionally narrower: clarify the public documentation for IMAP4.append() only.

Suggested documentation scope:

  • State that message must be a bytes-like object.
  • State which arguments may be None.
  • Clarify that mailbox=None (or another false value) uses INBOX.
  • Clarify that date_time=None omits the internal date argument.

This should stay separate from the existing CR/LF-normalization behavior tracked in #49680.

Linked PRs

Activity

  1. gvanrossum commented on May 17, 2026

    @gvanrossum
    Member

    AFAIK it is okay to submit doc PRs without an Issue now.

  2. savagemechanic commented on May 17, 2026

    @savagemechanic
    ContributorAuthor

    AFAIK it is okay to submit doc PRs without an Issue now.

    Understood 👊 Thanks Guido

  3. picnixz commented on May 19, 2026

    @picnixz
    Member

    While it is ok not to create issues most of the time, it is also good for tracking discussions if any (like, if the docs are changed or reorganized, having an issue is good; if it is only for improving, amending slightly, or fixing inconsistencies or incompleteness, no issue is needed).

    (In this case, there was no need for an issue but since one was created, we can keep it)

  4. savagemechanic commented on May 20, 2026

    @savagemechanic
    ContributorAuthor

    Thank you for taking your time to break that down for me :-)

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions