[issue10181] Problems with Py_buffer management in memoryobject.c (and elsewhere?)
Lenard Lindstrom added the comment: Using Python reference counting and the garbage collector to control when PyBuffer_Release is called has problems. First, it assumes the CPython interpreter will always use reference counting. Second, PyBuffer_Release may never get called if circular references exist. Third, an exception could keep a memoryview object alive in a traceback, delaying the PyBuffer_Release call. Finally, it does not play well with the memoryview __enter__, __exit__, and release methods. It makes Python level context management pointless; instead, just del the memoryview instance and hope the garbage collector cooperates. For the old buffer protocol and the Numpy array interface, resources have to be released in an object's destructor at garbage collection time. There is no other choice. If that also becomes the case for the new buffer protocol, then there is little incentive to migrate to it. -- ___ Python tracker <http://bugs.python.org/issue10181> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10181] Problems with Py_buffer management in memoryobject.c (and elsewhere?)
Lenard Lindstrom added the comment: It would if the proposed PyManagedBuffer only releases the Py_buffer struct - calls PyBuffer_Release - when its Python reference count goes to zero. So a separate reference count will be maintained instead. -- ___ Python tracker <http://bugs.python.org/issue10181> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10181] Problems with Py_buffer management in memoryobject.c (and elsewhere?)
Changes by Lenard Lindstrom : -- nosy: -kermode ___ Python tracker <http://bugs.python.org/issue10181> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1800] ctypes callback fails when called in Python with array argument
Lenard Lindstrom added the comment: I will check it out. -- ___ Python tracker <http://bugs.python.org/issue1800> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1800] ctypes callback fails when called in Python with array argument
Lenard Lindstrom added the comment: I have checked over the proposed patch and made a small change that more elegantly obtains PyCArrayType. Decaying arrays into pointers is not an ideal solution. Ctypes arrays have bounds checking (pointers do not) adding an extra margin of safety when a C function prototype has sized arrays in the declaration. But this is a rare case. So the proposed patch is good enough. The alternative is to reject arrays as arguments altogether, with CFUNCTYPE raising an exception if one is found. The problem lies with line 1241 in _ctypes.c and line 221 in callbacks.c (r84925 or py3k). In the first case, the value of CDataObject.b_ptr is assigned to PyCArgObject.value.p. In the second case PyCArgObject.value.p (*pArgs) is recovered to *CDataObject.b_ptr. I see no way to fix this without changes to several functions and files. -- Added file: http://bugs.python.org/file18938/issue1800.diff ___ Python tracker <http://bugs.python.org/issue1800> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9602] PyObject_AsCharBuffer() should only accept read-only objects
Lenard Lindstrom added the comment: PEP 3118 """ Rationale ... 3) There is no way for a consumer to tell the buffer-API-exporting object it is "finished" with its view of the memory and therefore no way for the exporting object to be sure that it is safe to reallocate the pointer to the memory that it owns (for example, the array object reallocating its memory after sharing it with the buffer object which held the original pointer led to the infamous buffer-object problem). """ Let's consider Pygame, and the SDL surface it wraps as a pygame.Surface. Pygame exposes a surface's data through the buffer protocol for manipulation by a NumPy array. Now some SDL surfaces need locking before accessing, so Pygame will lock the surface for the lifetime of the consumer array. How is the surface unlocked when the array is reclaimed? By a buffer proxy that is owned by the array. The proxy unlocks the surface when the proxy is garbage collected. The new buffer protocol suggests a simpler way, equivalent to contexts, but only if the buffer release mechanism works as advertised. This promise is broken when a consumer calls PyBuffer_Release before it is done with the buffer. All the questionable buffer api functions use the PyBUF_SIMPLE access flag. So I suggest a PyBUF_SIMPLE access request requires a returned buffer to remain valid for the lifetime of the exporter, not the Py_buffer view. If an exporter cannot honor this request, due to locking requirements for instance, then it raises an exception. All other access request flags promise that PyBuffer_Release, and therefore bf_releasebuffer, is called only when the buffer is released, not before. -- nosy: +kermode ___ Python tracker <http://bugs.python.org/issue9602> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9602] PyObject_AsCharBuffer() should only accept read-only objects
Lenard Lindstrom added the comment: >I don't know why you're saying that. The purpose of PyBuffer_Release is >precisely to solve these kinds of use cases (where you want timely >release of a resource rather than rely on the garbage collector). Yes, I was unclear. This refers to Python 3.2, not the 2.x series. PyObject_AsReadBuffer (defined at line 270 in abstract.c, code of routine attached) calls bf_getbuffer with the PyBUF_SIMPLE flag to retrieve a bytes buffer. It then calls bf_releasebuffer before returning the buffer to the caller. PyObject_AsCharBuffer and PyObject_AsWriteBuffer do the same. It is not be exactly the same issue discussed so far, but is closely related. Deprecating PyObject_AsReadBuffer is extreme, and doesn't solve the early release problem. Redefining the PyBUF_SIMPLE flag to be like the old buffer protocol warns those implementing a new buffer interface to avoid processing PyBUF_SIMPLE requests when locking is required. -- Added file: http://bugs.python.org/file19048/PyObject_AsReadBuffer.c ___ Python tracker <http://bugs.python.org/issue9602> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9602] PyObject_AsCharBuffer() should only accept read-only objects
Lenard Lindstrom added the comment: That is perfectly fine with me. -- ___ Python tracker <http://bugs.python.org/issue9602> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9990] PyMemoryView_FromObject alters the Py_buffer after calling PyObject_GetBuffer when ndim 1
New submission from Lenard Lindstrom : If an exporter returns a Py_buffer with ndim 1, PyMemoryView_FromObject changes the shape and strides pointer fields to point to a local Py_buffer array field. This array field is undocumented. Any heap memory these pointers reference is lost. Should the exporter's bf_releasebuffer later try and free the memory, the Python interpreter may segfault. Attached is a demonstration program. Its output is: Accessing buffer directly... Accessing buffer through a memory view... * View->shape has changed. Done. where the third line shows bf_releasebuffer has detected a changed pointer. -- components: Interpreter Core files: bufrel.c.gz messages: 117644 nosy: kermode priority: normal severity: normal status: open title: PyMemoryView_FromObject alters the Py_buffer after calling PyObject_GetBuffer when ndim 1 type: crash versions: Python 3.2 Added file: http://bugs.python.org/file19060/bufrel.c.gz ___ Python tracker <http://bugs.python.org/issue9990> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10001] ~Py_buffer.obj field is undocumented, though not hidden
New submission from Lenard Lindstrom : Python 3.2a2+ (py3k:85072M, Sep 29 2010, 12:11:17) (from SVN) [GCC 4.4.5 20100728 (prerelease)] on linux2 (Debian squeeze) The ~Py_buffer.obj field is undocumented. Yet memoryview, that acts as a wrapper, includes the field in gc traversal. Also, if the field is not initialized by bf_getbuffer its value can be indeterminate. For memoryview the gc can crash (see attached C demo program). -- components: Interpreter Core files: bufobj.c.gz messages: 117754 nosy: kermode priority: normal severity: normal status: open title: ~Py_buffer.obj field is undocumented, though not hidden versions: Python 3.2 Added file: http://bugs.python.org/file19069/bufobj.c.gz ___ Python tracker <http://bugs.python.org/issue10001> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10001] ~Py_buffer.obj field is undocumented, though not hidden
Lenard Lindstrom added the comment: This will work for bf_getbuffer, though having PyObject_GetBuffer set the obj field before passing it to the callback might be safer. Also, this does not address the case with wrapper types like memoryview. What happens if ~Py_buffer.obj is not visited in tp_traverse? Should this be documented? -- ___ Python tracker <http://bugs.python.org/issue10001> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9990] PyMemoryView_FromObject alters the Py_buffer after calling PyObject_GetBuffer when ndim 1
Lenard Lindstrom added the comment: Applied patch to: Python 3.2a2+ (py3k:85150M, Oct 1 2010, 14:40:33) [GCC 4.4.5 20100728 (prerelease)] on linux2 Python unit test test_capi.py crashes: internal test_broken_memoryview * ob object : type: str refcount: 0 address : 0xb7171178 * op->_ob_prev->_ob_next object : type: str refcount: 0 address : 0xb7171178 * op->_ob_next->_ob_prev object : Segmentation fault Pygame unit tests pass (segfaults without the patch). bufrel.c test passes. numpy 1.5.0 unit tests not run since they rely on a package that needs porting to Python 3.x. A memory view is used to manage an object whose buffer a numpy array exposes. This was where the Pygame unit test seqfault occurred. The patch fixes the problem with Pygame. Thanks. -- ___ Python tracker <http://bugs.python.org/issue9990> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10181] Problems with Py_buffer management in memoryobject.c (and elsewhere?)
Changes by Lenard Lindstrom : -- nosy: +kermode ___ Python tracker <http://bugs.python.org/issue10181> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9990] PyMemoryView_FromObject alters the Py_buffer after calling PyObject_GetBuffer when ndim 1
Lenard Lindstrom added the comment: I think only a simple solution is needed. From my experience adding the new buffer protocol to pygame.mixer.Sound it would be easy enough for bf_releasebuffer to use the "internal" field to free memory allocated by bf_getbuffer. As long as this pointer is preserved it would not matter if Py_buffer is copied or the "shape" and "strides" pointers change. Just ensure Py_buffer is clearly documented. -- ___ Python tracker <http://bugs.python.org/issue9990> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3440] Starting Python as a subprocess fails when subprocess.Popen has env argument
New submission from Lenard Lindstrom <[EMAIL PROTECTED]>:
Python 2.6b2 (r26b2:65106, Jul 18 2008, 18:22:27) [MSC v.1500 32 bit
(Intel)] on win32
Windows XP Professional, SP 2
Library class subprocess.Popen
When subprocess.Popen is used to start the python interpreter as a
subprocess with a custom environment, env is set to a mapping, the
subprocess terminates with the following pop-up error dialog:
"The application failed to initialize properly (0xc0150004). Click on OK
to terminate the application."
The attached fail.py program reproduces the bug. It should print "ABCDE"
if successful. It does for Pythons 2.4 and 2.5.
The reason is that Python 2.6 on Windows requires the environment
variable SystemRoot, which it cannot find. This is demonstrated by
modifying fail.py to include SystemRoot in the environment. This works:
import sys
import os
import subprocess
command = ('''%s -c "import os; print os.environ['YAHOO']"''' %
sys.executable)
env = {"YAHOO": "ABCDE", "SystemRoot": os.environ["SystemRoot"]}
subprocess.Popen(command, env=env).wait()
--
components: Library (Lib), Windows
files: fail.py
messages: 70225
nosy: kermode
severity: normal
status: open
title: Starting Python as a subprocess fails when subprocess.Popen has env
argument
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file10970/fail.py
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3440>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1800] ctypes callback fails when called in Python with array argument
New submission from Lenard Lindstrom: When a callback is created with an array argument and then is called from Python the callback function receives an array full of garbage. Here is an example: Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> from ctypes import * >>> A = c_int * 1 >>> A >>> Foo = CFUNCTYPE(None, A) >>> def py_foo(a): ... print a ... print a[0] ... >>> foo = Foo(py_foo) >>> foo(A(42)) <__main__.c_long_Array_1 object at 0x00B54440> 11879448 It works correctly when the callback is declared with a pointer argument instead: >>> A = c_int * 1 >>> Foo = CFUNCTYPE(None, POINTER(c_int)) >>> def py_foo(p): ... print p ... print p[0] ... >>> foo = Foo(py_foo) >>> foo(A(42)) 42 -- components: Library (Lib), Windows messages: 59759 nosy: kermode severity: normal status: open title: ctypes callback fails when called in Python with array argument type: behavior versions: Python 2.5 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1800> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2056] install command rejects --compiler option
New submission from Lenard Lindstrom: The install command returns the following error when the --compiler option is provided on the command line: >python setup.py install --compiler=mingw32 usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...] or: setup.py --help [cmd1 cmd2 ...] or: setup.py --help-commands or: setup.py cmd --help error: option --compiler not recognized This is problematic on Windows when MinGW is being used in place of Visual C. A package can be built with --compiler=mingw32, but if no compiler is specified for install the following error occurs: >python setup.py install running install running build running build_py running build_ext error: Python was built with Visual Studio 2003; extensions must be built with a compiler than can generate compatible binaries. Visual Studio 2003 was not found on this system. If you have Cygwin installed, you can try compiling with MingW32, by passing "-c mingw32" to setup.py. The work-around is to specify compiler=mingw32 in a setup.cfg file under a [build] or [build_ext] heading. But this would be inconvenient for someone who has both Visual C and MinGW and wants to choose. -- components: Distutils messages: 62241 nosy: kermode severity: normal status: open title: install command rejects --compiler option versions: Python 2.5 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2056> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2056] install command rejects --compiler option
Lenard Lindstrom added the comment: Yes, "setup.py build --compiler=mingw32 install" works. It is good enough for me. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2056> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2234] cygwinccompiler.py fails for latest MinGW releases.
New submission from Lenard Lindstrom: The cygwinccompiler.py module for distutils on Pythons 2.5 and 2.4 fails with an exception for the latest MinGW tools. running build_ext Traceback (most recent call last): File "setup.py", line 224, in setup(**PACKAGEDATA) File "C:\PRG\PYTHON25\lib\distutils\core.py", line 151, in setup dist.run_commands() File "C:\PRG\PYTHON25\lib\distutils\dist.py", line 974, in run_commands self.run_command(cmd) File "C:\PRG\PYTHON25\lib\distutils\dist.py", line 994, in run_command cmd_obj.run() File "C:\PRG\PYTHON25\lib\distutils\command\build.py", line 112, in run self.run_command(cmd_name) File "C:\PRG\PYTHON25\lib\distutils\cmd.py", line 333, in run_command self.distribution.run_command(command) File "C:\PRG\PYTHON25\lib\distutils\dist.py", line 994, in run_command cmd_obj.run() File "setup.py", line 186, in run build_ext.run(self) File "C:\PRG\PYTHON25\lib\distutils\command\build_ext.py", line 264, in run force=self.force) File "C:\prg\pygame\trunk_\mingw32distutils.py", line 31, in new_compiler return Mingw32DefaultCCompiler (None, dry_run, force) File "C:\PRG\PYTHON25\lib\distutils\cygwinccompiler.py", line 292, in __init__ CygwinCCompiler.__init__ (self, verbose, dry_run, force) File "C:\PRG\PYTHON25\lib\distutils\cygwinccompiler.py", line 84, in __init__ get_versions() File "C:\PRG\PYTHON25\lib\distutils\cygwinccompiler.py", line 424, in get_vers ions ld_version = StrictVersion(result.group(1)) File "C:\PRG\PYTHON25\lib\distutils\version.py", line 40, in __init__ self.parse(vstring) File "C:\PRG\PYTHON25\lib\distutils\version.py", line 107, in parse raise ValueError, "invalid version number '%s'" % vstring ValueError: invalid version number '2.18.50.20080109' For instance "ld -v" now returns "GNU ld (GNU Binutils) 2.18.50.20080109", not "GNU ld version 2.17.50 20060824". The extra period between the version number and date causes class StrictVersion to raise a ValueError. A fix is to alter the regular expressions in cygwinccompiler.get_versions(). This enclosed patch to cygwinccompiler.py has been tested with the current and previous linker as well as gcc 4.2.1 and gcc 3.4.5. -- components: Distutils files: cygwinccompiler.patch keywords: patch messages: 63257 nosy: kermode severity: normal status: open title: cygwinccompiler.py fails for latest MinGW releases. versions: Python 2.5 Added file: http://bugs.python.org/file9604/cygwinccompiler.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2234> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2234] cygwinccompiler.py fails for latest MinGW releases.
Lenard Lindstrom <[EMAIL PROTECTED]> added the comment: distutils.version.StrictVersion.parse does not handle x.y.z.n . That is why there is an exception. I have tested the patch both with binutils-2.18.50-20080109 (*), the latest version (a "Technology Preview"), and its predecessor binutils-2.18.50-20071123, which also works without the proposed patch. I use MinGW to build Pygame. Finally, there should be no reason to use earlier versions of binutils with Python 2.4 and up as msvcr71 support was introduced only a couple of years ago. (*) The MinGW binutils bundle contains both ld and dllwrap __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2234> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2683] subprocess.Popen.communicate takes bytes, not str
New submission from Lenard Lindstrom <[EMAIL PROTECTED]>:
subprocess.Popen.communicate is documented as taking a string as the
input argument. Instead is accepts only a binary stream (bytes).
Python 3.0a4 (r30a4:62126, Apr 3 2008, 15:34:18) [MSC v.1500 32 bit
(Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from subprocess import Popen, PIPE
>>> p = Popen('command.com', stdin=PIPE)
>>> p.communicate("dir\n")
Traceback (most recent call last):
File "", line 1, in
File "C:\Python30\lib\subprocess.py", line 588, in communicate
self.stdin.write(input)
File "C:\Python30\lib\io.py", line 844, in write
raise TypeError("can't write str to binary stream")
TypeError: can't write str to binary stream
--
components: Extension Modules
messages: 65740
nosy: kermode
severity: normal
status: open
title: subprocess.Popen.communicate takes bytes, not str
versions: Python 3.0
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2683>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2698] Extension module build fails for MinGW: missing vcvarsall.bat
New submission from Lenard Lindstrom <[EMAIL PROTECTED]>:
Python 2.6a2 on Windows XP
Distutils fails to build an extension module for MinGW. Even though
mingw32 is specified as the compiler distutils.msvc9compiler is still
loaded and it cannot find vcvarsall.bat. Here is an example:
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
[snip]
C:\pygame\ext>path=%path%;C:\python26;C:\mingw\bin
C:\pygame\ext>set MINGW_ROOT_DIRECTORY=C:\mingw
C:\pygame\ext>python setup.py build --compiler=mingw32
running build
running build_ext
error: None
C:\pygame\ext>python setup.py build_ext --compiler=mingw32
Traceback (most recent call last):
File "setup.py", line 6, in
ext_modules=[Extension('simple', ['simple.c',]),],
File "C:\python26\lib\distutils\core.py", line 137, in setup
ok = dist.parse_command_line()
File "C:\python26\lib\distutils\dist.py", line 459, in
parse_command_line
args = self._parse_command_opts(parser, args)
File "C:\python26\lib\distutils\dist.py", line 517, in
_parse_command_opts
cmd_class = self.get_command_class(command)
File "C:\python26\lib\distutils\dist.py", line 836, in
get_command_class
__import__ (module_name)
File "C:\python26\lib\distutils\command\build_ext.py", line 21, in
from distutils.msvccompiler import get_build_version
File "C:\python26\lib\distutils\msvccompiler.py", line 658, in
from distutils.msvc9compiler import MSVCCompiler
File "C:\python26\lib\distutils\msvc9compiler.py", line 286, in
VC_ENV = query_vcvarsall(VERSION, ARCH)
File "C:\python26\lib\distutils\msvc9compiler.py", line 253, in
query_vcvarsall
raise IOError("Unable to find vcvarsall.bat")
IOError: Unable to find vcvarsall.bat
C:\pygame\ext>type setup.py
from distutils.core import setup, Extension
setup(name='Simple',
version='1.0',
description='Python extension module test',
ext_modules=[Extension('simple', ['simple.c',]),],
)
C:\pygame\ext>gcc --version
gcc (GCC) 3.4.5 (mingw special)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
C:\pygame\ext>python -V
Python 2.6a2
--
components: Distutils
messages: 65850
nosy: kermode
severity: normal
status: open
title: Extension module build fails for MinGW: missing vcvarsall.bat
versions: Python 2.6
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2698>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4793] Glossary incorrectly describes a decorator as "merely syntactic sugar"
New submission from Lenard Lindstrom : http://www.python.org/doc/2.6/glossary.html The decorator entry in the Python 2.6 documentation incorrectly describes a decorator as "merely syntactic sugar". It is not, as this example shows: >>> def decorator(f): f.prev = globals()[f.__name__] return f >>> func = 0 >>> def func(): pass >>> func = decorator(func) >>> func.prev >>> func = 0 >>> @decorator def func(): pass >>> func.prev 0 This distinction could be useful in building multi-methods, for example. -- assignee: georg.brandl components: Documentation messages: 78643 nosy: georg.brandl, kermode severity: normal status: open title: Glossary incorrectly describes a decorator as "merely syntactic sugar" versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue4793> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4793] Glossary incorrectly describes a decorator as "merely syntactic sugar"
Lenard Lindstrom added the comment: It is distinct behavior. Without a decorator a new function is immediately assigned to the identifier. Any previous reference is lost. A decorator postpones assignment until the decorator returns. That allows the decorator to access the previous object. I don't know of any way to do the same thing with: def foo(): . foo = do_something(foo) Here is part of a comp.lang.python thread discussing the possibility of using a decorator for an overloaded function. http://groups.google.com/group/comp.lang.python/browse_thread/thread/16a2e8b9d6705dfb/1cb0b358173daf06?lnk=gst&q=Lenard+Lindstrom+decorator#1cb0b358173daf06 Note that the decorator could create an overloaded function without any extra variables. To do the equivalent in Python 2.3 a special attribute, with a mangled name, was needed to store intermediate declarations. ___ Python tracker <http://bugs.python.org/issue4793> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4793] Glossary incorrectly describes a decorator as "merely syntactic sugar"
Lenard Lindstrom added the comment: The claim "merely" syntactic sugar implies that the inverse is also true, the decorator expression: @do_something def foo(): can be replaced it with: def foo(): foo = do_something(foo) This is guaranteed if do_something is purely functional, but breaks if do_something has side effects. The example was for illustration only. A real application would likely access the parent frame. Whether or not this is a questionable practice, it happens. However, the issue is one of definitions. Is the phrase "merely syntactic sugar" misleading? In this case it makes promises that may not be kept. ___ Python tracker <http://bugs.python.org/issue4793> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13797] Allow objects implemented in pure Python to export PEP 3118 buffers
Lenard Lindstrom added the comment: A fourth way to add __getbuffer__ and __releasebuffer__ special methods to a Python class is through a new base class/mixin. The Py_buffer struct pointer passed to __getbuffer__ and __releasebuffer__ is wrapped with another special object type, which exposes the C struct fields as attributes. The base class is a direct subclass of object. Both the base and wrapper classes are implemented in an extension module. The use case is unit testing. A memoryview object may be adequate for simple C-contiguous arrays, but fails with F-contiguous or any non-contiguous array. It cannot export any arbitrary view, especially a deliberately invalid view, useful for testing error handlers. My implementation is at https://bitbucket.org/llindstrom/newbuffer . It is used in Pygame 1.9.2 unit tests: https://bitbucket.org/pygame/pygame . The newbuffer module exports two classes, BufferMixin and Py_buffer. The BufferMixin class adds bf_getbuffer and bf_releasebuffer slot functions to base class PyObject, nothing more. The Py_buffer class is low level, exposing pointer fields as integer addresses. It is designed for use with ctypes and is modelled on ctypes.Structure. Some limitations. In a class declaration, BufferMixin must be first in the inheritance list for the subclass to inherit the PEP 3118 interface. A buffer interface cannot be added to a builtin. I suggest this is a practical alternative to the three previously proposed solutions to this issue. This option takes its precedence from the ctypes module, which adds dangerous memory level access to Python, but optionally. It does not require modification of the base code, only an addition to the standard library. Finally, this approach has been demonstrated in a real-world application. -- nosy: +kermode Added file: http://bugs.python.org/file31329/llindstrom-newbuffer-0dd8ba1c2c2c.tar.gz ___ Python tracker <http://bugs.python.org/issue13797> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2698] Extension module build fails for MinGW: missing vcvarsall.bat
Lenard Lindstrom added the comment: Here is the build with Python 2.6.2. It works now. C:\pygame\bug2698>python setup.py build --compiler=mingw32 --verbose running build running build_ext building 'simple' extension creating build creating build\temp.win32-2.6 creating build\temp.win32-2.6\Release C:\mingw\bin\gcc.exe -mno-cygwin -mdll -O -Wall -IC:\python26\include -IC:\python26\PC -c simple.c -o build\temp.win32-2.6\Release\simple.o writing build\temp.win32-2.6\Release\simple.def creating build\lib.win32-2.6 C:\mingw\bin\gcc.exe -mno-cygwin -shared -s build\temp.win32-2.6\Release\simple.o build\temp.win32-2.6\Release\simple.def -LC:\python26\libs -LC:\python26\PCbuild -lpython26 -lmsvcr90 -o build\lib.win32-2.6\simple.pyd -- ___ Python tracker <http://bugs.python.org/issue2698> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3440] Starting any program as a subprocess fails when subprocess.Popen has env argument
Lenard Lindstrom added the comment: The notepad example works with Pythons 2.4.4 and 2.5.4 on Windows 98. So something changed in Windows XP. The 0xc0150004 error code crops up when a side-by-side assembly fails to load. The DLL loader appears to use the SystemRoot environment variable to find dependencies. I will check if the XP notepad.exe is an SxS and post a follow-up. -- ___ Python tracker <http://bugs.python.org/issue3440> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3440] Starting any program as a subprocess fails when subprocess.Popen has env argument
Lenard Lindstrom added the comment:
notepad.exe forms a side-by-side assembly with COMCTL32.DLL. So
SystemRoot must be included in the environment. The following example
works with Python 2.5.2 on Windows XP.
===
import struct, subprocess
import os
command = 'C:\\WINDOWS\\NOTEPAD.EXE'
env = {'FOO': 'bar', 'SystemRoot': os.environ['SystemRoot']}
p = subprocess.Popen(command, env=env)
p.wait()
err = struct.unpack('I', struct.pack('i', p.returncode))[0]
print '%x (%d)'%(err, err)
===
I would suggest Popen adds SystemRoot to env if it is not present.
--
___
Python tracker
<http://bugs.python.org/issue3440>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
