Re: Debugging technique

[Chris Angelico]

On Sat, Oct 3, 2020 at 4:53 PM Frank Millman  wrote:
>
> Hi all
>
> When debugging, I sometimes add a 'breakpoint()' to my code to examine
> various objects.
>
> However, I often want to know how I got there, so I replace the
> 'breakpoint()' with a '1/0', to force a traceback at that point. Then I
> can rerun the previous step using the extra info from the traceback.
>
> Is there a way to combine these into one step, so that, while in the
> debugger, I can find out how I got there?
>

Not sure if it's what you're looking for, but in the debugger, you can
type "bt" to show a backtrace.

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

Re: Debugging technique

[Frank Millman]

On 2020-10-03 8:58 AM, Chris Angelico wrote:

On Sat, Oct 3, 2020 at 4:53 PM Frank Millman  wrote:


Hi all

When debugging, I sometimes add a 'breakpoint()' to my code to examine
various objects.

However, I often want to know how I got there, so I replace the
'breakpoint()' with a '1/0', to force a traceback at that point. Then I
can rerun the previous step using the extra info from the traceback.

Is there a way to combine these into one step, so that, while in the
debugger, I can find out how I got there?



Not sure if it's what you're looking for, but in the debugger, you can
type "bt" to show a backtrace.



That is exactly what I was looking for :-)

Thanks very much.

Frank

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

Re: Python 3.8.5 Not Launching

[Gertjan Klein]

Eryk Sun schreef:

On 10/2/20, Gertjan Klein  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

Re: Python 3.8.5 Not Launching

[Gertjan Klein]

Chris Angelico schreef:

On Fri, Oct 2, 2020 at 7:51 PM Gertjan Klein  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

Re: Python 3.8.5 Not Launching

[Eryk Sun]

On 10/3/20, Gertjan Klein  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

Re: ValueError: arrays must all be same length

[Peter Pearson]

On Fri, 2 Oct 2020 13:34:46 +0100, Shaozhong SHI  wrote:
> Hello,
>
> I got a json response from an API and tried to use pandas to put data into
> a dataframe.
>
> However, I kept getting this ValueError: arrays must all be same length.
>
> Can anyone help?
>
> The following is the json text.  Regards, Shao
>
> {
>   "locationId": "1-1004508435",
>   "providerId": "1-101641521",
...
[huge block removed]
...
>   "reportType": "Location"
> }
>   ]
> }
>
> In [ ]:
>
>
> In [25]:
> j
>
>
> import pandas as pd
>
> import json
>
> j = json.JSONDecoder().decode(req.text)  ###req.json
>
> df = pd.DataFrame.from_dict(j)

An important programming skill is paring back failing code to
create the smallest example that exhibits the failure.  Often, the
paring process reveals the problem; and if it doesn't, the shorter
code is more likely to attract help.

-- 
To email me, substitute nowhere->runbox, invalid->com.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Debugging technique

[Irv Kalb]

This probably is not for you.  But PyCharm has a panel that shows a stack trace.

I created a video about debugging using the PyCharm debugger.  Here is a 
YouTube link:

https://www.youtube.com/watch?v=cxAOSQQwDJ4 


Irv

> On Oct 2, 2020, at 11:51 PM, Frank Millman  wrote:
> 
> Hi all
> 
> When debugging, I sometimes add a 'breakpoint()' to my code to examine 
> various objects.
> 
> However, I often want to know how I got there, so I replace the 
> 'breakpoint()' with a '1/0', to force a traceback at that point. Then I can 
> rerun the previous step using the extra info from the traceback.
> 
> Is there a way to combine these into one step, so that, while in the 
> debugger, I can find out how I got there?
> 
> Frank Millman
> 
> -- 
> https://mail.python.org/mailman/listinfo/python-list
> 

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