Skip to content

gh-143754: Use neutral terminology in tkinter documentation #143779

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
VanshAgarwal24036 wants to merge 2 commits into
base: main
Choose a base branch
from
+7 −7
Open

gh-143754: Use neutral terminology in tkinter documentation #143779

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
f50a321
Use neutral parent/child terminology in tkinter documentation
VanshAgarwal24036 Jan 13, 2026
b630d3f
Refine tkinter terminology per review feedback
VanshAgarwal24036 Jan 14, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 7 additions & 7 deletions Doc/library/tkinter.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -179,10 +179,10 @@ the modern themed widget set and API::
The widget object that contains this widget. For :class:`Tk`, the
*master* is :const:`None` because it is the main window. The terms
*master* and *parent* are similar and sometimes used interchangeably
as argument names; however, calling :meth:`winfo_parent` returns a
as argument names; however, calling ``winfo_parent`` returns a
string of the widget name whereas :attr:`master` returns the object.
*parent*/*child* reflects the tree-like relationship while
*master*/*slave* reflects the container structure.
*master*/*child widget* reflects the container structure.

.. attribute:: children

Expand Down Expand Up @@ -644,8 +644,8 @@ used less commonly, and we do not cover here), the packer takes qualitative
relationship specification - *above*, *to the left of*, *filling*, etc - and
works everything out to determine the exact placement coordinates for you.

The size of any *master* widget is determined by the size of the "slave widgets"
inside. The packer is used to control where slave widgets appear inside the
The size of any *parent* widget is determined by the size of the "child widgets"
inside. The packer is used to control where child widgets appear inside the
master into which they are packed. You can pack widgets into frames, and frames
into other frames, in order to achieve the kind of layout you desire.
Additionally, the arrangement is dynamically adjusted to accommodate incremental
Expand Down Expand Up @@ -673,7 +673,7 @@ For more extensive information on the packer and the options that it can take,
see the man pages and page 183 of John Ousterhout's book.

anchor
Anchor type. Denotes where the packer is to place each slave in its parcel.
Anchor type. Denotes where the packer is to place each child in its parcel.

expand
Boolean, ``0`` or ``1``.
Expand All @@ -682,10 +682,10 @@ fill
Legal values: ``'x'``, ``'y'``, ``'both'``, ``'none'``.

ipadx and ipady
A distance - designating internal padding on each side of the slave widget.
A distance - designating internal padding on each side of the child widget.

padx and pady
A distance - designating external padding on each side of the slave widget.
A distance - designating external padding on each side of the child widget.

side
Legal values are: ``'left'``, ``'right'``, ``'top'``, ``'bottom'``.
Expand Down
Loading