[ python-Bugs-1222459 ] Typo in section 5.3 of tutorial
Bugs item #1222459, was opened at 2005-06-17 01:50 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=1222459&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: None Status: Open Resolution: None Priority: 5 Submitted By: uman (btvincent) Assigned to: Nobody/Anonymous (nobody) Summary: Typo in section 5.3 of tutorial Initial Comment: In section 5.3 of the tutorial: As you see, on output tuples are alway enclosed in parentheses, should read: As you see, on output tuples are always enclosed in parentheses, there is an "s" missing from "always". -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1222459&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1222459 ] Typo in section 5.3 of tutorial
Bugs item #1222459, was opened at 2005-06-17 01:50 Message generated for change (Settings changed) made by btvincent You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1222459&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: None Status: Open Resolution: None >Priority: 1 Submitted By: uman (btvincent) Assigned to: Nobody/Anonymous (nobody) Summary: Typo in section 5.3 of tutorial Initial Comment: In section 5.3 of the tutorial: As you see, on output tuples are alway enclosed in parentheses, should read: As you see, on output tuples are always enclosed in parentheses, there is an "s" missing from "always". -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1222459&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1222459 ] Typo in section 5.3 of tutorial
Bugs item #1222459, was opened at 2005-06-17 03:50 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1222459&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: None >Status: Closed >Resolution: Fixed Priority: 1 Submitted By: uman (btvincent) Assigned to: Nobody/Anonymous (nobody) Summary: Typo in section 5.3 of tutorial Initial Comment: In section 5.3 of the tutorial: As you see, on output tuples are alway enclosed in parentheses, should read: As you see, on output tuples are always enclosed in parentheses, there is an "s" missing from "always". -- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-17 05:28 Message: Logged In: YES user_id=80475 Fixed. Thanks for the report. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1222459&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1222235 ] Bad optparse help wrapping with multiple paragraphs
Bugs item #135, was opened at 2005-06-16 17:18 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=135&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) >Assigned to: Greg Ward (gward) Summary: Bad optparse help wrapping with multiple paragraphs Initial Comment: If the help text for an option consists of multiple paragraphs, optparse wraps all the paragraphs into one big mess when --help is used. optparse should really split the text by paragraphs and fill each individual paragraph. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=135&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1163563 ] Sub threads execute in restricted mode
Bugs item #1163563, was opened at 2005-03-15 09:56 Message generated for change (Comment added) made by yetanothermax You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163563&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: Threads Group: Python 2.4 Status: Open Resolution: None Priority: 8 Submitted By: anothermax (yetanothermax) Assigned to: Nobody/Anonymous (nobody) Summary: Sub threads execute in restricted mode Initial Comment: I'm using the JEP product which allows integration of Java with Python (see http://jepp.sourceforge.net) via starting a Python interpreter in the same process as the JVM. This integrates with python via the C interface, allowing the user to 'eval' python code (amongst other features). It seems that since Python 2.3.5 any threads (using the threading module) created via code that has been evaluated through the jep.eval() interface (i.e.Python C interface )are executed in restricted mode and cannot, for example, create files. Code that is just evaled (i.e not in a subthread) thread has no restrictions. The error reported is: IOError: file() constructor not accessible in restricted mode (see http://sourceforge.net/forum/forum.php? thread_id=1247793&forum_id=376782) - I've given a JEP specific example here. There seems to be a similar problem with mod_python (see http://www.modpython.org/pipermail/mod_python/2005- January/017129.html) Reading through the release notes for Python 2.3.5 I see: Bug #754449: threading.Thread will no longer mask exceptions raised during interpreter shutdown with another exception caused by attempting to output the initial exception. This fix also includes a backport of rev. 1.41 from HEAD. This might be the problem as it seems to involve the porting of 2.4 threading code back to the 2.3 tree. I've attached a Java file which shows the problem when using JEP. The error output is: Exception in thread Thread-1: Traceback (most recent call last): File "C:\Python24\Lib\threading.py", line 442, in __bootstrap File "", line 5, in run IOError: file() constructor not accessible in restricted mode 2.4.1c1 (#63, Mar 10 2005, 10:36:41) [MSC v.1310 32 bit (Intel)] Creating file from main thread... Done Creating file from sub thread... Done -- >Comment By: anothermax (yetanothermax) Date: 2005-06-17 12:35 Message: Logged In: YES user_id=1218811 Good news - I've made a couple of tests and the patch seems to fix the problem. With regards to the earlier patch: - apologies for not running the test suite - I feel suitably chastised :) & I'll be sure to run it in the future. - I did note that it would probably re-raise #1010677 (see 2005-04-20 13:51 comment) but guessed it was more important to contribute the patch so that someone who has better thread implementation knowledge could look into it... -- Comment By: Michael Hudson (mwh) Date: 2005-06-16 14:39 Message: Logged In: YES user_id=6656 So here's my take on a fix to 1010677, relative to CVS HEAD. It's something of a hack, and I certainly wouldn't condone applying it to the trunk as is but I would be interested in hearing if it fixes your problems. (after applying your patch the test suite failed to complete, btw -- please try this yourself next time :) -- Comment By: Michael Hudson (mwh) Date: 2005-06-16 14:09 Message: Logged In: YES user_id=6656 (Grr, SF hates me today) Why, are you under the impression that that could make a difference here? (hint: it can't). The problem with Py_NewInterpreter was an over-zealous check in PythreadState_Swap(), which I've tweaked. A red herring. On to the real problem... I see the problem, and can now reproduce it with your test code, but isn't your patch just a reversion of the patch that was attached to bug #1010677? Why won't applying it bring that patch back? -- Comment By: anothermax (yetanothermax) Date: 2005-06-16 13:32 Message: Logged In: YES user_id=1218811 Have you tried the threadtest.c with a debug build after applying the patch to threadmodule.c? The patch is here http://sourceforge.net/tracker/index.php? func=detail&aid=1203393&group_id=5470&atid=305470 Cheers, Max -- Comment By: Michael Hudson (mwh) Date: 2005-06-16 11:58 Message: Logged In: YES user_id=6656 Hmm. threadtest.c just crashed for me with a debug build: Fatal Python error: Invalid thread state for this thread Abort trap This is in the call to Py_NewInterpreter() ... (eek). --
[ python-Bugs-1163563 ] Sub threads execute in restricted mode
Bugs item #1163563, was opened at 2005-03-15 08:56 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163563&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: Threads Group: Python 2.4 Status: Open Resolution: None Priority: 8 Submitted By: anothermax (yetanothermax) >Assigned to: Tim Peters (tim_one) Summary: Sub threads execute in restricted mode Initial Comment: I'm using the JEP product which allows integration of Java with Python (see http://jepp.sourceforge.net) via starting a Python interpreter in the same process as the JVM. This integrates with python via the C interface, allowing the user to 'eval' python code (amongst other features). It seems that since Python 2.3.5 any threads (using the threading module) created via code that has been evaluated through the jep.eval() interface (i.e.Python C interface )are executed in restricted mode and cannot, for example, create files. Code that is just evaled (i.e not in a subthread) thread has no restrictions. The error reported is: IOError: file() constructor not accessible in restricted mode (see http://sourceforge.net/forum/forum.php? thread_id=1247793&forum_id=376782) - I've given a JEP specific example here. There seems to be a similar problem with mod_python (see http://www.modpython.org/pipermail/mod_python/2005- January/017129.html) Reading through the release notes for Python 2.3.5 I see: Bug #754449: threading.Thread will no longer mask exceptions raised during interpreter shutdown with another exception caused by attempting to output the initial exception. This fix also includes a backport of rev. 1.41 from HEAD. This might be the problem as it seems to involve the porting of 2.4 threading code back to the 2.3 tree. I've attached a Java file which shows the problem when using JEP. The error output is: Exception in thread Thread-1: Traceback (most recent call last): File "C:\Python24\Lib\threading.py", line 442, in __bootstrap File "", line 5, in run IOError: file() constructor not accessible in restricted mode 2.4.1c1 (#63, Mar 10 2005, 10:36:41) [MSC v.1310 32 bit (Intel)] Creating file from main thread... Done Creating file from sub thread... Done -- >Comment By: Michael Hudson (mwh) Date: 2005-06-17 13:10 Message: Logged In: YES user_id=6656 That's good to hear. Tim: could you glance over the attached? If you can't be assed to read all the various reports, I've attempted to summarise the problem(s) here: http://mail.python.org/pipermail/python-dev/2005-June/054258.html If you don't have time, please at least say so... yetanothermax: thanks for the confirmation. Could you also try this cleaner version of the patch? Wrt your patch, it took me too long to work out that it was simply unapplying the earlier changes -- and you don't need to supply a patch for that, even creaky old CVS makes *that* easy :) -- Comment By: anothermax (yetanothermax) Date: 2005-06-17 11:35 Message: Logged In: YES user_id=1218811 Good news - I've made a couple of tests and the patch seems to fix the problem. With regards to the earlier patch: - apologies for not running the test suite - I feel suitably chastised :) & I'll be sure to run it in the future. - I did note that it would probably re-raise #1010677 (see 2005-04-20 13:51 comment) but guessed it was more important to contribute the patch so that someone who has better thread implementation knowledge could look into it... -- Comment By: Michael Hudson (mwh) Date: 2005-06-16 13:39 Message: Logged In: YES user_id=6656 So here's my take on a fix to 1010677, relative to CVS HEAD. It's something of a hack, and I certainly wouldn't condone applying it to the trunk as is but I would be interested in hearing if it fixes your problems. (after applying your patch the test suite failed to complete, btw -- please try this yourself next time :) -- Comment By: Michael Hudson (mwh) Date: 2005-06-16 13:09 Message: Logged In: YES user_id=6656 (Grr, SF hates me today) Why, are you under the impression that that could make a difference here? (hint: it can't). The problem with Py_NewInterpreter was an over-zealous check in PythreadState_Swap(), which I've tweaked. A red herring. On to the real problem... I see the problem, and can now reproduce it with your test code, but isn't your patch just a reversion of the patch that was attached to bug #1010677? Why won't applying it bring that patch back? ---
[ python-Bugs-1163563 ] Sub threads execute in restricted mode
Bugs item #1163563, was opened at 2005-03-15 09:56 Message generated for change (Comment added) made by yetanothermax You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163563&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: Threads Group: Python 2.4 Status: Open Resolution: None Priority: 8 Submitted By: anothermax (yetanothermax) Assigned to: Tim Peters (tim_one) Summary: Sub threads execute in restricted mode Initial Comment: I'm using the JEP product which allows integration of Java with Python (see http://jepp.sourceforge.net) via starting a Python interpreter in the same process as the JVM. This integrates with python via the C interface, allowing the user to 'eval' python code (amongst other features). It seems that since Python 2.3.5 any threads (using the threading module) created via code that has been evaluated through the jep.eval() interface (i.e.Python C interface )are executed in restricted mode and cannot, for example, create files. Code that is just evaled (i.e not in a subthread) thread has no restrictions. The error reported is: IOError: file() constructor not accessible in restricted mode (see http://sourceforge.net/forum/forum.php? thread_id=1247793&forum_id=376782) - I've given a JEP specific example here. There seems to be a similar problem with mod_python (see http://www.modpython.org/pipermail/mod_python/2005- January/017129.html) Reading through the release notes for Python 2.3.5 I see: Bug #754449: threading.Thread will no longer mask exceptions raised during interpreter shutdown with another exception caused by attempting to output the initial exception. This fix also includes a backport of rev. 1.41 from HEAD. This might be the problem as it seems to involve the porting of 2.4 threading code back to the 2.3 tree. I've attached a Java file which shows the problem when using JEP. The error output is: Exception in thread Thread-1: Traceback (most recent call last): File "C:\Python24\Lib\threading.py", line 442, in __bootstrap File "", line 5, in run IOError: file() constructor not accessible in restricted mode 2.4.1c1 (#63, Mar 10 2005, 10:36:41) [MSC v.1310 32 bit (Intel)] Creating file from main thread... Done Creating file from sub thread... Done -- >Comment By: anothermax (yetanothermax) Date: 2005-06-17 16:37 Message: Logged In: YES user_id=1218811 The maybe-even-better-1010677-fix also seems to work -- Comment By: Michael Hudson (mwh) Date: 2005-06-17 14:10 Message: Logged In: YES user_id=6656 That's good to hear. Tim: could you glance over the attached? If you can't be assed to read all the various reports, I've attempted to summarise the problem(s) here: http://mail.python.org/pipermail/python-dev/2005-June/054258.html If you don't have time, please at least say so... yetanothermax: thanks for the confirmation. Could you also try this cleaner version of the patch? Wrt your patch, it took me too long to work out that it was simply unapplying the earlier changes -- and you don't need to supply a patch for that, even creaky old CVS makes *that* easy :) -- Comment By: anothermax (yetanothermax) Date: 2005-06-17 12:35 Message: Logged In: YES user_id=1218811 Good news - I've made a couple of tests and the patch seems to fix the problem. With regards to the earlier patch: - apologies for not running the test suite - I feel suitably chastised :) & I'll be sure to run it in the future. - I did note that it would probably re-raise #1010677 (see 2005-04-20 13:51 comment) but guessed it was more important to contribute the patch so that someone who has better thread implementation knowledge could look into it... -- Comment By: Michael Hudson (mwh) Date: 2005-06-16 14:39 Message: Logged In: YES user_id=6656 So here's my take on a fix to 1010677, relative to CVS HEAD. It's something of a hack, and I certainly wouldn't condone applying it to the trunk as is but I would be interested in hearing if it fixes your problems. (after applying your patch the test suite failed to complete, btw -- please try this yourself next time :) -- Comment By: Michael Hudson (mwh) Date: 2005-06-16 14:09 Message: Logged In: YES user_id=6656 (Grr, SF hates me today) Why, are you under the impression that that could make a difference here? (hint: it can't). The problem with Py_NewInterpreter was an over-zealous check in PythreadState_Swap(), which I've tweaked. A red herring. On to the real problem... I see the proble
[ python-Bugs-1222721 ] tk + setlocale problems...
Bugs item #1222721, was opened at 2005-06-17 19:23 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=1222721&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: Tkinter Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Alex A. Naanou (alex_nanou) Assigned to: Martin v. Löwis (loewis) Summary: tk + setlocale problems... Initial Comment: Description: when using both the tkinter GUI and the locale.setlocale (locale.LC_ALL, '') call on Py2.4, the following error is printed to stderr: error reading package index file /usr/share/tcl/vfs1.3/pkgIndex.tcl: syntax error in expression "[package provide Tcl] < 8.4": extra tokens at end of expression in addition to this, the BackSpace key appears not to be handled by the tk input widgets (for example "Entry") after the setlocale call. in Py2.4.1 the error is no longer printed, though the problem with the BS key persists. Testcase: see attached file. --- Originally posted to ALTLinux bugtracker (original text (Russian): https://bugzilla.altlinux.org/show_bug.cgi? id=6339) --- additionally tested on: Py2.4.1 (builds for win32, cygwin, debian linux) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1222721&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1222790 ] SimpleXMLRPCServer does not set FD_CLOEXEC
Bugs item #1222790, was opened at 2005-06-17 19:18 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=1222790&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: Demos and Tools Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Winfried Harbecke (wharbecke) Assigned to: Nobody/Anonymous (nobody) Summary: SimpleXMLRPCServer does not set FD_CLOEXEC Initial Comment: The SimpleXMLRPCServer constructor does not set FD_CLOEXEC on the socket that listens for new connections. When the XML RPC server spawns other daemons, and the XML RPC server is stopped before the spawned daemon dies, the spawned daemon will hog the inherited socket and the XML RPC server will be unable to open its listening socket again (ADDR_IN_USE). Since there is no reason why a spawned process should inherit the listen socket, the close-on-exec flag should be used to prevent inheriting the socket to spawned processes. import socket + import fcntl import xmlrpclib ... def __init__(self, addr, ... SocketServer.TCPServer.__init__(self, addr, requestHandler) ! # close on exec - spawned shell should not access the service ! # listen socket ! flags = fcntl.fcntl(self.fileno(), fcntl.F_GETFD) ! flags |= fcntl.FD_CLOEXEC ! fcntl.fcntl(self.fileno(), fcntl.F_SETFD, flags) ! There is a similar fix in the Zope distribution, see http://archives.free.net.ph/message/20030719.201708.f3a aed4d.html -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1222790&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1221424 ] buffer() object broken.
Bugs item #1221424, was opened at 2005-06-15 11:17
Message generated for change (Comment added) made by rjs_org
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1221424&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Ray Schumacher (rjs_org)
Assigned to: Neil Schemenauer (nascheme)
Summary: buffer() object broken.
Initial Comment:
Same as:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1033720&group_id=5470:
Still broken in 2.4.1...!
C:\projects\temp\fftw>python
ActivePython 2.4.1 Build 245 (ActiveState Corp.) based on
Python 2.4.1 (#65, Mar 30 2005, 09:33:37) [MSC v.1310
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for
more information.
>>> import Numeric
>>> i = Numeric.zeros(8)
>>> repr(buffer(i))
''
>>> repr(buffer(""))
''
(Numeric v23.8)
--
>Comment By: Ray Schumacher (rjs_org)
Date: 2005-06-17 10:31
Message:
Logged In: YES
user_id=287034
repr(buffer("")) used to return:
now returns:
>>> repr(buffer(""))
''
same as:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1033720&group_id=5470
--
Comment By: Neil Schemenauer (nascheme)
Date: 2005-06-16 11:49
Message:
Logged In: YES
user_id=35752
Please explain exactly what you think is broken about the
buffer object.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1221424&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1221424 ] buffer() object broken.
Bugs item #1221424, was opened at 2005-06-15 18:17
Message generated for change (Comment added) made by nascheme
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1221424&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Ray Schumacher (rjs_org)
Assigned to: Neil Schemenauer (nascheme)
Summary: buffer() object broken.
Initial Comment:
Same as:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1033720&group_id=5470:
Still broken in 2.4.1...!
C:\projects\temp\fftw>python
ActivePython 2.4.1 Build 245 (ActiveState Corp.) based on
Python 2.4.1 (#65, Mar 30 2005, 09:33:37) [MSC v.1310
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for
more information.
>>> import Numeric
>>> i = Numeric.zeros(8)
>>> repr(buffer(i))
''
>>> repr(buffer(""))
''
(Numeric v23.8)
--
>Comment By: Neil Schemenauer (nascheme)
Date: 2005-06-17 17:52
Message:
Logged In: YES
user_id=35752
The repr of a buffer() object has indeed changed. I don't
see how that's a bug though.
--
Comment By: Ray Schumacher (rjs_org)
Date: 2005-06-17 17:31
Message:
Logged In: YES
user_id=287034
repr(buffer("")) used to return:
now returns:
>>> repr(buffer(""))
''
same as:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1033720&group_id=5470
--
Comment By: Neil Schemenauer (nascheme)
Date: 2005-06-16 18:49
Message:
Logged In: YES
user_id=35752
Please explain exactly what you think is broken about the
buffer object.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1221424&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1221424 ] buffer() object broken.
Bugs item #1221424, was opened at 2005-06-15 11:17
Message generated for change (Comment added) made by rjs_org
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1221424&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Ray Schumacher (rjs_org)
Assigned to: Neil Schemenauer (nascheme)
Summary: buffer() object broken.
Initial Comment:
Same as:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1033720&group_id=5470:
Still broken in 2.4.1...!
C:\projects\temp\fftw>python
ActivePython 2.4.1 Build 245 (ActiveState Corp.) based on
Python 2.4.1 (#65, Mar 30 2005, 09:33:37) [MSC v.1310
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for
more information.
>>> import Numeric
>>> i = Numeric.zeros(8)
>>> repr(buffer(i))
''
>>> repr(buffer(""))
''
(Numeric v23.8)
--
>Comment By: Ray Schumacher (rjs_org)
Date: 2005-06-17 12:04
Message:
Logged In: YES
user_id=287034
In 2.3, the actual adress of the first element of an array
could be parsed for doing a memmove(), and now, not, which
breaks some older code. If this is a "more Pythonic"
feature, then OK; the previous resolution said "Fixed in
bufferobject.c 2.25." without remark. I assumed that it had
been restored to the previous.
I now have:
ptr = tpcnv[a.typecode()]()
pythonapi.PyObject_AsReadBuffer(py_object(a),
byref(ptr),
byref(c_int()))
ptr.refed_array = a
instead of:
split(repr(buffer(a)))[5][:-1]
to get/use an address with ctypes...
--
Comment By: Neil Schemenauer (nascheme)
Date: 2005-06-17 10:52
Message:
Logged In: YES
user_id=35752
The repr of a buffer() object has indeed changed. I don't
see how that's a bug though.
--
Comment By: Ray Schumacher (rjs_org)
Date: 2005-06-17 10:31
Message:
Logged In: YES
user_id=287034
repr(buffer("")) used to return:
now returns:
>>> repr(buffer(""))
''
same as:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1033720&group_id=5470
--
Comment By: Neil Schemenauer (nascheme)
Date: 2005-06-16 11:49
Message:
Logged In: YES
user_id=35752
Please explain exactly what you think is broken about the
buffer object.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1221424&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1222928 ] it's -> its
Bugs item #1222928, was opened at 2005-06-17 14:57 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=1222928&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.3 Status: Open Resolution: None Priority: 5 Submitted By: Ed Swierk (eswierk) Assigned to: Nobody/Anonymous (nobody) Summary: it's -> its Initial Comment: These are not earth-shattering bugs, but for the sake of my obsessiveness... "it's" should be changed to "its" in each of these instances: ref/id-classes.html: and it's implementation (including the standard library); mac/module-FrameWork.html:that shouldn't be difficult), that it's dialog support is minimal and mac/module-FrameWork.html:that it's control/toolbar support is non-existent. api/common-structs.html: that it's own expansion varies depending on the definition of api/instanceObjects.html: Create a new instance of a specific class without calling it's doc/inline-markup.html: be used for simple constant definitions. Examples of it's use doc/info-units.html: be used for simple constant definitions. Examples of it's use lib/module-cgitb.html:scripts. (It's name is a bit misleading. It was originally designed to -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1222928&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1222978 ] 2.4.1 .msi file won't install to different disk
Bugs item #1222978, was opened at 2005-06-17 16:57 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=1222978&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: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ray Trent (hacksoncode) Assigned to: Nobody/Anonymous (nobody) Summary: 2.4.1 .msi file won't install to different disk Initial Comment: I just downloaded and tried to install 2.4.1 for Windows. I downloaded the .msi file to f:\rat\stuff. When I tried to install it (selecting the default install dir of c:\Python24), MSI error messages appeared claiming that it couldn't read from the MSI file. Moving the .msi file to c:\swtools and installing from there worked. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1222978&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1222978 ] 2.4.1 .msi file won't install to different disk
Bugs item #1222978, was opened at 2005-06-17 16:57 Message generated for change (Comment added) made by hacksoncode You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1222978&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: Installation Group: Python 2.4 >Status: Closed Resolution: None Priority: 5 Submitted By: Ray Trent (hacksoncode) Assigned to: Nobody/Anonymous (nobody) Summary: 2.4.1 .msi file won't install to different disk Initial Comment: I just downloaded and tried to install 2.4.1 for Windows. I downloaded the .msi file to f:\rat\stuff. When I tried to install it (selecting the default install dir of c:\Python24), MSI error messages appeared claiming that it couldn't read from the MSI file. Moving the .msi file to c:\swtools and installing from there worked. -- >Comment By: Ray Trent (hacksoncode) Date: 2005-06-17 17:06 Message: Logged In: YES user_id=691303 Hmmm. This seems to be a problem with my MSI. Or at least the MySQL .msi file has the same issue. Closing. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1222978&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
