[ python-Bugs-1180147 ] test_posix fails on cygwin
Bugs item #1180147, was opened at 2005-04-10 13: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=1180147&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Henrik Wist (wist) Assigned to: Nobody/Anonymous (nobody) Summary: test_posix fails on cygwin Initial Comment: $ python test/test_posix.py testNoArgFunctions (__main__.PosixTester) ... ERROR test_access (__main__.PosixTester) ... ok test_chdir (__main__.PosixTester) ... ok test_dup (__main__.PosixTester) ... ok test_dup2 (__main__.PosixTester) ... ok test_fdopen (__main__.PosixTester) ... ok test_fstat (__main__.PosixTester) ... ok test_fstatvfs (__main__.PosixTester) ... ok test_ftruncate (__main__.PosixTester) ... ok test_lsdir (__main__.PosixTester) ... ok test_pipe (__main__.PosixTester) ... ok test_stat (__main__.PosixTester) ... ok test_statvfs (__main__.PosixTester) ... ok test_strerror (__main__.PosixTester) ... ok test_tempnam (__main__.PosixTester) ... ok test_tmpfile (__main__.PosixTester) ... ok test_umask (__main__.PosixTester) ... ok test_utime (__main__.PosixTester) ... ok == ERROR: testNoArgFunctions (__main__.PosixTester) -- Traceback (most recent call last): File "test/test_posix.py", line 40, in testNoArgFunctions posix_func() OSError: [Errno 22] Invalid argument -- Ran 18 tests in 0.038s FAILED (errors=1) Traceback (most recent call last): File "test/test_posix.py", line 159, in ? test_main() File "test/test_posix.py", line 156, in test_main test_support.run_unittest(PosixTester) File "/usr/lib/python2.3/test/test_support.py", line 262, in run_unittest run_suite(suite, testclass) File "/usr/lib/python2.3/test/test_support.py", line 247, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "test/test_posix.py", line 40, in testNoArgFunctions posix_func() OSError: [Errno 22] Invalid argument This is with cygwin 1.5.12-1 and python 2.3.4-2. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1180147&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1180147 ] test_posix fails on cygwin
Bugs item #1180147, was opened at 2005-04-10 13:10 Message generated for change (Comment added) made by wist You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1180147&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Henrik Wist (wist) Assigned to: Nobody/Anonymous (nobody) Summary: test_posix fails on cygwin Initial Comment: $ python test/test_posix.py testNoArgFunctions (__main__.PosixTester) ... ERROR test_access (__main__.PosixTester) ... ok test_chdir (__main__.PosixTester) ... ok test_dup (__main__.PosixTester) ... ok test_dup2 (__main__.PosixTester) ... ok test_fdopen (__main__.PosixTester) ... ok test_fstat (__main__.PosixTester) ... ok test_fstatvfs (__main__.PosixTester) ... ok test_ftruncate (__main__.PosixTester) ... ok test_lsdir (__main__.PosixTester) ... ok test_pipe (__main__.PosixTester) ... ok test_stat (__main__.PosixTester) ... ok test_statvfs (__main__.PosixTester) ... ok test_strerror (__main__.PosixTester) ... ok test_tempnam (__main__.PosixTester) ... ok test_tmpfile (__main__.PosixTester) ... ok test_umask (__main__.PosixTester) ... ok test_utime (__main__.PosixTester) ... ok == ERROR: testNoArgFunctions (__main__.PosixTester) -- Traceback (most recent call last): File "test/test_posix.py", line 40, in testNoArgFunctions posix_func() OSError: [Errno 22] Invalid argument -- Ran 18 tests in 0.038s FAILED (errors=1) Traceback (most recent call last): File "test/test_posix.py", line 159, in ? test_main() File "test/test_posix.py", line 156, in test_main test_support.run_unittest(PosixTester) File "/usr/lib/python2.3/test/test_support.py", line 262, in run_unittest run_suite(suite, testclass) File "/usr/lib/python2.3/test/test_support.py", line 247, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "test/test_posix.py", line 40, in testNoArgFunctions posix_func() OSError: [Errno 22] Invalid argument This is with cygwin 1.5.12-1 and python 2.3.4-2. -- >Comment By: Henrik Wist (wist) Date: 2005-04-10 13:12 Message: Logged In: YES user_id=1256464 And, I forgot, this is with WinXP SP2 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1180147&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1180160 ] subprocess.Popen fails with closed stdout
Bugs item #1180160, was opened at 2005-04-10 13:41 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=1180160&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: neuhauser (neuhauser) Assigned to: Nobody/Anonymous (nobody) Summary: subprocess.Popen fails with closed stdout Initial Comment: I have a piece of code that gets run in a script that has its stdout closed: import sys sys.stdout = sys.stderr c = subprocess.Popen (..., stdin = subprocess.PIPE, stdout = subprocess.PIPE, stderr = subprocess.STDOUT) and this is what I get: SendingSVNR/permissions Transmitting file data .svn: Commit failed (details follow): svn: 'pre-commit' hook failed with error output: Traceback (most recent call last): (...) File ".../__init__.py", line 40, in run stderr = subprocess.STDOUT) File "/usr/local/lib/python2.4/subprocess.py", line 554, in __init__ errread, errwrite) File "/usr/local/lib/python2.4/subprocess.py", line 986, in _execute_child raise child_exception OSError: [Errno 2] No such file or directory This is the child_traceback: File "/usr/local/lib/python2.4/subprocess.py", line 955, in _execute_child File "/usr/local/lib/python2.4/os.py", line 341, in execvp File "/usr/local/lib/python2.4/os.py", line 379, in _execvpe func(fullname, *argrest) OSError: [Errno 2] No such file or directory http://docs.python.org/lib/node230.html claims that "PIPE indicates that a new pipe to the child should be created" which doesn't seem to be the case. Subversion code that runs the script can be seen at http://svn.collab.net/viewcvs/svn/trunk/subversion/libsvn_repos/hooks.c (run_hook_cmd()). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1180160&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1180193 ] broken pyc files
Bugs item #1180193, was opened at 2005-04-10 13: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=1180193&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: broken pyc files Initial Comment: In a number of situations, the .pyc files can become "corrupted" in a subtle way: the co_filename attribute of the code objects it contains become wrong. This can occur if we move or rename directories, or if we access the same set of files from two different locations (e.g. over NFS). This corruption doesn't prevent the .pyc files from working, but the interpreter looses the reference to the source file. It causes trouble in tracebacks, in the inspect module, etc. A simple fix would be to use the following logic when importing a .py file: if there is a corresponding .pyc file, in addition to checking the timestamp, check the co_filename attribute of the loaded object. If it doesn't point to the original .py file, discard the code object and ignore the .pyc file. Alternatively, we could force all co_filenames to point to the .py file when loading the .pyc file. I'll write a patch for whichever alternative seems better. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1180193&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1180002 ] locale.format question
Bugs item #1180002, was opened at 2005-04-10 01:28
Message generated for change (Comment added) made by andrewma
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1180002&group_id=5470
Category: Python Library
Group: Python 2.4
>Status: Closed
>Resolution: Remind
Priority: 5
Submitted By: Andrew Ma (andrewma)
Assigned to: Nobody/Anonymous (nobody)
Summary: locale.format question
Initial Comment:
locale.format is returning send("234,5") rather than send
("2,345") as I was expecting. Is this a bug?
The example is modified from the Tutorial 11.1 Output
Formatting
--
Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more
information.
>>> import locale
>>> locale.setlocale(locale.LC_ALL, 'English_United
States.1252')
'English_United States.1252'
>>> data=2345
>>> locale.format('send("%d")', data, grouping = True)
'send("234,5")'
>>> locale.format('%d', data, grouping = True)
'2,345'
>>>
--
>Comment By: Andrew Ma (andrewma)
Date: 2005-04-10 14:55
Message:
Logged In: YES
user_id=621709
Berk,
I followed your advice using
'send("%s")' % locale.format("%d", data, grouping=True)
and solved my problem. Too bad there is no way to add your
advice to the Python documentation. I am putting the status
to remind, in case anybody (including me) wants to fix this
later.
Thanks.
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-04-10 05:51
Message:
Logged In: YES
user_id=1188172
locale.format is implemented very "pragmatic". For example,
you can't do
locale.format('"1.%d."', 123)
("too many decimal points") though this should be supported.
This is because it first formats the string with the normal
"%" operation and then searches the whole string for decimal
points to substitute.
IMHO, format should first separate the % escapes from the
format string, then format the numbers accordingly, and then
use the % operation.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1180002&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1180237 ] Python keeps file references after calling close methode
Bugs item #1180237, was opened at 2005-04-10 17:20
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=1180237&group_id=5470
Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Eelco (eternia)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python keeps file references after calling close methode
Initial Comment:
I found this bug using a python script that:
- first mounts a partition (os.system("mount") etc)
- change a few files on this partition (f = open ();
f.write; f.close)
- umounts the partition (os.system("umount") etc)
Strangely, the umount didn't work because of a
filesystem busy error. Using fuser and lsof i traced
this being busy back to the script itself. This is
strange behavior because after changing the files on
the mounted partition the close method was called which
should close all references to the file on the partition.
Finally the solution was to do f = 0. So if python has
closed a file on a mount a open reference to that file
will keep to exist until the script has ended or until
the file object is nullified.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1180237&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1180267 ] expanding platform module and making it work as it should
Bugs item #1180267, was opened at 2005-04-10 19:44
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=1180267&group_id=5470
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nikos Kouremenos (nkour)
Assigned to: Nobody/Anonymous (nobody)
Summary: expanding platform module and making it work as it should
Initial Comment:
platform.release() (which is supposed to return the
Name of Windows) also does not work as it should in
some versions of windows I tried (xp pro sp1). Luckily
to print more than Windows (eg. print Windows XP or
Windows 2000 etc) you can have a look at this
http://www.brunningonline.net/simon/blog/archives/001168.html
of Simon Brunning
also only debian, mdk and redhat is scanned for
GNU/Linux ?? why even bother then?
I think that PSL is good but this module is has hell of
limitations. At least dont' make anyone write this:
import os
distro_info = {
'Arch Linux': '/etc/arch-release', 'Aurox Linux': '/etc/aurox-release',
'Conectiva Linux': '/etc/conectiva-release', 'Debian GNU/Linux':
'/etc/debian_release', 'Debian GNU/Linux': '/etc/debian_version', 'Fedora
Linux': '/etc/fedora-release', 'Gentoo Linux': '/etc/gentoo-release',
'Mandrake Linux': '/etc/mandrake-release', 'Slackware Linux':
'/etc/slackware-release', 'Slackware Linux': '/etc/slackware-version',
'Solaris/Sparc': '/etc/release', 'Sun JDS': '/etc/sun-release', 'Novell SUSE
Linux': '/etc/SuSE-release', 'PLD Linux': '/etc/pld-release', 'SUSE Linux':
'/etc/SuSE-release', 'Yellow Dog Linux': '/etc/yellowdog-release', # many
distros use the /etc/redhat-release for
compatibility
# so Redhat is the last
'Redhat Linux': '/etc/redhat-release'}
def get_os_info():
if os.name =='nt':
win_version = {
(1, 4, 0): "95",(1, 4, 10):
"98", (1, 4, 90): "ME", (2, 4, 0):
"NT",(2, 5, 0): "2000", (2, 5, 1):
"XP"
}[os.sys.getwindowsversion()[3],
os.sys.getwindowsversion()[0],
os.sys.getwindowsversion()[1]]
return 'Windows' + ' ' + win_version
elif os.name =='posix':
executable = 'lsb_release'
params = ' --id --codename --release --short'
for path in os.environ['PATH'].split(':'):
full_path_to_executable = os.path.join(path,
executable)
if os.path.exists(full_path_to_executable):
command = executable + params
child_stdin, child_stdout = os.popen2(command)
output = child_stdout.readline().strip()
child_stdout.close()
child_stdin.close()
return output
# lsb_release executable not available, so parse files
for distro in distro_info:
path_to_file = distro_info[distro]
if os.path.exists(path_to_file):
file = open(path_to_file)
text = file.read().strip()
file.close()
if path_to_file.endswith('version'):
text = distro + ' ' + text
return text
print get_os_info()
Thank you
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1180267&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1180267 ] expanding platform module and making it work as it should
Bugs item #1180267, was opened at 2005-04-10 19:44
Message generated for change (Comment added) made by nkour
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1180267&group_id=5470
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nikos Kouremenos (nkour)
Assigned to: Nobody/Anonymous (nobody)
Summary: expanding platform module and making it work as it should
Initial Comment:
platform.release() (which is supposed to return the
Name of Windows) also does not work as it should in
some versions of windows I tried (xp pro sp1). Luckily
to print more than Windows (eg. print Windows XP or
Windows 2000 etc) you can have a look at this
http://www.brunningonline.net/simon/blog/archives/001168.html
of Simon Brunning
also only debian, mdk and redhat is scanned for
GNU/Linux ?? why even bother then?
I think that PSL is good but this module is has hell of
limitations. At least dont' make anyone write this:
import os
distro_info = {
'Arch Linux': '/etc/arch-release', 'Aurox Linux': '/etc/aurox-release',
'Conectiva Linux': '/etc/conectiva-release', 'Debian GNU/Linux':
'/etc/debian_release', 'Debian GNU/Linux': '/etc/debian_version', 'Fedora
Linux': '/etc/fedora-release', 'Gentoo Linux': '/etc/gentoo-release',
'Mandrake Linux': '/etc/mandrake-release', 'Slackware Linux':
'/etc/slackware-release', 'Slackware Linux': '/etc/slackware-version',
'Solaris/Sparc': '/etc/release', 'Sun JDS': '/etc/sun-release', 'Novell SUSE
Linux': '/etc/SuSE-release', 'PLD Linux': '/etc/pld-release', 'SUSE Linux':
'/etc/SuSE-release', 'Yellow Dog Linux': '/etc/yellowdog-release', # many
distros use the /etc/redhat-release for
compatibility
# so Redhat is the last
'Redhat Linux': '/etc/redhat-release'}
def get_os_info():
if os.name =='nt':
win_version = {
(1, 4, 0): "95",(1, 4, 10):
"98", (1, 4, 90): "ME", (2, 4, 0):
"NT",(2, 5, 0): "2000", (2, 5, 1):
"XP"
}[os.sys.getwindowsversion()[3],
os.sys.getwindowsversion()[0],
os.sys.getwindowsversion()[1]]
return 'Windows' + ' ' + win_version
elif os.name =='posix':
executable = 'lsb_release'
params = ' --id --codename --release --short'
for path in os.environ['PATH'].split(':'):
full_path_to_executable = os.path.join(path,
executable)
if os.path.exists(full_path_to_executable):
command = executable + params
child_stdin, child_stdout = os.popen2(command)
output = child_stdout.readline().strip()
child_stdout.close()
child_stdin.close()
return output
# lsb_release executable not available, so parse files
for distro in distro_info:
path_to_file = distro_info[distro]
if os.path.exists(path_to_file):
file = open(path_to_file)
text = file.read().strip()
file.close()
if path_to_file.endswith('version'):
text = distro + ' ' + text
return text
print get_os_info()
Thank you
--
>Comment By: Nikos Kouremenos (nkour)
Date: 2005-04-10 19:46
Message:
Logged In: YES
user_id=865368
identation went to take a walk :(
I'm sorry
look here:
http://nkour.blogspot.com/2005/03/python-script-to-detect-gnulinux.html
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1180267&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1179957 ] Missing def'n of equality for set elements
Bugs item #1179957, was opened at 2005-04-09 17:10 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1179957&group_id=5470 Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: Missing def'n of equality for set elements Initial Comment: The documentation of the sets module doesn't describe the properties of set elements that they must have to properly work in sets (at least I didn't see it described). In creating a set of instances, I had to sort of stumble around and discover that the class needed to define both __eq__ and __hash__. Either alone didn't seem to work. Perhaps I've got it all wrong and there's a better way to do things. It would be nice if the docs described things officially though. -- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-10 12:20 Message: Logged In: YES user_id=80475 It does say that sets are implemented using dictionaries. That implies that the requirements for set elements are the same as for dictionary keys. Will see if I can add some clarifying wording. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1179957&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1179957 ] Missing def'n of equality for set elements
Bugs item #1179957, was opened at 2005-04-09 17:10 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1179957&group_id=5470 Category: Documentation Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: Missing def'n of equality for set elements Initial Comment: The documentation of the sets module doesn't describe the properties of set elements that they must have to properly work in sets (at least I didn't see it described). In creating a set of instances, I had to sort of stumble around and discover that the class needed to define both __eq__ and __hash__. Either alone didn't seem to work. Perhaps I've got it all wrong and there's a better way to do things. It would be nice if the docs described things officially though. -- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-10 12:30 Message: Logged In: YES user_id=80475 Updated both libstdtypes.tex and libsets.tex with explicit documentation for element requirements. -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-10 12:20 Message: Logged In: YES user_id=80475 It does say that sets are implemented using dictionaries. That implies that the requirements for set elements are the same as for dictionary keys. Will see if I can add some clarifying wording. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1179957&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1180392 ] StringIO's docs should mention overwriting of initial value
Bugs item #1180392, was opened at 2005-04-10 17: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=1180392&group_id=5470 Category: Documentation Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Leif K-Brooks (eurleif) Assigned to: Nobody/Anonymous (nobody) Summary: StringIO's docs should mention overwriting of initial value Initial Comment: StringIO's initial file position is always set to 0, rather than being set to the length of the initial text. This isn't mentioned in the documentation, which could cause confusion. I've attached some text the docs could use. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1180392&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1180392 ] StringIO's docs should mention overwriting of initial value/
Bugs item #1180392, was opened at 2005-04-10 17:55 Message generated for change (Settings changed) made by eurleif You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1180392&group_id=5470 Category: Documentation Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Leif K-Brooks (eurleif) Assigned to: Nobody/Anonymous (nobody) >Summary: StringIO's docs should mention overwriting of initial value/ Initial Comment: StringIO's initial file position is always set to 0, rather than being set to the length of the initial text. This isn't mentioned in the documentation, which could cause confusion. I've attached some text the docs could use. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1180392&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1180392 ] StringIO's docs should mention overwriting of initial value/
Bugs item #1180392, was opened at 2005-04-10 17:55 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1180392&group_id=5470 Category: Documentation Group: Feature Request >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Leif K-Brooks (eurleif) Assigned to: Nobody/Anonymous (nobody) Summary: StringIO's docs should mention overwriting of initial value/ Initial Comment: StringIO's initial file position is always set to 0, rather than being set to the length of the initial text. This isn't mentioned in the documentation, which could cause confusion. I've attached some text the docs could use. -- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-10 20:04 Message: Logged In: YES user_id=80475 Okay, I added an explicit comment that the initial file position is zero even when the object has been initialized with a string. FWIW, I recommend not using initialization when also using a write method. That will not allow a seemless conversion to cStringIO where intialized objects are read-only. A more scalable technique is to create an empty object and then call write() to initialize it. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1180392&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1180470 ] BaseHTTPServer uses deprecated mimetools.Message
Bugs item #1180470, was opened at 2005-04-11 04:26 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=1180470&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Paul Jimenez (paulj) Assigned to: Nobody/Anonymous (nobody) Summary: BaseHTTPServer uses deprecated mimetools.Message Initial Comment: BaseHTTPServer used a deprecated (as of 2.3) class: mimetools.Message. cgi.py also uses it, but that's getting fixed. If only there was just a single API for writing webapps. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1180470&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
