[issue7472] email.encoders.encode_7or8bit(): typo iso-2202. iso-2022 is correct.
Yukihiro Nakadaira yukihiro.nakada...@gmail.com added the comment: In other words, I think the correct thing to do is to delete that if test. I think so too. Do you have a case where the code produces incorrect behavior that your patch turns into correct behavior? No, I don't. I just found a typo. The code for iso-2022 was added by issue #804885. But I don't know why it was requested. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7472 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7738] IDLE hang when tooltip comes up in Linux
New submission from Kent Yip yes...@gmail.com: IDLE will hang when a tooltip shows in a Linux system (Ubuntu). do this: t = (1,2,3) len(t) it will hang after the closing ')', when you press return nothing will happen or when you press any keys, it won't show up. However, you can work around this hangup by clicking on the IDLE menus on top or clicking on a different application on your desktop and return to IDLE and press Enter will work again tested on python2.5, python2.6, python3.0 on linux machine however in windows vista with python3.1 the tooltip hangup doesn't exist. Only in Linux does it behave like that. -- components: IDLE messages: 98048 nosy: yesk13 severity: normal status: open title: IDLE hang when tooltip comes up in Linux type: behavior versions: Python 2.5, Python 2.6, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7738 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7739] time.strftime may hung while trying to open /etc/localtime but does not release GIL
New submission from Doron Tal doron.tal.l...@gmail.com:
I've encountered a hung of python process for more than a second. It appears
that the stall happens due to time.strftime call, which internally opens a file
('/etc/localtime'). I think it is best if the GIL would have been released to
allow other threads to continue working.
Snippet from strace on:
---
import time
time.strftime('%Z')
---
Note the line:
open(/etc/localtime, O_RDONLY)= 4
=== strace output Starts here ===---
stat(/usr/local/lib/python2.6/lib-old/time, 0x7fff871deff0) = -1 ENOENT (No
such file or directory)
open(/usr/local/lib/python2.6/lib-old/time.so, O_RDONLY) = -1 ENOENT (No such
file or directory)
open(/usr/local/lib/python2.6/lib-old/timemodule.so, O_RDONLY) = -1 ENOENT
(No such file or directory)
open(/usr/local/lib/python2.6/lib-old/time.py, O_RDONLY) = -1 ENOENT (No such
file or directory)
open(/usr/local/lib/python2.6/lib-old/time.pyc, O_RDONLY) = -1 ENOENT (No
such file or directory)
stat(/usr/local/lib/python2.6/lib-dynload/time, 0x7fff871deff0) = -1 ENOENT
(No such file or directory)
open(/usr/local/lib/python2.6/lib-dynload/time.so, O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0755, st_size=46995, ...}) = 0
futex(0x393b4030ec, FUTEX_WAKE_PRIVATE, 2147483647) = 0
open(/usr/local/lib/python2.6/lib-dynload/time.so, O_RDONLY) = 4
read(4, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\\30\0\0\0\0\0\0...,
832) = 832
fstat(4, {st_mode=S_IFREG|0755, st_size=46995, ...}) = 0
mmap(NULL, 2115944, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 4, 0) =
0x2adf26fba000
mprotect(0x2adf26fbd000, 2097152, PROT_NONE) = 0
mmap(0x2adf271bd000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 4, 0x3000) = 0x2adf271bd000
close(4)= 0
time(NULL) = 1263890749
open(/etc/localtime, O_RDONLY)= 4
fstat(4, {st_mode=S_IFREG|0644, st_size=2197, ...}) = 0
fstat(4, {st_mode=S_IFREG|0644, st_size=2197, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x2adf271bf000
read(4, TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0\0..., 4096)
= 2197
lseek(4, -1394, SEEK_CUR) = 803
read(4, TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\5\0\0\0\5\0\0\0\0..., 4096)
= 1394
close(4)= 0
munmap(0x2adf271bf000, 4096)= 0
close(3)= 0
time(NULL) = 1263890749
stat(/etc/localtime, {st_mode=S_IFREG|0644, st_size=2197, ...}) = 0
rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x393b60e930}, {0x4c4730, [],
SA_RESTORER, 0x393b60e930}, 8) = 0
exit_group(0) = ?
--
messages: 98049
nosy: dorontal
severity: normal
status: open
title: time.strftime may hung while trying to open /etc/localtime but does not
release GIL
versions: Python 2.6
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7739
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7723] sqlite only accept buffer() for BLOB objects (input/output)
Antoine Pitrou pit...@free.fr added the comment: Hello Gerhard, As far as I can see, the Python 3 definition of the old buffer interface is anything that I can apply memoryview to. Roughly, yes. When returning BLOBs, the sqlite3 module now returns bytes objects. I think this could be changed to memoryview without causing any problems. No, returning bytes objects is the right thing to do under py3k. This bug report is only about 2.x, where bytes is the same as str and therefore doesn't allow to distinguish text from binary data. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7723 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7739] time.strftime may hung while trying to open /etc/localtime but does not release GIL
Antoine Pitrou pit...@free.fr added the comment: You might want to investigate which C library call opens this file, and propose a patch to release the GIL before doing that call. As far as I can tell, Python itself does not open /etc/localtime in any place. -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7739 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7741] Allow multiple statements in code.InteractiveConsole.push
New submission from Kristján Valur Jónsson krist...@ccpgames.com: The code.InteractiveConsole() is useful to emulate a python console. However, any code currently pushed to it must be single statements. This is because it passes the ´single´ symbol mode to the underlying compile function. This patch allows the caller of InteractiveConsole.push to specify a different mode, e.g. ´exec´. This is useful if one wants to paste entire code snippets into the console. Without it, pasting the following: 'if True:\n print 1\nprint 2' Won't run. pushing such multiline code snippets with an additional 'exec' argument will allow it to work. Patch included. -- components: Library (Lib) files: code.patch keywords: patch messages: 98056 nosy: krisvale severity: normal status: open title: Allow multiple statements in code.InteractiveConsole.push type: feature request versions: Python 2.7 Added file: http://bugs.python.org/file15950/code.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7741 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7741] Allow multiple statements in code.InteractiveConsole.push
Kristján Valur Jónsson krist...@ccpgames.com added the comment: Note, there are no regression tests for the code module. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7741 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7741] Allow multiple statements in code.InteractiveConsole.push
Kristján Valur Jónsson krist...@ccpgames.com added the comment: Here is how to test this manually: from code import InteractiveConsole c = InteractiveConsole() s = if True:\n print 1\nprint 2 c.push(s) #fails c.push(s, exec) #succeeds -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7741 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7712] Add a context manager to change cwd in test.test_support
Changes by Florent Xicluna la...@yahoo.fr: Removed file: http://bugs.python.org/file15907/temp_cwd_decorator.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7712 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7712] Add a context manager to change cwd in test.test_support
Florent Xicluna la...@yahoo.fr added the comment: Changed, after review from Ezio and other developpers. -- Added file: http://bugs.python.org/file15951/temp_cwd_decorator_v2.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7712 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7712] Add a context manager to change cwd in test.test_support
Antoine Pitrou pit...@free.fr added the comment: with_writable_cwd should probably use functools.wraps. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7712 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7712] Add a context manager to change cwd in test.test_support
Ezio Melotti ezio.melo...@gmail.com added the comment: The patch looks good, I'd just move _test_cwd inside the function and drop the [:-3] from TESTFN, but apart from that it's OK. I also agree that functools.wraps should be added. To summarize the discussion we had on #python-dev: 1) the context manager should always create a writable cwd and to be able to run with -J it should contain the process id. Using TESTFN as first-level dir solves both the issues; 2) a suffix is added to TESTFN to let the tests use TESTFN as a valid filename; 3) the second-level dir is 'tempcwd' by default or can be passed to the function in case a test needs a specific name for the cwd; The result will be something like '@test__tmp_cwd/dirname'. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7712 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4194] default subprocess.Popen buffer size
Skip Montanaro s...@pobox.com added the comment: Looks good to me: tmp% python3.1 popentest.py time with os.popen : 0.035565 time with subprocess.Popen : 0.031796 tmp% python3.2 popentest.py time with os.popen : 0.03501 time with subprocess.Popen : 0.031168 tmp% python3.1 Python 3.1.1+ (release31-maint:77485M, Jan 13 2010, 19:53:41) [GCC 4.0.1 (Apple Inc. build 5490)] on darwin Type help, copyright, credits or license for more information. tmp% python3.2 Python 3.2a0 (py3k:77484:77485, Jan 13 2010, 19:49:33) [GCC 4.0.1 (Apple Inc. build 5490)] on darwin Type help, copyright, credits or license for more information. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4194 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1578269] Add os.link() and os.symlink() and os.path.islink() support for Windows
Jason R. Coombs jar...@jaraco.com added the comment: I'm currently struggling with determining if the host process has the appropriate privileges. I'm stuck in that I've enumerated the privileges for an admin account, but the SeCreateSymbolicLink privilege is not present. I guess it's inherited. If you have any suggestions for determining access, please consider posting a response at http://stackoverflow.com/questions/2094663/determine-if-windows-process-has-permission-to-create-symbolic-link . -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1578269 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1578269] Add os.link() and os.symlink() and os.path.islink() support for Windows
Changes by Gabriel Genellina gagsl-...@yahoo.com.ar: -- nosy: +gagenellina ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1578269 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1578269] Add os.link() and os.symlink() and os.path.islink() support for Windows
Amaury Forgeot d'Arc amaur...@gmail.com added the comment: IMO we could just catch the WindowsError, and skip the test if its winerror attribute is 1314 (=ERROR_PRIVILEGE_NOT_HELD). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1578269 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5684] test_zipfile writes in its test directory
Florent Xicluna la...@yahoo.fr added the comment: Patch using the proposed context manager (#7712). -- keywords: +patch nosy: +flox Added file: http://bugs.python.org/file15952/issue5684_test_zipfile.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5684 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5684] test_zipfile writes in its test directory
Changes by Ezio Melotti ezio.melo...@gmail.com: -- assignee: - ezio.melotti keywords: +needs review priority: low - normal stage: needs patch - patch review versions: +Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5684 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7739] time.strftime may hung while trying to open /etc/localtime but does not release GIL
Martin v. Löwis mar...@v.loewis.de added the comment: I'd also be curious why it takes a second to open /etc/localtime. That sounds like a bug in the C library, or a mismanaged system. -- nosy: +loewis ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7739 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7736] ctypes freezes/deadlocks process
Marcin Bachry hegel...@gmail.com added the comment: Here's the backtrace: #0 sem_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:85 #1 0x7fcd0234a6e8 in PyThread_acquire_lock (lock=0x183f3f0, waitflag=128) at Python/thread_pthread.h:349 #2 0x7fcd02311fa4 in PyEval_RestoreThread (tstate=0x17a9b00) at Python/ceval.c:356 #3 0x7fcd02336a28 in PyGILState_Ensure () at Python/pystate.c:592 #4 0x7fcd013fcec1 in _CallPythonObject (cif=0x183f3f0, resp=0x80, args=0x7fccff153f40, userdata=value optimized out) at /home/marcin/Desktop/python/python2.x-hg/Modules/_ctypes/callbacks.c:220 #5 closure_fcn (cif=0x183f3f0, resp=0x80, args=0x7fccff153f40, userdata=value optimized out) at /home/marcin/Desktop/python/python2.x-hg/Modules/_ctypes/callbacks.c:374 #6 0x7fcd014044f0 in ffi_closure_unix64_inner (closure=value optimized out, rvalue=value optimized out, reg_args=0x246, argp=0x0) at /home/marcin/Desktop/python/python2.x-hg/Modules/_ctypes/libffi/src/x86/ffi64.c:566 #7 0x7fcd01404b68 in ffi_closure_unix64 () at /home/marcin/Desktop/python/python2.x-hg/Modules/_ctypes/libffi/src/x86/unix64.S:230 #8 0x7fccff572429 in ?? () from /lib/libfuse.so.2 #9 0x7fccff5704fa in fuse_session_loop () from /lib/libfuse.so.2 #10 0x7fccff1576e4 in ?? () #11 0x7fccff154188 in ?? () #12 0x7fccff3580e0 in ?? () #13 0x0192e2f0 in ?? () #14 0x0004 in ?? () #15 0x0001 in ?? () #16 0x016ff5e0 in ?? () #17 0x0001 in ?? () #18 0x in ?? () All calls to native POSIX functions seem to be wrapped with Py_BEGIN_ALLOW_THREADS/Py_END_ALLOW_THREADS except of opendir() and closedir(). When I fix it (as in attached patch), call_hello.py doesn't block anymore. -- keywords: +patch nosy: +marcin.bachry Added file: http://bugs.python.org/file15953/posix-opendir-and-gil.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7736 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7736] ctypes freezes/deadlocks process
Nikolaus Rath nikol...@rath.org added the comment: Wow, great! Thanks for looking into this. How did you manage to get the backtrace? As I said, on my system gdb -p just hangs with when attaching. I'm changing the component, since it seems that it's the os module that's at fault and not ctypes. -- components: +Library (Lib) -ctypes versions: +Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7736 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7736] os.listdir hangs since opendir() and closedir() do not release GIL
Changes by Nikolaus Rath nikol...@rath.org: -- title: ctypes freezes/deadlocks process - os.listdir hangs since opendir() and closedir() do not release GIL ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7736 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7736] os.listdir hangs since opendir() and closedir() do not release GIL
Changes by Brian Curtin cur...@acm.org: -- keywords: +needs review nosy: +brian.curtin priority: - normal stage: - patch review versions: +Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7736 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7739] time.strftime may hung while trying to open /etc/localtime but does not release GIL
Doron Tal doron.tal.l...@gmail.com added the comment: We didn't prove this point yet, currently it's merely circumstantial. The application calls strftime few dozen times each second from different threads. We spot the stall using another two threads, the first takes a time stamp before calling a python function and reset the time stamp when the python function is done. The other thread watches the timestamp and if it gets over a certain limit (2 seconds) it aborts the process, leaving a core dump behind. We've build this infrastructure to tackle python stalls caused by misbehaving C calls which takes long but does not release the GIL. Here is the traceback (one of the threads): #0 0x003424ac5800 in __open_nocancel () from /lib64/libc.so.6 #1 0x003424a6c383 in __GI__IO_file_open () from /lib64/libc.so.6 #2 0x003424a6c43c in _IO_new_file_fopen () from /lib64/libc.so.6 #3 0x003424a61764 in __fopen_internal () from /lib64/libc.so.6 #4 0x003424a8d666 in __tzfile_read () from /lib64/libc.so.6 #5 0x003424a8c56f in tzset_internal () from /lib64/libc.so.6 #6 0x003424a8d010 in tzset () from /lib64/libc.so.6 #7 0x003424a91934 in strftime_l () from /lib64/libc.so.6 #8 0x2aea01bced34 in ?? () from /usr/lib64/python2.4/lib-dynload/timemodule.so #9 0x0034304360f0 in PyObject_Call () from /usr/lib64/libpython2.4.so.1.0 #10 0x003430436bbc in PyObject_CallMethod () from /usr/lib64/libpython2.4.so.1.0 #11 0x2aea01dda64a in ?? () from /usr/lib64/python2.4/lib-dynload/datetime.so #12 0x2aea01dda9c3 in ?? () from /usr/lib64/python2.4/lib-dynload/datetime.so #13 0x0034304950ba in PyEval_EvalFrame () from /usr/lib64/libpython2.4.so.1.0 #14 0x003430494b66 in PyEval_EvalFrame () from /usr/lib64/libpython2.4.so.1.0 #15 0x003430495fe5 in PyEval_EvalCodeEx () from /usr/lib64/libpython2.4.so.1.0 #16 0x00343044c45a in ?? () from /usr/lib64/libpython2.4.so.1.0 #17 0x0034304360f0 in PyObject_Call () from /usr/lib64/libpython2.4.so.1.0 #18 0x00343049352c in PyEval_EvalFrame () from /usr/lib64/libpython2.4.so.1.0 #19 0x003430495fe5 in PyEval_EvalCodeEx () from /usr/lib64/libpython2.4.so.1.0 #20 0x00343044c45a in ?? () from /usr/lib64/libpython2.4.so.1.0 #21 0x0034304360f0 in PyObject_Call () from /usr/lib64/libpython2.4.so.1.0 #22 0x00343049352c in PyEval_EvalFrame () from /usr/lib64/libpython2.4.so.1.0 #23 0x003430494b66 in PyEval_EvalFrame () from /usr/lib64/libpython2.4.so.1.0 #24 0x003430495fe5 in PyEval_EvalCodeEx () from /usr/lib64/libpython2.4.so.1.0 #25 0x00343044c367 in ?? () from /usr/lib64/libpython2.4.so.1.0 #26 0x0034304360f0 in PyObject_Call () from /usr/lib64/libpython2.4.so.1.0 #27 0x00343043c1ef in ?? () from /usr/lib64/libpython2.4.so.1.0 #28 0x0034304360f0 in PyObject_Call () from /usr/lib64/libpython2.4.so.1.0 #29 0x00343048fc3d in PyEval_CallObjectWithKeywords () from /usr/lib64/libpython2.4.so.1.0 #30 0x0034304d in ?? () from /usr/lib64/libpython2.4.so.1.0 #31 0x0034256064a7 in start_thread () from /lib64/libpthread.so.0 #32 0x003424ad3c2d in clone () from /lib64/libc.so.6 So, we didn't actually proved that opening /etc/localtime takes so long. I assumed that it is better to release the GIL prior to opening a file. In any case, it won't solve our problem, since we use old Python 2.4.3 (CentOS5.4)... --doron On Tue, Jan 19, 2010 at 10:27 PM, Martin v. Löwis rep...@bugs.python.orgwrote: Martin v. Löwis mar...@v.loewis.de added the comment: I'd also be curious why it takes a second to open /etc/localtime. That sounds like a bug in the C library, or a mismanaged system. -- nosy: +loewis ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7739 ___ -- Added file: http://bugs.python.org/file15954/unnamed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7739 ___div dir=ltrWe didn#39;t prove this point yet, currently it#39;s merely circumstantial.brThe application calls strftime few dozen times each second from different threads. We spot the stall using another two threads, the first takes a time stamp before calling a python function and reset the time stamp when the python function is done. The other thread watches the timestamp and if it gets over a certain limit (2 seconds) it aborts the process, leaving a core dump behind.br brWe#39;ve build this infrastructure to tackle python stalls caused by misbehaving C calls which takes long but does not release the GIL.brbrHere is the traceback (one of the threads):brmeta http-equiv=Content-Type content=text/html; charset=utf-8meta name=ProgId content=Word.Documentmeta name=Generator content=Microsoft Word 12meta name=Originator content=Microsoft Word 12link rel=File-List
[issue7742] please avoid 'which' in Modules/ld_so_aix
New submission from Michael Haubenwallner michael.haubenwall...@salomon.at: In Modules/ld_so_aix there is `which $CC` to search for the full compiler's path. Unfortunately, /usr/bin/which on AIX is a csh-script and thus ~/.cshrc gets sourced before doing the path search. Now, when the user does set some PATH in ~/.cshrc, `which` might print a wrong path for the compiler, causing the build to fail (at best). It would be better to do the path search without launching an external program. -- files: ld_so_aix-which.patch keywords: patch messages: 98070 nosy: haubi severity: normal status: open title: please avoid 'which' in Modules/ld_so_aix versions: Python 3.2 Added file: http://bugs.python.org/file15955/ld_so_aix-which.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7742 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7742] please avoid 'which' in Modules/ld_so_aix
Michael Haubenwallner michael.haubenwall...@salomon.at added the comment: Uhm, as I read the patch again, there's room for improvement of pywhich(): it likely fails with CC=/full/path/to/cc -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7742 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7712] Add a context manager to change cwd in test.test_support
Florent Xicluna la...@yahoo.fr added the comment: Different approach, after some other talks with Ezio and David. Now the directory is changed before running any test. The developer can assume that the current directory if always writable. It makes the tests easier to write, and repeatable. Additionally, TESTFN always contains a single filename (without path). Before this change, it could be /tmp/@test or @test, which is error-prone. The decorator becomes useless. -- Added file: http://bugs.python.org/file15956/issue7712_context_manager.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7712 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7742] please avoid 'which' in Modules/ld_so_aix
Changes by Brian Curtin cur...@acm.org: -- components: +None keywords: +needs review priority: - normal stage: - patch review type: - behavior versions: +Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7742 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
