Mailman 3 May 2018 - docs

[issue19124] os.execv executes in background on Windows
by Jakub Wilk May 15, 2018

May 15, 2018

Change by Jakub Wilk <jwilk(a)jwilk.net>: ---------- nosy: +jwilk _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue19124> _______________________________________

1 0

[issue24318] Better documentaiton of profile-opt (and release builds in general?)
by Gregory P. Smith May 15, 2018

May 15, 2018

Change by Gregory P. Smith <greg(a)krypto.org>: ---------- pull_requests: +6537 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue24318> _______________________________________

1 0

[issue33479] Document tkinter and threads
by Mark Roseman May 15, 2018

May 15, 2018

Mark Roseman <mark(a)markroseman.com> added the comment: Hi Ivan, thanks for your detailed response. The approach you're suggesting ("Since the sole offender is their threading model, the way is to show them how it's defective and work towards improving it.") is in the end not something I think is workable. Some historical context. Ousterhout had some specific ideas about how Tcl/Tk should be used, and that was well-reflected in his early control of the code base. He was certainly outspoken against threads. The main argument is that they're complicated if you don't know what you're doing, which included the "non-professional programmers" he considered the core audience. Enumerating how threads were used at the time, most of the uses could be handled (more simply) in other ways, such as event-driven and non-blocking timers and I/O (so what people today would refer to as the "node.js event model"). Threads (or separate communicating processes) were for long-running computations, things he always envisioned happening in C code (written by more "professional programmers"), not Tcl. His idea of how Tcl and C development would be split didn't match reality given faster machines, more memory, etc. The second thing is that Tcl had multiple interpreters baked in pretty much from the beginning at the C level and exposed fairly early on (1996?) at the Tcl level, akin to PEP 554. Code isolation and resource management were the key motivators, but of course others followed. Creating and using Tcl interpreters was quick, lightweight (fast startup, low memory overhead, etc.) and easy. So in other words, the notion of multiple interpreters in Tcl vs. Python is completely different. I had one large application I built around that time that often ended up with hundreds of interpreters running. Which brings me to threads and how they were added to the language. Your guess ("My guess for the decision is it was the easiest way to migrate the code base") is incorrect. The idea of "one thread/one interpreter" was just not seen as a restriction, and was a very natural extension of what had come before. It fit the use cases well (AOLserver was another good example) and was still very understandable from the user level. Contrast with Python's GIL, etc. With that all said, there would be very little motivation to change the Tcl/Tk side to allow multiple threads to access one interpreter, because in terms of the API and programming model that Tcl/Tk advertises, it's simply not a problem. Keep in mind, the people working on the Tcl/Tk core are very smart programmers, know threads very well, etc., so it's not an issue of "they should know better" or "it's old." In other words, "show them how it's defective" is a non-starter. The other, more practical matter in pushing for changes in the Tcl/Tk core, is that there are a fairly small number of people working on it, very part-time. Almost all of them are most interested in the Tcl side, not Tk. Changes made in Tk most often amount to bug fixes because someone's running into something in their own work. Expecting large-scale changes to happen to Tk without some way to get dedicated new resources put into it is not realistic. A final matter on the practical side. As you've carefully noted, certain Tcl/Tk calls now happen to work when called from different threads. Consider those a side-effect of present implementation, not a guarantee. Future core changes could change what can be called from different threads, making the situation better or worse. From the Tcl/Tk perspective, this is not a problem, and would not be caught by any testing, etc. Even if it were, it likely wouldn't be fixed. It would be considered an "abuse" of their API (I think correctly). My suggestion, given the philosophical and practical mismatch, is that Tkinter move towards operating as if the API Tk provides is inviolate. In other words, all calls into a Tcl interpreter happen from the same thread that created the Tcl interpreter. Tkinter acts as a bridge between Python and Tcl/Tk. It should present an API to Python programs compatible with the Python threading model. It's Tkinter's responsibility to map that onto Tcl/Tk's single threaded API through whatever internal mechanism is necessary (i.e. pass everything to main thread, block caller thread until get response, etc.) I'd go so far as to suggest that all the Tkapp 'call' code (i.e. every place that Tkinter calls Tcl_Eval) check what thread it's in, and issue a warning or error (at least for testing purposes) if it's being called from the "wrong" thread. Having this available in the near future would help people who are debugging what are fairly inexplicable problems now. The approach of making Tkinter responsible also has the advantage of dealing with far more Tcl/Tk versions and builds. Given in practice that few people are really running into things, and that if they are, they know enough to be able to follow the instruction "all Tkinter calls from the same thread" for now, add the warnings/errors in via whatever "turn on debugging" mechanism makes sense. A future version of Python would include a fully thread-safe Tkinter that internally makes all Tcl/Tk calls from a single thread, as per above. Sorry this is so incredibly long-winded. I hope the context at least is useful information. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue33479> _______________________________________

1 0

[issue33479] Document tkinter and threads
by Ivan Pozdeev May 14, 2018

May 14, 2018

