[issue32830] tkinter documentation suggests "from tkinter import *", contradicting PEP8
Tom Middleton added the comment: While I agree that it shouldn't be imposed on changing previous code, changing the documentation isn't changing the previous code it is encouraging future code. I think that the documentation should have a caveat. I'm seeing a lot of new code using tkinter with glob import which is obviously from the documentation as it suggests doing so. I think that the glob import practice should be overall discouraged. I think adding a disclaimer in the documentation at the reference to `from tkinter import *` would be sufficient. A reference to PEP8 would be good. I'd imagine that most people look up docs and are not as familiar with PEP. Why can't something like that be added to the documentation? -- nosy: +busfault ___ Python tracker <https://bugs.python.org/issue32830> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27564] 2.7.12 Windows Installer package broken.
Tom Middleton added the comment: Ok, so really bizarre. I uninstalled 2.7.11, then I was getting the same error with the 2.7.11 msi. So I was thinking that I should go back to the original version I had installed (2.7.10) the installer showed a "repair" option so I did that, then the 2.7.11 install worked. And then the 2.7.12 installer worked. I would have to agree with Steve Dower. I think that it had something to do with pip because there were a couple cmd windows that popped up during the install process that showed something to do with pip which didn't the first time I ran the installer. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27564> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27564] 2.7.12 Windows Installer package broken.
Tom Middleton added the comment: @Zachary, I tried to uninstall (the C:\python27\ directory seemed to persist after) the install of 2.7.12 failed again same message. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27564> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27564] 2.7.12 Windows Installer package broken.
Tom Middleton added the comment: @Steve, I think my pip install was fine? I was using pip pretty regularly with 2.7.11. I had to do a restore to get 2.7.11 working again, and after an install of 2.7.12 failed again with the same issue. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27564> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27564] 2.7.12 Windows Installer package broken.
New submission from Tom Middleton: I was running: Python 2.7.11 (v2.7.11:6d1b6a68f775, Dec 5 2015, 20:32:19) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. I downloaded the msi for Python 2.7.12 and attempted to run it. During the installation it gave me the following error: "There is a problem with this Windows Installer package. A program required for this install to complete could not be run. Contact your support personnel or package vendor." Then it "rolls back" the action, which killed my current 2.7.11 installation. Despite that it states: "Python 2.7.12 setup ended prematurely because of an error. Your system has not been modified. To install this program at a later time, please run the installation again." (pardon any typos in the error messages since I wasn't able to copy the text directly.) I attempted this twice with the same result. Thanks, Tom -- components: Installation messages: 270762 nosy: busfault priority: normal severity: normal status: open title: 2.7.12 Windows Installer package broken. type: behavior versions: Python 2.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27564> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26866] Inconsistent environment in Windows using "Open With"
Tom Middleton added the comment: I agree with your assessment Steve. I don't see there being a good fix to this. I also think it would be a bad idea to have the launcher change the current working directory. Example: c:\foo\> python d:\scripts\bar.py myfile (where myfile is in c:\foo\) A kludge work around in a script is something like this: import os if __name__ == "__main__": os.chdir(os.path.dirname(__file__)) I also don't think it makes sense to counteract what seems to be a Windows issue in python (or the launcher of which I am less familiar with). I was hoping it was going to be a simple registry setting or something like that which could be handled in the install process. Eryk, you are correct, it was poor coding that led to the issue. I don't think I was clear in my initial post that I realize that opening a file and assuming the directory of the script is the cwd is not good practice. I was commenting that it is inconsistent between launching methods. I was launching a script that was attempting to write a log file using the logging module with a relative path filename. It was a gotcha because it worked fine on my desktop and it wasn't working when a colleague ran it from "Open with". I've since improved my methodology so the issue is moot for that regard. However, it is still interesting that there is an inconsistency in Windows in those methods of execution. FWIW I also tested it out with perl and as I expected, got the same results of working directories. Also please note that I am working in Python 2.7, there is no py launcher as there is in 3. I am not certain what inconsistencies may occur between calling py.exe v. python.exe. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26866> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26866] Inconsistent environment in Windows using "Open With"
Tom Middleton added the comment: That is interesting, in my use #3 seems to work. I am not certain if it matters whether the default application is already selected as python.exe or not. FWIW I'm on Windows 7 64 bit using 2.7.11 release install. **Full Disclosure** I did muck in the registry to get command line arguments to work correctly.(adding the %* to python.exe commands ala #7936) though that shouldn't have any affect on this issue. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26866> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26866] Inconsistent environment in Windows using "Open With"
New submission from Tom Middleton: I have found that the execution of python scripts is inconsistent from the following methods: >From Explorer: 1) Right-Click->Open with->python.exe 2) Right-Click->Open (assuming python.exe being the "default" application) 3) Right-Click->Open with->"Choose default program..."->python.exe 4) Double-Click the script from the command prompt: 4) python 5) Of those listed, #1 opens the script with the CWD as c:\Windows\System32\ The remainder open the script with the CWD (as from os.getcwd()) as the current directory of the executed script. The issue arose when attempting to open a file in the same directory as the script. The issue of how to access a file in the same directory as the script isn't the point of this issue however it is that it is inconsistent across methods that would seem to be identical to the user. A use case for Open with->python.exe is if say you want your default behavior to be open with an IDE. The following other issues I found may be relevant. #22121 #25450 Some digging found this registry entry which may be relevant. HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.py -- components: Installation, Windows messages: 264315 nosy: busfault, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Inconsistent environment in Windows using "Open With" type: behavior versions: Python 2.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26866> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12288] Python 2.7.1 tkSimpleDialog initialvalue
New submission from Tom Middleton busfa...@gmail.com: Using Tkinter under Python 2.7.1 (Windows XP FWIF) If using the tkSimpleDialog.askinteger() function with an initialvalue = 0, the 0 is not displayed in the dialog box. The same is true for tkSimpleDialog.askfloat(). The cause of this seems to be the following: in Lib\libi-tk\tkSimpleDialog.py (attached for convenience) under class _QueryDialog(Dialog) def body(self, master): w = Label(master, text=self.prompt, justify=LEFT) w.grid(row=0, padx=5, sticky=W) self.entry = Entry(master, name=entry) self.entry.grid(row=1, padx=5, sticky=W+E) if self.initialvalue: self.entry.insert(0, self.initialvalue) self.entry.select_range(0, END) return self.entry The if self.initialvalue will evaluate to a FALSE when the initial value is a 0. Changing this line to: if self.initialvalue is not None: fixed this issue. I am not certain that this is as intended or a bug. -- components: Tkinter files: tkSimpleDialog.py messages: 137925 nosy: busfault priority: normal severity: normal status: open title: Python 2.7.1 tkSimpleDialog initialvalue type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file22286/tkSimpleDialog.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12288 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
