[ python-Bugs-1112549 ] cgi.FieldStorage memory usage can spike in line-oriented ops
Bugs item #1112549, was opened at 2005-01-30 08:40 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=1112549&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Chris McDonough (chrism) Assigned to: Nobody/Anonymous (nobody) Summary: cgi.FieldStorage memory usage can spike in line-oriented ops Initial Comment: Various parts of cgi.FieldStorage call its "read_lines_to_outerboundary", "read_lines" and "skip_lines" methods.These methods use the "readline" method of the file object that represents an input stream. The input stream is typically data supplied by an untrusted source (such as a user uploading a file from a web browser). The input data is not required by the RFC 822/1521/1522/1867 specifications to contain any newline characters. For example, it is within the bounds of the specification to supply a a multipart/form-data input stream with a "file-data" part that consists of a 2GB string composed entirely of "x" characters (which happens to be something I did that led me to noticing this bug). The simplest fix is to make use of the "size" argument of the readline method of the file object where it is used within all parts of FieldStorage that make use of it. A patch against the Python 2.3.4 cgi.py module that does this is attached. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112549&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1108992 ] idle freezes when run over ssh
Bugs item #1108992, was opened at 2005-01-25 10:44 Message generated for change (Comment added) made by mgpoolman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1108992&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Mark Poolman (mgpoolman) Assigned to: Nobody/Anonymous (nobody) Summary: idle freezes when run over ssh Initial Comment: Python 2.3.4 (#2, Aug 13 2004, 00:36:58) [GCC 3.3.4 (Debian 1:3.3.4-5ubuntu2)] on linux2 IDLE 1.0.3 When running idle over an ssh link, idle freezes after an unpredictable length of time. Over 3 days the longest it has stayed allive for is ~4hrs, but a few minutes before freezing is the norm. Niether idle nor python are consuming cpu time once frozen. I can find no definete recipie to bring about the freeze, although (I think) there has always been at least one editor window open when it happens. There is no output on stderr, or other diagnostics that I can see. ssh server(ubuntu warty): OpenSSH_3.8.1p1 Debian 1:3.8.1p1-11ubuntu3.1, OpenSSL 0.9.7d 17 Mar 2004 ssh client (RH9): OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090701f /best/* Mark -- >Comment By: Mark Poolman (mgpoolman) Date: 2005-01-30 17:02 Message: Logged In: YES user_id=993923 Yes, exactly. I'm pretty sure it's not an X/ssh/network problem, everything else works fine (including Idle 0.8). Mark -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-01-29 20:23 Message: Logged In: YES user_id=341410 It has been a while since I ran Idle, but I am curious as to what you mean by "run over ssh". Do you mean that you have an SSH tunnel to a remote machine, which forwards X-Windows sessions, and when running Idle over this, it locks up? -- Comment By: Mark Poolman (mgpoolman) Date: 2005-01-26 09:15 Message: Logged In: YES user_id=993923 PS - You don't need an editor window open to get the freeze. M -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1108992&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1108992 ] idle freezes when run over ssh
Bugs item #1108992, was opened at 2005-01-25 02:44 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1108992&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Mark Poolman (mgpoolman) Assigned to: Nobody/Anonymous (nobody) Summary: idle freezes when run over ssh Initial Comment: Python 2.3.4 (#2, Aug 13 2004, 00:36:58) [GCC 3.3.4 (Debian 1:3.3.4-5ubuntu2)] on linux2 IDLE 1.0.3 When running idle over an ssh link, idle freezes after an unpredictable length of time. Over 3 days the longest it has stayed allive for is ~4hrs, but a few minutes before freezing is the norm. Niether idle nor python are consuming cpu time once frozen. I can find no definete recipie to bring about the freeze, although (I think) there has always been at least one editor window open when it happens. There is no output on stderr, or other diagnostics that I can see. ssh server(ubuntu warty): OpenSSH_3.8.1p1 Debian 1:3.8.1p1-11ubuntu3.1, OpenSSL 0.9.7d 17 Mar 2004 ssh client (RH9): OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090701f /best/* Mark -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-01-30 11:43 Message: Logged In: YES user_id=341410 Do you have physical access to the ubuntu warty machine, and if so, does Idle run very well locally on that machine, not X forwarded? -- Comment By: Mark Poolman (mgpoolman) Date: 2005-01-30 09:02 Message: Logged In: YES user_id=993923 Yes, exactly. I'm pretty sure it's not an X/ssh/network problem, everything else works fine (including Idle 0.8). Mark -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-01-29 12:23 Message: Logged In: YES user_id=341410 It has been a while since I ran Idle, but I am curious as to what you mean by "run over ssh". Do you mean that you have an SSH tunnel to a remote machine, which forwards X-Windows sessions, and when running Idle over this, it locks up? -- Comment By: Mark Poolman (mgpoolman) Date: 2005-01-26 01:15 Message: Logged In: YES user_id=993923 PS - You don't need an editor window open to get the freeze. M -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1108992&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1108992 ] idle freezes when run over ssh
Bugs item #1108992, was opened at 2005-01-25 10:44 Message generated for change (Comment added) made by mgpoolman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1108992&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Mark Poolman (mgpoolman) Assigned to: Nobody/Anonymous (nobody) Summary: idle freezes when run over ssh Initial Comment: Python 2.3.4 (#2, Aug 13 2004, 00:36:58) [GCC 3.3.4 (Debian 1:3.3.4-5ubuntu2)] on linux2 IDLE 1.0.3 When running idle over an ssh link, idle freezes after an unpredictable length of time. Over 3 days the longest it has stayed allive for is ~4hrs, but a few minutes before freezing is the norm. Niether idle nor python are consuming cpu time once frozen. I can find no definete recipie to bring about the freeze, although (I think) there has always been at least one editor window open when it happens. There is no output on stderr, or other diagnostics that I can see. ssh server(ubuntu warty): OpenSSH_3.8.1p1 Debian 1:3.8.1p1-11ubuntu3.1, OpenSSL 0.9.7d 17 Mar 2004 ssh client (RH9): OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090701f /best/* Mark -- >Comment By: Mark Poolman (mgpoolman) Date: 2005-01-30 20:06 Message: Logged In: YES user_id=993923 Yes, I've used Idle on that (although only ~ 1 hour) and not seen the problem there. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-01-30 19:43 Message: Logged In: YES user_id=341410 Do you have physical access to the ubuntu warty machine, and if so, does Idle run very well locally on that machine, not X forwarded? -- Comment By: Mark Poolman (mgpoolman) Date: 2005-01-30 17:02 Message: Logged In: YES user_id=993923 Yes, exactly. I'm pretty sure it's not an X/ssh/network problem, everything else works fine (including Idle 0.8). Mark -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-01-29 20:23 Message: Logged In: YES user_id=341410 It has been a while since I ran Idle, but I am curious as to what you mean by "run over ssh". Do you mean that you have an SSH tunnel to a remote machine, which forwards X-Windows sessions, and when running Idle over this, it locks up? -- Comment By: Mark Poolman (mgpoolman) Date: 2005-01-26 09:15 Message: Logged In: YES user_id=993923 PS - You don't need an editor window open to get the freeze. M -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1108992&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-531205 ] Bugs in rfc822.parseaddr()
Bugs item #531205, was opened at 2002-03-18 17:13
Message generated for change (Comment added) made by anadelonbrin
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=531205&group_id=5470
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Barry A. Warsaw (bwarsaw)
Assigned to: Ben Gertzfield (che_fox)
Summary: Bugs in rfc822.parseaddr()
Initial Comment:
This bug is in rfc822.parseaddr(), and thus inherited
into email.Utils.parseaddr() since the latter does a
straight include of the former. It has a nasty bug
when the email address contains embedded spaces: it
collapses the spaces:
>>> from email.Utils import parseaddr
>>> parseaddr('foo [EMAIL PROTECTED]')
('', '[EMAIL PROTECTED]')
>>> parseaddr('')
('', '[EMAIL PROTECTED]')
Boo, hiss. Of course parseaddr() would be more
involved to implement in an RFC 2822 compliant way, but
it would be very cool.
Note that I'm reporting this bug here instead of the
mimelib project because it's actually in rfc822.py.
Once solution might include fixing it in the email
package only.
--
Comment By: Tony Meyer (anadelonbrin)
Date: 2005-01-31 12:43
Message:
Logged In: YES
user_id=552329
IMO, the current behaviour should be retained for the
reasons outlined by Tim Roberts, or extra code should be
added to strip spaces around periods and the @, and if there
are others then ('', '') should be returned. The latter is
probably more correct, but there doesn't seem to be any
pressing reason for the former.
As such, recommend closing "Won't fix". If the latter
behaviour is desired, then I could work up a patch for it.
--
Comment By: Facundo Batista (facundobatista)
Date: 2004-11-25 14:29
Message:
Logged In: YES
user_id=752496
Reassigning it as a Py2.4 bug.
--
Comment By: Paul Moore (pmoore)
Date: 2004-11-09 09:49
Message:
Logged In: YES
user_id=113328
This issue still exists in Python 2.3.4 and Python 2.4b2.
--
Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-07-23 06:30
Message:
Logged In: YES
user_id=469548
Well, the docs say "unless the parse fails, in which case a
2-tuple of ('', '') is returned". I think it's reasonable to
say that non-compliant addresses like this should fail to
parse and thus that parseaddr('foo [EMAIL PROTECTED]') should
returns ('', '')
--
Comment By: Tim Roberts (timroberts)
Date: 2002-08-13 09:40
Message:
Logged In: YES
user_id=265762
Interesting to note that RFC 822 (but not 2822) allows spaces
around any periods in the address without quoting (2822 does
allow spaces around the @), and those spaces are to be
removed. Section A.1.4 gives the example
Wilt . [EMAIL PROTECTED]
and says it should be parsed as "Wilt.Chamberlain".
Given that, it's hard for me to see that the current behavior
should be changed at all, since there is no correct way to
parse this non-compliant address.
--
Comment By: Barry A. Warsaw (bwarsaw)
Date: 2002-04-16 05:18
Message:
Logged In: YES
user_id=12800
Note further that "foo bar"@wooz.org is properly parsed.
The question is, what should parseaddr() do in this
non-compliant situation? I can think of a couple of things:
- it could raise an exception
- it could return ('', '[EMAIL PROTECTED]')
- it could return ('foo', '[EMAIL PROTECTED]')
- it could return ('' '"foo bar"@wooz.org')
I'm not sure what the right thing to do is. I'm assigning
to Ben Gertzfield to get his opinion. Ben, feel free to add
a comment and re-assign the bug to me.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=531205&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-768419 ] Subtle bug in os.path.realpath on Cygwin
Bugs item #768419, was opened at 2003-07-10 00:38
Message generated for change (Comment added) made by anadelonbrin
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768419&group_id=5470
Category: Python Library
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Erik Demaine (edemaine)
Assigned to: Nobody/Anonymous (nobody)
Summary: Subtle bug in os.path.realpath on Cygwin
Initial Comment:
Cygwin allows mounting directories within other mount
points. This can cause os.path.realpath to expand some
symlinks that it shouldn't. For example:
$ cd /
$ mkdir X
$ mkdir X/Y
$ ln -s X Z
$ mount C:/ /Z/Y
$ ls Z/Y
[...contents of C:\...]
$ ls X/Y
[empty directory]
$ python -c "import os; print os.path.realpath('Z/Y')"
/X/Y
[bad because /X/Y is empty yet the original Z/Y has files]
In Cygwin, the correct answer would be either 'C:\' or
'/cygdrive/c/'.
Conceivably this problem can happen in UNIces other
than Cygwin. It would be rather annoying to fix,
because it would require looking at the mount table.
But I thought I would mention it anyway...
--
Comment By: Tony Meyer (anadelonbrin)
Date: 2005-01-31 12:57
Message:
Logged In: YES
user_id=552329
I agree with Sjoerd - this is a Cygwin bug, not a Python one.
--
Comment By: Sjoerd Mullender (sjoerd)
Date: 2003-07-10 01:33
Message:
Logged In: YES
user_id=43607
I'd think this is rather a Cygwin bug than a Python bug.
Before the mount, /X/Y and /Z/Y refer to the same directory,
and on Unix they have the same device/inode combination.
And that combination is the all-important factor when doing
a mount on that directory.
If you do this on Unix (I used an NFS mount instead of the
mount shown in the report), both /X/Y and /Z/Y contain the
mounted directory.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768419&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-989338 ] test_unicode_file fails on win2k
Bugs item #989338, was opened at 2004-07-12 13:11 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989338&group_id=5470 Category: Python Library Group: Python 2.4 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: test_unicode_file fails on win2k Initial Comment: >>> test_support.verbose = 1 >>> test_unicode_file.test_main() test_directories (test.test_unicode_file.TestUnicodeFiles) ... ERROR test_equivalent_files (test.test_unicode_file.TestUnicodeFiles) ... ERROR test_single_files (test.test_unicode_file.TestUnicodeFiles) ... ERROR == ERROR: test_directories (test.test_unicode_file.TestUnicodeFiles) -- Traceback (most recent call last): File "C:\apps\Python24\lib\test\test_unicode_file.py", line 178, in test_directories self._do_directory(TESTFN_ENCODED+ext, TESTFN_ENCODED+ext, True) File "C:\apps\Python24\lib\test\test_unicode_file.py", line 112, in _do_directory os.mkdir(make_name) OSError: [Errno 22] Invalid argument: '@test-??.dir' == ERROR: test_equivalent_files (test.test_unicode_file.TestUnicodeFiles) -- Traceback (most recent call last): File "C:\apps\Python24\lib\test\test_unicode_file.py", line 170, in test_equivalent_files self._test_equivalent(TESTFN_ENCODED, TESTFN_UNICODE) File "C:\apps\Python24\lib\test\test_unicode_file.py", line 154, in _test_equivalent f = file(filename1, "w") IOError: [Errno 2] No such file or directory: '@test-??' == ERROR: test_single_files (test.test_unicode_file.TestUnicodeFiles) -- Traceback (most recent call last): File "C:\apps\Python24\lib\test\test_unicode_file.py", line 164, in test_single_files self._test_single(TESTFN_ENCODED) File "C:\apps\Python24\lib\test\test_unicode_file.py", line 136, in _test_single f = file(filename, "w") IOError: [Errno 2] No such file or directory: '@test-??' -- Ran 3 tests in 0.061s FAILED (errors=3) Traceback (most recent call last): File "", line 1, in -toplevel- test_unicode_file.test_main() File "C:\apps\Python24\lib\test\test_unicode_file.py", line 191, in test_main run_suite(suite) File "C:\apps\Python24\lib\test\test_support.py", line 274, in run_suite raise TestFailed(msg) TestFailed: errors occurred; run in verbose mode for details >>> This is Python2.4a1 on win2k pro -- >Comment By: Martin v. Löwis (loewis) Date: 2005-01-30 23:56 Message: Logged In: YES user_id=21627 No. A release candidate for 2.3.5 was already made; at this point, test cases should not be changed anymore. As 2.3.5 will be the last 2.3 release, backporting the change *after* 2.3.5 is pointless. -- Comment By: George Yoshida (quiver) Date: 2005-01-27 22:16 Message: Logged In: YES user_id=671362 Can anyone merge this(test_unicode_file.py rev 1.16) to release23-maint branch? This is not specific to Python 2.4. -- Comment By: Martin v. Löwis (loewis) Date: 2004-11-07 20:58 Message: Logged In: YES user_id=21627 This is now fixed in test_unicode_file.py 1.16. -- Comment By: Martin v. Löwis (loewis) Date: 2004-11-07 11:12 Message: Logged In: YES user_id=21627 I'm talking about the third tab on XP regional settings; I don't know how the user interface looks in W2k. This tab says something like "language for programs which don't support Unicode". It might be that this setting is simply not available on W2k. -- Comment By: Grzegorz Makarewicz (makaron) Date: 2004-11-03 09:23 Message: Logged In: YES user_id=115179 Martin, on other w2k pro (english) sp4 with POLISH locale set this test works as expected - "All the Unicode tests appeared to work". Both versions have the same settings for regional options - polish: On first tab (general) I have Polish location and other languages on the same tab selected: western europe and US, central europe. On last tab (6 = input locales) I have polish programmers and endglish (US). Third tab - currency ? Or this test fails on non english versions of W2K ? German ? Hungarian ? ... -- Commen
[ python-Bugs-803413 ] uu.decode prints to stderr
Bugs item #803413, was opened at 2003-09-10 08:31 Message generated for change (Comment added) made by anadelonbrin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=803413&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Sami Hangaslammi (shang) Assigned to: Nobody/Anonymous (nobody) Summary: uu.decode prints to stderr Initial Comment: Python 2.3 final The standard library function uu.decode prints a warning message to stderr if there is an error when decoding the file. This feels like an incorrect behaviour for a library function. The warning message can be supressed by providing a quiet=True parameter, but this is not currently documented. The relevant line in uu.py is 138 -- Comment By: Tony Meyer (anadelonbrin) Date: 2005-01-31 13:15 Message: Logged In: YES user_id=552329 Printing to stderr outside of debugging is uncommon for the standard library, but there are other modules (ftplib, asyncore) that do it. In this case, it only happens when there is an error (which can be recovered from), so printing to stderr seems fairly appropriate. An alternative would be to call warnings.warn(), although by default that will have the same effect. Documenting the 'quiet' parameter seems reasonable, however, and would be a simple change to libuu.tex. I can produce such a patch, if desired. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=803413&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-989333 ] Empty curses module is loaded in win32
Bugs item #989333, was opened at 2004-07-12 23:00 Message generated for change (Comment added) made by anadelonbrin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989333&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: Empty curses module is loaded in win32 Initial Comment: When doing "import curses" an empty curses module is loaded. I think that since curses is not supported in win32 that an ImportError should be raised (like in 2.3) -- Comment By: Tony Meyer (anadelonbrin) Date: 2005-01-31 13:25 Message: Logged In: YES user_id=552329 I do not get this behaviour (I get the expected ImportError): C:\>c:\python22\python Python 2.2.3 (#42, May 30 2003, 18:12:08) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import curses Traceback (most recent call last): File "", line 1, in ? ImportError: No module named curses C:\>c:\python23\python Python 2.3.4 (#53, May 25 2004, 21:17:02) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import curses Traceback (most recent call last): File "", line 1, in ? ImportError: No module named curses C:\>c:\python24\python Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import curses Traceback (most recent call last): File "", line 1, in ? File "c:\python24\lib\curses\__init__.py", line 15, in ? from _curses import * ImportError: No module named _curses What version of Python is this with? Do you possibly have a curses.pyc that shouldn't be there? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989333&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1090076 ] Defaults in ConfigParser.get overrides section values
Bugs item #1090076, was opened at 2004-12-23 11:23
Message generated for change (Comment added) made by anadelonbrin
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1090076&group_id=5470
Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Gabriel Genellina (gagenellina)
Assigned to: Nobody/Anonymous (nobody)
Summary: Defaults in ConfigParser.get overrides section values
Initial Comment:
ConfigParser.get has an optional argument vars that -
according to the docstring- "which must be a dictionary
whose contents overrides any pre-existing defaults."
I understand that it overrides the default values, but
should not override an actual value existing in the file.
That is, given this contents:
[DEFAULT]
key1=default1
[section]
key2=value2
vars={'key1:vars1','key2:vars2'}
cfg.get('section','key1',0,vars) gives 'vars1' (ok)
cfg.get('section','key2',0,vars) gives 'vars2' (wrong,
should be 'value2', since key2 is actually in the section
and no default is needed).
To correct this behavior, simply move this two lines of
code up in ConfigParser.get (ConfigParser.py), just below
the first line and before the first try/except:
# Update with the entry specific variables
if vars is not None:
d.update(vars)
--
Comment By: Tony Meyer (anadelonbrin)
Date: 2005-01-31 13:42
Message:
Logged In: YES
user_id=552329
This is indeed what happens. However, changing this could
break existing code, so an alternative fix would be to
change the documentation to "overrides any pre-existing
values.". I am not sure what the desired behaviour is - if
it is what is current, then recommend updating the
documentation. If the desired behaviour is what the
documentation currently says, then recommend applying the
above patch (although the code is not exactly the same
anymore, the effect is).
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1090076&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1112856 ] patch 1079734 broke cgi.FieldStorage w/ multipart post req.
Bugs item #1112856, was opened at 2005-01-31 01:58
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=1112856&group_id=5470
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Irmen de Jong (irmen)
Assigned to: Nobody/Anonymous (nobody)
Summary: patch 1079734 broke cgi.FieldStorage w/ multipart post req.
Initial Comment:
Patch 1079734 "Make cgi.py use email instead of rfc822
or mimetools" seems to have broken the cgi.FieldStorage
in cases where the request is a multipart post (for
instance, when a file upload form field is used).
See the attached test program.
With cgi.py revision <1.83 (python 2.4 for instance) I
get the expected results;
374
FieldStorage(None, None, [FieldStorage('param1', None,
'Value of param1'), FieldStorage('param2', None, 'Value
of param2'), FieldStorage('file', '', ''),
FieldStorage(None, None, '')])
but with cgi.py rev 1.83 (current) I get this:
374
FieldStorage(None, None, [FieldStorage('param1', None,
'')])
Another thing that I observed (which isn't reproduced
by this test program) is that cgi.FieldStorage.__init__
never completes when the fp is a socket-file (and the
request is again a multipart post). It worked fine with
the old cgi.py.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112856&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-783887 ] Tab / Space Configuration Does Not Work in IDLE
Bugs item #783887, was opened at 2003-08-05 22:00
Message generated for change (Comment added) made by kbk
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=783887&group_id=5470
Category: IDLE
>Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 3
Submitted By: Andy Huibers (ahuibers)
Assigned to: Kurt B. Kaiser (kbk)
Summary: Tab / Space Configuration Does Not Work in IDLE
Initial Comment:
On Python 2.3/IDLE 1.0, when I go from the editor to:
Options->Configure Idle->Font/Tabs
And set it to "Tab key inserts tabs" what actually
happens is that the tab key inserts spaces (4 spaces).
--
>Comment By: Kurt B. Kaiser (kbk)
Date: 2005-01-30 22:46
Message:
Logged In: YES
user_id=149084
Removed Tab indentation selection from the Options
dialog. Not appropriate for IDLE. Tab indentation default
may still be configured 'manually' by modifying
config-main.def but that's for experts. You can switch on
tabs for individual Edit windows using the Format menu.
(Note: the Tab indent option was never finished and
never operable)
Changing the 'screen' indent width in the Options menu
will now be effective if you aren't using tabs (it's always
8 if you are using tabs).
Thanks for the patch and the reminder.
--
Comment By: Nanjundi (nanjundi)
Date: 2005-01-17 15:07
Message:
Logged In: YES
user_id=1199110
I got the error. I am using Python 2.3.4.
Hitting TAB in the editor advances the cursor by "4" spaces
irrespective of the "indent width" in Configure idle...->
Fonts/Tab -> choose indentation size:
I did a quick and dirty fix.
I had to modify the Line# 915 in file Python23/Lib/idlelib/EditorWindow.py
Requires restart of IDLE for the change to take effect.
[Before]
indentwidth = 3
[After]
indentwidth =
idleConf.GetOption('main','Indent','num-spaces',
default=4,type='int')
--
Comment By: Kurt B. Kaiser (kbk)
Date: 2003-09-05 18:26
Message:
Logged In: YES
user_id=149084
I can reproduce this on XP and Linux.
Of course, everyone should use 4 spaces :)
--
Comment By: Andy Huibers (ahuibers)
Date: 2003-08-06 14:09
Message:
Logged In: YES
user_id=838612
Mmm.. I re-installed the Windows Python-2.3 installer EXE on
a fresh PC and I have the problem, even when I hit "Apply"
and "OK".
It is not a big deal of course, but would be nice if it worked..
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2003-08-06 00:17
Message:
Logged In: YES
user_id=80475
I cannot reproduce the problem.
This may be a silly question, but did you click Apply after
changing the setting?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=783887&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1112949 ] ioctl has problems on 64 bit machines
Bugs item #1112949, was opened at 2005-01-31 15:55 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=1112949&group_id=5470 Category: Python Library Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Stephen Norris (stephennorris) Assigned to: Nobody/Anonymous (nobody) Summary: ioctl has problems on 64 bit machines Initial Comment: fcntly.ioctl takes an int as the second argument. If the value passed is a large 32 bit quantity (0x80046601 for example - EXT2_IOC_GETFLAGS) then I get: Traceback (most recent call last): File "CommSecure-CVS/Operations/checkSpace.py", line 73, in ? main(sys.argv[1:]) File "CommSecure-CVS/Operations/checkSpace.py", line 25, in main os.path.walk(file, doDirectory, total) File "/usr/lib64/python2.3/posixpath.py", line 282, in walk func(arg, top, names) File "CommSecure-CVS/Operations/checkSpace.py", line 61, in doDirectory flags = fcntl.ioctl(fd, EXT3_IOC_GETFLAGS, "") OverflowError: signed integer is greater than maximum My _guess_ here is that the code is checking against 32 bit quantities rather than 64 bit when converting to the C data type? Platform is Linux, Fedora Core 3 on AMD Opteron. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112949&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1112955 ] move_file()'s return value when dry_run=1 unclear
Bugs item #1112955, was opened at 2005-01-31 06:18
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=1112955&group_id=5470
Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Eelis (eelis)
Assigned to: Nobody/Anonymous (nobody)
Summary: move_file()'s return value when dry_run=1 unclear
Initial Comment:
distutils.file_util.move_file has the following signature:
move_file(src, dst, verbose=0, dry_run=0)
Unfortunately, the purpose of the dry_run parameter is
not described in the documentation. However, it's
obvious that one effect of specifying dry_run=1 should
be that the file is not actually moved. Less obvious is
how dry_run=1 affects move_file's return value, which
the documentation describes as follows:
"Returns the new full name of the file."
Should the dry_run parameter be allowed to affect the
return value? My guess is that it shouldn't, but it
does (on win32 and linux):
# given a file named foo and a directory named bar
move_file('foo', 'bar', 0, 1) #-> 'bar'
move_file('foo', 'bar', 0, 0) #-> 'bar/foo'
A quick look at the source code showed that:
if isdir(dst):
dst = os.path.join(dst, basename(src))
is executed _before_:
if dry_run:
return dst
which causes the discrepancy.
Is this a bug, or should the return value of move_file
when dry_run=1 be considered unreliable? If the latter
is the case, perhaps it should be documented explicitly.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112955&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1108992 ] idle freezes when run over ssh
Bugs item #1108992, was opened at 2005-01-25 05:44 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1108992&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Mark Poolman (mgpoolman) Assigned to: Nobody/Anonymous (nobody) Summary: idle freezes when run over ssh Initial Comment: Python 2.3.4 (#2, Aug 13 2004, 00:36:58) [GCC 3.3.4 (Debian 1:3.3.4-5ubuntu2)] on linux2 IDLE 1.0.3 When running idle over an ssh link, idle freezes after an unpredictable length of time. Over 3 days the longest it has stayed allive for is ~4hrs, but a few minutes before freezing is the norm. Niether idle nor python are consuming cpu time once frozen. I can find no definete recipie to bring about the freeze, although (I think) there has always been at least one editor window open when it happens. There is no output on stderr, or other diagnostics that I can see. ssh server(ubuntu warty): OpenSSH_3.8.1p1 Debian 1:3.8.1p1-11ubuntu3.1, OpenSSL 0.9.7d 17 Mar 2004 ssh client (RH9): OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090701f /best/* Mark -- >Comment By: Kurt B. Kaiser (kbk) Date: 2005-01-31 01:26 Message: Logged In: YES user_id=149084 Please try two things: 1. Run IDLE directly on the ubuntu machine long enough to assure there is no problem standalone. 2. Run IDLE on the xclient but start it with the -n switch so it runs without the subprocess. When IDLE freezes, walk over to the server and kill the subprocess. It should restart itself. Is the system still frozen? And by frozen, I assume you mean all screen and keyboard events are unresponsive. -- Comment By: Mark Poolman (mgpoolman) Date: 2005-01-30 15:06 Message: Logged In: YES user_id=993923 Yes, I've used Idle on that (although only ~ 1 hour) and not seen the problem there. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-01-30 14:43 Message: Logged In: YES user_id=341410 Do you have physical access to the ubuntu warty machine, and if so, does Idle run very well locally on that machine, not X forwarded? -- Comment By: Mark Poolman (mgpoolman) Date: 2005-01-30 12:02 Message: Logged In: YES user_id=993923 Yes, exactly. I'm pretty sure it's not an X/ssh/network problem, everything else works fine (including Idle 0.8). Mark -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-01-29 15:23 Message: Logged In: YES user_id=341410 It has been a while since I ran Idle, but I am curious as to what you mean by "run over ssh". Do you mean that you have an SSH tunnel to a remote machine, which forwards X-Windows sessions, and when running Idle over this, it locks up? -- Comment By: Mark Poolman (mgpoolman) Date: 2005-01-26 04:15 Message: Logged In: YES user_id=993923 PS - You don't need an editor window open to get the freeze. M -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1108992&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-989333 ] Empty curses module is loaded in win32
Bugs item #989333, was opened at 2004-07-12 14:00 Message generated for change (Comment added) made by tebeka You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989333&group_id=5470 Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: Empty curses module is loaded in win32 Initial Comment: When doing "import curses" an empty curses module is loaded. I think that since curses is not supported in win32 that an ImportError should be raised (like in 2.3) -- >Comment By: Miki Tebeka (tebeka) Date: 2005-01-31 09:13 Message: Logged In: YES user_id=358087 Currently I have 2.4 installed and I also get an ImportError. Looks likes something went wrong with my 2.3 installation. Closing the bug. -- Comment By: Tony Meyer (anadelonbrin) Date: 2005-01-31 02:25 Message: Logged In: YES user_id=552329 I do not get this behaviour (I get the expected ImportError): C:\>c:\python22\python Python 2.2.3 (#42, May 30 2003, 18:12:08) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import curses Traceback (most recent call last): File "", line 1, in ? ImportError: No module named curses C:\>c:\python23\python Python 2.3.4 (#53, May 25 2004, 21:17:02) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import curses Traceback (most recent call last): File "", line 1, in ? ImportError: No module named curses C:\>c:\python24\python Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import curses Traceback (most recent call last): File "", line 1, in ? File "c:\python24\lib\curses\__init__.py", line 15, in ? from _curses import * ImportError: No module named _curses What version of Python is this with? Do you possibly have a curses.pyc that shouldn't be there? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989333&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
