how to include text data in source code?

[Sun]

as the subject, I 'd like to know how to include a piece of text as input in 
the source code so that I do not need to read in data from files. I remember 
there is some thing like this in Perl, have no idea if python has the same 
thing?

Thanks.



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

Re: how to include text data in source code?

[Sun]

"Matimus" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> On Feb 1, 9:28 am, "Sun" <[EMAIL PROTECTED]> wrote:
>> as the subject, I 'd like to know how to include a piece of text as input 
>> in
>> the source code so that I do not need to read in data from files. I 
>> remember
>> there is some thing like this in Perl, have no idea if python has the 
>> same
>> thing?
>>
>> Thanks.
>
> You can just add a big string to your file. Triple quotes will help
> with that. Of course, if you are going to be entering the data into
> your python file, why don't you enter it using the most appropriate
> data structure. Were intending to also append to the data in the file?
> I'm sure you could figure something out to do that, but there is no
> inherent feature that does that automatically.
>
> Matt
Thanks you all for the answers.

The reason is that I am using pydot to deal with graphiz dot format data, 
which in my case is a very simple graph, just few lines. So i was trying to 
just embed this data within the code. One functiuon will read in the data 
and parse it as in "dot language" format.



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

Re: ways to declare empty set variable

[Sun]

"Chris" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> On Feb 12, 3:45 pm, "Sun" <[EMAIL PROTECTED]> wrote:
>> Maybe this is a very primative question, but I just get a bit confused 
>> about
>> 'set' and 'Set' module in python.
>>
>> I understand 'set' is a build in type in python after 2.4(or 2.3) and Set 
>> a
>> seperate module, anyhow, I gonna use build in 'set'.
>>
>> then the question is how can I declare a empty set variable as a 'var= 
>> []'
>> do to a list variable?
>
>>>> test = set()
>>>> test
> set([])
>>>> type(test)
> 
>
> You looking for that ?

yeah, that 's what I am looking for, thanks all for such prompt answers!

I was wondering why can't I use a format as "var = {} " to "var=list()" in 
set variable, and decided not to  bother with it.

Thanks.




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

ways to declare empty set variable

[Sun]

Maybe this is a very primative question, but I just get a bit confused about 
'set' and 'Set' module in python.

I understand 'set' is a build in type in python after 2.4(or 2.3) and Set a 
seperate module, anyhow, I gonna use build in 'set'.

then the question is how can I declare a empty set variable as a 'var= []' 
do to a list variable?
 


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

how can pulldom save to xml file?

[sun]

I have a large xml file parsed by pulldom. I did some editing on some 
node,change attributes and remove some child node, how do I save it back 
to this xml file or write a new xml file? The save method in minidom 
does not work for pulldom.

Thanks
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Run Windows commands from Python console

[eryk sun]

On Sun, Sep 3, 2017 at 7:56 AM,   wrote:
>
> I run Python console in Windows. Can I run cmd prompt commands
> there?

Python doesn't know the first thing about CMD's "batch" language.
Also, Python's shell (i.e. REPL) is not a system administration shell
that implicitly runs external commands. You need to use the subprocess
module for that. For example:

>>> import subprocess
>>> subprocess.call(['icacls.exe', 'SomeFile.ext', '/grant',
'JaneDoe:(F)']).

If you need to run a CMD command, use shell=True with a command-line
string. For example:

>>> subprocess.call('icacls SomeFile.ext /grant %USERNAME%:(F)', shell=True)

FYI, being attached to a console for standard I/O doesn't mean you're
using a "Command Prompt" that can run CMD commands.

python.exe is a character (i.e. text user interface or command-line
interface) application that creates or inherits a console
automatically. You're probably used to running python.exe from cmd.exe
and inheriting CMD's console. But you can also run python.exe directly
from Explorer, in which case it creates its own console. If Python
creates its own console, the window will be destroyed automatically
when Python exits -- unless you create child processes that are also
attached to the console and remain running.

pythonw.exe is graphical or background application, not a character
application, so it doesn't create or inherit a console automatically.
Typically IDLE runs via pythonw.exe, in which case if you want a
console you need to call WinAPI AllocConsole() or AttachConsole().
Once attached to a console, you can open "CON", "CONIN$" , or
"CONOUT$".

> What means line below:
>
> File "", line 1
>
> I don't have any  file.

Indeed, on Windows you cannot create a file named "". Python
uses this fake name for the code object it compiles when reading from
stdin (i.e. the file stream opened for console input).

It's not exactly smart about this, either, since whenever an exception
is raised in the REPL it will try to open this fake file multiple
times, including trying every entry in sys.path. For example, in a
typical Python 3.6 all-users installation, it will try opening the
following file paths:



C:\Program Files\Python36\python36.zip\
C:\Program Files\Python36\python36.zip\
C:\Program Files\Python36\DLLs\
C:\Program Files\Python36\lib\
C:\Program Files\Python36\
C:\Program Files\Python36\lib\site-packages\
...

Of course, all of these attempts to open "" necessarily fail on
Windows. On Unix, however, this can actually succeed, which is kind of
funny:

>>> open('', 'w').write('What the !@#$%^&*?')
18

>>> dit
Traceback (most recent call last):
  File "", line 1, in 
What the !@#$%^&*?
NameError: name 'dit' is not defined
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: ANN: psutil 5.3.0 with full unicode support is out

[eryk sun]

On Sun, Sep 3, 2017 at 9:58 AM, Giampaolo Rodola'  wrote:
>
> - #1040: all strings are encoded by using OS fs encoding.
> - #1040: the following Windows APIs on Python 2 now return a string instead
> of
>   unicode:
>   - Process.memory_maps().path
>   - WindowsService.bin_path()
>   - WindowsService.description()
>   - WindowsService.display_name()
>   - WindowsService.username()

This seems wrong. User names, file paths, registry strings, etc are
all Unicode in Windows. One cannot in general encode them as the
legacy (as in it really should be avoided) 'mbcs' encoding, i.e. ANSI.
Using the 'replace' handler will make a mess with best-fit
replacements and question marks. For example, _winreg in Python 2 has
to return unicode strings and always has, which should be the
precedent for psutil. Python 2 code that supports Windows has to be
able to handle this.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: ANN: psutil 5.3.0 with full unicode support is out

[eryk sun]

On Sun, Sep 3, 2017 at 11:09 PM, Giampaolo Rodola'  wrote:
>
> This is an example which filters processes with a funky name which works
> with both Python 2
> and 3:
>
> import psutil, sys
>
> PY3 = sys.version_info[0] == 2
> LOOKFOR = u"ƒőő.exe"
> for proc in psutil.process_iter(attrs=['name']):
> name = proc.info['name']
> if not PY3:
> name = unicode(name, sys.getdefaultencoding(), errors="replace")
> if LOOKFOR == name:
>  print("process %s found" % p)
>
> This is IMO the best compromise for a lib which aims to work on both Python
> 2 and 3. It's either that or returning Unicode all over the place in Python
> 2, but that's something I considered and rejected because most of the times
> the string is not supposed to have funky characters, so "practicality beats
> purity" in this case.

The encoded name for ANSI codepage 1252 is "\x83oo.exe". Python 2's
default encoding is ASCII, so the decoded result is u'\ufffdoo.exe'.
Even if it should be the filesystem encoding ('mbcs'), the result is
u"ƒoo.exe". Neither equals u"ƒőő.exe".

Instead, shouldn't it encode LOOKFOR as "mbcs" with errors="replace"
before comparing it to proc.info['name']?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python console's workspace path

[eryk sun]

On Tue, Sep 5, 2017 at 9:26 AM, Andrej Viktorovich
 wrote:
>
> I run Python 3.6 console under windows 10. Where is default console directory?

The working directory for the console (i.e. conhost.exe) is irrelevant
to Python. So I assume you mean the default working directory of the
Python shell (i.e. the REPL). There isn't one. It's set by or
inherited from the parent process.

> Can I change default work space location?

For interactive work, set the PYTHONSTARTUP environment variable to
the fully-qualified path of a startup script. Set the working
directory in this script via os.chdir("fully/qualified/path").

For a script, the working directory should not be used to find private
resources. Use the script/package directory for read-only resources
and otherwise use a platform-dependent data directory (e.g. on Windows
use a subdirectory of %LocalAppData% or %ProgramData%).
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: remove path forever

[eryk sun]

On Thu, Sep 7, 2017 at 1:39 AM, Andrej Viktorovich
 wrote:
>
> I have 64 bit python on my windows 10 machine. Install contains 32 bit python 
> libs in path
> and I would like to remove them.
>
> I do
> imprt sys
> sys.path.remove("C:\\Users\\me\\AppData\\Local\\Programs\\Python\\Python36-32")
>
> It works for current python instance, but paths appears in new one. How to 
> remove paths forever?

Probably you have the Python36-32 directories set in PYTHONPATH. For
some reason some people think they need to add standard directories to
this environment variable, which is something you should never do.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: remove path forever

[eryk sun]

On Thu, Sep 7, 2017 at 9:25 AM, Andrej Viktorovich
 wrote:
> On Thursday, 7 September 2017 14:35:58 UTC+3, eryk sun  wrote:
>> On Thu, Sep 7, 2017 at 1:39 AM, Andrej Viktorovich
>>  wrote:
>> >
>> > I have 64 bit python on my windows 10 machine. Install contains 32 bit 
>> > python libs in path
>> > and I would like to remove them.
>> >
>> > I do
>> > imprt sys
>> > sys.path.remove("C:\\Users\\me\\AppData\\Local\\Programs\\Python\\Python36-32")
>> >
>> > It works for current python instance, but paths appears in new one. How to 
>> > remove paths forever?
>>
>> Probably you have the Python36-32 directories set in PYTHONPATH. For
>> some reason some people think they need to add standard directories to
>> this environment variable, which is something you should never do.
>
> Yes, my PYTHONPATH looks like:
> C:\Users\me\AppData\Local\Programs\Python\Python36-32
> C:\Users\me\AppData\Local\Programs\Python\Python36-32\DLLs
> C:\Users\me\AppData\Local\Programs\Python\Python36-32\Lib
>
> Should I remove them? I suppose installer did so. But why 64 bit installer 
> skiped this?

Yes, remove them. I don't know what added them, but the installer did
not -- assuming it's a standard installer from python.org. Those
entries are not necessary and are guaranteed to break other
installations of Python. Typically they get added manually by users
who are desperate to resolve some path issue, which is often a
completely unrelated system PATH issue.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Delay a computation in another thread

[eryk sun]

On Fri, Sep 8, 2017 at 10:03 AM, Thomas Jollans  wrote:
> On 2017-09-08 16:49, Steve D'Aprano wrote:
>
>> Sorry for the long delay in replying to this, but if I set its daemon 
>> attribute,
>> won't that mean it will live on after the interpreter shuts down?
>>
>> Also, what happens if it tries to print after the interpreter shuts down? 
>> Where
>> does output go?
>
> On Linux, I think it would go to the same virtual terminal as it did
> before, if that still exists. (Otherwise, to /dev/null). This is how
> processes that started out attached to a terminal and then went into the
> background normally behave.

In the normal case, when the interpreter shuts down, the process exits
along with all threads. On the other hand, when Python is embedded,
daemon threads may persist if the interpreter is finalized without
exiting the process. Such threads shouldn't be able to do anything
because they'll block trying to acquire the GIL.

> No idea what happens on Windows, but if I had to guess, I'd say "not that".

The Windows console system (i.e. condrv.sys driver, conhost.exe host,
and csrss.exe session server) doesn't have full support for Unix-style
process groups. They're supported for targeting Ctrl+C and Ctrl+Break.
Also, Ctrl+C is disabled for new process groups. But there's no notion
of foreground and background process groups. Thus it can't implement
the Unix feature that suspends a background process that tries to read
from console input. (Usually background processes in Unix are allowed
to write to the terminal, but that can be disallowed as well.)

In the CMD shell, the closest you can do for running a process in the
background is via "start /b [...] https://mail.python.org/mailman/listinfo/python-list

Re: Interactive scripts (back on topic for once) [was Re: The "loop and a half"]

[eryk sun]

On Fri, Oct 6, 2017 at 9:48 AM, Paul Moore  wrote:
> On 6 October 2017 at 09:36, Peter J. Holzer  wrote:
>> On 2017-10-06 08:09, Steve D'Aprano  wrote:
>>
>>> # 1 detect input coming from a pipe.
>>> import sys
>>> import os
>>> from stat import S_ISFIFO
>>> if S_ISFIFO(os.fstat(0).st_mode):
>>> print("Reading from a pipe")
>>>
>>> # 2 detect input coming from a regular file.
>>> from stat import S_ISREG
>>> if S_ISREG(os.fstat(0).st_mode):
>>> print("Reading from a file.")
>>>
>>> # 3 detect a terminal, hopefully with a human typing at it
>>> if os.isatty(0):
>>> print("Oy noddy, wake up and type something, I'm waiting for you!")
[...]

> All of these work on Windows, I just tested. Which surprised me, as I
> thought things like S_ISFIFO were Unix specific. Today I learned...

The fstat implementation for Windows calls GetFileType to look for
FILE_TYPE_CHAR (i.e. S_IFCHR) and FILE_TYPE_PIPE (i.e. S_IFIFO).

The C runtime's isatty() on Windows checks for for a character device,
not a console. If we're using this to test for interactive mode, we'll
get a false positive on Windows if StandardInput is redirected to the
DOS "NUL" device (i.e. NT "\Device\Null") or a COM port (rarely).

As to using fd 0 instead of stdin.fileno(), for a non-console process
(e.g. pythonw.exe), the C runtime doesn't initialize the standard file
descriptors beyond their static definitions, and isatty(0) will return
true even though it's not a valid file descriptor (i.e. the mapped
Windows handle is INVALID_HANDLE_VALUE). We need to rely on the C
stdin FILE stream being invalid, in which case sys.stdin is set to
None.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The "loop and a half"

[eryk sun]

On Fri, Oct 6, 2017 at 2:35 PM, Paul Moore  wrote:
>
> cmd:
> for /f %i in ('gcc -E program.c') do ...

Note that CMD processes the output as decoded Unicode text instead of
encoded bytes. This is often a source of mojibake. It runs the above
command with stdout redirected to a pipe, and it decodes the output
line-by-line using the console's output codepage from
GetConsoleOutputCP(). The console defaults to the system locale's OEM
codepage. If CMD is run without a console (detached), it defaults to
the system locale's ANSI codepage. Commonly, the program being run
might write its output as OEM, ANSI, or UTF-8 text. For example,
Python defaults to ANSI on Windows, but %PYTHONIOENCODING% could
override this as UTF-8.

You can change the console's input and output codepages to another
codepage (but not separate values) via chcp.com. For example, `chcp
65001`  sets it to UTF-8. But don't change it permanently, and
certainly don't leave it in its (buggy) UTF-8 mode. Instead, a batch
script should save the previous codepage and switch back when it's
done.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Interactive scripts (back on topic for once) [was Re: The "loop and a half"]

[eryk sun]

