Hi friends 
,
I’ve comed up with the idea on a new built-in:
intput(), which is the shortened variation of int(input()). I believe this shortcut would help many beginner-programmers since the INCREABLE use of int(input()) among them.
Python has many shortcuts, and intput() should be one of them. I’d really appreciate to hear your thoughts on this.
Help intput() To Get To The Next Python’s Version!
Thank you 
Can you name examples of existing such shortcuts?
For shortcuts, take for example the default parameters; *args; **kwargs; list-comprehension; enumerate(); zip(a,b) and ect.
The idea of combining the int(input()) to intput() is explaining itself, clear and easy to use. Hence, I’d like you to vote for the idea!
The Zen of Python states
There should be one-- and preferably only one --obvious way to do it.
The examples you gave were added to the language / standard library in order to allow for expressive code, not as mere shortcuts for other code.
Your proposal – it actually took my two times to see the additional t in intput – is not helpful for writing expressive code by lumping together two functions into one. Sorry, that won’t fly
With that, I could see a valid argument for adding an optional parameter of a factory to input:
x: int = input('How old are you?', factory=int)
And having it run the text through the factory. I personally don’t think I would use that because I don’t trust user input and want to validate it before I actually run any computations on it. At the very least I would want to either make sure it’s numeric or wrap it in the appropriate try/except. But I think this would be both in the spirit of the Zen of Python and the idea itself.
I think this is the key point here. Conversion isn’t the hard part of dealing with user input. The difficult thing is validating the input and providing a good error when the input is wrong. Having a means of automatically calling int on user input (whether it’s spelled intput() or input(factory=int)) makes it easier to do the wrong thing (pass untrusted, unvalidated user input to a processing function). Convenience should never be prioritised over correctness.
It’s not as if int(input()) is hard to write, if you want fast but unsafe code…
Thanks for your interest in improving Python language! You’re welcome here.
But maybe it will be much more useful for read different topics on this forum, read a list of existing PEPs. Your current proposal seems to be unprepared and with very little real help.
Although, this doesn’t mean that some well-prepared proposal wouldn’t be accepted somewhere in the future. But it often takes a lot of work to create it. I wish you all the good luck in this journey!
I partly agree with you. I do think that the management of the input is the key in this subject, but the way of input("Message" , factory=int) NOT raising a ValueError Is more useful.
Usually, when trying to get an int from the terminal/console then we only care whether the data is in int type. Therefore, I think that errors occur during x = input("Message", factory=int) should to x : None.
I believe this improvement will make python better.
P.S, how does x = input("Message", factory=int) dealing the PEPs?
Why do you think that this is a proper mode of error handling?
As opposed to raising an exeception immediately (as int(input("...")) would do), this would usually lead wrong or unexpected results or to exceptions that are raised on different places.
Following standard naming conventions, it would be named int_input if implemented, but it wouldn’t provide any meaningful added value compared to int(input()).
I don’t think the beginner would gain over learning the composability of Python functions. When introducing input to beginners, a course mayhave many examples that use int(input(...)), but that is just the nature of that part of the course. As the beginner learns more, they find, in general, that input is usually followed by checks and data conversions not necessary for the sanitised data provided to new programmers on courses.
A closer look at int leads me to ask if your proposed intput should have a base specifier to allow octal or hex input? Should intput allow the use of underscores in a number; how about the use of commas in a number?
Beginnersneed to learn how to read, write and compose functions each with a clear focused purpose to achieve their goal. If you have functions that can parse ints, floats, and timestamps from a string; and that string could be from an input statement a database access function, or the result from running a subprocess - then that is three datatype parsers, P and three string providing functions, S. Those P + S == 6 functions can be combined in P * S == 9 ways to parse from different string providers. It is easier to learn P + Q functions and how to combine them than to learn P * Q combined functions like your intput. (especially as numbers P and Q grow); and composability is a key thing to learn in programming.