[ python-Bugs-1586414 ] tarfile.extract() may cause file fragmentation on Windows XP
Bugs item #1586414, was opened at 2006-10-28 21:22 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=1586414&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 Private: No Submitted By: Enoch Julias (enochjul) Assigned to: Nobody/Anonymous (nobody) Summary: tarfile.extract() may cause file fragmentation on Windows XP Initial Comment: When I use tarfile.extract() to extract all the files from a large tar archive with lots of files tends to cause file fragmentation in Windows. Apparently NTFS cluster allocation interacts badly with such operations if Windows is not aware of the size of each file. The solution is to use a combination of the Win32 APIs SetFilePointer() and SetEndOfFile() before writing to the target file. This helps Windows choose a contiguous free space for the file. I tried it on the 2.6 trunk by calling file.truncate() (which seems to implement the appropriate calls on Windows) to set the file size before writing to a file. It helps to avoid fragmentation for the extracted files on my Windows XP x64 system. Can this be added to tarfile to improve its performance on Windows? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1586414&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1565514 ] does not raise SystemError on too many nested blocks
Bugs item #1565514, was opened at 2006-09-25 23:10 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565514&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: Fixed Priority: 5 Private: No Submitted By: Greg Hazel (ghazel) >Assigned to: Neal Norwitz (nnorwitz) Summary: does not raise SystemError on too many nested blocks Initial Comment: Simple script attached, in python 2.4.3 I get reasonable results: C:\>.\python24\python.exe nested.py File "nested.py", line 22 while 22: SystemError: too many statically nested blocks C:\> However in python 2.5 I get nothing: C:\>.\python25\python.exe nested.py C:\> Shouldn't the same error be raised? (Note that it's not executing the file, or the prints would occur). -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-10-28 14:59 Message: Logged In: YES user_id=33168 Committed revision 52510. (2.5) Committed revision 52504. (2.6) -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-26 21:45 Message: Logged In: YES user_id=33168 The attached patch fixes the problem. I'm not so sure that the error should be a SystemError, but some exception should definitely be produced. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565514&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1548092 ] curses module segfaults on invalid tparm arguments
Bugs item #1548092, was opened at 2006-08-28 10:47
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1548092&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: Extension Modules
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Marien Zwart (marienz)
Assigned to: Neal Norwitz (nnorwitz)
Summary: curses module segfaults on invalid tparm arguments
Initial Comment:
At least on my platform the ncurses "tparm" function
returns NULL on certain invalid arguments.
PyCurses_tparm does not check the return value, it just
passes it to PyString_FromString. This means:
python -c "import curses;curses.setupterm();print
curses.tparm('', curses.COLOR_GREEN)"
gives me:
zsh: segmentation fault python -c
(tested with python 2.4.3)
I am not sure what the best fix is. An exception would
make sense to me, but the (related) tigetstr function
returns None to python if the wrapped c function
returns NULL, and I have not used the curses module
enough to know what is more common.
--
>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-10-28 15:05
Message:
Logged In: YES
user_id=33168
2.5.1 - r51723
this wasn't backported to 2.4.4. there are not more 2.4.x
releases planned.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2006-09-01 19:51
Message:
Logged In: YES
user_id=33168
Thanks!
Committed revision 51683. 2.6
Needs to be backported to 2.5.1 and earlier.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2006-09-01 19:25
Message:
Logged In: YES
user_id=33168
reproduced with 2.5
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1548092&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1566611 ] Idle 1.2 - Calltips Hotkey does not work
Bugs item #1566611, was opened at 2006-09-27 13:24 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566611&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: fladd (fladd710) >Assigned to: Kurt B. Kaiser (kbk) Summary: Idle 1.2 - Calltips Hotkey does not work Initial Comment: Hitting CTRL+Backslash does not show the calltip (which is not shown by default) on Windows Xp with Python 1.5 Final. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566611&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1571112 ] simple moves freeze IDLE
Bugs item #1571112, was opened at 2006-10-04 21:46 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1571112&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: Python 2.5 Status: Open Resolution: None Priority: 7 Private: No Submitted By: Douglas W. Goodall (douglas_goodall) >Assigned to: Kurt B. Kaiser (kbk) Summary: simple moves freeze IDLE Initial Comment: Using version 2.5 for Windows... import os then type "print os." and wait for the hint window. then scroll to the bottom (spawnv). That's it. At this point IDLE is frozen. I have done it a few times in a row. It seems very reproduceable to me. Be well. Doug -- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-10-08 10:47 Message: Logged In: YES user_id=580910 As an additional data point: this seems to work just fine on Mac OS X. -- Comment By: Raymond Hettinger (rhettinger) Date: 2006-10-07 20:16 Message: Logged In: YES user_id=80475 I can reproduce this in Py2.5 final. This may be a TkInter bug and not unique to IDLE or to Windows. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-10-07 09:58 Message: Logged In: YES user_id=341410 I can reproduce this on 2.5 beta 2, and it dies exactly when 'spawnv' is highlighted. I have no suggested fixes, only reproducing to verify that this is not user-specific bug. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1571112&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1542677 ] IDLE shell doesn\'t accept non ascii char input
Bugs item #1542677, was opened at 2006-08-18 07:37
Message generated for change (Settings changed) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542677&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Santiago Gala (sgala)
>Assigned to: Kurt B. Kaiser (kbk)
>Summary: IDLE shell doesn\'t accept non ascii char input
Initial Comment:
in bug 1528802 ( see
https://sourceforge.net/tracker/index.php?func=detail&aid=1528802&group_id=5470&atid=105470
) , I noticed that idle shell behaviour WRT
non-ascii chars was different than python console, and
possibly broken.
For example, IDLE produces:
>>> print u"á"
á
>>> print len(u"á")
2
>>> print "á"
á
>>> print len("á")
2
---
a python shell (gnome-terminal):
>>> print u"á"
á
>>> print len(u"á")
1
>>> print "á"
á
>>> print len("á")
2
Both are using es_ES.utf-8 system encoding.
IDLE can manage unicode, it is just input that gives
problems:
>>> import unicodedata
>>> print unicodedata.lookup("LATIN SMALL LETTER A
WITH ACUTE")
á
>>> print len(unicodedata.lookup("LATIN SMALL
LETTER A WITH
ACUTE"))
1
Not that I like that much the violation of the least
surprising behaviour that python console offers with
non-ascii letters, but at least some internal
consistency would be great, until python 3000 gives us
true strings.
I'm using python 2.5 (svn trunk) --with-unicode=ucs4
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542677&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1562193 ] IDLE Hung up after open script by command line...
Bugs item #1562193, was opened at 2006-09-20 06:10
Message generated for change (Settings changed) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562193&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Marek Nowicki (faramir2)
>Assigned to: Kurt B. Kaiser (kbk)
Summary: IDLE Hung up after open script by command line...
Initial Comment:
Hello,
I wrote that code in python and saved as prx.py:
--- CUT ---
from BaseHTTPServer import HTTPServer,
BaseHTTPRequestHandler
from time import strftime, gmtime
import urllib2
import thread
from sys import stdout
class RequestHandler(BaseHTTPRequestHandler):
def serve(self):
print "%s %s %s\r\n%s" % (self.command,
self.path,
self.request_version, self.headers)
header={}
header["content-length"]=0
for i in str(self.headers).split("\r\n"):
j=i.split(":", 1)
if len(j)==2:
header[j[0].strip().lower()] =
j[1].strip()
content=self.rfile.read(int(header["content-
length"]))
print content
url="http://faramir2.prv.pl";
u=urllib2.urlopen(url)
for i,j in u.info().items():
print "%s: %s" % (i,j)
self.server_version = "Apache"
self.sys_version = ""
self.send_response(200)
self.send_header("Content-type", "text/html;
charset=ISO-8859-2")
self.send_header("Connectin", "close")
self.end_headers()
def do_POST(self): self.serve()
def do_HEAD(self): self.serve()
def do_GET(self): self.serve()
address = ("", 80)
server = HTTPServer(address, RequestHandler)
thread.start_new_thread(server.serve_forever, () )
--- CUT ---
When I right click on that file and select "Edit with
IDLE" it opens. Then
when I push F5 the script is running. *Python Shell*
is restarting. But
when I try to connect by browser to http://
localhost:80/ IDLE Hung-up. I
don't see that hung ups when I open IDLE from shortcut
and then in IDLE
open file prx.py and run it works normally - good.
IDLE does't hung up.
I don't know why it works like that, but I think that
it's bug..
Python version: 2.5c2
Tk version: 8.4
IDLE version: 1.2c2
OS Version: Microsoft Windows XP Professional with SP2
---
Again:
* Freeze:
>
"C:\Python25\pythonw.exe" "C:\Python25\Lib\idlelib\idle.pyw"
-n -e "prx.py"
// then F5 on IDLE
// when run open Browser and try to open page: http://
localhost:80
// IDLE freezes
* Works ok:
>
"C:\Python25\pythonw.exe" "C:\Python25\Lib\idlelib\idle.pyw"
-e
// open prx.py in IDLE
// press F5 on IDLE
// run Browwser and try to open page: http://
localhost:80
// all works ok
---
regards,
Marek
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562193&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1586448 ] compiler module dont emit LIST_APPEND w/ list comprehension
Bugs item #1586448, was opened at 2006-10-29 00:58 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1586448&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 Private: No Submitted By: sebastien Martini (seb_martini) Assigned to: Nobody/Anonymous (nobody) Summary: compiler module dont emit LIST_APPEND w/ list comprehension Initial Comment: In the module compiler, list comprehensions are implemented without emitting this bytecode. For example: >>> src = "[a for a in range(3)]" >>> co = compiler.compile(src, 'lc1', 'exec') >>> co at 0x404927b8, file "lc1", line 1> >>> dis.dis(co) 1 0 BUILD_LIST 0 3 DUP_TOP 4 LOAD_ATTR0 (append) 7 STORE_NAME 1 ($append0) 10 LOAD_NAME2 (range) 13 LOAD_CONST 1 (3) 16 CALL_FUNCTION1 19 GET_ITER >> 20 FOR_ITER16 (to 39) 23 STORE_NAME 3 (a) 26 LOAD_NAME1 ($append0) 29 LOAD_NAME3 (a) 32 CALL_FUNCTION1 35 POP_TOP 36 JUMP_ABSOLUTE 20 >> 39 DELETE_NAME 1 ($append0) 42 POP_TOP 43 LOAD_CONST 0 (None) 46 RETURN_VALUE >>> co2 = compile(src, 'lc2', 'exec') >>> co2 at 0x40492770, file "lc2", line 1> >>> dis.dis(co2) 1 0 BUILD_LIST 0 3 DUP_TOP 4 STORE_NAME 0 (_[1]) 7 LOAD_NAME1 (range) 10 LOAD_CONST 0 (3) 13 CALL_FUNCTION1 16 GET_ITER >> 17 FOR_ITER13 (to 33) 20 STORE_NAME 2 (a) 23 LOAD_NAME0 (_[1]) 26 LOAD_NAME2 (a) 29 LIST_APPEND 30 JUMP_ABSOLUTE 17 >> 33 DELETE_NAME 0 (_[1]) 36 POP_TOP 37 LOAD_CONST 1 (None) 40 RETURN_VALUE -- sébastien martini -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1586448&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1543306 ] "from __future__ import foobar; " causes wrong SyntaxError
Bugs item #1543306, was opened at 2006-08-19 19:16 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1543306&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.4 >Status: Closed >Resolution: Wont Fix Priority: 3 Private: No Submitted By: daniel hahler (blueyed) >Assigned to: Neal Norwitz (nnorwitz) Summary: "from __future__ import foobar;" causes wrong SyntaxError Initial Comment: Instead of "SyntaxError: future feature foobar is not defined", you will get "SyntaxError: from __future__ imports must occur at the beginning of the file", if you use a semicolon at the end of the line (which is valid for existing future-imports of course). Python 2.4.3 (#2, Apr 27 2006, 14:43:58) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from __future__ import foobar; File "", line 1 SyntaxError: from __future__ imports must occur at the beginning of the file >>> from __future__ import generators; >>> -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-10-28 15:58 Message: Logged In: YES user_id=33168 As Georg noted, this is fixed in 2.5. 2.4 is no longer supported. -- Comment By: Georg Brandl (gbrandl) Date: 2006-08-20 07:33 Message: Logged In: YES user_id=849994 The 2.5+ AST compiler gives the correct error message. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1543306&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1491574 ] distutils adds (unwanted) -xcode=pic32 in the compile comman
Bugs item #1491574, was opened at 2006-05-19 06:04 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1491574&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: Distutils Group: Platform-specific >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Toon Knapen (tknapen) Assigned to: Nobody/Anonymous (nobody) Summary: distutils adds (unwanted) -xcode=pic32 in the compile comman Initial Comment: After configuring, making and make installing the svn-trunk version with sunstudio11 on a Solaris 9 box, an extra '-xcode=pic32' argument is added to the compile-command when I try to install numarray using the setup.py that comes with numarray. To configure python I first executed: export CC=cc export CFLAGS="-xarch=v9" # to force 64bit compilation export EXTRA_CFLAGS="-xarch=v9" # export CXX=CC export CXXFLAGS="-xarch=v9" export F77=f77 export FFLAGS="-xarch=v9" export LDFLAGS="-xarch=v9" Note that EXTRA_CFLAGS needs to be defined too, otherwise python itself will not be compiled with the -xarch=v9 option. Afterwards I want to install numarray using the setup.py (`python setup.py install` command). During compilation of numarray I can however see that distutils is adding -xcode=pic32 on the command-line. Afterwards distutils is not able to link because there now is a mix of 32bit and 64bit code. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-10-28 18:02 Message: Logged In: YES user_id=33168 Based on last comment, I'm closing this report. -- Comment By: Toon Knapen (tknapen) Date: 2006-05-30 01:39 Message: Logged In: YES user_id=144552 Done. AFAIAC you can close this issue or we wait for the outcome of the discussion on python-dev -- Comment By: Martin v. Löwis (loewis) Date: 2006-05-23 14:11 Message: Logged In: YES user_id=21627 Yes, please move discussion to python-dev, although discussion of the build process usually fails to attract anybody. -- Comment By: Toon Knapen (tknapen) Date: 2006-05-23 02:13 Message: Logged In: YES user_id=144552 Looking through the code of distutils I finally found that plenty of information is recoved from the _current_ environment in distutils/sysconfig.py. Thus the LDFLAGS env.var. I had defined when configuring python is not stored somewhere. So when e.g. installing numarray, I need to set the LDFLAGS env.var. again. Would'nt it be better if python would store the flags/options that were used to compile python itself. This guarantees that the extension modules will be compiled/linked with the same flags and guarantees a maximal compatibility? If you prefer to move this discussion to the python-ml -- Comment By: Martin v. Löwis (loewis) Date: 2006-05-22 15:27 Message: Logged In: YES user_id=21627 Something like that, yes. It's quite involved, so it is not easy to see what the right approach is. If you can come up with a patch that works for you, I can review the patch to find out what else it breaks. -- Comment By: Toon Knapen (tknapen) Date: 2006-05-22 06:09 Message: Logged In: YES user_id=144552 Indeed the -xcode=pic32 is not at fault here. The problem though still is that distutils is not linking the shared libraries using the link-option '-xarch=v9'. The linker therefore complains about a mix of 32bit and 64bit code. Should'nt distutils copy the content of LDFLAGS of when python is being configured and add these options to the link-line ? -- Comment By: Martin v. Löwis (loewis) Date: 2006-05-19 23:31 Message: Logged In: YES user_id=21627 You must be misunderstanding something. -xcode=pic32 does *not* mean that the code ought to be compiled for the 32-bit processor mode. Instead, it means that the PIC (position independent code) offsets are encoded using 32-bit numbers, which works for both 32-bit and 64-bit code as long as the size of the code does not exceed 4GiB. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1491574&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1582742 ] Python is dumping core after the test test_ctypes
Bugs item #1582742, was opened at 2006-10-23 02:42 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1582742&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 Private: No Submitted By: shashi (shashikala) >Assigned to: Thomas Heller (theller) Summary: Python is dumping core after the test test_ctypes Initial Comment: Hi , Iam building Python-2.5 on HPUX Itanium. The compilation is done without any error, but while testing the same using gmake test it is dumping core telling "Segementation Fault" after the test test_ctypes. Please help me in resolving the above issue.Iam attaching the output of gmake test. Thanks in advance, -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-10-28 19:05 Message: Logged In: YES user_id=33168 This is the code that crashes: from ctypes import * print cast(c_void_p(0), POINTER(c_int)) *** #0 ffi_call_unix+0x20 () at trunk/Modules/_ctypes/libffi/src/ia64/unix.S:63 #1 0x200079194d30:0 in ffi_call (cif=0x7fffe020, fn=0x7913a860, rvalue=0x7fffe090, avalue=0x7fffe070) at trunk/Modules/_ctypes/libffi/src/ia64/ffi.c:372 #2 0x2000791762f0:0 in _call_function_pointer (flags=4101, pProc=0x7913a860, avalues=0x7fffe070, atypes=0x7fffe050, restype=0x40081de8, resmem=0x7fffe090, argcount=3) at trunk/Modules/_ctypes/callproc.c:665 #3 0x2000791781d0:0 in _CallProc (pProc=0x7913a860, argtuple=0x401cdd78, flags=4101, argtypes=0x401ef7b8, restype=0x400eacd8, checker=0x0) at trunk/Modules/_ctypes/callproc.c:1001 #4 0x200079165350:0 in CFuncPtr_call (self=0x4007abe8, inargs=0x401cdd78, kwds=0x0) at trunk/Modules/_ctypes/_ctypes.c:3364 *** Also note there are a bunch of errors like this: Warning: could not import ctypes.test.test_cfuncs: Unsatisfied code symbol '__divsf3' in load module 'trunk/build/lib.hp-ux-B.11.23-ia64-2.6/_ctypes_test.so'. -- Comment By: Martin v. Löwis (loewis) Date: 2006-10-25 01:41 Message: Logged In: YES user_id=21627 You will need to run Python in a debugger and find out where it crashes. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1582742&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1586513 ] codecs.open problem with "with" statement
Bugs item #1586513, was opened at 2006-10-28 21:56 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=1586513&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 Private: No Submitted By: Shaun Cutts (shauncutts) Assigned to: Nobody/Anonymous (nobody) Summary: codecs.open problem with "with" statement Initial Comment: Codecs.open does not seem to properly support the "with" protocol. Using codecs.open with "with" and without "with" hill give different results in a simple test. - from __future__ import with_statement import codecs fn = 'test.txt' f = open( fn, 'w' ) f.write( '\xc5' ) f.close() f = codecs.open( fn, 'r', 'L1' ) print repr( f.read() ) f.close() with codecs.open( fn, 'r', 'L1' ) as f: print repr( f.read() ) --- output: --- u'\xc5' '\xc5' --- Note: 2nd string not unicode. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1586513&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