On Fri, Oct 6, 2017 at 1:31 PM, Thomas Jollans  wrote:
> On 2017-10-06 12:33, Ben Bacarisse wrote:
>
>> A general solution to the (rather odd) complaint about silent waiting
>> should really check any input fileno to see if a prompt is needed.  You
>> could argue, though, that anyone who's re-arranged a program's input so
>> that some non-zero input fileno is attached to a terminal won't need the
>> prompt!
>
> stdin is ALWAYS fileno 0, whether the input is attached to a tty or not.
> The only situation where sys.stdin.fileno() != 0 is when sys.stdin has
> been reassigned from within python.
>
> $ python -c 'import sys; print(sys.stdin.fileno())' < /dev/zero
> 0
>
> This should be true for all platforms, or at least all platforms python
> supports.

POSIX defines STDIN_FILENO as 0, and the Windows C runtime reserves FD
0 to map to the native StandardInput handle. But as I noted in a
previous message, on Windows isatty(0) returns true if a process isn't
executed with a valid StandardInput. In this case sys.stdin will be
None, so call sys.stdin.fileno() and handle the exception if that
fails.

If you really need to know that stdin is interactive for something
critical, then isatty() is the wrong function on Windows. You need to
check for a console, which is most easily done by using ctypes to call
GetConsoleMode. For example:

import os

if os.name == 'posix':
from os import isatty

elif os.name == 'nt':
import ctypes
import msvcrt
kernel32 = ctypes.WinDLL('kernel32', use_last_error=True)

def isatty(fd):
"""Return True if the fd is connected to a console."""
try:
handle = ctypes.c_void_p(msvcrt.get_osfhandle(fd))
except (OSError, IOError):
return False
mode = ctypes.c_ulong()
success = kernel32.GetConsoleMode(handle, ctypes.byref(mode))
return bool(success)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Interactive scripts (back on topic for once) [was Re: The "loop and a half"]

[eryk sun]

On Fri, Oct 6, 2017 at 4:27 PM, Thomas Jollans  wrote:
> On 2017-10-06 17:01, eryk sun wrote:
>>
>> POSIX defines STDIN_FILENO as 0, and the Windows C runtime reserves FD
>> 0 to map to the native StandardInput handle. But as I noted in a
>> previous message, on Windows isatty(0) returns true if a process isn't
>> executed with a valid StandardInput. In this case sys.stdin will be
>> None, so call sys.stdin.fileno() and handle the exception if that
>> fails.
>
> Seriously? sys.stdin can be None? That's terrifying.

Just check for None or handle the exception.

It could be worse in Windows -- like inheriting broken standard I/O.
This can happen if a console application is run without a console
(i.e. dwCreationFlags=DETACHED_PROCESS) yet console handles are
inherited in the standard handles via STARTUPINFO. isatty() will
return True, but using the handles will fail. To avoid this problem
with subprocess.Popen, if you use creationflags=DETACHED_PROCESS, make
sure to set unused standard handles to subprocess.DEVNULL.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The "loop and a half"

[eryk sun]

On Sat, Oct 7, 2017 at 1:06 PM, bartc  wrote:
>
> So I have to copy 33,000 lines from a document, get to the terminal (keeping
> that document open because I'm not done with it), start 'sort', and paste
> those 33,000 lines into the console, then type Ctrl-D. Which then promptly
> prints the newly sorted 33,000 lines onto the console. Then you have to
> select those 33,000 lines (not easy as you now have find the midpoint of
> 66,000 lines of output), copy it, and paste it back into the app.

Just redirect sort's output to the clipboard. In X11 a common program
for this is xclip, e.g. `sort | xclip`, which defaults to the
"primary" clipboard but can also use the "secondary" and "clipboard"
clipboards.

In Windows it's clip.exe, e.g. `sort /u /c | clip`, where /u and /c
are undocumented sort switches to use UTF-16 output and a
case-sensitive sort.

That said, I wouldn't use sort.exe to read input from the Windows
console since it uses the legacy codepage. Instead I'd use the new
Linux subsystem in Windows 10, which as of the Creators update
supports piping between Linux and Windows programs and reads Unicode
from the console. Run `bash` and then `sort | clip.exe`. Finish with
Ctrl+D, and Bob's your uncle. Using MSYS bash.exe and sort.exe (e.g.
from Git for Windows) is another option.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The "loop and a half"

[eryk sun]

On Sun, Oct 8, 2017 at 10:12 AM, Steve D'Aprano
 wrote:
> On Sun, 8 Oct 2017 02:06 am, bartc wrote:
>
>> Especially on
>> Windows where the usual Ctrl C doesn't work, so you resort to Ctrl-Break
>> will which actually abort it. Ctrl Z is uncommon.
>
> Thousands of Python programmers on Windows successfully learned to use Ctrl-Z
> ENTER back in the days of Python 1.5, before quit/exit were added as a
> convenience for beginners, and many of them probably still use it.

Using Ctrl+Z (0x1A) isn't specific to Python. The Windows CRT's
text-mode I/O inherits this from MS-DOS, which took it from CP/M. It's
obvious in Python 2:

>>> open('test.txt', 'w').write('123\x1a456')
>>> open('test.txt', 'r').read()
'123'
>>> open('test.txt', 'rb').read()
'123\x1a456'

This has been misreported as a bug more than once.

Python 3 opens CRT file descriptors in binary mode. Its text mode
(TextIOWraper) doesn't implement the legacy Ctrl+Z behavior. However,
Ctrl+Z at the start of a line is manually supported in the REPL and
raw _WindowsConsoleIO.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Is there a way to globally set the print function separator?

[eryk sun]

On Mon, Oct 9, 2017 at 10:04 PM, John Black  wrote:
> In article , python@example.invalid says...
>>
>> Le 09/10/2017 à 18:22, John Black a écrit :
>> > I want sep="" to be the default without having to specify it every time I
>> > call print.  Is that possible?
>>
>>  >>> oldprint = print
>>  >>> def print(*args,**kwargs):
>> ...   oldprint(*args,**kwargs,sep='')
>> ...
>>  >>> print(1,2,3)
>> 123
>
> Winner!  Thanks all.

functools.partial(print, sep='') is the winner, IMO. Or even code that
use kwargs.setdefault('sep', ''). The above code is wrong in a way
that leads to a TypeError. Can you see the problem?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: pathlib PurePosixPath

[eryk sun]

On Tue, Oct 10, 2017 at 11:18 AM, Tim Golden  wrote:
> On 2017-10-10 10:58, Chris Angelico wrote:
>> On Tue, Oct 10, 2017 at 8:56 PM, Tim Golden  wrote:
>>
>>> In fact its presence in that filename creates a (usually hidden) data
>>> stream piggybacked onto that file which has the name "abc" into which the
>>> data is written.
>>>
>>> So, following on, the follow works:
>>>
>>> assert open("temp.txt:abc").read() == "abc"
>>
>> Cool. Does it require that temp.txt exist first? And if you have
>> multiple colons (as in the OP's), does the part after the second colon
>> have to be a type indicator?
>>
>> ChrisA
>
> No. temp.txt is created empty.
>
> Multiple colons *does* appear to be a syntax error in the filename.

Colon in a file path (not a device name) is a reserved character
that's used to reference NTFS file streams. The colon is not part of
the name of either the base file/directory or the stream. You can
check whether a volume supports named streams by calling
GetVolumeInformation. If they're supported, then lpFileSystemFlags
will contain the flag FILE_NAMED_STREAMS.

The complete spec is "FileName:StreamName:StreamType". When a regular
file is opened, NTFS defaults to opening the anonymous data stream,
"FileName::$DATA". When a directory is opened, NTFS defaults to
opening "DirName:$I30:$INDEX_ALLOCATION", i.e. the $I30 stream of type
$INDEX_ALLOCATION. A directory can also have named $DATA streams, but
it can't have an anonymous $DATA stream because that would be
ambiguous in general.

Other stream types used internally in NTFS include $FILE_NAME,
$REPARSE_POINT, $OBJECT_ID, $ATTRIBUTE_LIST, $INDEX_ROOT, and $BITMAP.
But these are of little interest unless you specialize in forensics or
are supporting NTFS on another OS.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Calling of GetVolumeInformation returns empty serial number

[eryk sun]

On Tue, Nov 7, 2017 at 7:58 AM, Durumdara  wrote:
>
> I want to get the serial number of the drives (without external modules
> like Win32 or WMI).

The volume serial number is more easily available as
os.stat(drive).st_dev, which comes from calling
GetFileInformationByHandle. Note that despite using the volume serial
number (VSN) as the nearest equivalent of POSIX st_dev, there is no
requirement that the VSN is unique or even non-zero. The same applies
to the file index number that's used for POSIX st_ino. For example,
both values are 0 on a WebDav drive, for which Python's implementation
of os.path.samefile is useless. Practically speaking, however, it's
good enough in most cases, especially for mounted disk volumes.

That said, maybe what you really want is the hardware (disk) serial
number -- not a volume serial number. The easiest way to get that is
via WMI. You can use subprocess to run wmic.exe if you don't want an
external dependency. You can also get the disk serial number by
calling DeviceIoControl via ctypes. This is a fairly complex
IOCTL_STORAGE_QUERY_PROPERTY request, with an input
STORAGE_PROPERTY_QUERY structure requesting the StorageDeviceProperty.
The result is a STORAGE_DEVICE_DESCRIPTOR structure that has a
SerialNumberOffset field that's the byte offset from the beginning of
the buffer of the serial number as a null-terminated string.

Getting back to the VSN, note that the mount-point manager doesn't
rely on it as a unique identifier. For associating volume devices with
logical DOS drives and volume GUID names (i.e. names like
"Volume{12345678----123456789abc}", which are used to
mount volumes as NTFS junctions), the mount-point manager queries a
unique ID via IOCTL_MOUNTDEV_QUERY_UNIQUE_ID. Sometimes the volume
driver returns a unique ID that's very long -- over 200 bytes. This
doesn't matter because it's only used to uniquely associate a GUID
name (and maybe a DOS drive) with the given volume when the system
boots. This association is persisted in HKLM\System\MountedDevices.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: ctypes help

[eryk sun]

 On Fri, Nov 17, 2017 at 10:11 PM, Python  wrote:
>
> I'm starting to play with ctypes, as I'd like to provide Python
> interfaces to a C/C++ library I have.  For now I'm just messing with a
> very simple piece of code to get things sorted out.  I'm working with
> this example C++ library, which just wraps a call to stat():

Calling POSIX system functions via ctypes can be difficult if they use
struct layouts that vary with the target platform and architecture.

> class Stat(ctypes.Structure):
> _fields_ = [("st_dev", ctypes.c_ulong),
> ("st_ino", ctypes.c_ulong),
> ("st_mode", ctypes.c_ulong),
> ("st_nlink", ctypes.c_ulong),
> ("st_uid", ctypes.c_ulong),
> ("st_gid", ctypes.c_ulong),

For x64 the above incorrectly uses 64-bit integers for mode, uid, and
gid. Also, it has mode and nlink flipped around in the x86 order
instead of the new x64 order.

> ("st_rdev", ctypes.c_ulong),
> ("st_size", ctypes.c_ulonglong),
> ("st_blksize", ctypes.c_ulonglong),
> ("st_blocks", ctypes.c_ulonglong),
> ("st_atim", Timespec),
> ("st_mtim", Timespec),
> ("st_ctim", Timespec)]

Try to strictly adhere to the defined types. Don't use `long long` for
a `long`, even if it happens to be the same size in a given
architecture. Also, avoid using definitions from docs and man pages.
Use the exact headers that the compiler sees. In this case, you missed
the 3 reserved long-integer fields at the end on x64 builds. Your Stat
struct is 128 bytes overall instead of the required 144 bytes. glibc
will corrupt the heap when it writes to the last 16 bytes. The best
case is that this immediately crashes Python.

Below I've included an example ctypes wrapper for calling stat() on
Linux x64 and x86 systems. I verified the sizes and offsets and tested
in 64-bit Python. From a C test program, I also have the field sizes
and offsets for the two 32-bit cases (with and without large file
support), but I'd need to build 32-bit Python to verify that the
ctypes wrapper is correct. I have no personal use for 32-bit Python,
so I leave that part up to you.

C header definitions from time.h, bits/typesizes.h, bits/types.h, and
bits/stat.h:

#define __DEV_T_TYPE   __UQUAD_TYPE
#define __INO_T_TYPE   __SYSCALL_ULONG_TYPE
#define __INO64_T_TYPE __UQUAD_TYPE
#ifdef __x86_64__
#define __NLINK_T_TYPE __SYSCALL_ULONG_TYPE
#else
#define __NLINK_T_TYPE __UWORD_TYPE
#endif
#define __MODE_T_TYPE  __U32_TYPE
#define __UID_T_TYPE   __U32_TYPE
#define __GID_T_TYPE   __U32_TYPE
#define __OFF_T_TYPE   __SYSCALL_SLONG_TYPE
#define __OFF64_T_TYPE __SQUAD_TYPE
#define __BLKSIZE_T_TYPE   __SYSCALL_SLONG_TYPE
#define __BLKCNT_T_TYPE__SYSCALL_SLONG_TYPE
#define __BLKCNT64_T_TYPE  __SQUAD_TYPE
#define __TIME_T_TYPE  __SYSCALL_SLONG_TYPE

struct timespec
{
__time_t tv_sec;
__syscall_slong_t tv_nsec;
};

struct stat
{
__dev_t st_dev;
#ifndef __x86_64__
unsigned short int __pad1;
#endif
#if defined __x86_64__ || !defined __USE_FILE_OFFSET64
__ino_t st_ino;
#else
__ino_t __st_ino;
#endif
#ifndef __x86_64__
__mode_t st_mode;
__nlink_t st_nlink;
#else
__nlink_t st_nlink;
__mode_t st_mode;
#endif
__uid_t st_uid;
__gid_t st_gid;
#ifdef __x86_64__
int __pad0;
#endif
__dev_t st_rdev;
#ifndef __x86_64__
unsigned short int __pad2;
#endif
#if defined __x86_64__ || !defined __USE_FILE_OFFSET64
__off_t st_size;
#else
__off64_t st_size;
#endif
__blksize_t st_blksize;
#if defined __x86_64__  || !defined __USE_FILE_OFFSET64
__blkcnt_t st_blocks;
#else
__blkcnt64_t st_blocks;
#endif
#ifdef __USE_XOPEN2K8
struct timespec st_atim;
struct timespec st_mtim;
struct timespec st_ctim;
#else
__time_t st_atime;
__syscall_ulong_t st_atimensec;
__time_t st_mtime;
__syscall_ulong_t st_mtimensec;
__time_t st_ctime;
__syscall_ulong_t st_ctimensec;
#endif
#ifdef __x86_64__
__syscall_slong_t __glibc_reserved[3];
#else
#ifndef __USE_FILE_OFFSET64
unsigned long int __glibc_reserved4;
unsigned long int __glibc_reserved5;
#else
__ino64_t st_ino;
#endif
#endif
};


ctypes:

import os
import sys
import ctypes
import ctypes.util

libc = ctypes.CDLL(ctypes.util.find_library('c'), use_errno=True)

def c_errcheck(result, func, args):
if result == -1:
err = ctypes.get_errno()
raise OSError(err, os.strerror(err))
return args

class timespec(ctypes.Structure):
   

Re: Please tell me how to execute python file in Ubuntu by double

[eryk sun]

On Tue, Dec 12, 2017 at 3:30 PM, Chris Angelico  wrote:
> On Wed, Dec 13, 2017 at 12:54 AM, Rick Johnson
>  wrote:
>> Chris Angelico wrote:
>>
>>> Which is why OS/2, back in the 1990s, had *multiple*
>>> associations for any given file. You could use file types
>>> (sadly not MIME types - this was before MIME was the one
>>> obvious standard to use) to identify *any number* of
>>> programs that are likely to be used with a file, and then
>>> one of them is the global default. For any specific file,
>>> you can change which program is its own default, and even
>>> add specific associations for that individual file. When
>>> you double-click, you get the default; if you right-click
>>> and choose "Open", you could pick from the associated
>>> programs. A good system, and one that I still haven't seen
>>> replicated in a mainstream OS.
>>
>> Windows has the same features.
>
> It does? Show me how to specify that one file - which might have the
> exact same name as many similar files - should be associated with a
> different program than the one its name would normally suggest. Show
> me how to identify multiple file types for a given file, independently
> of its filename.

AFAIK that's not currently possible in Windows -- at least not without
writing a custom shell extension. Hypothetically, the shell could
support something like this on NTFS drives by storing a perceived type
(e.g. text, audio, image, video) and lists of ProgIDs (e.g. txtfile,
mp3file, jpegfile, mpegfile) either in a file's extended attributes
(EAs) or an alternate data stream. I think OS/2 used EAs to store file
associations. It's too bad NT's FAT32 doesn't support EAs (unlike
FAT16 on NT, which needed them for the OS/2 subsystem) or alternate
data streams. So an unobtrusive, decentralized approach that works
automatically with existing backup software isn't feasible with FAT32
drives.