Ivan Pozdeev <ivan_pozdeev(a)mail.ru> added the comment: > This seems very complicated. The official line on threads for Tk has always been to make all Tk calls from one thread, which is at least predictable and comprehensible. Is there any reason for Tkinter to suggest anything different? Tcl/Tk doesn't have a notion of a blocking event loop like other GUI toolkits do. Any code using Tcl must essentially call Tcl_DoOneEvent/`update` regularly at strategic points. This allows to work completely in one thread -- i.e. even if the OS has no threads whatsoever. Tcl/Tk is very old, and this model made perfect sense back then (and still does in some scenarios -- e.g. https://stackoverflow.com/questions/4083796/how-do-i-run-unittest-on-a-tkin… -- so there's no point in dropping it). If we'll be updating tutorials (the reference is a priority though), we definitly need to demonstrate this option. The current best practice for GUI programming is different. There's one "GUI" thread that runs just the event loop constantly, and other threads submit GUI-related work items into its queue (whatever they are called - "messages", "events", "futures"...). Likewise, for any lengthy task, the GUI thread spawns worker threads that report back on their progress via the same queue. All more or less modern GUI toolkits implement and advertize this model as the primary one -- as does Tkinter. So, at least the work item submitting API must be thread-safe (and in other GUI tooltikts, it is -- see https://mail.python.org/pipermail/python-dev/2018-May/153359.html ). For programmer's convenience, Tkinter does this transparently: whenever and whatever Python thread a call is made from, it makes it look for the Tcl interpreter as if all calls are sequential, and it enforces correct order for interdependent calls. A great deal of complexity comes from the fact that Tcl's threading model is very unothodox. Tcl's team seem to only have accepted threads reluctantly and to have been campaigning against threads for years before that (https://wiki.tcl.tk/38128 is arguably the most egregious case). So, what they did is tie a Tcl interpreter to an OS thread (by using thread local storage for its data). Long story short, no-one else does it like this (at least, I've never seen or heard of anything of the kind), and this is not what thread-local storage is meant for (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4324.html lists some use cases for TLS). The best practice is to use locks to ensure orderly access to the shared state instead. My guess for the decision is it was the easiest way to migrate the code base (yet still tough as https://wiki.tcl.tk/1370 seems to hint), and it kinda lines up with that "single thread" mindset. Tkinter thus has to jump through hoops for calls coming from other threads (since for Python, it absolutely doesn't matter which OS thread makes a call). All the limitations when using threaded Tcl (see the letter attached to the ticket for details) come solely from this tying. With nonthreaded Tcl (bugs nonwithstanding), it's free-for-all, everything can be called from everywhere. The only upside is that with threaded Tcl, calls to different interpreters can run in parallel. > This ignores the compilation issue of course. FYI, the Tcl core group will probably eliminate the possibility of doing non-threaded builds in the future, though with backwards compatibility issues, that's neither here nor there. I know. Me asking them for clarifications from Tcl/Tk's side seems to have triggered it, in fact. Since the sole offender is their threading model, the way is to show them how it's defective and work towards improving it. We have at least a few years with old versions, and the limitations seem tolerable at first glance anyway, so that's not a priority. > do you know how to identify the tcl/tk build on MacOS or Linux? The same way Tkinter does @_tkinter.c:624 . The equivalent Python is `tkinter.Tk().tk.call("array","get","tcl_platform","threaded")` ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue33479> _______________________________________

1 0

[issue33479] Document tkinter and threads
by Terry J. Reedy May 14, 2018

May 14, 2018

Terry J. Reedy <tjreedy(a)udel.edu> added the comment: The official line is the claim in the docs that tkinter *is* threadsafe, repeated by Martin on at least one issue. See the first paragraph above. Therein lies the problem. A reason to not just reverse the claim is that it is, at least for practical purposes, true, by default, for 8.6. See the opening post of #11077 for one motivation for calling from threads. (Numerous others have tried and reported failures, though usually without explaining why they tried.) Mark, do you know how to identify the tcl/tk build on MacOS or Linux? If so, and you have installed 3.7.0 on MacOS since b0, which includes 8.6.8, can you report which it is? Ditto for any Linux distribution you have. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue33479> _______________________________________

1 0

[issue33479] Document tkinter and threads
by Mark Roseman May 14, 2018

May 14, 2018

Mark Roseman <mark(a)markroseman.com> added the comment: This seems very complicated. The official line on threads for Tk has always been to make all Tk calls from one thread, which is at least predictable and comprehensible. Is there any reason for Tkinter to suggest anything different? This ignores the compilation issue of course. FYI, the Tcl core group will probably eliminate the possibility of doing non-threaded builds in the future, though with backwards compatibility issues, that's neither here nor there. ---------- nosy: +markroseman _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue33479> _______________________________________

1 0

[issue14845] list(<generator expression>) != [<list comprehension>]
by Cheryl Sabella May 14, 2018

May 14, 2018

Change by Cheryl Sabella <chekat2(a)gmail.com>: ---------- status: open -> pending _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue14845> _______________________________________

1 0

[issue26103] Contradiction in definition of "data descriptor" between (dotted lookup behavior/datamodel documentation) and (inspect lib/descriptor how-to)
by Serhiy Storchaka May 14, 2018

May 14, 2018

Change by Serhiy Storchaka <storchaka+cpython(a)gmail.com>: ---------- versions: +Python 3.8 -Python 3.5 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue26103> _______________________________________

1 0

[issue22069] TextIOWrapper(newline="\n", line_buffering=True) mistakenly treat \r as a newline
by Mariatta Wijaya May 14, 2018

May 14, 2018

Change by Mariatta Wijaya <mariatta.wijaya(a)gmail.com>: ---------- resolution: -> fixed _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue22069> _______________________________________

1 0

[issue22069] TextIOWrapper(newline="\n", line_buffering=True) mistakenly treat \r as a newline
by Mariatta Wijaya May 14, 2018

May 14, 2018

Mariatta Wijaya <mariatta.wijaya(a)gmail.com> added the comment: Thanks! ---------- stage: patch review -> resolved status: open -> closed versions: +Python 2.7, Python 3.6 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue22069> _______________________________________

1 0