Mailing List Archive

Hi,

On Tue, Sep 22, 2020 at 11:25 PM <yehudisgru@gmail.com> wrote:
>
> Hi,
>
>
>
> I installed Python 3.8.5 on Windows 10
>
> When I click on a python file it launches the program but it closes
> immediately.

What is the content of this file?
Is it a py or pyc file?

Thank you.

>
>
>
> Please help, thanks.
>
>
>
> Yehudis Gruber
>
>
>
>
> --
> https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list

On 9/22/2020 11:54 PM, yehudisgru@gmail.com wrote:

> I installed Python 3.8.5 on Windows 10
> When I click on a python file it launches the program but it closes
> immediately.

When you run a program that way, the console/terminal window closes when
the program finishes executing.


--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

It’s a py file with simple python code

 

From: [1]Igor Korot
Sent: Wednesday, September 23, 2020 12:39 AM
To: [2]yehudisgru@gmail.com
Cc: [3]python-list@python.org
Subject: Re: Python 3.8.5 Not Launching

 

Hi,

 

On Tue, Sep 22, 2020 at 11:25 PM <yehudisgru@gmail.com> wrote:

> 

>    Hi,

> 

> 

> 

>    I installed Python 3.8.5 on Windows 10

> 

>    When I click on a python file it launches the program but it closes

>    immediately.

 

What is the content of this file?

Is it a py or pyc file?

 

Thank you.

 

> 

> 

> 

>    Please help, thanks.

> 

> 

> 

>    Yehudis Gruber

> 

> 

> 

> 

> --

> https://mail.python.org/mailman/listinfo/python-list

 

References

Visible links
1. mailto:ikorot01@gmail.com
2. mailto:yehudisgru@gmail.com
3. mailto:python-list@python.org
--
https://mail.python.org/mailman/listinfo/python-list

On 9/23/20, yehudisgru@gmail.com <yehudisgru@gmail.com> wrote:
> It’s a py file with simple python code

If .py files are associated with py.exe or python.exe, then running a
.py script either inherits or allocates a console and attaches to it.
The console closes automatically as soon as the last reference to it
closes. If you need the console to remain open, then it should be
inherited from the parent process. Typically that's a shell such as
CMD or PowerShell, but any process can manually allocate an
inheritable console via WinAPI AllocConsole.

To run a script from a shell command line, simply enter
"path\to\some_script.py". If the script is in a PATH directory and .PY
is in PATHEXT, then you can simply run "some_script" in CMD or
PowerShell.
--
https://mail.python.org/mailman/listinfo/python-list

Eryk Sun wrote:

> If .py files are associated with py.exe or python.exe, then running a
> .py script either inherits or allocates a console and attaches to it.

Is it possible to determine, from within Python, whether Python
allocated or inherited the console? This could be useful to know in a
(global) error trap: to be able to see a traceback, the console must
remain open, which won't happen if Python allocated the console itself.

Regards,
Gertjan.
--
https://mail.python.org/mailman/listinfo/python-list

On Fri, Oct 2, 2020 at 7:51 PM Gertjan Klein <gklein@xs4all.nl> wrote:
>
> Eryk Sun wrote:
>
> > If .py files are associated with py.exe or python.exe, then running a
> > .py script either inherits or allocates a console and attaches to it.
>
> Is it possible to determine, from within Python, whether Python
> allocated or inherited the console? This could be useful to know in a
> (global) error trap: to be able to see a traceback, the console must
> remain open, which won't happen if Python allocated the console itself.
>

It might be possible, but then there'd have to be lots of magic and
the result would be a different set of complaints ("sometimes I get a
black window, other times it just disappears"). Instead of trying to
detect and such, maybe there needs to be a standard recommendation for
an atexit or something - advise people to "stick this line at the top
of your program so the black window stays around". No magic, and
completely consistent.

ChrisA
--
https://mail.python.org/mailman/listinfo/python-list

On 10/2/20, Gertjan Klein <gklein@xs4all.nl> wrote:
> Eryk Sun wrote:
>
>> If .py files are associated with py.exe or python.exe, then running a
>> .py script either inherits or allocates a console and attaches to it.
>
> Is it possible to determine, from within Python, whether Python
> allocated or inherited the console?

If a console session isn't headless (i.e. it's not a pseudoconsole)
and has a window (i.e. not allocated with CREATE_NO_WINDOW), then the
effective owner of the window is initially the process that allocated
the console session, as long as it's still running and attached. For
example, with "python.exe" (not a launcher) executed from Explorer:

>>> hwnd = win32console.GetConsoleWindow()
>>> tid, pid = win32process.GetWindowThreadProcessId(hwnd)
>>> pid == os.getpid()
True

A problem is the case of a launcher such as "py.exe", or the
"python.exe" launcher used by venv virtual environments. A venv
launcher can be detected by comparing sys.executable with
sys._base_executable. For example, with a venv launcher executed from
Explorer:

>>> hwnd = win32console.GetConsoleWindow()
>>> tid, pid = win32process.GetWindowThreadProcessId(hwnd)

The current process doesn't own the console, but the parent does:

>>> pid == os.getpid()
False
>>> pid == os.getppid()
True

Check whether the parent is a venv launcher:

>>> print(sys.executable)
C:\Temp\env\test38\Scripts\python.exe
>>> print(sys._base_executable)
C:\Program Files\Python38\python.exe

Double check that the parent is the venv launcher:

