[ python-Bugs-1569057 ] Using .next() on file open in write mode writes junk to file
Bugs item #1569057, was opened at 2006-10-01 23:49
Message generated for change (Comment added) made by montanaro
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569057&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: andrei kulakov (rainy)
Assigned to: Nobody/Anonymous (nobody)
Summary: Using .next() on file open in write mode writes junk to file
Initial Comment:
When you open a file in write mode and use .next(), it
prints an error and writes many lines of junk to file.
I tested on windows and python 2.5:
>>> f = open('test', 'w')
>>> f.fileno()
4
>>> f.write('1\n')
>>> f.write('2\n3\n4\n')
>>> f.next()
Traceback (most recent call last):
File "", line 1, in
f.next()
IOError: [Errno 9] Bad file descriptor
>>> f.close()
>>> f = open('test')
>>> f.next()
'1\n'
>>> f.next()
'2\n'
>>> f.next()
'3\n'
>>> f.next()
'4\n'
>>> f.next()
'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x
00\x00\x00\x00\x00\x
00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
\x00\x00\x00\x00\x00\
x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
\x00\x00\x00
...many more lines of junk...'
--
>Comment By: Skip Montanaro (montanaro)
Date: 2006-10-07 05:38
Message:
Logged In: YES
user_id=44345
Works for me. (Nearly current build from SVN.) I find it implausible that your
explanation of failing to flush the file is the cause of the problem since
closing
the file will cause it to be flushed. You didn't open the file for "w+" so
there's no
opportunity to switch between writing and reading.
What platform are you using?
--
Comment By: andrei kulakov (rainy)
Date: 2006-10-03 20:23
Message:
Logged In: YES
user_id=511010
Python newsgroup folks said that this is normal because when
switching between write/read modes without doing flush()
first, result is undefined. There was a suggestion from
Terry Ready to add this to documentation on file methods:
"When switching from reading or writing (or vice versa),
call flush(), or
the result will be undefined."
thx, -andrei
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569057&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1572471 ] csv "dialect = 'excel-tab'" to use excel_tab
Bugs item #1572471, was opened at 2006-10-06 19:06 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1572471&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Dan Goldner (goldner) >Assigned to: Skip Montanaro (montanaro) Summary: csv "dialect = 'excel-tab'" to use excel_tab Initial Comment: Python Library Reference v2.5 (19 September 2006), section 9.1.1, entry for class excel_tab: Documentation should note that though the class is excel_tab (with an underscore), the dialect name is 'excel-tab' (with a hyphen). Possible fix is to add a sentence: class excel_tab() The excel_tab class defines the usual properties of an Excel-generated TAB-delimited file. Specify in reader, writer, etc. with "dialect = 'excel-tab'" (with a hyphen, not an underscore). -- >Comment By: Skip Montanaro (montanaro) Date: 2006-10-07 06:21 Message: Logged In: YES user_id=44345 Thanks. Checked in as revision 52218 on svn trunk. I'm having some svn trouble with the 2.5 maintenance branch but will check it in there as well once that's working again. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1572471&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1572710 ] cElementTree.SubElement doesn't recognize keyword "attrib"
Bugs item #1572710, was opened at 2006-10-07 08:32
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1572710&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: XML
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Stephens (hugesmile)
Assigned to: Nobody/Anonymous (nobody)
Summary: cElementTree.SubElement doesn't recognize keyword "attrib"
Initial Comment:
Calling the c routine cElementTree with the keyword
"attrib" fails. This works in the python version
(ElementTree).
Example:
head = ET.SubElement(root, "head", attrib={"dir":"ltr"})
Python version 2.5, Windows version XP Professional
2002, Service Pack 2
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1572710&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1572710 ] cElementTree.SubElement doesn't recognize keyword "attrib"
Bugs item #1572710, was opened at 2006-10-07 14:32
Message generated for change (Comment added) made by effbot
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1572710&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: XML
Group: Python 2.5
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Mark Stephens (hugesmile)
Assigned to: Nobody/Anonymous (nobody)
Summary: cElementTree.SubElement doesn't recognize keyword "attrib"
Initial Comment:
Calling the c routine cElementTree with the keyword
"attrib" fails. This works in the python version
(ElementTree).
Example:
head = ET.SubElement(root, "head", attrib={"dir":"ltr"})
Python version 2.5, Windows version XP Professional
2002, Service Pack 2
--
>Comment By: Fredrik Lundh (effbot)
Date: 2006-10-07 15:05
Message:
Logged In: YES
user_id=38376
The first two arguments in the ET interface are positional
arguments, not keyword arguments.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1572710&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1569057 ] Using .next() on file open in write mode writes junk to file
Bugs item #1569057, was opened at 2006-10-01 23:49
Message generated for change (Comment added) made by rainy
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569057&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: andrei kulakov (rainy)
Assigned to: Nobody/Anonymous (nobody)
Summary: Using .next() on file open in write mode writes junk to file
Initial Comment:
When you open a file in write mode and use .next(), it
prints an error and writes many lines of junk to file.
I tested on windows and python 2.5:
>>> f = open('test', 'w')
>>> f.fileno()
4
>>> f.write('1\n')
>>> f.write('2\n3\n4\n')
>>> f.next()
Traceback (most recent call last):
File "", line 1, in
f.next()
IOError: [Errno 9] Bad file descriptor
>>> f.close()
>>> f = open('test')
>>> f.next()
'1\n'
>>> f.next()
'2\n'
>>> f.next()
'3\n'
>>> f.next()
'4\n'
>>> f.next()
'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x
00\x00\x00\x00\x00\x
00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
\x00\x00\x00\x00\x00\
x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
\x00\x00\x00
...many more lines of junk...'
--
>Comment By: andrei kulakov (rainy)
Date: 2006-10-07 11:04
Message:
Logged In: YES
user_id=511010
I tried it on win2k sp4 running python 2.5 and right now
tried it on winXP running python 2.4 - same error. Also, at
least one user on python newsgroup tried it and got a
slightly different result: he did not get the error on
.next() but the junk was written to the file. I paste my
latest attempt right out of IDLE, without any modification
(my first paste was also straight from idle). Except that I
trim the junk characters, because there's more than a
screen of 'em.
IDLE 1.1.2
>>> f = open('test', 'w')
>>> f.write('1\n')
>>> f.next()
Traceback (most recent call last):
File "", line 1, in -toplevel-
f.next()
IOError: [Errno 9] Bad file descriptor
>>> f.close()
>>> f = open('test')
>>> f.next()
'1\n'
>>> f.next()
"\x95\x00\xc8\xe ..."
Please let me know if you need to know anything else...
--
Comment By: Skip Montanaro (montanaro)
Date: 2006-10-07 05:38
Message:
Logged In: YES
user_id=44345
Works for me. (Nearly current build from SVN.) I find it implausible that your
explanation of failing to flush the file is the cause of the problem since
closing
the file will cause it to be flushed. You didn't open the file for "w+" so
there's no
opportunity to switch between writing and reading.
What platform are you using?
--
Comment By: andrei kulakov (rainy)
Date: 2006-10-03 20:23
Message:
Logged In: YES
user_id=511010
Python newsgroup folks said that this is normal because when
switching between write/read modes without doing flush()
first, result is undefined. There was a suggestion from
Terry Ready to add this to documentation on file methods:
"When switching from reading or writing (or vice versa),
call flush(), or
the result will be undefined."
thx, -andrei
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569057&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1569356 ] sys.settrace cause curried parms to show up as attributes
Bugs item #1569356, was opened at 2006-10-02 08:26
Message generated for change (Comment added) made by josiahcarlson
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569356&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: applebucks (scott_marks)
Assigned to: Martin v. Löwis (loewis)
Summary: sys.settrace cause curried parms to show up as attributes
Initial Comment:
The code below exhibits different behavior depending on
whether it invokes sys.settrace ('-t' option) or not.
This means that (in a more complicated case) debugging
the code (which uses sys.settrace) makes it fail.
Reported v 2.4, but the same behavior on 2.5. Any ideas?
""" Demonstrace that tracing messes up curried class
definitions """
# Some simple command line parsing: -t or --trace means
trace, nothing means don't trace
import sys
def usage( ):
print 'Usage:', sys.argv[ 0 ], '[-t | --trace]'
sys.exit( 1 )
if 1 == len( sys.argv ):
pass
elif 2 == len( sys.argv ):
if sys.argv[ 1 ]=='-t' or sys.argv[ 1 ]=='--trace':
def trace ( frame, event, arg ):
# print frame, event, arg
return trace
sys.settrace( trace )
else:
usage( )
else:
usage( )
# The test: define a class factory with a curried
member function
def the_factory( parm1 ):
class the_class( object ):
def curried( self ): return parm1
return the_class
x = the_factory( 42 )
y = x( )
try:
x.parm1
print "Failure: x (the manufactured class) has
attribute parm1?!"
except AttributeError:
print "Success with the manufactured class!"
try:
y.parm1
print "Failure: y (the instance) has attribute parm1?!"
except AttributeError:
print "Success with the instance!"
assert y.curried( ) == 42, "Currying didn't work?!"
--
Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-10-07 09:54
Message:
Logged In: YES
user_id=341410
I'm not going to comment on the internals, because I don't
know enough about them to make a positive comment, but it
seems to me that your statement of:
..."just makes Python seem ... lame."
is insulting to those who have helped to develop Python over
the years. In my experience attempting to help, the surest
way of not getting what you want is to insult those who have
developed Python (nevermind that according to the lack of
bugs on the topic, very few people want/need the
functionality you expect).
--
Comment By: applebucks (scott_marks)
Date: 2006-10-03 19:32
Message:
Logged In: YES
user_id=120857
"Cannot be fixed" sounds pretty final, and also a little
pessimistic. From your description, it seems that the
correct functionality could be maintained at the cost of
retention of the keys in "normal locals" and dissection back
into "fast locals" and "normal locals" after the trace
function does ... whatever it does. In particular, it seems
unacceptable that the invariants of the semantics of class
creation (on which introspection and other important
functionality depends) is borked by debugging in such a way
as to render quite misleading the process of debugging code
that depends on those invariants.
Not to mention that the workaround ("be sure to rename your
class factory function parameters so that they don't collide
with intended attributes of the created class") just makes
Python seem ... lame.
I hope for a more optimistic reply.
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-10-02 23:49
Message:
Logged In: YES
user_id=849994
I'm afraid that this cannot be fixed.
In normal execution, the variable "parm1" is stored by the
compiler in the "fast locals" (that are referenced by index
into a list) for the function that is used to build the
class, which means that it is not in the dict of "normal
locals" (that are referenced by their name in the dict) that
is returned at the end.
If you set a trace function, on each call to the trace
function the "fast locals" are merged into the "normal
locals" in order to give the trace function full control
over the execution frame. This means that after the trace
function has been executed for the class' frame, the locals
will contain "parm1" which will then show up as an attribute
of that class.
Martin, do you you have an additional opinion?
--
Comment By: applebucks (scott_marks)
Date: 2006-10-02 09:02
Message:
Logged In: YES
user_id=120857
This bug actually causes a failure in a system that heavily
uses function-level programming and member delegat
[ python-Bugs-1571112 ] simple moves freeze IDLE
Bugs item #1571112, was opened at 2006-10-04 21:46 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1571112&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Douglas W. Goodall (douglas_goodall) Assigned to: Nobody/Anonymous (nobody) Summary: simple moves freeze IDLE Initial Comment: Using version 2.5 for Windows... import os then type "print os." and wait for the hint window. then scroll to the bottom (spawnv). That's it. At this point IDLE is frozen. I have done it a few times in a row. It seems very reproduceable to me. Be well. Doug -- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-10-07 09:58 Message: Logged In: YES user_id=341410 I can reproduce this on 2.5 beta 2, and it dies exactly when 'spawnv' is highlighted. I have no suggested fixes, only reproducing to verify that this is not user-specific bug. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1571112&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1571112 ] simple moves freeze IDLE
Bugs item #1571112, was opened at 2006-10-05 00:46 Message generated for change (Settings changed) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1571112&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: Platform-specific Status: Open Resolution: None >Priority: 6 Submitted By: Douglas W. Goodall (douglas_goodall) >Assigned to: Kurt B. Kaiser (kbk) Summary: simple moves freeze IDLE Initial Comment: Using version 2.5 for Windows... import os then type "print os." and wait for the hint window. then scroll to the bottom (spawnv). That's it. At this point IDLE is frozen. I have done it a few times in a row. It seems very reproduceable to me. Be well. Doug -- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-10-07 12:58 Message: Logged In: YES user_id=341410 I can reproduce this on 2.5 beta 2, and it dies exactly when 'spawnv' is highlighted. I have no suggested fixes, only reproducing to verify that this is not user-specific bug. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1571112&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1567450 ] tabs missing in idle options configure
Bugs item #1567450, was opened at 2006-09-28 23:34 Message generated for change (Settings changed) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1567450&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: None >Status: Closed Resolution: Works For Me Priority: 5 Submitted By: jrgutierrez (jrgutierrez) Assigned to: Kurt B. Kaiser (kbk) Summary: tabs missing in idle options configure Initial Comment: 1)The option to select indentation type (insert spaces or tabs) is missing 2) The indented width is ignored As a result IDLE 2.5 always indents inserting tabs, width 8 Sources edited in IDLE 2.4 cannot be corrected with IDLE 2.5: The tabbing errors cannot be corrected with IDLE 2.5. You must revert to IDLE 2.4 -- Comment By: Kurt B. Kaiser (kbk) Date: 2006-10-01 02:39 Message: Logged In: YES user_id=149084 See IDLE NEWS for 1.2a1. The ability to configure tab insertion as a default didn't work, and was removed. You can set the default by changing config-main.def: [Indent] use-spaces=0 but Python policy is to strongly encourage spaces instead of tabs. For any edit window, you can switch to tab indentation by using the Format / Toggle Tabs menu selection. When using Tabs in an edit window, the indent width must be eight spaces because of Tk limitations. If a file uses tabs, you have to toggle tabs 'on' before you start editing it. IDLE doesn't yet have the ability to detect whether a file uses tabs or spaces. (A TAB indicator in the status line would be useful.) Note that Tabs are always used in the Shell window. I'm not sure what you mean by "cannot be corrected". The Format menu has Tabify and Untabify. I suspect it might be clearer if the dialog asking for 'tab width' was changed to ask for 'indent width'. I am able to change back and forth between tabs and spaces in any region, but it does take some care. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1567450&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1442493 ] IDLE shell window gets very slow when displaying long lines
Bugs item #1442493, was opened at 2006-03-03 09:45 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1442493&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Heiko Selber (drhok) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE shell window gets very slow when displaying long lines Initial Comment: I wrote a little python script that prints a large dictionary to stdout (simply using 'print mydictionary'). In fact, the type is irrelevant, what matters is that the resulting output had approx. 200,000 characters. The shell prints the dictionary into a single line, which causes the window to be almost non-responding, e.g. when I try to scroll the window. Even on a high-end PC it takes a minute or even longer to react to anything. I use Python 2.4.2 on Windows XP SP2. I am aware that it is not exactly wise to print such large objects, but I usually print return values to stdout when I debug a script, and I do not always expect an object to be that large. The average text editor handles such long lines much better. A quick workaround might be to break very long lines automagically (perhaps at around column 1000). PS: I already observed the bug some years ago. I think I even submitted it to python or idlefork a long time ago but I was unable to find it in the buglist. -- >Comment By: Kurt B. Kaiser (kbk) Date: 2006-10-07 13:45 Message: Logged In: YES user_id=149084 Patch 1529353 by Tal Einat -- Comment By: Tal Einat (taleinat) Date: 2006-07-26 19:35 Message: Logged In: YES user_id=1330769 Done. -- Comment By: Kurt B. Kaiser (kbk) Date: 2006-07-26 16:38 Message: Logged In: YES user_id=149084 Sure, please open a patch and supply a diff against Noam's version. -- Comment By: Tal Einat (taleinat) Date: 2006-07-26 13:56 Message: Logged In: YES user_id=1330769 The Squeezer extension works like a charm! It's also been thoroughly tested by tens of users over the past several years. Why not include it as one of the default extensions, and have it enabled by default? BTW I have a tweaked version of Squeezer (I fixed the line counting code), if you're interested. -- Comment By: Kurt B. Kaiser (kbk) Date: 2006-03-29 15:52 Message: Logged In: YES user_id=149084 It's not that I don't consider it an issue, but I can't do anything to improve the performance of the Tk text widget. IDLE is pure Python. One thing that comes to mind is to set a maximum line length. If the line exceeds that, print line(:(MAX -100) + '...' + line(:-100) instead of printing the whole thing which no one wants to look at anyway. Another thing I've wanted to do is provide the ability to clear the shell window when it gets too full, w/o restarting IDLE. Yes, you might ask the tkinter guys on their mail list, I'd be interested in hearing their reply. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-03-29 15:35 Message: Logged In: YES user_id=341410 You can close the window which includes the Shell that has the huge output, or even reduce the priority of your Idle shell (you can make it automatic by mucking about with the shortcut; see the 'start' command). -- Comment By: Heiko Selber (drhok) Date: 2006-03-29 15:19 Message: Logged In: YES user_id=865975 Hi kbk, well, my use case is debugging. I write a script and run it with IDLE. It doesn't behave as expected, so I insert a print statement. Next time I run it, IDLE hangs. Oops, it was a long array; it should have been an int. Line too long. Duh. OK, I wait through it, correct the bug, run it again. What happens? IDLE hangs again, trying to scroll a long line (of the previous run). Never mind, I can always kill the process... Dammit, I can't! It eats 100% CPU; task manager doesn't respond. IMHO his takes away one of python's strengths, which is making quick hacks really quick. Would you suggest redirecting this issue to tkinter? You don't seem to consider this an issue at all. I will give squeezer a try. Or maybe PyDev? -- Comment By: Kurt B. Kaiser (kbk) Date: 2006-03-28 18:08 Message: Logged In: YES user_id=149084 This is a known problem with Tk/Tcl/tkinter - large output
[ python-Bugs-1563630 ] IDLE doesn't load - apparently without firewall problems
Bugs item #1563630, was opened at 2006-09-22 13:19 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563630&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: dani (daniboy22) Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE doesn't load - apparently without firewall problems Initial Comment: I've installed Python in Windows XP, SP2. When I ran IDLE for the first times, it worked ok. But then I redefined some shorcuts (history-previous, history-next, and expand-word). This also worked ok, but there was a problem I wasn't expecting: I changed the history-previous to the short-cut + P, and when I use it for the first time it printed the content of the window... I forgot that this shorcut was already in use... Then came the real problem. I went to redefine the history-previous to another key set, but each time I clicked for "oK" for the new keys, the shell wrote some errors in red (-/+ 7/8 lines). I did that a few times until I closed IDLE and tried to restarted it again. Then it stop working. The only thing it does now is to show the hourglass logo in the mouse pointer for a few seconds and then it does not do anything else. I've installed Python in its default path (C:\Python25), and tried to switch off all the firewalls I remembered (Windows Firewall and disabled McAfee Virus Scan). None of that worked. I tried several times to reinstall the software, but that didn't work either. I even tried to install a previous version of Python (v2.4.3), but it had exactly the same problem. I haven't found any similar problem on the web. Thanks, Dani -- >Comment By: Kurt B. Kaiser (kbk) Date: 2006-10-07 13:52 Message: Logged In: YES user_id=149084 I take it that the problem is gone now? If it's real, to have any hope of addressing it I need to be able to reproduce it. IDLE may be printing error messages to stderr. If you have more problems, start IDLE from a command window so you can see the error messages: cd to idlelib and run ..\..\python .\PyShell.py -- Comment By: jordanramz (jordanramz) Date: 2006-10-04 19:58 Message: Logged In: YES user_id=1604497 Well I think there is just a problem with my OS files or something anyway. There are a couple other things (i.e. my "Recent Documents" folder) that do the same thing, even when I'm logged on as myself. Thanks for the help though. I need something to run and find/fix errors with my system, but not sure what the best program is. If you know of any, could you let me know. :) Thanks -- Comment By: dani (daniboy22) Date: 2006-10-04 10:38 Message: Logged In: YES user_id=1604341 Usually I do not need to boot on safe mode to log in as asministrator (I also work on a laptop)... The safe mode reduces some of the Windows functionalities... Perhaps this is the real reason for your problem. Otherwise, I don't know what to tell you more... :-( -- Comment By: jordanramz (jordanramz) Date: 2006-10-03 22:45 Message: Logged In: YES user_id=1604497 The problem is that it is my laptop, so I am the administrator. I booted up in safe mode so that I could log on as the administrator, and even then it wouldn't let me access any of my (username) documents, so I couldn't even get in to view that folder let alone change the name. -- Comment By: dani (daniboy22) Date: 2006-10-03 09:33 Message: Logged In: YES user_id=1604341 Well, I'm also not a specialist on the subject, but in my case I don't have any problems in opening the folder. I just had some problems to rename it (it didn't accepted a name starting with a "."), but I resolve it (I rename it to "pinga"). Concerning your problem, my hint is that your account is not an administrator one. Try to enter as an administrator and make the necessary changes. Or else change the permissions of your account to the "administrator" type (ask someone that is already an administrator on that computer to do that). -- Comment By: jordanramz (jordanramz) Date: 2006-10-02 18:15 Message: Logged In: YES user_id=1604497 Thanks for that, I found it. However, I guess I'm not as skilled with the computer as I thought... It won't let me change the name, open the folder etc. It says access is denied. Know why it's doing that when I try to modify it? --
[ python-Bugs-1571754 ] Building using Sleepycat db 4.5.20 is broken
Bugs item #1571754, was opened at 2006-10-05 23:31 Message generated for change (Comment added) made by robert-scheck You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1571754&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Robert Scheck (robert-scheck) Assigned to: Nobody/Anonymous (nobody) Summary: Building using Sleepycat db 4.5.20 is broken Initial Comment: Using latest Sleepycat db 4.5.20, I'm getting the following result during make of python 2.5: gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -fPIC - DPy_BUILD_CORE -I/usr/include/db4 -c ./Modules/_bsddb. c -o Modules/_bsddb.o ./Modules/_bsddb.c: In function 'DBEnv_set_lk_max': ./Modules/_bsddb.c:4142: error: 'DB_ENV' has no member named 'set_lk_max' ./Modules/_bsddb.c: In function 'init_bsddb': ./Modules/_bsddb.c:5838: error: 'DB_CACHED_COUNTS' undeclared (first use in this function) ./Modules/_bsddb.c:5838: error: (Each undeclared identifier is reported only once ./Modules/_bsddb.c:5838: error: for each function it appears in.) ./Modules/_bsddb.c:5873: error: 'DB_RECORDCOUNT' undeclared (first use in this function) make: *** [Modules/_bsddb.o] Error 1 -- >Comment By: Robert Scheck (robert-scheck) Date: 2006-10-07 21:11 Message: Logged In: YES user_id=203809 The attached patches are solving the problems for me and should be the correct fix when reading Sleepycat's upgrade documentation... -- Comment By: Robert Scheck (robert-scheck) Date: 2006-10-05 23:34 Message: Logged In: YES user_id=203809 Ah, python 2.4.3 has the same problem plus further errors: ./Modules/_bsddb.c: In function 'DB_length': ./Modules/_bsddb.c:2453: error: 'DB_CACHED_COUNTS' undeclared (first use in this function) ./Modules/_bsddb.c:2453: error: (Each undeclared identifier is reported only once ./Modules/_bsddb.c:2453: error: for each function it appears in.) ./Modules/_bsddb.c: In function 'DBEnv_set_lk_max': ./Modules/_bsddb.c:3811: error: 'DB_ENV' has no member named 'set_lk_max' ./Modules/_bsddb.c: In function 'init_bsddb': ./Modules/_bsddb.c:5004: error: 'DB_CACHED_COUNTS' undeclared (first use in this function) ./Modules/_bsddb.c:5039: error: 'DB_RECORDCOUNT' undeclared (first use in this function) make: *** [Modules/_bsddb.o] Error 1 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1571754&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-691733 ] Let assign to as raise SyntaxWarning as well
Bugs item #691733, was opened at 2003-02-23 09:08 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=691733&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 2 Submitted By: Gerrit Holl (gerrit) >Assigned to: Neal Norwitz (nnorwitz) Summary: Let assign to as raise SyntaxWarning as well Initial Comment: according to the Python Language Reference Manual: > In some future version of Python, the identifiers > as and None will both become keywords. Hence, it seems natural to me to raise a SyntaxWarning when assigning to either of these. However, the current Python implementation doesn't: 103 >>> None="foo":1: SyntaxWarning: assignment to None 104 >>> as="foo" 105 >>> For consistency and cleanliness, assignment to 'as' should raise a SyntaxWarning as well. Currently, it's possible to not know it'll be a keyword and use it as a variable; people shouldn't, so a SyntaxWarning would be good. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-10-07 15:37 Message: Logged In: YES user_id=33168 The warning was added for 2.5 and 2.6 this produces an error. Python 2.5 (release25-maint:51996M, Sep 26 2006, 00:14:14) >>> as = None :1: Warning: 'as' will become a reserved keyword in Python 2.6 Python 2.6a0 (trunk:51986M, Oct 7 2006, 15:36:46) >>> as = None File "", line 1 as = None ^ SyntaxError: invalid syntax -- Comment By: Georg Brandl (birkenfeld) Date: 2005-08-31 14:59 Message: Logged In: YES user_id=1188172 For Py2.5, "with" and "as" will become keywords. However, that will need "from __future__ import with_statement". So I suggest to raise SyntaxWarning in 2.5 without this statement if with or as are used as names. -- Comment By: Georg Brandl (birkenfeld) Date: 2005-05-31 04:23 Message: Logged In: YES user_id=1188172 This may be too late if as becomes a keyword in the new with/do/whatever-statement... -- Comment By: Gerrit Holl (gerrit) Date: 2003-02-23 09:21 Message: Logged In: YES user_id=13298 I'm not sure whether this should be considered as a feature. I'd call it a minor wart... I'm also not sure about the category, is this 'Python interpreter core' or am I right with 'parser/compiler'? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=691733&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-764447 ] cvs update warnings
Bugs item #764447, was opened at 2003-07-02 00:56 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764447&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Macintosh Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Sjoerd Mullender (sjoerd) Assigned to: Just van Rossum (jvr) Summary: cvs update warnings Initial Comment: On Windows, when you do "cvs update" in the "Mac/IDE scripts" directory, you get the following warnings (example uses Cygwin, but it also happens with other CVS clients): $ cd "Mac/IDE scripts"; cvs update ? Hold option to open a script ? Insert file name ? Insert folder name ? Search Python Documentation ? Hack/Remove .pyc files ? Hack/Toolbox Assistant cvs server: Updating . cvs server: Updating Hack cvs server: Updating Widget demos $ This is due to the fact that Windows can't deal with periods at the end of file names. All files giving warnings end in "...". These periods are removed when the files get created, and so CVS sees the files without periods and complains about them. At one level the solution is simple: rename those files. At another level, I don't know what the consequences are for the Mac, so assigning to Just (Jack doesn't seem to want to deal with this :-) -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-10-07 15:44 Message: Logged In: YES user_id=33168 Mac/IDE scripts is gone, so is CVS. :-) -- Comment By: Nick Coghlan (ncoghlan) Date: 2004-07-04 20:46 Message: Logged In: YES user_id=1038590 The leading spaces on some filenames are causing Eclipse to choke on the checkout, too (I'm guessing the spaces are there to get the right sequencing of the filenames). One possibility that would give a minimal change is to prepend and append underscores to all of the filenames, then modify the code that reads these files to remove the first and last character before performing the same parsing it does now. -- Comment By: Sjoerd Mullender (sjoerd) Date: 2003-09-09 07:12 Message: Logged In: YES user_id=43607 It's now past 2.3 final, so can you look into this again? -- Comment By: Sjoerd Mullender (sjoerd) Date: 2003-07-02 03:36 Message: Logged In: YES user_id=43607 I've lived with this for years. A few more weeks won't matter. -- Comment By: Just van Rossum (jvr) Date: 2003-07-02 02:33 Message: Logged In: YES user_id=92689 Any objections to postponing this to after 2.3 final? The thing is, currently these file names map to menu items directly, and to fix this I have to build a way to specify the menu item from within the file. This will cause way more changes than I'm comfortable with, just before 2.3. Removing the spaces from folder names can be done at the same time. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764447&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-789159 ] Minor floatobject.c bug
Bugs item #789159, was opened at 2003-08-15 03:39
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789159&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.2.3
>Status: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: Nick Maclaren (nmm1)
Assigned to: Nobody/Anonymous (nobody)
Summary: Minor floatobject.c bug
Initial Comment:
The following is a previously reported bug that got
only half fixed.
The bug was closed before I could respond that the fix
was incomplete;
here is a complete fix.
The failure is when overflow checking is enabled on
integers, as is
good programming practice and permitted by the C
standard. It could
also cause wrong answers if overflow is mishandled (as
is also permitted
and can happen).
*** ./Objects/floatobject.c.org Tue Jan 28 19:40:35
2003
--- ./Objects/floatobject.c Tue Jun 3 13:02:48
2003
***
*** 659,667
to long may yield gibberish in either case.
What really matters
is whether converting back to double again
reproduces what we
started with. */
! aslong = (long)wholepart;
! if ((double)aslong == wholepart)
! return PyInt_FromLong(aslong);
PyErr_SetString(PyExc_OverflowError, "float too
large to convert");
return NULL;
}
--- 659,669
to long may yield gibberish in either case.
What really matters
is whether converting back to double again
reproduces what we
started with. */
! if (wholepart > LONG_MIN-1.0 && wholepart <
LONG_MAX+1.0) {
! aslong = (long)wholepart;
! if ((double)aslong == wholepart)
! return PyInt_FromLong(aslong);
! }
PyErr_SetString(PyExc_OverflowError, "float too
large to convert");
return NULL;
}
Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH,
England.
Email: [EMAIL PROTECTED]
Tel.: +44 1223 334761Fax: +44 1223 334679
--
>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-10-07 15:54
Message:
Logged In: YES
user_id=33168
The code is out of date. It looks like the problem has been
addressed. Please provide an updated patch in a new report
if this is not the case.
--
Comment By: Nick Maclaren (nmm1)
Date: 2003-08-15 08:08
Message:
Logged In: YES
user_id=652073
Thanks for the remark about closing. I tried to append,
but Sourceforge wouldn't let me. It is all a while ago
now, though.
Heck. I remember the discussion. That has problems when
rounding gets in the way. The following is an improved
fix and SHOULD work on all machines, past, present and
future that support standard C and used a power of two
base floating-point (or base 10, actually):
*** floatobject.c.org Tue Jan 28 19:40:35 2003
--- floatobject.c Fri Aug 15 15:22:48 2003
***
*** 645,667
{
double x = PyFloat_AsDouble(v);
double wholepart; /* integral portion of x,
rounded toward 0 */
! long aslong;/* (long)wholepart */
(void)modf(x, &wholepart);
- #ifdef RISCOS
- /* conversion from floating to integral type would
raise exception */
- if (wholepart>LONG_MAX || wholepart LONG_MIN/2 && wholepart <
LONG_MAX/2)
! x = 0.0;
! else {
! k = (x >= 0.0);
! x =
[ python-Bugs-971213 ] another threads+readline+signals nasty
Bugs item #971213, was opened at 2004-06-11 08:30 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=971213&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None >Status: Closed Resolution: Works For Me Priority: 7 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Anthony Baxter (anthonybaxter) Summary: another threads+readline+signals nasty Initial Comment: python -c "import time, readline, thread; thread.start_new_thread(raw_input, ()); time.sleep(2)" Segfaults on ^C Fails on Linux, freebsd. On linux (FC - using kernel 2.6.1, glibc 2.3.3, gcc-3.3.3) (gdb) where #0 0x002627a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x008172b1 in ___newselect_nocancel () from /lib/tls/libc.so.6 #2 0x0011280b in time_sleep (self=0x0, args=0xb7fe17ac) at Modules/timemodule.c:815 on FreeBSD 5.2.1-RC, a different error. Fatal error 'longjmp()ing between thread contexts is undefined by POSIX 1003.1' at line 72 in file /usr/src/lib/libc_r/uthread/uthread_jmp.c (errno = 2) Abort (core dumped) -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-10-07 16:25 Message: Logged In: YES user_id=33168 I'm closing this since it's presumably fixed. -- Comment By: Georg Brandl (gbrandl) Date: 2006-08-18 22:35 Message: Logged In: YES user_id=849994 Not reproducable here either (Gentoo x86). -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-18 20:09 Message: Logged In: YES user_id=33168 This doesn't crash for me any more. I remember there was another fix for socket timeouts and Ctrl-C. Maybe that fixed this too? Anthony, can you reproduce this? -- Comment By: Michael Hudson (mwh) Date: 2005-10-03 04:13 Message: Logged In: YES user_id=6656 I can't, on OS X or debian. -- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-02 21:12 Message: Logged In: YES user_id=33168 I can reproduce with cvs head (gentoo linux/amd64). -- Comment By: Michael Hudson (mwh) Date: 2005-04-07 02:03 Message: Logged In: YES user_id=6656 I think this is fixed now, as in I can't reproduce it with CVS HEAD. Not sure why! I can think of a few fixes that might be responsible. It still messes the terminal up, though. -- Comment By: Michael Hudson (mwh) Date: 2004-08-07 14:41 Message: Logged In: YES user_id=6656 Bah, this still segfaults with CVS head. -- Comment By: Michael Hudson (mwh) Date: 2004-06-21 03:45 Message: Logged In: YES user_id=6656 Can you try the patch that's *now* in 960406? It seems to help for me (but I really would rather not think too hard about this!). -- Comment By: Michal Pasternak (mpasternak) Date: 2004-06-11 08:43 Message: Logged In: YES user_id=799039 readline used on FreeBSD was readline-4.3pl5; everything else: gcc 3.3.3, ncurses, libc were standard from 5.2.1. -- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-06-11 08:39 Message: Logged In: YES user_id=29957 The patch in #960406 doesn't help here. The FC test system also has readline-4.3, if it helps, as does the FreeBSD box. It apparently doesn't crash on OSX. -- Comment By: Michael Hudson (mwh) Date: 2004-06-11 08:38 Message: Logged In: YES user_id=6656 Hmm. Doesn't crash on OS X. Messes the terminal up good and proper, though. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=971213&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1572968 ] release GIL while doing I/O operations in the mmap module
Feature Requests item #1572968, was opened at 2006-10-08 02:26 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1572968&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Lukas Lalinsky (luks) Assigned to: Nobody/Anonymous (nobody) Summary: release GIL while doing I/O operations in the mmap module Initial Comment: There is a few system I/O calls in the mmap module that can take some time. Would be be possible to put Py_BEGIN_ALLOW_THREADS/Py_END_ALLOW_THREADS around these to release the GIL and allow other Python threads to do their work? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1572968&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1571112 ] simple moves freeze IDLE
Bugs item #1571112, was opened at 2006-10-04 23:46 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1571112&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE >Group: Python 2.5 Status: Open Resolution: None >Priority: 7 Submitted By: Douglas W. Goodall (douglas_goodall) >Assigned to: Nobody/Anonymous (nobody) Summary: simple moves freeze IDLE Initial Comment: Using version 2.5 for Windows... import os then type "print os." and wait for the hint window. then scroll to the bottom (spawnv). That's it. At this point IDLE is frozen. I have done it a few times in a row. It seems very reproduceable to me. Be well. Doug -- >Comment By: Raymond Hettinger (rhettinger) Date: 2006-10-07 22:16 Message: Logged In: YES user_id=80475 I can reproduce this in Py2.5 final. This may be a TkInter bug and not unique to IDLE or to Windows. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-10-07 11:58 Message: Logged In: YES user_id=341410 I can reproduce this on 2.5 beta 2, and it dies exactly when 'spawnv' is highlighted. I have no suggested fixes, only reproducing to verify that this is not user-specific bug. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1571112&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
