[issue31382] CGI upload error when file ~< 10kb
New submission from Marc:
An error occurs when uploading a file ~<10kb:
A problem occurred in a Python script. Here is the sequence of function calls
leading up to the error, in the order they occurred.
/var/www/html/file-uploader/uploader.py in ()
39
40 # A nested FieldStorage instance holds the file
=> 41 fileitem = form['file']
42
43 # Test if the file was uploaded
fileitem undefined, form = FieldStorage(None, None, '')
/usr/lib/python3.4/cgi.py in __getitem__(self=FieldStorage(None, None, ''),
key='file')
591 """Dictionary style indexing."""
592 if self.list is None:
=> 593 raise TypeError("not indexable")
594 found = []
595 for item in self.list:
builtin TypeError =
TypeError: not indexable
args = ('not indexable',)
with_traceback =
but not when file is ~> 10kb
--
components: Extension Modules
messages: 301582
nosy: mschaming
priority: normal
severity: normal
status: open
title: CGI upload error when file ~< 10kb
versions: Python 3.4
___
Python tracker
<http://bugs.python.org/issue31382>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13968] Support recursive globs
Marc added the comment: Please review one word documentation change at https://github.com/python/cpython/pull/12918 to clarify that recursive glob ** follows symbolic links to directories. -- nosy: +marc-hb pull_requests: +12844 ___ Python tracker <https://bugs.python.org/issue13968> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18017] ctypes.PyDLL documentation
marc added the comment: I think the problem was a combination of two issues. First, the warning in 16.17.2.2 is a bit hidden. Kind of squeezed in between CDLL, etc and PyDLL. In contrast, 16.17.2.4 does a much better job, because it restates the fact that the GIL is released at each and every item. I think this is much better, because chances are high that you actually read the entry completely. In contrast, in case you are in a hurry you might miss the warning in 16.17.2.2 I think the second problem was that back then I was not aware of the fact that you need the GIL to call the Python/C API. That was a bit stupid indeed. But as a Python beginner it was just not obvious. Maybe the Introduction of the Python/C API needs some work, too. No GIL mentioned at https://docs.python.org/3/c-api/intro.html. Furthermore, the examples at https://docs.python.org/3/extending/extending.html also do not talk about the GIL. -- nosy: [email protected] ___ Python tracker <http://bugs.python.org/issue18017> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27543] from module import function creates package reference to the module
New submission from Marc:
Hello,
I've found an issue in python 2.7 and 3.4 and I don't if this is a bug or a
feature that acts strange to me.
The import of a module or method from a module creates a reference in the
package to that module only the first time, which could lead to unexpected
behavior.
Description:
In following code there's one line marked with 'this line fixes the code to
what I expected'
1. Without that line package.a.test() results in 'from module a'
2. With the line package.a.test() results in 'from module b'
Situation 1 is unexpected because I did not create the reference to 'module a',
python did that with the statement 'from package.a import test' and this will
happen from any place in the code that loads 'module a' for the first time. The
documentation says that this reference will not be created.
Kind regards,
Marc
# FILES USED
#
# test.py
# package
# __init__.py
# a.py
# b.py
# -
# Content of a.py:
def test():
print('from module a')
# -
# Content of a.py:
def test():
print('from module b')
# -
# Content of __init__.py
#import a # <--- this line fixes the code to what I expected
import b as a
from a import test
# -
# Content of test.py
import package
print(dir(package))
package.a.test()
--
components: Interpreter Core
messages: 270658
nosy: m.nijland
priority: normal
severity: normal
status: open
title: from module import function creates package reference to the module
type: behavior
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue27543>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18030] IDLE shell crashes when reporting errors in Windows 7
New submission from Marc: Using TkInter as gui, running a module that worked in 3.0 (I believe). It is trying to print a warning message about RuntimeWarning: overflow encountered in double_scalars and stops my process (running eval) returning this error File "C:\Python32\lib\idlelib\PyShell.py", line 59, in idle_showwarning file.write(warnings.formatwarning(message, category, filename, AttributeError: 'NoneType' object has no attribute 'write' If I use python -m idlelib.idle it doesn't happen; it just prints the error. Previously this worked fine using the shell as stdout. This is similar to a bug about symbols' errors however it has been closed and this one is not about symbols. http://bugs.python.org/issue14200 I don't really know a lot about programming and don't often submit bugs so sorry if I've missed any major details here. Marc -- components: IDLE messages: 189788 nosy: marcopolo priority: normal severity: normal status: open title: IDLE shell crashes when reporting errors in Windows 7 type: crash versions: Python 3.2 ___ Python tracker <http://bugs.python.org/issue18030> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23337] Run python with restricted rights
New submission from Marc: Hi, We work in a school within a domain and pupils are using different restricted account on this domain. We tried to install Python 3.4 and it's work with an Administrator Account. With Children account , we got the message "IDLE's subprocess didn't make connection. Either IDLE can't start a subprocess or personal firewall software is blocking the connection" . We checked if there is any python file in the python.exe directory like advised on http://stackoverflow.com/questions/874757/python-idle-subprocess-error. We also tried to give more right on the python directory for the children account. If anyone have a solution please let me know. Thanks -- components: Windows files: python_error.png messages: 234883 nosy: marcd, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Run python with restricted rights type: crash versions: Python 3.4 Added file: http://bugs.python.org/file37889/python_error.png ___ Python tracker <http://bugs.python.org/issue23337> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23337] Run python with restricted rights
Marc added the comment: Hi Ramchandra, I actually have an AV (Sophos) but no firewall on the computer -- ___ Python tracker <http://bugs.python.org/issue23337> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46162] Make `builtins.property` generic
Change by Marc Mueller : -- nosy: +cdce8p ___ Python tracker <https://bugs.python.org/issue46162> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46197] ensurepip bootstrap breaks out of isolated environment
Change by Marc Mueller : -- nosy: +cdce8p ___ Python tracker <https://bugs.python.org/issue46197> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46414] Add typing.reveal_type
Change by Marc Mueller : -- nosy: +cdce8p ___ Python tracker <https://bugs.python.org/issue46414> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43224] Add support for PEP 646
Change by Marc Mueller : -- nosy: +cdce8p ___ Python tracker <https://bugs.python.org/issue43224> ___ ___ 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.
Marc Culler added the comment: The TKApplication class is a subclass of NSApplication which adds both attributes and methods. Those are used throughout the macOS port of Tk, and as Ronald says, the unique instance of NSApplication in Tk is actually a TKApplication. Every macOS Application must have a unique NSApplication object which is referenced by the global variable NSApp. The TKApplication subclass was part of the first Cocoa port of Tk, long before I became involved, and it may have even been there in the Carbon days. Subclassing NSApplication appears to be something that Apple expects. I don't know enough about Categories to understand how they could be used to solve this problem. Do they somehow make it possible to add new methods and attributes to an existing NSApplication object at runtime? I have always thought of them as being syntactical in nature, as opposed to allowing runtime modifications of an object's class after the object has been instantiated. But I am not an expert on Categories by any means. - Marc On Wed, Feb 2, 2022 at 1:54 PM Ned Deily wrote: > > Ned Deily added the comment: > > Thanks for looking into this, Ronald. Before we close this as a Python > issue, perhaps Marc might have a suggestion on what should be done here > from a Tk perspective. > > -- > nosy: +culler > status: pending -> open > > ___ > Python tracker > <https://bugs.python.org/issue46573> > ___ > -- nosy: +Marc.Culler ___ 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
[issue44791] Substitution of ParamSpec in Concatenate
Change by Marc Mueller : -- nosy: +cdce8p ___ Python tracker <https://bugs.python.org/issue44791> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44863] Allow TypedDict to inherit from Generics
Change by Marc Mueller : -- nosy: +cdce8p ___ Python tracker <https://bugs.python.org/issue44863> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4256] argparse: provide a simple way to get a programmatically useful list of options
Changes by Marc Sibson : -- nosy: +marcs ___ Python tracker <http://bugs.python.org/issue4256> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11176] give more meaningful argument names in argparse documentation
Changes by Marc Sibson : -- nosy: +marcs ___ Python tracker <http://bugs.python.org/issue11176> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12933] Update or remove claims that distutils requires external programs
Changes by Marc Sibson : -- nosy: +marcs ___ Python tracker <http://bugs.python.org/issue12933> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10772] Several actions for argparse arguments missing from docs
Marc Sibson added the comment: changes as per the review, -- Added file: http://bugs.python.org/file23713/issue10772.patch3 ___ Python tracker <http://bugs.python.org/issue10772> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10772] Several actions for argparse arguments missing from docs
Marc Sibson added the comment: issue10772.patch: add help, count and parsers to Doc/library/argparse.rst -- keywords: +patch nosy: +marcs Added file: http://bugs.python.org/file22179/issue10772.patch ___ Python tracker <http://bugs.python.org/issue10772> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10772] Several actions for argparse arguments missing from docs
Marc Sibson added the comment: issue10772.patch2: document help and count actions in Doc/library/argparse.rst -- Added file: http://bugs.python.org/file22198/issue10772.patch2 ___ Python tracker <http://bugs.python.org/issue10772> ___ ___ 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
Marc Culler added the comment: I am running OSX 10.5.8 on this macbook. The Tcl/Tk package on the system is ActiveState Tcl/Tk 8.4.19. I just installed Python 3.2 (r32:88452, Feb 20 2011, 10:19:59) from http://www.python.org/getit/releases/3.2/ and I am still seeing this bug. It does not occur with the Python 2.7 Tkinter package, which uses the same Tcl/Tk framework. So if it is a bug in Tk, it is harmless when used with Python 2.7. But, after all, it is not so surprising to see new UnicodeDecodeErrors when porting from Python 2 to Python 3. -- versions: +Python 3.2 -Python 3.1 ___ 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
[issue7517] freeze.py not ported to python3
Marc Sibson added the comment: I think the original issue has been fixed by http://hg.python.org/cpython/rev/fd20eba1f201. freeze.py is now broken due to pep3149 and ABIFLAGS, freeze-pep3149-compat.patch adds awareness of ABIFLAGS to Tools/freeze/freeze.py. For me "python3.3 freeze.py hello.py && make && ./hello" now works. -- keywords: +patch nosy: +marcs Added file: http://bugs.python.org/file21825/freeze-pep3149-compat.patch ___ Python tracker <http://bugs.python.org/issue7517> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10582] PyErr_PrintEx exits silently when passed SystemExit exception
New submission from Marc Horowitz :
I discovered this bug working with panda3d. I've attached a short
python script which demonstrates the problem. After installing
panda3d, run the script, and then hit q in the window which appears.
You'll see that none of the cleanup code after the 'run()' main loop
runs.
The underlying cause is in how panda3d uses the C API. It's got code
like this (in src/pipeline/thread.cxx):
// Call the user's function.
result = PyObject_Call(function, args, NULL);
if (result == (PyObject *)NULL && PyErr_Occurred()) {
// We got an exception. Move the exception from the current
// thread into the main thread, so it can be handled there.
PyObject *exc, *val, *tb;
PyErr_Fetch(&exc, &val, &tb);
thread_cat.error()
<< "Exception occurred within " << *this << "\n";
// Temporarily restore the exception state so we can print a
// callback on-the-spot.
Py_XINCREF(exc);
Py_XINCREF(val);
Py_XINCREF(tb);
PyErr_Restore(exc, val, tb);
PyErr_Print();
...
If the code being called (generally a panda3d task function or event
handler) calls sys.exit, the PyErr_Print() never returns. This is
surprising, as the the documentation never mentions that a function
with an innocuous name like "Print" might never return.
However, I don't think this is a panda3d bug; I think that the
function as documented is the way it should behave. Otherwise, the
vast majority of calls to this method will need to look like
if (!PyErr_ExceptionMatches(PyExc_SystemExit)) {
PyErr_PrintEx(1);
}
which seems like a poor abstraction.
Another unexpected side effect is when python is used with the -i
flag. Because of the way this alters the normal exit behavior, the
code runs the way I'd expect, and the cleanup code in the test
application *does* run. It seems rather strange to me that cleanup
code should run or not run based on the -i flag.
I believe the fix for all this is that PyErr_PrintEx be changed to
behave as documented, *not* call handle_system_exit() when passed
SystemExit, and instead in the places where the interpreter main loop
is run, followed by PyErr_PrintEx(), that SystemExit is special cased
in those specific locations as needed.
--
components: Interpreter Core
files: exit_test.py
messages: 122846
nosy: Marc.Horowitz
priority: normal
severity: normal
status: open
title: PyErr_PrintEx exits silently when passed SystemExit exception
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file19875/exit_test.py
___
Python tracker
<http://bugs.python.org/issue10582>
___
___
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
New submission from Marc Culler :
In OS X tkinter the "two-finger scroll" generates events.
The following code:
bug.py
import tkinter
def mouse_wheel(event):
print('Mouse wheel event')
tk = tkinter.Tk()
list = tkinter.Listbox(tk)
list.bind('', mouse_wheel)
for n in range(20):
list.insert(tkinter.END, str(n**n))
list.pack(fill=tkinter.BOTH, expand=1)
tk.mainloop()
often throws a UnicodeDecodeError exception with a traceback like the one shown
below when you do a "two-finger scroll" in the window.
Traceback (most recent call last):
File "bug.py", line 12, in
tk.mainloop()
File
"/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/tkinter/__init__.py",
line 1009, in mainloop
self.tk.mainloop(n)
UnicodeDecodeError: 'utf8' codec can't decode byte 0x84 in position 1:
unexpected code byte
The value of the byte changes from time to time, and sometimes it may be
possible to scroll a few times without producing the error.
This problem did not occur on my Mandriva 2010.2 system. I think it is
specific to the Macintosh. It might possibly be related to:
http://bugs.python.org/issue834351
--
components: Tkinter
messages: 124287
nosy: culler
priority: normal
severity: normal
status: open
title: UnicodeDecodeError in OS X tkinter when binding to
type: crash
versions: Python 3.1
___
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
[issue3493] No Backslash (\) in IDLE 1.2.2
New submission from Marc Rambert <[EMAIL PROTECTED]>: With my MacBook, on IDLE application, I can't type any character like this one \. -- components: IDLE messages: 70637 nosy: Marc67 severity: normal status: open title: No Backslash (\) in IDLE 1.2.2 versions: Python 2.5 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3493> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3493] No Backslash (\) in IDLE 1.2.2
Changes by Marc Rambert <[EMAIL PROTECTED]>: -- type: -> feature request ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3493> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44118] cython compiler error
New submission from Marc Udoff : Hi, The follow gives an unexpected error during compilation: In [1]: %%cython ...: #cython: infer_types=True ...: class A: ...: def f(self): ...: x = max(self.a, self.a) Removing max, or setting infer_types=False, or setting x = None first all make it compile. -- components: C API files: cpython_error.txt messages: 393548 nosy: mlucool priority: normal severity: normal status: open title: cython compiler error type: compile error versions: Python 3.7 Added file: https://bugs.python.org/file50039/cpython_error.txt ___ Python tracker <https://bugs.python.org/issue44118> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44118] cython compiler error
Marc Udoff added the comment: Wrong forum -- resolution: -> third party stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue44118> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44828] Using tkinter.filedialog crashes on macOS Python 3.9.6
Marc Culler added the comment: I built Tcl and Tk 8.6 on Monterey beta (21A5294g) and I see this traceback in the Wish file dialog demo. Note that this is *not* an error. The file dialog works fine. This is a non-fatal NSInternalInconsistencyException which prints a traceback to stderr. It occurs within a call to [NSSavePanel runModal] which is entirely Apple code. The runModal method is not deprecated. Most likely, when Apple releases Monterey the assert command will have been removed, possibly replaced by a call to NSLog which writes information into a log file rather than print it to stderr. (NSLog itself prints to stderr when debugging is enabled.) Of course macOS apps run without stderr, so you will only see this traceback when running a python program from the terminal. (Any linux user who runs linux apps from the terminal is used to seeing lots of stderr messages in stderr. Try running okular from a terminal sometime. So we shouldn't complain too much.) Anyway, this looks harmless and the messages will almost surely go away in the production version. However, there are several new deprecations related to specifying preferred file types in a file dialog which I will address in Tk before Monterey is released. Beta releases are betas, even for macOS. - Marc On Thu, Aug 5, 2021 at 1:23 PM Ned Deily wrote: > > > Ned Deily added the comment: > > > I used brew.sh to install Python, which I think uses the universal installer > > As far as I know, Homebrew builds its own Python and Tk. > > > After I reinstall macOS, if you need further testing, i’m open to trying. > > Thanks. I think the next step would be to try to reproduce just using Tcl and > Tk as this most likely is an issue in Tk rather than Python. It's also quite > possible that the underlying problem will be fixed in a future Monterey beta. > Alas, I don't have time to look further into this in the immediate future. > Perhaps someone can follow up directly with the Tk folks. > > -- > nosy: +culler > > ___ > Python tracker > <https://bugs.python.org/issue44828> > ___ -- nosy: +Marc.Culler ___ Python tracker <https://bugs.python.org/issue44828> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44828] Using tkinter.filedialog crashes on macOS Python 3.9.6
Marc Culler added the comment: I should have mentioned that I tested on Intel hardware, not M1. I do not have access to an M1 Apple at this time. -- ___ Python tracker <https://bugs.python.org/issue44828> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43532] Add keyword-only fields to dataclasses
Change by Marc Mueller : -- nosy: +cdce8p ___ Python tracker <https://bugs.python.org/issue43532> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43994] change representation of match as / capture as `Name(..., ctx=Store())`
Change by Marc Mueller : -- nosy: +cdce8p ___ Python tracker <https://bugs.python.org/issue43994> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41629] __class__ not set defining 'X' as
Change by Marc Mueller : -- nosy: +cdce8p ___ Python tracker <https://bugs.python.org/issue41629> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44828] Using tkinter.filedialog crashes on macOS Python 3.9.6
Marc Culler added the comment: Unfortunately, I am still seeing this failure in Monterey beta 9. However, we are no longer alone. Here is a report of the same issue in Android Studio: https://stackoverflow.com/questions/69068842/android-studio-open-file-operation-failed-the-open-file-operation-failed-to-co This is reportedly fixed in the Adroid Studio beta, so maybe someone will be able to figure out what Google did to workaround the problem. -- ___ Python tracker <https://bugs.python.org/issue44828> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44828] Using tkinter.filedialog crashes on macOS Python 3.9.6
Marc Culler added the comment: I was able to fix this problem for Tk on Monterey beta [21A5543b]. The fix has been committed to the tip of the core-8-6-branch in the Tk fossil repository. Here is a synopsis. Tk used to open the file dialog by calling [NSApp runModalForWindow:panel]. Starting with the release of 10.14 this call would produce a warning message on stderr saying that [NSOpenPanel runModal] should be used instead. But on systems older than 10.14, the runModal method would fail because the completion handler would not get called. Now, with 12.0 (at least in the beta) calling [NSOpenPanel runModal] produces an error dialog saying "The open file operation failed to connect to the open and save panel service" and this would be accompanied by a traceback printed on stderr for an assertion error. (It was not a "crash" but the file selection would fail.) However, it turns out that calling [NSApp runModalForWindow:panel] no longer produces the warning in 12.0, and it works correctly. So my workaround was to add conditional code that only calls the runModal method on 10.14 and 10.15 and calls runModalForWindow on other versions of macOS. I tested on 10.15 and it works there as well. Needless to say, none of these changes are documented by Apple. -- ___ Python tracker <https://bugs.python.org/issue44828> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44828] Using tkinter.filedialog crashes on macOS Python 3.9.6
Marc Culler added the comment: Hi Ronald, There is no calendar scheduling for Tk releases. Don Porter decides when they happen. But I think we are due for another one soonish. In case it doesn't happen before the next Python release I will attach the patch file for commit a32262e9. (Note that this is subject to change - I still need to test on 10.14.) I believe that this patch is completely self-contained and can be applied to the 8.6.11 release. (Hint: Tk uses fossil as its SCM system. On a fossil timeline, clicking any two nodes generates their diff. The Tk timeline is at https://core.tcl-lang.org/tk/timeline) -- keywords: +patch Added file: https://bugs.python.org/file50343/openfile.patch ___ Python tracker <https://bugs.python.org/issue44828> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44828] Using tkinter.filedialog crashes on macOS Python 3.9.6
Marc Culler added the comment: No, Apple is not going to do away with their NSOpenPanel. There is always some churn when they release a new OS. Subtle changes to APIs can occur with no warning and no documentation. Sometimes they are bugs. Sometimes they disappear when the OS is released. Sometimes they are permanent. I would not recommend using a beta version of the OS to develop your tkinter app. -- ___ Python tracker <https://bugs.python.org/issue44828> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44828] tkinter.filedialog linked with Tk 8.6.11 crashes on macOS 12 Monterey, breaking IDLE saves
Marc Culler added the comment: Thanks, Ned, for finding my mistake which you generously called a typo. I have fixed the inequality in the Tk fossil repository. Incidentally, there is now a core-8-6-12-rc branch of Tk, also containing the fix. So it should not be too long before 8.6.12 is released. I will look at the code and check whether I see the UFO that you report. As you know, all that Tk does is to open an NSOpenPanel. Once that is open it is completely handled by the OS. Tk sees no events from the modal interaction and does not have any way of controlling any aspect of the dialog. So the only hope would be that it is possible to set some configuration option before opening the NSOpenPanel which would somehow cause the OS to assign focus to the correct widget. I will try to investigate what options are available. -- ___ Python tracker <https://bugs.python.org/issue44828> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44828] tkinter.filedialog linked with Tk 8.6.11 crashes on macOS 12 Monterey, breaking IDLE saves
Marc Culler added the comment: Hi Ned, I think this problem is fixed now in the tip of the Tk macosx_filedialog branch. I am attaching the tkMacOSXDialog.c file from that branch. I think you should be able to just replace the version in 8.6.11 and be able to build a working version. I have tested on macOS 10.14, 10.15, 11 and 12. Can you please test on your systems? If it looks OK I will merge the changes into 8.6.12-rc so they will appear in the 8.6.12 release when that happens. It should be fairly soon. -- Added file: https://bugs.python.org/file50398/tkMacOSXDialog.c ___ Python tracker <https://bugs.python.org/issue44828> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44828] tkinter.filedialog linked with Tk 8.6.11 crashes on macOS 12 Monterey, breaking IDLE saves
Marc Culler added the comment: Thanks for doing all the testing, Ned. I guess that the path forward is now clear. I will revert to the 8.6.11 code for 10.15 and earlier and use the new code for 11 and later. Of course the 8.6.11 code already has two cases, for 10.14 and earlier and 10.15 and later. So I will have some code cleanup to do. The UFO, by the way, was a standalone file dialog which was first being rendered as a separate window and then immediately attached to the parent window as a sheet. This was easier to see on a slower machine, like a VMWare VM which does not have graphics acceleration. Evidently the big change for 10.15 was that the file dialog was changed so that it became managed by a separate process, rather than just borrowing the current process's event queue. The reason, supposedly, was to make it so that an app running in a sandbox could still read and write the user's files. It seems that Apple had a hard time making this work, and the UFO as well as the assertion error suggest to me that they still haven't figured it out. So I thnk we can expect more trouble with the next OS. At least we have a year before that adventure starts. Needless to say, having some documentation from Apple would be much more pleasant than the trial and error method that we are forced to use now. But we know better than to expect that. -- ___ Python tracker <https://bugs.python.org/issue44828> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44828] tkinter.filedialog linked with Tk 8.6.11 crashes on macOS 12 Monterey, breaking IDLE saves
Marc Culler added the comment: Hmmm, the 10.15 segfault seems to occur when writing the filename into the entry widget on the dialog. So maybe it is actually an issue with reference counting an NSString. I will have to look at that more carefully. -- ___ Python tracker <https://bugs.python.org/issue44828> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44828] tkinter.filedialog linked with Tk 8.6.11 crashes on macOS 12 Monterey, breaking IDLE saves
Marc Culler added the comment: Hi Ned. Here is one more attempt, hopefully the final one. I tested with IDLE on 10.14 (VM), 10.15(hard), 11(hard), 12(VM). I used Python 3.10.0. I replaced libtk8.6.dylib with the Tk lib compiled from the tip of the macosx_filedialog branch. I could not reproduce any of the issues that you reported. (But I hope you will retry as well, since just replacing the tkMacOSXDialog.c file in 8.6.11 is not the same as using the soon-to-be 8.6.12 release candidate.) I will attach the tkMacOSXDialog.c that I used. -- Added file: https://bugs.python.org/file50408/tkMacOSXDialog.c ___ Python tracker <https://bugs.python.org/issue44828> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44828] tkinter.filedialog linked with Tk 8.6.11 crashes on macOS 12 Monterey, breaking IDLE saves
Marc Culler added the comment: That is great news! I will now merge the changes into the Tk core-8-6-branch and core-8-6-12-rc branches. -- ___ Python tracker <https://bugs.python.org/issue44828> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44828] tkinter.filedialog linked with Tk 8.6.11 crashes on macOS 12 Monterey, breaking IDLE saves
Marc Culler added the comment: Heads up! A strange Apple quirk has been identified which could affect the file dialog behavior if the Tk library is compiled on macOS 10.XX and used on macOS 11 or 12. (I am not sure if this applies here.) The fix for the broken file dialog was to use different calls to display the dialog, depending on the OS version. The quirk is that code compiled on 10.XX and run on 11 or 12 will report the host OS version as 10.16 (which does not exist) no matter whether the actual version is 11 or 12. The simplest workaround is to replace the condition OSVersion < 11 by the condition OSVersion < 101600. Since tests like this occur in many places, a more robust workaround has been implemented in the Tk fossil repository and will appear in 8.6.12. -- ___ Python tracker <https://bugs.python.org/issue44828> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44828] tkinter.filedialog linked with Tk 8.6.11 crashes on macOS 12 Monterey, breaking IDLE saves
Marc Culler added the comment: I found the cause of the zombie dialog window. I was supposed to call [parent endSheet] after calling [parent beginSheet]. Adding that stops the window from reappearing. But it does not solve the whole problem. Subsequent Command-S presses do not cause the file dialog to reappear. In fact, they do not even generate a call to showOpenSavePanel, which is supposed to present the dialog, and is also the function where all of the changes have been made. So this would seem to be a different bug. I see that if I open a new editor with Command-N and enter some text then Command-S works for the new editor. -- ___ Python tracker <https://bugs.python.org/issue44828> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44828] tkinter.filedialog linked with Tk 8.6.11 crashes on macOS 12 Monterey, breaking IDLE saves
Marc Culler added the comment: Yes that is what I meant. So I guess everything may be OK now. I did verify that the Tk demo can repeatedly open file save dialogs. When you press Command-S on a non-new edit window you do see the flash of the Save menu, so it would appear that a dialog was meant to appear, and there is no indication of why it did not. But that is an IDLE UX issue and in any case it sounds like Tk is not doing anything wrong. -- ___ Python tracker <https://bugs.python.org/issue44828> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44828] tkinter.filedialog linked with Tk 8.6.11 crashes on macOS 12 Monterey, breaking IDLE saves
Marc Culler added the comment: OK. Shift-Command-S works. I will attach the fossil diff which should have enough context to indicate where to add the one new line. Then I will merge this change into the 8.6.12 release candidate -- Added file: https://bugs.python.org/file50420/endsheet.patch ___ Python tracker <https://bugs.python.org/issue44828> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44828] tkinter.filedialog linked with Tk 8.6.11 crashes on macOS 12 Monterey, breaking IDLE saves
Marc Culler added the comment: A (hypothetical) explanation: I think that each NSWindow maintains a queue of attached sheets. Failing to call the [parent endSheet] method left the file dialogue NSPanel in the queue, although it had been ordered offscreen and so was not visible. Opening the NSAlert added it to the top of the queue. Closing the alert caused it to be removed from the queue. But, since the queue was not empty, the window manager was supposed to orderFront the next sheet in the queue. That sheet was the file dialog, which had not been destroyed since adding it to the queue had incremented its reference count, and failing to remove it had not decremented its reference count. But the separate process that handles events for the file dialog had exited long ago. So that made the newly re-opened file dialog NSPanel into a zombie. -- ___ Python tracker <https://bugs.python.org/issue44828> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44828] tkinter.filedialog linked with Tk 8.6.11 crashes on macOS 12 Monterey, breaking IDLE saves
Marc Culler added the comment: Where do you think that "feature" is documented? -- ___ Python tracker <https://bugs.python.org/issue44828> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44828] tkinter.filedialog linked with Tk 8.6.11 crashes on macOS 12 Monterey, breaking IDLE saves
Marc Culler added the comment: According to wikipedia, it was only the Big Sur beta that identified itself as 10.16. (And I observed this with the beta). But the release and, I think, the later Big Sur betas stopped doing that. But I did eventually find a page showing a tweet that "documents" this behavior: https://eclecticlight.co/2020/07/21/big-sur-is-both-10-16-and-11-0-its-official/ I guess obscure tweets have replaced documentation. -- ___ Python tracker <https://bugs.python.org/issue44828> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44828] tkinter.filedialog linked with Tk 8.6.11 crashes on macOS 12 Monterey, breaking IDLE saves
Marc Culler added the comment: Well, not exactly ... culler@abner ~ % export SYSTEM_VERSION_COMPAT=1 culler@abner ~ % sw_vers ProductName:Mac OS X ProductVersion: 10.16 BuildVersion: 20G224 culler@abner ~ % export SYSTEM_VERSION_COMPAT=0 culler@abner ~ % sw_vers ProductName:macOS ProductVersion: 11.6.1 BuildVersion: 20G224 But that would only be helpful to me if the operatingSystemVersion property of an NSProcessInfo object also depended on that environment variable. Feel free to check the docs for an answer to that question: https://developer.apple.com/documentation/foundation/nsprocessinfo/1410906-operatingsystemversion -- ___ Python tracker <https://bugs.python.org/issue44828> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45938] EmailMessage as_bytes
New submission from Marc Villain :
I am parsing an email with a subject header where the encoding of a unicode
character happens to be cut in half. When a second encoded unicode character is
encountered, we get the following error:
> 'utf-8' codec can't encode characters in position 1-2: surrogates not allowed
This error can be reproduced using the following:
>>> from email.message import EmailMessage
>>> msg = EmailMessage()
>>> msg.add_header('subject', '=?UTF-8?Q?a=C3?= =?UTF-8?Q?=B1o_a=C3=B1o?=')
>>> print(str(msg)) # This will succeed
>>> print(msg.as_bytes()) # This will fail
>>> print(msg.as_string()) # This will fail
After a bit of investigations, it appears the library is at some poing trying
to concatenate 'a\udcc3\udcb1o ' and 'cómo'. It then proceeds to try to call
_ew.encode in email._header_value_parser._fold_as_ew on that. This obviously
fails as '\udcc3\udcb1o' is not utf-8, whereas 'cómo' is.
More tests:
[OK] '=?UTF-8?Q?a=C3?= =?UTF-8?Q?=B1o_a=C3=B1o?='
> b' subject: =?utf-8?q?a=C3=B1o_c=C3=B3mo?=\n\n'
[OK] '=?UTF-8?Q?a=C3?= =?UTF-8?Q?=B1o_cmo?='
> b' subject: =?unknown-8bit?q?a=C3=B1o?= cmo\n\n'
[OK] '=?UTF-8?Q?a=C3?= =?UTF-8?Q?=B1o?= =?UTF-8?Q?a=C3?= =?UTF-8?Q?=B1o?='
> b' subject: =?unknown-8bit?q?a=C3=B1oa=C3=B1o?=\n\n'
[KO] '=?UTF-8?Q?a=C3?= =?UTF-8?Q?=B1o_a=C3=B1o?='
> 'utf-8' codec can't encode characters in position 1-2: surrogates not
allowed
Not sure what is the best way to fix that.
--
components: Library (Lib)
messages: 407379
nosy: marc.villain
priority: normal
severity: normal
status: open
title: EmailMessage as_bytes
type: crash
versions: Python 3.10
___
Python tracker
<https://bugs.python.org/issue45938>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38882] IDLE should not make the about dialog be a transient of the withdrawn root window
New submission from Marc Culler : The soon-to-be-released Tcl/Tk 8.6.10 includes some changes to the macOS port which cause the wm transient command to behave in the way that the Tk manual says it should: "A transient window will mirror state changes in the master and inherit the state of the master when initially mapped." This means that a transient of a withdrawn window will be withdrawn. In the macOS version of IDLE the about dialog is assigned as a transient of the root window which is withdrawn, so the dialog does not appear on the screen. Consequently, activating the about menu will cause IDLE to become unresponsive as it waits for an offscreen window to be closed. Deleting line 28 in aboutDialog.py: self.transient(parent) makes the about dialog behave normally. -- assignee: terry.reedy components: IDLE messages: 357195 nosy: culler, terry.reedy priority: normal severity: normal status: open title: IDLE should not make the about dialog be a transient of the withdrawn root window type: behavior versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue38882> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38882] IDLE should not make the about dialog be a transient of the withdrawn root window
Marc Culler added the comment: It definitely makes sense for an on-screen window to have a transient dialog. With a little care (see "messages boxes" in the widget demo) on the mac the transient can be a "sheet" that opens from the top of the master window. It even makes sense for an iconified window to have a transient since the window manager still controls iconified windows. But a withdrawn window, with no icon (and no listing in the mac Window menu) is beyond the user's control. The really deadly combination is when a transient of a withdrawn window (so the transient is withdrawn) also has a grab on mouse and keyboard events. That one should be avoided. It is not clear to me why Tk allows it. I believe it should be avoided on all platforms, since withdrawn windows are supposed to be completely removed from the window manager and only known to Tk. But testing is needed, of course. I don't know the full history. I know there were changes between 8.6.9 and 8.6.10 needed to bring the mac port to its current state where it passes all of the Tk regression tests. (That is not the case with unix at the moment and I know there are many issues with iconified and withdrawn windows in Gnome 3 due to changes in window manager behavior which have not been fully incorporated into Tk.) I suspect there were many prior releases with no changes to this behavior on the mac. PS The formerly soon-to-be-released 8.6.10 has now been released. -- ___ Python tracker <https://bugs.python.org/issue38882> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38882] IDLE should not make the about dialog be a transient of the withdrawn root window
Marc Culler added the comment: I should have mentioned that I did not see the IDLE hang with Python 3, only with Python 2.7. So I changed the Version in the ticket. -- versions: +Python 3.7 -Python 3.8 ___ Python tracker <https://bugs.python.org/issue38882> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38882] IDLE should not make the about dialog be a transient of the withdrawn root window
Change by Marc Culler : -- versions: +Python 2.7 -Python 3.7 ___ Python tracker <https://bugs.python.org/issue38882> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38882] IDLE should not make the about dialog be a transient of the withdrawn root window
Marc Culler added the comment: One thing to keep in mind is that Apple's release of OSX 10.14.6 caused Tk 8.6.8 to stop working on many systems in an extremely obnoxious way. Starting a Tk Application would trigger a segfault in Apple's WindowServer which would then cause the user to be immediately logged out. That does not happen with 8.6.10. (Other types of applications were also affected.) Here is one of many bug reports: https://github.com/matplotlib/matplotlib/issues/14999 Whether the crash would occur depended on which Apple hardware was used. -- ___ Python tracker <https://bugs.python.org/issue38882> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42541] Tkinter colours wrong on MacOS universal2
Marc Culler added the comment: Yes, I can provide a good commit ID to work with. Please give me a couple of days. The current tip is almost an ideal choice. There have been no Aqua bug reports for quite some time. But now there is one new one (from Kevin) so I'd like to fix that, discuss with Kevin, and test. -- ___ Python tracker <https://bugs.python.org/issue42541> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30459] PyList_SET_ITEM could be safer
Espie Marc added the comment: On Sat, Dec 05, 2020 at 01:28:33AM +, STINNER Victor wrote: > > STINNER Victor added the comment: > > I propose to merge my PR 23645 change right now. If it breaks too many C > extensions, we still have time before Python 3.10.0 final scheduled at > Monday, 2021-10-04, to revert the change. > > > "if (obj == NULL || PyList_SET_ITEM (l, i, obj) < 0)" > > Well, this is obviously a bug in py-qt4 and it's a good thing to get a > compiler error on such code. I guess that the intent was to use > PyList_SetItem(). > > It's also an issue for Python implementation other than CPython which does > not behave exactly like CPython C API. I prefer to fix the C API to make it > respect its own documentation (return "void"). > > > Espie Marc: "Well, there is not going to be a lot of breakage. This problem > is the only instance I've encountered in the full OpenBSD ports tree." > > Oh, thanks for providing this very useful feedback! That's very promising. > > Did you report the issue to py-qt4 upstream? If yes, can you please copy here > the link to your report? I'm sorry, it's been so long ago, I can't remember. I've been dealing with 10s of other bugs since. -- ___ Python tracker <https://bugs.python.org/issue30459> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42068] For macOS, package the included Tcl and Tk frameworks in a rational way.
Marc Culler added the comment: Hi Ned, I have a comment about the code signing issues that would arise if the Tcl and Tk frameworks were embedded as actual subframeworks inside the Python.framework, and a user later replaced those with newer versions. The answer is that no new issues arise. The current Python.framework fails codesign verification as soon as a single new package is installed with pip (even upgrading pip itself). The codesign command detects the new files and exits with non-zero status if called with --verify. In verbose mode it will list all of the files that were added. This does not prevent python from working. So it should just be acknowledged that python's codesigning is used purely to make installation simpler and that no attempt is currently being made to ensure that an installed python framework continues to pass codesign verification. As a consequence, my proposal in this ticket would raise no new codesigning issues, but it would allow users to much more easily upgrade the Tcl and Tk embedded in /Library/Frameworks/Python.framework versions. It would also simplify the recipe for building Tcl and Tk in the buildscript. While the python framework may be viewed as a black box, in fact it is not a black box at all. It can be changed at will either by python itself or by a user. Making its structure clearer and cleaner could only be an improvement. -- ___ Python tracker <https://bugs.python.org/issue42068> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42541] Tkinter colours wrong on MacOS universal2
Marc Culler added the comment: Well, actually the release was announced today. There was one bug fix which did not make it into the release but could possibly affect Python, due to the fact that Python is installed as a framework, and frameworks to not have icons. I can supply a (1-line) patch if needed. To test, import tkinter, create a tkinter.Tk object and open the "About Python" menu. If the icon displayed on the About dialog looks like a folder then you need the patch. Please let me know what happens when switching to dark mode. My concern arises from my understanding that python is being built with a macOS 10.9 SDK, which does not understand dark mode. I don't know what will happen when running that code on a system which does support dark mode. Since Tk can be build on Big Sur with a minimum target of 10.9 (and I recommend doing so) I think it should be OK. There may be warnings when linking _tkinter.so though. I do not understand why the 10.9 SDK is needed, since I recently built Python 3.9.0 on Big Sur, with a minimum target of 10.9, and did not see any significant issues. (Well, maybe A few warnings from the posix module need investigation.) -- ___ Python tracker <https://bugs.python.org/issue42541> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42068] For macOS, package the included Tcl and Tk frameworks in a rational way.
New submission from Marc Culler : Packaging Tcl and Tk within the python framework is a great idea and a big improvement. But the way it is being done is pretty crazy, and makes it unnecessarily difficult to upgrade the version of Tcl/Tk that python is using. That is something which should be easy, especially since python is still using version 8.6.8 even though 8.6.11 is about to be released and includes the results of a huge effort to improve and stabilize the macOS port of Tk. There is a standard and completely straightforward way of including a framework within a framework. The normal thing to do would be to create a directory Python.framework/Versions/X.Y/Frameworks/ which contains Tcl.framework and Tk.framework. Upgrading to a newer version of Tcl and Tk would then simply require updating those frameworks, which would be very easy to accomplish, for example, with a .pkg file. Instead of doing this, Python currently jams everything related to Tcl and Tk into its lib directory, changing the library and directory names randomly and breaking the standard directory structure that Tcl and Tk use in their frameworks. Why not make it standard and simple? Why add all of this random noise? -- components: macOS messages: 378860 nosy: culler, ned.deily, ronaldoussoren priority: normal severity: normal status: open title: For macOS, package the included Tcl and Tk frameworks in a rational way. type: enhancement versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue42068> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42068] For macOS, package the included Tcl and Tk frameworks in a rational way.
Marc Culler added the comment: Dear Eric, I am aware that python is cross platform. The change that I am proposing would be almost entirely limited to the file: Mac/BuildScript/build-installer.py which is entirely mac-specific. It controls how the Mac installer is constructed. Specifically, the effect would be to change the directory structure of the Python framework which is installed by the Python installer package in /Library/Frameworks/Python.framework. There presumably would also be a very small change in the _tkinter module to account for the fact that the Tcl and Tk shared libraries would acquire new pathnames. My sincere apologies for offending you by my use of the words "crazy" and "random noise". I hope you will be able to focus on the content of the ticket in spite of my use of those offensive words. -- ___ Python tracker <https://bugs.python.org/issue42068> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42068] For macOS, package the included Tcl and Tk frameworks in a rational way.
Marc Culler added the comment: Dear Ronald, You are correct that "It is already possible to replace the Tcl/Tk libraries by replacing the relevant files in Python.framework." I know that because I have done it. Moreover, having done it, I know that it is much more difficult than it should be. A large part of the difficulty is that the directory structure of the Tcl/Tk installation within the Python framework is undocumented and completely different from that used within Tcl.framework and Tk.framework. There is no need for that. The versions of those frameworks with Python wants to use could simply be embedded within the Python.framework as subframeworks. That simplifies the build and it simplifies upgrades and it costs nothing as far as Python is concerned. The backwards compatibility promise offered by Tk and Tcl means that replacing Tcl/Tk 8.6.X with Tcl/Tk 8.6.Y will work with no change to the binary _tkinter. module. When improvements or bug fixes are made to Tcl and Tk it should be straightforward for users to update Python so that it will take advantage of those improvements. Before Tcl and Tk were included in the Python framework that was simple. You could just install the newer release of Tcl/Tk (at least for patch releases). Since _tkinter would look in the standard places, i.e. /Library/Frameworks/Tk.framework (or Tcl.framework) for its shared libraries, that would automatically work. The point is that it could, and should, be just as simple to make such an upgrade with the new where Tcl and Tk are included within the Python.framework. That is what I am trying to accomplish. The scope of this change will probably be clearer if I make a pull request. So I will do that. -- ___ Python tracker <https://bugs.python.org/issue42068> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42068] For macOS, package the included Tcl and Tk frameworks in a rational way.
Marc Culler added the comment: Ned - do you have any news on the topic of packaging Tcl/Tk within the Python bundle? -- ___ Python tracker <https://bugs.python.org/issue42068> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13985] Menu.tk_popup : menu doesn't disapear when main window is iconified.
New submission from marc dechico : actions do discover the bug with the source I have given: pushing the right button to get the pop-up menu . going out of the popup_menu still pushing the right button. the menu doesn't disapear when releasing the button. and still doesn't disapear when iconnifying the main window. I suppose the pop up_menu should behave in a transient way. when doing such a thing with google-chrome I first have my popup menu disapear and I need to click again to iconify. perhaps we should have the choice and have access to a transient function. -- components: Tkinter files: popupmenu.py messages: 153037 nosy: marc.dechico priority: normal severity: normal status: open title: Menu.tk_popup : menu doesn't disapear when main window is iconified. type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file24474/popupmenu.py ___ Python tracker <http://bugs.python.org/issue13985> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13405] Add DTrace probes
Marc Abramowitz added the comment: Jesús said he was focusing on Solaris and couldn't help with OS X. Not sure if anyone else was going to try tackling that... Just tried the patch `issue13405_4027.diff` on OS X 10.6.8. First problem I ran into was: gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I./Include-DPy_BUILD_CORE -o ./Include/phelper_offsets \ ./Include/phelper_offsets.c ./Include/phelper_offsets.c: In function 'main': ./Include/phelper_offsets.c:23: warning: format '%d' expects type 'int', but argument 2 has type 'long int' ./Include/phelper_offsets.c:26: warning: format '%d' expects type 'int', but argument 2 has type 'long unsigned int' ./Include/phelper_offsets.c:28: warning: implicit declaration of function 'offsetof' ./Include/phelper_offsets.c:28: error: expected expression before 'PyCompactUnicodeObject' ./Include/phelper_offsets.c:30: error: expected expression before 'PyCompactUnicodeObject' make: *** [Include/phelper_offsets.h] Error 1 OS X seems to have `offsetof` defined in `stddef.h` -- adding `#include ` got this to compile. The next problem was with: ``` if test "dtrace" != "" ; then \ dtrace -o Python/phelper.o -DPHELPER -64 \ -I. -I./Include -C -G -s ./Include/phelper.d ; \ elsetouch Python/phelper.o ; \ fi; ``` This fails because DTrace on OS X doesn't have the -G option. Removing the `-G` (total hack since it seems like `-G` is not at all a trivial option) results in: ``` dtrace: failed to initialize dtrace: DTrace requires additional privileges ``` Adding `sudo` isn't a practical solution, but I tried it to see if it would help or if there would be other errors and there was another error: ``` dtrace: ignored option -- 64 /dev/fd/5:42:8: warning: undefining "__STDC__" dtrace: failed to compile script ./Include/phelper.d: "/usr/include/libkern/_OSByteOrder.h", line 98: specified storage class not appropriate in D make: *** [Python/phelper.o] Error 1 ``` -- nosy: +Marc.Abramowitz ___ Python tracker <http://bugs.python.org/issue13405> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13405] Add DTrace probes
Marc Abramowitz added the comment: With an hg checkout, I don't run into the `offsetof` problem - it fails when it gets to calling dtrace to generate Python/dtrace.o (again -G is the culprit). ``` $ hg clone https://hg.jcea.es/cpython-2011/ $ cd cpython-2011 $ hg update dtrace-issue13405_2.7 $ ./configure --prefix=/Users/marca/custom --enable-shared --with-dtrace ... $ make ... $ make if test "dtrace" != "" ; then \ dtrace -o Python/dtrace.o -64 \ -C -G -s ./Include/pydtrace.d \ Python/ceval.o Modules/gcmodule.o \ Objects/classobject.o Objects/typeobject.o; \ elsetouch Python/dtrace.o ; \ fi; dtrace: ignored option -- 64 Usage: dtrace [-aACeFHlqSvVwZ] [-arch i386|x86_64] [-b bufsz] [-c cmd] [-D name[=def]] [-I path] [-L path] [-o output] [-p pid] [-s script] [-U name] [-x opt[=val]] ... ``` -- ___ Python tracker <http://bugs.python.org/issue13405> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13405] Add DTrace probes
Marc Abramowitz added the comment: My understanding of DTrace is extremely shallow, but I think there is a major difference in how USDT probes are created between Solaris and OS X. Whereas on Solaris one generates object code using the -G option of dtrace and then links it in with the application, it seems that on OS X, the header file that dtrace -h spits out already has the magic assembler voodoo in it and thus you don't link with anything extra for DTrace. If that's true, then we probably need Makefile ifdef stuff to make it work. If someone can verify my theories, I might be inclined to take a stab at it. -- ___ Python tracker <http://bugs.python.org/issue13405> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13405] Add DTrace probes
Marc Abramowitz added the comment:
I noticed that jcea already had some commented out stuff for OS X in his
configure.in.
I tried it out and stuff builds and works in a basic way, although it might not
be fully functional.
```
~/src/python-hg/cpython-2011$ hg diff configure.in
diff -r b50130b35288 configure.in
--- a/configure.in Wed Feb 22 02:15:47 2012 +0100
+++ b/configure.in Wed Feb 22 14:19:42 2012 -0800
@@ -2670,8 +2670,7 @@
DFLAGS="-32"
fi
-#if dtrace -G -o /dev/null Include/pydtrace.d 2>/dev/null
-if true
+if dtrace -G -o /dev/null Include/pydtrace.d 2>/dev/null
then
DTRACE_NM=SOLARIS
AC_DEFINE(WITH_DTRACE, 1,
```
```
~/src/python-hg/cpython-2011$ ./configure --prefix=/Users/marca/custom
--enable-shared --with-dtrace
...
~/src/python-hg/cpython-2011$ make
...
~/src/python-hg/cpython-2011$ DYLD_LIBRARY_PATH=. python2.7
Python 2.7.2+ (dtrace-issue13405_2.7:b50130b35288+, Feb 22 2012, 14:11:17)
[GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.getpid()
34764
# In another tab...
$ sudo dtrace -l | grep python34764
124748 python34764 libpython2.7.dylibPyEval_EvalFrameExReal
function-entry
124749 python34764 libpython2.7.dylibPyEval_EvalFrameExReal
function-return
124750 python34764 libpython2.7.dylib collect gc-done
124751 python34764 libpython2.7.dylib collect gc-start
124752 python34764 libpython2.7.dylib subtype_dealloc
instance-delete-done
124753 python34764 libpython2.7.dylib instance_dealloc
instance-delete-done
124754 python34764 libpython2.7.dylib subtype_dealloc
instance-delete-start
124755 python34764 libpython2.7.dylib instance_dealloc
instance-delete-start
124756 python34764 libpython2.7.dylib PyType_GenericAlloc
instance-new-done
124757 python34764 libpython2.7.dylibPyInstance_New
instance-new-done
124758 python34764 libpython2.7.dylib PyType_GenericAlloc
instance-new-start
124759 python34764 libpython2.7.dylibPyInstance_New
instance-new-start
124760 python34764 libpython2.7.dylibPyEval_EvalFrameExReal line
```
So it builds and works at a basic level.
However, I did see some weirdness as well:
```
$ sudo dtrace -n 'python34764::: { printf("%s (%s:%d)", copyinstr(arg1),
copyinstr(arg0), arg2) }' | grep test
dtrace: description 'python34764::: ' matched 13 probes
dtrace: error on enabled probe ID 4 (ID 124751:
python34764:libpython2.7.dylib:collect:gc-start): invalid address (0x2) in
action #2 at DIF offset 24
dtrace: error on enabled probe ID 3 (ID 124750:
python34764:libpython2.7.dylib:collect:gc-done): invalid address
(0xfffb) in action #1 at DIF offset 24
```
and
```
~/src/python-hg/cpython-2011$ sudo DYLD_LIBRARY_PATH=. dtrace -n 'python*::: {
printf("%s (%s:%d)", copyinstr(arg1), copyinstr(arg0), arg2) }' -c 'python2.7
/Users/marca/python/test.py' > /dev/null
dtrace: description 'python*::: ' matched 29 probes
dtrace: pid 34907 has exited
dtrace: error on enabled probe ID 20 (ID 126731:
python34907:libpython2.7.dylib:collect:gc-start): invalid address (0x2) in
action #2 at DIF offset 24
dtrace: error on enabled probe ID 19 (ID 126730:
python34907:libpython2.7.dylib:collect:gc-done): invalid address
(0xfffb) in action #1 at DIF offset 24
```
On the other hand, some stuff appears to work sometimes:
```
~/src/python-hg/cpython-2011$ sudo DYLD_LIBRARY_PATH=. dtrace -n
'python*:::function-entry { printf("%s (%s:%d)", copyinstr(arg1),
copyinstr(arg0), arg2) }' -c 'python2.7 /Users/marca/python/test.py'
dtrace: description 'python*:::function-entry ' matched 9 probes
Current working directory: /Users/marca/src/python-hg/cpython-2011
11
Current working directory: /Users/marca/src/python-hg/cpython-2011
11
Current working directory: /Users/marca/src/python-hg/cpython-2011
11
dtrace: pid 34953 has exited
CPU IDFUNCTION:NAME
2 125639 PyEval_EvalFrameExReal:function-entry
(/Users/marca/python/test.py:1)
2 125639 PyEval_EvalFrameExReal:function-entry
(/Users/marca/python/marcsmath.py:1)
2 125639 PyEval_EvalFrameExReal:function-entry test_func
(/Users/marca/python/test.py:4)
2 125639 PyEval_EvalFrameExReal:function-entry add
(/Users/marca/python/marcsmath.py:1)
2 125639 PyEval_EvalFrameExReal:function-entry test_func
(/Users/marca/python/test.py:4)
2 125639 PyEval_EvalFrameExReal:function-entry add
(/Users/marca/python/marcsmath.py:1)
2 125639 PyEval_EvalFrameExReal:function-entry test_func
(/Users
[issue13405] Add DTrace probes
Marc Abramowitz added the comment: Hi Jesús, Yes, I'm on an x86 machine. A MacBook Pro with OS X 10.6.8. I'll try to hop on Google Talk during the week. I'm on the west coast of the U.S. (GMT-8) so it might be tricky to find a mutually good time. Here's the result of the tests - like you said the stack test failed but everything else passed: ``` [last: 0] marca@SCML-MarcA:~/src/python-hg/cpython-2011$ sudo ~/custom/bin/python Lib/test/test_dtrace.py test_function_entry_return (__main__.DTraceTestsNormal) ... ok test_garbage_collection (__main__.DTraceTestsNormal) ... ok test_instance_creation_destruction (__main__.DTraceTestsNormal) ... ok test_line (__main__.DTraceTestsNormal) ... ok test_stack (__main__.DTraceTestsNormal) ... FAIL test_verify_opcodes (__main__.DTraceTestsNormal) ... ok == FAIL: test_stack (__main__.DTraceTestsNormal) ... ``` Perhaps the test should be modified as follows: ``` [last: 0] marca@SCML-MarcA:~/src/python-hg/cpython-2011$ hg diff Lib/test/test_dtrace.py diff -r b50130b35288 Lib/test/test_dtrace.py --- a/Lib/test/test_dtrace.py Wed Feb 22 02:15:47 2012 +0100 +++ b/Lib/test/test_dtrace.py Sun Feb 26 22:56:03 2012 -0800 @@ -78,6 +78,9 @@ self.assertEqual(actual_result, expected_result) def test_stack(self) : +if sys.platform == 'darwin': +raise unittest.SkipTest, "No jstack support on Mac OS X" + dscript = """ python$target:::function-entry /(copyinstr(arg0)=="%(path)s") && ``` Then the result is: ``` [last: 0] marca@SCML-MarcA:~/src/python-hg/cpython-2011$ sudo ~/custom/bin/python Lib/test/test_dtrace.py test_function_entry_return (__main__.DTraceTestsNormal) ... ok test_garbage_collection (__main__.DTraceTestsNormal) ... ok test_instance_creation_destruction (__main__.DTraceTestsNormal) ... ok test_line (__main__.DTraceTestsNormal) ... ok test_stack (__main__.DTraceTestsNormal) ... skipped 'No jstack support on Mac OS X' test_verify_opcodes (__main__.DTraceTestsNormal) ... ok -- Ran 6 tests in 0.561s OK (skipped=1) test_function_entry_return (__main__.DTraceTestsOptimize) ... ok test_garbage_collection (__main__.DTraceTestsOptimize) ... ok test_instance_creation_destruction (__main__.DTraceTestsOptimize) ... ok test_line (__main__.DTraceTestsOptimize) ... ok test_stack (__main__.DTraceTestsOptimize) ... skipped 'No jstack support on Mac OS X' test_verify_opcodes (__main__.DTraceTestsOptimize) ... ok -- Ran 6 tests in 0.577s OK (skipped=1) ``` By the way, I have some virtual machines set up for OpenIndiana b151A and FreeBSD 9.0, so you need some testing on those platforms, let me know. -- ___ Python tracker <http://bugs.python.org/issue13405> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13405] Add DTrace probes
Marc Abramowitz added the comment: All tests pass on OpenIndiana b151A (SunOS openindiana 5.11 oi_151a2 i86pc i386 i86pc Solaris). -- ___ Python tracker <http://bugs.python.org/issue13405> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13405] Add DTrace probes
Marc Abramowitz added the comment: I get a build error on FreeBSD 9.0: make: don't know how to make ./Include/phelper_offsets.h. Stop Any ideas? -- ___ Python tracker <http://bugs.python.org/issue13405> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13405] Add DTrace probes
Marc Abramowitz added the comment: Re my comment in #154513, the following seems to fix that problem on FreeBSD 9.0: [marca@freebsd9-0 ~/src/cpython-2011]$ hg diff Makefile.pre.in diff -r 70dc1e48bd7f Makefile.pre.in --- a/Makefile.pre.in Mon Feb 27 22:43:17 2012 +0100 +++ b/Makefile.pre.in Mon Feb 27 14:20:18 2012 -0800 @@ -632,7 +632,7 @@ elsetouch $@ ; \ fi; -Include/phelper_offsets.h: $(srcdir)/Include/phelper_offsets.c $(srcdir)/Python/ceval.o +$(srcdir)/Include/phelper_offsets.h: $(srcdir)/Include/phelper_offsets.c $(srcdir)/Python/ceval.o $(CC) $(PY_CFLAGS) -o $(srcdir)/Include/phelper_offsets \ $(srcdir)/Include/phelper_offsets.c $(srcdir)/Include/phelper_offsets.sh $(DTRACE_NM) \ I'm now struggling with some other errors: gcc -pthread -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -DPy_BUILD_CORE -c ./Modules/xxsubtype.c -o Modules/xxsubtype.o if test "dtrace" != "" ; then dtrace -o Python/dtrace.o -64 -C -G -s ./Include/pydtrace.d Python/ceval.o Modules/gcmodule.o Objects/classobject.o Objects/typeobject.o; elsetouch Python/dtrace.o ; fi; gcc -pthread -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -DPy_BUILD_CORE -o ./Include/phelper_offsets ./Include/phelper_offsets.c ./Include/phelper_offsets.sh OTHER ./Python/ceval.o ./Include/phelper_offsets > ./Include/phelper_offsets.h if test "dtrace" != "" ; then dtrace -o Python/phelper.o -DPHELPER -64 -I. -IInclude -I./Include -C -G -s ./Include/phelper.d ; else touch Python/phelper.o ; fi; dtrace: failed to compile script ./Include/phelper.d: line 3: useless declaration *** Error code 1 -- ___ Python tracker <http://bugs.python.org/issue13405> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13405] Add DTrace probes
Marc Abramowitz added the comment: Limiting to 10.6 and above seems entirely reasonable to me. I am one of the few folks that I know who is still on 10.6. Most of my friends are on 10.7. Since OS X is primarily a desktop OS, I think people tend to upgrade more quickly compared to more of a server OS like Solaris. For instance, I stayed on 10.5 for a while but was eventually forced to upgrade to 10.6, because I wanted to do iOS development and the Xcode and developer SDK needed to do that required 10.6. That right there kind of tells you that even Apple is not really supporting 10.5 for development. Also, if you target 10.6, I can test it for you. If you target 10.5, I don't have a 10.5 machine to test with. So if it's at all hard to support 10.5, I'd say skip it and someone else can do it if they really need it. But I doubt that will happen. -- ___ Python tracker <http://bugs.python.org/issue13405> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13405] Add DTrace probes
Marc Abramowitz added the comment: I wanted to post an update on FreeBSD 9.0, which Jesús and I worked on a bit yesterday. Maybe Jordan will chime in here with an answer to my FreeBSD problems. :-) With a little bit of Makefile hackery (make it skip building the phelper stuff which was failing with a "useless declaration" error and which is for jstack which might not be supported on FreeBSD), I got Python to build with Jesús's patches. But I couldn't actually dtrace anything with it. And then I stepped back and tried to dtrace other programs to see if userland DTrace was working and I ran into all kinds of problems, including killing the traced program and a (reproduceable) kernel panic. Here's a question that I posted about it on the FreeBSD-questions mailing list: http://lists.freebsd.org/pipermail/freebsd-questions/2012-February/238862.html If I can get the FreeBSD DTrace support working without too much effort, then I'll do it, but if it's problematic, then I might skip it and focus on helping Jesús test his stuff on OS X and OpenIndiana. -- ___ Python tracker <http://bugs.python.org/issue13405> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13405] Add DTrace probes
Marc Abramowitz added the comment: [marca@freebsd9-0 ~]$ /home/marca/custom/bin/python Python 2.7.2+ (dtrace-issue13405_2.7:e612f29478e3+, Feb 27 2012, 20:37:22) [GCC 4.2.1 20070831 patched [FreeBSD]] on freebsd9 Type "help", "copyright", "credits" or "license" for more information. >>> [marca@freebsd9-0 ~]$ sudo dtrace -n 'pid$target:python::entry' -c /home/marca/custom/bin/python Python 2.7.2+ (dtrace-issue13405_2.7:e612f29478e3+, Feb 27 2012, 20:37:22) [GCC 4.2.1 20070831 patched [FreeBSD]] on freebsd9 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.getpid() 2541 >>> dtrace: failed to control pid 2541: process exited with status 0 [marca@freebsd9-0 ~]$ ps auxww | grep python marca 2546 0.0 2.3 27452 5668 1 S+3:29AM 0:00.02 /home/marca/custom/bin/python [marca@freebsd9-0 ~]$ sudo dtrace -n 'pid2546:python::entry' [marca@freebsd9-0 ~]$ ps auxww | grep python marca 2552 0.0 0.5 16460 1244 0 S+3:29AM 0:00.00 grep python In the above case, the python proces (pid 2546) died with: >>> Killed: 9 Why would DTrace kill -9 the program it's tracing? -- ___ Python tracker <http://bugs.python.org/issue13405> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13405] Add DTrace probes
Marc Abramowitz added the comment: For anyone who is curious about the FreeBSD 9.0 DTrace userland problems I experienced, see http://www.freebsd.org/cgi/query-pr.cgi?pr=165541 -- ___ Python tracker <http://bugs.python.org/issue13405> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14204] Support for the NPN extension to TLS/SSL
New submission from Colin Marc : Recent versions of OpenSSL (1.0.1 and greater) support a new extension to SSL/TLS called Next Protocol Negotiation, defined here: http://tools.ietf.org/html/draft-agl-tls-nextprotoneg-02. The extension allows servers and clients to advertise which protocols they support (for example, both HTTP and SPDY) and then agree on one during the handshake according to a simple algorithm. This patch to 2.7 adds support for the NPN extension via another parameter to ssl.wrap_socket, called 'npn_protocols', and by using the OpenSSL API. It should fail gracefully if the linked version of OpenSSL has no support for NPN, using a macro guard. Once the handshake is completed, SSLSocket.selected_protocol() returns whatever was agreed upon. Although I included client/server tests with the patch, testing this functionality in real-life situations proved difficult. Google chrome has SPDY and NPN functionality baked in, so I wrote a simple socket server that advertises SPDY/2 in addition to HTTP/1.1. Chrome, pointed at this server, correctly completed the handshake and started merrily sending SPDY control frames. -- files: npn_patch.diff keywords: patch messages: 154973 nosy: colinmarc priority: normal severity: normal status: open title: Support for the NPN extension to TLS/SSL type: enhancement versions: Python 2.7 Added file: http://bugs.python.org/file24739/npn_patch.diff ___ Python tracker <http://bugs.python.org/issue14204> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14204] Support for the NPN extension to TLS/SSL
Colin Marc added the comment: If I ported it to 3.3 or 3.4, would it then be backported to 2.7? Or is there zero chance of that either? If so, why? I apologize, I'm new to the process. -- ___ Python tracker <http://bugs.python.org/issue14204> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14204] Support for the NPN extension to TLS/SSL
Colin Marc added the comment: Re the IETF draft: I'm not sure. However, I didn't actually have to implement the specification at all - that was all handled by OpenSSL. My patch just calls the appropriate SSL_CTX_* methods. Thanks for the tip. I'm still interested in this getting included, so I'll work on porting it over. -- ___ Python tracker <http://bugs.python.org/issue14204> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14204] Support for the NPN extension to TLS/SSL
Colin Marc added the comment: Here's an updated patch against 3.3. -- Added file: http://bugs.python.org/file24775/npn_patch_py3.diff ___ Python tracker <http://bugs.python.org/issue14204> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14204] Support for the NPN extension to TLS/SSL
Colin Marc added the comment: Oops, I had my vim configured wrong and left a few tab characters in there. Here's another updated patch =) -- Added file: http://bugs.python.org/file24777/npn_patch_py3.diff ___ Python tracker <http://bugs.python.org/issue14204> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14204] Support for the NPN extension to TLS/SSL
Colin Marc added the comment: Here's the OpenSSL code I referenced for my implementation. It's an excerpt of ssl/lib_ssl.c, starting at line 1514. -- Added file: http://bugs.python.org/file24778/npn_openssl_ref.c ___ Python tracker <http://bugs.python.org/issue14204> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14204] Support for the NPN extension to TLS/SSL
Colin Marc added the comment: Updated patch. -- Added file: http://bugs.python.org/file24786/npn_patch_py3.diff ___ Python tracker <http://bugs.python.org/issue14204> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14204] Support for the NPN extension to TLS/SSL
Colin Marc added the comment: More updates to the patch. -- Added file: http://bugs.python.org/file24797/npn_patch_py3.diff ___ Python tracker <http://bugs.python.org/issue14204> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14285] Traceback wrong on ImportError while executing a package
New submission from Marc Schlaich : It is very simple to reproduce this error. There is an executable package: package/ __init__.py __main__.py The __init__ imports a missing module: import missing_module And the __main__ imports from it: from . import missing_module Now I get the following output which is not what I am expecting: C:\Python27\python.exe: No module named missing_module; 'package' is a package and cannot be directly executed -- messages: 155574 nosy: ms4py priority: normal severity: normal status: open title: Traceback wrong on ImportError while executing a package type: behavior versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue14285> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13405] Add DTrace probes
Marc Abramowitz added the comment: Hey Jesús, Let me know if you need any additional help testing. Marc -- ___ Python tracker <http://bugs.python.org/issue13405> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35596] Fatal Python error: initfsencoding: unable to load the file system codec zipimport.ZipImportError: can't find module 'encodings'
Change by Marc Schlaich : -- nosy: +schlamar ___ Python tracker <https://bugs.python.org/issue35596> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9400] multiprocessing.pool.AsyncResult.get() messes up exceptions
Marc Schlaich added the comment: Davin, why isn't just one of the simple one-line patches applied. This would be much more reasonable instead of closing this as won't fix. This is a really ugly bug and it took me hours to find the cause... -- nosy: +schlamar ___ Python tracker <https://bugs.python.org/issue9400> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35699] distutils cannot find Build Tools 2017 since 3.7.2
New submission from Marc Schlaich : vshwere.exe doesn't return Build Tools 2017 per default. This means Build Tools 2017 are not detected by distutils in 3.7.2 and you get the famous "Microsoft Visual C++ 14.0 is required" error. Please see https://github.com/Microsoft/vswhere/issues/125 for more details. The solution is to add "-products", "*", to the vswhere.exe call. This is a regression of https://bugs.python.org/issue35067. -- components: Distutils messages: 12 nosy: dstufft, eric.araujo, schlamar, steve.dower priority: normal severity: normal status: open title: distutils cannot find Build Tools 2017 since 3.7.2 type: behavior versions: Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue35699> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35699] distutils cannot find Build Tools 2017 since 3.7.2
Marc Schlaich added the comment: We are passing arguments -latest(Return only the newest version and last installed.) and "-requires", "Microsoft.VisualStudio.Component.VC.Tools.x86.x64", So this should handle the cases multiple installs and different products without compilers. I try to get a PR ready. -- ___ Python tracker <https://bugs.python.org/issue35699> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35699] distutils cannot find Build Tools 2017 since 3.7.2
Change by Marc Schlaich : -- keywords: +patch pull_requests: +11016 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue35699> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35699] distutils cannot find Build Tools 2017 since 3.7.2
Change by Marc Schlaich : -- keywords: +patch, patch, patch pull_requests: +11016, 11017, 11018 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue35699> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35699] distutils cannot find Build Tools 2017 since 3.7.2
Change by Marc Schlaich : -- keywords: +patch, patch pull_requests: +11016, 11017 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue35699> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35840] Control flow inconsistency on closed asyncio stream
New submission from Marc Schlaich : After closing a StreamWriter the `StreamReaderProtocol.connection_lost` on the other end is not getting called. In this case the StreamReader is at EOF but calling write/drain does not raise any Exception (and sending data to Nirvana). I would expect that StreamWriter.is_closing returns True after the close and calling write/drain raises immediately and not just after the second call. Please see attached example. I see the same behavior with Proactor and Selector event loop on Windows. Maybe this is expected behavior. But in this case it is completely undocumented. Should there be a check for `StreamReader.at_eof` (and maybe `StreamReader.exception`) before writing to the StreamWriter? This might be related to bpo-34176. -- components: asyncio files: tcp_test.py messages: 334450 nosy: asvetlov, schlamar, yselivanov priority: normal severity: normal status: open title: Control flow inconsistency on closed asyncio stream type: behavior versions: Python 3.7 Added file: https://bugs.python.org/file48082/tcp_test.py ___ Python tracker <https://bugs.python.org/issue35840> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35840] Control flow inconsistency on closed asyncio stream
Marc Schlaich added the comment: After having a closer look I fear that there isn't a correct implementation for half closed sockets and returning True from eof_received results in a fundamentally broken state machine. I'm not sure if a selector implementation can handle half closed sockets, at least I'm pretty sure that this is not supported on Windows (https://docs.microsoft.com/en-us/windows/desktop/api/winsock2/nf-winsock2-select). -- ___ Python tracker <https://bugs.python.org/issue35840> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35872] Creating venv from venv no longer works in 3.7.2
New submission from Marc Schlaich : Creating a venv from the python.exe from another venv does not work since 3.7.2 on Windows. This is probably related to the change bpo-34977: venv on Windows will now use a python.exe redirector rather than copying the actual binaries from the base environment. For example running c:\users\$USER\.local\pipx\venvs\pipx-app\scripts\python.exe -m venv C:\Users\$USER\.local\pipx\venvs\tox C:\Users\$USER\.local\pipx\venvs\tox\Scripts\python.exe -m pip install --upgrade pip results in pip installing to venvs\pipx-app and not in venvs\tox. Downstream bugreport in pipx is https://github.com/pipxproject/pipx-app/issues/81. -- components: Library (Lib), Windows messages: 334658 nosy: paul.moore, schlamar, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Creating venv from venv no longer works in 3.7.2 type: behavior versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue35872> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35873] Controlling venv from venv no longer works in 3.7.2
New submission from Marc Schlaich : Controlling a venv from the python.exe from another venv does not work since 3.7.2 on Windows. This is probably related to the change bpo-34977: venv on Windows will now use a python.exe redirector rather than copying the actual binaries from the base environment. This is obviously related to bpo-35872, but this could be a different bug. When a Python script in a venv wants to control another venv by running commands like `another-venv\python.exe -m pip` with subprocess, python.exe is not referencing the other venv. It is referencing to the venv the script currently running from. This is probably because os.environ contains a '__PYVENV_LAUNCHER__' which is pointing to the venv from the script. This can be reproduced with pipx (https://github.com/pipxproject/pipx-app) by running pipx install --python "C:\Program Files (x86)\Python37-32\python.exe" --verbose tox This results in pip installing to venvs\pipx-app and not in venvs\tox. I assume a simpler reproduction might be (but I cannot check this anymore as I'm back on 3.7.1 right now): C:\Program Files (x86)\Python37-32\python.exe -m venv C:\Users\$USER\.local\pipx\venvs\tox c:\users\$USER\.local\pipx\venvs\pipx-app\scripts\python.exe -c "import subprocess; subprocess.run(['C:\Users\$USER\.local\pipx\venvs\tox\Scripts\python.exe', '-m', 'pip', 'install', 'tox'])" Downstream bugreport in pipx is https://github.com/pipxproject/pipx-app/issues/81. -- components: Library (Lib), Windows messages: 334659 nosy: paul.moore, schlamar, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Controlling venv from venv no longer works in 3.7.2 type: behavior versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue35873> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35840] Control flow inconsistency on closed asyncio stream
Marc Schlaich added the comment: No, I'm seeing the same issue on MacOS. Attached modified example. -- Added file: https://bugs.python.org/file48160/tcp_test.py ___ Python tracker <https://bugs.python.org/issue35840> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
