A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from http://mail.python.org/pipermail/python-dev/attachments/20120320/83d45f1c/attachment.html below:

<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#330033">
    On 3/20/2012 4:25 PM, Mark Hammond wrote:
    <blockquote cite="mid:4F6911EE.1030400@gmail.com" type="cite">I
      think it does.  Consider I've installed Python as a "system
      install". Â Now I want to install some other package - ideally that
      installer will request elevation - all well and good - the .py
      files are installed. However, next time I want to run Python, it
      will fail to generate the .pyc files - even though I'm an
      administrator.  I would need to explicitly tell Python to execute
      "as administrator" (or run it from an already elevated
      command-prompt) to have things work as expected.  Thus, the
      "usual" case would be that Python is unable to update any files in
      its install directory.
      <br>
      <br>
      If Python installed for a single user didn't install into Program
      Files (which it probably couldn't do without an administrator
      providing credentials anyway) then it wouldn't be a problem - but
      then we have multiple possible default install locations, which
      sounds like more trouble than it is worth...
      <br>
      <br>
      <blockquote type="cite" style="color: #000000;">That said, there
        is an open bug in the tracker about the insecurity
        <br>
        of a system install of python (exactly that the files are
        writable
        <br>
        by anyone).  So that would have to be solved first.  I'd say
        this
        <br>
        is definitely a separate issue from Van's discussion, and the <b
          class="moz-txt-star"><span class="moz-txt-tag">*</span>only<span
            class="moz-txt-tag">*</span></b>
        <br>
        reason one might want to tie them together at all is "well,
        we're
        <br>
        changing the directory layout anyway".
      </blockquote>
    </blockquote>
    <br>
    Indeed, the single user "place" isn't a single place, unless you
    consider the per-user $APPDATA environment variable sufficient to
    determine it (or the Windows API that returns the initial boot up
    value of $APPDATA/ %APPDATA%, which is the preferred technique for
    code).  But it does solve the security problem (stuff in APPDATA is
    accessible only to a single login by default).  So that might be
    justification for putting it there, for single users.<br>
    <br>
    For multi-user installs, %PROGRAMFILES% is appropriate, but, like
    I've heard some Linux distributions do, *.pyc might have to be
    prebuilt and installed along with Python (or generated during
    install, instead of waiting for first use).<br>
  </body>
</html>

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4