A regular Python print statement might look like this (Dart printing looks similar to this):

print(a_number) # for a number
print(a_string) # for a string

These print statements can accept arbitrary values without type specification.

In C using printf, a print statement might look like this:

printf("%d", a_number); // for a number
printf("%s\n", a_string.c_str()); // for a string

This one can't, the programmer needs to specify the type.

What are the main differences between designing a print function similar to Python's print() as opposed to C's printf()?

  • 5
    $\begingroup$ Not my downvotes, but they could be caused by the inappropriate use of "C++" when what is really meant is "C", and by using a non-equivalent Python example instead of print(f'{a_number}'). $\endgroup$ Jun 25, 2023 at 1:38
  • 3
    $\begingroup$ Changing print(f'{x}') from print(x) significantly changed the question. Those are two entirely separate printing modes $\endgroup$
    – mousetail
    Jun 25, 2023 at 6:05
  • 2
    $\begingroup$ After the edit applying Ray's comment, the question has pivoted to more about string formatting than printing. $\endgroup$
    – Michael Homer
    Jun 25, 2023 at 6:06
  • $\begingroup$ @MichaelHomer, it's not obvious exactly what the question is asking about. The two examples illustrate printing where the function determines the type of the arguments and where the caller specifies the type. Is that what the fundamental question is about, the ability to print an arbitrary object without having to specify its type? If so, the answer is that C doesn't do it because it isn't possible to do it. If not, what exactly is the characteristic that is meant by "C-style" and "Python-style"? $\endgroup$ Jun 25, 2023 at 12:53
  • $\begingroup$ @RayButterworth Yes, there is a meta post about this question, in case you haven’t seen it. $\endgroup$
    – Michael Homer
    Jun 25, 2023 at 20:01

3 Answers 3


It's mainly related to the basics of the type system, but sometimes related to other considerations on the philosophy of the language.

print with arbitrary values

Some languages have a print function that accepts arbitrary values. Others need the program to explicitly convert data to a string. What makes the difference is whether the language makes it possible to infer how to convert the data with some default conversion mechanism (e.g. integers printed in decimal, lists printed as something like the language's list constructor syntax, etc.).

In a dynamically typed language like Python, it's easy. All values have runtime type information, so the printing function can use that to determine how to print the argument.

In statically typed languages, there typically isn't enough information at runtime to find a sensible way to convert a value's representation to a string. For example, a word in memory could contain an integer or a float or a pointer and there's no way to find out which. So any automatic conversion to string has to follow some rules at compile time, where the compiler generates the correct formatting function based on the argument's static type.

C has no such mechanism. C is a low-level language which gives the programmer a lot of control. If you want to print an integer, you have to specify whether you want it in decimal, hexadecimal or octal. If you want to print a floating-point value, you have to specify how many digits of precision. This philosophy is prevalent in C, so the design of the language doesn't include any mechanism for selecting between different implementations of a function based on the argument type. (From C11 onwards there is such a mechanism, but it's restricted to selecting between floating point types for a few built-in functions.)

Many statically typed languages have an overloading mechanism that allows the selection of different implementations of a function based on the argument's type. For example, in C++, the << operator selects between different printing functions based on the type of its right-hand argument, so you can write cout << 1, cout << 1.5, cout << "hello", etc. (And << even selects between being a printing function and a bitwise operator, based on the type of its left-hand argument.) This is a compile-time mechanism: the compiler knows that there are many << functions, each with their type. In Haskell, this is the Show type class, with an instance for each type or type constructor for which a printing mechanism exists.

printf with a template

Almost all general-purpose languages have function that's similar to C's sprintf, often with a similar template syntax. They may or may not have a function that's similar to printf, combining the string templating with printing: when combining a string-printing function with a template formatting function is simple enough, there's no need for a function that does both.

For example, in Python, the equivalent of C's sprintf is the % operator, which uses a printf-like template syntax. This templating mechanism from the original version of the language is somewhat deprecated in modern Python in favor of a different template syntax that is accessible via the format method on the template string; the syntax is different, but the core principle is the same. Python only has a sprintf equivalent, not a printf equivalent, because there wouldn't be much point: it's almost as easy to write print(template % (arg1, arg2)) or print(template.format(arg1, arg2)) as it would be to write print(template, arg1, arg2).

Having separate functions requires constructing the resulting string in memory. In C, that's a big deal: you have to allocate enough memory, and C gives you a choice of allocators: you can use a global buffer, or a buffer on the stack, or a buffer allocated by malloc, or a buffer allocated by some custom allocator. So it's convenient to have a function that can directly print out the data piece by piece. In a high-level language like Python, the allocation is done entirely under the hood and allocating a string in memory is not considered a big deal.

