Bruce Frederiksen <dangy...@gmail.com> added the comment:

No, IDLE compiles the module (with the 'compile' built-in using the 'exec'
option) and then does an 'exec' on the code (in PyShell.py).  It has several
lines of code that it runs before this exec to prepare the environment that
the code is run in.  It appears to be an oversight that the __file__
variable is not being set as a part of this preparation code to match the
behavior of the python CLI.  The patch that I included only changes one line
of this preparation code to also set the __file__ variable and that fixes
the problem.  If you examine the IDLE code in the immediate vicinity of my
patch you will see this.

I have several use cases where I'm relying on the __file__ variable in my
module so that it can find other non .py files that it needs in the same
directory that it's in.  This works under all combinations of uses from the
CLI, but fails in IDLE using Run Module.

The language reference
manual<http://docs.python.org/reference/datamodel.html?highlight=__file__>states
under "Module":

Predefined (writable) attributes: __name__ is the module’s name; __doc__ is
> the module’s documentation string, or None if unavailable; __file__ is the
> pathname of the file from which the module was loaded, if it was loaded from
> a file. The __file__ attribute is not present for C modules that are
> statically linked into the interpreter; for extension modules loaded
> dynamically from a shared library, it is the pathname of the shared library
> file.
>

The python CLI honors this definition in all cases, but IDLE/Run Module does
not.

On Fri, Jun 11, 2010 at 11:11 AM, Tal Einat <rep...@bugs.python.org> wrote:

>
> Tal Einat <talei...@users.sourceforge.net> added the comment:
>
> I believe IDLE runs modules via execfile(), so I would expect the behavior
> to be similar, and execfile() does not set __file__. Doing "Run Module" is
> also IMO equivalent to doing execfile(), so this behavior retains
> consistency.
>
> However, I would expect __file__ to be set when running IDLE -r <script>,
> but I get "name '__file__' is not defined" (with Python 2.6.2). This is
> inconsistent and should be fixed.
>
> ----------
> nosy: +taleinat
>
> _______________________________________
> Python tracker <rep...@bugs.python.org>
> <http://bugs.python.org/issue8515>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file17632/unnamed

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue8515>
_______________________________________
No, IDLE compiles the module (with the &#39;compile&#39; built-in using the 
&#39;exec&#39; option) and then does an &#39;exec&#39; on the code (in 
PyShell.py).  It has several lines of code that it runs before this exec to 
prepare the environment that the code is run in.  It appears to be an 
oversight that the __file__ variable is not being set as a part of this 
preparation code to match the behavior of the python CLI.  The patch that I 
included only changes one line of this preparation code to also set the 
__file__ variable and that fixes the problem.  If you examine the IDLE code in 
the immediate vicinity of my patch you will see this.<br>
<br>I have several use cases where I&#39;m relying on the __file__ variable in 
my module so that it can find other non .py files that it needs in the same 
directory that it&#39;s in.  This works under all combinations of uses from 
the CLI, but fails in IDLE using Run Module.<br>
<br>The <a 
href="http://docs.python.org/reference/datamodel.html?highlight=__file__";>language
 reference manual</a> states under &quot;Module&quot;:<br><br><blockquote 
style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); 
padding-left: 1ex;" class="gmail_quote">
Predefined (writable) attributes: <tt class="xref docutils literal"><span 
class="pre">__name__</span></tt> is the module’s name;
<tt class="xref docutils literal"><span class="pre">__doc__</span></tt> 
is the module’s documentation string, or <tt class="xref docutils 
literal"><span class="pre">None</span></tt> if
unavailable; <tt class="xref docutils literal"><span class="pre"><span 
class="highlight">__file__</span></span></tt> is the pathname of the 
file from which the module
was loaded, if it was loaded from a file. The <tt class="xref docutils 
literal"><span class="pre"><span class="highlight">__file__</span></span></tt>
 attribute is not
present for C modules that are statically linked into the interpreter; 
for
extension modules loaded dynamically from a shared library, it is the 
pathname
of the shared library file.<br></blockquote><br>The python CLI honors this 
definition in all cases, but IDLE/Run Module does not.<br><br><div 
class="gmail_quote">On Fri, Jun 11, 2010 at 11:11 AM, Tal Einat <span 
dir="ltr">&lt;<a 
href="mailto:rep...@bugs.python.org";>rep...@bugs.python.org</a>&gt;</span> 
wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 
1px solid rgb(204, 204, 204); padding-left: 1ex;"><br>
Tal Einat &lt;<a 
href="mailto:talei...@users.sourceforge.net";>talei...@users.sourceforge.net</a>&gt;
 added the comment:<br>
<br>
I believe IDLE runs modules via execfile(), so I would expect the behavior to 
be similar, and execfile() does not set __file__. Doing &quot;Run Module&quot; 
is also IMO equivalent to doing execfile(), so this behavior retains 
consistency.<br>

<br>
However, I would expect __file__ to be set when running IDLE -r &lt;script&gt;, 
but I get &quot;name &#39;__file__&#39; is not defined&quot; (with Python 
2.6.2). This is inconsistent and should be fixed.<br>
<br>
----------<br>
nosy: +taleinat<br>
<div><div></div><div class="h5"><br>
_______________________________________<br>
Python tracker &lt;<a 
href="mailto:rep...@bugs.python.org";>rep...@bugs.python.org</a>&gt;<br>
&lt;<a href="http://bugs.python.org/issue8515"; 
target="_blank">http://bugs.python.org/issue8515</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br>
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to