Your proposal would break likely a majority of all Python programs ever written, simply to avoid typing print(x, end='') (because flush=False is the default for print already.)
To get pedantic, Rust has macros for print! and println!, but neither of them are functions. They basically just get translated[1] into the Rust equivalent of print(..., end="") and print(...).
If Python were to grow a macro syntax[2], itād be easy to define such macros. But the print() function definitely canāt change this behavior because it would break the world, as @TomRitchford said.
@TomRitchford, It would actually break any library that uses the print function. A bit like when Python 2 went to Python 3 with the transition from Keyword to a function ā¦
But as in Python 2, if there was a form that encapsulates the two new functions, it would not break anything.
from __future__ import new_print_function
print("message")
println("message")
@Paddy3118, I would say that my proposal was for a improvement and not for a previous, which among other things, in Python already exists. printf is a function of the C language that translates a formatting into a string in stdout. This, the current print function already provides for it:
Having said that, I apologize if I seemed not very accurate and precise in the proposal. It is not a lack of knowledge, but I only wrote in a hurry on my cell phone after a lunch.
I believe that the changes, albeit painful, can sometimes benefit even if they seem superficial. Thank you all for your precious ideas.
Integrating this into Python is a complete non-starter, because it would be a breaking change for an overwhelmingly large percentage of existing code (possibly requiring fixes in many places - or else a similar aliasing back the other way around!).
Python long precedes all the other languages you cite, and has no reason to be beholden to design decisions made by other people/groups later on. Pythonās assumption is that people will usually want a blank line after output to a terminal, so thatās the default. Aside from that, if readability is the goal, why abbreviate line?
I apologize in advance. I donāt think I forced anyone to choose anything. Personally, I have 15 years of Python development under my belt and in the last 5 I have tried and used Rust and Go. I donāt want to compare features, but some are more convenient than others, like the two features I mentioned.
I can understand any disagreement and thoughts contrary to mine, but I think Iām in a discussion site where a person can feel free to express themselves without having to feel the weight of the obligation to think like the masses.
I apologize again if my proposal was understood as a stance, but it was intended to be a comparative idea, with no obligation towards anyone, least of all towards the Python community, of which I have been part of for years and which I respect infinitely, as the language itself.
As I said in response to @TomRitchford , I accept a negative will given the massive change in the code.
I donāt think thereās much to apologise for here. And I donāt think
readers have been offended (my subjective impression).
But Python is backward compatible - the 2->3 transition was the place
for breaking changes. As youāre clearly aware anyway
A suggestion for print, like anything already present, can extend its
features but not change them, because such a change would break
everyoneās existing code.
Thereās also the notion that ānot every one-line function needs to be in
the stdlibā.
Plenty of us keep personal utility libraries with things weād like.
Nothing prevents you making a little eg mateo.util module with
convenient print() wrapper functions with your preferred names. Just
import them!
No apology needed! The reactions youāre seeing are not about yourself or the tone of the messages, but about the idea in itself. Itās not easy to change Python, especially the language, because of multiple concerns:
not making the language too big
preserving a certain design consistency
preserving backward compatibility
etc
Ideas are easy, but serious proposals need a bit more: the proposer needs to make the case about how the new thing would work, what it would improve (new use cases, better clarity for some code patterns, elimination of possible bugsā¦), how it fits with other Python features, whether it breaks compatibility, how to teach itā¦
In your message in this thread, you have shown examples of other languages, but did not make a case for why it would be better for Python to have two functions instead of one.
Then people have pointed out that changing default behaviour of print is excluded, which means the idea should be adapted.
One possible argument could be: itās better to have two clear names than one function with a boolean parameter.
This is a design insight that fits with Python! (I think I read GvR saying that)
Then people could reply with their thoughts about whether end is a parameter thatās important enough to split print in two. This would be a true idea discussion, more fruitful than Ā«this other language has thisĀ».
As others have noted, print by default is the proposed āprintlnā. Not said is that perhaps 95% of print uses keep the final newline. So I think it a waste for other languages to use the longer and slightly harder to type word for the overwhelmingly most common use. Besides which, people writing test blocks, rather than lines, to files can use file.write(chars).
).