That said, I don't see this feature as being very useful compared to
just using "open with" when I occasionally need to open a file with a
non-default program.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Please tell me how to execute python file in Ubuntu by double

[eryk sun]

On Wed, Dec 13, 2017 at 5:43 AM, Chris Angelico  wrote:
>
> A Windows equivalent would be to have a .py file associated normally
> with the regular console, but some individual ones associated with
> pythonw.exe - without renaming them to .pyw. AFAIK there is no way to
> do this on Windows short of renaming the files.

If using another file is ok, then a shell shortcut or hard link would
work.A symbolic link doesn't work because it seems the shell resolves
the link before querying the file association.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Please tell me how to execute python file in Ubuntu by double

[eryk sun]

On Wed, Dec 13, 2017 at 9:04 PM, Chris Angelico  wrote:
> On Thu, Dec 14, 2017 at 7:56 AM, eryk sun  wrote:
>> On Wed, Dec 13, 2017 at 5:43 AM, Chris Angelico  wrote:
>>>
>>> A Windows equivalent would be to have a .py file associated normally
>>> with the regular console, but some individual ones associated with
>>> pythonw.exe - without renaming them to .pyw. AFAIK there is no way to
>>> do this on Windows short of renaming the files.
>>
>> If using another file is ok, then a shell shortcut or hard link would
>> work.A symbolic link doesn't work because it seems the shell resolves
>> the link before querying the file association.
>
> As workarounds go, a hardlink isn't too bad. (A shell shortcut has its
> own problems and limitations.) But you still need to be able to define
> a filename pattern, usually by specifying an extension, that catches
> the alternates. So it's definitely a workaround, not a true feature.

I think a shell shortcut is a good workaround. It's less obtrusive
than a hard link since the script still has the same name. The command
line would be something like `"C:\Windows\pyw.exe"
"path\to\script.py"`. Clear the shortcut's "start in" field to make
pyw.exe inherit the working directory of the parent process. Add .LNK
to the PATHEXT environment variable to support executing "script.lnk"
as "script".
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Right way to io.open(...) an existing file object in Python 2.7?

[eryk sun]

On Tue, Jan 16, 2018 at 4:00 PM, Skip Montanaro
 wrote:
> I'd like to take advantage of the seekable() method of io.IOBase with
> existing open file objects, especially the standard in/out/err file
> objects.

io.open can open a file descriptor. If you don't use a duplicated FD
(os.dup), then you probably also want the option `closefd=False`. For
example:

$ cat test.py
import sys
import io

stdin = io.open(sys.stdin.fileno(), closefd=False)
print 'stdin seekable: %s' % stdin.seekable()

$ python test.py
stdin seekable: False

$ echo spam | python test.py
stdin seekable: False

$ python test.py < test.py
stdin seekable: True
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Can't get python running

[eryk sun]

On Sun, Jan 21, 2018 at 10:57 AM, Paul Moore  wrote:
>
> The "py" launcher is always added to PATH. It's installed by default
> (and always has been I believe) although there is a checkbox you can
> untick if you don't want to install it.

Yes, we can choose to not install the launcher. However, if we select
to install it, it seems we don't get to choose the install path or
whether it's added to PATH. When installed for the current user, the
launcher installs in "%LocalAppData%\Python\Launcher". This directory
is added to PATH even if we don't select "add Python to environment
variables". When installed for all users it goes in "%SystemRoot%",
which is already in the default system PATH and also implicitly
searched by WinAPI CreateProcess even if PATH isn't defined. The
launcher's primary purpose is to handle the .py[w] file association
and support shebangs in scripts, and to that end it does not have to
be in PATH. But it has also become a convenient way to manage multiple
Python installations from the command line, especially for `py
-X[.Y[-32]] -m pip` and (for 3.5+) `py -X[.Y[-32]] -m venv`

As to installing Windows applications in the root of the system drive,
that's fine for a single-user or personal system, if it's what you
prefer. The default DACL of the system drive's root directory allows
authenticated users to create directories that all authenticated users
have the right to modify. This is too permissive in general, so
starting with 3.5 the installer stopped using C:\PythonXY as the
default target. Now, all-users installs default to
"%ProgramFiles%\PythonXY" or "%ProgramFiles(x86)%\PythonXY-32", and
current-user installs default to
"%LocalAppData%\Programs\Python\PythonXY[-32]". %LocalAppData% expands
to "%UserProfile%\AppData\Local". By default, a user's profile
directory is accessible only to the user, administrators, and SYSTEM.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Help: 64bit python call c and got OSError: exception: access violation writing 0xFFFFFFFF99222A60

[eryk sun]

On Mon, Jan 22, 2018 at 9:00 PM, Jason Qian via Python-list
 wrote:
>
> I am using ctypes on Windows to interface with a dll  and it works fine
> on Linux and windows 32-bit python.  But, when using 64-bit python, we got
> error "exception: access violation writing 0x99222A60".
>
> from ctypes import *

Try to avoid * imports if it's a public module.

> lib = cdll.LoadLibrary('xxx.dll')

Just use CDLL directly. cdll.LoadLibrary is pointless, and
`cdll.xxx` is problematic in some cases because it caches CDLL
instances, which cache function pointers. Also, the ".dll" filename
extension isn't required in Windows.

> lib.createService.argtypes=[c_int,ctypes.c_char_p]
> lib.createService.restype=ctypes.c_int
>
> class myDriver(object):
> def init(self):
> self.obj = lib.loadInstance()

Since you didn't set loadInstance.restype, the result gets truncated
as a C int, the default result type.

I recommend defining an opaque ctypes struct (i.e. no defined fields)
for the C++ class. This provides type safety. Staying strict and
literal on types is more work than using a `void *` everywhere, but it
pays off in terms of easier debugging and more resilient code. A
simple example is that ctypes returns a `void *` result (or gets a
struct field or array item) as a Python integer. Then for any FFI call
that you may have forgotten to define argtypes, ctypes will default to
truncating this integer value as a C int. At best that causes an
immediate crash. At worst it's a subtle bug that corrupts data.

Here's an example implementation with an opaque struct:

import ctypes

lib = ctypes.CDLL('xxx')

class myPythonAPI(ctypes.Structure):
pass

PmyPythonAPI = ctypes.POINTER(myPythonAPI)

lib.loadInstance.restype = PmyPythonAPI
lib.loadInstance.argtypes = ()

lib.createService.restype = ctypes.c_int
lib.createService.argtypes = (PmyPythonAPI, ctypes.c_char_p)

class myDriver(object):

def init(self):
self.obj = lib.loadInstance()

def create_services(self, servicename):
return lib.createService(self.obj, servicename)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Processing a key pressed in Python 3.6

[eryk sun]

On Tue, Jan 23, 2018 at 11:29 PM, Virgil Stokes  wrote:
>
> How would this code be modified to handle using the "Esc" key instead of the
> "Enter" key?

The input() function depends on the console or terminal to read a line
of input. If you're using the Windows console, it calls the high-level
ReadConsole (or ReadFile) function, which performs a 'cooked' read. In
this case some keys are reserved. Escape is consumed to clear/flush
the input buffer. Function keys and arrows are consumed for line
editing and history navigation. And for some reason line-feed (^J) is
always ignored. Additionally, normal operation requires the following
input modes to be enabled:

ENABLE_PROCESSED_INPUT
process Ctrl+C as CTRL_C_EVENT and carriage return (^M)
as carriage return plus line feed (CRLF). consume
backspace (^H) to delete the previous character.

ENABLE_LINE_INPUT
return only when a carriage return is read.

ENABLE_ECHO_INPUT
echo read characters to the active screen.

Reading the escape key from the console requires the low-level
ReadConsoleInput, GetNumberOfConsoleInputEvents, and
FlushConsoleInputBuffer functions. These access the console's raw
stream of input event records, which includes key events, mouse
events, and window/buffer resize events. It's a bit complicated to use
this API, but fortunately the C runtime wraps it with convenient
functions such as _kbhit, _getwch, and _getwche (w/ echo). On Windows
only, you'll find these functions in the msvcrt module, but named
without the leading underscore. Here's an example of reading the
escape character without echo:

>>> msvcrt.getwch()
'\x1b'

Simple, no?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Processing a key pressed in Python 3.6

[eryk sun]

On Wed, Jan 24, 2018 at 8:02 PM, Virgil Stokes  wrote:
> Yes, I am aware of this Dennis. However, but, on my system I actually had it
> running without the msvcrt.kbhit()

_getwch loops calling ReadConsoleInput until a key event is read. The
key can be typed manually in the console, or posted (i.e. PostMessage,
not SendMessage) to the console window as a WM_KEYDOWN message, or the
key event can be written directly to the input buffer via
WriteConsoleInput.

_kbhit calls PeekConsoleInput to scan for key events without removing
them from the input buffer. This call does not block.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Where has the practice of sending screen shots as source code come from?

[eryk sun]

On Sun, Jan 28, 2018 at 4:36 PM, Steven D'Aprano
 wrote:
> On Sun, 28 Jan 2018 15:54:31 +, Tim Golden wrote:
>
>> At least for Windows users, grabbing a partial screenshot (eg of text)
>> has been very easy since Windows 7 when the "Snipping Tool" was added to
>> the builtins.
>
> Thanks, I didn't know that.

It's a common feature in desktop environments. In Ubuntu Linux I can
hit Shift+PrintScreen to select and save part of the screen as a PNG
file, or copy it to the clipboard.

But it's no excuse for sending screen shots of source code.
Fortunately on Stack Overflow I usually see this for command prompt
screenshots of errors, not source code.

>> Certainly easier for the average user than trying to do a
>> slightly tricky rectangle selection within the Windows console.
>
> But I'm not seeing that it could possibly be easier than selecting text
> and hitting copy and paste. Not even in the Windows console, which I
> admit is a bit clunky, let alone a modern IDE. More *familiar*, maybe,
> but easier?

The new console in Windows 10 defaults to line-wrapping selection
instead of rectangle selection. Holding the ALT key temporarily
toggles the selection mode.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Where has the practice of sending screen shots as source code come from?

[eryk sun]

On Mon, Jan 29, 2018 at 5:34 PM, John Gordon  wrote:
>
> The displayed filename in File Explorer was input.txt -- meaning that the
> real filename was actually input.txt.txt, because File Explorer shows file
> extensions as a separate column.

One of the first things I do after creating an account is to modify
Explorer to show all files and not hide extensions. Windows 10 makes
this more discoverable. In the settings page that enables developer
mode, you can configure the system to show file extensions, hidden and
system files, empty drives, the full path in Explorer's title bar, and
the start-menu option to run a program as a different user.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Where has the practice of sending screen shots as source code come from?

[eryk sun]

On Mon, Jan 29, 2018 at 7:43 PM, John Ladasky
 wrote:
> On Sunday, January 28, 2018 at 7:07:11 AM UTC-8, Steven D'Aprano wrote:
>>
>> (The day a programmer posts a WAV file of themselves reading their code
>> out aloud, is the day I turn my modem off and leave the internet forever.)
>
> What's a... modem?

A modem is a MOulator-DEMmodulator. The idea is to transmit a baseband
signal by modulating the amplitude, frequency, or phase of a carrier
signal. At the receiving end, the signal is demodulated back to
baseband. It's a common technique in communication systems (e.g. DSL,
cable, wireless modems -- even optical modems). In popular culture,
people tend to think of telephone-system modems that were common in
the 1980s and 90s.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Handle SIGINT in C and Python (Posting On Python-List Prohibited)

[eryk sun]

On Thu, Feb 1, 2018 at 4:57 AM, Victor Porton  wrote:
> Lawrence D’Oliveiro wrote:
>
>> On Thursday, February 1, 2018 at 8:10:24 AM UTC+13, Victor Porton wrote:
>>> Lawrence D’Oliveiro wrote:
>>>
 The usual behaviour for POSIX is that the call is aborted with EINTR
 after you get the signal.
>>>
>>> That poll() is interrupted does not imply that Python will run its
>>> pythonic signal handler at the point of interruption. That is a problem.
>>
>> * Python calls poll()
>> * poll() aborted with EINTR
>> * Python runs your signal handler
>>
>> Versus native C code:
>>
>> * your code calls poll()
>> * poll() aborted with EINTR
>> * your signal handler is run
>>
>> Where is there a fundamental difference?
>
> I meant to call poll() from C code, not Python code. In this case when
> poll() is aborted with EINTR, the pythonic signal handler does not run.

An extension module should call PyErr_CheckSignals [1] when
interrupted by EINTR. For example, here's the loop used to call poll()
in the standard-library select module:

async_err = 0;
do {
Py_BEGIN_ALLOW_THREADS
errno = 0;
poll_result = poll(self->ufds, self->ufd_len, (int)ms);
Py_END_ALLOW_THREADS

if (errno != EINTR)
break;

/* poll() was interrupted by a signal */
if (PyErr_CheckSignals()) {
async_err = 1;
break;
}

if (timeout >= 0) {
timeout = deadline - _PyTime_GetMonotonicClock();
if (timeout < 0) {
poll_result = 0;
break;
}
ms = _PyTime_AsMilliseconds(timeout, _PyTime_ROUND_CEILING);
/* retry poll() with the recomputed timeout */
}
} while (1);

