[issue46043] Python Launcher Not Opening Files.
Ronald Oussoren added the comment: Are you on macOS 10.15 or later? If so, this is a duplicate of issue40477. A workaround mentioned in that issue is to make sure that Terminal.app is open. -- type: crash -> behavior ___ Python tracker <https://bugs.python.org/issue46043> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40477] Python Launcher app on macOS 10.15+ fails to run scripts
Ronald Oussoren added the comment: FWIW, I'm experimenting with using Scripting Bridge instead of raw Apple Events in Python Laucher. Mostly to check if that fixes the issue because I can run scripts in Terminal using Scripting Bridge from a Python script using PyObjC. Scripting Bridge would also result in slightly easier to read code. On my machine (M1 Mac Book running macOS 12.0.1) Python Launcher cannot start scripts (as described in this issue). Same when I strip code signatures (and ad-hoc sign without using the hardened runtime) -- ___ Python tracker <https://bugs.python.org/issue40477> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40477] Python Launcher app on macOS 10.15+ fails to run scripts
Ronald Oussoren added the comment:
It looks like this is related to code signing and entitlements, in particular:
* On my system Terminal.app is in the "Automation" list in the Security &
Privacy control panel, and none of the installed Python Launchers are
* The script let below works (assuming PyObjC is installed):
```
import ScriptingBridge
command = """cd '' &&
'/Library/Frameworks/Python.framework/Versions/3.10/bin/python3'
'/Users/ronald/issuequery.py' && echo Exit status: $? && exit 1"""
app =
ScriptingBridge.SBApplication.applicationWithBundleIdentifier_("com.apple.Terminal")
app.activate()
res = app.doScript_in_(command, None)
print(res)
```
* Python Launcher does not work when launched normally
* Python Launcher *does* work when I run "/Applcations/Python 3.X/Python
Launcher/Contents/MacOS/Python Launcher" in Terminal.app and try to open a
python file using Python Launcher
- I've tried this with 3 variants of Python Launcher: 3.9.7 from python.org
installer, no modifications; 3.10.1 from python.org installer, stripped
signature and resigned ad-hoc; 3.11 installed from source with ScriptingBridge.
As mentioned before I've experimented with ScriptingBridge in Python Launcher,
replacing "doscript.m" by the code below:
```
#import
#import
#import "doscript.h"
extern int
doscript(const char *command)
{
NSObject* terminalApp = [SBApplication
applicationWithBundleIdentifier:@"com.apple.Terminal"];
//[terminalApp activate];
NSObject* res = [terminalApp doScript:[NSString
stringWithUTF8String:command] in:nil];
NSRunAlertPanel(@"script result", @"%@", @"ok",nil, nil, res);
return 0;
}
```
That's equivalent to the python code I posted earlier. This is not production
quality code, it compiles with a warning about "doScript:in:" that can be
avoided by a different way of using ScriptingBridge. That's irrelevant for this
experiment though.
When I test the call to "doScript:in:" *fails* (returns nil) when launching the
app regularly, and *succeeds* when running as a terminal command (as mentioned
earlier).
--
___
Python tracker
<https://bugs.python.org/issue40477>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40477] Python Launcher app on macOS 10.15+ fails to run scripts
Ronald Oussoren added the comment: Pfff Apple's documentation is too incomplete. In recent versions the apple events entitlement only works when the program also has an NSAppleEventsUsageDescription key in Info.plist with a string value that describes why it needs the entitlement, this information is shown to the user on first launch. When I add this key to info.plist and resign the launcher works. I forgot to create a screenshot of this and cannot recreate the system dialog that gets shown, probably documentement somewhere that I haven't found yet... For now I used: NSAppleEventsUsageDescription Python Launcher needs this to run scripts in a Terminal window This requires no code changes. -- ___ Python tracker <https://bugs.python.org/issue40477> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46117] tk could not refresh auto in mac os
Ronald Oussoren added the comment:
The script seems to work fine for me, python 3.10.1 on macOS 12.1. I used the
python.org installer.
Did you install Python from source or using the installer? What's the output of
``python3 -m test.pythoninfo``, in particular the lines related to Tcl/Tk at
the end?
For example:
...
time.tzname: ('CET', 'CEST')
tkinter.TCL_VERSION: 8.6
tkinter.TK_VERSION: 8.6
tkinter.info_patchlevel: 8.6.12
zlib.ZLIB_RUNTIME_VERSION: 1.2.11
...
--
___
Python tracker
<https://bugs.python.org/issue46117>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46117] tk could not refresh auto in mac os
Ronald Oussoren added the comment: I don't know why it doesn't work for you. The version of Tk looks recent enough. As I mentioned before I don't see this problem using the script in your initial message, it works fine both with and without changing the size of the window. You could try installing Python 3.10.1, which should get you the exact some binary and Tcl/Tk version as I'm using. That might fix the problem. Btw. I'm on an M1 MacBook, although that shouldn't be relevant here. -- ___ Python tracker <https://bugs.python.org/issue46117> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46174] Feature Request for Python Interfaces
Ronald Oussoren added the comment: I agree with Terry. This requires a clear proposal that describes the behaviour and differences with ABC-s. I'm closing this issue for now. -- nosy: +ronaldoussoren resolution: -> later stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46174> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46248] Compilation errors on macOS
Ronald Oussoren added the comment: Part of the problem here is that most keys in the result of sysconfig.get_config_vars() are copied as-is from the CPython Makefile and pyconfig.h header file. The keys copied from the Makefile are in a lot of cases not useful for users of python because they contain values that are only useful while building CPython itself. Without knowing your use case it is hard to point you to a better solution, but as Ned writes in general just follow the instructions from the extending and embedding documentation. -- ___ Python tracker <https://bugs.python.org/issue46248> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46248] Compilation errors on macOS
Ronald Oussoren added the comment: The libraries you mention are 3th party projects. Please check with the project first. I've look at the GitHub repository for libmobiledevice and have no idea how they determine the compiler flags for Python. As mentioned in an earlier version "python-config" is the documented way to fetch such flags. -- ___ Python tracker <https://bugs.python.org/issue46248> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34602] python3 resource.setrlimit strange behaviour under macOS
Ronald Oussoren added the comment: > My understanding of the resolution of this ticket is that it is still not > possible to use setrlimit with RLIMIT_STACK to raise the soft stack limit. > Is that correct? Yes, the code in msg324731 still fails. We're still using the mechanism described in msg324818, but with a larger stack size for some builds. It is rather annoying that -Wl,-stack_size, sets a hard limit on the stack size, rather than overriding the soft limit. I guess we could change the startup code for the interpreter executable (Py_Main or related code) to set the RLIMIT_STACK to a larger value when it is too small, that way applications can still pick a different (and in particular larger) value. @ned.deily, @lukasz.langa: reopen this issue or open a new one? -- versions: +Python 3.10, Python 3.11 -Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue34602> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46412] PyQT6 projects crashes with python 3.10
Ronald Oussoren added the comment: This is most likely a problem with PyQt6. Please ask that project first (with a clearer description of what goes wrong and on which platforms). -- nosy: +ronaldoussoren resolution: -> third party stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46412> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46514] Pathlib Path.touch() seems to ignore groups write bit for mode parameter
Ronald Oussoren added the comment: The touch method combines the mode you specify with the active umask (set by os.umask()). This is fairly standard behaviour for Unix APIs that accept a file mode. This is documented at: https://docs.python.org/3/library/pathlib.html#pathlib.Path.touch -- nosy: +ronaldoussoren resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46514> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46548] macOS installers cannot be signed on Monterey
Change by Ronald Oussoren : -- components: +macOS nosy: +ronaldoussoren ___ Python tracker <https://bugs.python.org/issue46548> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46550] __slots__ updates despite being read-only
Ronald Oussoren added the comment: Python's is behaving as expected here (but see below): the slots definition tells the interpreter which attribute names can be set on an instance and "__slots__" is not one of those attributes in your code. "a.__slots__ += ..." will try to set the "a.__slots__" attribute (see Eryk's message for documentation on this) and that results in the exception you are seeing. What surprised me is that A.__slots__ is mutable at all, the value of that attribute during class construction affects the layout of instances and that layout won't change when you change A.__slots__ later on. That is: class A: __slots__ = ['a'] a = A() a.a = ... # OK a.b = ... # raises AttributeError A.__slots__ = ['b'] a.a = ... # still OK a.b = ... # still raises AttributeError I don't know if this should be considered a bug or that this is intended behaviour. -- components: +Interpreter Core -Library (Lib) nosy: +ronaldoussoren versions: +Python 3.11, Python 3.9 -Python 3.8 ___ Python tracker <https://bugs.python.org/issue46550> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46573] Python modules such as pyglet or pygame crash Python when tkinter message boxes are opened on MacOS.
Ronald Oussoren added the comment: Error output when running the script: 2022-02-01 22:15:32.213 Python[5468:5726153] ApplePersistenceIgnoreState: Existing state will not be touched. New state will be written to /var/folders/d3/rc5nx4v12y96knh2px3bpqscgn/T/org.python.python.savedState 2022-02-01 22:15:32.362 Python[5468:5726153] -[NSApplication macOSVersion]: unrecognized selector sent to instance 0x105624bc0 2022-02-01 22:15:32.367 Python[5468:5726153] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[NSApplication macOSVersion]: unrecognized selector sent to instance 0x105624bc0' *** First throw call stack: ( 0 CoreFoundation 0x00018b4c01cc __exceptionPreprocess + 240 1 libobjc.A.dylib 0x00018b2117b8 objc_exception_throw + 60 2 CoreFoundation 0x00018b5531a0 -[NSObject(NSObject) __retain_OA] + 0 3 CoreFoundation 0x00018b420360 ___forwarding___ + 1728 4 CoreFoundation 0x00018b41fbe0 _CF_forwarding_prep_0 + 96 5 libtk8.6.dylib 0x000100940a1c GetRGBA + 64 6 libtk8.6.dylib 0x0001009404a8 SetCGColorComponents + 140 7 libtk8.6.dylib 0x0001009408e0 TkpGetColor + 544 8 libtk8.6.dylib 0x0001008a2454 Tk_GetColor + 220 9 libtk8.6.dylib 0x000100895aa0 Tk_Get3DBorder + 204 10 libtk8.6.dylib 0x0001008958ac Tk_Alloc3DBorderFromObj + 144 11 libtk8.6.dylib 0x0001008a3810 DoObjConfig + 832 12 libtk8.6.dylib 0x0001008a33cc Tk_InitOptions + 348 13 libtk8.6.dylib 0x0001008a32c8 Tk_InitOptions + 88 14 libtk8.6.dylib 0x0001008cacf0 CreateFrame + 1448 15 libtk8.6.dylib 0x0001008cafe8 TkListCreateFrame + 156 16 libtk8.6.dylib 0x0001008c3ec0 Initialize + 1848 17 _tkinter.cpython-310-darwin.so 0x0001008762d4 Tcl_AppInit + 92 18 _tkinter.cpython-310-darwin.so 0x000100875f6c Tkapp_New + 548 19 _tkinter.cpython-310-darwin.so 0x000100875d44 _tkinter_create_impl + 268 20 _tkinter.cpython-310-darwin.so 0x00010087597c _tkinter_create + 240 21 Python 0x00010109b1f0 cfunction_vectorcall_FASTCALL + 88 22 Python 0x000101169f48 call_function + 132 23 Python 0x000101161fac _PyEval_EvalFrameDefault + 23072 24 Python 0x00010115ad5c _PyEval_Vector + 360 25 Python 0x000101033dac _PyObject_FastCallDictTstate + 96 26 Python 0x0001010c7cbc slot_tp_init + 196 27 Python 0x0001010be950 type_call + 312 28 Python 0x000101033af4 _PyObject_MakeTpCall + 136 29 Python 0x00010116a040 call_function + 380 30 Python 0x000101160a18 _PyEval_EvalFrameDefault + 17548 31 Python 0x00010115ad5c _PyEval_Vector + 360 32 Python 0x000101169f48 call_function + 132 33 Python 0x000101160a18 _PyEval_EvalFrameDefault + 17548 34 Python 0x00010115ad5c _PyEval_Vector + 360 35 Python 0x000101169f48 call_function + 132 36 Python 0x000101161404 _PyEval_EvalFrameDefault + 20088 37 Python 0x00010115ad5c _PyEval_Vector + 360 38 Python 0x00010115cb3c _PyEval_EvalFrameDefault + 1456 39 Python 0x00010115ad5c _PyEval_Vector + 360 40 Python 0x000101169f48 call_function + 132 41 Python 0x000101160a18 _PyEval_EvalFrameDefault + 17548 42 Python 0x00010115ad5c _PyEval_Vector + 360 43 Python 0x00010115cb3c _PyEval_EvalFrameDefault + 1456 44 Python 0x00010115ad5c _PyEval_Vector + 360 45 Python 0x00010115cb3c _PyEval_EvalFrameDefault + 1456 46 Python 0x00010115ad5c
[issue46573] Python modules such as pyglet or pygame crash Python when tkinter message boxes are opened on MacOS.
Ronald Oussoren added the comment: The last bit of the call stack according to lldb: * thread #2, queue = 'com.apple.main-thread', stop reason = signal SIGABRT frame #0: 0x00018b3419b8 libsystem_kernel.dylib`__pthread_kill + 8 frame #1: 0x00018b374eb0 libsystem_pthread.dylib`pthread_kill + 288 frame #2: 0x00018b2b2314 libsystem_c.dylib`abort + 164 frame #3: 0x00018b331b50 libc++abi.dylib`abort_message + 132 frame #4: 0x00018b322f64 libc++abi.dylib`demangling_terminate_handler() + 332 frame #5: 0x00018b21a140 libobjc.A.dylib`_objc_terminate() + 144 frame #6: 0x00018b330ee4 libc++abi.dylib`std::__terminate(void (*)()) + 20 * frame #7: 0x00018b333c5c libc++abi.dylib`__cxxabiv1::failed_throw(__cxxabiv1::__cxa_exception*) + 36 frame #8: 0x00018b333c08 libc++abi.dylib`__cxa_throw + 140 frame #9: 0x00018b2118dc libobjc.A.dylib`objc_exception_throw + 352 frame #10: 0x00018b5531a0 CoreFoundation`-[NSObject(NSObject) doesNotRecognizeSelector:] + 144 frame #11: 0x00018b420360 CoreFoundation`___forwarding___ + 1728 frame #12: 0x00018b41fbe0 CoreFoundation`_CF_forwarding_prep_0 + 96 frame #13: 0x000102388a1c libtk8.6.dylib`GetRGBA + 64 frame #14: 0x0001023884a8 libtk8.6.dylib`SetCGColorComponents + 140 frame #15: 0x0001023888e0 libtk8.6.dylib`TkpGetColor + 544 frame #16: 0x0001022ea454 libtk8.6.dylib`Tk_GetColor + 220 frame #17: 0x0001022ddaa0 libtk8.6.dylib`Tk_Get3DBorder + 204 frame #18: 0x0001022dd8ac libtk8.6.dylib`Tk_Alloc3DBorderFromObj + 144 frame #19: 0x0001022eb810 libtk8.6.dylib`DoObjConfig + 832 frame #20: 0x0001022eb3cc libtk8.6.dylib`Tk_InitOptions + 348 frame #21: 0x0001022eb2c8 libtk8.6.dylib`Tk_InitOptions + 88 frame #22: 0x000102312cf0 libtk8.6.dylib`CreateFrame + 1448 frame #23: 0x000102312fe8 libtk8.6.dylib`TkListCreateFrame + 156 frame #24: 0x00010230bec0 libtk8.6.dylib`Initialize + 1848 frame #25: 0x00010026a2d4 _tkinter.cpython-310-darwin.so`Tcl_AppInit + 92 frame #26: 0x000100269f6c _tkinter.cpython-310-darwin.so`Tkapp_New + 548 frame #27: 0x000100269d44 _tkinter.cpython-310-darwin.so`_tkinter_create_impl + 268 frame #28: 0x00010026997c _tkinter.cpython-310-darwin.so`_tkinter_create + 240 frame #29: 0x000100bf71f0 Python`cfunction_vectorcall_FASTCALL + 88 -- ___ Python tracker <https://bugs.python.org/issue46573> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46573] Python modules such as pyglet or pygame crash Python when tkinter message boxes are opened on MacOS.
Ronald Oussoren added the comment: If I interpret the information I posted earlier correctly this is a bug in Tkinter, it calls a non-existing Objecive-C method (``-[NSApplication macOSVersion]``) and that results in an uncaught Objective-C exception and hence an abort(). BTW. All of this is using python 3.10.2 using the installer on python.org. -- components: +Tkinter ___ Python tracker <https://bugs.python.org/issue46573> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46573] Python modules such as pyglet or pygame crash Python when tkinter message boxes are opened on MacOS.
Ronald Oussoren added the comment: Oops, sorry: In Tk itself. -- ___ Python tracker <https://bugs.python.org/issue46573> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46573] Python modules such as pyglet or pygame crash Python when tkinter message boxes are opened on MacOS.
Ronald Oussoren added the comment: I've done some more research and this is an integration issue between pyglet and Tk. In particular: * Both pyglet and Tk use AppKit to implement their GUI * AppKit uses an NSApplication class, and in particular a singleton instance of that class, to represent the application, which will get instantiated during application startup * The Tk library uses a sublclass of NSApplication with additional functionality (TkApplication). * When pyglet is started first the NSApplication singleton is an instance of NSApplication and not of TkApplication, but Tk's implementation assumes that the singleton is an instance of TkApplicationo. A workaround for this issue is to make sure Tk is initialised before initialising pyglet. For example using this code at the start of the script: "from tkinter import Tk; root = Tk()" There's not much we can do about this in CPython, other than maybe filing an issue with the Tk project about this. I haven't looked at the Tk codebase and there cannot tell how hard it would be for then to avoid a dependency on TkApplication as a separate class (for example by implementing the additional functionality they need in a category on NSApplication). -- resolution: -> third party stage: -> resolved status: open -> pending ___ Python tracker <https://bugs.python.org/issue46573> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46550] __slots__ updates despite being read-only
Ronald Oussoren added the comment: W.r.t. augmented assignments, this is a good blog post about how they work under the hood: https://snarky.ca/unravelling-augmented-arithmetic-assignment/ -- ___ Python tracker <https://bugs.python.org/issue46550> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46550] __slots__ updates despite being read-only
Ronald Oussoren added the comment: There's a use case for using a dict for __slots__, pydoc will use a dict value for the slots as a mapping from attribute name to attribute documentation. Because of that it is not really worthwhile to transform the value of __slots__ during class definition. -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46550> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46573] Python modules such as pyglet or pygame crash Python when tkinter message boxes are opened on MacOS.
Ronald Oussoren added the comment: Categories make it possible to add methods to an existing class, but not new attributes. The latter shouldn't be a problem in principle for an NSApplication subclass because only a single instance of the application class will get created and you may as well use global variables for those. In some sense categories are syntactic sugar for monkey patching existing classes, commonly used to add convenience methods to Cocoa classes. -- ___ Python tracker <https://bugs.python.org/issue46573> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46573] Python modules such as pyglet or pygame crash Python when tkinter message boxes are opened on MacOS.
Ronald Oussoren added the comment: Something I forgot to mention: I don't think this is a bug in Tk now that I've looked into this more deeply. The integration problem between Tk and other users of the Cocoa event loop is unfortunate but not a bug. -- ___ Python tracker <https://bugs.python.org/issue46573> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46871] Lambda can't be pickled with "spawn" and only "fork"
Ronald Oussoren added the comment: The default start method for multirprocessing was changed from "fork" to "spawn" on macOS. This was done because the "fork" method can easily be triggered into causing hard crashes (on macOS), in particular when the parent proces has called higher-level systemen APIs. The "spawn" method requires pickling the data and callable passed to the child proces, and that's not supported for lambda's. -- components: +macOS nosy: +ned.deily, ronaldoussoren ___ Python tracker <https://bugs.python.org/issue46871> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46871] Lambda can't be pickled with "spawn" and only "fork"
Ronald Oussoren added the comment: This is not a bug in CPython, at best this can be a feature request to make it possible to pickle lambda's (which IMHO is unlikely to happen). The "fork" and "spawn" start methods result in different behaviour in how data is copied into the new worker proces and there's nothing we can do about this. Note that the same difference in behaviour can be observed on Windows, which does not support the "fork" method at all. -- resolution: -> not a bug stage: -> resolved status: open -> pending ___ Python tracker <https://bugs.python.org/issue46871> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46890] vent does not create "python" link in python 3.11
New submission from Ronald Oussoren : In python3.10 and earlier "python3 -m venv something" creates "something/bin/python" as a symlink to the interpreter itself. In python3.11 (a5) the same command no longer creates "something/bin/python", but only the ".../python3" symlink. With this change the "python" command no longer refers to the interpreter in an activated virtualenv, but to a different binary on $PATH (if any). I tested using the Python 3.11a5 installer for macOS on python.org. -- components: Library (Lib) keywords: 3.11regression messages: 414278 nosy: ronaldoussoren priority: normal severity: normal status: open title: vent does not create "python" link in python 3.11 type: behavior versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46890> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46890] venv does not create "python" link in python 3.11
Ronald Oussoren added the comment:
This is be related to how the virtual environment is populated. In 3.10 the
"python3.10" name in the environment is a symlink to sys.executable. In 3.10
"Python" (not the capital) is a symlink to the binary in Python.app and
"python3.11" is a symlink to "Python". Given that the filesystem is case
preserving there is no "python" name.
The behaviour in 3.11 is clearly a bug: the virtual environment is no longer
using the launcher binary in "{sys.prefix]/bin" but directly uses the "real"
binary (in a framework build), and because of that scripts cannot use system
APIs that expect to run in an application bundle.
Listing "env/bin" in Python 3.10:
-rw-rw-r-- 1 ronald staff 9033 Mar 1 18:11 Activate.ps1
-rw-rw-r-- 1 ronald staff 2018 Mar 1 18:11 activate
-rw-rw-r-- 1 ronald staff 944 Mar 1 18:11 activate.csh
-rw-rw-r-- 1 ronald staff 2086 Mar 1 18:11 activate.fish
-rwxr-xr-x 1 ronald staff 269 Mar 1 18:11 pip
-rwxr-xr-x 1 ronald staff 269 Mar 1 18:11 pip3
-rwxr-xr-x 1 ronald staff 269 Mar 1 18:11 pip3.10
lrwxr-xr-x 1 ronald staff10 Mar 1 18:11 python -> python3.10
lrwxr-xr-x 1 ronald staff10 Mar 1 18:11 python3 -> python3.10
lrwxr-xr-x 1 ronald staff65 Mar 1 18:11 python3.10 ->
/Library/Frameworks/Python.framework/Versions/3.10/bin/python3.10
In python3.11:
total 72
-rw-rw-r-- 1 ronald staff 9033 Mar 1 17:23 Activate.ps1
lrwxr-xr-x 1 ronald staff93 Mar 1 17:23 Python ->
/Library/Frameworks/Python.framework/Versions/3.11/Resources/Python.app/Contents/MacOS/Python
-rw-rw-r-- 1 ronald staff 2018 Mar 1 17:23 activate
-rw-rw-r-- 1 ronald staff 944 Mar 1 17:23 activate.csh
-rw-rw-r-- 1 ronald staff 2086 Mar 1 17:23 activate.fish
-rwxr-xr-x 1 ronald staff 265 Mar 1 17:23 pip
-rwxr-xr-x 1 ronald staff 265 Mar 1 17:23 pip3
-rwxr-xr-x 1 ronald staff 265 Mar 1 17:23 pip3.11
lrwxr-xr-x 1 ronald staff 6 Mar 1 17:23 python3 -> Python
lrwxr-xr-x 1 ronald staff 6 Mar 1 17:23 python3.11 -> Python
--
components: +macOS
nosy: +ned.deily
priority: normal -> release blocker
___
Python tracker
<https://bugs.python.org/issue46890>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46890] venv does not create "python" link in python 3.11
Ronald Oussoren added the comment:
The root cause likely is the calculation of sys._base_executable. In 3.10 this
is {sys.prefix}/bin/python3.10, while in 3.11 this is
{sys.prefix}/Resources/Python.app/Contents/MacOS/Python.
The venv library uses the incorrect value and therefore creates an incorrect
virtual environment.
--
components: +Interpreter Core
___
Python tracker
<https://bugs.python.org/issue46890>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46890] venv does not create "python" link in python 3.11
Ronald Oussoren added the comment: The change to _base_executable is the real problem. Venv creates the correct directory structure if I add a sitecustomize.py to the python path that sets _base_executable to the correct value. # sitecustomize import sys sys._base_executable = sys.executable # EOF Is sys._base_executable updated after running getpath.py? On first glance getpath.py does update config['base_executable'] and _PyConfig_FromDict reads that value back, but that's based on a quick scan through the code. I haven't tried debugging this yet. -- ___ Python tracker <https://bugs.python.org/issue46890> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46891] Crash in ModuleType subclass with __slots__
New submission from Ronald Oussoren :
The following crashes the interpreter in Python 3.11, and works fine in older
versions:
# --- script.py
import types
class MyModule (types.ModuleType):
__slots__ = (
"_MyModule__a",
"_MyModule__b",
)
def __init__(self, name):
super().__init__(name)
m = MyModule("name")
# -- end of file
The key in this is the ``__slots__`` definition: The script does not crash
without ``__slots__``, or with a slots tuple with 1 item.
This is a reproducer based on code in PyObjC.
--
components: Interpreter Core
keywords: 3.11regression
messages: 414294
nosy: ronaldoussoren
priority: normal
severity: normal
stage: needs patch
status: open
title: Crash in ModuleType subclass with __slots__
type: crash
versions: Python 3.11
___
Python tracker
<https://bugs.python.org/issue46891>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46891] Crash in ModuleType subclass with __slots__
Ronald Oussoren added the comment: This is with python 3.11 alpha 5 using the installer for macOS. -- ___ Python tracker <https://bugs.python.org/issue46891> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46891] Crash in ModuleType subclass with __slots__
Ronald Oussoren added the comment: The crash itself happens during garbage collection: % python3.11 -Xdev t.py (master)pyobjc-8 Fatal Python error: Segmentation fault Current thread 0x000104ce0580 (most recent call first): Garbage-collecting And when using a debug build and -Xdev: ../Modules/gcmodule.c:2187: visit_validate: Assertion failed: PyObject_GC_Track() object is not valid Enable tracemalloc to get the memory block allocation traceback object address : 0x101a5f690 object refcount : 1 object type : 0x15503f230 object type name: MyModule object repr : Fatal Python error: _PyObject_AssertFailed: _PyObject_AssertFailed Python runtime state: initialized Current thread 0x0001019c0580 (most recent call first): File "/Users/ronald/Projects/Forks/cpython/build/t.py", line 12 in zsh: abort ./python.exe -Xdev t.py -- ___ Python tracker <https://bugs.python.org/issue46891> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46891] Crash in ModuleType subclass with __slots__
Ronald Oussoren added the comment: The debug build seems to indicate that slot memory is not initiated properly, a stack trace (note the argument to visit_validate at frame #7): * frame #0: 0x00019b60d9b8 libsystem_kernel.dylib`__pthread_kill + 8 frame #1: 0x00019b640eb0 libsystem_pthread.dylib`pthread_kill + 288 frame #2: 0x00019b57e314 libsystem_c.dylib`abort + 164 frame #3: 0x00010030c4f4 python.exe`fatal_error_exit(status=-1) at pylifecycle.c:2624:9 frame #4: 0x00010030c3cc python.exe`fatal_error(fd=2, header=1, prefix="_PyObject_AssertFailed", msg="_PyObject_AssertFailed", status=-1) at pylifecycle.c:2805:5 frame #5: 0x00010030be20 python.exe`_Py_FatalErrorFunc(func="_PyObject_AssertFailed", msg="_PyObject_AssertFailed") at pylifecycle.c:2821:5 frame #6: 0x000100169fe0 python.exe`_PyObject_AssertFailed(obj=0x000100d63690, expr=0x, msg="PyObject_GC_Track() object is not valid", file="../Modules/gcmodule.c", line=2187, function="visit_validate") at object.c:2293:5 frame #7: 0x000100351184 python.exe`visit_validate(op=0xcdcdcdcdcdcdcdcd, parent_raw=0x000100d63690) at gcmodule.c:2186:9 frame #8: 0x00010019845c python.exe`traverse_slots(type=0x000101813230, self=0x000100d63690, visit=(python.exe`visit_validate at gcmodule.c:2183), arg=0x000100d63690) at typeobject.c:1207:27 frame #9: 0x000100197fe8 python.exe`subtype_traverse(self=0x000100d63690, visit=(python.exe`visit_validate at gcmodule.c:2183), arg=0x000100d63690) at typeobject.c:1228:23 frame #10: 0x000100350fdc python.exe`PyObject_GC_Track(op_raw=0x000100d63690) at gcmodule.c:2212:11 -- ___ Python tracker <https://bugs.python.org/issue46891> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46890] venv does not create "python" link in python 3.11
Ronald Oussoren added the comment:
Again without diving deep I've constructed a test case that is probably
relevant. I've pasted the diff below because I'm not yet convinced that it is
correct (in particular the value for "argv0". This would also require a second
test case that does something similar for a venv when using a framework build
(the test_venv_macos case seems to be for a regular install and not a framework
install)
With this tests case I get a test failure that matches my observations:
test test_getpath failed -- Traceback (most recent call last):
File "/Users/ronald/Projects/Forks/cpython/Lib/test/test_getpath.py", line
444, in test_framework_python
self.assertEqual(expected, actual)
^^
AssertionError: {'exe[273 chars]/9.8/bin/python9.8', 'base_prefix':
'/Library/[381 chars]ad']} != {'exe[273
chars]/9.8/Resources/Python.app/Contents/MacOS/Pytho[410 chars]ad']}
{'base_exec_prefix': '/Library/Frameworks/Python.framework/Versions/9.8',
- 'base_executable':
'/Library/Frameworks/Python.framework/Versions/9.8/bin/python9.8',
?^^^ ^
- ^
+ 'base_executable':
'/Library/Frameworks/Python.framework/Versions/9.8/Resources/Python.app/Contents/MacOS/Python',
?
^ ^ ^
'base_prefix': '/Library/Frameworks/Python.framework/Versions/9.8',
'exec_prefix': '/Library/Frameworks/Python.framework/Versions/9.8',
'executable':
'/Library/Frameworks/Python.framework/Versions/9.8/bin/python9.8',
'module_search_paths':
['/Library/Frameworks/Python.framework/Versions/9.8/lib/python98.zip',
'/Library/Frameworks/Python.framework/Versions/9.8/lib/python9.8',
'/Library/Frameworks/Python.framework/Versions/9.8/lib/python9.8/lib-dynload'],
'module_search_paths_set': 1,
'prefix': '/Library/Frameworks/Python.framework/Versions/9.8'}
test_getpath failed (1 failure)
The inline diff (and as mentioned before, I'm not sure if the value for "argv0"
is correct):
% git diff ../Lib/test/test_getpath.py
(main)cpython
diff --git a/Lib/test/test_getpath.py b/Lib/test/test_getpath.py
index 3fb1b28003..69b469f179 100644
--- a/Lib/test/test_getpath.py
+++ b/Lib/test/test_getpath.py
@@ -414,6 +414,36 @@ def test_custom_platlibdir_posix(self):
actual = getpath(ns, expected)
self.assertEqual(expected, actual)
+def test_framework_python(self):
+""" Test framework layout on macOS """
+ns = MockPosixNamespace(
+os_name="darwin",
+
argv0="/Library/Frameworks/Python.framework/Versions/9.8/Resources/Python.app/Contents/MacOS/Python",
+PREFIX="/Library/Frameworks/Python.framework/Versions/9.8",
+
ENV___PYVENV_LAUNCHER__="/Library/Frameworks/Python.framework/Versions/9.8/bin/python9.8",
+
real_executable="/Library/Frameworks/Python.framework/Versions/9.8/Resources/Python.app/Contents/MacOS/Python",
+)
+
ns.add_known_xfile("/Library/Frameworks/Python.framework/Versions/9.8/Resources/Python.app/Contents/MacOS/Python")
+
ns.add_known_xfile("/Library/Frameworks/Python.framework/Versions/9.8/bin/python9.8")
+
ns.add_known_xfile("/Library/Frameworks/Python.framework/Versions/9.8/lib/python9.8/lib-dynload")
+expected = dict(
+
executable="/Library/Frameworks/Python.framework/Versions/9.8/bin/python9.8",
+prefix="/Library/Frameworks/Python.framework/Versions/9.8",
+exec_prefix="/Library/Frameworks/Python.framework/Versions/9.8",
+
base_executable="/Library/Frameworks/Python.framework/Versions/9.8/bin/python9.8",
+base_prefix="/Library/Frameworks/Python.framework/Versions/9.8",
+
base_exec_prefix="/Library/Frameworks/Python.framework/Versions/9.8",
+module_search_paths_set=1,
+module_search_paths=[
+
"/Library/Frameworks/Python.framework/Versions/9.8/lib/python98.zip",
+
"/Library/Frameworks/Python.framework/Versions/9.8/lib/python9.8",
+
"/Library/Frameworks/Python.framework/Versions/9.8/lib/python9.8/lib-dynload",
+],
+)
[issue46890] venv does not create "python" link in python 3.11
Ronald Oussoren added the comment: > This is marked as a release blocker so I am holding the alpha release on > this. Is there anything we can do to unblock this issue? I marked the issue as a release blocker because it must not end up in a beta release, its probably not worth it to hold up an alpha release for this. -- ___ Python tracker <https://bugs.python.org/issue46890> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46891] Crash in ModuleType subclass with __slots__
Ronald Oussoren added the comment: @Pablo: this is a possible release blocker, hard crash for code that works in earlier releases. That said, I have a workaround on my end and IMHO a fix could wait for the next alpha. -- nosy: +pablogsal ___ Python tracker <https://bugs.python.org/issue46891> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46891] Crash in ModuleType subclass with __slots__
Ronald Oussoren added the comment: I don't feel qualified to review the PR, but can confirm that this PR fixes this issue as well as the crash in PyObjC that I extracted my reproducer from. -- ___ Python tracker <https://bugs.python.org/issue46891> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46903] Crash when setting attribute with string subclass as the name (--with-pydebug)
New submission from Ronald Oussoren :
The script below fails with an assertion error with python 3.11a5+ (current
trunk) when build with --with-pydebug:
# BEGIN OF FILE
class String(str):
__slots__ = ()
name = String("hello")
class Bag:
pass
o = Bag()
setattr(o, name, 42)
# END OF FILE
Error output:
% /tmp/py311/bin/python3 -Xdev str.py
(master)pyobjc-8
Assertion failed: (PyUnicode_CheckExact(name)), function
_PyObject_StoreInstanceAttribute, file dictobject.c, line 5426.
Fatal Python error: Aborted
Current thread 0x000100a98580 (most recent call first):
File "/Users/ronald/Projects/pyobjc-8/pyobjc-core/str.py", line 10 in
zsh: abort /tmp/py311/bin/python3 -Xdev str.py
--
components: Interpreter Core
messages: 414386
nosy: ronaldoussoren
priority: normal
severity: normal
status: open
title: Crash when setting attribute with string subclass as the name
(--with-pydebug)
type: crash
versions: Python 3.11
___
Python tracker
<https://bugs.python.org/issue46903>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46903] Crash when setting attribute with string subclass as the name (--with-pydebug)
Ronald Oussoren added the comment: A hard crash seems wrong to me, and I'm not convinced yet that checking that the type of the attribute name is exactly string is correct. Found while debugging a crash in PyObjC's testsuite, PyObjC uses a subclass of str to represent Objective-C strings. Using such instances works fine in practice, but causes a crash in a --with-pydebug build due to this assertion. -- ___ Python tracker <https://bugs.python.org/issue46903> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46914] On Osx Monterey(12.x), Logging.handlers.SysLogHandler does not work
Ronald Oussoren added the comment: This is probably not a bug in python, but a change in system behaviour. In particular, I've used the lsof command to check the open files for the syslogd proces on a macOS 10.13 and 12.2 system. On the former syslogd has /var/run/syslog open, on the latter it doesn't. The feature to listen on this socket has been removed entirely, the 12.2 system no longer lists a "-bsd_in" option for syslogd in the manual page whereas it is both available and enabled by default on 10.13. It might be possible to change the SyslogHandler to optionally use the syslog module to log, but I'm not sure it is worth doing this and that would definitely be a new feature. -- resolution: -> third party type: -> behavior ___ Python tracker <https://bugs.python.org/issue46914> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46928] type.__qualname__ ignores module name in tp_name for static types
New submission from Ronald Oussoren :
In a static type when the "tp_name" is set to a fully qualified name (such as
"my.package.TypeName") the "__qualname__" returns the unqualified name
("TypeName") instead of the fully qualified name.
The type's ``__name__`` and ``__module__`` have the expected value.
This is IMHO a bug in the implementation of type_qualname in
Objects/typeobject.c.
Note that setting ``__qualname__`` in the types's ``__dict__`` doesn't work,
that value is ignored.
--
components: Interpreter Core
messages: 414574
nosy: ronaldoussoren
priority: normal
severity: normal
stage: test needed
status: open
title: type.__qualname__ ignores module name in tp_name for static types
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9
___
Python tracker
<https://bugs.python.org/issue46928>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46928] type.__qualname__ ignores module name in tp_name for static types
Ronald Oussoren added the comment: You're right. I was sure that __qualname__ included the module name, but PEP 3155 is clear about actual semantics. Sorry about the noise. -- resolution: -> not a bug stage: test needed -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46928> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46903] Crash when setting attribute with string subclass as the name (--with-pydebug)
Ronald Oussoren added the comment: Your PR fixed the issue for me. -- resolution: -> fixed stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46903> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46890] venv does not create "python" link in python 3.11
Ronald Oussoren added the comment: I have a patch that seems to do the right thing. It required adding WITH_NEXT_FRAMEWORK to the globals when evaluating getpath.py to detect this scenario. There probably should be more tests, in particular a test for a virtual environment using a framework install as I had to adjust my patch after manually testing a virtual environment. I'm not entirely happy with the patch yet, the change to getpath.py is basically the minimal change I could get away with without grokking the entire file. There's no PR yet as I've broken my fork of cpython, fixing that is next up on the list. BTW. Is there a way to find the values that get put into the globals dict for getpath.py without using a debugger (either a real one or the printf variant)? -- Added file: https://bugs.python.org/file50660/issue-46890.txt ___ Python tracker <https://bugs.python.org/issue46890> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46890] venv does not create "python" link in python 3.11
Ronald Oussoren added the comment: This is also dodgy: test_framework_macos (test.test_getpath.MockGetPathTests) ... Read link from /Library/Frameworks/Python.framework/Versions/9.8/Resources/Python.app/Contents/MacOS/Python Check if /Library/Frameworks/Python.framework/Versions/9.8/Resources/Python.app/Contents/MacOS/Modules/Setup.local is a file Check if /Library/Frameworks/Python.framework/Versions/9.8/lib/python98.zip is a file Check if /Library/Frameworks/Python.framework/Versions/lib/python98.zip is a file Check if /Library/Frameworks/Python.framework/lib/python98.zip is a file Check if /Library/Frameworks/lib/python98.zip is a file Check if /Library/lib/python98.zip is a file Check if /Library/Frameworks/Python.framework/Versions/9.8/lib/python9.8/os.py is a file Check if /Library/Frameworks/Python.framework/Versions/9.8/bin/lib/python9.8/lib-dynload is a dir Check if /Library/Frameworks/Python.framework/Versions/9.8/lib/python9.8/lib-dynload is a dir Note how the code checks for the standard library outside of the framework itself. -- ___ Python tracker <https://bugs.python.org/issue46890> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46890] venv does not create "python" link in python 3.11
Ronald Oussoren added the comment:
I'm now in the fun position where the code works, but the test test_getpath.py
fails.
The test case below tries to test a venv in a framework build, but somehow
fails to calculate prefix and exec_prefix correctly. The calculation does work
when using a framework build with my patch...
def test_venv_framework_macos(self):
"""Test a venv layout on macOS using a framework build
"""
venv_path = "/tmp/workdir/venv"
ns = MockPosixNamespace(
os_name="darwin",
argv0="/Library/Frameworks/Python.framework/Versions/9.8/Resources/Python.app/Contents/MacOS/Python",
WITH_NEXT_FRAMEWORK=1,
PREFIX="/Library/Frameworks/Python.framework/Versions/9.8",
EXEC_PREFIX="/Library/Frameworks/Python.framework/Versions/9.8",
ENV___PYVENV_LAUNCHER__=f"{venv_path}/bin/python",
real_executable="/Library/Frameworks/Python.framework/Versions/9.8/Resources/Python.app/Contents/MacOS/Python",
library="/Library/Frameworks/Python.framework/Versions/9.8/Python",
)
ns.add_known_dir(venv_path)
ns.add_known_xfile(f"{venv_path}/bin/python")
ns.add_known_dir(f"{venv_path}/lib/python9.8")
ns.add_known_xfile("/Library/Frameworks/Python.framework/Versions/9.8/Resources/Python.app/Contents/MacOS/Python")
ns.add_known_xfile("/Library/Frameworks/Python.framework/Versions/9.8/bin/python9.8")
ns.add_known_dir("/Library/Frameworks/Python.framework/Versions/9.8/lib/python9.8/lib-dynload")
ns.add_known_xfile("/Library/Frameworks/Python.framework/Versions/9.8/lib/python9.8/os.py")
ns.add_known_file(f"{venv_path}/pyvenv.cfg", [
"home = /Library/Frameworks/Python.framework/Versions/9.8/bin"
])
expected = dict(
executable=f"{venv_path}/bin/python",
prefix=venv_path,
exec_prefix=venv_path,
base_executable="/Library/Frameworks/Python.framework/Versions/9.8/bin/python9.8",
base_prefix="/Library/Frameworks/Python.framework/Versions/9.8",
base_exec_prefix="/Library/Frameworks/Python.framework/Versions/9.8",
module_search_paths_set=1,
module_search_paths=[
"/Library/Frameworks/Python.framework/Versions/9.8/lib/python98.zip",
"/Library/Frameworks/Python.framework/Versions/9.8/lib/python9.8",
"/Library/Frameworks/Python.framework/Versions/9.8/lib/python9.8/lib-dynload",
],
)
actual = getpath(ns, expected)
self.assertEqual(expected, actual)
--
___
Python tracker
<https://bugs.python.org/issue46890>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46890] venv does not create "python" link in python 3.11
Ronald Oussoren added the comment: I've attached a new patch file with some more tweaks, including the additional test case from msg414665. I've pretty sure that the changes to getpath.py are slightly worse in the new version, but aren't fully correct in the initial version as well (see my previous message about searching outside of the framework). I may return to this later when I have time to try to really understand what's going on and compare the logic with the previous C code (especially for framework builds). But for now I'm giving up. -- Added file: https://bugs.python.org/file50662/issue-46890-v2.txt ___ Python tracker <https://bugs.python.org/issue46890> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1779871] Make python build with gcc-4.2 on OS X 10.4.9
Ronald Oussoren added the comment: Why does you patch test for -mno-fused-madd? If it isn't actually needed for something I'd rather not have that logic in the configure file, determining which bits of that file are actually needed for supported OS-es is hard enough as it is. -Wno-long-double is needed when compiling on old versions of OSX, where "long double" worked but wasn't actually useful. Keeping that option seems to be harmless. -no-cpp-precomp was necessary for several packages on older releases of OSX. I'll test on a 10.3 box when I have time (which is the oldest I can test on). -- assignee: -> ronaldoussoren nosy: +ronaldoussoren _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1779871> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1779871] Make python build with gcc-4.2 on OS X 10.4.9
Ronald Oussoren added the comment:
jyasskin: could you test apple_gcc_flags.diff? That's a version of your
patch where configure tests if GCC supports -Wno-long-double and -no-
cpp-precomp.
NOTE: the patch doesn't update configure, you'll have to run autoconf
after applying it.
NOTE2: the patch is relative to python's trunk, but should apply to
2.5.x as well.
--
resolution: -> accepted
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1779871>
_Index: configure.in
===
--- configure.in(revision 57620)
+++ configure.in(working copy)
@@ -818,7 +818,45 @@
;;
# is there any other compiler on Darwin besides gcc?
Darwin*)
- BASECFLAGS="$BASECFLAGS -Wno-long-double -no-cpp-precomp
-mno-fused-madd"
+ BASECFLAGS="$BASECFLAGS -no-cpp-precomp -mno-fused-madd"
+
+ # Earlier versions of Xcode/DeveloperTools shipped with GCC 3.x
+ # which warned about using "long double". That warning is
+ # surpressed using -Wno-long-double, but that flag is not
+ # available in stock GCC
+ AC_MSG_CHECKING(whether $CC accepts -Wno-long-double)
+ ac_save_cc="${CC}"
+ CC="${CC} -Wno-long-double"
+ AC_TRY_RUN([int main(void) { return 0; }],
+ ac_cv_no_long_double_ok=yes,
+ ac_cv_no_long_double_ok=no,
+ ac_cv_no_long_double_ok=no)
+ CC="$ac_save_cc"
+ AC_MSG_RESULT($ac_cv_no_long_double_ok)
+ if test $ac_cv_no_long_double_ok = yes; then
+ BASECFLAGS="$BASECFLAGS -Wno-long-double"
+fi
+
+ # Even earlier versions of Apple's GCC (appearently before
+ # GCC 3.1) sported a broken implementation of precompiled headers,
+ # -no-cpp-precomp disables that functionality, but isn't supported
+ # by stock GCC.
+ # XXX: need to check which version of OSX/DeveloperTools ships
+ # with this broken version of GCC, if that's old enough we can
+ # drop this check.
+ AC_MSG_CHECKING(whether $CC accepts -no-cpp-precomp)
+ ac_save_cc="${CC}"
+ CC="${CC} -no-cpp-precomp"
+ AC_TRY_RUN([int main(void) { return 0; }],
+ ac_cv_no_precomp_ok=yes,
+ ac_cv_no_precomp_ok=no,
+ ac_cv_no_precomp_ok=no)
+ CC="$ac_save_cc"
+ AC_MSG_RESULT($ac_cv_no_precomp_ok)
+ if test $ac_cv_no_precomp_ok = yes; then
+ BASECFLAGS="$BASECFLAGS -no-cpp-precomp"
+fi
+
if test "${enable_universalsdk}"; then
BASECFLAGS="-arch ppc -arch i386 -isysroot ${UNIVERSALSDK}
${BASECFLAGS}"
fi
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1779871] Make python build with gcc-4.2 on OS X 10.4.9
Changes by Ronald Oussoren: _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1779871> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1779871] Make python build with gcc-4.2 on OS X 10.4.9
Changes by Ronald Oussoren: _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1779871> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1402] Interpreter cleanup: order of _PyGILState_Fini and PyInterpreterState_Clear
New submission from Ronald Oussoren:
Py_Finalize cleans up the thread state by first calling _PyGILState_Fini
and then calling PyInterpreterState_Clear. The latter can cause user
code to run, which could use the GILState API and this then causes a
crash.
The attached file 'threads.py' causes a crash on OSX leopard because of
this issue. The script causes an exception to be set that has an
attribute that uses the GILState API in its dealloc slot.
--
components: Interpreter Core
files: threads.py
messages: 57225
nosy: ronaldoussoren
priority: normal
severity: normal
status: open
title: Interpreter cleanup: order of _PyGILState_Fini and
PyInterpreterState_Clear
type: crash
versions: Python 2.5
Added file: http://bugs.python.org/file8710/threads.py
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1402>
__from Foundation import *
import threading
class MyObject (NSObject):
def myMethod_(self, dummy):
print dummy
raise RuntimeError("hello")
obj = MyObject.new()
class MyThread(threading.Thread):
def run(self):
while True:
pool = NSAutoreleasePool.alloc().init()
print "Doit!"
obj.performSelectorOnMainThread_withObject_waitUntilDone_(
'myMethod:', [], True)
print "Result is in"
del pool
t = MyThread()
t.setDaemon(1)
t.start()
loop = NSRunLoop.currentRunLoop()
try:
loop.run()
except:
print "Exception!"
print "Ready!"
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1402] Interpreter cleanup: order of _PyGILState_Fini and PyInterpreterState_Clear
Ronald Oussoren added the comment: I don't have a patch. I don't even know enough of the threading infrastructure to know if this really a bug or if it is a bug in my code. I'll work on a patch this weekend, if changing the order of calls to PyGILState_Fini and PyInterpreterState_Clear doesn't break unittests and fixes the problem I ran into I'll post about this issue on python-dev. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1402> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1402] Interpreter cleanup: order of _PyGILState_Fini and PyInterpreterState_Clear
Ronald Oussoren added the comment: The attached patch fixes the crash, but I haven't verified if the patch is actually correct. With this patch some PyThread API's are called after PyInterpreterState_Clear and I don't know if it is valid to do so. All unittests pass fine on OSX though. Added file: http://bugs.python.org/file8793/pygilstate.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1402> __Index: Python/pythonrun.c === --- Python/pythonrun.c (revision 59115) +++ Python/pythonrun.c (working copy) @@ -437,14 +437,15 @@ _Py_PrintReferences(stderr); #endif /* Py_TRACE_REFS */ + + /* Clear interpreter state */ + PyInterpreterState_Clear(interp); + /* Cleanup auto-thread-state */ #ifdef WITH_THREAD _PyGILState_Fini(); #endif /* WITH_THREAD */ - /* Clear interpreter state */ - PyInterpreterState_Clear(interp); - /* Now we decref the exception classes. After this point nothing can raise an exception. That's okay, because each Fini() method below has been checked to make sure no exceptions are ever ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1402] Interpreter cleanup: order of _PyGILState_Fini and PyInterpreterState_Clear
Ronald Oussoren added the comment: This is not a mac-specific issue, the script happens to be mac-specific because that's how I found the issue. Amaury's patch adds a unittest that reproduces the problem in a platform-indepenent way using ctypes. The _PyGILState_Fini function might cause user code to run as well, it removes the thread-local variable that contains the PyThreadState for threads, and that contains some Python objects that might contain arbitrary values (such as the last exception value). I guess that means that a variation on Amaury's patch would cause a patched interpreter to crash (create on instance of 'C' as an attribute on an exception, e.g. raise ValueError(C()) in the second thread). BTW. I would be very uncomfortable if my patch were applied without review from someone that knows his way around the threading code. BTW2. I have a workaround for my initial issue (the crash in threads.py): if I add an atexit handler that performs some cleanup in PyObjC the problem goes away. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1402> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12990] launcher can't work on path including tradition chinese char
New submission from Ronald Oussoren : Could you please add some more information on how I can reproduce this issue? -- stage: -> test needed type: -> behavior ___ Python tracker <http://bugs.python.org/issue12990> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10881] test_site and macframework builds fails
Ronald Oussoren added the comment: On 11 Oct, 2011, at 22:28, Ned Deily wrote: > > Ned Deily added the comment: > > I forgot to mention that one advantage of using another framework and root > location, say, under your home directory somewhere, is that it is unnecessary > to use sudo. And you don't need to use the special target in any case, > simply "make install". Make install always works, the frameworkinstall target is a leftover from a time when you couldn't use "make install". -- Added file: http://bugs.python.org/file23438/smime.p7s ___ Python tracker <http://bugs.python.org/issue10881> ___ smime.p7s Description: S/MIME cryptographic signature ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13315] tarfile extract fails on OS X system python due to chown of gid=-1
Ronald Oussoren added the comment: There's little chance that Apple will fix this issue in their build (at least not until Lion+1 gets released) because this is not a security bug. Their breaking of 2.7 in Lion is probably due to lack of review for their collection of patches, and is not something we can fix. I'd close this as invalid as the issue is already fixed in our codebase. I won't file a bug at Apple for this, although that shouldn't stop anyone else from doing so (and remember: bugreport.apple.com is a popularity contest, the more people file an report about a bug the more likely it is that it will get fixed) -- status: pending -> open ___ Python tracker <http://bugs.python.org/issue13315> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13370] test_ctypes fails on osx 10.7
New submission from Ronald Oussoren : test_ctypes fails when building and testing on OSX 10.7 (Lion). This is likely caused by changes in the compiler w.r.t. the calling convention. I've worked around this problem in PyObjC, and will try to port that workaround to ctypes. BTW. Using --with-system-ffi does not fix the issue for me -- assignee: ronaldoussoren components: Macintosh, ctypes messages: 147299 nosy: ronaldoussoren priority: normal severity: normal stage: needs patch status: open title: test_ctypes fails on osx 10.7 type: behavior versions: Python 2.7, Python 3.2, Python 3.3 ___ Python tracker <http://bugs.python.org/issue13370> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13370] test_ctypes fails on osx 10.7
Ronald Oussoren added the comment:
I should have included the failures in my first message, sorry about that.
IIRC the workaround in PyObjC I mention in my initial message does explicit
sign extension when needed.
W.r.t to the first couple of failures, not that:
struct.unpack('b', struct.pack('B', 130)) == (-126,)
==
FAIL: test_byte (ctypes.test.test_cfuncs.CFunctions)
--
Traceback (most recent call last):
File
"/Library/Frameworks/PythonDev.framework/Versions/2.7/lib/python2.7/ctypes/test/test_cfuncs.py",
line 21, in test_byte
self.assertEqual(self.S(), -126)
AssertionError: 130 != -126
==
FAIL: test_byte_plus (ctypes.test.test_cfuncs.CFunctions)
--
Traceback (most recent call last):
File
"/Library/Frameworks/PythonDev.framework/Versions/2.7/lib/python2.7/ctypes/test/test_cfuncs.py",
line 27, in test_byte_plus
self.assertEqual(self.S(), -126)
AssertionError: 130 != -126
==
FAIL: test_short (ctypes.test.test_cfuncs.CFunctions)
--
Traceback (most recent call last):
File
"/Library/Frameworks/PythonDev.framework/Versions/2.7/lib/python2.7/ctypes/test/test_cfuncs.py",
line 45, in test_short
self.assertEqual(self.S(), -32766)
AssertionError: 32770 != -32766
==
FAIL: test_short_plus (ctypes.test.test_cfuncs.CFunctions)
--
Traceback (most recent call last):
File
"/Library/Frameworks/PythonDev.framework/Versions/2.7/lib/python2.7/ctypes/test/test_cfuncs.py",
line 51, in test_short_plus
self.assertEqual(self.S(), -32766)
AssertionError: 32770 != -32766
==
FAIL: test_doubleresult (ctypes.test.test_functions.FunctionTestCase)
--
Traceback (most recent call last):
File
"/Library/Frameworks/PythonDev.framework/Versions/2.7/lib/python2.7/ctypes/test/test_functions.py",
line 143, in test_doubleresult
self.assertEqual(result, -21)
AssertionError: 65771.0 != -21
==
FAIL: test_floatresult (ctypes.test.test_functions.FunctionTestCase)
--
Traceback (most recent call last):
File
"/Library/Frameworks/PythonDev.framework/Versions/2.7/lib/python2.7/ctypes/test/test_functions.py",
line 131, in test_floatresult
self.assertEqual(result, -21)
AssertionError: 65771.0 != -21
==
FAIL: test_intresult (ctypes.test.test_functions.FunctionTestCase)
--
Traceback (most recent call last):
File
"/Library/Frameworks/PythonDev.framework/Versions/2.7/lib/python2.7/ctypes/test/test_functions.py",
line 105, in test_intresult
self.assertEqual(result, -21)
AssertionError: 65771 != -21
==
FAIL: test_longdoubleresult (ctypes.test.test_functions.FunctionTestCase)
--
Traceback (most recent call last):
File
"/Library/Frameworks/PythonDev.framework/Versions/2.7/lib/python2.7/ctypes/test/test_functions.py",
line 155, in test_longdoubleresult
self.assertEqual(result, -21)
AssertionError: 65771.0 != -21
--
___
Python tracker
<http://bugs.python.org/issue13370>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13371] Some Carbon extensions don't build on OSX 10.7
New submission from Ronald Oussoren : A number of Carbon wrapper modules don't build on OSX 10.7: $ make ... Failed to build these modules: _Fm_Qd_Qdoffs This is with '--with-universal-archs=intel', which worked fine on OSX 10.6. A short part of the compiler output: /Users/ronald/Projects/python/rw/2.7/Mac/Modules/fm/_Fmmodule.c:26: error: expected ‘)’ before ‘*’ token /Users/ronald/Projects/python/rw/2.7/Mac/Modules/fm/_Fmmodule.c: In function ‘Fm_GetFontName’: /Users/ronald/Projects/python/rw/2.7/Mac/Modules/fm/_Fmmodule.c:60: error: ‘GetFontName’ undeclared (first use in this function) /Users/ronald/Projects/python/rw/2.7/Mac/Modules/fm/_Fmmodule.c:60: error: (Each undeclared identifier is reported only once /Users/ronald/Projects/python/rw/2.7/Mac/Modules/fm/_Fmmodule.c:60: error: for each function it appears in.) /Users/ronald/Projects/python/rw/2.7/Mac/Modules/fm/_Fmmodule.c:65: warning: implicit declaration of function ‘GetFontName’ /Users/ronald/Projects/python/rw/2.7/Mac/Modules/fm/_Fmmodule.c: In function ‘Fm_GetFNum’: /Users/ronald/Projects/python/rw/2.7/Mac/Modules/fm/_Fmmodule.c:78: error: ‘GetFNum’ undeclared (first use in this function) /Users/ronald/Projects/python/rw/2.7/Mac/Modules/fm/_Fmmodule.c:83: warning: implicit declaration of function ‘GetFNum’ /Users/ronald/Projects/python/rw/2.7/Mac/Modules/fm/_Fmmodule.c: In function ‘Fm_RealFont’: /Users/ronald/Projects/python/rw/2.7/Mac/Modules/fm/_Fmmodule.c:97: error: ‘RealFont’ undeclared (first use in this function) /Users/ronald/Projects/python/rw/2.7/Mac/Modules/fm/_Fmmodule.c:103: warning: implicit declaration of function ‘RealFont’ /Users/ronald/Projects/python/rw/2.7/Mac/Modules/fm/_Fmmodule.c: In function ‘Fm_SetFScaleDisable’: /Users/ronald/Projects/python/rw/2.7/Mac/Modules/fm/_Fmmodule.c:115: error: ‘SetFScaleDisable’ undeclared (first use in this function) /Users/ronald/Projects/python/rw/2.7/Mac/Modules/fm/_Fmmodule.c:120: warning: implicit declaration of function ‘SetFScaleDisable’ /Users/ronald/Projects/python/rw/2.7/Mac/Modules/fm/_Fmmodule.c: In function ‘Fm_FontMetrics’: /Users/ronald/Projects/python/rw/2.7/Mac/Modules/fm/_Fmmodule.c:129: error: ‘FMetricRec’ undeclared (first use in this function) /Users/ronald/Projects/python/rw/2.7/Mac/Modules/fm/_Fmmodule.c:129: error: expected ‘;’ before ‘theMetrics’ Given the modules and failure it seems that a number of (long) deprecated Carbon functions got removed from Apple's header files. -- assignee: ronaldoussoren components: Macintosh messages: 147304 nosy: ronaldoussoren priority: normal severity: normal stage: needs patch status: open title: Some Carbon extensions don't build on OSX 10.7 type: compile error versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue13371> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13371] Some Carbon extensions don't build on OSX 10.7
Ronald Oussoren added the comment: _Fm fails because the wrapped functionality is no longer present in the Headers (last seen in the QD.framework headers in the 10.6 SDK) likewise for _Qdoffs and _Qd. The attached patch changed the preprocessor guards around these bindings from #ifndef __LP64__ To: #if !defined(__LP64__) && !defined(MAC_OS_X_VERSION_10_7) That is, disable the bindings for these deprecated APIs when building for 64-bit code or when building with the 10.7 SDK (or later). There is a small risk with this patch: I'm not 100% sure that Apple will refrain from adding a definition for MAC_OS_X_VERSION_10_7 in a later release of the 10.6 SDK. -- keywords: +patch nosy: +ned.deily stage: needs patch -> patch review Added file: http://bugs.python.org/file23633/issue13371.txt ___ Python tracker <http://bugs.python.org/issue13371> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13241] llvm-gcc-4.2 miscompiles Python (XCode 4.1 on Mac OS 10.7)
Ronald Oussoren added the comment:
The bug in the 'gcc' command is still present when using Xcode 4.2.1 (that is,
the attached unicode.c miscompiles with "gcc -O3").
Clang (again from Xcode 4.2.1) compiles the file correctly, but fails to do a
proper build the last few lines of the build log:
clang -bundle -undefined dynamic_lookup
build/temp.macosx-10.4-x86_64-3.3/Users/ronald/Projects/python/rw/cpython/Modules/_cursesmodule.o
-L/usr/local/lib -lncurses -o build/lib.macosx-10.4-x86_64-3.3/_curses.so
/bin/sh: line 1: 84213 Segmentation fault: 11 CC='clang' LDSHARED='clang
-bundle -undefined dynamic_lookup ' OPT='-DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes' ./python.exe -E ./setup.py build
make: *** [sharedmods] Error 139
The last bit of a gdb stack trace:
#0 0x7fff86cd94f0 in strlen ()
#1 0x00010005bee1 in PyUnicode_FromString (u=0x4c ) at unicodeobject.c:1735
#2 0x00010003bb65 in PyDict_GetItemString (v=0x10075cc58, key=) at dictobject.c:2187
#3 0x00010004eaf8 in add_getset [inlined] () at
/Users/ronald/Projects/python/rw/cpython/Objects/typeobject.c:3771
#4 0x00010004eaf8 in PyType_Ready (type=0x10159efb8) at typeobject.c:4109
#5 0x00010159209a in PyInit__curses () at
/Users/ronald/Projects/python/rw/cpython/Modules/_cursesmodule.c:3293
#6 0x0001000c0e20 in _PyImport_LoadDynamicModule (name=0x1010f9f80,
path=0x10074c750, fp=) at
importdl.c:85
#7 0x0001000beca0 in imp_load_dynamic (self=, args=) at import.c:3804
#8 0x00010009f0c8 in call_function [inlined] () at
/Users/ronald/Projects/python/rw/cpython/Python/ceval.c:4003
For some reason a clean rebuild got a failure in another location, this time in
the Py_XDECREF call on line 2966 in ceval.c:
while (!EMPTY()) {
v = POP();
Py_XDECREF(v);
}
Due to the optimization level I couldn't get more information.
When I patch the Makefile to use '-O2' instead of '-O3' in CFLAGS the problems
stays (obviously with full rebuild).
Patching the optimization level down to '-O1' gives a slightly better result,
this time I get:
./python.exe -SE -m sysconfig --generate-posix-vars
Fatal Python error: Py_Initialize: unable to load the file system codec
SystemError: NULL result without error in PyObject_Call
BTW. I tried to build with srcdir==builddir and "./configure CC=clang" on an
up-to-date OSX 10.7 system with Xcode 4.2.1.
Summary of compiler results:
- gcc-4.2 (i686-apple-darwin11-gcc-4.2.1): unicode.c OK, build OK
- gcc (i686-apple-darwin11-llvm-gcc-4.2):unicode.c fails, build fails
- clang: unicode.c OK, build fails
--
nosy: +ronaldoussoren
type: -> compile error
___
Python tracker
<http://bugs.python.org/issue13241>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13511] Specifying multiple lib and include directories on linux
Ronald Oussoren added the comment:
He's probably referring to this fragment in setup.py:
if platform == 'darwin':
# This should work on any unixy platform ;-)
# If the user has bothered specifying additional -I and -L flags
# in OPT and LDFLAGS we might as well use them here.
# NOTE: using shlex.split would technically be more correct, but
# also gives a bootstrap problem. Let's hope nobody uses directories
# with whitespace in the name to store libraries.
cflags, ldflags = sysconfig.get_config_vars(
'CFLAGS', 'LDFLAGS')
for item in cflags.split():
if item.startswith('-I'):
inc_dirs.append(item[2:])
for item in ldflags.split():
if item.startswith('-L'):
lib_dirs.append(item[2:])
The entire block was added when I worked on the Mac port with Jack Jansen. It
ensures that additional include and lib directories specified through the 'OPT'
and 'LDFLAGS' shell variables get added to the search path used by distutils.
As the comment says this should be safe all unity platforms, not just OSX.
IIRC the platform test is there because we couldn't easily test on other
platforms and didn't want to accidentally break stuff (this was before we had a
good buildbot setup).
--
___
Python tracker
<http://bugs.python.org/issue13511>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13241] llvm-gcc-4.2 miscompiles Python (XCode 4.1 on Mac OS 10.7)
Ronald Oussoren added the comment: The version of clang included in Xcode 4.2.1 (the current release) still miscompiles Python 3.3 and both C files included in this issue. The same is true for the Xcode 4.3 beta. Python 2.7 seems to work fine with the same compiler, either because we don't trigger the bug or it fails in a more subtle way than crashing. Has anyone filed a bug with Apple and/or the clang developers? -- ___ Python tracker <http://bugs.python.org/issue13241> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13241] llvm-gcc-4.2 miscompiles Python (XCode 4.1 on Mac OS 10.7)
Ronald Oussoren added the comment: I've filed an issue in Apple's tracker, #10667893. Filing more issues would be helpful, if more issues in their tracker mention this bug it is more likely to get fixed. -- ___ Python tracker <http://bugs.python.org/issue13241> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13241] llvm-gcc-4.2 miscompiles Python (XCode 4.1 on Mac OS 10.7)
Ronald Oussoren added the comment:
I've found a bug in the curses module that is causing problems:
diff --git a/Modules/_cursesmodule.c b/Modules/_cursesmodule.c
--- a/Modules/_cursesmodule.c
+++ b/Modules/_cursesmodule.c
@@ -2056,7 +2056,8 @@
{"encoding",
(getter)PyCursesWindow_get_encoding,
(setter)PyCursesWindow_set_encoding,
- "the typecode character used to create the array"}
+ "the typecode character used to create the array"},
+{NULL, NULL, NULL, NULL}
};
/* ---*/
That is, there is no sentinel in the PyCursesWindow_getsets list. Shouldn't
this cause failures on more platforms than just OSX?
With this patch I can build python 3.3 with clang (as included in Xcode 4.2.1).
BTW. clang as included with Xcode 4.2.1 seems to build the attached copy of
unicode.c without problems, the gcc command still fails though.
I did run into problems when building outside of the source directory, but that
seems to be an unrelated issue.
--
keywords: +needs review, patch
Added file: http://bugs.python.org/file24206/issue13241.patch
___
Python tracker
<http://bugs.python.org/issue13241>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13241] llvm-gcc-4.2 miscompiles Python (XCode 4.1 on Mac OS 10.7)
Ronald Oussoren added the comment: Both clang and llvm-gcc had problems, the llvm-gcc problem is still there and is caused by a compiler bug. There is nothing we can do about that beyond warning Apple. It's also pretty clear that llvm-gcc (and gcc in general) is on the way out as the system compiler on OSX. It's therefore unlikely that the compiler bug we ran into will get fixed. I'm leaning towards adding code to configure that either tests for this issue and refers to documentation in Mac/README (also to be added) when this bug is found, or just switches to clang instead of gcc as the default compiler when a recent version of Xcode is detected (and 'CC' is not set in the environment). -- ___ Python tracker <http://bugs.python.org/issue13241> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11623] Distutils is reporting OSX 10.6 w/ XCode 4 as "universal"
Ronald Oussoren added the comment: I don't agree that distutils should autodetect architectures, that can result in silent behavior changes when you built extensions and assume ppc support will get compiled in. We should probably start to mention the intel only builds more prominently though, that's the one that will be useful to most people at this time. -- ___ Python tracker <http://bugs.python.org/issue11623> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11623] Distutils is reporting OSX 10.6 w/ XCode 4 as "universal"
Ronald Oussoren added the comment: What 10.7? ;-) Please remember 10.7 is under NDA, and as such shouldn't be discussed in public. As I mentioned earlier: the 32-bit build should be deprecated and is only needed for older machines, anyone running modern machines can install OSX 10.6 (or later) and can use the intel-only build. -- ___ Python tracker <http://bugs.python.org/issue11623> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11277] Crash with mmap and sparse files on Mac OS X
Ronald Oussoren added the comment:
Steffen: _mac_ver_xml should not be dropped, it is a perfectly fine way to
determine the system version. Discussing it is also off-topic for this issue,
please keep the discussion focussed.
Wrt. mailing Apple: I wouldn't expect and answer. Is there something specific
you want to know? I'm currently at WWDC and might be able to ask the question
at one of the labs (where Apple's engineers hang out).
If it is really necessary to check for the OS version to enable the
OSX-specific bugfix it is possible to look at the uname information instead of
using gestalt. In particular something simular to this Python code:
v = os.uname()[2]
major = int(v.split('.')[0])
if major <= 10:
# We're on OSX 10.6 or earlier
enableWorkaround()
This tests the kernel version instead of the system version, but until now the
major version of the kernel has increased with every major release of the OS
and I have no reason to suspect that Lion will be any different.
BTW2: OSX 10.7 is not released yet and should not be discussed in public fora,
as you should know if you have legal access.
--
___
Python tracker
<http://bugs.python.org/issue11277>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11277] Crash with mmap and sparse files on Mac OS X
Ronald Oussoren added the comment: steffen: I have no idea what you are trying to say in your last message. Could you please try to stay on topic. -- ___ Python tracker <http://bugs.python.org/issue11277> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9344] please add posix.getgrouplist()
Ronald Oussoren added the comment: I haven't tested yet, but feel free to commit and I'll fix any OSX issues later. -- ___ Python tracker <http://bugs.python.org/issue9344> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9516] sysconfig: $MACOSX_DEPLOYMENT_TARGET mismatch: now "10.3" but "10.5" during configure
Ronald Oussoren added the comment: I agree with Ned, the changes to the environment should only be done in subprocesses started by distutils. The patch looks fine, but I haven't tested the patches yet. -- ___ Python tracker <http://bugs.python.org/issue9516> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8716] test_tk/test_tkk_guionly fails on OS X if run from buildbot slave daemon -- crashes Python
Ronald Oussoren added the comment: python2.7 has MacOS.WMAvailable(). When that function returns False the Tkinter tests should be disabled. The function is not available in Python 3, but is easy enough to implement using ctypes. -- ___ Python tracker <http://bugs.python.org/issue8716> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10910] pyport.h FreeBSD/Mac OS X "fix" causes errors in C++ compilation
Ronald Oussoren added the comment: Waiting for a new version of boost probably won't help: this is an incompatibility between a redefinition of ctypes macros in pyport.h and definitions in the C++ header . I barely use C++ at this time and don't know how to tweak the headers to avoid this problem. It would probably have been better to not redefine the ctype.h definitions, we should have introduced Py_isascii etc. That requires some invasive changes to the Python codebase though, and I'm not sure if that is worth the trouble. Could someone attach a sample project that suffers from this issue (with instructions on how to build it)? That would make it easier to debug the problem. (Removing python 2.6 because that version receives only security patches at this time, adding 3.2 and 3.3 because those use the same code in pyport.h and hence should also be affected by this issue) -- versions: +Python 3.2, Python 3.3 -Python 2.6 ___ Python tracker <http://bugs.python.org/issue10910> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10731] UnicodeDecodeError in OS X tkinter when binding to
Ronald Oussoren added the comment: This is almost certainly a bug in Tk. What OSX version are you using, and which python installer did you use? One thing you could try is installing a matching copy of ActiveState's Tk (8.4 for the 32-bit build, 8.5 for intel-only builds of python 2.7 and 3.2) -- ___ Python tracker <http://bugs.python.org/issue10731> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12701] Apple's clang 2.1 (xcode 4.1, OSX 10.7) optimizer miscompiles intobject.c
Ronald Oussoren added the comment: Have you checked if -fwrapv is in the list of compiler arguments in the generated makefile? There is an open issue about adding that flag when clang is used as the compiler (the flag is already used for gcc). The flag is necessary because the example code contains an integer overflow and that is undefined behavior according to the C standard. -- Added file: http://bugs.python.org/file22866/unnamed ___ Python tracker <http://bugs.python.org/issue12701> ___Have you checked if -fwrapv is in the list of compiler arguments in the generated makefile?There is an open issue about adding that flag when clang is used as the compiler (the flag is already used for gcc). The flag is necessary because the example code contains an integer overflow and that is undefined behavior according to the C standard. ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12701] Apple's clang 2.1 (xcode 4.1, OSX 10.7) optimizer miscompiles intobject.c
Ronald Oussoren added the comment: Clang has an option "-fcatch-undefined-behavior" that might help in locating other locations where we use undefined behavior. -- ___ Python tracker <http://bugs.python.org/issue12701> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9568] test_urllib2_localnet fails on OS X 10.3
Ronald Oussoren added the comment: Barry: I agree with Ned that this is low-risk patch. The patch changes a default return value in a code-path that is used on OSX 10.3 to make it the same as the default value on the code-path for other OSX releases. I'm therefore +1 on applying this for 2.6.6, but won't apply without explicit permission to do so. -- ___ Python tracker <http://bugs.python.org/issue9568> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9516] sysconfig: $MACOSX_DEPLOYMENT_TARGET mismatch: now "10.3" but "10.5" during configure
Ronald Oussoren added the comment: Assigning to myself because I intend to work on this. More questions: does the error occur on the 10.6 machine you used to do the build or another machine? Is MACOSX_DEPLOYMENT_TARGET set in the environment when you run the command that gives the error message? -- assignee: tarek -> ronaldoussoren ___ Python tracker <http://bugs.python.org/issue9516> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9581] PosixGroupsTester fails as root
Ronald Oussoren added the comment: I won't have time to look at this until sunday. Alexander Belopolsky wrote these patch tests. Alexanders: do you have time to look into this? -- nosy: +belopolsky ___ Python tracker <http://bugs.python.org/issue9581> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9610] buildbot: uncaptured python exception (smtpd), but no failure in regrtest
Ronald Oussoren added the comment: Could this be related to Issue5154? I've noticed in the past that some asyncore/asychat tests print stacktraces as well, all of them in the testcases that use poll instead of select. -- ___ Python tracker <http://bugs.python.org/issue9610> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8857] socket.getaddrinfo needs tests
Ronald Oussoren added the comment: I think there is a missing '0' in the failing line: Index: Lib/test/test_socket.py === --- Lib/test/test_socket.py (revision 84079) +++ Lib/test/test_socket.py (working copy) @@ -608,7 +608,7 @@ for _, socktype, _, _, _ in infos: self.assertEqual(socktype, socket.SOCK_STREAM) # test proto and flags arguments -socket.getaddrinfo(HOST, None, 0, 0, socket.AI_CANONNAME) +socket.getaddrinfo(HOST, None, 0, 0, 0, socket.AI_CANONNAME) socket.getaddrinfo(HOST, None, 0, 0, 0, socket.AI_PASSIVE) # a server willing to support both IPv4 and IPv6 will # usually do this With this patch the tests pass, without the patch AI_CANNAME gets used as the value for 'proto'. -- ___ Python tracker <http://bugs.python.org/issue8857> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8857] socket.getaddrinfo needs tests
Ronald Oussoren added the comment: There is one thing I don't understand about these tests: they basicly only seem to test if the function implements the right interface (argument counts and the structure of the return value). Shouldn't the tests also test if the behaviour is somewhat sane? One example of this: test the 'family' flag by looking for www.google.com with both AF_INET and AF_INET6 and then check that the first returns IPv4 information and the second IPv6. -- ___ Python tracker <http://bugs.python.org/issue8857> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9189] Improve CFLAGS handling
Ronald Oussoren added the comment: issue9047 is related to the issue Stefan mentions -- ___ Python tracker <http://bugs.python.org/issue9189> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9584] Allow curly braces in fnmatch
Ronald Oussoren added the comment:
I agree with Antoine that this would be useful functionality and that matching
"the" shell is futile here.
A quick check on an old linux server: bash and ksh do brace expansion before
expanding '*', but that csh does both at the same time.
That is, in a directory with foo.py and no .h files 'echo *.{py,h}' returns
foo.py with csh and '*.h foo.py' with bash.
I'm +1 on matching the behavior of csh here.
--
nosy: +ronaldoussoren
___
Python tracker
<http://bugs.python.org/issue9584>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9516] sysconfig: $MACOSX_DEPLOYMENT_TARGET mismatch: now "10.3" but "10.5" during configure
Ronald Oussoren added the comment:
I can reproduce this with a script that builds and installs a couple of python
versions, annoyingly enough I don't understand why that code fails.
In particular, in my script the run of python that fails is started with this
code:
lg.debug("Run setup script with '%s'", python)
pprint.pprint(os.environ)
p = subprocess.Popen([
python, "setup.py", "install"],
cwd=distribute_dir, stdout=subprocess.PIPE,
stderr=subprocess.STDOUT)
This prints the environment and then runs a setup.py script. What confuses me
is that the printed environment does *not* contain MACOSX_DEPLOYMENT_TARGET
while that is the only way to trigger this bug.
--
___
Python tracker
<http://bugs.python.org/issue9516>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9516] sysconfig: $MACOSX_DEPLOYMENT_TARGET mismatch: now "10.3" but "10.5" during configure
Ronald Oussoren added the comment:
This (untested) patch should fix the issue:
Index: Lib/sysconfig.py
===
--- Lib/sysconfig.py(revision 84147)
+++ Lib/sysconfig.py(working copy)
@@ -295,9 +295,8 @@
cur_target = cfg_target
os.putenv('MACOSX_DEPLOYMENT_TARGET', cfg_target)
elif map(int, cfg_target.split('.')) > map(int, cur_target.split('.')):
-msg = ('$MACOSX_DEPLOYMENT_TARGET mismatch: now "%s" but "%s" '
- 'during configure' % (cur_target, cfg_target))
-raise IOError(msg)
+os.putenv('MACOSX_DEPLOYMENT_TARGET', cfg_target)
+cfg_target = cur_target
# On AIX, there are wrong paths to the linker scripts in the Makefile
# -- these paths are relative to the Python source, but when installed
This removes the exception, and instead replaces the incompatible environment
setting by the configured setting.
It might be better to just have:
Index: Lib/sysconfig.py
===
--- Lib/sysconfig.py(revision 84147)
+++ Lib/sysconfig.py(working copy)
@@ -291,13 +291,8 @@
if sys.platform == 'darwin' and 'MACOSX_DEPLOYMENT_TARGET' in vars:
cfg_target = vars['MACOSX_DEPLOYMENT_TARGET']
cur_target = os.getenv('MACOSX_DEPLOYMENT_TARGET', '')
-if cur_target == '':
-cur_target = cfg_target
+if cur_target != cfg_target:
os.putenv('MACOSX_DEPLOYMENT_TARGET', cfg_target)
-elif map(int, cfg_target.split('.')) > map(int, cur_target.split('.')):
-msg = ('$MACOSX_DEPLOYMENT_TARGET mismatch: now "%s" but "%s" '
- 'during configure' % (cur_target, cfg_target))
-raise IOError(msg)
# On AIX, there are wrong paths to the linker scripts in the Makefile
# -- these paths are relative to the Python source, but when installed
This entirely ignores the environment variable and always uses the value that
was present during the configure run.
--
___
Python tracker
<http://bugs.python.org/issue9516>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9516] sysconfig: $MACOSX_DEPLOYMENT_TARGET mismatch: now "10.3" but "10.5" during configure
Ronald Oussoren added the comment:
I now understand why my script fails, and it is caused by this issue.
The sysconfig.py code has another major issue: the use of os.putenv. This
changes the environment, without changing os.environ. The use of os.putenv
should be replaced by setting keys in os.environ to make it easier to discover
that changes have been made.
Even that is no good: setting the environment variable should only be done in
distutils to ensure that the right build environment is used. It should not be
set globally where it will affect code that it was never intended to affect.
BTW. Sridhar: could this be the reason you cannot find the correct reproduction
steps for this? Do you use a build script that is writting in python and run
with a copy of python where
sysconfig.get_config_var('MACOSX_DEPLOYMENT_TARGET') returns '10.3'?
--
___
Python tracker
<http://bugs.python.org/issue9516>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue901727] extra_path kwarg to setup() undocumented
Ronald Oussoren added the comment: I don't understand why distutils won't even get documentation updates. Bob's report is about undocumented functionality that is used in real life and was the best way to install python distributions in a self-contained way before setuptools was invented. AFAIK The "options" argument to setup is also not documented an that one is also used (both py2exe and py2app mention this feature in their documentation). -- ___ Python tracker <http://bugs.python.org/issue901727> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9670] Exceed Recursion Limit in Thread
Ronald Oussoren added the comment: This is the same issue as #6763. The root cause of this issue is that the default stack size for threads other than the main thread is small. One way to fix this issue is to increase the default stacksize for new threads. -- ___ Python tracker <http://bugs.python.org/issue9670> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9610] buildbot: uncaptured python exception (smtpd), but no failure in regrtest
Ronald Oussoren added the comment: $ python2.7 test/test_asyncore.py -v test_closeall (__main__.HelperFunctionTests) ... ok test_closeall_default (__main__.HelperFunctionTests) ... ok test_compact_traceback (__main__.HelperFunctionTests) ... ok test_readwrite (__main__.HelperFunctionTests) ... ok test_readwriteexc (__main__.HelperFunctionTests) ... ok test_basic (__main__.DispatcherTests) ... ok test_issue_8594 (__main__.DispatcherTests) ... ok test_log (__main__.DispatcherTests) ... ok test_log_info (__main__.DispatcherTests) ... ok test_repr (__main__.DispatcherTests) ... ok test_strerror (__main__.DispatcherTests) ... ok test_unhandled (__main__.DispatcherTests) ... ok test_send (__main__.DispatcherWithSendTests) ... ok test_send (__main__.DispatcherWithSendTests_UsePoll) ... ok test_bind (__main__.TestAPI_UseSelect) ... ok test_connection_attributes (__main__.TestAPI_UseSelect) ... ok test_create_socket (__main__.TestAPI_UseSelect) ... ok test_handle_accept (__main__.TestAPI_UseSelect) ... ok test_handle_close (__main__.TestAPI_UseSelect) ... ok test_handle_connect (__main__.TestAPI_UseSelect) ... ok test_handle_error (__main__.TestAPI_UseSelect) ... ok test_handle_expt (__main__.TestAPI_UseSelect) ... ok test_handle_read (__main__.TestAPI_UseSelect) ... ok test_handle_write (__main__.TestAPI_UseSelect) ... ok test_set_reuse_addr (__main__.TestAPI_UseSelect) ... ok test_bind (__main__.TestAPI_UsePoll) ... ok test_connection_attributes (__main__.TestAPI_UsePoll) ... ok test_create_socket (__main__.TestAPI_UsePoll) ... ok test_handle_accept (__main__.TestAPI_UsePoll) ... ok test_handle_close (__main__.TestAPI_UsePoll) ... ok test_handle_connect (__main__.TestAPI_UsePoll) ... ok test_handle_error (__main__.TestAPI_UsePoll) ... ok test_handle_expt (__main__.TestAPI_UsePoll) ... ok test_handle_read (__main__.TestAPI_UsePoll) ... ok test_handle_write (__main__.TestAPI_UsePoll) ... ok test_set_reuse_addr (__main__.TestAPI_UsePoll) ... ok test_dispatcher (__main__.FileWrapperTest) ... error: uncaptured python exception, closing channel <__main__.FileDispatcher at 0x70db48> (:file_wrapper instance has no attribute 'getsockopt' [/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/asyncore.py|readwrite|106] [/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/asyncore.py|handle_write_event|449]) ERROR test_recv (__main__.FileWrapperTest) ... ok test_send (__main__.FileWrapperTest) ... ok == ERROR: test_dispatcher (__main__.FileWrapperTest) -- Traceback (most recent call last): File "test/test_asyncore.py", line 441, in test_dispatcher asyncore.loop(timeout=0.01, use_poll=True, count=2) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/asyncore.py", line 214, in loop poll_fun(timeout, map) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/asyncore.py", line 195, in poll2 readwrite(obj, flags) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/asyncore.py", line 119, in readwrite obj.handle_error() File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/asyncore.py", line 489, in handle_error self.handle_close() File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/asyncore.py", line 508, in handle_close self.close() File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/asyncore.py", line 396, in close self.socket.close() File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/asyncore.py", line 614, in close os.close(self.fd) OSError: [Errno 9] Bad file descriptor -- Ran 39 tests in 1.445s FAILED (errors=1) Traceback (most recent call last): File "test/test_asyncore.py", line 721, in test_main() File "test/test_asyncore.py", line 718, in test_main run_unittest(*tests) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/test/test_support.py", line 1055, in run_unittest _run_suite(suite) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/test/test_support.py", line 1038, in _run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "test/test_asyncore.py", line 441, in test_dispatcher asyncore.loop(timeout=0.01, use_poll=True, count=2) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/asyncore.py", line 214, in loop poll_fun(timeout, map) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/asyncore.py", line 195, in poll2 readwrite(obj, flags) File "/Library/Framewo
[issue1602133] non-framework built python fails to define environ properly
Ronald Oussoren added the comment: This is still a problem. Technically this only works accidently with a framework build, code that expects that '_environ' is defined in a shared library on OSX is broken. -- ___ Python tracker <http://bugs.python.org/issue1602133> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8716] test_tk fails on OS X if run from buildbot slave daemon -- crashes Python
Ronald Oussoren added the comment: In python 2.x 'MacOS.WMAvailable()' returns True if the windowserver is available. The whole MacOS extension is gone in 3.x, although it should be easy enough to reimplement WMAvailable() using ctypes. -- ___ Python tracker <http://bugs.python.org/issue8716> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9691] sdist includes files that are not in MANIFEST.in
New submission from Ronald Oussoren : The attached file 'manifest-test.zip' is a small distutils project that demonstrates a problem I have with the sdist command. The archive contains a directory 'sandbox' that is not mentioned in MANIFEST.in or anywhere in setup.py. When I create an sdist using "python setup.py sdist" the sandbox directory is included in the archive. This happens with 2.7 on Windows, while 2.7 on OSX does not have this behavior. -- assignee: tarek components: Distutils files: manifest-test.zip messages: 114966 nosy: eric.araujo, ronaldoussoren, tarek priority: normal severity: normal stage: unit test needed status: open title: sdist includes files that are not in MANIFEST.in type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file18650/manifest-test.zip ___ Python tracker <http://bugs.python.org/issue9691> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5504] ctypes should work with systems where mmap can't be PROT_WRITE and PROT_EXEC
Ronald Oussoren added the comment: Fixing the alloc_closure error is easy enough: Index: ../setup.py === --- ../setup.py (revision 84528) +++ ../setup.py (working copy) @@ -1653,7 +1653,9 @@ '_ctypes/callbacks.c', '_ctypes/callproc.c', '_ctypes/stgdict.c', - '_ctypes/cfield.c'] + '_ctypes/cfield.c', + '_ctypes/malloc_closure.c', + ] depends = ['_ctypes/ctypes.h'] if sys.platform == 'darwin': That's not enough to make it possible to build ctypes on OSX though, I now get the same error for a different symbol: *** WARNING: renaming "_ctypes" since importing it failed: dlopen(build/lib.macosx-10.6-fat-3.2/_ctypes.so, 2): Symbol not found: _ffi_prep_closure_loc Referenced from: /Users/ronald/Projects/python/python-3.x/build/build/lib.macosx-10.6-fat-3.2/_ctypes.so Expected in: flat namespace in /Users/ronald/Projects/python/python-3.x/build/build/lib.macosx-10.6-fat-3.2/_ctypes.so -- nosy: +ronaldoussoren ___ Python tracker <http://bugs.python.org/issue5504> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9662] ctypes not building under OS X because of ffi_closure_free not being defined early enough
Ronald Oussoren added the comment: I'm looking into this issue. One problem is that the version of libffi used on OSX is no longer in sync with the version that is used on other platforms. The version that is used on OSX does not have some of the symbols expected by ctypes, such as 'ffi_prep_closure_loc'. -- ___ Python tracker <http://bugs.python.org/issue9662> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5504] ctypes should work with systems where mmap can't be PROT_WRITE and PROT_EXEC
Ronald Oussoren added the comment: Łukasz' patch fixes the issue for me. As the patch only affects code-paths used on OSX (patches to the libffi version for OSX and an #ifdef that makes OSX use ffi_prep_closure instead of ffi_prep_closure_loc) I intend to commit the patch later today to be able to build a working copy of the OSX installer for the next alpha release. I'm at best -0 on moving all platforms to libffi 3.0.9. 'libffi_osx' works properly on OSX and I have no idea whether all changes in that fork of libffi have been merged back into the canonical version. -- ___ Python tracker <http://bugs.python.org/issue5504> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9662] ctypes not building under OS X because of ffi_closure_free not being defined early enough
Ronald Oussoren added the comment: Thanks! That patch fixes the issue for me and I will commit it later today. -- ___ Python tracker <http://bugs.python.org/issue9662> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
