[ python-Bugs-947894 ] calendar.weekheader() undocumented
Bugs item #947894, was opened at 2004-05-04 20:20 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=947894&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Leonardo Rochael Almeida (rochael) Assigned to: Walter Dörwald (doerwalter) Summary: calendar.weekheader() undocumented Initial Comment: http://www.python.org/doc/current/lib/module-calendar.html makes no mention of calendar.weekheader() -- >Comment By: Walter Dörwald (doerwalter) Date: 2004-12-06 09:14 Message: Logged In: YES user_id=89016 Checked in as: Doc/lib/libcalendar.tex 1.19 Doc/lib/libcalendar.tex 1.18.4.1 -- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2004-12-04 05:55 Message: Logged In: YES user_id=3066 The patch looks good to me. Walter, can you commit on the trunk and the release24-maint branch? -- Comment By: Walter Dörwald (doerwalter) Date: 2004-06-02 20:53 Message: Logged In: YES user_id=89016 How about the following patch? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=947894&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1071513 ] test_sutil fails on cygwin
Bugs item #1071513, was opened at 2004-11-23 09:29
Message generated for change (Comment added) made by jlgijsbers
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1071513&group_id=5470
Category: Python Library
Group: Python 2.4
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Miki Tebeka (tebeka)
Assigned to: Johannes Gijsbers (jlgijsbers)
Summary: test_sutil fails on cygwin
Initial Comment:
[10:23] $python -V
Python 2.4c1
[10:25] $python -c 'from test.test_shutil import
test_main; test_main()' -v
test_dont_copy_file_onto_link_to_itself
(test.test_shutil.TestShutil) ... ok
test_dont_move_dir_in_itself
(test.test_shutil.TestShutil) ... ok
test_on_error (test.test_shutil.TestShutil) ... ERROR
test_rmtree_dont_delete_file
(test.test_shutil.TestShutil) ... ok
test_rmtree_errors (test.test_shutil.TestShutil) ... ok
==
ERROR: test_on_error (test.test_shutil.TestShutil)
--
Traceback (most recent call last):
File "/usr/lib/python2.4/test/test_shutil.py", line
34, in test_on_error
os.chmod(TESTFN, old_dir_mode)
OSError: [Errno 2] No such file or directory: '@test'
--
Ran 5 tests in 0.036s
FAILED (errors=1)
Traceback (most recent call last):
File "", line 1, in ?
File "/usr/lib/python2.4/test/test_shutil.py", line
99, in test_main
test_support.run_unittest(TestShutil)
File "/usr/lib/python2.4/test/test_support.py", line
290, in run_unittest
run_suite(suite, testclass)
File "/usr/lib/python2.4/test/test_support.py", line
275, in run_suite
raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent
call last):
File "/usr/lib/python2.4/test/test_shutil.py", line
34, in test_on_error
os.chmod(TESTFN, old_dir_mode)
OSError: [Errno 2] No such file or directory: '@test'
--
>Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-12-06 21:53
Message:
Logged In: YES
user_id=469548
Closing this. I've added a comment to the source pointing to
here.
--
Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-11-23 11:04
Message:
Logged In: YES
user_id=469548
Hmm, strange. I should perhaps have provided the link that I
based this on: http://www.cygwin.com/faq/faq_3.html#SEC41.
The thing is, the test needs a permissions error so it can
check shutil.rmtree's error handling. Setting the
permissions for the directory to stat.S_IREAD (0400) doesn't
seem to prevent Python from removing the file. I don't know
enough about the intricacies of Cygwin+chmod (I don't have a
Windows machine) to make this work reliably, but I'll be
happy to take another patch.
Note, by the way, that this is not a problem with shutil
itself, but just with the test.
--
Comment By: Miki Tebeka (tebeka)
Date: 2004-11-23 10:41
Message:
Logged In: YES
user_id=358087
I disagree, chmod seems to work:
[11:35] - adp96: touch zzz
[11:35] - adp96: ll zzz
-rw-rw-rw-1 mikitDomain U0 Nov 23 11:35 zzz
[11:35] - adp96: python -c 'from os import chmod;
chmod("zzz", 0700)'
[11:36] - adp96: ll zzz
-rwx--1 mikitDomain U0 Nov 23 11:35 zzz
--
Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-11-23 10:29
Message:
Logged In: YES
user_id=469548
Ah, seems like chmod doesn't work on Cygwin. That means
there's no way to run this test there, so I've changed it so
that it doesn't run on Cygwin anymore.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1071513&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1076467 ] test_shutil fails on x86-64 // Suse 9.1
Bugs item #1076467, was opened at 2004-12-01 03:45 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076467&group_id=5470 Category: Installation Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Ross G Baker Jr (rossgbaker2) >Assigned to: Johannes Gijsbers (jlgijsbers) Summary: test_shutil fails on x86-64 // Suse 9.1 Initial Comment: Here is the log of the single failing test: attached -- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-12-06 22:22 Message: Logged In: YES user_id=469548 Fixed by not running this test when running as root. Checked in on both HEAD and release24-maint. -- Comment By: Michal Čihař (nijel) Date: 2004-12-04 22:05 Message: Logged In: YES user_id=192186 I meant, that as root you can do anything regardless actual file permissions: as root: # mkdir test # touch test/file # chmod 400 test # ll -d test dr 2 root root 4096 2004-12-04 22:00 test # rm -rf test # as user: $ mkdir test $ touch test/file $ chmod 400 test $ ll -d test dr 2 michal michal 4096 2004-12-04 22:05 test $ rm -rf test rm: cannot chdir from `.' to `test': Permission denied $ -- Comment By: Edward C. Jones (edcjones) Date: 2004-12-04 18:47 Message: Logged In: YES user_id=58796 I am having the same problem with Mandrake 10.1. I have an AMD chip with at least a i686 architecture. My Mandrake 10.1 is set at security level 3. In the past (RedHat, Gentoo), I have installed programs from source as follows: 1. su to root. 2. Copy the tar ball (.tgz, .tar.gz, or .tar.bz2) into /usr/local/src. 3. Expand the tar ball. 4. cd to the top directory of the new source tree. 5. Follow the directions given there. For Mandrake 10.1, this process failed when installing Python 2.4. The failure occured during "make test" in test_shutil.py with the same error message as above in this thread. Nigel said above that "This failure happens only when testing as root, because then permissions don't have usual meaning". Have the meaning of the root permissions changed? What do the root permissions now mean? Is this documented somewhere? -- Comment By: Michal Čihař (nijel) Date: 2004-12-02 12:57 Message: Logged In: YES user_id=192186 This failure happens only when testing as root, because then permissions don't have usual meaning, when testing as user, it works fine. -- Comment By: Pierre (pierre42) Date: 2004-12-01 22:35 Message: Logged In: YES user_id=512388 Same here. -- Comment By: Michal Čihař (nijel) Date: 2004-12-01 16:11 Message: Logged In: YES user_id=192186 Same happends on i386 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076467&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-853411 ] After fork in subthread, signals are blocked
Bugs item #853411, was opened at 2003-12-03 16:55 Message generated for change (Comment added) made by pymonger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=853411&group_id=5470 Category: Threads Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Göran Uddeborg (goeran) Assigned to: Nobody/Anonymous (nobody) Summary: After fork in subthread, signals are blocked Initial Comment: When a Python program starts a new thread, and this new thread forks, the forked process ingores signals. It will not terminate, or dump core if that would be applicable, when it receives a signal. I attach a test case which illustrates the behaviour. In this example, the child process is sent a SEGV signal from the subthread of the parent process. This should cause the child process to die and produce a core. But execution of the parent program threads finishes, there is still a python process around, continuing to sleep. Apparently, Python subthreads blocks signals. On Linux, /proc/*/status for subthreads includes the line SigBlk: 7ffbfeff The Python documentation says one should only install signal handlers in the main thread, and only the main thread will recieve signals. So this makes sense. But when the subthread forks, the new process inherits this signal mask, which seems to be incorrect behaviour. I would assume, if Python sets this signal mask for threads, it should also reset it again after a fork. I've seen this on these two platforms: Python 2.2.3 on Red Hat Linux RHEL 3WS (IA32) Python 2.2.1 on Sun Solaris 8 (Sparc) -- Comment By: gmanipon (pymonger) Date: 2004-12-06 21:24 Message: Logged In: YES user_id=1173063 Sorry for the bother. Was there any resolution to this bug report? -- Comment By: Jack Jansen (jackjansen) Date: 2004-01-26 10:02 Message: Logged In: YES user_id=45365 I have absolutely no idea where the bug could be, someone better versed in the threading ideosyncracies of the various platforms needs to look at this, but I do want to point at hairy_flange's comment that fink-python 2.2.3 on OSX does *not* exhibit the bug (while on other platforms it does). It may be worthwhile to download a fink-python in source form, and see whether they do any configure magic. -- Comment By: Steve Muir (hairy_flange) Date: 2004-01-26 04:04 Message: Logged In: YES user_id=960132 I just submitted a bug report that is a duplicate of this bug (apologies!), I observed the same behaviour with the Python shipped with Mac OS X (Python 2.3), and Python 2.2.2 on RedHat/x86, but Fink Python 2.2.3 for OS X does not have this bug. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=853411&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1079134 ] datetime changes missing from "Porting from 2.3 to 2.4"
Bugs item #1079134, was opened at 2004-12-05 00:29 Message generated for change (Settings changed) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1079134&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Sadruddin Rejeb (sadrejeb) >Assigned to: A.M. Kuchling (akuchling) Summary: datetime changes missing from "Porting from 2.3 to 2.4" Initial Comment: Since Python2.4, it's impossible to compare date and datetime when it was possible to do so in previous versions. I think this changed behaviour is missing from the "What's new in Python 2.4" documentation and should figure in the "porting from 2.3 to 2.4" section. -- Comment By: Tim Peters (tim_one) Date: 2004-12-05 03:45 Message: Logged In: YES user_id=31435 The truth (which is more involved than your characterization) is in the NEWS file: """ SF bug #1028306: Trying to compare a ``datetime.date`` to a ``datetime.datetime`` mistakenly compared only the year, month and day. Now it acts like a mixed-type comparison: ``False`` for ``==``, ``True`` for ``!=``, and raises ``TypeError`` for other comparison operators. Because datetime is a subclass of date, comparing only the base class (date) members can still be done, if that's desired, by forcing using of the approprate date method; e.g., ``a_date.__eq__(a_datetime)`` is true if and only if the year, month and day members of ``a_date`` and ``a_datetime`` are equal. """ -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1079134&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1079545 ] python-2.4.msi install error
Bugs item #1079545, was opened at 2004-12-05 21:02 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1079545&group_id=5470 Category: Installation Group: None Status: Open Resolution: None Priority: 5 Submitted By: maharal (maharal) >Assigned to: Martin v. Löwis (loewis) Summary: python-2.4.msi install error Initial Comment: when I try to install python2.4. using the python- 2.4.msi-file, it stopps with the error message: "The installer has encountered an unexpected error installing this package. This may inidicate a problem with this package. The error code is 2738" -- >Comment By: Martin v. Löwis (loewis) Date: 2004-12-06 22:59 Message: Logged In: YES user_id=21627 Can you please try to install VBScript, from http://msdn.microsoft.com/downloads/list/webdev.asp and report whether this works? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1079545&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1076515 ] shutil.move clobbers read-only files.
Bugs item #1076515, was opened at 2004-12-01 06:40 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076515&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Fincher (jemfinch) Assigned to: Nobody/Anonymous (nobody) Summary: shutil.move clobbers read-only files. Initial Comment: The summary states it fine. shutil.move happily overwrites read- only files. It looks like it indiscriminately catches OSError, and never bothers to check whether it's a permission error. It'd be nice if permission errors raised an exception that was a subclass of OSError, then it'd be cake to fix this (at least for *nices; I'm not sure about the Windows implications). According to tracker #810879, clobbering read-only files isn't the desired behavior for shutil.copyfile, so I doubt it's desired for shutil.move. -- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-12-06 23:21 Message: Logged In: YES user_id=469548 Your analysis is not correct. On Unix, you need write permission to the *directory* to rename. So the os.rename() call simply succeeds on a read-only file if you have write access to its parent directory. I think we could shield from this by always using the fallback implementation (copy2+unlink(src)), but I'm not sure what the implications of that would be (qua performance and cross-platform issues). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076515&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1074011 ] write failure ignored in Py_Finalize()
Bugs item #1074011, was opened at 2004-11-26 23:02
Message generated for change (Comment added) made by wom-work
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1074011&group_id=5470
Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 6
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: write failure ignored in Py_Finalize()
Initial Comment:
[forwarded from http://bugs.debian.org/283108]
Write errors on stdout may be ignored, and hence may
result in loss of valuable user data.
Here's a quick demo:
$ ./close-bug
foo
$ ./close-bug > /dev/full && echo unreported write failure
unreported write failure
$ cat close-bug
#!/usr/bin/python
import sys
def main ():
try:
print 'foo'
sys.stdout.close ()
except IOError, e:
sys.stderr.write ('write failed: %s\n' % e)
sys.exit (1)
if __name__ == '__main__':
main ()
This particular failure comes from the following
unchecked fflush
of stdout in pythonrun.c:
static void
call_ll_exitfuncs(void)
{
while (nexitfuncs > 0)
(*exitfuncs[--nexitfuncs])();
fflush(stdout);
fflush(stderr);
}
Flushing the stream manually, python does raise an
exception.
Please note that simply adding a test for fflush
failure is
not sufficient. If you change the above to do this:
if (fflush(stdout) != 0)
{
...handle error...
}
It will appear to solve the problem.
But here is a counterexample:
import sys
def main ():
try:
print "x" * 4095
print
sys.stdout.close ()
except IOError, e:
sys.stderr.write ('write failed: %s\n' % e)
sys.exit (1)
if __name__ == '__main__':
main ()
If you run the above with stdout redirected to /dev/full,
it will silently succeed (exit 0) in spite of a write
failure.
That's what happens on my debian unstable system.
Instead of just checking the fflush return value,
it should also check ferror:
if (fflush(stdout) != 0 || ferror(stdout))
{
...handle error...
}
--
Comment By: Ben Hutchings (wom-work)
Date: 2004-12-06 23:11
Message:
Logged In: YES
user_id=203860
The second sample script works for me (in that it raises the
expected exception) with or without my patch. If the error
status of the file has been set by some other operation
without Python noticing it then surely that's a bug in the
code that calls that other operation.
--
Comment By: Jim Meyering (meyering)
Date: 2004-12-02 09:20
Message:
Logged In: YES
user_id=41497
Hi,
I submitted the original report (and text above).
The patch that just calls fflush is not enough, as the second sample script
illustrates.
Here's a patch that does a little better
--- Python/sysmodule.c.~2.126.~ 2004-08-12 20:19:17.0 +0200
+++ Python/sysmodule.c 2004-12-02 09:59:09.058953816 +0100
@@ -927,6 +927,13 @@ settrace() -- set the global debug traci
)
/* end of sys_doc */ ;
+static int
+_check_and_flush (FILE *stream)
+{
+ int prev_fail = ferror (stream);
+ return fflush (stream) || prev_fail ? EOF : 0;
+}
+
PyObject *
_PySys_Init(void)
{
@@ -941,8 +948,8 @@ _PySys_Init(void)
sysdict = PyModule_GetDict(m);
sysin = PyFile_FromFile(stdin, "", "r", NULL);
- sysout = PyFile_FromFile(stdout, "", "w", NULL);
- syserr = PyFile_FromFile(stderr, "", "w", NULL);
+ sysout = PyFile_FromFile(stdout, "", "w", _check_and_flush);
+ syserr = PyFile_FromFile(stderr, "", "w", _check_and_flush);
if (PyErr_Occurred())
return NULL;
#ifdef MS_WINDOWS
With that patch, the failing script now evokes a diagnostic
and nonzero exit.
$ ./python write-4096 > /dev/full
write failed: (0, 'Error')
But, as you can see, the diagnostic leaves a lot to be desired.
It should say ``write failes: [Errno 28] No space left on device''.
It'll take a more significant change to propagate errno from the
failing fputs/fwrite/etc. to where it can be used.
[EMAIL PROTECTED]
--
Comment By: Ben Hutchings (wom-work)
Date: 2004-11-29 10:51
Message:
Logged In: YES
user_id=203860
I can't see how to upload an attachment to this bug, so see
patch 1075147.
--
Comment By: Ben Hutchings (wom-work)
Date: 2004-11-29 10:43
Message:
Logged In: YES
user_id=203860
Each Python file object has a pointer to the function to be
called on the C stream when close is called on the file
object. Normally this is fclose, but Python doesn't want
the standard streams closed so their file objects are
created with the function pointer set to NULL, making close
a n
[ python-Bugs-1074011 ] write failure ignored in Py_Finalize()
Bugs item #1074011, was opened at 2004-11-26 23:02
Message generated for change (Comment added) made by meyering
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1074011&group_id=5470
Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 6
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: write failure ignored in Py_Finalize()
Initial Comment:
[forwarded from http://bugs.debian.org/283108]
Write errors on stdout may be ignored, and hence may
result in loss of valuable user data.
Here's a quick demo:
$ ./close-bug
foo
$ ./close-bug > /dev/full && echo unreported write failure
unreported write failure
$ cat close-bug
#!/usr/bin/python
import sys
def main ():
try:
print 'foo'
sys.stdout.close ()
except IOError, e:
sys.stderr.write ('write failed: %s\n' % e)
sys.exit (1)
if __name__ == '__main__':
main ()
This particular failure comes from the following
unchecked fflush
of stdout in pythonrun.c:
static void
call_ll_exitfuncs(void)
{
while (nexitfuncs > 0)
(*exitfuncs[--nexitfuncs])();
fflush(stdout);
fflush(stderr);
}
Flushing the stream manually, python does raise an
exception.
Please note that simply adding a test for fflush
failure is
not sufficient. If you change the above to do this:
if (fflush(stdout) != 0)
{
...handle error...
}
It will appear to solve the problem.
But here is a counterexample:
import sys
def main ():
try:
print "x" * 4095
print
sys.stdout.close ()
except IOError, e:
sys.stderr.write ('write failed: %s\n' % e)
sys.exit (1)
if __name__ == '__main__':
main ()
If you run the above with stdout redirected to /dev/full,
it will silently succeed (exit 0) in spite of a write
failure.
That's what happens on my debian unstable system.
Instead of just checking the fflush return value,
it should also check ferror:
if (fflush(stdout) != 0 || ferror(stdout))
{
...handle error...
}
--
Comment By: Jim Meyering (meyering)
Date: 2004-12-06 23:27
Message:
Logged In: YES
user_id=41497
Even with python-2.4 (built fresh from CVS this morning),
I can still reproduce the problem on a Linux-2.6.9/ext3 system:
/p/p/python-2.4/bin/python write-4096 > /dev/full && echo fail
fail
The size that provokes the failure depends on the I/O block size
of your system, so you might need something as big as 131072
on some other type of system.
--
Comment By: Ben Hutchings (wom-work)
Date: 2004-12-06 23:11
Message:
Logged In: YES
user_id=203860
The second sample script works for me (in that it raises the
expected exception) with or without my patch. If the error
status of the file has been set by some other operation
without Python noticing it then surely that's a bug in the
code that calls that other operation.
--
Comment By: Jim Meyering (meyering)
Date: 2004-12-02 09:20
Message:
Logged In: YES
user_id=41497
Hi,
I submitted the original report (and text above).
The patch that just calls fflush is not enough, as the second sample script
illustrates.
Here's a patch that does a little better
--- Python/sysmodule.c.~2.126.~ 2004-08-12 20:19:17.0 +0200
+++ Python/sysmodule.c 2004-12-02 09:59:09.058953816 +0100
@@ -927,6 +927,13 @@ settrace() -- set the global debug traci
)
/* end of sys_doc */ ;
+static int
+_check_and_flush (FILE *stream)
+{
+ int prev_fail = ferror (stream);
+ return fflush (stream) || prev_fail ? EOF : 0;
+}
+
PyObject *
_PySys_Init(void)
{
@@ -941,8 +948,8 @@ _PySys_Init(void)
sysdict = PyModule_GetDict(m);
sysin = PyFile_FromFile(stdin, "", "r", NULL);
- sysout = PyFile_FromFile(stdout, "", "w", NULL);
- syserr = PyFile_FromFile(stderr, "", "w", NULL);
+ sysout = PyFile_FromFile(stdout, "", "w", _check_and_flush);
+ syserr = PyFile_FromFile(stderr, "", "w", _check_and_flush);
if (PyErr_Occurred())
return NULL;
#ifdef MS_WINDOWS
With that patch, the failing script now evokes a diagnostic
and nonzero exit.
$ ./python write-4096 > /dev/full
write failed: (0, 'Error')
But, as you can see, the diagnostic leaves a lot to be desired.
It should say ``write failes: [Errno 28] No space left on device''.
It'll take a more significant change to propagate errno from the
failing fputs/fwrite/etc. to where it can be used.
[EMAIL PROTECTED]
--
Comment By: Ben Hutchings (wom-work)
Date: 2004-11-29 10:51
Message:
Logged In: YES
user_id=203860
I can't see how
[ python-Bugs-1074011 ] write failure ignored in Py_Finalize()
Bugs item #1074011, was opened at 2004-11-26 23:02
Message generated for change (Comment added) made by wom-work
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1074011&group_id=5470
Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 6
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: write failure ignored in Py_Finalize()
Initial Comment:
[forwarded from http://bugs.debian.org/283108]
Write errors on stdout may be ignored, and hence may
result in loss of valuable user data.
Here's a quick demo:
$ ./close-bug
foo
$ ./close-bug > /dev/full && echo unreported write failure
unreported write failure
$ cat close-bug
#!/usr/bin/python
import sys
def main ():
try:
print 'foo'
sys.stdout.close ()
except IOError, e:
sys.stderr.write ('write failed: %s\n' % e)
sys.exit (1)
if __name__ == '__main__':
main ()
This particular failure comes from the following
unchecked fflush
of stdout in pythonrun.c:
static void
call_ll_exitfuncs(void)
{
while (nexitfuncs > 0)
(*exitfuncs[--nexitfuncs])();
fflush(stdout);
fflush(stderr);
}
Flushing the stream manually, python does raise an
exception.
Please note that simply adding a test for fflush
failure is
not sufficient. If you change the above to do this:
if (fflush(stdout) != 0)
{
...handle error...
}
It will appear to solve the problem.
But here is a counterexample:
import sys
def main ():
try:
print "x" * 4095
print
sys.stdout.close ()
except IOError, e:
sys.stderr.write ('write failed: %s\n' % e)
sys.exit (1)
if __name__ == '__main__':
main ()
If you run the above with stdout redirected to /dev/full,
it will silently succeed (exit 0) in spite of a write
failure.
That's what happens on my debian unstable system.
Instead of just checking the fflush return value,
it should also check ferror:
if (fflush(stdout) != 0 || ferror(stdout))
{
...handle error...
}
--
Comment By: Ben Hutchings (wom-work)
Date: 2004-12-07 00:33
Message:
Logged In: YES
user_id=203860
OK, I can reproduce the remaining problem if I substitute
1023 for 4095. The culprit seems to be the unchecked fputs()
in PyFile_WriteString, which is used for the spaces and
newlines generated by the print statement but not for the
objects. I think that's a separate bug.
--
Comment By: Jim Meyering (meyering)
Date: 2004-12-06 23:27
Message:
Logged In: YES
user_id=41497
Even with python-2.4 (built fresh from CVS this morning),
I can still reproduce the problem on a Linux-2.6.9/ext3 system:
/p/p/python-2.4/bin/python write-4096 > /dev/full && echo fail
fail
The size that provokes the failure depends on the I/O block size
of your system, so you might need something as big as 131072
on some other type of system.
--
Comment By: Ben Hutchings (wom-work)
Date: 2004-12-06 23:11
Message:
Logged In: YES
user_id=203860
The second sample script works for me (in that it raises the
expected exception) with or without my patch. If the error
status of the file has been set by some other operation
without Python noticing it then surely that's a bug in the
code that calls that other operation.
--
Comment By: Jim Meyering (meyering)
Date: 2004-12-02 09:20
Message:
Logged In: YES
user_id=41497
Hi,
I submitted the original report (and text above).
The patch that just calls fflush is not enough, as the second sample script
illustrates.
Here's a patch that does a little better
--- Python/sysmodule.c.~2.126.~ 2004-08-12 20:19:17.0 +0200
+++ Python/sysmodule.c 2004-12-02 09:59:09.058953816 +0100
@@ -927,6 +927,13 @@ settrace() -- set the global debug traci
)
/* end of sys_doc */ ;
+static int
+_check_and_flush (FILE *stream)
+{
+ int prev_fail = ferror (stream);
+ return fflush (stream) || prev_fail ? EOF : 0;
+}
+
PyObject *
_PySys_Init(void)
{
@@ -941,8 +948,8 @@ _PySys_Init(void)
sysdict = PyModule_GetDict(m);
sysin = PyFile_FromFile(stdin, "", "r", NULL);
- sysout = PyFile_FromFile(stdout, "", "w", NULL);
- syserr = PyFile_FromFile(stderr, "", "w", NULL);
+ sysout = PyFile_FromFile(stdout, "", "w", _check_and_flush);
+ syserr = PyFile_FromFile(stderr, "", "w", _check_and_flush);
if (PyErr_Occurred())
return NULL;
#ifdef MS_WINDOWS
With that patch, the failing script now evokes a diagnostic
and nonzero exit.
$ ./python write-4096 > /dev/full
write failed: (0, 'Error')
But, as yo
[ python-Bugs-955197 ] CFLAGS, CPPFLAGS, LDFLAGS are NOT used when building modules
Bugs item #955197, was opened at 2004-05-17 03:36 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=955197&group_id=5470 Category: Build >Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Niki W. Waibel (nikiwaibel) Assigned to: Brett Cannon (bcannon) Summary: CFLAGS, CPPFLAGS, LDFLAGS are NOT used when building modules Initial Comment: i am trying to compile python in solaris 2.8. ncurses incl files and libs are not in theis usual places (/usr/include, /usr/lib)! so i usually set CPPFLAGS, CFLAGS, LDFLAGS and LD_RUN_PATH when compiling programs. that works nicely if all of the automake, autoconf and libtool machinery is used. but it seems that the python team has decided to do sthg unusual when building the modules... === building '_curses' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -fno-strict-aliasing -I. -I/tmp/Python-2.3.3/./Include -I/tmp/Python-2.3. 3/Include -I/tmp/Python-2.3.3 -c /tmp/Python-2.3. 3/Modules/_cursesmodule.c -o build/temp.solaris-2.8-sun4u-2. 3/_cursesmodule.o In file included from /tmp/Python-2.3.3/Modules/_cursesmodule.c:113: /tmp/Python-2.3.3/./Include/py_curses.h:43:21: ncurses.h: No such file or directory === adding CPPFLAGS or CFLAGS to the compile command would sort things out. the same thing happens to other modules as well (bz2 ie). -- >Comment By: Brett Cannon (bcannon) Date: 2004-12-06 16:47 Message: Logged In: YES user_id=357491 rev. 1.205 of setup.py and rev. 1.149 of Makefile.pre.in allow extension modules to be compiled with the directories specified in LDFLAGS and CPPFLAGS. As for CFLAGS, that gets trickier. For that situation I would set OPT or BASECFLAGS when running configure (be careful of the latter, though, since you really are not supposed to play with that). Considering this bug closed and fixed. -- Comment By: Brett Cannon (bcannon) Date: 2004-11-06 17:30 Message: Logged In: YES user_id=357491 It's too late for 2.4, but I will get this in for 2.5 . I will try to add support for CC, CFLAGS, LDFLAGS, CPPFLAGS, and CPP (all of the environment variables listed by ``./configure -h``). Basically the problem is that setup.py does not check these. If you need a quick fix than just add the directories yourself (grep for Fink or DarwinPorts in setup.py to see the function calls). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=955197&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1080387 ] IDLE and old color themes
Bugs item #1080387, was opened at 2004-12-06 19:54 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=1080387&group_id=5470 Category: IDLE Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: projecktzero (projecktzero) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE and old color themes Initial Comment: After uninstalling Python 2.3.4 on my Windows 2000 workstation, I installed Python 2.4. Unfortunately, IDLE refused to start up. I would just see some hard drive activity, then nothing. Getting some help from the tutor list(Danny Yoo), I was told to try... import idlelib.PyShell idlelib.PyShell.main() from the Python command prompt. IDLE fired up, but it complained about my color theme(which I had created in Python 2.3.4). Unfortunately, I do not have the errors/warnings. I deleted the color theme from IDLE, and now IDLE fires up without issue. The color theme must have been left over from Python 2.3.4. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080387&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1080387 ] IDLE and old color themes
Bugs item #1080387, was opened at 2004-12-06 21:54 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080387&group_id=5470 Category: IDLE Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: projecktzero (projecktzero) >Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE and old color themes Initial Comment: After uninstalling Python 2.3.4 on my Windows 2000 workstation, I installed Python 2.4. Unfortunately, IDLE refused to start up. I would just see some hard drive activity, then nothing. Getting some help from the tutor list(Danny Yoo), I was told to try... import idlelib.PyShell idlelib.PyShell.main() from the Python command prompt. IDLE fired up, but it complained about my color theme(which I had created in Python 2.3.4). Unfortunately, I do not have the errors/warnings. I deleted the color theme from IDLE, and now IDLE fires up without issue. The color theme must have been left over from Python 2.3.4. -- >Comment By: Kurt B. Kaiser (kbk) Date: 2004-12-07 00:13 Message: Logged In: YES user_id=149084 The (un)installer doesn't know about the user's .idlerc file. There should not be any incompatiblility between 2.3.4 and 2.4 regarding the color themes. It's too bad you didn't save the error messages. Could you describe exactly what you mean by "I deleted the color theme?" . What files or parts of files were removed? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080387&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1080424 ] Inplace set merge produces wrong results
Bugs item #1080424, was opened at 2004-12-07 06:36 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=1080424&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: Inplace set merge produces wrong results Initial Comment: [forwarded from http://bugs.debian.org/284490] the inplace set merge can produce wrong results compared to the a = a | b non in-place (and slower) version. Please see the attached tarball: running the "test" script shows the problem. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080424&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1080440 ] float issue for NaN type in .pyc file
Bugs item #1080440, was opened at 2004-12-07 13:24 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=1080440&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dileep Nirala (dileep_nirala) Assigned to: Nobody/Anonymous (nobody) Summary: float issue for NaN type in .pyc file Initial Comment: There is a difference in output between .pyc and .py file, while dealing with NaN float. In fact I am doing a float range validation as part of my requirement. The content of my sample program [test.py] aboveMax = 1.8e+308 belowMin = -1.8e+308 print aboveMax, belowMin While execution: command: python test.py output: 1.#INF -1.#INF This output is expected and good, however if I use compiled python file as below, command: python test.pyc output: 1.0 -1.0 This output is wrong, it does not show Nan floating point. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080440&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1080424 ] Inplace set merge produces wrong results
Bugs item #1080424, was opened at 2004-12-07 00:36 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080424&group_id=5470 Category: Python Interpreter Core >Group: Not a Bug >Status: Closed >Resolution: Invalid Priority: 6 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: Inplace set merge produces wrong results Initial Comment: [forwarded from http://bugs.debian.org/284490] the inplace set merge can produce wrong results compared to the a = a | b non in-place (and slower) version. Please see the attached tarball: running the "test" script shows the problem. -- >Comment By: Tim Peters (tim_one) Date: 2004-12-07 02:46 Message: Logged In: YES user_id=31435 I can pretty much guarantee this isn't a bug in Python, but is in some aspect of your algorithm that *relies* on not sharing mutable sets. For example, if I leave Debtags1.py's self.items[t] |= add_elements alone but add this right after it: self.items[t] = self.items[t].copy() then Debtags1.py produces the same output as Debtags.py. Same thing with Debtags2.py: adding that line also makes Debtag2.py's output the same. That proves the problem isn't in the implementations of "|=" or .update(). It strongly suggests that you're mutating a shared set that you're not expecting to mutate, or aren't expecting is shared. For example, your driver does s = db.elset(sys.argv[1]) for t in sys.argv[2:]: s &= db.elset(t) and that mutates the set in self.items[sys.argv[1]]. If you don't intend that computing output will mutate the sets in db, then that code is confused. That's not the source of your differing output, but "something like it" probably is. In fact, the problem is probably here: self.items[t] = add_elements That can assign the same add_elements as the value associated with *many* distinct values of t. Then you try to update those later in place, but "those" is a single shared set. Changing the value associated with one of the t's then changes the value associated with all of the t's that originally got assigned the same "add_elements" set. If I go back to the original Debtags1.py, and replace self.items[t] = add_elements with self.items[t] = add_elements.copy() then the later updates-in-place do no harm, and it produces the output you said you expected. If you don't understand this, here's a dead simple example: >>> x = set([1]) >>> y = x # y and x are the *same* set now >>> x |= set([2]) # so mutating x in place ... >>> x set([1, 2]) >>> y # ... also mutates the set bound to y set([1, 2]) >>> -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080424&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1080440 ] float issue for NaN type in .pyc file
Bugs item #1080440, was opened at 2004-12-07 01:24 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080440&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dileep Nirala (dileep_nirala) Assigned to: Nobody/Anonymous (nobody) Summary: float issue for NaN type in .pyc file Initial Comment: There is a difference in output between .pyc and .py file, while dealing with NaN float. In fact I am doing a float range validation as part of my requirement. The content of my sample program [test.py] aboveMax = 1.8e+308 belowMin = -1.8e+308 print aboveMax, belowMin While execution: command: python test.py output: 1.#INF -1.#INF This output is expected and good, however if I use compiled python file as below, command: python test.pyc output: 1.0 -1.0 This output is wrong, it does not show Nan floating point. -- >Comment By: Tim Peters (tim_one) Date: 2004-12-07 02:51 Message: Logged In: YES user_id=31435 Python guarantees nothing about behavior in the presence of NaNs, infinities, or signed zeroes. Anything you see then is a platform-dependent accident. This should be closed with a reference to PEP 42 (I don't have time to look it all up now -- "non-accidental" IEEE behavior is a longstanding feature request, but one unlikely to be resolved in the foreseeable future; the particular problem here is that the marshal format deals in accidental ways with infinities, NaNs, and signed zeroes, so accidents in .py files may not be reproduced from .pyc files) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080440&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