>>> access = win32con.PROCESS_QUERY_LIMITED_INFORMATION
>>> hproc = win32api.OpenProcess(access, False, pid)
>>> executable = win32process.GetModuleFileNameEx(hproc, None)
>>> os.path.samefile(executable, sys.executable)
True
--
https://mail.python.org/mailman/listinfo/python-list

Eryk Sun schreef:
> On 10/2/20, Gertjan Klein <gklein@xs4all.nl> wrote:
>> Is it possible to determine, from within Python, whether Python
>> allocated or inherited the console?
>
> If a console session isn't headless (i.e. it's not a pseudoconsole)
> and has a window (i.e. not allocated with CREATE_NO_WINDOW), then the
> effective owner of the window is initially the process that allocated
> the console session, as long as it's still running and attached. For
> example, with "python.exe" (not a launcher) executed from Explorer:
>
> >>> hwnd = win32console.GetConsoleWindow()
> >>> tid, pid = win32process.GetWindowThreadProcessId(hwnd)
> >>> pid == os.getpid()
> True

I can't replicate this. I installed pywin32 in a Python 3.8 virtual
environment, and double-clicked on the venv\Scripts\python.exe in explorer:

Python 3.8.6 (tags/v3.8.6:db45529, Sep 23 2020, 15:52:53) [MSC v.1927 64
bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import os, win32console, win32process
>>> hwnd = win32console.GetConsoleWindow()
>>> tid, pid = win32process.GetWindowThreadProcessId(hwnd)
>>> pid == os.getpid()
False

I tried to find out what happens, using your other code:

>>> import win32con, win32api
>>> access = win32con.PROCESS_QUERY_LIMITED_INFORMATION
>>> hproc = win32api.OpenProcess(access, False, pid)
>>> executable = win32process.GetModuleFileNameEx(hproc, None)
>>> print(executable)
C:\Temp\Python\Console\venv\Scripts\python.exe
>>> hproc = win32api.OpenProcess(access, False, os.getpid())
>>> win32process.GetModuleFileNameEx(hproc, None)
'C:\\dev\\Python\\Python38\\python.exe'

So, if I understand this correctly, the console is owned by the venv
Python, but the running process is the installed Python executable. I'm
lost! How did that latter one get involved?

Regards,
Gertjan.
--
https://mail.python.org/mailman/listinfo/python-list

Chris Angelico schreef:
> On Fri, Oct 2, 2020 at 7:51 PM Gertjan Klein <gklein@xs4all.nl> wrote:
>>
>> Is it possible to determine, from within Python, whether Python
>> allocated or inherited the console? This could be useful to know in a
>> (global) error trap: to be able to see a traceback, the console must
>> remain open, which won't happen if Python allocated the console itself.
>
> It might be possible, but then there'd have to be lots of magic and
> the result would be a different set of complaints ("sometimes I get a
> black window, other times it just disappears").

That sounds a bit dismissive. Who would do that complaining? I would
like to be able to do this for scripts I write for myself. If these
scripts have something to tell me, they should make sure I get to see
that. If they don't, the console can disappear (if started from
explorer). I can do this with "input('Press enter when done')" easily;
however, if I start the script from a console window I get to press
enter too, needlessly.

> Instead of trying to
> detect and such, maybe there needs to be a standard recommendation for
> an atexit or something - advise people to "stick this line at the top
> of your program so the black window stays around". No magic, and
> completely consistent.

I specifically asked for the opposite of consistency.

Regards,
Gertjan.
--
https://mail.python.org/mailman/listinfo/python-list

On 10/3/20, Gertjan Klein <gklein@xs4all.nl> wrote:
>
> I tried to find out what happens, using your other code:
>
> >>> import win32con, win32api
> >>> access = win32con.PROCESS_QUERY_LIMITED_INFORMATION
> >>> hproc = win32api.OpenProcess(access, False, pid)
> >>> executable = win32process.GetModuleFileNameEx(hproc, None)
> >>> print(executable)
> C:\Temp\Python\Console\venv\Scripts\python.exe
> >>> hproc = win32api.OpenProcess(access, False, os.getpid())
> >>> win32process.GetModuleFileNameEx(hproc, None)
> 'C:\\dev\\Python\\Python38\\python.exe'
>
> So, if I understand this correctly, the console is owned by the venv
> Python, but the running process is the installed Python executable. I'm
> lost! How did that latter one get involved?

In Windows, venv defaults to copying binaries instead of creating
symlinks. Starting with 3.7.2, venv copies a python.exe launcher (a
custom build of the py.exe launcher) instead of copying the base
executable and DLLs [1]. The launcher finds and spawns the base
python.exe, and waits for it to exit. If you run the launcher from
Explorer, it's the launcher that allocates and owns the console
session. The base python.exe inherits the console session.

The primary benefit of copying a launcher is that existing virtual
environments don't have to be updated or recreated when the base
installation is updated. The primary downside is that the parent
process has a handle for and PID of the launcher process instead of
the base Python process. This causes problems if the parent tries to
manually duplicate a handle to the child, or vice versa, since it's
actually duplicating the handle to the launcher process.

This is particularly a problem for the multiprocessing module. It has
to detect whether it's in a launcher-based virtual environment by
comparing sys.executable with sys._base_executable. If they're
different files, it executes sys._base_executable and sets the child's
"__PYVENV_LAUNCHER__" environment variable to sys.executable (the venv
launcher) in order to make it use the virtual environment.

[1] https://docs.python.org/3.7/whatsnew/3.7.html#notable-changes-in-python-3-7-2
--
https://mail.python.org/mailman/listinfo/python-list