[issue4313] IDLE segfault at exit
New submission from STINNER Victor [EMAIL PROTECTED]: With Python 3.0 trunk on Ubuntu Gutsy, IDLE crashs at exit. gdb trace: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1210763072 (LWP 9441)] 0xb79ac133 in Tk_Free3DBorder () from /usr/lib/libtk8.4.so.0 (gdb) where #0 0xb79ac133 in Tk_Free3DBorder () from /usr/lib/libtk8.4.so.0 #1 0xb7a3cb36 in TkTextFreeTag () from /usr/lib/libtk8.4.so.0 #2 0xb7a2aef1 in ?? () from /usr/lib/libtk8.4.so.0 #3 0x084ade70 in ?? () #4 0x084b2410 in ?? () #5 0xbfecb248 in ?? () #6 0xb798e518 in ?? () from /usr/lib/libtcl8.4.so.0 #7 0xbfecb250 in ?? () #8 0x084ade84 in ?? () #9 0xbfecb268 in ?? () #10 0xb798e518 in ?? () from /usr/lib/libtcl8.4.so.0 #11 0x084ade84 in ?? () #12 0x0001 in ?? () #13 0x in ?? () -- messages: 75817 nosy: haypo severity: normal status: open title: IDLE segfault at exit ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4313 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4313] IDLE segfault at exit
STINNER Victor [EMAIL PROTECTED] added the comment: The crash occurs when I close a window if a file was open. I can reproduce the crash on Debian Sid, so it's not a problem of an old library version. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4313 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1222] locale.format bug if thousand separator is space (french separator as example)
Changes by Walter Doekes [EMAIL PROTECTED]: -- nosy: +wdoekes ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1222 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4313] IDLE segfault at exit
STINNER Victor [EMAIL PROTECTED] added the comment:
The bug looks to be specific to Python3 but may comes from Tk and not
directly from tkinter module. I recompiled Tk with debug symbols to get
a better backtrace:
malformed bucket chain in Tcl_DeleteHashEntry
Program received signal SIGABRT, Aborted.
[Switching to Thread 0xb7e178c0 (LWP 23520)]
0xb7fd1424 in __kernel_vsyscall ()
(gdb) where
#0 0xb7fd1424 in __kernel_vsyscall ()
#1 0xb7e43640 in raise () from /lib/i686/cmov/libc.so.6
#2 0xb7e45018 in abort () from /lib/i686/cmov/libc.so.6
#3 0xb78c2cff in Tcl_PanicVA () from /usr/lib/libtcl8.4.so.0
#4 0xb78c2d27 in Tcl_Panic () from /usr/lib/libtcl8.4.so.0
#5 0xb78a469d in Tcl_DeleteHashEntry () from /usr/lib/libtcl8.4.so.0
#6 0xb7922c33 in Tk_FreeColor (colorPtr=0x987cfb0)
at /tmp/tk8.4-8.4.19/unix/../generic/tkColor.c:492
#7 0xb79166cd in Tk_Free3DBorder (border=0x985b830)
at /tmp/tk8.4-8.4.19/unix/../generic/tk3d.c:440
#8 0xb7938a6e in Tk_FreeOptions (specs=0xb79df240,
widgRec=0x986f9d8 , display=0x9733c88,
needFlags=0)
at /tmp/tk8.4-8.4.19/unix/../generic/tkOldConfig.c:1039
#9 0xb79984bb in DestroyText (memPtr=0x986f9d8 )
at /tmp/tk8.4-8.4.19/unix/../generic/tkText.c:996
#10 0xb78ca115 in Tcl_EventuallyFree () from /usr/lib/libtcl8.4.so.0
#11 0xb7998bae in TextEventProc (clientData=0x986f9d8,
eventPtr=0xbfcea6bc)
at /tmp/tk8.4-8.4.19/unix/../generic/tkText.c:1270
#12 0xb7928026 in Tk_HandleEvent (eventPtr=0xbfcea6bc)
at /tmp/tk8.4-8.4.19/unix/../generic/tkEvent.c:1037
#13 0xb7945c1c in Tk_DestroyWindow (tkwin=0x987d9b0)
at /tmp/tk8.4-8.4.19/unix/../generic/tkWindow.c:1423
#14 0xb7920020 in Tk_DestroyObjCmd (clientData=0x9735210,
interp=0x961ea80, objc=2,
objv=0xbfcea910) at /tmp/tk8.4-8.4.19/unix/../generic/tkCmds.c:471
#15 0xb786e926 in TclEvalObjvInternal () from /usr/lib/libtcl8.4.so.0
#16 0xb786eb79 in Tcl_EvalObjv () from /usr/lib/libtcl8.4.so.0
#17 0xb7b7cc0d in Tkapp_Call (selfptr=0xb7c97918, args=0xb6da1e4c)
at /home/haypo/prog/py3k/Modules/_tkinter.c:1241
#18 0x0812121d in PyCFunction_Call (func=0xb7bfc6cc, arg=0xb6da1e4c,
kw=0x0)
at Objects/methodobject.c:81
#19 0x080942e4 in call_function (pp_stack=0xbfceab38, oparg=2) at
Python/ceval.c:3398
#20 0x08091027 in PyEval_EvalFrameEx (f=0x9a4f6dc, throwflag=0) at
Python/ceval.c:2205
(...)
And the Python backtrace:
(gdb) pystack
/home/haypo/prog/py3k/Lib/tkinter/__init__.py (1929): destroy
/home/haypo/prog/py3k/Lib/tkinter/__init__.py (1928): destroy
/home/haypo/prog/py3k/Lib/tkinter/__init__.py (1928): destroy
/home/haypo/prog/py3k/Lib/idlelib/WindowList.py (70): destroy
/home/haypo/prog/py3k/Lib/idlelib/EditorWindow.py (887): _close
/home/haypo/prog/py3k/Lib/idlelib/PyShell.py (260): _close
/home/haypo/prog/py3k/Lib/idlelib/FileList.py (41): open
/home/haypo/prog/py3k/Lib/idlelib/PyShell.py (1382): main
Tools/scripts/idle (5): module
So if I add the source code to the trace:
---
/home/haypo/prog/py3k/Lib/tkinter/__init__.py (1929): destroy
def destroy(self):
Destroy this and all descendants widgets.
for c in list(self.children.values()): c.destroy()
self.tk.call('destroy', self._w)
if self._name in self.master.children: ~~~ HERE
del self.master.children[self._name]
Misc.destroy(self)
/home/haypo/prog/py3k/Lib/tkinter/__init__.py (1928): destroy
def destroy(self):
Destroy this and all descendants widgets.
for c in list(self.children.values()): c.destroy()
self.tk.call('destroy', self._w) ~~~ HERE
if self._name in self.master.children:
del self.master.children[self._name]
Misc.destroy(self)
/home/haypo/prog/py3k/Lib/tkinter/__init__.py (1928): destroy
def destroy(self):
Destroy this and all descendants widgets.
for c in list(self.children.values()): c.destroy()
self.tk.call('destroy', self._w) ~~~ HERE
if self._name in self.master.children:
del self.master.children[self._name]
Misc.destroy(self)
/home/haypo/prog/py3k/Lib/idlelib/WindowList.py (70): destroy
def destroy(self):
registry.delete(self)
Toplevel.destroy(self)
# If this is Idle's last window then quit the mainloop
# (Needed for clean exit on Windows 98)
if not registry.dict: ~~~ HERE
self.quit()
/home/haypo/prog/py3k/Lib/idlelib/EditorWindow.py (887): _close
def _close(self):
(...)
self.per.close()
self.per = None
self.top.destroy()
if self.close_hook: ~~~ HERE
# unless override: unregister from flist, terminate if last
window
self.close_hook()
(...)
---
Hum, the Python line numbers are maybe invalid.
--
components: +IDLE
versions: +Python 3.0
___
Python tracker
[issue4295] closing stdout in a child process on cygwin means that process doesn't receive bytes from stdin anymore. I think.
Changes by Jean-Paul Calderone [EMAIL PROTECTED]: -- nosy: +exarkun ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4295 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4314] isalpha bug
New submission from ZooKeeper [EMAIL PROTECTED]: This may be a little tricky to recreate but here it is: q = u'абвгде' q.isalpha() True foo = u'ч' foo.isalpha() False So the Russian character u'ч' and u'ё' as well as a bunch of others is not recognized by isalpha as a alphabetic character, which it is a matter of fact. This applies to both capital and regular versions of the letters. http://en.wikipedia.org/wiki/%D0%81 http://en.wikipedia.org/wiki/Che_(Cyrillic) Using: Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on win32 -- components: Extension Modules, Unicode messages: 75820 nosy: ZooKeeper severity: normal status: open title: isalpha bug type: behavior versions: Python 2.5 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4314 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue887237] Machine integers
Mark Dickinson [EMAIL PROTECTED] added the comment: Is it be feasible to add arithmetic operations to the ctypes integer types? Since ctypes is now in the core, it would seem better to enhance ctypes than provide a new module. I think this would be valuable for rapid prototyping of an algorithm in Python before translating it into C. In particular, it might help with detecting some common C code bugs involving undefined behaviour---for example, overflow in signed-integer arithmetic. -- nosy: +marketdickinson ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue887237 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4312] Unicode in distutils meta-data?
New submission from Hagen Fürstenau [EMAIL PROTECTED]: http://docs.python.org/dev/3.0/distutils/setupscript.html#additional-meta-data says None of the string values may be Unicode.. How is this to be interpreted (or changed) w.r.t. Python 3.0? -- assignee: georg.brandl components: Documentation messages: 75816 nosy: georg.brandl, hagen severity: normal status: open title: Unicode in distutils meta-data? versions: Python 3.0 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4312 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4314] isalpha bug
Marc-Andre Lemburg [EMAIL PROTECTED] added the comment: Are you sure that you've used the right source code encoding for writing these characters ? Note that the Unicode .isalpha() method relies entirely on what the Unicode database provides as code point information. If a character is marked as not being alphanumeric (ie. is not in one of the categories 'Ll', 'Lu', 'Lt', 'Lo' or 'Lm'), it will return False. -- components: -Extension Modules nosy: +lemburg ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4314 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4314] isalpha bug
Marc-Andre Lemburg [EMAIL PROTECTED] added the comment: FWIW: I get the following in Python 2.5: print u'\u0401' Ё print u'\u0451' ё print u'\u0401'.isalpha() True print u'\u0451'.isalpha() True ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4314 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4314] isalpha bug
Marc-Andre Lemburg [EMAIL PROTECTED] added the comment: ... and for the other character: print u'\u0427' Ч print u'\u0447' ч print u'\u0427'.isalpha() True print u'\u0447'.isalpha() True Looks fine. -- resolution: - works for me status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4314 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4314] isalpha bug
STINNER Victor [EMAIL PROTECTED] added the comment:
Results on Linux:
With Python 2.7 trunk:
print(', '.join('%s:%s' % (c, c.isalpha()) for c in u'абвгдеч'))
а:True, б:True, в:True, г:True, д:True, е:True, ч:True
With Python 2.5.1:
print(', '.join('%s:%s' % (c, c.isalpha()) for c in u'абвгдеч'))
а:True, б:True, в:True, г:True, д:True, е:True, ч:True
With Python 3.0 trunk:
print(', '.join('%s:%s' % (c, c.isalpha()) for c in 'абвгдеч'))
а:True, б:True, в:True, г:True, д:True, е:True, ч:True
Are you sure that you really typed the character ч? Can you retry
using unichr(0x447).isalpha()?
Test with Python3:
print(' - '.join((r\u%04x % x) for x in range(0x400, 0x4ff+1) if
not chr(x).isalpha()))
\u0482 - \u0483 - \u0484 - \u0485 - \u0486 - \u0487 - \u0488 - \u0489
Which means that Python thinks that all unicode character in range
U+0400..U+04ff are letters except the range U+0482..U+0489 (thousands
sign ҂ to million sign ҉).
--
nosy: +haypo
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4314
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4111] Add DTrace probes
Brett Hoerner [EMAIL PROTECTED] added the comment: On Wed, Nov 12, 2008 at 9:31 PM, Skip Montanaro [EMAIL PROTECTED] wrote: I see the reference to Apple in your original post, but can't find anything related to dtrace python starting from the URL you gave. Do you have something more specific? http://www.opensource.apple.com/darwinsource/10.5.5/python-30.1.2/ That isn't Python 3.0, that's what I guess they call Python Apple Version 30? Anyways, it's their Python 2.5.1 and their patches against it are actually ed scripts, contained in fix/ That's where my patch comes from, it's just changing the .ed scripts to a patch and applying it against 2.6 At this point Jeff's code does a fair bit more than simply tracing the CALL_FUNCTION opcode but needs some work with the other CALL_FUNCTION_* opodes. It also has some obmalloc tracing which I've not yet tested. I would have thought Apple would more heavily instrument the interpreter than it appears they have. Sun has released a patch against DTrace that probes more than just function calls also. At least, it provides line number and some other information, http://cvs.opensolaris.org/source/xref//jds/spec-files/trunk/patches/Python-07-dtrace.diff I couldn't figure out why it broke the compile on OS X though, and could only get it working on Solaris. There's another problem (I think) with DTrace probes ... if the Apple guys release Apple-Probe-Python.d and the Sun guys release Sun-Probe-Python.d (just two scripts) and we setup our probes differently, one or both will fail (because one may expect a probe for foo while another expects a probe for bar). Kind of sucks, considering Sun was first and Apple chose to probe Python differently. Now we have to pick one or make a 3rd... I could be very mistaken here, though. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4111 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4314] isalpha bug
ZooKeeper [EMAIL PROTECTED] added the comment: I'll investigate it in further shortly, but for now replicating the test. print u'\u0451' ¸ print u'\u0427' × Something must be going on here. Running Win XP. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4314 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4314] isalpha bug
STINNER Victor [EMAIL PROTECTED] added the comment: $ python Python 2.5.1 (r251:54863, Jul 31 2008, 23:17:40) print u'\u0451' ё print u'\u0427' Ч @ZooKeeper: Try Python 2.6, I guess that your bug is already fixed. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4314 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4111] Add DTrace probes
Skip Montanaro [EMAIL PROTECTED] added the comment: Brett http://www.opensource.apple.com/darwinsource/10.5.5/python-30.1.2/ ... Brett http://cvs.opensolaris.org/source/xref//jds/spec-files/trunk/patches/Python-07-dtrace.diff Thanks for the pointers. I'll work on getting a uniform patch which incorporates both. (Though some of the comments in the OpenSolaris patch are a bit scary.) Brett There's another problem (I think) with DTrace probes ... if the Brett Apple guys release Apple-Probe-Python.d and the Sun guys release Brett Sun-Probe-Python.d (just two scripts) and we setup our probes Brett differently, one or both will fail (because one may expect a Brett probe for foo while another expects a probe for bar). Kind of Brett sucks, considering Sun was first and Apple chose to probe Python Brett differently. Yeah, that would suck. It would be nice if they could agree on a common set of probes. I don't know that we have any contacts within the two development communities but if we can scare some up maybe we can get them to talk to each other. :-/ Skip ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4111 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4315] On some Python builds, exec in a function can't create shadows of variables if these are declared global in another function of the same module
New submission from Silas S. Brown [EMAIL PROTECTED]:
Here's the example code:
setting1 = val1
setting2 = val2
def dummy():
global setting1
def f(x):
d ={setting1:setting1,setting2:setting2}
exec(x) in d
return d['setting1'], d['setting2']
print f(setting1=setting2='new')
Expected result: ('new', 'new')
Actual result: ('val1', 'new')
The presence of global setting1 in a different function effectively
stops a shadowed setting1 from being created by the exec.
Workaround: Add a real assignment before the exec, i.e.:
def f(x):
setting1 = 0
exec(x)
return setting1, setting2
or do the exec in a dictionary instead of in the current scope.
Observed in:
Python 2.5.1 (r251:54863, May 18 2007, 16:56:43) on Cygwin
Python 2.5.2 on 2.6.26-gentoo-r1 (by Christopher Faylor
http://www.cygwin.com/ml/cygwin/2008-11/msg00168.html )
Not observed in:
Python 2.5.1 (r251:54863, Aug 1 2008, 00:32:16) on SUSE Linux
Python 2.4.4 (#2, Apr 17 2008, 01:58:28) (Debian etch, ARM)
Python 2.5.2 (r252:60911, Jul 31 2008, 17:31:22) (Ubuntu)
--
components: None
messages: 75829
nosy: ssb22
severity: normal
status: open
title: On some Python builds, exec in a function can't create shadows of
variables if these are declared global in another function of the same module
type: behavior
versions: Python 2.5
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4315
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4295] closing stdout in a child process on cygwin means that process doesn't receive bytes from stdin anymore. I think.
Zooko O'Whielacronx [EMAIL PROTECTED] added the comment: Corinna Vinschen of cygwin requests a smaller test case: http://www.cygwin.com/ml/cygwin/2008-11/msg00166.html ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4295 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4315] On some Python builds, exec in a function can't create shadows of variables if these are declared global in another function of the same module
Silas S. Brown [EMAIL PROTECTED] added the comment:
Sorry, I accidentally posted the workaround code instead of the bug
example. This is what I should have posted:
setting1 = val1
setting2 = val2
def dummy():
global setting1
def f(x):
exec(x)
return setting1,setting2
print f(setting1='new' ; setting2='new')
Expected result: ('new', 'new')
Actual result: ('val1', 'new')
The presence of global setting1 in a different function effectively
stops a shadowed setting1 from being created by the exec.
Workaround: Add a real assignment before the exec, i.e.:
def f(x):
setting1 = 0
exec(x)
return setting1, setting2
or do the exec in a dictionary instead of in the current scope, i.e.:
def f(x):
d ={setting1:setting1,setting2:setting2}
exec(x) in d
return d['setting1'], d['setting2']
Observed in:
Python 2.5.1 (r251:54863, May 18 2007, 16:56:43) on Cygwin
Python 2.5.2 on 2.6.26-gentoo-r1 (by Christopher Faylor
http://www.cygwin.com/ml/cygwin/2008-11/msg00168.html )
Not observed in:
Python 2.5.1 (r251:54863, Aug 1 2008, 00:32:16) on SUSE Linux
Python 2.4.4 (#2, Apr 17 2008, 01:58:28) (Debian etch, ARM)
Python 2.5.2 (r252:60911, Jul 31 2008, 17:31:22) (Ubuntu)
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4315
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2996] IDLE find in files output not formatted optimally
Changes by Russell Blau [EMAIL PROTECTED]: -- versions: +Python 2.5.3, Python 2.6 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2996 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4315] On some Python builds, exec in a function can't create shadows of variables if these are declared global in another function of the same module
Changes by Amaury Forgeot d'Arc [EMAIL PROTECTED]: -- nosy: +amaury.forgeotdarc ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4315 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4111] Add DTrace probes
Brett Cannon [EMAIL PROTECTED] added the comment: On Thu, Nov 13, 2008 at 08:05, Skip Montanaro [EMAIL PROTECTED] wrote: Skip Montanaro [EMAIL PROTECTED] added the comment: Brett http://www.opensource.apple.com/darwinsource/10.5.5/python-30.1.2/ ... Brett http://cvs.opensolaris.org/source/xref//jds/spec-files/trunk/patches/Python-07-dtrace.diff Thanks for the pointers. I'll work on getting a uniform patch which incorporates both. (Though some of the comments in the OpenSolaris patch are a bit scary.) Brett There's another problem (I think) with DTrace probes ... if the Brett Apple guys release Apple-Probe-Python.d and the Sun guys release Brett Sun-Probe-Python.d (just two scripts) and we setup our probes Brett differently, one or both will fail (because one may expect a Brett probe for foo while another expects a probe for bar). Kind of Brett sucks, considering Sun was first and Apple chose to probe Python Brett differently. Yeah, that would suck. It would be nice if they could agree on a common set of probes. I don't know that we have any contacts within the two development communities but if we can scare some up maybe we can get them to talk to each other. :-/ Obviously Ronald is the Apple insider to talk to. If you want Sun, you might want to talk to Ted Leung and see who he can put you in touch with. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4111 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1699259] replacing char* with const char* in sysmodule.c/.h
Sebastian Ramacher [EMAIL PROTECTED] added the comment: At least a response, finally. * Any reason why PySys_SetPath(char *) is left out? I guess it I just missed it. * Same for PySys_SetArgv(int, char **) That one is non-trivial and requires some rewriting of PySys_SetArgv. And I didn't have the time to look into it any further. I attached an updated patch. Added file: http://bugs.python.org/file11999/sysmodule_const_char_r67215.diff ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1699259 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4111] Add DTrace probes
Ted Leung [EMAIL PROTECTED] added the comment: And courtesy of Philip Jenvey, here I am. I would *really* like to work to help make this happen. Laszlo Peter at Sun has been doing the ports of Python on Solaris, but we are not up to 2.6 just yet. I'm attaching a pointer to his patches against 2.5: http://src.opensolaris.org/source/xref/jds/spec-files/trunk/patches/Python25-07-dtrace.diff These patches include John Levon's ustack provider, which if you care about DTrace and Python, you want to have. I've also had some conversations with people at Apple, and they have agreed that they will pull DTrace probes from python.org if they got in there. That would solve the diverging probe problem. I'd love to have a discussion about DTrace probe futures for CPython -- probably on python-dev. -- nosy: +twleung ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4111 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4316] Improper use of [] in configure.in leads to useless regexp in configure
New submission from Soren jacobsen [EMAIL PROTECTED]: NetBSD/1.6[A-S] is what is desired in configure, but the wrong configure.in goop is used, so NetBSD/1.6A-S is generated instead. Apply the attached patch, commit configure.in, run autoreconf, commit configure. -- components: Build files: netbsd-configure-in.diff keywords: patch messages: 75835 nosy: snj severity: normal status: open title: Improper use of [] in configure.in leads to useless regexp in configure type: compile error Added file: http://bugs.python.org/file12000/netbsd-configure-in.diff ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4316 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1716] String format operator '%i' fails for large floats
Mark Dickinson [EMAIL PROTECTED] added the comment: I think in 2.6 we can't change this, I'm not sure when it happened, but it looks like this *was* fixed for 2.6. Closing. -- nosy: +marketdickinson resolution: - fixed status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1716 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1699259] replacing char* with const char* in sysmodule.c/.h
Alexander Belopolsky [EMAIL PROTECTED] added the comment: The new patch looks fine to me. It applies and compiles without warnings and the changes are now reflected in the docs. I guess someone would need to write a NEWS entry because it is a public API change, but otherwise I would say it should be applied. [U]nless 'C' has adopted overloading while I wasn't looking ... it's hard to imagine what kind of problems you could introduce in `C' code by changing char* to char const* that wouldn't be caught at compile-time. (Dave Abrahams in C++-sig) http://mail.python.org/pipermail/cplusplus-sig/2005-December/009562.html On Thu, Nov 13, 2008 at 2:24 PM, Sebastian Ramacher [EMAIL PROTECTED] wrote: .. * Same for PySys_SetArgv(int, char **) That one is non-trivial and requires some rewriting of PySys_SetArgv. And I didn't have the time to look into it any further. I agree and I only tossed this one in to check if you are aware of the char ** issues. I believe it was agreed at some point that changing char ** to const char ** is not a good idea (see revision 42596 reverting such change), but I could not find a clear explanation of the associated problems. In any case, +1 from me in favor of applying this patch and I will try to add Jeremy Hylton to the nosy list since he is the developer who made similar API changes in r41638 . ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1699259 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1699259] replacing char* with const char* in sysmodule.c/.h
Changes by Alexander Belopolsky [EMAIL PROTECTED]: -- nosy: +jhylton ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1699259 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1814] Victor Stinner's GMP patch for longs
STINNER Victor [EMAIL PROTECTED] added the comment: Notes: - GNU Common LISP uses CLN, which uses GMP's low-level functions (http://cvs.savannah.gnu.org/viewvc/gcl/gcl/gmp/) - GHC (Haskell compiler, http://haskell.org/ghc/) uses (or used) GMP. But Haskell is a statically typed language, where one can choose between fixed sized types like Int, and variable sized integers. (informations from the GMP mailing list) ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1814 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1699259] replacing char* with const char* in sysmodule.c/.h
Christian Heimes [EMAIL PROTECTED] added the comment: Sorry, but it's too late to apply the patch. The issues don't count as critical and it changes the API, too. Only critical and important bugs are solved during the release candidate phase of 3.0. Python 2.6 is already out. I set the target version to 2.7 and 3.1. -- stage: - patch review versions: +Python 2.7, Python 3.1 -Python 2.6 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1699259 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4317] Buffer overflow in imageop module
New submission from Amaury Forgeot d'Arc [EMAIL PROTECTED]: The interpreter sometimes segfaults when running the test suite, in test_imageop. A more reliable crasher is: import imageop s = A * 32000 imageop.rgb2rgb8(s, 1, len(s)) The failure was recently introduced by r66689, a security fix :-( and backported today in 2.4! This is a 2.4 release blocker. Patch is attached, please review. -- files: rgbcrash.diff keywords: needs review, patch messages: 75840 nosy: amaury.forgeotdarc priority: release blocker severity: normal status: open title: Buffer overflow in imageop module type: crash versions: Python 2.4, Python 2.6 Added file: http://bugs.python.org/file12001/rgbcrash.diff ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4317 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4317] Buffer overflow in imageop module
STINNER Victor [EMAIL PROTECTED] added the comment: Ooops. That's why I asked for one or more reviewers :-) -- nosy: +haypo ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4317 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4317] Buffer overflow in imageop module
Changes by Amaury Forgeot d'Arc [EMAIL PROTECTED]: Removed file: http://bugs.python.org/file12001/rgbcrash.diff ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4317 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4317] Buffer overflow in imageop module
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: Of course I uploaded the wrong patch. Trying again. Added file: http://bugs.python.org/file12002/rgbcrash.diff ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4317 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2869] Wrong doc for `calendar.Calendar.iterweekdays`
benny daon [EMAIL PROTECTED] added the comment: It confused me. Got to this URL: http://www.python.org/doc/2.5.2/lib/module-calendar.html -- nosy: +daonb ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2869 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1699259] replacing char* with const char* in sysmodule.c/.h
Alexander Belopolsky [EMAIL PROTECTED] added the comment: While technically this is an API change, in reality it is unlikely to break anyone's code because you can always pass char * to a function that expects const char* and the ABI does not change. (Also I cannot think why anyone would want to use pointers to the affected functions, which would be another potential breakage.) In any case, I am not a big proponent of const correctness, but this patch was forgotten for 1.5 years and deferring it to 2.7 and 3.1 is virtually equivalent to closing with won't fix. Is it clear that this patch is not a candidate for minor releases - 2.5.3 or 2.6.1? As I explained, it is not *really* an API change. If it is a backport candidate, I would see benefit in committing it sooner and blocking in py3k merge until 3.0 is out. On Thu, Nov 13, 2008 at 4:29 PM, Christian Heimes [EMAIL PROTECTED] wrote: Christian Heimes [EMAIL PROTECTED] added the comment: Sorry, but it's too late to apply the patch. The issues don't count as critical and it changes the API, too. Only critical and important bugs are solved during the release candidate phase of 3.0. Python 2.6 is already out. I set the target version to 2.7 and 3.1. -- stage: - patch review versions: +Python 2.7, Python 3.1 -Python 2.6 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1699259 ___ ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1699259 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1665333] Documentation missing for OptionGroup class in optparse
A.M. Kuchling [EMAIL PROTECTED] added the comment: Re-opening, since Optik is no longer externally maintained. -- assignee: - akuchling nosy: +akuchling resolution: invalid - status: closed - open title: Documentation missing for OptionGroup class in optparse - Documentation missing for OptionGroup class in optparse versions: +Python 2.7 -Python 2.4 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1665333 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4318] optparse: formatting of help text/descriptions
New submission from A.M. Kuchling [EMAIL PROTECTED]: (Copied from an anonymous submission in the Optik bug tracker.) There have been some recent discussions on comp.lang.python about the optparse/optik module, and Steve Bethard suggested you might be interested in some of the work done there. I don't know if you'd find any of this helpful for inclusion in Optik/optparse, but Steve says it's come up on your mailing list too. The problem at hand involves formatting help-strings so that they respect newlines. Simply passing formatted help-strings off to the textwrap.* methods mungs the newlines and loses them. The original thread: http://groups.google.com/group/comp.lang.python/browse_thread/thread/6df6e6 b541a15bc2/acf1d05cad60fc45?#acf1d05cad60fc45 My solution: http://groups.google.com/group/comp.lang.python/msg/09f28e26af0699b1 Dan then asked about it, and took my solution and ran with it: http://groups.google.com/group/comp.lang.python/browse_thread/thread/e72dee e779d9989b/4ec68cd2a35d52e1?hl=en#4ec68cd2a35d52e1 Feel free to do with it as you like. -- components: Library (Lib) messages: 75846 nosy: akuchling severity: normal status: open title: optparse: formatting of help text/descriptions type: feature request versions: Python 2.7 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4318 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4319] optparse and non-ascii help strings
New submission from A.M. Kuchling [EMAIL PROTECTED]: (copied from the Optik bug tracker) Related bug: http://www.mail-archive.com/python-bugs-list@python.org/msg07227.html Hi all, It seems to me that the workaround to the above bug in optparse.py versio 1.5.3 introduces a new bug when help strings are byte strings (as opposed to unicode) containing non-ascii characters. Consider the following script: $ cat test.py #!/usr/bin/env python # -*- coding:latin-1 -*- import optparse parser = optparse.OptionParser() parser.add_option(--test,help=This does not work: é) parser.parse_args() When called with $ ./test.py --help, this script fails with the following traceback: $ ./test.py -h Traceback (most recent call last): File ./test.py, line 7, in module parser.parse_args() File /usr/lib/python2.5/optparse.py, line 1385, in parse_args stop = self._process_args(largs, rargs, values) File /usr/lib/python2.5/optparse.py, line 1429, in _process_args self._process_short_opts(rargs, values) File /usr/lib/python2.5/optparse.py, line 1536, in _process_short_opts option.process(opt, value, values, self) File /usr/lib/python2.5/optparse.py, line 782, in process self.action, self.dest, opt, value, values, parser) File /usr/lib/python2.5/optparse.py, line 804, in take_action parser.print_help() File /usr/lib/python2.5/optparse.py, line 1655, in print_help file.write(self.format_help().encode(encoding, replace)) UnicodeDecodeError: 'ascii' codec can't decode byte 0xe9 in position 117: ordinal not in range(128) This behaviour can be reproduced with utf-8 encoded strings as well. If I understand correctly, line 1655 of optparse.py only works if format_help() returns an ascii byte string or a unicode string, but the call to encoding fails when it is a byte string containing non-ascii character. I think this is either a bug and should be fixed, or very misleading (and should be fixed too :). I hope to have helped even a little. Thanks for optparse, and keep up the good work! Cheers, Antoine -- components: Library (Lib) messages: 75847 nosy: akuchling severity: normal status: open title: optparse and non-ascii help strings type: behavior versions: Python 2.7 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4319 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4320] optparse: 1 2 3 should be seen as one string
New submission from A.M. Kuchling [EMAIL PROTECTED]: (copied from the Optik bug tracker -- I haven't tried to replicate this.) -- components: Library (Lib) messages: 75848 nosy: akuchling severity: normal status: open title: optparse: 1 2 3 should be seen as one string versions: Python 2.7 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4320 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4111] Add DTrace probes
Laszlo (Laca) Peter [EMAIL PROTECTED] added the comment: I'm the python package maintainer at Sun. We would really like to get the dtrace probes upstream, let me know how I can help. -- nosy: +laca ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4111 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4321] unintended syntax error with decorators, parenthesis, and dots?
New submission from Erick Tryzelaar [EMAIL PROTECTED]: I believe I found an unintentional syntax error with a combination of decorators, parenthesis, and dots. Here's a demonstration: class C: def prop(self, function): return property(function) class F: @C().prop def foo(self): return 5 Which errors out with: File foo.py, line 6 @C().prop ^ SyntaxError: invalid syntax I can't imagine why this would be desired, since these equivalent forms work: class D: def foo(self): return 5 foo = C().prop(foo) class E: c = C() @c.prop def foo(self): return 5 -- components: Interpreter Core messages: 75850 nosy: erickt severity: normal status: open title: unintended syntax error with decorators, parenthesis, and dots? type: compile error versions: Python 2.5.3, Python 3.0 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4321 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4321] unintended syntax error with decorators, parenthesis, and dots?
David W. Lambert [EMAIL PROTECTED] added the comment: Guido gets to choose. Read PEP:318 Title: Decorators for Functions and Methods and gut feeling http://mail.python.org/pipermail/python-dev/2004-August/046711.html -- nosy: +LambertDW ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4321 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4322] function with modified __name__ uses original name when there's an arg error
New submission from Erick Tryzelaar [EMAIL PROTECTED]: I ran into a case where I modified the __name__ attribute of a function and then didn't specify the right number of arguments, and I got a TypeError that used the original function name, as demonstrated here: def foo(): pass ... foo.__name__ = 'bar' foo(1) Traceback (most recent call last): File stdin, line 1, in module TypeError: foo() takes no arguments (1 given) I would have expected it to say TypeError: bar() I'm guessing that the interpreter isn't using the __name__ attribute in this case. -- components: Library (Lib) messages: 75853 nosy: erickt severity: normal status: open title: function with modified __name__ uses original name when there's an arg error type: behavior versions: Python 3.0 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4322 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4191] urlparse normalize URL path
Senthil [EMAIL PROTECTED] added the comment:
This report almost seems like a bug with urlparse, but it is not. We
have to consider certain cases here.
1) First of all, we cannot equate urlparsing, urlsplit, urljoin with
path normalization provided by posixpath.normalize. The reason is the
url syntax is strictly by RFCs which are different than Operating
system's file and directory naming syntaxes. So, the expectation that
urlparse() should return the same result as posixpath.normalize() is
wrong. What we can at most look is, does urlparse follow the guidelines
mentioned in the RFC1808 to start with and RFC3986 ( Current).
2) Secondly, in a generic sense, it is better to follow the RFC defined
parsing rules for URLS than implementing browser behavior. Because, the
urlparse needs to parse urls of other schemes also say svn+ssh where a
valid url is svn+ssh://localhost/ and in this case '' is the the
name of my directory where I have the source code. Quite possible,
right? So, it should not be converted to '/' which will be wrong.
3) And coming down to the more specific issues with the examples
presented in this report,
urlsplit considers the first '//' to follow the netloc
and a single '/' or '///' to be path '/'
urlparse.urlsplit('//')
SplitResult(scheme='', netloc='', path='', query='', fragment='')
urlparse.urlsplit('/')
SplitResult(scheme='', netloc='', path='/', query='', fragment='')
urlparse.urlsplit('///')
SplitResult(scheme='', netloc='', path='/', query='', fragment='')
Having this in mind, follow the examples you have provided:
print urlparse.urljoin('http://www.example.com///', '//')
print urlparse.urljoin('http://www.example.com///', '/')
print urlparse.urljoin('http://www.example.com///', '')
You will find that they are according the parsing and joining rules as
defined in RFC 1808 (http://www.faqs.org/rfcs/rfc1808.html)
The same is with other examples, monk.e.boy.
If you see that urlparse method has a problem, then please point me to
the section in the RFC1808/RFC3986, where it is not confirming, I shall
work on the patch to fix.
This report, is not a valid bug and can be closed.
--
nosy: +orsenthil
type: - behavior
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4191
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