self->poll_running = 0;

if (poll_result < 0) {
if (!async_err)
PyErr_SetFromErrno(PyExc_OSError);
return NULL;
}

[1]: https://docs.python.org/3/c-api/exceptions.html#c.PyErr_CheckSignals
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Where has the practice of sending screen shots as source code come from?

[eryk sun]

On Fri, Feb 2, 2018 at 6:28 PM, Gilmeh Serda
 wrote:
>
> M$'s excuse for a real Terminal, "Power" Shell (sigh), is _slightly_
> better but still lacking lots of features. Like a decent scripting
> language. I loath VBS. ¦þ,,, /puke

PowerShell is a .NET scripting language that's available in Windows,
Linux, and MacOS. VBScript is an unrelated scripting language that was
more commonly used on Windows before PowerShell came along. On
Windows, powershell.exe either allocates a console or inherits one
from its parent.

The Windows console adapts the message-based desktop environment to
support command-line applications. It provides an input stream with
keyboard and mouse records, and screen buffers that support UCS-2 and
a 16-color palette. In Windows 10, it also functions as a virtual
terminal with 24-bit color.

In Windows 7 and up, each console is hosted by a separate instance of
conhost.exe. Previously, NT systems hosted consoles in the system
process, csrss.exe.

In Windows 8 and up, the console API uses the ConDrv device for IPC
with an attached console. Previously, NT systems used LPC ports and
shared memory for this.

In Windows 9x, the console window was hosted by conagent.exe, and the
API used the VCOND device for IPC.

Despite the ever-changing implementation details, the console API
itself has been relatively stable for about 25 years.

> It does have mouse selection (but still treats the text as a block of
> characters, like a DOS box, and not lines of text, like Terminal)

In Windows 10, the console uses line-wrapping selection by default,
and rectangle selection requires holding ALT.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: abspath returns different results when py_compile input path is different in Python?

[eryk sun]

On Mon, Feb 12, 2018 at 9:40 AM, lampahome  wrote:
> I want to know abspath of python script followed by steps below.
>
>1. *built it to byte code by py_compile.*
>2. *execute it to check abspath.*
>
> But I got *2 results* when I execute it.I found the *results based on the
> path of script* followed by py_compile.
>
> Here is my script test.py :
>
> import os
> import inspect
> print 
> os.path.dirname(os.path.abspath(inspect.getfile(inspect.currentframe(
>
> Build it with py_compile, then got 2 results when I enter *different path
> of test.py*:
>
> *enter the folder and compile with only script name.*
>
> [~] cd /usr/local/bin/
> [/usr/local/bin/] python -m py_compile test.py
> [/usr/local/bin/] cd ~
> [~] python /usr/local/bin/test.pyc
> /home/UserXX
>
> *In other folder and compile with absolute script name.*
>
> [~] python -m py_compile /usr/local/bin/test.py
> [~] python /usr/local/bin/test.pyc
> /usr/local/bin

A code object has a co_filename attribute for use in creating
tracebacks. This path isn't necessarily fully qualified. Here are a
couple of examples using the built-in compile() function:

>>> compile('42', 'test.py', 'exec').co_filename
'test.py'
>>> compile('42', '/usr/local/bin/test.py', 'exec').co_filename
'/usr/local/bin/test.py'

py_compile.compile() does not normalize the filename.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: No shortcut Icon on Desktop

[Eryk Sun]

On 4/15/22, Grant Edwards  wrote:
>
> The problem is that people run the installer, don't see a desktop
> icon, and think nothing has been installed.

Such people need to learn how to use the start menu, where all of
Python's shortcuts are installed in a folder named "Python ". One
can also press the Windows key and type "python" to get a filtered
view of the application shortcuts.

> Or they think the installer "is python", and run it over and over
> again trying to "run Python".

I'm not opposed to renaming the installer to something that makes it
more obvious that it's only an installer. But, to put this in
perspective, I think you're talking about a small number of people out
of the millions of users who I presume install and use Python without
a problem. It could be that thousands of people install Python and
give up without complaining when they can't use it, but I doubt it.

> If the installer, by default, created an IDLE desktop shortcut and a
> cmd.exe shortcut that ran Python, I believe it would eliminate most of
> those problems.

The installed shortcuts are to IDLE (via "pythonw.exe") and
"python.exe". IDLE is a graphical integrated development environment
(shell, editor, debugger) that by default runs an interactive shell.
The "python.exe" executable is a console (terminal) application that
by default runs an interactive shell if its arguments do not specify a
script file, -m module, or -c command to run.

A console application is attached to a console session, a resource
that's hosted by an instance of "conhost.exe" or (in a tab of Windows
Terminal) "openconsole.exe".  It connects to the console session via
files on the ConDrv device (e.g. "\Device\ConDrv\Connect",
"\Device\ConDrv\Input", "\Device\ConDrv\Output").

If an application executable is flagged as a console application, such
as "python.exe", and no console session was inherited from the parent
process, and the process wasn't spawned with the DETACHED_PROCESS
flag, then the Windows base API automatically allocates and attaches
to a new console session at startup during the initialization of
kernelbase.dll. If an application executable is flagged as a graphical
application, such as "pythonw.exe", then a console session is never
inherited and never automatically allocated, but one can be manually
allocated or acquired via AllocConsole() or
AttachConsole(dwProcessId).
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: upgrade pip

[Eryk Sun]

On 4/22/22, Tola Oj  wrote:
> im trying to upgrade my pip so i can install openpyxl. i though i had
> successfully upgraded pip, and then I was trying to install openpyxl, but I
> was getting this:
>
> C:\Users\ojomo>"C:\Program Files\Python310\python.exe" -m pip install
> --upgrade
>
> [...]
>
> "C:\Users\ojomo\AppData\Roaming\Python\Python310\site-packages\pip\__main__.py",
> line 29, in 

You have pip installed for the current user, but Python is installed
for all users. I'd delete the package directory
"%AppData%\Python\Python310\site-packages\pip". Then run ensurepip and
upgrade from an administrator shell. This will install and update pip
for all users.

https://docs.python.org/3/library/ensurepip.html
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to have python 2 and 3 both on windows?

[Eryk Sun]

On 4/23/22, Sunil KR via Python-list  wrote:
>
> I am happy with how the python starts up. When I use python I get
> python 2. I am ok with using py -3 for my new scripts, even using the
> shebang like #!py -3

`#!py -3` is not a valid shebang for the py launcher. Use `#!python3`
to run a script with the highest version of Python 3 that's registered
on your system. Or for cross-platform support, use
`#!/usr/bin/python3`.

> I don't want to put a unix (or for that matter windows) path in the shebang,
> as it is not platform portable

The launcher supports builtin virtual shebangs, including:

* #!python[X[.Y][-32|-64]]
* #!/usr/bin/python[X[.Y][-32|-64]]
* #!/usr/bin/env python[X[.Y][-32|-64]]
* #!/usr/local/bin/python[X[.Y][-32|-64]]

The implementation of the `/usr/bin/env` virtual shebang searches PATH
for a given command that's exactly "python" (no version spec) or any
command that doesn't start with "python". If a "python" command has a
version spec, then PATH is not searched, and it works the same as a
`#!pythonX[.Y]` shebang. The latter is because a normal Python
installation doesn't include versioned executable names, so the
launcher doesn't even try to search PATH for something like
"python3.11.exe".

You can set the default version to use via the PY_PYTHON environment
variable, e.g. `set PY_PYTHON=3.9`. If Python 3 is requested without a
specific version (e.g. via `py -3` at the command line, or the shebang
`#!python3`), then the default 3.x version to run can be set via the
PY_PYTHON3 environment variable, e.g. `set PY_PYTHON3=3.10`. The
default for Python 2 is set similarly via PY_PYTHON2.

The launcher also supports real file paths in shebangs. Generally
you'd only use a real path in order to run in a virtual environment,
such as #!"C:\Path\to\venv\Scripts\python.exe".
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Verifying I installed Python correctly

[Eryk Sun]

On 4/25/22, Barry  wrote:
>
>> On 25 Apr 2022, at 21:14, Jack Dangler  wrote:
>
>> Have you tried
>>
>> python3 hello.py
>
> Will not work on windows. Python is always installed as python.exe and
> py.exe only.

Yes, except the app versions installed from the Microsoft Store do
create appexec aliases for python.exe, python3.exe, and python3.x.exe
(e.g. python3.10.exe). The aliases for installed versions can be
toggled separately, so "python.exe" could be enabled to run 3.9, while
"python3.exe" is enabled to run 3.10. The same applies to the "pip*"
and "idle*" aliases.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Difference in Setup Between Windows 10 Running Python 3.9 and Windows 11 Running Python 3.10

[Eryk Sun]

On 5/1/22, Brent Hunter  wrote:
>
> I was recently running a Windows 10 machine Python 3.9.  I simply created a
> batch file titled "Start-AIG.bat" which simply contained the following:
> "pythonw AIG.py".  It started a python program titled "AIG.py" and the
> Python dialog box was displayed on my screen, running all day and night.  I
> set up Windows to run this batch file upon startup and it worked fine.  I
> remember having to do a bunch of research before I learned that I needed to
> put "pythonw AIG.py" in the batch file as opposed to "python AIG.py".

When running a command at startup, it's best to use the full path of
the application and the full path of any files passed on the command
line. For example, run something like the following:

"path\to\pythonw.exe" "path\to\AIG.py"

This removes any dependency on the search PATH or the current working
directory. Also, the script shouldn't depend on the initial working
directory. Any files that it needs should be in a well-known location,
such as the script directory,
os.path.dirname(os.path.abspath(__file__)).

Also, there's no need to use a batch script just to run a single
command. When you use a batch script, a visible console gets created
for CMD. It doesn't close until CMD exits, which in this case won't be
until pythonw.exe exits, unless you use `START` to run the command
without waiting. It's simpler to just run the command directly using a
shortcut (i.e. LNK file) or the task scheduler.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Windows registry PermissionError

[Eryk Sun]

On 5/12/22, Mike Dewhirst  wrote:
>
>  access=wr.KEY_ALL_ACCESS + wr.KEY_WRITE,

The access parameter is a bit mask of access rights that combine via
bitwise OR (|), not via arithmetic addition.

KEY_ALL_ACCESS (0x000F_003F) is a superset of KEY_WRITE (0x0002_0006):

KEY_WRITE = (
READ_CONTROL   | # 0x0002_
KEY_SET_VALUE  | # 0x_0002
KEY_CREATE_SUB_KEY | # 0x_0004
)# 0x0002_0006

KEY_ALL_ACCESS = (
DELETE | # 0x0001_
READ_CONTROL   | # 0x0002_
WRITE_DAC  | # 0x0004_
WRITE_OWNER| # 0x0008_
KEY_QUERY_VALUE| # 0x_0001
KEY_SET_VALUE  | # 0x_0002
KEY_CREATE_SUB_KEY | # 0x_0004
KEY_ENUMERATE_SUB_KEYS | # 0x_0008
KEY_NOTIFY | # 0x_0010
KEY_CREATE_LINK| # 0x_0020
)# 0x000F_003F

The result of the arithmetic addition `KEY_ALL_ACCESS + KEY_WRITE` is
0x0011_0045, which is wrong and meaningless. Registry key objects do
not support SYNCHRONIZE (0x0010_) access; DELETE (0x0001_)
access isn't needed; 0x_0040 is not a supported key right;
KEY_CREATE_SUB_KEY (0x_0004) access isn't needed; and
KEY_QUERY_VALUE (0x_0001) isn't sufficient.

You should limit the requested access to the specific access rights
that are required for querying and setting values in the key:

access=(wr.KEY_QUERY_VALUE | wr.KEY_SET_VALUE)

> def setvalue(self, vname, value):
>return wr.SetValueEx(self.select(), vname, 0, 1, value)

You shouldn't hard code the value of the data type constant. Use
wr.REG_SZ instead of 1.

The return value of self.select() is a winreg PyHKEY object that wraps
the OS handle for the key object. You're relying on implicit closing
of this handle based on referencing counting. It's cleaner to use it
in a `with` statement, as you would for a file object returned by
open(). For example:

with self.select() as hkey:
wr.SetValueEx(hkey, vname, 0, wr.REG_SZ, value)

>  lmregistry = Registry(
>  hkey=wr.HKEY_LOCAL_MACHINE,
>  sub_key="SOFTWARE\WOW6432Node\XXX Technology\AppName",

You really shouldn't open the "WOW6432Node" key directly. It is an
implementation detail of the WOW64 subsystem that runs 32-bit
applications on a 64-bit system. If you need to operate on the
registry keys of 32-bit applications from a native 64-bit process,
open the normal path using the access right KEY_WOW64_32KEY
(0x_0200). For example:

hkey = wr.HKEY_LOCAL_MACHINE
subkey = r"SOFTWARE\XXX Technology\AppName"
access = (
wr.KEY_QUERY_VALUE |
wr.KEY_SET_VALUE |
wr.KEY_WOW64_32KEY
)

Typically you'd first try opening the path without either
KEY_WOW64_32KEY or KEY_WOW64_64KEY. The default view matches the
current process.

https://docs.microsoft.com/en-us/windows/win32/winprog64/accessing-an-alternate-registry-view

Remember to escape the backslash separators in string literals of key
paths, or use raw string literals as I used in the above example.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [Solved] Re: Windows registry PermissionError

[Eryk Sun]

Since self.connect() is always called, you should document that the
initial hkey parameter has to be one of the following predefined key
handles:

HKEY_LOCAL_MACHINE
HKEY_USERS
HKEY_PERFORMANCE_DATA

WinAPI RegConnectRegistryW() only matters when the target computer is
a different machine, in which case an RPC proxy handle is returned.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [Solved] Re: Windows registry PermissionError

[Eryk Sun]

On 5/13/22, Mike Dewhirst  wrote:
> On 13/05/2022 4:14 pm, Eryk Sun wrote:
>> Since self.connect() is always called, you should document that the
>> initial hkey parameter has to be one of the following predefined key
>> handles:
>>
>>  HKEY_LOCAL_MACHINE
>>  HKEY_USERS
>
> I'm targeting HKEY_CURRENT_USER so I assume HK_USERS includes that.

Using HKEY_CURRENT_USER with RegConnectRegistryW() to access a remote
registry isn't well defined and not documented as supported. If it
works at all, the API probably just opens a subkey of the remote
HKEY_USERS based on the string SID (security identifier string) of the
current user. That may fail as not found since user SIDs are unique to
machines, unless it's on a domain.

Bear in mind that the remote registry service is running on the remote
machine as SYSTEM (S-1-5-18) in the non-interactive services session.
If it literally accessed its "current user", then it would open
"HKEY_USERS\S-1-5-18".
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Seeking deeper understanding of python equality (==)

[Eryk Sun]

On 5/14/22, Jonathan Kaczynski  wrote:
>
> So, I'm still wondering how Py_TYPE(v)->tp_richcompare resolves to __eq__
> on a user-defined class. Conversely, my understanding is, for a type
> defined in cpython, like str, there is usually an explicitly
> defined tp_richcompare function.

Sometimes it's simplest to directly examine an object using a native
debugger (e.g. gdb in Linux; cdb/windbg in Windows).

With a debugger attached to the interpreter, create two classes, one
that doesn't override __eq__() and one that does:

>>> class C:
... pass
...
>>> class D:
... __eq__ = lambda s, o: False
...

In CPython, the id() of an object is its address in memory:

>>> hex(id(C))
'0x2806a705790'
>>> hex(id(D))
'0x2806a6bbfe0'

Break into the attached debugger to examine the class objects:

>>> kernel32.DebugBreak()

(1968.1958): Break instruction exception - code 8003 (first chance)
KERNELBASE!wil::details::DebugBreak+0x2:
7ffd`8818fd12 cc  int 3

Class C uses the default object_richcompare():

0:000> ?? *((python310!PyTypeObject *)0x2806a705790)->tp_richcompare
 0x7ffd`55cac288
 _object*  python310!object_richcompare+0(
_object*,
_object*,
int)

Class D uses slot_tp_richcompare():

0:000> ?? *((python310!PyTypeObject *)0x2806a6bbfe0)->tp_richcompare
 0x7ffd`55cdef1c
 _object*  python310!slot_tp_richcompare+0(
_object*,
_object*,
int)

Source code of slot_tp_richcompare():

https://github.com/python/cpython/blob/v3.10.4/Objects/typeobject.c#L7610-L7626
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Discerning "Run Environment"

[Eryk Sun]

On 5/18/22, Chris Angelico  wrote:
>
> Real solution? Set the command prompt to codepage 65001. Then it
> should be able to handle all characters. (Windows-65001 is its alias
> for UTF-8.)

I suggest using win_unicode_console for Python versions prior to 3.6:

https://pypi.org/project/win_unicode_console

This package uses the console's native 16-bit character support with
UTF-16 text, as does Python 3.6+. Compared to the console's incomplete
and broken support for UTF-8, the console's support for UTF-16 (or
just UCS-2 prior to Windows 10) is far more functional and reliable
across commonly used versions of Windows 7, 8, and 10.

Reading console input as UTF-8 is still limited to ASCII up to and
including Windows 11, which for me is a showstopper. Non-ASCII
characters are read as null bytes, which is useless. Support for
writing UTF-8 to the console screen buffer is implemented correctly in
recent builds of Windows 10 and 11, and mostly correct in Windows 8.
Prior to Windows 8, writing UTF-8 to the console is badly broken. It
returns the number of UTF-16 codes written instead of the number of
bytes written, which confuses buffered writers into writing a lot of
junk to the screen.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: pip does not find after Python 3.10.4 installed

[Eryk Sun]

On 5/26/22, ANTHONY CHU  wrote:
> The Python 3.10.4 (64-bit) and Python Launcher had been (standard) installed
> successfully. But I could not find pip anywhere.  I uninstalled and
> re-installed a couple of times, it is still the problem. I checked the
> installed directory
> C:\Users\x\AppData\Local\Programs\Python\Python310\Tools\Scripts\

FYI, scripts and binaries for packages such as pip are installed in
"Scripts", not in "Tools\Scripts".

In Windows, it's common to run pip via `py -m pip`. Note that the
latter command will use an active virtual environment, if any, else it
defaults to the highest version of Python that's installed. You can
use a specific installed version via `py -X.Y[-32] -m pip`.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: .0 in name

[Eryk Sun]

On 5/28/22, Chris Angelico  wrote:
>
> be extremely confusing; so to keep everything safe, the interpreter
> generates a name you couldn't possibly want - same as for the function
> itself, which is named "" or "", angle brackets
> included.

To clarify, "" is the co_name and co_qualname value of the
code object, which was compiled for the list comprehension. These
names are also used as the __name__ and __qualname__ of the temporary
object that's created by MAKE_FUNCTION. They are not identifiers. The
code object is a constant, which is referenced solely by its index in
the co_consts tuple. The temporary function is referenced on the
stack.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PYLAUNCH_DEBUG not printing info

[Eryk Sun]

On 6/9/22, Peter Otten <__pete...@web.de> wrote:
>
> Looks like the variable is now called PYLAUNCHER_DEBUG:
>
> https://docs.python.org/3.11/using/windows.html#diagnostics

I wonder why Steve changed the name of the environment variable
without supporting the old "PYLAUNCH_DEBUG" name, at least for a
couple of releases. Since 3.11 is still in beta, with the first
release candidate expected in August, there's still time to restore
support for the old name.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: ModuleNotFoundError

[Eryk Sun]

On 6/17/22, Zoltan Szenderak  wrote:
>
> print(sys.version_info) and executable:
> Unable to initialize device PRN

That's the command-line "print" program. You need to first start the
Python shell via python.exe. The prompt should change to ">>> ". Then
run print(sys.version) and print(sys.executable).
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "CPython"

[Eryk Sun]

On 6/20/22, Paulo da Silva  wrote:
>
> Yes, but that does not necessarily means that the C has to refer to the
> language of implementation. It may well be a "core" reference to
> distinguish that implementation from others with different behaviors.

If the reference implementation and API ever switched to a different
programming language, I'd personally be fine with changing the 'C" in
"CPython" to mean "canonical", but not "core". The term "core" is used
for building the interpreter core with access to internals (i.e.
Py_BUILD_CORE, Py_BUILD_CORE_BUILTIN, Py_BUILD_CORE_MODULE, and
Include/internal/pycore*.h). It does not refer to the overall
implementation and API for embedding and extension modules.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Byte arrays and DLLs

[Eryk Sun]

On 6/30/22, Rob Cliffe via Python-list  wrote:
>
> AKAIK it is not possible to give ctypes a bytearray object and persuade
> it to give you a pointer to the actual array data, suitable for passing
> to a DLL.

You're overlooking the from_buffer() method. For example:

>>> ba = bytearray(10)
>>> ca = (ctypes.c_char * len(ba)).from_buffer(ba)
>>> ca.value = b'spam&eggs'
>>> ba
bytearray(b'spam&eggs\x00')

Note that the bytearray can't be resized while a view of the data is
exported. For example:

>>> ba.append(97)
Traceback (most recent call last):
  File "", line 1, in 
BufferError: Existing exports of data: object cannot be re-sized

>>> del ba[-1]
Traceback (most recent call last):
  File "", line 1, in 
BufferError: Existing exports of data: object cannot be re-sized
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: script folder is empty

[Eryk Sun]

On 7/17/22, Scott Baer  wrote:
>
> I've done some troubleshooting, and nothing is in the C:\Program
> Files\Python310\Scripts folder.

The installer may have silently failed to install pip. Run the
following command to check whether the package was installed.

"C:\Program Files\Python310\python.exe" -m pip -V

The standard library includes pip (a third-party package) via the
"ensurepip" bundle. You can use it to install pip with the following
command:

"C:\Program Files\Python310\python.exe" -m ensurepip --default-pip

Since your Python installation is for all users, this command must be
run from an elevated shell, i.e. "run as administrator". If your user
is in the administrators group and UAC is enabled (the default
configuration), then the system logs you on without administrator
rights and privileges. You have to elevate via the UAC consent prompt
in order to run a program with administrator access.

For installing other packages, in most cases you should run pip in a
virtual environment, or at least just for the current user via --user.
Installing to the system site packages should be limited to common
packages that you need for system services and administration across
multiple accounts, such as the pywin32 package.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Pip upgrade causing issues in 3.10

[Eryk Sun]

On 7/20/22, Mike Dewhirst  wrote:
> On 20/07/2022 4:43 am, David Raymond wrote:
>> C:\Program Files\Python310\Scripts>..\python.exe -m pip install --upgrade
>> pip
>> ERROR: Could not install packages due to an OSError: [WinError 32] The
>> process cannot access the file because it is being used by another
>> process: 'c:\\program files\\python310\\scripts\\'
> There's your problem. The 'other' process is your cmd.exe within which
> you are typing etc.
>
> Python scripts dir should be on the path so you don't have to execute
> anything from within it. Windows is obviously tripping over its own toes
> trying to delete and install something in the same dir while you also
> have your foot in it.

This should only occur if uninstalling pip deletes all of the files in
the "Scripts" directory. In this case, pip will 'compress' the
individual delete operations to remove the entire directory. It begins
by trying to 'stash' the "Scripts" directory, i.e. by renaming it to a
temporary adjacent name. It uses shutil.move() for this, which tries
os.rename() and falls back on shutil.copytree() and shutil.rmtree().

Of course this fails with a sharing violation if the directory is open
as the working directory in any process, including the current Python
process, because an open for a working directory doesn't share
delete/rename access. pip fails to handle this error. It crashes and
leaves a mess. The empty "Scripts" directory and the copytree() copy
aren't rolled back properly, and neither are the stashed (renamed)
"pip" and "pip*dist-info" directories in site packages.

This is not user error. It is a bug in pip. It should be able to
recover gracefully from failing to delete the directory. Moreover, it
shouldn't even have to roll back the operations if it deleted the
directory due to compression of explicit removals from the install
"RECORD". In particular there is no reason to delete the "Scripts"
directory, even if it's left empty.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: exec() an locals() puzzle

[Eryk Sun]

On 7/20/22, george trojan  wrote:
>
> 1. This works as I expect it to work:
>
> def f():
> i = 1
> print(locals())
> exec('y = i; print(y); print(locals())')
> print(locals())
> exec('y *= 2')
> print('ok:', eval('y'))
> f()

In CPython, the locals of a function scope (as opposed to a class
scope or module scope) are optimized by storing them in an array in
the current frame. locals(), however, always returns the non-optimized
locals mapping of the current frame, i.e. the value of
sys._getframe(0).f_locals. In the case of optimized locals, the
locals() call first updates this dict with a snapshot of the current
values of local variables. This is useful for introspection, but
modifying the snapshot cannot extend or modify the optimized local
variables of the function scope.

exec() and eval() default to using the global and local variable
mappings that are returned by globals() and locals(). This allows them
to access the snapshot of the containing function's optimized locals,
but they can't extend or modify the function's optimized locals. At
most they can add dynamic locals to the snapshot, as used by
subsequent calls to locals(), exec() and eval().
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Persistent Error: Python was not found

[Eryk Sun]

On 8/13/22, Jonathan Owah  wrote:
>
> I've been trying to configure my laptop to run python scripts.
> This is the error I keep getting:
> Python was not found; run without arguments to install from the Microsoft
> Store, or disable this shortcut from Settings > Manage App Execution
> Aliases.

If you keep seeing this message, then the shell is finding and running
Microsoft's default "python.exe" redirector app execution alias that's
located in "%LocalAppData%\Microsoft\WindowsApps". By default, this
directory is set at the beginning of the user "Path" value in the
registry and thus takes precedence (but not over the system "Path").
Confirm this by running `where.exe python`.

An app execution alias is a special type of filesystem symbolic link
to a store app's executable. These aliases are created in a user's
"%LocalAppData%\Microsoft\WindowsApps" directory. Store apps
themselves are usually installed in "%ProgramFiles%\WindowsApps",
which is a system managed directory that even administrators can't
easily modify (and shouldn't modify). Each user on a system has their
own set of installed store apps, even though the apps are installed
only once at the system level.

By default, Windows creates "python.exe" and "python3.exe" aliases for
the "App Installer" PythonRedirector app. In the alias manager, these
two will be clearly listed as aliases for "App Installer". If you run
this redirector app with one or more command-line arguments, it will
print the above quoted message to the console. If the redirector app
is run without arguments, it will open the Microsoft Store to install
the latest version of the Python store app distribution. Currently
that means Python 3.10.

In my experience, the app execution alias manager component of Windows
is unreliable. A disabled alias might still exist in
"%LocalAppData%\Microsoft\WindowsApps", or an old alias might be left
in place when an app is installed.  Once the real Python store app is
installed, go back into the alias manager and toggle the "python.exe"
and "python3.exe" aliases off and back on. If that doesn't resolve the
problem, manually delete the "python.exe" and "python3.exe" aliases
from "%LocalAppData%\Microsoft\WindowsApps". Then toggle them off and
on again in the alias manager. Hopefully they'll be created to
correctly alias the real Python app instead of the "App Installer"
redirector.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Persistent Error: Python was not found

[Eryk Sun]

On 8/15/22, Jonathan Owah  wrote:
> Thank you so much for your assistance .
>
> The fault was actually mine: I was running a command
> with python3, instead of just python.
> python3 works for Mac, but not Windows.

If the Python 3.10 store app is installed with all aliases enabled,
then "python", "python3", and "python3.10" all work. The standard
distribution from python.org, on the other hand, only has a "python"
executable.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Persistent Error: Python was not found

[Eryk Sun]

On 8/15/22, Gisle Vanem via Python-list  wrote:
> Eryk Sun wrote:
>
>> If the redirector app
>> is run without arguments, it will open the Microsoft Store to install
>> the latest version of the Python store app distribution. Currently
>> that means Python 3.10.
>
> That is true with cmd. But with a shell like 4NT, I get:
>c:\> "%LocalAppData%\Microsoft\WindowsApps\python.exe"
>4NT: (Sys) No access to the file.
> "C:\Users\gvane\AppData\Local\Microsoft\WindowsApps\python.exe"
>
> No matter what I do with this "App Alias" setting.
> What a broken and confusing design this AppX design is.

An app execution alias is a reparse point with the tag
IO_REPARSE_TAG_APPEXECLINK (0x801B). Neither the I/O manager no
any driver in the kernel supports this type of reparse point. For
better or worse, this is intentional. As such, if CreateFileW() is
called on an alias without using the flag
FILE_FLAG_OPEN_REPARSE_POINT, the attempt to traverse the link fails
with ERROR_CANT_ACCESS_FILE (1920). Note that Python's os.stat() was
updated to open the reparse point directly in this case instead of
failing. But a lot of applications, in particular non-Microsoft shells
such as MSYS bash (and apparently 4NT) haven't been updated similarly.

Even if the link could be traversed, the target file under
"%ProgramFiles%\WindowsApps" doesn't grant execute access to users
unless they have an access token that includes a WIN://SYSAPPID
attribute that corresponds to the executed app. How this works in
practice when executing an app is that CreateProcessW() handles
ERROR_CANT_ACCESS_FILE by opening the reparse point, reading the
relevant app information, and creating a custom access token that
allows it to execute the app directly via the internal equivalent of
CreateProcessAsUserW().
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Persistent Error: Python was not found

[Eryk Sun]

On 8/15/22, Dennis Lee Bieber  wrote:
>
>   Just double-clicking on the file will run it. The problem is that it
> will open a command shell, run, and then close the command shell UNLESS one
> explicitly codes some sort of "hold" at the end of the program

The console window is a terminal, not a shell. If an application is
flagged as a console app, as is "python.exe", and the process doesn't
inherit a console, the initialization code in kernelbase.dll allocates
a new console session. This could be implemented by the classic
conhost.exe host, or, in Windows 11, by an openconsole.exe session
that's associated with a tab in Windows Terminal. If it's the latter,
Terminal can be configured to keep a tab open after the console
session has ended. The tab will display the exit status of the process
that allocated the console session.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: subprocess.popen how wait complete open process

[Eryk Sun]

On 8/21/22, simone zambonardi  wrote:
> Hi, I am running a program with the punishment subrocess.Popen(...) what I
> should do is to stop the script until the launched program is fully open.
> How can I do this? I used a time.sleep() function but I think there are
> other ways. Thanks

In Windows, WaitForInputIdle() waits until a thread in a process
creates one or more windows and its message loop goes idle. Usually
this is the main UI thread. Console processes are not supported.

For example:

import ctypes
import subprocess

user32 = ctypes.WinDLL('user32', use_last_error=True)

INFINITE = 0x_
WAIT_FAILED = 0x_
WAIT_TIMEOUT = 0x_0102

# Waiting on a console process fails with ERROR_NOT_GUI_PROCESS.
# This case be handled in other ways, depending on the need.
ERROR_NOT_GUI_PROCESS = 1471

user32.WaitForInputIdle.restype = ctypes.c_ulong
user32.WaitForInputIdle.argtypes = (ctypes.c_void_p, ctypes.c_ulong)

def wait_for_input_idle(proc, timeout=None):
if isinstance(proc, subprocess.Popen):
handle = int(proc._handle)
args = p.args
else:
handle = int(proc)
args = ''
if timeout is None:
timeout_ms = INFINITE
elif timeout < 0:
raise ValueError('timeout cannot be negative')
else:
timeout_ms = int(timeout * 1000)
if timeout_ms >= INFINITE:
raise OverflowError('timeout is too large')
status = user32.WaitForInputIdle(handle, timeout_ms)
if status == WAIT_FAILED:
raise ctypes.WinError(ctypes.get_last_error())
elif status == WAIT_TIMEOUT:
raise subprocess.TimeoutExpired(args, timeout)
assert status == 0
return


if __name__ == '__main__':
import time
t0 = time.time()
p = subprocess.Popen(['pythonw.exe', '-m', 'idlelib'])

try:
wait_for_input_idle(p, 5)
except:
p.terminate()
raise

wait_time = time.time() - t0
print(f'wait time: {wait_time:.3f} seconds')
try:
p.wait(5)
except subprocess.TimeoutExpired:
p.terminate()
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Download Python 3.10.6 for windows

[Eryk Sun]

On 8/30/22, George Rwaga  wrote:
>
> 1. I installed Python 3.10.6 in the default directory
> C:\Users\x.x\AppData\local\programs\Python\Python310
> After the installation, there was no shortcut on my desktop.

Shortcuts are created in the start menu. The installer doesn't modify
the user's desktop or the desktop of all users, which many users don't
want and would find annoying. Just copy the shortcuts from the start
menu to the desktop if that's what you want. Right-click the icon in
the start menu and choose to open the location. You can copy shortcuts
from the opened Explorer window.

> 2. I then decided to install Python3.10.6 in a customized directory
> C:\program files\Python\Python310
> I am being asked to verify access to this directly. I went to properties,
> made what I thought were the relevant changes. But I keep getting asked to
> verify access.

Installing to "Program Files" requires elevating to get administrator
access. All users have the right to read and execute files in a
directory created in "Program Files", but adding, removing, or
deleting files and directories requires administrator access, as it
should.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Download Python 3.10.6 for windows

[Eryk Sun]

On 8/31/22, George Rwaga  wrote:
>
> I am not sure why the default for installing Python is
> C:\Users\x.x\AppData\local\programs\Python\Python310.

The "programs" folder in the above path is the default location to
install programs just for user "x.x." More precisely, the
default location is "%LOCALAPPDATA%\Programs". A user can easily
change this path to a custom location in Explorer, so one shouldn't
rely on the default value in general. Instead, use the shell protocol
path, shell:userprogramfiles. You can use the latter directly in
Explorer, such as the Win+R dialog. From the command line in CMD or
PowerShell, use the `start` command. For example:

>start shell:userprogramfiles

Python's installer defaults to the user program files directory when
installing just for the current user. When the setup is changed to
install for all users, it automatically switches to using
"%ProgramFiles%" or "%ProgramFiles(x86)%" (e.g. "C:\Program Files").
It will try to elevate to get administrator access when installing for
all users.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Local variable definition in Python list comprehension

[Eryk Sun]

On 9/1/22, James Tsai  wrote:
>
> I find it very useful if I am allowed to define new local variables in a
> list comprehension. For example, I wish to have something like
> [(x, y) for x in range(10) for y := x ** 2 if x + y < 80], or
> [(x, y) for x in range(10) with y := x ** 2 if x + y < 80].
>
> For now this functionality can be achieved by writing
> [(x, y) for x in range(10) for y in [x ** 2] if x + y < 80].

You can assign a local variable in the `if` expression. For example:

>>> [(x, y) for x in range(10) if x + (y := x**2) < 30]
[(0, 0), (1, 1), (2, 4), (3, 9), (4, 16)]
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to make a variable's late binding crosses the module boundary?

[Eryk Sun]

On 8/31/22, Jach Feng  wrote:
>
> I found that using "from test import *" in test2.py makes test2's relation
> to "test" almost like the function's relation to the module where it is
> defined. You can refer to all the variables of the module

Note that in general, if __all__ doesn't exist to explicitly define
the contents of a star import, then it imports everything except names
that begin with an underscore.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Can you mock a C function using ctypes?

[Eryk Sun]

On 9/15/22, Grant Edwards  wrote:
>
> Can that be done using ctypes?
>
> For example, I open a library that contains functon foo() where foo()
> calls external function bar() which is not contained in the library.
> Then, I provide a Python bar() function that gets called by foo() when
> foo() is called?

That's straight forward if the library allows the application to pass
a function pointer to bar(). ctypes function prototypes are defined by
ctypes.CFUNCTYPE(restype, *argtypes, use_errno=False,
use_last_error=False) for the cdecl calling convention, or similarly
by ctypes.WINFUNCTYPE() to use the Windows stdcall calling convention.
A prototype can be instantiated as a function pointer that calls a
Python function, e.g. c_bar = prototype(bar).
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Can you mock a C function using ctypes?

[Eryk Sun]

On 9/15/22, Grant Edwards  wrote:
>
> Does the pointer have to be passed? Or can it be "poked" into a global
> variable?

If the library exports the function pointer as a global variable, it
can be set in ctypes using the in_dll() method. Unfortunately, as far
as I know, a ctypes function prototype can't be used directly for
this, at least not easily, since the function pointer it creates
doesn't have a `value` or `contents` attribute to set the target
address. Instead, the exported global can be accessed as a void
pointer. It's clunky, but it works.

For example, Python's REPL supports a callback for reading a line from
the terminal. Normally it's either hooked by a C extension, such as
the readline module, or set to the default function
PyOS_StdioReadline(). We can use a ctypes callback to hook into this
and chain to the previous function.

import ctypes

PyOS_RFP = ctypes.CFUNCTYPE(
ctypes.c_void_p,
ctypes.c_void_p, # stdin (FILE *)
ctypes.c_void_p, # stdout (FILE *)
ctypes.c_char_p, # prompt
)

@PyOS_RFP
def readline_hook(stdin, stdout, prompt):
print('HOOKED: ', end='', flush=True)
return prev_rfp(stdin, stdout, prompt)

rfp_vp = ctypes.c_void_p.in_dll(ctypes.pythonapi,
'PyOS_ReadlineFunctionPointer')

if rfp_vp:
# there's a previous RFP that can be hooked
prev_rfp = ctypes.cast(rfp_vp, PyOS_RFP)
rfp_vp.value = ctypes.cast(readline_hook, ctypes.c_void_p).value

In this trivial example, "HOOKED: " is printed to the terminal before
each line is read:

HOOKED: >>> def f():
HOOKED: ... pass
HOOKED: ...
HOOKED: >>>

Note that I defined the return type of PyOS_RFP to be c_void_p. Using
c_char_p as the return type would convert the result to a bytes
object, which is wrong in this case. If the setfunc of the callback's
return type has to keep a reference to a converted Python object, such
as a bytes object, then the callback has no choice but to leak the
reference in order to keep the object alive indefinitely, which
usually causes a memory leak.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to replace an instance method?

[Eryk Sun]

On 9/16/22, Ralf M.  wrote:
> I would like to replace a method of an instance, but don't know how to
> do it properly.

A function is a descriptor that binds to any object as a method. For example:

>>> f = lambda self, x: self + x
>>> o = 42
>>> m = f.__get__(o)
>>> type(m)

>>> m.__self__ is o
True
>>> m(10)
52
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to replace an instance method?

[Eryk Sun]

On 9/17/22, Chris Angelico  wrote:
>
> The two are basically equivalent. Using functools.partial emphasizes
> the fact that all you're doing is "locking in" the first parameter;
> using the __get__ method emphasizes the fact that functions are,
> fundamentally, the same thing as methods. Choose whichever one makes
> sense to you!

Functions are really not "fundamentally, the same thing as methods".
They're only the same in that they're both callable. Also, a method's
__getattribute__() falls back on looking up attributes on the
underlying function (i.e. the method's __func__), such as inspecting
the __name__ and __code__. A fundamental difference is that, unlike a
function, a method is not a descriptor. Thus if a method object is set
as an attribute of a type, the method does not rebind as a new method
when accessed as an attribute of an instance of the type.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to replace an instance method?

[Eryk Sun]

On 9/17/22, Chris Angelico  wrote:
>
> A method IS a function. A bound method is a function with one argument
> locked in, but still a function.

We were talking past each other. A method object is not a function
object. You're talking about a function defined in a class that's
accessed as a method of an instance of the class. In the class, that's
just a function object; it's exactly a function, not merely
fundamentally the same thing as one. It's only when accessed as an
attribute of an instance of the type that the function's descriptor
__get__() method is called to bind it and the instance to a method
object that sets the instance as its __self__ and the function as its
__func__.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to replace an instance method?

[Eryk Sun]

On 9/18/22, Stefan Ram  wrote:
> r...@zedat.fu-berlin.de (Stefan Ram) writes (abbreviated):
>>types.MethodType( function, instance )
>>functools.partial( function, instance )
>>new_method.__get__( instance )
>
>   I wonder which of these three possibilities expresses
>   the idea of creating a new method from a function and
>   an instance most clearly.

Using types.MethodType(function, instance) is the most clear and
correct of the three. Using the function's descriptor __get__() method
is equivalent in terms of the result. That said, the descriptor
protocol is an intermediate-level concept, so manually calling
__get__() isn't friendly to novices or casual users of the language.

Using a functools.partial isn't the expected method type, with
__func__ and __self__ attributes, and, unlike a method, it doesn't
expose the wrapped function's __code__, __name__, __module__, __doc__,
__annotations__, __defaults__, __kwdefaults__, __closure__,
__globals__, or __builtins__. If dynamic inspection matters, using a
functools.partial won't work directly with dis.dis(),
inspect.getfile(), inspect.getsource(), inspect.getdoc(),
inspect.get_annotations(), inspect.getcallargs(), or
inspect.getclosurevars().
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to replace an instance method?

[Eryk Sun]

On 9/19/22, 2qdxy4rzwzuui...@potatochowder.com
<2qdxy4rzwzuui...@potatochowder.com> wrote:
> On 2022-09-18 at 09:11:28 +,
> Stefan Ram  wrote:
>
>> r...@zedat.fu-berlin.de (Stefan Ram) writes (abbreviated):
>> >types.MethodType( function, instance )
>> >functools.partial( function, instance )
>> >new_method.__get__( instance )
>>
>>   I wonder which of these three possibilities expresses
>>   the idea of creating a new method from a function and
>>   an instance most clearly.
>
> The first one.  And only the first one.
>
> The second one requires too much inside knowledge of Python to make the
> leap from currying to instance method.
>
> The third one doesn't even mention the function.

The OP's example named the function "new_method". In general the third
case would be func.__get__(instance). It's how the interpreter binds a
new method when a function from the class hierarchy is accessed as an
instance attribute.

When a function from the class hierarchy is accessed as an attribute
of the class, it's equivalent to calling func.__get__(None, cls),
which just returns a reference to the function. To use the descriptor
protocol to bind a function as a method of the class requires wrapping
it with the classmethod descriptor type. For example,
classmethod(func).__get__(None, cls) returns a method object with
__self__ that references the cls type. Of course, calling
types.MethodType(func, cls) is easier to understand and the preferred
way.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Debugging automatic quotation in subprocess.Popen()

[Eryk Sun]

On 10/7/22, c.bu...@posteo.jp  wrote:
>
> I need to improve my understanding about how subprocess.Popen() does
> quote arguments. I have special case here.
>
> Simple example:
> Popen(['ls', '-l']) results on a shell in "ls -l" without quotation.

The shell is only used if Popen is instantiated with `shell=True`. The
above example does not use the shell. It runs the "ls" executable
directly. On POSIX systems, fork() and exec() are called to create the
child process. The argument list is passed to exec() and becomes the
argv array of the application's main() entry point function.

On Windows systems, CreateProcessW() is called to created the child
process. It requires a command-line string instead of an argument
array. The argument list gets joined into a command-line string via
subprocess.list2cmdline(), which is based on the rules that are used
by the Windows C runtime library when it parses a command line into
the argv array of an application's [w]main() entry point. That said, a
Windows application is free to parse its command line however it
wants, so listcmdline() is little more than a best guess. On Windows,
Popen() may have to be called directly with a command-line string in
some cases.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to fix Python error, The term '.../python.exe' is not recognized as the name of a cmdlet, function, script file, or operable program, in VS Code?

[Eryk Sun]

On 10/11/22, LouisAden Capellupo via Python-list  wrote:
> Variables. 
> C:\Users\It'sMeLil'Loui\AppData\Local\Programs\Python\Python310\Scripts\,
> and C:\Users\It'sMeLil'Loui\AppData\Local\Programs\Python\Python310\.

I suggest that you switch to a user account that doesn't have single
quotes in the name. Using a name that contains single quotes is asking
for trouble. In most command-line shells, which includes PowerShell
(but not CMD), a literal (verbatim) string is contained by single
quotes. The shell usually consumes the quote character if it's not
escaped. See the following sections of the PowerShell documentation:

https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_quoting_rules?view=powershell-7.2#single-quoted-strings

https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_quoting_rules?view=powershell-7.2#including-quote-characters-in-a-string
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Fail 3.10.8 version installation on Windows 11 21H2

[Eryk Sun]

On 10/12/22, Kirill Ratkin via Python-list  wrote:
>
> Do anyone face issue like in log below?
>
> I got last installer (3.10.8) and try to install it 'for all users' with
> downloading precompiled (pdb) files.

There was a permission problem on the Python website that prevented
downloading the 3.8.10 debug binaries and symbol files. It's fixed
now.

https://github.com/python/cpython/issues/98193
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Find the path of a shell command (shutil.which)

[Eryk Sun]

On 10/12/22, Weatherby,Gerard  wrote:
>
> When no path is specified, the results of
> os.environ() are used,
> returning either the “PATH” value or a fallback of
> os.defpath.

The documentation is out of sync with what the code actually does.
os.defpath is hard coded in posixpath and ntpath, but shutil.which()
actually prefers to query the system's default path to use via
os.confstr(), if it's supported:

if path is None:
path = os.environ.get("PATH", None)
if path is None:
try:
path = os.confstr("CS_PATH")
except (AttributeError, ValueError):
# os.confstr() or CS_PATH is not available
path = os.defpath

As documented by POSIX, the CS_PATH string "can be used as a value of
the PATH environment variable that accesses all of the standard
utilities of POSIX.1-2017, that are provided in a manner accessible
via the exec family of functions".

https://pubs.opengroup.org/onlinepubs/9699919799/functions/confstr.html
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Problems with IDLE in Windows 8.1 and installer x86 Version 3.10.8

[Eryk Sun]

On 10/31/22, darkst...@o2online.de  wrote:
>
> i uninstalled this, because my Idle doesn’t start by clicking on the Icon.
> Are there any Solutions for the problem?

If it's the standard distribution from python.org, run the installer
again, and ensure that the test suite is installed.

In 3.10.8, IDLE mistakenly depends on the test suite. This mistake is
fixed in 3.10.9, which is planned to be released in early December.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Problems with IDLE in Windows 8.1 and installer x86 Version 3.10.8

[Eryk Sun]

On 10/31/22, darkst...@o2online.de  wrote:
>
> I installed the Standard Distribution from python.org again, and i ensured,
> that the checkmark test Suite is enabled. Idle does’nt start. The installer
> says “Installation successfully” at the end.
>
> What went wrong and how can I further delimit the fault/find the error?

Open a command prompt and run the following command:

py -3.10-32 -m idlelib

If it fails, an exception and traceback should be printed to the console.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Problems with IDLE in Windows 8.1 and installer x86 Version 3.10.8

[Eryk Sun]

On 11/1/22, darkst...@o2online.de  wrote:
>
> **IDLE can’t Import TKINTER
>
> Python may not be configured for TK**
>
> Checkmark for TK is set in the Installation Progress. What went wrong and ho
> can I fix it?

Run the following command to check whether the ImportError has any
further information.

py -3.10-32 -c "from tkinter import *"

It could be a missing extension module or DLL, or mismatched version.
You could try modifying the installation to remove tkinter and IDLE,
and then again to restore it.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Problems with IDLE in Windows 8.1 and installer x86 Version 3.10.8

[Eryk Sun]

On 11/1/22, Nithish Ramasamy  wrote:
>
> pip install tkinter
> Wait some minutes to install tkinter

There is no tkinter package on PyPI. It's part of the standard library
and included with the python.org installer as an optional component.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Problems with IDLE in Windows 8.1 and installer x86 Version 3.10.8

[Eryk Sun]

On 11/3/22, darkst...@o2online.de  wrote:
> Is there a reason, why it is not installed? Its the same check mark in the
> installer like IDLE…

Did you try what I suggested? Modify the installation to remove the
tkinter/IDLE component. Then modify it again to select the component
to be reinstalled. Also, try to repair the installation. This may
reset any DLLs or extension modules that were missing or that were the
wrong version.

Ignore the suggestion from Nithish to install tkinter via pip. tkinter
is part of the standard library and cannot be installed via pip. There
is no tkinter package on the Python package index (pypi.org).
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Problems with IDLE in Windows 8.1 and installer x86 Version 3.10.8

[Eryk Sun]

On 11/9/22, darkst...@o2online.de  wrote:
> Is there no one who can help?

If you can't run IDLE via `py -3.10-32 -m idlelib`, then something
isn't installed properly. You reported an error that IDLE fails to
load because importing tkinter fails. Did you try `import tkinter` in
the REPL? tkinter depends on the _tkinter extension module. Try
`import _tkinter`. If the latter fails because of a missing DLL
dependency, check the "DLLs" directory in the installation directory
for the TCL/Tk dependencies. They're "tcl86t.dll" and "tk86t.dll" for
Python 3.10. The installation directory should also have a "tcl"
directory, which should contain "tcl8.6" and "tk8.6" directories among
others, with many .tcl files.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Problems with IDLE in Windows 8.1 and installer x86 Version 3.10.8

[Eryk Sun]

On 11/11/22, darkst...@o2online.de  wrote:
>
> What can I do for the next step to find, why IDLE isn’t working?

The question is why tkinter isn't working. IDLE not working is just a
symptom of the underlying problem. In the command prompt, run 32-bit
Python 3.10 via `py -3.10-32`. In Python's interactive shell, run
`import _tkinter`. Please paste any resulting traceback and error
message in your reply to this message.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Strange UnicodeEncodeError in Windows image on Azure DevOps and Github

[Eryk Sun]

On 11/10/22, Jessica Smith <12jessicasmit...@gmail.com> wrote:
>
> Weird issue I've found on Windows images in Azure Devops Pipelines and
> Github actions. Printing Unicode characters fails on these images because,
> for some reason, the encoding is mapped to cp1252. What is particularly
> weird about the code page being set to 1252 is that if you execute "chcp"
> it shows that the code page is 65001.

If stdout isn't a console (e.g. a pipe), it defaults to using the
process code page (i.e. CP_ACP), such as legacy code page 1252
(extended Latin-1). You can override just sys.std* to UTF-8 by setting
the environment variable `PYTHONIOENCODING=UTF-8`. You can override
all I/O to use UTF-8 by setting `PYTHONUTF8=1`, or by passing the
command-line option `-X utf8`.

Background

The locale system in Windows supports a common system locale, plus a
separate locale for each user. By default the process code page is
based on the system locale, and the thread code page (i.e.
CP_THREAD_ACP) is based on the user locale. The default locale of the
Universal C runtime combines the user locale with the process code
page. (This combination may be inconsistent.)

In Windows 10 and later, the default process and thread code pages can
be configured to use CP_UTF8 (65001). Applications can also override
them to UTF-8 in their manifest via the "ActiveCodePage" setting. In
either case, if the process code page is UTF-8, the C runtime will use
UTF-8 for its default locale encoding (e.g. "en_uk.utf8").

Unlike some frameworks, Python has never used the console input code
page or output code page as a locale encoding. Personally, I wouldn't
want Python to default to that old MS-DOS behavior. However, I'd be in
favor of supporting a "console" encoding that's based on the console
input code page that's returned by GetConsoleCP(). If the process
doesn't have a console session, the "console" encoding would fall back
on the process code page from GetACP().
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Create a Python Launcher on Desktop

[Eryk Sun]

On 11/11/22, ohins...@gmail.com  wrote:
>
> I am real a beginner of Python.  Not able to create a Python launcher
> (shortcut) on Desktop after the installation.

Did you already install Python? If not, open the Store, and install
the Python 3.11 app that's published by the Python Software
Foundation. After Python is installed, you'll have shortcuts in the
start menu that run Python in a terminal or that run the IDLE
development environment.

On the context menu of a shortcut, there's an action to pin it to the
top-level start menu, which is more convenient than having to click on
"all apps" to find it. Also, the context menu of a pinned shortcut has
an action to pin it to the taskbar, for even more convenient access.
The running application icon on the taskbar also lets you pin the app.

If you really want a shortcut on your desktop, it depends on which
distribution you installed. If you installed the app version of 3.11,
then you have "python3.11.exe" to run Python in a terminal and
"idle3.11.exe" to IDLE. To create a shortcut, right click the desktop;
select the action to create a new shortcut; and enter one of the
latter executable names. After creating the shortcut, on its context
menu select the "properties" action, and then modify the "start in"
folder to your preferred working directory.

If you installed the standard distribution from python.org, then you
already have normal file shortcuts (as opposed to app shortcuts) in
the start menu, which you can copy to the desktop. The context menu of
the start-menu shortcut has an action to open the file location. This
opens an Explorer window. Right click the shortcut in that window and
drag it to the desktop. Release the mouse button and select the action
"copy here".
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Strange UnicodeEncodeError in Windows image on Azure DevOps and Github

[Eryk Sun]

On 11/11/22, 12Jessicasmith34 <12jessicasmit...@gmail.com> wrote:
>
> any idea why this would be happening in this situation? AFAIK, stdout
> *is* a console when these images are running the python process.

If sys.std* are console files, then in Python 3.6+,
sys.std*.buffer.raw will be _io._WindowsConsoleIO. The latter presents
itself to Python code as a UTF-8 file stream, but internally it uses
UTF-16LE with the wide-character API functions ReadConsoleW() and
WriteConsoleW().

> is there a way I can check the locale and code page values that you
> mentioned? I assume I could call GetACP using ctypes, but maybe
> there is a simpler way?

io.TextIOWrapper uses locale.getpreferredencoding(False) as the
default encoding. Actually, in 3.11+ it uses locale.getencoding()
unless UTF-8 mode is enabled, which is effectively the same as
locale.getpreferredencoding(False). On Windows this calls GetACP() and
formats the result as "cp%u" (e.g. "cp1252").
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Problems with IDLE in Windows 8.1 and installer x86 Version 3.10.8

[Eryk Sun]

On 11/12/22, darkst...@o2online.de  wrote:
>
 import _tkinter
> Traceback (most recent call last):
>   File "", line 1, in 
> ImportError: DLL load failed while importing _tkinter: Das angegebene Modul
> wurd
> e nicht gefunden.

Loading the extension module "_tkinter.pyd" tries to load two TCL/Tk
DLL files that should be in the same directory: "tcl86t.dll" and
"tk86t.dll". Previously I asked you to look for these two files, and
you said they were there, but maybe one is corrupt.

Please try the following in the interactive shell:

import os, sys, ctypes
tcl86 = os.path.join(sys.prefix, 'DLLs', 'tcl86t.dll')
tk86 = os.path.join(sys.prefix, 'DLLs', 'tk86t.dll')

Run the following two statements one after the other in the shell:

ctypes.CDLL(tcl86)
ctypes.CDLL(tk86)

Either or both will fail if the DLL or one of its dependencies can't
be found or loaded.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python 3.7+ cannot print unicode characters when output is redirected to file - is this a bug?

[Eryk Sun]

On 11/13/22, Jessica Smith <12jessicasmit...@gmail.com> wrote:
> Consider the following code ran in Powershell or cmd.exe:
>
> $ python -c "print('└')"
> └
>
> $ python -c "print('└')" > test_file.txt
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "C:\Program Files\Python38\lib\encodings\cp1252.py", line 19, in
> encode
> return codecs.charmap_encode(input,self.errors,encoding_table)[0]
> UnicodeEncodeError: 'charmap' codec can't encode character '\u2514' in
> position 0: character maps to 

If your applications and existing data files are compatible with using
UTF-8, then in Windows 10+ you can modify the administrative regional
settings in the control panel to force using UTF-8. In this case,
GetACP() and GetOEMCP() will return CP_UTF8 (65001), and the reserved
code page constants CP_ACP (0),  CP_OEMCP (1), CP_MACCP (2), and
CP_THREAD_ACP (3) will use CP_UTF8.

You can override this on a per-application basis via the
ActiveCodePage setting in the manifest:

https://learn.microsoft.com/en-us/windows/win32/sbscs/application-manifests#activecodepage

In Windows 10, this setting only supports "UTF-8". In Windows 11, it
also supports "legacy" to allow old applications to run on a system
that's configured to use UTF-8.  Setting an explicit locale is also
supported in Windows 11, such as "en-US", with fallback to UTF-8 if
the given locale has no legacy code page.

Note that setting the system to use UTF-8 also affects the host
process for console sessions (i.e. conhost.exe or openconsole.exe),
since it defaults to using the OEM code page (UTF-8 in this case).
Unfortunately, a legacy read from the console host does not support
reading non-ASCII text as UTF-8. For example:

>>> os.read(0, 6)
SPĀM
b'SP\x00M\r\n'

This is a trivial bug in the console host, which stems from the fact
that UTF-8 is a multibyte encoding (1-4 bytes per code), but for some
reason the console team at Microsoft still hasn't fixed it. You can
use chcp.com to set the console's input and output code pages to
something other than UTF-8 if you have to read non-ASCII input in a
legacy console app. By default, this problem doesn't affect Python's
sys.stdin, which internally uses wide-character ReadConsoleW() with
the system's native text encoding, UTF-16LE.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: unable to resolve readline issues

[Eryk Sun]

On 12/2/22, biglee12...@gmail.com  wrote:
>
> From this point on Python became unusable as I uninstalled rebooted then
> reinstalled to find I have the same issues as stated.  Finally uninstalled
> Python as it doesn't perform as usual especially trying to understand the
> use of pyreadline, gnureadline and or just readline.

When Python runs interactively, it implicitly tries to import the
readline module. On POSIX, Python has a builtin readline module that
usually uses the GNU Readline library.

On Windows, Python does not include a readline module. Instead, if
standard I/O is a console, the high-level WinAPI ReadConsoleW()
function is used, which implements its own line editor and
command-line history. It's not as general, flexible, or capable as the
readline interface, so a third-party pyreadline package was
implemented for Windows. However, as far as I know, pyreadline is no
longer actively developed. Thus it has out-of-date code, which may be
broken in newer releases of Python, such as isinstance(x,
collections.Callable).

Your choice is to either patch pyreadline to fix the bug or uninstall it.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Installation hell

[Eryk Sun]

On 12/18/22, Jim Lewis  wrote:
>
> Sometimes it's a path issue.

For whatever reason, Python installations on Windows lack versioned
executable names (except for the Microsoft Store distribution). Thus
adding multiple installations to PATH doesn't help unless "python.exe"
is manually linked or copied to versioned names, e.g. "python3.11.exe"
-> "python.exe" and "python3.exe" -> "python.exe". In this case, the
first installation in PATH is the default for running "python" and
"python3".

Using the "py.exe" launcher is the more general and preferred
solution. It allows running any registered Python installation. It's
also the installed handler for the ".py" file type, and it supports
Unix-style shebangs.

> Or exe naming confusion: python, python3, phthon311, etc.

I don't understand what's supposedly confusing here. Here are some
commands to help discover what "py" or "python" commands and
installations are available.

* CMD: where py*.exe
* PowerShell: get-command py*.exe
* Python launcher: py --list-paths

> Or library compatibility issues - took an hour to find out that
> pygame does not work with the current version of python.

It should be a trivial task to discover that wheel packages for pygame
aren't currently available for Python 3.11. It is not unreasonable to
expect Python developers to familiarize themselves with pip and PyPI.

If you search a bit deeper, you'll find a site with unofficial Windows
builds of many packages, including pygame for Python 3.11:

https://www.lfd.uci.edu/~gohlke/pythonlibs/#pygame

Otherwise, while building some packages from source can be quite
involved and difficult, I'd expect anyone with a degree in computer
science to be able to build pygame if necessary. They even provide a
simple guide:

https://www.pygame.org/wiki/CompileWindows

> Then the kludgy PIP app and using a DOS box under Windows with
> command prompts which is ridiculous.

How is pip "kludgy" (i.e. sloppy, hasty, shoddy, or inelegant)? How is
using a command-line interface "ridiculous"? Many programmers and
system administrators actually prefer using command-line interfaces
and text user interfaces (TUI) for many if not most development and
administration tasks. It's a matter of opinion.

---

Nerdy operating system discussion...

> using a DOS box under Windows

The term "DOS box" refers to a virtual machine running 16-bit MS-DOS
in virtual 8086 (v86) mode under Windows 3.1 or Windows 9x, with the
MS-DOS keyboard and display drivers hooked to redirect I/O to a
desktop window. There is no "DOS box" in Windows NT systems. Windows
client systems switched to NT starting with Windows XP. Thus the term
"DOS box" is about two decades out of date.

Also, "DOS" is not synonymous with a command-line interface shell
(e.g. the 16-bit MS-DOS shell, "COMMAND.COM"). A "Disk Operating
System" is one that supports disk drives and filesystems, which
includes most operating systems from the late 1960s onward (e.g.
DOS/360 from 1966). There were several DOS systems for personal
computers in the 1980s, such as Apple ProDOS, Atari DOS, Tandy TRSDOS,
Commodore DOS, and Microsoft MS-DOS. A DOS system can use a graphical
shell, such as running Windows 1.0 (1985) on MS-DOS.

The "python.exe" executable is a Windows application that's flagged to
require a console session. If it doesn't inherit a console session,
then the system allocates one automatically. However, any Windows
application can allocate, attach to, and detach from a console session
via AllocConsole(), AttachConsole(), and FreeConsole().

Prior to Windows 7, each console session in the current NT session is
hosted on threads in the subsystem process for Windows, "csrss.exe".
Starting with Windows 7, console sessions are hosted by instances of
"conhost.exe". The console host also implements a builtin terminal
window for command-line interface (CLI) and text user interface (TUI)
applications. (A console session can be allocated without a terminal
window if a console application is spawned with the creation flag
CREATE_NO_WINDOW.)

Prior to Windows 10, the connection between a console session and its
terminal is hardwired in the console host. This makes it difficult to
implement an alternate terminal, though some alternate terminals have
managed to do so in creative ways (e.g. ConEmu). Starting with Windows
10, alternate terminals can use an open source implementation of the
console host, named "openconsole.exe". The most important example is
Microsoft's "Windows Terminal". Starting with Windows 11, an alternate
terminal can also register as the default terminal for console
applications. For example, if Windows Terminal is set as the default
terminal, then running "python.exe" from Explorer opens a new tab in
Terminal.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to enter escape character in a positional string argument from the command line?

[Eryk Sun]

On 12/19/22, Jach Feng  wrote:
>
> That's really good for Linux user! How about Windows?

In CMD, typing the "^" escape character at the end of a line ignores
the newline and prompts for "more" input. If you press enter again,
you'll get another "more" prompt in which you can write the rest of
the command line. Command-line arguments are separated by spaces, so
you have to start the next line with a space if you want it to be a
new argument. Also, "^" is a literal character when it's in a
double-quoted string, which requires careful use of quotes. For
example:

C:\>py -c "import sys; print(sys.orig_argv[3:])" spam^
More?
More?  eggs^
More?
More? " and spam"
['spam\n', 'eggs\n and spam']

The above is easier in PowerShell, which supports entering multiline
strings without having to escape the newline. The second-level prompt
is ">> ". For example:

> py -c "import sys; print(sys.orig_argv[3:])" spam"
>> " eggs"
>>  and spam"
['spam\n', 'eggs\n and spam']
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Fwd: Installation hell

[Eryk Sun]

On 12/19/22, Chris Angelico  wrote:
> On Tue, 20 Dec 2022 at 09:12, Thomas Passin  wrote:
>
>> @echo off
>> setlocal
>> : Find effective drive for this file.
>> set ed=%~d0
>> path %ed%\python37\Scripts;%ed%\python37;%PATH%

For reference, in case not everyone on the list knows what "%~d0"
means, the CMD shell supports extracting the drive (d), path (p), name
(n), and extension (x) components of a path name that's stored in a
parameter such as "%0". The full path (f) is resolved beforehand. For
example:

C:\Temp>set var=spam\eggs.py

C:\Temp>for %c in (%var%) do @echo drive: "%~dc"
drive: "C:"

C:\Temp>for %c in (%var%) do @echo path: "%~pc"
path: "\Temp\spam\"

C:\Temp>for %c in (%var%) do @echo name: "%~nc"
name: "eggs"

C:\Temp>for %c in (%var%) do @echo extension: "%~xc"
extension: ".py"

C:\Temp>for %c in (%var%) do @echo full path: "%~dpnxc"
full path: "C:\Temp\spam\eggs.py"

C:\Temp>for %c in (%var%) do @echo full path: "%~fc"
full path: "C:\Temp\spam\eggs.py"

 > So much easier to do on a Unix-like system, where you don't need to
> concern yourself with "effective drive" and can simply use relative
> paths.

A relative path in the PATH environment variable would depend on the
current working directory. Surely the added paths need to be absolute.
However, Thomas didn't have to reference the drive explicitly. The
expression "%~dp0" is the fully-qualified directory of the executing
batch script, and an absolute path can reference its ancestor
directories using ".." components.

> I know we're not here to bash Windows, but... drive letters
> really need to just die already.

I don't foresee drive-letter names getting phased out of Windows. And
Windows itself is unlikely to get phased out as long as Microsoft
continues to profit from it, as it has for the past 37 years.

The drive concept is deeply ingrained in the design of NT, the Windows
API, shells, and applications. While assigning drive names "A:", "B:",
and "D:" to "Z:" can be avoided, the system volume, i.e. drive "C:",
still has to be accessed in the normal way, or using another one of
its persistent names, such as r"\\?\BootPartition".

The latter still uses the filesystem mount point on the root path of
the device (e.g. "?\\BootPartition\\"), which you probably take
issue with. That's a deeply ingrained aspect of Windows. Even mount
points set on filesystem directories are actually bind mount points
that ultimately resolve to the root path on the volume device (e.g.
"\\Device\\HarddiskVolume4\\").  This differs from how regular mount
points work on Unix, for which a path like "/dev/sda1/etc" is
gibberish.

Below I've outlined the underlying details of how logical drives (e.g.
"C:"), UNC shares (e.g. r"\\server\share"), other device names, and
filesystem mount points are implemented on NT.

---

NT Device Names

In contrast to Unix, NT is organized around an object namespace, not a
root filesystem. Instances of many object types can be named. Some
named object types also support a parse routine for paths in the
namespace of an object (e.g. the configuration manager's registry
"Key" type and the I/O manager's "Device" type).

The object manager uses two object types to define the object
namespace: Directory and Symbolic Link. Directory objects form the
hierarchical tree. At the base of the tree is the anonymous root
directory object (i.e. "\\"). A directory is implemented as a hashmap
of named objects. A directory can be set as the shadow of another
directory, creating a union directory for name lookups.

Unless otherwise stated, the following discussion uses "directory" and
"symlink" to refer to a directory object and a symbolic-link object,
respectively -- not to a filesystem directory or filesystem symlink.

A canonical NT device name (e.g. "C:", "PIPE", "UNC") is implemented
in the object namespace as a symlink that targets the path of a real
device object. The real device is typically in the r"\Device"
directory. A canonical device name might be a persistent name for an
enumerated device (e.g. "C:" -> r"\Device\HarddiskVolume2"). In some
cases the real device name is persistent, but it's different from the
canonical name (e.g. "PIPE" -> r"\Device\NamedPipe", or "UNC" ->
r"\Device\Mup").

The symlink that implements a canonical device name is created either
in the r"\Global??" directory or in a directory that's used for local
device names in a given logon session (e.g.
r"\Sessions\0\DosDevices\"). The global device
directory generally contains system devices. Mapped drives and
substitute drives typically use a local device directory, so users
don't have to worry about conflicting drive assignments in these
cases.

The global device directory is the shadow of each local device
directory, forming a union for name lookups. If the same device name
is defined in both the local and global directories, the local device
name takes precedence. However, each local device directory also
contains 

Re: What should go to stdout/stderr and why Python logging write everything to stderr?

[Eryk Sun]

On 1/3/23, c.bu...@posteo.jp  wrote:
>
> If the user request the usage info via "-h" it goes to stdout.

The standard file for application output is sys.stdout. Note that
sys.stdout may be buffered, particularly if it isn't a tty. When a
file is buffered, writes are aggregated and only written to the OS
file when the buffer fills up or is manually flushed.

> Why does logging behave different? DEBUG and INFO imho should go to
> stdout not stderr.

The standard file for error messages and other diagnostic information
is sys.stderr. This file should never be buffered.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What should go to stdout/stderr and why Python logging write everything to stderr?

[Eryk Sun]

On 1/3/23, Weatherby,Gerard  wrote:
> If sys.stdout is a tty, it typically flushes on newline. e. g.

Sorry if I wasn't clear. Yes, a tty file will be buffered, but it's
line buffering, which isn't an issue as long as lines are written to
stdout. I was referring to full buffering of pipe and disk files. This
can be a problem when printing diagnostics. We went the information
written to the file immediately, not whenever the buffer happens to
fill up. Thus sys.stderr is unbuffered.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What should go to stdout/stderr and why Python logging write everything to stderr?

[Eryk Sun]

On 1/3/23, Chris Angelico  wrote:
>
> writing the FD is the same as using stdout

Except stdout may be buffered. One should probably flush the buffer
before each raw write to the file descriptor.

> use /dev/tty to reach for the console directly.

On Windows, open "CON" (read or write), "CONIN$" (read-write), or
"CONOUT$" (read-write). Or use the more explicit device paths
"\\.\CON", "\\.\CONIN$", and "\\.\CONOUT$". If the process has no
console, one can call WinAPI AllocConsole() or
AttachConsole(process_id) to obtain one.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What should go to stdout/stderr and why Python logging write everything to stderr?

[Eryk Sun]

On 1/3/23, Grant Edwards  wrote:
>
> That's definitely a better option, but I'm pretty sure I've seen
> multiple examples over the decades where fd 0 was used instead. Was
> /dev/tty a "recent" enough invention that I would have seen
> application code that was written before it existed? Or maybe I was
> just looking at code written by people who weren't aware of /dev/tty?

POSIX has required "/dev/tty" for 20 years, or longer. It's in the
2004 edition of the spec, which was a minor update to the 2001
edition.

https://pubs.opengroup.org/onlinepubs/95399/basedefs/xbd_chap10.html

> No, the whole point is _not_ to write to stdout (which would corrupt
> the program's output). The way I remember it was that you wrote the
> prompt to fd 0, and then read the password from fd 0. That way it
> worked even when fd 1 (stdout) was redirected. It still failed if
> stdin was redirected...

FYI, that wouldn't work on Windows. The "\\.\CONIN$" and "\\.\CONOUT$"
files can be opened with read-write access, but it's for a different
purpose.

A console input buffer can be read from via read() or WinAPI
ReadFile(). It can also be read from using IOCTLs that work with
16-bit wide-character strings, which is the basis of WinAPI
ReadConsoleW() and ReadConsoleInputW(). A console input buffer can be
*written to* via the IOCTL-based function WriteConsoleInputW().

A console screen buffer can be written to via write() or WinAPI
WriteFile(). It can also be written to using IOCTLs that work with
16-bit wide-character strings, which is the basis of WriteConsoleW()
and WriteConsoleOutputW(). A console screen buffer can be *read from*
via the IOCTL-based function ReadConsoleOutputW().
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What should go to stdout/stderr and why Python logging write everything to stderr?

[Eryk Sun]

On 1/3/23, Chris Angelico  wrote:
>
> FDs can also be buffered. If it's buffering you want to avoid, don't
> mess around with exactly which one you're writing to, just flush.

I meant to flush a C FILE stream or Python file before writing
directly to the file descriptor, in order to avoid out-of-sequence and
interlaced writes that make no sense. Any OS buffering on the file
doesn't matter in this regard.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: No solution for "--verbose" (on stdout) output in Pythonds standard library?

[Eryk Sun]

On 1/4/23, c.bu...@posteo.jp  wrote:
>
> often seen "--verbose" switch in command line applications should
> affect only the messages given to the users. This means messages on
> "stdout". That is what this question is about.

Is this additional context information such as help and definitions?
If it's anything to do with diagnostics and telemetry, then logging to
stderr is normal. In my experience the verbosity level typically
applies to the latter. I might step it up as I delve deeper into a
problem and need to examine specific details.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: subprocess equivalent for "os.execvp()"?

[Eryk Sun]

On 1/8/23, c.bu...@posteo.jp  wrote:
>
> is there an equivalent in the subprocess module for "os.execvp()" to
> replace the current process with the new called one?

A note for Windows users

Avoid using any of the `os.exec*` functions on Windows. There's no
support for replacing a Windows process image, so the `exec*()`
functions simply spawn a child process and terminate the current one.
This is a mess in general because a waiting parent isn't aware of the
spawned descendant. It's particularly bad for a console process that
inherits the console session, since two processes will try to use
console I/O simultaneously.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: subprocess equivalent for "os.execvp()"?

[Eryk Sun]

On 1/9/23, c.bu...@posteo.jp  wrote:
>
> On Python for Windows what is the appropriate way how a process can call
> itself again?
>
> Let me give you an example [1]:
> There is a project "bitcli" having two entry points
>
> [project.scripts]
> bitcli = "bitcli.__main__:main"
> bitcli-root = "bitcli.__main__:run_main_as_root_via_policykit"
>
> The first is usual.
>
> But the second does call "bitcli" via "pkexec" to give it some root
> rights.
>
> This application is intended to be run as user or root by the user
> himself.
>
>  def run_main_as_root_via_policykit():
>  cmd = ['pkexec', '--disable-internal-agent', 'bitcli']
>
>  # See https://github.com/python/cpython/issues/39569
>  os.execvp(cmd[0], cmd)

The nearest equivalent on Windows, if the current process doesn't have
administrator access and high integrity level, would be to spawn a
process with administrator access and elevated integrity level by
calling ShellExecuteExW() with the "runas" operation. The original
process should wait on the spawned process and proxy its exit status.
It should also add the spawned process to a kill-on-close,
silent-breakaway job, such that terminating the original process also
terminates the spawned process.

The standard library doesn't support calling ShellExecuteExW() or
working with job objects, except via ctypes. Or use the PyWin32
package.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: No module named 'playsound'‏‏‏‏‏‏‏‏‏‏‏‏‏‏‏‏

[Eryk Sun]

On 1/9/23, MRAB  wrote:
>
> On Windows it's best to use pip via the Python Launcher:
>
> py -m pip show playsound

Python's app distribution on the Microsoft Store doesn't include the
py launcher, and we don't (but should) have a standalone app or
desktop version of the launcher. Unlike the desktop distribution,
however, the app distribution installs a versioned name as a link,
such as "python3.11". (Note that a venv virtual environment only has a
"python" command on Windows.)

If "pip" is in PATH, a versioned name such as "pip3.11" should also be
available. If multiple versions of the app distribution are installed,
and for some reason the "python" and "pip" links are mapped to
different versions, one can match up the versioned names "pip3.11" and
"python3.11" to ensure consistency. Or simply run "python -m pip".
-- 
https://mail.python.org/mailman/listinfo/python-list