[ python-Bugs-1487966 ] SystemError with conditional expression in assignment
Bugs item #1487966, was opened at 2006-05-13 09:25 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1487966&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: iga Seilnacht (zseil) >Assigned to: Neal Norwitz (nnorwitz) Summary: SystemError with conditional expression in assignment Initial Comment: When a conditional expression appears on the left side of an assignment, SystemError is raised instead of SyntaxError. Example: Python 2.5a2 (trunk:45989M, May 13 2006, 15:40:42) [MSC v.1310 32 bit (Intel)] on win32 >>> a if True else b = 3 SystemError: unexpected expression in assignment 5 (line 1) -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-05-15 00:04 Message: Logged In: YES user_id=33168 Thanks for the patch! Committed revision 46000. -- Comment By: iga Seilnacht (zseil) Date: 2006-05-13 13:50 Message: Logged In: YES user_id=1326842 Attaching a patch. Most of the changes in test_syntax are due to error renumbering. All tests passed with this patch applied. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1487966&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1483133 ] gen_iternext: Assertion `f->f_back != ((void *)0)' failed
Bugs item #1483133, was opened at 2006-05-07 00:09 Message generated for change (Comment added) made by svensoho You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1483133&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None >Priority: 6 Submitted By: svensoho (svensoho) Assigned to: Nobody/Anonymous (nobody) >Summary: gen_iternext: Assertion `f->f_back != ((void *)0)' failed Initial Comment: Seems to be similar bug as http://sourceforge.net/ tracker/index.php? func=detail&aid=1257960&group_id=5470&atid=105470 (fixed) Couldn't trigger with same script but with C application. Same source modification helps (at Objects/genobject.c:53) -- >Comment By: svensoho (svensoho) Date: 2006-05-15 11:26 Message: Logged In: YES user_id=1518209 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1483133&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1488717 ] appended file on Windows reads arbitrary data
Bugs item #1488717, was opened at 2006-05-15 18:08
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1488717&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: muimi (muimi)
Assigned to: Nobody/Anonymous (nobody)
Summary: appended file on Windows reads arbitrary data
Initial Comment:
checked with versions 2.3 & 2.4.2 on Windows 2000 & XP
reading an appended file without resetting its
current position causes reading/writing of arbitrary data.
this appears to be related to the MS Visual Studio C
library.
def bug(filename):
af=open(filename,'a+')
af.write('\nlast line?')
print af.tell()
d=af.read() # this causes a read/write problem
print len(d), af.tell()
af.close()
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1488717&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1488779 ] appended file on Windows reads arbitrary data
Bugs item #1488779, was opened at 2006-05-15 20:09
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=1488779&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: muimi (muimi)
Assigned to: Nobody/Anonymous (nobody)
Summary: appended file on Windows reads arbitrary data
Initial Comment:
checked with versions 2.3 & 2.4.2 on Windows 2000 & XP
reading an appended file without resetting its
current position causes reading/writing of arbitrary data.
this appears to be related to the MS Visual Studio C
library.
def bug(filename):
af=open(filename,'a+')
af.write('\nlast line?')
print af.tell()
d=af.read() # this causes a read/write problem
print len(d), af.tell()
af.close()
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1488779&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1488634 ] tarfile.TarFile.open can might incorrectly raise ValueError
Bugs item #1488634, was opened at 2006-05-15 08:25 Message generated for change (Comment added) made by gustaebel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1488634&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andrew Bennetts (spiv) Assigned to: Nobody/Anonymous (nobody) Summary: tarfile.TarFile.open can might incorrectly raise ValueError Initial Comment: tarfile.TarFile.open, if passed a fileobj argument for a valid plain tar or tar.gz file, might fail to open the file, and instead unexpectedly raise "ValueError: no support for external file objects". "open" iterates over TarFile.OPEN_METH, which is a dictionary, to try find a method that works for a given file. If the internal, undefined, ordering of that dict returns the "bz2" key before the right one for a given file, and the fileobj argument is passed, TarFile will attempt to call bz2open with the fileobj method, which then raises "ValueError: no support for external file objects", which then is not caught. The end result is that it's possible to pass a valid tar or tar.gz file to TarFile.open in the fileobj argument, but get a ValueError from bz2open instead of a TarFile object. -- Comment By: Lars Gustäbel (gustaebel) Date: 2006-05-15 16:19 Message: Logged In: YES user_id=642936 I just submitted patch #141 that would solve your problem as a side-effect. Thanks for your report. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1488634&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1488906 ] endless loop in PyCFunction_Fini()
Bugs item #1488906, was opened at 2006-05-15 17:05
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=1488906&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Matejcik (spektrum)
Assigned to: Nobody/Anonymous (nobody)
Summary: endless loop in PyCFunction_Fini()
Initial Comment:
see https://bugzilla.novell.com/show_bug.cgi?id=171066
Basically, under some circumstances not yet determined,
PyCFunction_Fini() goes into an endless loop over a
cyclic linked list.
void
PyCFunction_Fini(void)
{
while (free_list) {
PyCFunctionObject *v = free_list;
free_list = (PyCFunctionObject *)(v->m_self);
PyObject_GC_Del(v);
}
}
it looks like it's sufficient to do
v->m_self = NULL;
or something.
However, for one, i'm not sure if this wouldn't break
something, and for two, free_list should never be
cyclic, right?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1488906&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1488915 ] Multiple dots in relative import statement raise SyntaxError
Bugs item #1488915, was opened at 2006-05-15 17: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=1488915&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: iga Seilnacht (zseil)
Assigned to: Nobody/Anonymous (nobody)
Summary: Multiple dots in relative import statement raise SyntaxError
Initial Comment:
When a relative import statement contains more than
one period and no module name, SyntaxError is raised.
Example:
from . import spam # this works
from ..spam import eggs # this works
from .. import eggs # this raises SyntaxError
The problem is in the following line in Grammar/Grammar:
import_from: ('from' ('.'* dotted_name | '.')
According to Guido's mail:
http://mail.python.org/pipermail/python-dev/2003-December/041065.html
that line should be:
import_from: ('from' ('.'* dotted_name | '.'+)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1488915&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1488934 ] file.write + closed pipe = no error
Bugs item #1488934, was opened at 2006-05-15 12: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=1488934&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Erik Demaine (edemaine)
Assigned to: Nobody/Anonymous (nobody)
Summary: file.write + closed pipe = no error
Initial Comment:
I am writing a Python script on Linux that gets called
via ssh (ssh hostname script.py) and I would like it to
know when its stdout gets closed because the ssh
connection gets killed. I assumed that it would
suffice to write to stdout, and that I would get an
error if stdout was no longer connected to anything.
This is not the case, however. I believe it is because
of incorrect error checking in Objects/fileobject.c's
file_write.
Consider this example:
while True:
__print 'Hello'
__time.sleep (1)
If this program is run via ssh and then the ssh
connection dies, the program continues running forever
(or at least, over 10 hours). No exceptions are thrown.
In contrast, this example does die as soon as the ssh
connection dies (within one second):
while True:
__os.write (1, 'Hello')
__time.sleep (1)
I claim that this is because os.write does proper error
checking, but file.write seems not to. I was surprised
to find this intricacy in fwrite(). Consider the
attached C program, test.c. (Warning: If you run it,
it will create a file /tmp/hello, and it will keep
running until you kill it.) While the ssh connection
remains open, fwrite() reports a length of 6 bytes
written, ferror() reports no error, and errno remains
0. Once the ssh connection dies, fwrite() still
reports a length of 6 bytes written (surprise!), but
ferror(stdout) reports an error, and errno changes to 5
(EIO). So apparently one cannot tell from the return
value of fwrite() alone whether the write actually
succeeded; it seems necessary to call ferror() to
determine whether the write caused an error.
I think the only change necessary is on line 2443 of
file_write() in Objects/fileobject.c (in svn version
46003):
2441n2 = fwrite(s, 1, n, f->f_fp);
2442Py_END_ALLOW_THREADS
2443if (n2 != n) {
2444PyErr_SetFromErrno(PyExc_IOError);
2445clearerr(f->f_fp);
I am not totally sure whether the "n2 != n" condition
should be changed to "n2 != n || ferror (f->f_fp)" or
simply "ferror (f->f_fp)", but I believe that the
condition should be changed to one of these
possibilities. The current behavior is wrong.
Incidentally, you'll notice that the C code has to turn
off signal SIGPIPE (like Python does) in order to not
die right away. However, I could not get Python to die
by re-enabling SIGPIPE. I tried "signal.signal
(signal.SIGPIPE, signal.SIG_DFL)" and "signal.signal
(signal.SIGPIPE, lambda x, y: sys.exit ())" and neither
one caused death of the script when the ssh connection
died. Perhaps I'm not using the signal module correctly?
I am on Linux 2.6.11 on a two-CPU Intel Pentium 4, and
I am running the latest Subversion version of Python,
but my guess is that this error transcends most if not
all versions of Python.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1488934&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1488934 ] file.write + closed pipe = no error
Bugs item #1488934, was opened at 2006-05-15 12:10
Message generated for change (Comment added) made by edemaine
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1488934&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Erik Demaine (edemaine)
Assigned to: Nobody/Anonymous (nobody)
Summary: file.write + closed pipe = no error
Initial Comment:
I am writing a Python script on Linux that gets called
via ssh (ssh hostname script.py) and I would like it to
know when its stdout gets closed because the ssh
connection gets killed. I assumed that it would
suffice to write to stdout, and that I would get an
error if stdout was no longer connected to anything.
This is not the case, however. I believe it is because
of incorrect error checking in Objects/fileobject.c's
file_write.
Consider this example:
while True:
__print 'Hello'
__time.sleep (1)
If this program is run via ssh and then the ssh
connection dies, the program continues running forever
(or at least, over 10 hours). No exceptions are thrown.
In contrast, this example does die as soon as the ssh
connection dies (within one second):
while True:
__os.write (1, 'Hello')
__time.sleep (1)
I claim that this is because os.write does proper error
checking, but file.write seems not to. I was surprised
to find this intricacy in fwrite(). Consider the
attached C program, test.c. (Warning: If you run it,
it will create a file /tmp/hello, and it will keep
running until you kill it.) While the ssh connection
remains open, fwrite() reports a length of 6 bytes
written, ferror() reports no error, and errno remains
0. Once the ssh connection dies, fwrite() still
reports a length of 6 bytes written (surprise!), but
ferror(stdout) reports an error, and errno changes to 5
(EIO). So apparently one cannot tell from the return
value of fwrite() alone whether the write actually
succeeded; it seems necessary to call ferror() to
determine whether the write caused an error.
I think the only change necessary is on line 2443 of
file_write() in Objects/fileobject.c (in svn version
46003):
2441n2 = fwrite(s, 1, n, f->f_fp);
2442Py_END_ALLOW_THREADS
2443if (n2 != n) {
2444PyErr_SetFromErrno(PyExc_IOError);
2445clearerr(f->f_fp);
I am not totally sure whether the "n2 != n" condition
should be changed to "n2 != n || ferror (f->f_fp)" or
simply "ferror (f->f_fp)", but I believe that the
condition should be changed to one of these
possibilities. The current behavior is wrong.
Incidentally, you'll notice that the C code has to turn
off signal SIGPIPE (like Python does) in order to not
die right away. However, I could not get Python to die
by re-enabling SIGPIPE. I tried "signal.signal
(signal.SIGPIPE, signal.SIG_DFL)" and "signal.signal
(signal.SIGPIPE, lambda x, y: sys.exit ())" and neither
one caused death of the script when the ssh connection
died. Perhaps I'm not using the signal module correctly?
I am on Linux 2.6.11 on a two-CPU Intel Pentium 4, and
I am running the latest Subversion version of Python,
but my guess is that this error transcends most if not
all versions of Python.
--
>Comment By: Erik Demaine (edemaine)
Date: 2006-05-15 12:26
Message:
Logged In: YES
user_id=265183
One more thing: fwrite() is used in a couple of other
places, and I think the same comment applies to them. They are:
- file_writelines() in Objects/fileobject.c
- w_string() in Python/marshal.c doesn't seem to have any
error checking? (At least no ferror() call in marhsal.c...)
- string_print() in Objects/stringobject.c doesn't seem to
have any error checking (but I'm not quite sure what this
means in Python land).
- flush_data() in Modules/_hotshot.c
- array_tofile() in Modules/arraymodule.c
- write_file() in Modules/cPickle.c
- putshort(), putlong(), writeheader(), writetab() [and the
functions that call them] in Modules/rgbimgmodule.c
- svc_writefile() in Modules/svmodule.c
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1488934&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1488943 ] difflib.Differ() doesn't always add hints for tab characters
Bugs item #1488943, was opened at 2006-05-16 00:27 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=1488943&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Henry (henryl) Assigned to: Nobody/Anonymous (nobody) Summary: difflib.Differ() doesn't always add hints for tab characters Initial Comment: The difflib.Differ() object doesn't always add a hint for added tab characters. eg: import difflib differ = difflib.Differ() for change in differ.compare(["\tI am a buggy"], ["\t\tI am a bug"]): print repr(change) Should return '- \tI am a buggy' '? \t --\n' '+ \t\tI am a bug' '? +\n' but actually returns (no hint for the added tab) '- \tI am a buggy' '? \t --\n' '+ \t\tI am a bug' sys.version reports 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1488943&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1488717 ] appended file on Windows reads arbitrary data
Bugs item #1488717, was opened at 2006-05-15 05:08
Message generated for change (Comment added) made by tim_one
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1488717&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
>Group: Not a Bug
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: muimi (muimi)
Assigned to: Nobody/Anonymous (nobody)
Summary: appended file on Windows reads arbitrary data
Initial Comment:
checked with versions 2.3 & 2.4.2 on Windows 2000 & XP
reading an appended file without resetting its
current position causes reading/writing of arbitrary data.
this appears to be related to the MS Visual Studio C
library.
def bug(filename):
af=open(filename,'a+')
af.write('\nlast line?')
print af.tell()
d=af.read() # this causes a read/write problem
print len(d), af.tell()
af.close()
--
>Comment By: Tim Peters (tim_one)
Date: 2006-05-15 12:58
Message:
Logged In: YES
user_id=31435
Yes, and this is inherited from the platform C library,
which conforms to the C standard in this respect: all
behavior is undefined if you read after write, or write
after read, without a file-positioning operation (typically
a seek) between them. So don't do that. Closing as not-a-bug.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1488717&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1486897 ] OS X framework build for python 2.5 fails, configure is odd
Bugs item #1486897, was opened at 2006-05-11 14:44 Message generated for change (Comment added) made by vizowl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486897&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Christopher Knox (vizowl) Assigned to: Nobody/Anonymous (nobody) Summary: OS X framework build for python 2.5 fails, configure is odd Initial Comment: The OS X framework build for python 2.5 does not install a dynamic library at /Library/Frameworks/Python.framework/Versions/2.5/Python where it should. The python2.5 executible does not run because it is trying to load this dynamic library. This is on an intel mac with darwin-8.6.1 and gcc4 and python2.5a2. Also all of the extra modules (_CG extension, IDLE extra) fail to link because their link command is -lpython2.5 which is not what it should be for a framework build and even if it was correct for linking agianst a framework it would fil because the framework doesn't have its library anyway. Finally, the configure script behaves oddly in that it works fine, but if you change the parameters and rerun it it will fail unless you run 'make distclean' This is where it fails. checking whether mmap with MAP_ANON(YMOUS) works... yes configure: error: "libffi has not been ported to i686-apple-darwin8.6.1." Failed to configure _ctypes module -- >Comment By: Christopher Knox (vizowl) Date: 2006-05-15 10:13 Message: Logged In: YES user_id=1346203 Hi Neal, I checked out rev 46003 (the HEAD at the time) in a clean directory and used: ./configure --enable-profiling --enable-shared --enable-framework -- enable-universalsdk Unfortunately it failed in the same way it has the same problems in that it is linking with the flag -lpython2.5 when it should be a framework linking. I have attached the build log from after having built it once so you only see the linking. However, it does appear that the issue raised in bug # 1487105 is solved. It compiled fine on an intel mac it just has linking problems. Also I get exactly the same problem on a G5 Chris -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-05-14 23:25 Message: Logged In: YES user_id=33168 Christopher can you try with a current checkout? Ronald checked in lots of changes which I think include x86 support at svn rev 45997. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486897&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1489051 ] keyword and topic help broken in Pythonwin IDE
Bugs item #1489051, was opened at 2006-05-15 18:46
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=1489051&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: BartlebyScrivener (bscrivener)
Assigned to: Nobody/Anonymous (nobody)
Summary: keyword and topic help broken in Pythonwin IDE
Initial Comment:
Using ActivePython 2.4.3 on Windows XP
While in the Pythonwin IDE, if I seek keyword help by
issuing the following command:
>>>help ('while')
I get:
Sorry, topic and keyword documentation is not available
because the Python HTML documentation files could not
be found. If you have installed them, please set the
environment variable PYTHONDOCS to
indicate their location.
My PYTHONDOCS variable is set to:
c:\python24\Doc\Python-Docs-2.4.2\ref
which appears to be correct (ie the help html files are
installed
there).
Searching this group, I found someone else complaining
about the same behavior with no clear resolution.
http://tinyurl.com/pblev
See also
http://tinyurl.com/mbokp
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1489051&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1488779 ] appended file on Windows reads arbitrary data
Bugs item #1488779, was opened at 2006-05-15 11:09
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1488779&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Platform-specific
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: muimi (muimi)
Assigned to: Nobody/Anonymous (nobody)
Summary: appended file on Windows reads arbitrary data
Initial Comment:
checked with versions 2.3 & 2.4.2 on Windows 2000 & XP
reading an appended file without resetting its
current position causes reading/writing of arbitrary data.
this appears to be related to the MS Visual Studio C
library.
def bug(filename):
af=open(filename,'a+')
af.write('\nlast line?')
print af.tell()
d=af.read() # this causes a read/write problem
print len(d), af.tell()
af.close()
--
>Comment By: Georg Brandl (gbrandl)
Date: 2006-05-15 19:26
Message:
Logged In: YES
user_id=849994
Dupe of #1488717.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1488779&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1488634 ] tarfile.TarFile.open can might incorrectly raise ValueError
Bugs item #1488634, was opened at 2006-05-15 06:25 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1488634&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Andrew Bennetts (spiv) Assigned to: Nobody/Anonymous (nobody) Summary: tarfile.TarFile.open can might incorrectly raise ValueError Initial Comment: tarfile.TarFile.open, if passed a fileobj argument for a valid plain tar or tar.gz file, might fail to open the file, and instead unexpectedly raise "ValueError: no support for external file objects". "open" iterates over TarFile.OPEN_METH, which is a dictionary, to try find a method that works for a given file. If the internal, undefined, ordering of that dict returns the "bz2" key before the right one for a given file, and the fileobj argument is passed, TarFile will attempt to call bz2open with the fileobj method, which then raises "ValueError: no support for external file objects", which then is not caught. The end result is that it's possible to pass a valid tar or tar.gz file to TarFile.open in the fileobj argument, but get a ValueError from bz2open instead of a TarFile object. -- >Comment By: Georg Brandl (gbrandl) Date: 2006-05-15 19:31 Message: Logged In: YES user_id=849994 Fixed with commit of said patch. -- Comment By: Lars Gustäbel (gustaebel) Date: 2006-05-15 14:19 Message: Logged In: YES user_id=642936 I just submitted patch #141 that would solve your problem as a side-effect. Thanks for your report. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1488634&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1489246 ] 2.4.3 fails to find Tcl/Tk on Solaris 10 x86_64
Bugs item #1489246, was opened at 2006-05-15 20:52 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=1489246&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Tim Mooney (enchanter) Assigned to: Nobody/Anonymous (nobody) Summary: 2.4.3 fails to find Tcl/Tk on Solaris 10 x86_64 Initial Comment: First, I'm a complete python newbie, but I have lots of experience with other languages and I'm very experienced at building software on UNIX platforms. I've built 64 bit (LP64) versions of Tcl 8.4.13 and Tk 8.4.13 with the Sun Studio 11 compiler. They're installed under /local, with the libraries in /local/lib/64 , since the Solaris convention is to use lib/64 for ELF64 libraries. I can configure and compile Python 2.4.3 as an LP64 executable, but setup.py fails to find Tcl/Tk. I'm suspicious (but not certain) that the problem is that the calls to self.compiler.find_library_file in setup.py aren't finding any of the locally installed libraries because find_library_file isn't searching the "64" subdirectory under lib. I've been through the README, and looked at the URL for the FAQ mentioned in the README (though I don't see a "section 3" of the FAQ). Most of the suggestions in the README in the Solaris section are geared toward what to do when python can't find your shared libraries *at run time*. That's not the problem here. I have my loader set up (via crle with the -64 option) to search all of the necessary locally-installed directories that contain ELF64 libraries. The problem is that Python's setup can't find the libraries in the first place. Suggestions? If I already knew Python, I could probably figure out how to subclass "compiler" to always search the "/64" version of a library directory when I'm on Solaris and the compiler flags contain a certain set of characters (better yet would be to actually compile something to an object file and test whether it's ELF64). Unfortunately, I'm not at that level yet. This instance is specific to Solaris, but the general problem applies to other multi-ABI platforms too, like IRIX, HP-UX, etc. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1489246&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
