[ python-Bugs-1777160 ] Please warn about a subtle trap
Bugs item #1777160, was opened at 2007-08-19 10:25 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=1777160&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: Documentation Group: Feature Request Status: Open Resolution: None Priority: 5 Private: No Submitted By: Greg Kochanski (gpk) Assigned to: Nobody/Anonymous (nobody) Summary: Please warn about a subtle trap Initial Comment: In python, -1**2 is -1.This will horribly surprise most mathematicians or C programmers where unary - binds very tightly. Such people will expect -1**2 == 1. This problem shows up in scientific contexts, especially Numpy, where an easy way to generate an alternating string of positive and negative numbers is -1**numpy.arange(10). In this example, one expects to produce [1, -1, 1, -1, ...]. So, please put a note in the documentation warning of this problem. It can lead to subtly wrong computations. The appropriate place to put the note is in the Python Reference Manual, section 5.4, The Power operator. Please insert a final line saying: "Note: since the minus sign is not part of a numeric literal, powers of negative numeric constants need to be written with parentheses. Be aware that -1**2 == -(1**2), not (-1)**2." -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1777160&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1777168 ] Confusing typography Python Ref 5.9
Bugs item #1777168, was opened at 2007-08-19 10:40 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=1777168&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: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Greg Kochanski (gpk) Assigned to: Nobody/Anonymous (nobody) Summary: Confusing typography Python Ref 5.9 Initial Comment: In the python reference manual, section 5.9, all that stuff with italic "opa", "opb" etc reads rather poorly because of a visually confusing choice of names. The bit about "...then a opa b opb c ... y opy z opz" looks more like "aopabopbcopc...yopyzopz" : in other words a unintelligible string of gibberish. A similar problem occurs slightly below. Note that the spaces *are* really there, but they do not show up well in the italic font used on my Firefox/Debian system, so it's hard to parse. The visual confusion is exacerbated by the similarities in the operator and variable names (e.g. "opa" and "a", then "opb" then "b"), and also by the use of a three-character string to mean "operator a" versus a one-character name for the variable. So, please change "opa" to "A" et cetera, or make some other change that makes it easier to read. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1777168&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1777057 ] memoryview('test') is causing a segfault
Bugs item #1777057, was opened at 2007-08-19 03:13
Message generated for change (Comment added) made by tiran
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1777057&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 3000
>Status: Open
Resolution: Fixed
Priority: 8
Private: No
Submitted By: Christian Heimes (tiran)
Assigned to: Neal Norwitz (nnorwitz)
Summary: memoryview('test') is causing a segfault
Initial Comment:
./python -c "memoryview('test')"
Segmentation fault
I compiled Python 3.0 with
$ ./configure --with-pydebug --enable-unicode=ucs4
and
$ make EXTRA_CFLAGS="-DPy_REF_DEBUG -DPy_TRACE_REFS -DPy_DEBUG"
after a make clean; rm -rf build; svn up
I've used gdb to trace the segfault:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1210415424 (LWP 14436)]
0x080f77a0 in PyErr_SetObject (exception=0x81962c0, value=0xb7cee3a8) at
Python/errors.c:55
55 if (exception != NULL &&
--
>Comment By: Christian Heimes (tiran)
Date: 2007-08-19 14:49
Message:
Logged In: YES
user_id=560817
Originator: YES
I've found another bug:
$ ./python -c "memoryview('test')"
Fatal Python error: UNREF invalid object
Aborted
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2007-08-19 06:25
Message:
Logged In: YES
user_id=33168
Originator: NO
Committed revision 57193. This problem was due to not initializing the
new BufferError properly. Travis mentioned this in his post to
python-3000.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1777057&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1776696 ] tempfile.TemporaryFile differs between platforms
Bugs item #1776696, was opened at 2007-08-18 04:31 Message generated for change (Comment added) made by tiran You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1776696&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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Kenneth Loafman (loafman) Assigned to: Nobody/Anonymous (nobody) Summary: tempfile.TemporaryFile differs between platforms Initial Comment: When running the following: import tempfile foo=tempfile.TemporaryFile type(foo) Linux returns: Windows and Cygwin return: It should return the same across platforms, or return an undefined indication if not possible. -- Comment By: Christian Heimes (tiran) Date: 2007-08-19 14:54 Message: Logged In: YES user_id=560817 Originator: NO It's not a bug. The interface for both types are equal. Python doesn't guarantee that it uses the same types on every platform. It just guarantees that the behavior of the objects are the same on both platforms. Please study tempfile.py for detailed information. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1776696&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1751598 ] struni: str() doesn't call __str__() of subclasses of str
Bugs item #1751598, was opened at 2007-07-11 03:48
Message generated for change (Settings changed) made by tiran
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1751598&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 3000
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Christian Heimes (tiran)
Assigned to: Nobody/Anonymous (nobody)
Summary: struni: str() doesn't call __str__() of subclasses of str
Initial Comment:
In the py3k-struni branch the str() constructor doesn't use __str__ when the
argument is an instance of a subclass of str. A user defined string can't
change __str__().
It works in Python 2.5 and in the p3yk branch.
Python 3.0x (py3k-struni:56245, Jul 10 2007, 23:34:56)
[GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class Mystr(str):
... def __str__(self): return 'v'
...
>>> s = Mystr('x')
>>> s
'x'
>>> str(s)
'x' # <- SHOULD RETURN 'v'
Python 2.5.1 (r251:54863, May 2 2007, 16:56:35)
[GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class Mystr(str):
... def __str__(self): return 'v'
...
>>> s = Mystr('x')
>>> s
'x'
>>> str(s)
'v'
Python 3.0x (p3yk:56180, Jul 6 2007, 23:35:08)
[GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class Mystr(str):
... def __str__(self): return 'v'
...
>>> s = Mystr('x')
>>> s
'x'
>>> str(s)
'v'
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1751598&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1771260 ] Errors in site.py not reported properly
Bugs item #1771260, was opened at 2007-08-09 23:37 Message generated for change (Comment added) made by tiran You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1771260&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: None Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Adam Olsen (rhamphoryncus) Assigned to: Nobody/Anonymous (nobody) Summary: Errors in site.py not reported properly Initial Comment: (Ignore the p3yk dir name. This has been updated to the py3k branch.) [EMAIL PROTECTED]:~/src/python-p3yk/build$ make object : type: TypeError refcount: 4 address : 0x8239f0c lost sys.stderr make: *** [sharedmods] Error 1 The root cause is that (due to some local modifications) site.py failed to load and gave an error. This can be easily duplicated by opening up Lib/site.py:main and putting 1/0 on the first line. However, the ZeroDivisionError that should cause never gets printed. Python/pythonrun.c:initsite attempts to retrieve sys.stderr, which fails because site.py never got a chance to install it (!), then passes the NULL file object pointer to PyFile_WriteString, which turns that into a new exception (replacing the old one). initsite ignores the return value indicating the exception, instead clearing it, and the interpreter continues to load, no one the wiser. Several other exceptions may happen and get squashed, I'm not sure. Eventually, Python/sysmodule.c:sys_excepthook calls Python/pythonrun.c:PyErr_Display, which attempts to retrieve sys.stderr, and failing that calls _PyObject_Dump() on the exception (explaining the weird message). Oddly, there's a *second* if statement, which then prints the "lost sys.stderr" line. Possible remedies: 1. PyErr_Display's dump message is not very clear. 2. initsite should go directly to stderr if it can't retrieve sys.stderr. Alternatively, since site.py is now more important, it could be changed into a fatal error. Yet another option is to explicitly check for sys.stderr even on success and make that alone into a fatal error. 3. The error printing APIs could be modified to internalize the stderr retrieval. Upon failure they could print a brief "stderr unavailable; original exception was ..." message. -- Comment By: Christian Heimes (tiran) Date: 2007-08-19 15:56 Message: Logged In: YES user_id=560817 Originator: NO I run into trouble with stderr myself and I agree that the problem should be resolved somehow by falling back to the file descriptor 2 (stderr). The current implementation makes it unnecessarily hard to debug problems in site.py, io.py and possible also codecs.*. -- Comment By: Adam Olsen (rhamphoryncus) Date: 2007-08-10 20:19 Message: Logged In: YES user_id=12364 Originator: YES Following up on the possible remedies, I'm thinking PySys_WriteStderr could be extended to take file object as the first argument, and if null it writes to low-level stderr instead. That way the callers can add the message about "lost sys.stderr" themselves, rather than it being interspersed in their output. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1771260&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1777057 ] memoryview('test') is causing a segfault
Bugs item #1777057, was opened at 2007-08-18 18:13
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1777057&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 3000
>Status: Closed
Resolution: Fixed
Priority: 8
Private: No
Submitted By: Christian Heimes (tiran)
Assigned to: Neal Norwitz (nnorwitz)
Summary: memoryview('test') is causing a segfault
Initial Comment:
./python -c "memoryview('test')"
Segmentation fault
I compiled Python 3.0 with
$ ./configure --with-pydebug --enable-unicode=ucs4
and
$ make EXTRA_CFLAGS="-DPy_REF_DEBUG -DPy_TRACE_REFS -DPy_DEBUG"
after a make clean; rm -rf build; svn up
I've used gdb to trace the segfault:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1210415424 (LWP 14436)]
0x080f77a0 in PyErr_SetObject (exception=0x81962c0, value=0xb7cee3a8) at
Python/errors.c:55
55 if (exception != NULL &&
--
>Comment By: Neal Norwitz (nnorwitz)
Date: 2007-08-19 11:39
Message:
Logged In: YES
user_id=33168
Originator: NO
Committed revision 57198 fixes the problem in debug mode. Now a proper
exception is generated.
--
Comment By: Christian Heimes (tiran)
Date: 2007-08-19 05:49
Message:
Logged In: YES
user_id=560817
Originator: YES
I've found another bug:
$ ./python -c "memoryview('test')"
Fatal Python error: UNREF invalid object
Aborted
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2007-08-18 21:25
Message:
Logged In: YES
user_id=33168
Originator: NO
Committed revision 57193. This problem was due to not initializing the
new BufferError properly. Travis mentioned this in his post to
python-3000.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1777057&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1777398 ] IDLE Freezes After Running Scripts
Bugs item #1777398, was opened at 2007-08-19 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=1777398&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: Ross Peoples (deejross) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE Freezes After Running Scripts Initial Comment: IDLE freezes after running a script in a new window. I'm writing a wxPython script, which runs well until the window is closed, then IDLE freezes (shell and all open windows) and I have to kill the process. It is a tutorial script, so nothing too fancy: import wx class MyFrame(wx.Frame): def __init__(self, parent, id, title): wx.Frame.__init__(self, parent, id, title) menubar = wx.MenuBar() file = wx.Menu() edit = wx.Menu() help = wx.Menu() file.Append(101, "&New") file.Append(102, "&Open", "Open a new document") fileRecent = wx.Menu() fileRecent.Append(10301, "First Item") fileRecent.Append(10302, "Second Item") file.AppendMenu(103, "Open &Recent", fileRecent) file.Append(104, "&Save", "Save the document") file.AppendSeparator() file.Append(105, "E&xit", "Close this window") edit.Append(201, "Check 1", "Check 1 Tooltip", wx.ITEM_CHECK) edit.Append(202, "Check 2", "Check 2 Tooltip", wx.ITEM_CHECK) menubar.Append(file, "&File") menubar.Append(edit, "&Edit") menubar.Append(help, "&Help") self.SetMenuBar(menubar) self.CreateStatusBar() class MyApp(wx.App): def OnInit(self): frame = MyFrame(None, -1, "My Frame") frame.Center() frame.Show(True) return True app = MyApp(0) app.MainLoop() --- It should be noted that usually it freezes after running the script once, but sometimes I can run it a second time before it freezes IDLE. It doesn't seem to freeze using only core Python, only when using wxWidgets. Here are some versions: Ubuntu Gusty Python version 2.5.1 IDLE version 1.2.1 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1777398&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1777412 ] Python's strftime dislikes years before 1900
Bugs item #1777412, was opened at 2007-08-20 13:36
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1777412&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: Benno Rice (benno)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python's strftime dislikes years before 1900
Initial Comment:
Python 2.5 (r25:51918, Sep 19 2006, 08:49:13)
[GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import datetime
>>> datetime.date(1876, 2, 3).strftime('%Y-%m-%d')
Traceback (most recent call last):
File "", line 1, in
ValueError: year=1876 is before 1900; the datetime strftime() methods require
year >= 1900
Apparently this is due to platform-specific weirdnesses in implementations of
strftime. It is still very annoying however. Perhaps a good implementation of
strftime could be found and incorporated into Python itself?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1777412&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
