<html>

 <head>

  <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">

 </head>

 <body bgcolor="#FFFFFF" text="#330033">

  On 7/20/2011 4:41 PM, Mark Hammond wrote:

  <blockquote cite="mid:4E276795.9050404@gmail.com" type="cite">On

   21/07/2011 7:43 AM, Glenn Linderman wrote:

   <br>

   ...

   <br>

   <blockquote type="cite">

    <br>

    I still get the same behavior. Is there any debugging output

    produced

    <br>

    by py.exe that would tell what py.ini it looks in, and what the

    content

    <br>

    is? What diagnostic steps might I take to produce additional

    <br>

    information that would help you (or me, along the way) analyze

    the

    <br>

    issue? I do not presently have a C compiler installed on this

    machine,

    <br>

    however, unless it came along for a ride with something else.

    <br>

   </blockquote>

   <br>

   It doesn't do exactly what you ask, but setting an environment

   variable PYLAUNCH_DEBUG to any value will cause some debug output

   to be generated to stdout.

   <br>

   <br>

   Mark

   <br>

   <br>

  </blockquote>

  <br>

  It produces:<br>

  <br>

  d:\&gt;py d:\path\to\foo.py<br>

  launcher build: 64bit<br>

  launcher executable: Console<br>

  File 'C:\Users\Glenn\AppData\Roaming\py.ini' non-existent<br>

  maybe_handle_shebang: read 256 bytes<br>

  maybe_handle_shebang: BOM not found, using UTF-8<br>

  locate_pythons_for_key: unable to open PythonCore key<br>

  locate_pythons_for_key: unable to open PythonCore key<br>

  run_child: about to run 'C:\Python26\python.exe d:\path\to\foo.py'<br>

   File "d:\path\to\foo.py", line 469<br>

  child process exit code: 1<br>

  <br>

  So this tells me that it didn't find a local py.ini (no surprise, I

  don't have one) but doesn't tell me that it did find or read

  c:\Windows\system32\py.ini much less whether I have the syntax

  correct for my [defaults] section. It doesn't tell me that it

  didn't find a #! line (but there isn't one).<br>

  <br>

  Perhaps the problem is that there isn't one? If it finds no virtual

  command, maybe it doesn't obey the [defaults] python=3 directive? 

  The PEP says it should act like '!#python' (I think the PEP meant

  '#!python', though????). There is no " " after '!#python' in the

  PEP, so that disqualifies it from being a customized command, there

  is no '/usr/bin/' nor '/usr/bin/env ' in front of the 'python' so

  that means it is not a virtual command; and it is not a

  fully-qualified name, so it doesn't mean that case either.... looks

  like the PEP needs a bit of clarification here.<br>

  <br>

  I do have a python on my path, but it is 3.1.2, not 3.2.1 or 2.6.4,

  and it runs 2.6.4 as the output shows. And I would expect it to run

  3.2.1 with the [defaults] python=3 directive, since that is newer

  than 3.1.2, which is on my PATH.<br>

  <br>

  So, still a mystery.<br>

 </body>

</html>