The main reason some general-purpose don't have a printf or sprintf-like function is that it's hard to fit into a static type system. You have to match the content of the template string with the types of the other arguments, and even with the number of other arguments. In C, that's not a problem because the type system is very far from sound. It's the responsibility of the programmer to pass the correct number of arguments with the correct types. In dynamically typed languages, that's not a problem because the templating function can check argument types at runtime.

Many statically typed languages arrange some printf-like mechanism anyway, with various degree of “compiler magic”, i.e. you couldn't implement printf as a library function. For example, Pascal has special handling for some functions like write which accept multiple argument types and even a field width formatting syntax. You can write write('x=', x:3) but you can't make your own function that accepts a variable number of arguments, or that takes the extra width annotation :3. In Ocaml, the printf mechanism requires the template to be a string literal, which the compiler parses to deduce the expected type of the argument list: printf itself has a special type for which you can't build values normally, but sprintf "x=%3" has the type int -> string.

Haskell's type classes (a very fancy overloading mechanism) are powerful enough to define a printf function in the base library, but it requires runtime validation of the template against its type. The types of the arguments determine the type class of the template, which determines the implementation of the template-to-string conversion. The template-to-string conversion uses the template string to determine exactly what must be printed, but needs to validate that it matches the expected types for the arguments. For example, printf template 1 results in code that knows that it needs to format one integer, and will accept x=%3d as a template but not x=%s or x=%3d, y=%3d.


There is a price you need to pay for print to look like it does in python. Ask yourself if it is an acceptable price that fits well into your balance of goals and compromises.

The price is one of the following:

  • Dynamic type system with a runtime dispatch. With all the consequences - boxed values all over, limited static analysis availability, runtime overhead.
  • Function/method overloading (like in C++) - you no longer know what is the exact type of function arguments by looking at it. With an IDE with type hints you would not care, but not all languages have IDE integration ready, especially true for the small DSLs / amateur or toy languages. Also, presence of overloading may mess up badly with certain type systems (HM can handle it, but also at some extra cost).
  • Typed macro metaprogramming (e.g., as in Rust) - in my book, by far the preferable choice, but there is a lot of people with irrational fear of macros, and you're going to alienate them if you bake macros into such a core functionality of your standard library.
  • 2
    $\begingroup$ There is a fourth option which is special-casing the print function in the compiler. So "officially" it can be a varargs function which accepts any sequence of arguments, but the compiler recognises static calls and compiles them the way Rust does. I don't know if any language does this with printing, but Java has something similar to support optimised concatenations with more than operands (see JEP 280). Java's approach leaves it to the runtime to generate a concatenation method with the appropriate signature, though. $\endgroup$
    – kaya3
    Jun 25, 2023 at 15:42
  • $\begingroup$ @kaya3-supportthestrike - indeed, thanks for reminding. Although I believe the language should either not allow such things, or allow them to be user-defined. $\endgroup$
    – SK-logic
    Jun 25, 2023 at 16:01
  • 1
    $\begingroup$ @kaya3-supportthestrike Pascal (or at least many Pascal dialects, I don't remember if that was in the original) has a write function that accepts both number and string arguments. You can't define such a function yourself. $\endgroup$ Jun 25, 2023 at 18:30
  • $\begingroup$ Java just accepts an Object in its function, and just calls toString on it $\endgroup$
    – Seggan
    Jun 26, 2023 at 13:55
  • $\begingroup$ @Seggan-OnStrike which is also a polymorphysm, same as function overloading, with all the same potential drawbacks (perceived or real). $\endgroup$
    – SK-logic
    Jun 26, 2023 at 14:08

That's not C++ style, C++ style looks like this:

std::cout << 0.5f << std::endl;

That said, what you call "C++ style" is actually also available in Python:

string_formatted = '%d %f %s' % (2, 2.0, 'hello')

The main difference between both styles is that with the values passed directly to the print function it's harder to provide formatting directives, for example with string formatting you can do '%.2f' % (2.0) for '2.0' or '%.5f' % (2.0) for '2.00000'. That's not to say it's impossible, real C++ style with std::cout for example uses modifiers that give state to the output stream for formatting numbers and such:

#include <iostream>
#include <iomanip>

int main()
    double d = 122.345;

    std::cout << std::fixed;
    std::cout << std::setprecision(2);
    std::cout << d;

gives you 122.34.

As for implementation, both sorts of function need some sort of variable-argument support, but with a caveat. While C-Style string formatting requires you to parse the formatted string, in exchange you get hints on the kinds of arguments you'll be pulling. In C's implementation of variable arguments it's not possible to receive an argument you don't know the type of (you'd need some sort of tagged union), so Python's style of printing function would be very inconvenient to implement.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .