[ python-Bugs-1563630 ] IDLE doesn't load - apparently without firewall problems
Bugs item #1563630, was opened at 2006-09-22 12:19 Message generated for change (Comment added) made by jordanramz 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: jordanramz (jordanramz) Date: 2006-10-01 11:42 Message: Logged In: YES user_id=1604497 What is the .idlerc customization folder? -- Comment By: Kurt B. Kaiser (kbk) Date: 2006-09-30 21:38 Message: Logged In: YES user_id=149084 Use the task manager to kill all Python processes. Then set aside your .idlerc customization folder (i.e. rename it). Now IDLE should start. Try to recreate the problem and post any error messages you see here. -- Comment By: jordanramz (jordanramz) Date: 2006-09-22 16:15 Message: Logged In: YES user_id=1604497 I am having the same problem. When I first installed it, it ran okay. Now everytime I go back to run it, the hourglass on my mouse shows up for a few seconds and then nothing. At first I had v2.4.3 because that's what we're using in my class, but I tried v2.5(final) thinking it would help, but it didn't, so I reinstalled v2.4.3. I noticed that with my task manager in view, when I click the IDLE program my processes jump up one number for a few seconds also, then goes back. So apparently it's running but then ending before it loads up? I tried messing with my firewall and stuff also, with no success, so I'm in the same boat as you. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563630&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1568842 ] Test for uintptr_t seems to be incorrect
Bugs item #1568842, was opened at 2006-10-01 20:10 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=1568842&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: 6 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Nobody/Anonymous (nobody) Summary: Test for uintptr_t seems to be incorrect Initial Comment: Someone reported on the pythonmac list that HAVE_UINTPTR_T wasn't defined in pyconfig.h while it should have been defined. I'm looking into this and am now wondering whether the configure snipped below is correct: AC_MSG_CHECKING(for uintptr_t support) have_uintptr_t=no AC_TRY_COMPILE([], [uintptr_t x; x = (uintptr_t)0;], [ AC_DEFINE(HAVE_UINTPTR_T, 1, [Define this if you have the type uintptr_t.]) have_uintptr_t=yes ]) AC_MSG_RESULT($have_uintptr_t) if test "$have_uintptr_t" = yes ; then AC_CHECK_SIZEOF(uintptr_t, 4) fi This seems to check for uintptr_t as a builtin type. Isn't one supposed to include to get this type? Chaning the AC_TRY_COMPILE line to the line below fixes the issue for me on OSX and Linux: AC_TRY_COMPILE([#include ], [uintptr_t x; x = (uintptr_t)0;], [ BTW. This issue is also present in Python 2.4. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568842&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1568897 ] http redirect does not pass 'post' data
Bugs item #1568897, was opened at 2006-10-02 10:08 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=1568897&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: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: hans_moleman (hans_moleman) Assigned to: Nobody/Anonymous (nobody) Summary: http redirect does not pass 'post' data Initial Comment: A HTTP(S) redirect does not pass POST 'data'. Currently: If a redirect is required, a new Request is created with a URL that the redirect response has provided. This new Request has the original headers. Required: For the new Request the data too will be copied from the original Request. I believe the following one line change is required in 'urllib2.HTTPRedirectHandler.redirect_request': return Request(url = newurl, headers = req.headers, data= req.data, ... Environment: Linux Python 2.5 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568897&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1562716 ] Spurious Tabnanny error
Bugs item #1562716, was opened at 2006-09-21 04:23
Message generated for change (Comment added) made by kbk
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562716&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: Closed
>Resolution: Fixed
Priority: 5
Submitted By: torhu (torhu)
>Assigned to: Kurt B. Kaiser (kbk)
Summary: Spurious Tabnanny error
Initial Comment:
IDLE 1.2, Py 2.5 on WinXP SP2.
The extra parenthesis on the second line triggers a
warning message box:
"Tabnanny Tokenizing Error"
"Token Error: EOF in multi-line statement"
for i in range(10):
a = list("123"))
The second line is indented with 8 or 4 spaces, doesn't
matter which.
Can't recall this happening in the IDLE version bundled
with py2.4. Don't know if IDLE or the tabnanny module
is the culprit.
--
>Comment By: Kurt B. Kaiser (kbk)
Date: 2006-10-01 17:17
Message:
Logged In: YES
user_id=149084
Problem is with the tokenize module.
A pre-run tabnanny check was added to 2.5.
I've corrected this by doing the syntax check first.
Rev 52083
--
Comment By: torhu (torhu)
Date: 2006-09-21 04:25
Message:
Logged In: YES
user_id=1038085
I also had somone on #python confirm this behavior for me.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562716&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1562719 ] Spurious Tab/space error
Bugs item #1562719, was opened at 2006-09-21 04:29
Message generated for change (Comment added) made by kbk
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562719&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: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: torhu (torhu)
>Assigned to: Kurt B. Kaiser (kbk)
Summary: Spurious Tab/space error
Initial Comment:
IDLE 1.2, Py 2.5 on WinXP SP2.
The extra parenthesis on the second line triggers a
warning message box:
"Tab/space error"
"Error: Inconsistent indentation detected!"
Etc.
for i in range(10):
a = list("123"))
x = 5
The second line is indented with 8 spaces.
Can't recall this happening in the IDLE version bundled
with py2.4.
--
>Comment By: Kurt B. Kaiser (kbk)
Date: 2006-10-01 17:19
Message:
Logged In: YES
user_id=149084
see 1562716
--
Comment By: torhu (torhu)
Date: 2006-09-21 04:30
Message:
Logged In: YES
user_id=1038085
I also had somone on #python confirm this.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562719&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-779460 ] plistlib should be moved out of plat-mac
Bugs item #779460, was opened at 2003-07-29 09:01 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779460&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: Feature Request >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Sarwat Khan (sarwatfoo) Assigned to: Nobody/Anonymous (nobody) Summary: plistlib should be moved out of plat-mac Initial Comment: plistlib doesn't (I think, it shouldn't anyway) have any Mac dependancies and should be moved out of plat-mac so plists can be generated and parsed on non-Mac platforms. I intend to use it, for example, on a Linux web server in CGI scripts for basic XML handling. -- >Comment By: Georg Brandl (gbrandl) Date: 2006-10-01 22:23 Message: Logged In: YES user_id=849994 Duplicate of #1565129. -- Comment By: Guido Guenther (guidog) Date: 2006-09-13 13:12 Message: Logged In: YES user_id=696207 Can this be done for python 2.5 please. It's need to run apple's caldav server on e.g. Linux. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779460&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1552935 ] Pythonw doesn't get rebuilt if version number changes
Bugs item #1552935, was opened at 2006-09-05 12:37 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1552935&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: Python 2.6 >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Ronald Oussoren (ronaldoussoren) Summary: Pythonw doesn't get rebuilt if version number changes Initial Comment: If the Python version number changes (as it did this week) Mac/pythonw should get rebuilt so it fires up the correct real Python executable. -- >Comment By: SourceForge Robot (sf-robot) Date: 2006-10-01 19:20 Message: Logged In: YES user_id=1312539 This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). -- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-09-17 12:23 Message: Logged In: YES user_id=580910 This should be fixed in revision 51904. -- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-09-14 14:16 Message: Logged In: YES user_id=580910 pythonw should depend on the Makefile and the Makefile should be automaticly rebuild when config.status changes (just like the toplevel Makefile). I'll check in a patch this weekend, I need to test before I do the checkin. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1552935&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1565797 ] 'all' documentation missing online
Bugs item #1565797, was opened at 2006-09-26 10:21 Message generated for change (Comment added) made by aisaac0 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565797&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: Open Resolution: Invalid Priority: 5 Submitted By: Alan (aisaac0) Assigned to: Nobody/Anonymous (nobody) Summary: 'all' documentation missing online Initial Comment: http://docs.python.org/lib/built-in-funcs.html is missing a description of the new built-in 'all' function. On a separate note, contrary to the statement on the bugs page, the search dialogue is not in the left margin ... -- >Comment By: Alan (aisaac0) Date: 2006-10-01 22:23 Message: Logged In: YES user_id=1025672 For reasons unknown to me my browser was displaying a cached version of the Built-In Functions page. Very sorry for the noise. As for the other matter: the page is http://sourceforge.net/tracker/?func=add&group_id=5470&atid=105470 where the first full line of text is "Please try to see if the bug you are about to submit hasn't already been submitted before. The search box in the left margin can be used for this purpose." But the search box is above this text, to the right. fwiw -- Comment By: Martin v. Löwis (loewis) Date: 2006-09-26 11:06 Message: Logged In: YES user_id=21627 Could it be that you had been looking at an old version of the documentation (the new version wasn't online shortly after the release). I can clearly see 'all' documented as all(iterable) Return True if all elements of the iterable are true. Equivalent to: ... As for the separate note: what bugs page are you referring to? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565797&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 (Tracker Item Submitted) made by Item Submitter
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: Python Library
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...'
--
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-1569084 ] External codecs no longer usable
Bugs item #1569084, was opened at 2006-10-02 08:42
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=1569084&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: Unicode
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Ivan Vilata i Balaguer (ivilata)
Assigned to: M.-A. Lemburg (lemburg)
Summary: External codecs no longer usable
Initial Comment:
Up to Python 2.5, external codec packages could be used
just by dropping them somewhere in the $PYTHONPATH, as
long as they provided a ``getregentry()`` function and
the normalised encoding name matched the name of the
package. For instance, having a ``myencoding`` package
with a ``getregentry()`` function in it made possible
executing::
>>> u'something'.encode('myencoding')
without even importing ``myencoding``. It was the
``__import__(modname, ...)`` statement in
``encodings.search_function()`` which made this possible.
However, in Python 2.5 the previous statement was
changed to the absolute one ``__import('encodings.' +
modname, ...)``, which makes external codec packages no
longer reachable in the way described above. Is this a
bug, or has this been made on purpose? In the later
case, what do you recommend to use external codecs as
transparently as possible? I now manually enter the
registry tuple/CodecInfo into the encodings cache, but
tampering with it doesn't seem right (and it also means
that some initialisation code must be explicitly run).
By the way, this bug may be related with #223642.
Maybe it should be reopened.
Thank you very much!
(I know, I should have checked the betas and release
candidates in case this was a bug. I didn't have the
time, sorry!)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569084&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
