[Python-Dev] IDLE reading IDLESTARTUP or PYTHONSTARTUP on restart
I have a small change (shown below) to PyShell.py in idlelib that
causes the subprocess interpreter to read IDLESTARTUP or
PYTHONSTARTUP each time it restarts. To me this would make IDLE much
more useful for myself and students I teach. It isn't quite clear
what behavior to install with the enabling patch, so I would like
some feedback before submitting it. The main question is:
Shouldn't IDLE always read IDLESTARTUP (if defined) or PYTHONSTARTUP
(if IDLESTARTUP is not defined and PYTHONSTARTUP is) when it starts
rather than that requiring a command-line switch as it does now? This
is the behavior of python, and I don't see why it should be any
different for IDLE. More importantly, there is no convenient way to
say "and read my startup file" when double-clicking the IDLE icon.
(I'm on a Mac. On Windows the -s switch could be added to an icon for
IDLE, but that's still awkward.)
Secondary questions;
If IDLE is changed to read a startup file, should the -s switch be
dropped altogether? If so, should a -q switch be added (as with
emacs) to start without loading the startup file? I think yes to both.
When the subprocess interpreter is restarted should it look in the
environment for the current values of IDLESTARTUP and PYTHONSTARTUP,
or should IDLE store those values in a property of the subprocess
interpreter when first started and have restart go directly to the
saved path even if the value of IDLESTARTUP or PYTHONSTARTUP has
changed since IDLE had been started. I think restart should go to the
path as it was when IDLE was started and ignore subsequent changes.
Or at least the reststart should notice the change and present a
dialog asking the user to choose between the old path and the new one.
The diff modifies PyShell by copying the four lines of code that load
IDLESTARTUP or PYTHONSTARTUP from where they appear in the initial
startup code and adding to where the subprocess interpreter writes
"RESTART" to the console.
@@ -434,6 +434,10 @@
console.write(halfbar + ' RESTART ' + halfbar)
console.text.mark_set("restart", "end-1c")
console.text.mark_gravity("restart", "left")
+filename = os.environ.get("IDLESTARTUP") or \
+ os.environ.get("PYTHONSTARTUP")
+if filename and os.path.isfile(filename):
+self.execfile(filename)
console.showprompt()
# restart subprocess debugger
if debug:___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] IDLE reading IDLESTARTUP or PYTHONSTARTUP on restart
I have a patch for IDLE, but I've never submitted a patch before and not quite sure of the procedure, despite reading the guidelines at http://www.python.org/dev/patches/. But I'll be brave and persevere. The question I have at the moment is should I only submit the patch vs. 3.1 or also for 3.0? 2.7? 2.6? 2.5? The main thing the patch does is: modify the subprocess restart procedure so that it reloads whatever file, if any, was loaded when IDLE first started and looked for IDLESTARTUP then PYTHONSTARTUP environment variables. In addition: a -q option is added for starting IDLE on the command line to mean "quiet", as with Emacs, e.g., to suppress loading of IDLESTARTUP or PYTHONSTARTUP The former effect of -s would now be the default, which is desirable so double-clicking an IDLE icon to start it will cause the startup file to run. -s is changed to take an argument that is an alternate startup file to use I am a bit concerned about changing -s to have a different meaning. Perhaps it's better to leave -s as an option that is simplhy superfluous and use a different letter for the alternate startup. Guidance on all of these would be greatly appreciated. The patch itself disturbs things in a half-dozen places, but in very minimal ways, so it's not quite as easy as saying "add these three lines over here". (It was that simple until I started thinking about whether the restart should search for IDLESTARTUP/PYTHONSTARTUP again, and perhaps encounter a different file than IDLE did on startup [I think it shouldn't, but it's not a big deal either way] and if shouldn't, then whatever path was originally found has to be stored somewhere and used later. That led to the thinking behind the changes to the startup switches. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] .Idle.py init file
I was trying to disentangle some IDLE behavior today and discovered that If the user has a .Idle.py file IDLE will run it when it starts up. This is independent of running IDLESTARTUP or PYTHONSTARTUP when the -s switch is given. It is run by Tk.readprofile as called from Tk.__init__. The "Idle" comes from the name passed to TK() when PyShell.py creates its Tk root. In fact, not only is it independent, but it works differently: any imports done in .Idle.py go into Tk's name space, whereas IDLESTARTUP/PYTHONSTARTUP is exec'd and imports go into the interpreter's namespace. I don't think this behavior is documented anywhere, although since I had a .Idle.py file I must have seen something about this somewhere at some point. It's very hard to search for ".Idle.py" when "idle.py" is a file whose name appears frequently in discussions. Is this something that I should submit as an Issue or is it widely known behavior? It should at least be documented. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] patch to make IDLE load IDLESTARTUP/PYTHONSTARTUP on restart
I have submitted patches to idlelib/PyShell.py for Python 2.7 (Issue 5233) and 3.1 (5234), made against local repository copies as updated an hour ago. The purpose of the patch is to have IDLE load IDLESTARTUP or PYTHONSTARTUP on restart. Along the way I also made -s the default so IDLESTARTUP or PYTHONSTARTUP gets loaded when IDLE is started by double-clicking rather than from the command line (no reasonable way for the user to get the -s switch into IDLE.app on the Mac). I decided that on restart IDLE should load the file that was loaded when it started in the first place, on the off chance that something had changed in the interim. I changed the meaning of the -s switch to take an argument that is an alternate startup file to load instead of IDLESTARTUP or PYTHONSTARTUP. It might be better, though, to leave -s as it is and mark it deprecated or obsolete or the default or whatever and use a different letter to specify a load file. I added a switch -q to suppress loading of the startup file. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] lifting of prohibition against readlines inside a "for line in file" in Py3?
I discovered today that Python 2's prohibition against performing
readlines on a file being iterated over appears to have been lifted
in Python 3. Is this intentional? If it is, should it be added to the
What's New in the documentation? I haven't been able to find anything
mentioning the change.
with open("lines.txt") as fil:
for line in fil:
print(line[:-1])
print(fil.readline())
produces a runtime error in 2.5 and 2.6 but not in 3.0 or 3.1 (and
the output is as expected).
Also, I was surprised that nested "for line in file" that use the
same file cause no problems in Python 2.5, 2.6, 3.0, or 3.1.
with open("lines.txt") as fil:
for line1 in fil:
print(line1)
if line1[0] == '1':
for line2 in fil:
print(line2[:-1])
if line2[0] == '2':
break
I would have expected the "for line in file" iterator to get confused
by the file position having been moved out from under it, but I
suppose all it has to do is just more readlines from wherever the
file pointer is when it regains control. I mention this because apart
from implementation considerations any reasoning that would
discourage one from mixing line iterations with readlines might leave
one thinking that nested line iterations wouldn't work either. But if
it is intended that Python 3 allow mixing readlines with line
iterations, there would be much less reason to suspect nested line
iterations.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] lifting of prohibition against readlines inside a "for line in file" in Py3?
In Digest Vol. 67, Issue 52 (13 Feb 2009) I pointed out that Python 2's prohibition against performing readlines on a file being iterated over appears to have been lifted in Python 3. I asked if this was intentional and whether it should be add to the "What's New" documentation. I also expressed muy surprise that "for line in fil"'s can be nested using the same fil in both Python 2 and 3. I presented an example for each point and some and further comments. I didn't get any response. Is this the wrong list for the question? Did appropriate responders assume another would respond? I want to reraise this because lifting of that prohibition is a quite significant change in the behavior from Python 2. Even if it ws a bug in Python 2, or the side effect of other changes in Python 3, it should at least be documented prominently. True, no-one's code will be affected by lifting a prohibition against something their code couldn't have done, but the new behavior offers significant flexibility in writing "for line in fil" iterations in that it allows recognizing the beginning of a sequence of lines that should be considered a unified "chunk" and allows the loop to do readlines to handle the rest of the chunk. Some of these can be handled by just nesting a second "for line in fil" inside a conditional inside the outer iteration but some are better handled by individual readlines. I'd appreciate comments -- especially a redirection to a different list, if this one isn't appropriate for my query. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] .pythonrc.py in man page
The python man page, dated 2005 even in 3.1, has this curious entry: ~/.pythonrc.py User-specific initialization file loaded by the user module; not used by default or by most applications. 1. I couldn't figure out what the user module is. 2. I couldn't figure out what "not used by default or by most applications" meant: what would cause it to get loaded when python starts up? how would an application load it even if the user's environment didn't cause it to get loaded? 3. Why would this file exist if the environment variable PYTHONSTARTUP can specify a file to be loaded at startup? Perhaps this entry in the man page is obsolete and should be removed? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] draft 3.1 release schedule
Would whoever is responsible for IDLE please take a look at the patches I submitted for Python 2 & 3 [tracker IDs 5233 and 5234 respectively]. These change the behavior of IDLE so that IDLESTARTUP or PYTHONSTARTUP files are executed with each restart. This allows loading frequently used packages, personal utilities, etc. automatically at each restart. I consider this a very important problem in IDLE, especially when using it to teach. I would really like to see them in 3.1. The patch is already there; someone just has to do whatever gets done with patches to validate it and check it in. It's not a lot of code changes. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] IDLE maintenance
I've been trying to decipher the various mentions of IDLE maintenance on this list to determine the likely future (not necessarily feature addition, just keeping it working with each new version of Python and, I suppose, Tk) , who is currently responsible for it, and who will be responsible for it. Presumably these questions have official answers somewhere, but I wouldn't know where to find them. I have several strong reasons to want IDLE to survive, including using it in teaching and writing, where it becomes absurd to provide instructions full of variations based on different IDE's. IDLE is sufficient for introductory courses and books, and useful for many purposes even beyond that. The community should want to minimize the entry friction new users experience, and new users in these times will not necessarily have any experience with command-line shells or editors like vi and emacs. IDLE is at just the right level for someone new to Python to just jump in and start exploring or even for someone with reasonable Python experience investigating a new area of the library. As I said, I don't know the plans or people surrounding IDLE are. If it needs a new maintainer I hereby volunteer. Discussions about my qualifications should probably be conducted through email to me personally, rather than through this mailing list, using the address I use when submitting issues to the tracker: [email protected]. -- Mitchell L Model, Ph.D. [email protected] Consulting (508) 358-8055 (v) 42 Oxbow Road (508) 641-7772 (m) Wayland, MA 01778 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] #!/usr/bin/env python --> python3 where applicable
Some library files, such as pdb.py, begin with #!/usr/bin/env python In various discussions regarding some issues I submitted I was told that the decision had been made to call Python 3.x release executables python3. (One of the conflicts I ran into when I made 'python' a link to python3.1 was that some tools used in making the HTML documentation haven't been upgraded to run with 3.) Shouldn't all library files that begin with the above line be changed so that they read 'python3' instead of python? Perhaps I should have just filed this as an issue, but I'm not confident of the state of the plan to move to python3 as the official executable name. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Documentation of Slicings in 3.0
The section of the documentation on slicings in 3.0 is substantially different than in previous versions, including 2.6. In particular it states that "The primary must evaluate to a maping object." I've followed the grammar and the commentary around through a few paths and cannot convince myself that the docmentation ever covers sequence slicing. I'm not sufficiently confident of this to post as a bug, so I decided to post here first. -- --- Mitchell L Model ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
