A good measure of the complexity of a system is the length of its documentation. That is, assuming that the documentation is of good
quality, and for Python I think it is.

I decided to do a quick count of the length, by using WeasyPrint to
convert the HTML pages to PDF files, and totalling up the number of
PDF pages generated.

For Python 3.14 (still the default on Debian Unstable as of this
writing), the main language documentation is divided into 3 parts: the
core language, the builtins, and the standard library.

For the core language (files
/usr/share/doc/python3.14/html/reference/*.html), I counted 271 pages
total.

For the builtins (files
/usr/share/doc/python3.14/html/builtins/*.html), I counted 218 pages
total.

These counts might be slight overestimates. I saw a couple of extra
pages with no body text in one or two PDF files, and also the default
font seemed a bit large.

For comparison, the Java 21 language spec, already provided as a PDF
file, totals 872 pages. Note this is just the core language, not even
including the java.lang package (the equivalent of Python?s builtins).

This confirms the point, that Python is a much simpler language than
Java. And yet it does this without compromising on power: Python
manages to include niceties like multiple inheritance and operator
overloads, which Java had to leave out.

I also did a count of the standard library (files /usr/share/doc/python3.14/html/library/*.html); this consisted of 323
separate HTML files, totalling 3915 formatted pages. It took nearly 20
minutes to format and count all these.

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Fri, 30 Oct 2026 04:25:56 -0000 (UTC), I wrote:

I decided to do a quick count of the length, by using WeasyPrint to
convert the HTML pages to PDF files, and totalling up the number of
PDF pages generated.

I have rerun my tests, this time adding the following simple
stylesheet to WeasyPrint:

body
{
font-size : 10pt !important;
}

For the core language (files /usr/share/doc/python3.14/html/reference/*.html), I counted 271 pages
total.

With the reduced font size, I now get a count of 204.

For the builtins (files
/usr/share/doc/python3.14/html/builtins/*.html), I counted 218 pages
total.

For this, the page count is now 168.

These counts might be slight overestimates. I saw a couple of extra
pages with no body text in one or two PDF files ...

The extra-pages issue still remains, but is probably minor.

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Lawrence D?Oliveiro wrote:

On Fri, 30 Oct 2026 04:25:56 -0000 (UTC), I wrote:

I decided to do a quick count of the length, by using WeasyPrint to
convert the HTML pages to PDF files, and totalling up the number of
PDF pages generated.

I have rerun my tests, this time adding the following simple
stylesheet to WeasyPrint:

body
{
font-size : 10pt

True dat. But the complexity of Python was always that whatever quotes everyone else was making off with, 'I'm feeling better!' 'Nobody expects
the Spanish Inquisition!' was that I always found myself somewhere else
in the Python mythos.
--
Sometimes I just feel like I need to get away
A place where I can be by myself, all alone
I kinda lay down in the back yard
Watch the leaves fall down on my face

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 30/10/2026 05.25, Lawrence D?Oliveiro wrote:
[...]

Very likely the C (not C++) documentation is a
dozen pages, maybe 30 with the libc.

What does this tell us about this metric?

bye,

--

piergiorgio

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Sun, 1 Nov 2026 10:46:03 +0100, Piergiorgio Sartor wrote:

Very likely the C (not C++) documentation is a dozen pages, maybe 30
with the libc.

Looking at the C99 spec (the publicly-available ?draft? version), the
core language part is 172 pages, including the ?Future language
directions? page. The standard library is another 400-odd pages.

I?d look at later versions, but they would be even larger.

So yes, that says C is simpler than Python, but perhaps by not as much
as you think.

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Something to consider is how much this is measuring the complexity of
the language and how much it's measuring the verbosity of the
documentation style.

Also Python's built-in types are documented in the Library Reference
rather than the Language Reference. When measuring complexity of the
core language, you should probably include the standard types section of
the Library Reference.

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Mon, 2 Nov 2026 12:38:20 +1300, Greg Ewing wrote:

Something to consider is how much this is measuring the complexity
of the language and how much it's measuring the verbosity of the documentation style.

Feel free to point out which side you think the current comparison is favouring. Frankly, I don?t think it matters much.

Also Python's built-in types are documented in the Library Reference
rather than the Language Reference.

Since 3.13, they have been separated out into their own documentation
section.

When measuring complexity of the core language, you should probably
include the standard types section of the Library Reference.

I quoted figures for both sections.

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Greg Ewing wrote:

Something to consider is how much this is measuring the complexity of
the language and how much it's measuring the verbosity of the
documentation style.

Also Python's built-in types are documented in the Library Reference
rather than the Language Reference. When measuring complexity of the
core language, you should probably include the standard types section of
the Library Reference.

What can you say about this:

Is it better to rely on AI to do the fetching for you to get your
reference materials, or is it better to go digging through the official
docs, perhaps using Edit/Find resources?

I've learned some from AI access, but I often think I would learn more
by going to the official documentation, which I do, but only on occasion.
--
Sometimes I just feel like I need to get away
A place where I can be by myself, all alone
I kinda lay down in the back yard
Watch the leaves fall down on my face

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Stefan Ram wrote:

Greg Ewing <greg.ewing@canterbury.ac.nz> wrote or quoted:

Something to consider is how much this is measuring the complexity of
the language and how much it's measuring the verbosity of the
documentation style.

The specifications of C and C++ are much more formal
with many more details than the reference for Python.

For example, this is from a recent C++ draft:

Great! Maybe the geeks from comp.lang.c with their glasses covered in
masking tape at the center of the frame can take over Python and boot
any casual users who visit this newsgroup. I look forward to being
shunned and excluded by the total fag geeks like in comp.lang.c because
the language has been around almost as long as the dinosaurs using COBOL
and FORTRAN.
--
Sometimes I just feel like I need to get away
A place where I can be by myself, all alone
I kinda lay down in the back yard
Watch the leaves fall down on my face

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2 Nov 2026 11:15:59 GMT, Stefan Ram wrote:

The specifications of C and C++ are much more formal with many more
details than the reference for Python.

Do you feel that there are details that the core Python language spec
has omitted, that should have been spelled out?

For example, this is from a recent C++ draft:

A constraint P subsumes a constraint Q if and only if, for every
disjunctive clause P_i in the disjunctive normal form of P, P_i
subsumes every conjunctive clause Q_j in the conjunctive normal
form of Q, where (1.1) - a disjunctive clause P_i subsumes a
conjunctive clause Q_j if and only if there exists an atomic
constraint P_{ia} in P_i for which there exists an atomic
constraint Q_jb in Q_j such that P_{ia} subsumes Q_{jb}, (1.2) -
an atomic constraint A subsumes another atomic constraint B if
and only if A and B are identical using the rules described in
13.5.2.3, and (1.3) - a fold expanded constraint A subsumes
another fold expanded constraint B if they are compatible for
subsumption, have the same fold-operator, and the constraint of
A subsumes that of B.

. This is not language being verbose, this is actually
specifying relevant details tersely.

I was just looking a a draft language document (N5054), and the first
15 chapters (excluding the standard library from chapter 16) are
actually less than 550 pages -- even smaller than the Java core
language spec.

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)