From Bob_Linder@NAI.com  Wed Oct  4 14:49:43 2000
From: Bob_Linder@NAI.com (Linder, Bob)
Date: Wed, 4 Oct 2000 06:49:43 -0700
Subject: [Idle-dev] Bug in Python 1.6 (#0, Sep  5 2000, 08:16:13) [MSC 32 bit (Intel)
 ] on win32
Message-ID: <B481990C9658D411BD3C009027D6F54462CBD7@ca-exchange3.nai.com>

I am using Python 1.6 (#0, Sep  5 2000, 08:16:13) [MSC 32 bit (Intel)] on
win32

I am currently learning Tkinter, so I am tracing 'IDLE' code to learn it.


In TreeWidget.py, assignment of '_icondir' using '__file__' is wrong,
'sys.argv[0]' works.

'__file__' looks like 'C/C++' syntax.

The way I found this problem by copying file to another directory and
running it.

 
# Look for Icons subdirectory in the same directory as this module
try:
    #_icondir = os.path.join(os.path.dirname(__file__), ICONDIR)
	_icondir = os.path.join(os.path.dirname(sys.argv[0]), ICONDIR)
except NameError:
    _icondir = ICONDIR
if os.path.isdir(_icondir):
    ICONDIR = _icondir
elif not os.path.isdir(ICONDIR):
    raise RuntimeError, "can't find icon directory (%s)" % `ICONDIR`



From njriley@uiuc.edu  Wed Oct  4 20:28:47 2000
From: njriley@uiuc.edu (Nicholas Riley)
Date: Wed, 4 Oct 2000 14:28:47 -0500
Subject: [Idle-dev] Bug in Python 1.6 (#0, Sep  5 2000, 08:16:13) [MSC 32 bit (Intel) ] on win32
In-Reply-To: <B481990C9658D411BD3C009027D6F54462CBD7@ca-exchange3.nai.com>; from Bob_Linder@NAI.com on Wed, Oct 04, 2000 at 06:49:43AM -0700
References: <B481990C9658D411BD3C009027D6F54462CBD7@ca-exchange3.nai.com>
Message-ID: <20001004142847.A21681@uiuc.edu>

On Wed, Oct 04, 2000 at 06:49:43AM -0700, Linder, Bob wrote:

> I am currently learning Tkinter, so I am tracing 'IDLE' code to
> learn it.

I'd recommend "Python Programming with Tkinter" if you don't already
have it - that's how I learned.

> In TreeWidget.py, assignment of '_icondir' using '__file__' is wrong,
> 'sys.argv[0]' works.

sys.argv[0] refers to the first argument Python was invoked with, and
may not always have something useful in it.

> '__file__' looks like 'C/C++' syntax.

I'm sure it is modeled after C/C++ syntax!  However, it does work.

> The way I found this problem by copying file to another directory and
> running it.

You need to move the Icons directory too.  That's the point of the
code, it'll take the directory where TreeWidget.py is located, and
look for an Icons subdirectory.

Here's a (hopefully) illustrative example:

% echo "import sys\nprint globals().get('__file__', '<undefined>'), sys.argv" > blah.py
% python 
Python 1.6 (#6, Sep  6 2000, 17:37:56)  [GCC 2.95.2 19991024 (release)] on linux2
[snip]
>>> import blah
blah.py ['']
>>>
% python blah.py 
<undefined> ['blah.py']

Reminds me, I need to do something about my TreeWidget changes that
I've had sitting around for many months...

-- 
Nicholas Riley <njriley@uiuc.edu> | <http://www.uiuc.edu/ph/www/njriley>


From jbaker@ummelec.com  Wed Oct  4 21:10:02 2000
From: jbaker@ummelec.com (Jake Baker)
Date: Wed, 04 Oct 2000 15:10:02 -0500
Subject: [Idle-dev] re: Bug in Python 1.6
Message-ID: <s9db4858.024@gwia.ummelec.com>

> In TreeWidget.py, assignment of '_icondir' using '__file__' is wrong,
> 'sys.argv[0]' works.
>
> '__file__' looks like 'C/C++' syntax.
>
> The way I found this problem by copying file to another directory and
> running it.

Not a bug. __file__ is a module attribute - if you didn't import the file =
as an module, then it doesn't exist in the namespace. __file__ evaluates =
to the full path of the python file which the module was loaded from.

> _icondir =3D os.path.join(os.path.dirname(sys.argv[0]), ICONDIR)

This doesn't work, at least under my system, because sys.argv[0] =3D=3D =
''. Your code would work as long as the current directory and the desired =
directory is the same.

(__file__ is not documented anywhere I can find.)



From guido@python.org  Thu Oct  5 18:36:41 2000
From: guido@python.org (Guido van Rossum)
Date: Thu, 05 Oct 2000 12:36:41 -0500
Subject: [Idle-dev] __file__
In-Reply-To: Your message of "Wed, 04 Oct 2000 15:10:02 EST."
 <s9db4858.024@gwia.ummelec.com>
References: <s9db4858.024@gwia.ummelec.com>
Message-ID: <200010051736.MAA13902@cj20424-a.reston1.va.home.com>

> (__file__ is not documented anywhere I can find.)

__file__ is documented in chapter 3 of the Python reference manual:

Modules
    [...]

    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.

http://www.pythonlabs.com/doc/manuals/python2.0/ref/types.html

--Guido van Rossum (home page: http://www.python.org/~guido/)


From mats@laplaza.org  Wed Oct 25 14:59:56 2000
From: mats@laplaza.org (Mats Wichmann)
Date: Wed, 25 Oct 2000 07:59:56 -0600
Subject: [Idle-dev] Doc Commentary
Message-ID: <3.0.6.32.20001025075956.00ea0aa0@laplaza.org>

Pardon a newbie's intrusion here... someone point me
to the right discussion place if this is no longer
current or is inappropriate.

In Re: Idle documentation - since Idle is now "standard"
in Python distribution kits, can Idle documentation also
become a "standard" part of the release?


In the 0.5 Idle docs - the latest I've come across -
there's a small section on limitations ("Shell Window" ->
"Special Issues").

Seems to me a mention might be made that the following
idiom also doesn't work as expected:

>>> import sys
>>> f = open('some-output-file', 'w')
>>> sys.stdout = f
>>> # do some stuff
>>> sys.stdout = sys.__stdout__

Because on entry, sys.stdout is already redirected
(not reflected in sys.__stdout__)

>>> sys.stdout
<PyShell.PseudoFile instance at 01128B1C>
>>> sys.__stdout__
<open file '<stdout>', mode 'w' at 00D328F0>

Gave me a moment's pause when I was writing up some
try-this-out examples - this is a difference from
the "normal" interpreter environment.  Easy enough
to work around if you know it's this way...

Cheers,

Mats Wichmann






From guido@python.org  Wed Oct 25 16:13:59 2000
From: guido@python.org (Guido van Rossum)
Date: Wed, 25 Oct 2000 10:13:59 -0500
Subject: [Idle-dev] Doc Commentary
In-Reply-To: Your message of "Wed, 25 Oct 2000 07:59:56 CST."
 <3.0.6.32.20001025075956.00ea0aa0@laplaza.org>
References: <3.0.6.32.20001025075956.00ea0aa0@laplaza.org>
Message-ID: <200010251513.KAA28803@cj20424-a.reston1.va.home.com>

> In Re: Idle documentation - since Idle is now "standard"
> in Python distribution kits, can Idle documentation also
> become a "standard" part of the release?

Aargh!  There's no "official" IDLE documentation.  There's a very
useful doc package by Daryl Harms, which I put up at
http://www.python.org/idle/doc/.  Perhaps this should be converted to
LaTeX and incorporated into the Python doc tree.  Issue: Daryl has
screen shots that the current Python documentation package can't deal
with.  For Fred Drake to resolve...

> In the 0.5 Idle docs - the latest I've come across -
> there's a small section on limitations ("Shell Window" ->
> "Special Issues").
> 
> Seems to me a mention might be made that the following
> idiom also doesn't work as expected:
> 
> >>> import sys
> >>> f = open('some-output-file', 'w')
> >>> sys.stdout = f
> >>> # do some stuff
> >>> sys.stdout = sys.__stdout__
> 
> Because on entry, sys.stdout is already redirected
> (not reflected in sys.__stdout__)

Where did you get this idiom?  You should never use sys.__stdout__
this way!  The proper idiom is

  save_stdout = sys.stdout
  try:
      sys.stdout = f
      # do some stuff
  finally:
      sys.stdout = save_stdout

If you know of any places that are promoting direct use of __stdout__,
please let them know this is wrong.  If you are contemplating to use
this in code examples you intend to distribute, please don't!

--Guido van Rossum (home page: http://www.python.org/~guido/)