Why is it that when I do self.SetPosition((0,0)), the result is a window that is flush with the top of the screen, but five pixels to the right of the left edge?
The operating system likely puts a border around your window, which might be transparent if that’s what the OS Theme specifies. IIRC, I get an 8 pixel transparent border on all sides of a Frame on Windows, and that’s how I interpreted it.
David
at MAXIMIZE event GetPosition gives (-8, -8) 
I just find the whole thing puzzling. I understand that when I draw a pixel to a control in an app that (0,0) refers to the upper leftmost pixel in the client area which is inside the control border.
But a screen/display should not have an invisible border, especially one that I can’t easily get the size of along with all the other display parameters. There are a number of applications that draw directly to the screen. Sysinternals zoomit and faststone capture for two. The idea of being able to draw directly to the screen means that I can freeze the screen annotate it, then save it to a file. By what has been posted here it would seem that anyone doing this would have to account for this invisible border which has no fixed size and serves no apparent purpose.
The border comes from the operating system and does serve a purpose for things like resizing the window and letting the OS know what part of the screen need to be redrawn as different programs move to the front or get moved to the back.
You can alter the transparency and color of the border using OS themes and color configuration. For example, see for Win11.
Hope that helps reduce your puzzlement.
David
I also came across some weird behaviour recently when trying to position a frame at 0, 0.
In my applications I have code which saves and loads the positions and sizes of most of the frames and dialogs so that they reappear where the user left them. After making some modifications to one program I noticed while testing that sometimes it appeared at the saved position of (0, 0), but other times it appeared at (186, 163). I checked the config file and it was definitely saving the correct coordinates. Running in debug I could see it was also loading the correct values and passing them to SetPosition() correctly.
Then I realised that when I ran the application from PyCharm it did display it at the correct position, but when I ran it from a desktop icon it displayed it at the wrong position. However, that was a red herring! What was actually affecting the position was the virtual workspace I was running it in. I have my Linux PCs configured to have 8 virtual workspaces and I found that if I started the application in workspaces 1, 2, 4 or 8, then the frame did appear at the correct saved position of (0, 0). If I started the application in workspaces 3, 5, 6 or 7 then the frame consistently appeared at (186, 163). The reason it worked when running from PyCharm was that I usually have PyCharm running in workspace 8.
Could it be that the window manager doesn’t correctly map the position (0, 0) in some of the virtual workspaces to (0, 0) on the screen?
As a workaround my code now saves the position (0, 0) as (1, 0) and the windows appear in almost the correct position on all the workspaces.
I am using Python 3.8.10 + wxPython 4.1.1 gtk3 (phoenix) wxWidgets 3.1.5 + Linux Mint 20.3.
Basically your reason is “because”. I don’t see why the screen needs a border, and “for things like resizing…” don’t explain the reason. If a border is needed (and I still don’t see why it is), why not make it width zero and the size of the display?
You can alter the transparency and color of the border using OS themes and color configuration. For example, see for Win11.
When I go to settings and type “border” into the search bar, the only thing that comes up is regarding screencaps. I have no idea what setting you are referring to.
As a workaround my code now saves the position (0, 0) as (1, 0) and the windows appear in almost the correct position on all the workspaces.
At this point I don’t see why we need “word-arounds”. Those should only be needed when running on buggy systems.
From Microsoft
The coordinate system for a window is based on the coordinate system of the display device. The basic unit of measure is the device unit (typically, the pixel). Points on the screen are described by x- and y-coordinate pairs. The x-coordinates increase to the right; y-coordinates increase from top to bottom. The origin (0,0) for the system depends on the type of coordinates being used.
The system and applications specify the position of a window on the screen in screen coordinates. For screen coordinates, the origin is the upper-left corner of the screen. The full position of a window is often described by a RECT structure containing the screen coordinates of two points that define the upper-left and lower-right corners of the window.
and
The system and applications specify the position of points in a window by using client coordinates. The origin in this case is the upper-left corner of the window or client area. Client coordinates ensure that an application can use consistent coordinate values while drawing in the window, regardless of the position of the window on the screen.
So if you are referring to an app you use client coordinates. When referring to the screen you use screen coordinates. There is no mention of a 7 or 8 pixel offset. It specifically states the origin is the upper-left corner of the screen
wx isn’t shy at all and let’s you choose style=wx.BORDER_NONE, so let’s give it a try 
I don’t want my app to have no border. If you are not referring to the main app frame then what? Information out of context is not useful.
My reason is “because” like the reason cars have wheels is “because.” An app frame has a border because the operating system needs to operate within, with, or outside of that border. The border is an integral part of every frame you create. You may not be paying attention, but you certainly interact with window borders every time you resize a window and the operating system deals with the window border every time it changes the z-order (not a wx-concept, but very important to the OS) of your windows.
I’m reminded of the phrase “it’s turtles all the way down.”
I’m not talking about app frames or app borders or anything to do with apps other than their positioning. I’m talking about the desktop. The only reason I am asking this question on the wxPython forum is that wxPython is the only framework in which I have written GUI apps in the last five years. I don’t know or care what happens when I try to program a GUI in any other framework. Forget I even mentioned apps.
Even the Microsoft Docs say that the screen starts at (0,0). That means that according to Microsoft, the coordinates of the top left pixel are (0,0). So where does the (-7,-7) come from?
I recall something that happened many years ago when I went to a presentation by a local Commodore 64 user group. Somebody was demoing a midi peripheral called Band-In-a-Box. One of the attendees couldn’t understand how it could produce so much complex sound. His response to any explanation was an astonished, “but it only has an 8 bit bus”.
I sincerely hope I have not become “that guy”.
I’m going to guess that at some point someone will point out that the desktop is essentially an explorer window (albeit a special one with no visible border). In that case I would have to reason that the client area is the visible part of the explorer window, which is the entire visible desktop. Based on that logic, the upper left pixel would be, based on client coordinates, (0,0).