[python] Mobilni python

[Radek Kanovsky]

On Mon, Oct 16, 2006 at 06:08:40PM +0200, superman wrote:

> Jenže python interpretr to v mém pokusu dělal takto:
> 
> open(cesta_z_registru + modul)
> open(cesta_ze_systemoveho_adresare_windows + modul)
> open(cesta_z_PYTHONPATH + modul)
> if (se nepodarilo otevrit soubor z cesty z PYTHONPATH):
>    open(cesta_z_registru + modul)
>    if (se nepodarilo otevrit soubor z cesty z registru):
>       open(cesta_ze_systemoveho_adresare_windows + modul)
>       if (se nepodarilo otevrit soubor z cesty ze systemu win):
>           vyhod vyjimku importu
> 
> Coz je prakticky doslovny prepis jeho cinnosti pri hledani modulu a to 
> uz mi normalni fakt neprijde. Možná detaily byly malinko jinak, ale 
> pochopil jsem, že Python postupuje stylem nejdřív otevírej soubor a až 
> pak se zeptej, jestli ho vlastně vůbec chceš otevírat.

To je mozna odtrasovane volani open, ale urcite to neni doslovny prepis
toho, co Python vevnitr dela. Myslim, ze neni vubec problem nastavit
Python tak, aby delal to, co chcete. Jelikoz i na windows se bere
v uvahu hodnota PYTHONHOME, nemusel by to byt takovy problem.
Pro zacatek bych se zkusil podivat na tohle:

/* ----------------------------------------------------------------
   PATH RULES FOR WINDOWS:
   This describes how sys.path is formed on Windows.  It describes the 
   functionality, not the implementation (ie, the order in which these 
   are actually fetched is different)

   * Python always adds an empty entry at the start, which corresponds
     to the current directory.

   * If the PYTHONPATH env. var. exists, its entries are added next.

   * We look in the registry for "application paths" - that is, sub-keys
     under the main PythonPath registry key.  These are added next (the
     order of sub-key processing is undefined).
     HKEY_CURRENT_USER is searched and added first.
     HKEY_LOCAL_MACHINE is searched and added next.
     (Note that all known installers only use HKLM, so HKCU is typically
     empty)

   * We attempt to locate the "Python Home" - if the PYTHONHOME env var
     is set, we believe it.  Otherwise, we use the path of our host .EXE's
     to try and locate our "landmark" (lib\\os.py) and deduce our home.
     - If we DO have a Python Home: The relevant sub-directories (Lib, 
       plat-win, lib-tk, etc) are based on the Python Home
     - If we DO NOT have a Python Home, the core Python Path is
       loaded from the registry.  This is the main PythonPath key, 
       and both HKLM and HKCU are combined to form the path)

   * Iff - we can not locate the Python Home, have not had a PYTHONPATH
     specified, and can't locate any Registry entries (ie, we have _nothing_
     we can assume is a good path), a default path with relative entries is 
     used (eg. .\Lib;.\plat-win, etc)


  The end result of all this is:
  * When running python.exe, or any other .exe in the main Python directory
    (either an installed version, or directly from the PCbuild directory),
    the core path is deduced, and the core paths in the registry are
    ignored.  Other "application paths" in the registry are always read.

  * When Python is hosted in another exe (different directory, embedded via 
    COM, etc), the Python Home will not be deduced, so the core path from
    the registry is used.  Other "application paths" in the registry are 
    always read.

  * If Python can't find its home and there is no registry (eg, frozen
    exe, some very strange installation setup) you get a path with
    some default, but relative, paths.

   ---------------------------------------------------------------- */

Radek Kaňovský