0

I use notepad++ to write my python code, and when I put in this code for a basic calculator:

However, after the input calls are over, it auto-closes the console window, supposedly because it finishes the rest of the calculations extremely quickly, but how do I stop it from closing?`I use notepad++ to write my python code, and when I put in this code for a basic calculator:

num1 = input("Enter a number")
num2 = input("Enter another number")
result = float(num1) + float(num2)

print(result)

However, after the input calls are over, it auto-closes the console window, supposedly because it finishes the rest of the calculations extremely quickly, but how do I stop it from closing?

azro
  • 53,056
  • 7
  • 34
  • 70
Codedcoder
  • 1
  • 3
    Does this answer your question? [How to keep a Python script output window open?](https://stackoverflow.com/questions/1000900/how-to-keep-a-python-script-output-window-open) – CodeAllDay Nov 28 '20 at 10:35
  • The problem isn’t Python, it’s Notepad++. I’m extremely surprised that Notepad++ has such a glaring bug, but from a quick search this indeed seems to be the case. So the solution is: use a proper editor. – Konrad Rudolph Nov 28 '20 at 10:38
  • 2
    @KonradRudolph Umm.. No? If you ran this Python script standalone the exact same thing would happen - thats just how python works. Once its finished it closes the window. The has absolutely nothing to do with Notepad++, given that the program simply runs the standard python command anyway. – dwb Nov 28 '20 at 10:42
  • @dantechguy No, Python does none of these things. The behaviour is due to cmd.exe, not due to Python. If you run the Python script standalone *inside a regular terminal* it works. And that’s how command-line applications are supposed to be run. If you want to run an application that opens an interactive window by double-clicking, and keeps it open, don’t write a command-line application; write a GUI application. – Konrad Rudolph Nov 28 '20 at 10:46
  • @KonradRudolph Here's an [Official Python page](https://wiki.python.org/moin/Asking%20for%20Help/How%20come%20when%20I%20double%20click%20on%20a%20.py%20a%20black%20thing%20flashes%20and%20then%20disappears%3F%20And%20what/where%20exactly%20is%20the%20%27Python%20Interpreter%27%3F) describing the exact situation above. I completely agree, what you've described *is* how command line applications should be run. But in cases like this, I feel its more helpful to answer the user's question in an accessible way, over a 100% technically correct one. – dwb Nov 28 '20 at 10:54
  • @dantechguy Not sure what your link is supposed to show me, because it completely agrees with what I said. Regarding what is most helpful for OP, I fundamentally disagree that teaching hacks (without *at least* explaining precisely why they’re hacks) is helpful, because it teaches the OP to write code that is wrong. Now, what would *actually* be helpful is if NP++ fixed this behaviour … but in the context of this discussion I believe the most helpful advice for OP is this: **yes, this is a known, common limitation; using a better editor fixes the problem.** – Konrad Rudolph Nov 28 '20 at 10:59
  • @KonradRudolph Fair enough, guess we'll have to agree to disagree haha! ;D – dwb Nov 28 '20 at 11:10

2 Answers2

0

You can have an input function at the end of the file. Then it'll halt until the user presses enter.

num1 = input("Enter a number")
num2 = input("Enter another number")
result = float(num1) + float(num2)

print(result)
input('Press the Enter key to exit...')
Ted Klein Bergman
  • 9,146
  • 4
  • 29
  • 50
  • 1
    That’s a terrible solution. The issue isn’t with Python, it’s the editor. This hack breaks the code’s correct behaviour to work around a bug in the editor. – Konrad Rudolph Nov 28 '20 at 10:37
  • @KonradRudolph Why would this be a bug with Notepad++? Notepad++ simply executes the Python scripts, and if you execute the Python script the console will close immediately. Other editor may execute the script in terminal, etc., but that's just a different way of doing things, not a broken way. – Holt Nov 28 '20 at 10:41
  • @Holt Because Notepad++ purports to be an IDE with built-in support for executing command-line applications. If it fails to keep the console open after the application has terminated, that’s a bug. Of course the real issue is that cmd.exe is idiotic. But this is known, and if an editor wants to use it productively, it simply *has* to account for that fact. – Konrad Rudolph Nov 28 '20 at 10:41
  • No, it's not a problem with the editor. The editor is not a part of a running program. I've done something similar when running C++ code in Visual Studio as well. – Ted Klein Bergman Nov 28 '20 at 10:41
  • @TedKleinBergman Just because other programs have the same issue (even extremely big ones, like VS) doesn’t make this less of a problem of the editor. The behaviour of cmd.exe is well-known. NP++ can’t just say “so what?” and ignore that. Anyway, VS at least *does* work around this issue (= running the application in debug mode). – Konrad Rudolph Nov 28 '20 at 10:43
  • @KonradRudolph It supports console application, it runs them, the way they are meant to be run outside of the IDE. VS has the exact same behavior will C++ console application. If your application works differently within your IDE and outside, maybe it's that kind of IDE that's broken. You're going to ship the application and no one is going to be able to use it because they don't use your IDE. – Holt Nov 28 '20 at 10:43
  • @Holt ?! The *program* doesn’t work differently, it behaves exactly the same. The IDE just needs to keep the *terminal* open. — *Obviously*. I can’t believe we’re even debating this. In fact, it’s exactly the other way round: what you’re describing applies to the hack described in this answer: it makes the application work OK in the IDE, but it breaks it in real usage inside a regular terminal, where an application *should not* wait for user input before terminating. – Konrad Rudolph Nov 28 '20 at 10:45
  • @KonradRudolph Not at all. If you double-click the Python file in Windows (well, run it with Python), the program will open and close immediately after the `print` since it's Python executable behavior. You might be used to running the program from a terminal, but that's not what users of your program might be used to. – Holt Nov 28 '20 at 10:46
  • @KonradRudolph I understand your concern, but I ultimately disagree for what the OP is asking for. It's not the IDE's purpose to keep the terminal open (in this specific case). Consider a executable. A user won't run the program in an IDE. The OP wants the program to stay open until the user decide to close it and this does exactly that. If they want it to stay open *for debugging purposes*, then I agree with you. But to me it seems like they want it as a part of the program. – Ted Klein Bergman Nov 28 '20 at 10:47
  • @Holt The solution to that is easy: don’t conflate command line and GUI applications. They’re different things. If you want to write an application that is opened by double-clicking and keeps a window open interactively, write a GUI application (that’s *literally* what this is!), don’t write a console application. Windows treats these two types of applications fundamentally different, you can’t just ignore that difference. And if you want to have a terminal inside your GUI application, [you can still do that](https://learn.microsoft.com/en-us/windows/console/allocconsole). – Konrad Rudolph Nov 28 '20 at 10:50
  • @TedKleinBergman “It's not the IDE's purpose to keep the terminal open” — Yes, is unambiguously is, and good IDEs do that. There’s really nothing that merits a technical debate here. NP++ does this wrong, and working around the problem by introducing hacks into the program source is the wrong solution. Good IDEs do this correctly (yes, even VS, see above). – Konrad Rudolph Nov 28 '20 at 10:51
  • @KonradRudolph VS does not do it in Release mode. NP++ is not an IDE and never claimed to be one. – Holt Nov 28 '20 at 10:53
  • @Holt Whether NP++ claims to be an IDE or not is really *completely* irrelevant here. It provides this feature, but badly. And I can’t say why VS behaves the way it does in release mode, all I can say that this feature was already annoying — and considered a bug! — 20 years ago. The fact that VS does this wrong too is really not an argument that this behaviour is correct, because it simply isn’t. Other editors/IDEs (e.g. VS Code) do *not* do this wrongly. – Konrad Rudolph Nov 28 '20 at 10:55
  • @KonradRudolph NP++ never claims the feature. It has a "run" button which runs an external command. OP probably has the default application for `.py` sets as Python so it runs Python. If you really want to help OP, maybe tell them what's actually happening, why they should not run program like this through NP++, or whatever. Saying "It's a NP++ bug, use something else." is irrelevant and not helpful. – Holt Nov 28 '20 at 10:58
  • @Holt Your two assertions “NP++ never claims the feature.” and “It has a "run" button which runs an external command” are in direct contradiction to each other. Can’t you see that? And saying “this is an NP++ bug” *is* helpful, because it provides direct, actionable advice to the OP: use a better program. By contrast, claiming counter-factually that this isn’t a bug is extremely *unhelpful* because it teaches OP something wrong, and makes them think that the problem is their own code. – Konrad Rudolph Nov 28 '20 at 11:00
  • @KonradRudolph Not at all. You're writing about things you never even tried... I never use NP++, but I downloaded it and tried it to see what was the OP doing. It has a "Run" button but the "Run" button opens dialog asking what program you want to Run. It does not even run the current file or whatever. People probably write bad tutorials about using this "Run" command improperly to run Python script, but that's not NP++ fault. – Holt Nov 28 '20 at 11:02
  • @Holt “You're writing about things you never even tried” — but I *have* tried it (albeit a very long time ago), found it insufficient, and stopped using it, partially because of this very problem (namely, the half-assed support for running the code currently being edited). I wish people would stop recommending NP++. Regardless of whether you call this a bug or a lacking feature, it’s simply not a good editor for programming. Hence my initial comment: do not change the code, change your editor. We’ve come full circle. – Konrad Rudolph Nov 28 '20 at 11:04
  • @KonradRudolph I never claimed NP++ to be good editor (I actually fully agree with you that people should stop recommending it to write programs). My point on your comment is that it does not tell the OP why the current behavior happens. Sure, telling people hack without explaining them is no good, but telling people to switch to another IDE without explaining to them why the previous one was not doing the same thing is not much better. Anyway, I will stop commenting here because this is going completely off-topic and not helping the OP. – Holt Nov 28 '20 at 11:10
  • I think we're talking pass each other. I'm talking about the running process. When running a script from an IDE, programmatically, or any other way, it'll start up a console. When the process exit, the console will close (on some platforms). This is often not a problem as scripts often won't visualize anything. But in OPs case it does! The program wants to **show** the result until the user wants to close it. The code in the answer does exactly that. It halts until the user wants to close it. If you only run the code in an IDE, then I agree that the IDE should keep the console up. – Ted Klein Bergman Nov 28 '20 at 11:11
  • @Ted We’re not talking past each other, we just disagree about the proper behaviour and usage of command line applications: what you’re describing is simply not the correct, conventional behaviour of a command line application. You’re describing a *GUI (or TUI) application*. Well-behaved command line applications do not stay open to display results. They write them to a file or a stream, which is captured by another application, and terminate as soon as the job is done. – Konrad Rudolph Nov 28 '20 at 11:33
  • @KonradRudolph I do agree with you that pure command line programs shouldn't halt. I was thinking of TUI, which is what I thought OP's program was supposed to be, i.e. an interactive calculator. I think I know your concern about the answer is then. I'll try, tomorrow, edit in a more thorough explanation to the answer about it. – Ted Klein Bergman Nov 28 '20 at 12:02
0

You're completely right, as soon as Python finishes it sees no need to keep the console window open, so the trick is to make it keep doing something. That way it hasn't "finished", and won't close.

If you add

input()

to the last line of your program, Python will wait until you press Enter, therefore keeping the console window open until you're ready :)

dwb
  • 2,136
  • 13
  • 27
  • 1
    That’s a terrible solution. The issue isn’t with Python, it’s the editor. This hack breaks the code’s correct behaviour to work around a bug in the editor. – Konrad Rudolph Nov 28 '20 at 10:37