[issue33239] tempfile module: functions with the 'buffering' option are incorrectly documented
Martin Falatic <mar...@falatic.com> added the comment: The correction of `buffering=None` --> `buffering=-1` for the defaults definitely needs to happen. A reference to `open()` is already present in the 3.x documentation: "buffering, encoding and newline are interpreted as for open()." Given that the `open()` reference already suffices for `encoding` and `newline`, it ought to suffice for `buffering` as well. No extra text beyond that should be necessary (I originally thought that might be good to add, but looking at this now it's clear if you add more to describe `buffering` you'll need to add it for the other two options, and it's all duplicative. Fixing the defaults should suffice.) -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33239> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33239] tempfile module: functions with the 'buffering' option are incorrectly documented
New submission from Martin Falatic <mar...@falatic.com>: The documentation for the tempfile module in Python 3.x for the `buffering` option is incorrect: https://docs.python.org/3/library/tempfile.html TemporaryFile, NamedTemporaryFile, and SpooledTemporaryFile all take the `buffering` option, which in turn appears to correlate to the Python 2.7 option `bufsize`, which was and continues to be an integer (per the source). In the 3.x documentation the default signature for TemporaryFile, NamedTemporaryFile, and SpooledTemporaryFile includes `buffering=None`. Actually specifying None as a default for this will cause an exception (`TypeError: an integer is required (got type NoneType)`). There is a cross-reference in the 3.x tempfile docs to `open` (https://docs.python.org/3/library/functions.html#open) which in turn shows the correct signature to use for `buffering`. Additionally, the source code is clearly documented (https://github.com/python/cpython/blob/master/Lib/tempfile.py) A good correction would be to ensure `buffering=-1` is documented as the default for the three functions in tempfile, with an additional note explicitly stating that -1 == no buffering, and the existing `open` cross-reference retained. -- assignee: docs@python components: Documentation messages: 315072 nosy: MartyMacGyver, docs@python priority: normal severity: normal status: open title: tempfile module: functions with the 'buffering' option are incorrectly documented versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33239> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23982] Tkinter in Python 3.4 for Windows incorrectly renders certain colors using non-TclTk RGB values
Martin Falatic added the comment: Works, using = this works, it's what I'm using (was trying to be brief - was too brief evidently). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23982 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23982] Tkinter in Python 3.4 for Windows incorrectly renders certain colors using non-TclTk RGB values
Martin Falatic added the comment: There may be a more uniform way to do all this that I'm not aware of. root.tcl.call() and root.tk.call() would be most symmetric while not creating extraneous windows, but that's not an option for the former, thus the methods I ended up using look different for Tk and Tcl. Whatever the output, a tuple (8,5,9) or string 8.5.9 (easily converted to a tuple) will be nice, hiding any disparate implementation details. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23982 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23982] Tkinter in Python 3.4 for Windows incorrectly renders certain colors using non-TclTk RGB values
Martin Falatic added the comment: No, I don't expect something like the color change to be documented here (unless that thing is incorrectly documented within python.org's current release trees). I do expect that just as python.org's OSX releases document the recommended version of TclTk to use (e.g., https://www.python.org/download/mac/tcltk/) there should be equivalent documentation describing what version of TckTk is actualy compiled into the Windows releases here (e.g., 8.5.9 or 8.6.4 or such. (Note that Tkinter.TclVersion/TkVersion aren't sufficiently detailed to dynamically determine the exact in-built versions either). Beyond that, it's up to the user to read more about that specified or recommended release in the external Tcl/Tk docs (except where such documentation is present in the doc trees on python.org). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23982 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23982] Tkinter in Python 3.4 for Windows incorrectly renders certain colors using non-TclTk RGB values
Martin Falatic added the comment: Yes, the python.org releases specify the TclTK they should be used with, for OSX: https://www.python.org/download/mac/tcltk/ If there's another python.org bug report list let me know, but this still seems to be the right place. Since Python.org's windows distribution is what led to this question, I'd like to at least see it documented somewhere what TclTk is compiled into the Python.org windows distribution. I didn't find any info on what TclTk Python.org's Windows build includes, and that's something that can be rectified here. (Since there are documented *recommendations* for what to use with the OSX builds from this site then there ought to be some similar documentation what is *built in* to the Windows builds from this site.) As for the failure of TclTk to properly document the change they made to their colors, that's a matter for their bug tracker. I took their documentation at face value, and didn't find information to the contrary when I searched prior to posting this. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23982 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23982] Tkinter in Python 3.4 for Windows incorrectly renders certain colors using non-TclTk RGB values
Martin Falatic added the comment: FYI, I've filed a bug with the TclTk people regarding their documentation. http://core.tcl.tk/tk/tktview/2a02881e4c23634022d0ae40a14383d9baad9eb9 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23982 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23982] Tkinter in Python 3.4 for Windows incorrectly renders certain colors using non-TclTk RGB values
Martin Falatic added the comment: Thank you. Before going down the road of revising PEP 101 (which appears to be very non-trivial despite the simple (and certainly always present) data involved), I'd like to know: is version information about the pre-compiled Windows binaries (of which this is one) already being captured anywhere else publically visible on a per-release or per-build basis? It's useful that such binaries exist given Windows' unique requirements versus other systems, but are these binaries themselves documented anywhere as they are updated (e.g., how to re-create them)? Such a source of truth would simplify that revision request. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23982 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23982] Tkinter in Python 3.4 for Windows incorrectly renders certain colors using non-TclTk RGB values
Martin Falatic added the comment:
FYI, I'm currently using calls into Tkinter to get more detailed version info.
Some methods work better than others... I've outlined my attempts below for
reference (the last tcl_ver and tk_ver outputs are the ones I'm using, even
though they are somewhat different in how they are written).
try: # Python2
import Tkinter as tk
except ImportError: # Python3
import tkinter as tk
root = tk.Tk()
tcl_ver = tk.TclVersion # Typical but low precsion
tcl_ver = tk.Tcl().eval('info patchlevel') # Works but uses eval()
tcl_ver = root.tcl.call('info', 'patchlevel') # Fails (AttributeError)
tcl_ver = tk.Tcl().call('info', 'patchlevel') # Works, using
tk_ver = tk.TkVersion # Typical but low precsion
tk_ver = tk.Tk().eval('info patchlevel') # Works but makes extra window, uses
eval()
tk_ver = tk.Tk().call('info', 'patchlevel') # Works but makes extra window
tk_ver = root.tk.call('info', 'patchlevel') # Works, using
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23982
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23982] Tkinter in Python 3.4 for Windows incorrectly renders certain colors using non-TclTk RGB values
Martin Falatic added the comment: This change wasn't in their documentation anywhere: http://www.tcl.tk/man/tcl8.5/TkCmd/colors.htm http://www.tcl.tk/man/tcl8.6/TkCmd/colors.htm It would be of value to call this out in the Python documentation (as far as I can find, there's nothing specifying which version of TclTk goes with what version of Python for Windows). As for OSX, it appears to use whatever TclTk is installed on the system. The recommended version isn't consistent with this change either - Python specifies 8.5 for 2.7 and 3.4: https://www.python.org/download/mac/tcltk/ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23982 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23982] Tkinter in Python 3.4 for Windows incorrectly renders certain colors using non-TclTk RGB values
New submission from Martin Falatic: In Python 2.7.9 for Windows, colors displayed match their RGB values as defined in TclTk: http://www.tcl.tk/man/tcl8.5/TkCmd/colors.htm (8.6 is identical) In Python 3.4.3 for Windows, the following colors differ noticeably from their TclTk counterparts: grey/gray, green, purple, and maroon. Instead of the spec TclTk RGB values, these particular colors are rendered using the HTML RGB values. This only happens in Python for Windows - OSX doesn't have this problem as it appears to use the same TclTk package for both 2.7 and 3.4 and correctly renders the colors per TclTk specs in each. Tkinter ought to render named colors using the spec TclTk RGB values regardless of platform. -- components: Tkinter files: colortest.py messages: 241300 nosy: MartyMacGyver priority: normal severity: normal status: open title: Tkinter in Python 3.4 for Windows incorrectly renders certain colors using non-TclTk RGB values type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file39081/colortest.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23982 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
