🌐 Mailman 3 May 2018 - Python-list - python.org

Is this a bug or a feature in TkInter?
by charmingoldgit＠gmail.com May 11, 2018

May 11, 2018

I'm learning to use TkInter in Python and came across this example program from 'Thinking in TkInter' (http://thinkingtkinter.sourceforge.net) - see below. Two buttons 'button1' and 'button2' are defined. The bug is that event.widget returns '.!frame.!button' from a button1 event. i.e. it somehow drops the '1' from the widget name. Events on button2 are correctly reported. Is this a bug or a feature? <code> from tkinter import * class MyApp: def __init__(self, parent): self.myParent = parent self.myContainer1 = Frame(parent) self.myContainer1.pack() button_name = "OK" self.button1 = Button(self.myContainer1, command=self.buttonHandler(button_name, 1, "Good stuff!")) # self.button1.bind("<Return>", self.buttonHandler_a(event, button_name, 1, "Good stuff!")) self.button1.configure(text=button_name, background="green") self.button1.pack(side=LEFT) self.button1.focus_force() # Put keyboard focus on button1 button_name = "Cancel" self.button2 = Button(self.myContainer1, command=self.buttonHandler(button_name, 2, "Bad stuff!")) # self.button2.bind("<Return>", self.buttonHandler_a(event, button_name, 2, "Bad stuff!")) self.button2.configure(text=button_name, background="red") self.button2.pack(side=LEFT) def buttonHandler(self, arg1, arg2, arg3): print(" buttonHandler routine received arguments:", arg1.ljust(8), arg2, arg3) def buttonHandler_a(self, event, arg1, arg2, arg3): print("buttonHandler_a received event", event) self.buttonHandler(arg1, arg2, arg3) print("\n"*100) # clear the screen print("Starting program tt077.") root = Tk() myapp = MyApp(root) print("Ready to start executing the event loop.") root.mainloop() print("Finished executing the event loop.") </code>

3 3

Re: Is this a bug or a feature in TkInter?
by Cuthbert Milligen May 11, 2018

May 11, 2018

Found it! Thanks again :-)

1 0

Re: Print Failure or success based on the value of the standalone tool
by Rob Gaddi May 11, 2018

May 11, 2018

On 05/10/2018 09:48 AM, Ganesh Pal wrote: > I have to test a standalone tool from a python script and I am using > os.system() to run the tool . I need to take decision based on the return > value of the standalone tool . > > But since os.system merely throws the output value to STDOUT & returns the > exit status (0 => no error) of the shell , how can I make this print Fail > or Pass based on the return value of the standalone tool. > > In the below example ( return_values() function) > [snip] By not using os.system, it's been superseded for reasons exactly like yours. https://docs.python.org/3/library/subprocess.html is your friend. -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix.

4 3

Re: Meaning of abbreviated terms
by T Berger May 11, 2018

May 11, 2018

On Saturday, May 5, 2018 at 6:45:46 PM UTC-4, MRAB wrote: > On 2018-05-05 17:57, T Berger wrote: > > What does the "p" in "plist" stand for? > > Is there a python glossary that spells out the meanings of abbreviated terms? > > > "plist" is "property list". It's listed in the Python documentation. Thanks for the answer. Missed it till now.

3 2

Re: seeking deeper (language theory) reason behind Python design choice
by Marko Rauhamaa May 11, 2018

May 11, 2018

Mikhail V <mikhailwas(a)gmail.com>: > On Wed, May 9, 2018 at 8:50 AM, Chris Angelico <rosuav(a)gmail.com> wrote: >> On Wed, May 9, 2018 at 3:36 PM, Ian Kelly <ian.g.kelly(a)gmail.com> wrote: >>> while True: >> >> Why is it that "while True" is idiomatic Python for a non-infinite >> loop? Is it merely because Python currently has no other way to spell >> certain loops? Surely it would be more idiomatic to encode the loop's >> termination condition in the header, if it were possible. > > Don't know about 'idiomatic', but the above spelling is exactly what i > tend to use lately for almost all loops. It noticeably reduces > cognitive load. Though lately more often i prefer "while 1:" so it > makes the nodes more lightweight and distinct from the rest lines. And > not even official declaration of "idiomatic" as something else will > make me switch back. How about: while ...: do_stuff() if done: break do_more_stuff() where ... is the Ellipsis. Joking aside, to answer Chris's question, of course you can use a real condition with "while". However, you shouldn't force it or try to avoid "while True". It turns out "while True" is the most natural choice in about half of the while loops. Marko

3 2

Re: seeking deeper (language theory) reason behind Python design choice
by Marko Rauhamaa May 11, 2018

May 11, 2018

Chris Angelico <rosuav(a)gmail.com>: > On Fri, May 11, 2018 at 5:59 AM, Marko Rauhamaa <marko(a)pacujo.net> wrote: >> Joking aside, to answer Chris's question, of course you can use a >> real condition with "while". However, you shouldn't force it or try >> to avoid "while True". It turns out "while True" is the most natural >> choice in about half of the while loops. > > So if I understand you correctly, you're saying that a real condition > is better, but "while True" is the best option half the time. In other > words, "while True" is the ONLY option half the time, since any other > option would be better. A real example: def split_cmd(self, cmd): args = [] while True: match = self.TERM_PTN.match(cmd) if match is None: return None, None args.append(match.group('term')) if not match.group('sep'): break cmd = cmd[match.end(0):] verb = args.pop(0).upper() return verb, args You *could* get rid of True. For example: def split_cmd(self, cmd): args = [] match = self.TERM_PTN.match(cmd) while match is not None: args.append(match.group('term')) if not match.group('sep'): verb = args.pop(0).upper() return verb, args cmd = cmd[match.end(0):] match = self.TERM_PTN.match(cmd) return None, None However, that would be a slight stylistic degradation because 1. the redundant matching statement is redundant and 2. an abnormal return is at the bottom of the function. Marko

2 1

Re: Leading 0's syntax error in datetime.date module (Python 3.6)
by bartc May 11, 2018

May 11, 2018

On 10/05/2018 18:58, Skip Montanaro wrote: >> I wonder why someone would take a feature generally agreed to be a >> poorly designed feature of C, and incorporate it into a new language. > > I think you might be looking at a decision made in the late 1980s through a > pair of glasses made in 2018. > > As a C programmer back then I never had a problem with C's octal number > notation. People coming from C, C++ or Java to Python at that time would > certainly have understood that syntax. It's only in the past 15 years or so > that we've seen tons of people coming to Python as a first language for > whom leading zero notation would be unfamiliar. I'm pretty sure I would have had exactly the same opinion in 1989. Decimal numbers in code should reflect their usage in everyday life as much as possible. And in everyday life, leading zeros do not change the base of a number so that it becomes octal. If my car odometer says 075300, it means I've done 75,300 miles or km, not 31424: mileages = ( # python 2 215820, 121090, 075300, 005105) for m in mileages: print m,"miles" Output: 215820 miles 121090 miles 31424 miles 2629 miles This is Wrong, and would have been just as obviously wrong in 1989. -- bartc

2 1

Re: seeking deeper (language theory) reason behind Python design choice
by Peter Pearson May 10, 2018

May 10, 2018

On Wed, 09 May 2018 12:51:15 -0700, Paul Rubin wrote: > Dennis Lee Bieber <wlfraed(a)ix.netcom.com> writes: >> Yes, code reviews may catch such errors... and later, when the >> summary of errors is analyzed for suggestions on how to reduce them -- >> the odds are good that "assignment expressions" will be banned in the >> style documents for that language at the company. > > I don't think I've worked on any C programs with that style restriction > and I can't think of any times when I found that type of bug in deployed > code. I've made the error once or twice while coding, but caught it > right away during inspection or testing. Banning it seems > counterproductive. I could imagine having it flagged by a compiler > warning that can be locally disabled by a pragma. Interestingly, the problem is broader than inadvertently making the mistake yourself; it includes catching deliberate misdirection by others. In the famous "Linux Backdoor Attempt of 2003" (https://freedom-to-tinker.com/2013/10/09/the-linux-backdoor-attempt-of-2003/), somebody who I think never got caught introduced these lines into the code for the wait4 function: if ((options == (__WCLONE|__WALL)) && (current->uid = 0)) retval = -EINVAL; Setting the user ID to zero confers root privileges. - Peter

1 0

Re: Leading 0's syntax error in datetime.date module (Python 3.6)
by Jon Ribbens May 10, 2018

May 10, 2018

On 2018-05-10, Skip Montanaro <skip.montanaro(a)gmail.com> wrote: >> I wonder why someone would take a feature generally agreed to be a >> poorly designed feature of C, and incorporate it into a new language. > > I think you might be looking at a decision made in the late 1980s through a > pair of glasses made in 2018. > > As a C programmer back then I never had a problem with C's octal number > notation. People coming from C, C++ or Java to Python at that time would > certainly have understood that syntax. It's only in the past 15 years or so > that we've seen tons of people coming to Python as a first language for > whom leading zero notation would be unfamiliar. This whole thread is reminding me PHP 2, which would magically treat the second parameter of ChMod() as octal, because clearly if weak typing is good then *no* typing must be best of all! ChMod($filename, 644); // second parameter is actually 420 base 10

4 4

Re: Leading 0's syntax error in datetime.date module (Python 3.6)
by bartc May 10, 2018

May 10, 2018

On 10/05/2018 18:03, Ian Kelly wrote: > On Thu, May 10, 2018 at 10:36 AM, bartc <bc(a)freeuk.com> wrote: >> What, 0O100 instead of 0100? Yeah that's a big improvement... >> >> Fortunately octal doesn't get used much. > > The PEP discusses this: > > """ > Proposed syntaxes included things like arbitrary radix prefixes, such > as 16r100 (256 in hexadecimal), and radix suffixes, similar to the > 100h assembler-style suffix. The debate on whether the letter "O" > could be used for octal was intense -- an uppercase "O" looks > suspiciously similar to a zero in some fonts. Suggestions were made to > use a "c" (the second letter of "oCtal"), or even to use a "t" for > "ocTal" and an "n" for "biNary" to go along with the "x" for > "heXadecimal". > > For the string % operator, "o" was already being used to denote octal. > Binary formatting is not being added to the % operator because PEP > 3101 (Advanced String Formatting) already supports binary, % > formatting will be deprecated in the future. > > At the end of the day, since uppercase "O" can look like a zero and > uppercase "B" can look like an 8, it was decided that these prefixes > should be lowercase only, but, like 'r' for raw string, that can be a > preference or style-guide issue. > """ > > Personally I would have preferred the "t". > In my own [syntax] designs, for a long time I used: 100H (256) Hex 100B (4) Binary in addition to decimal. Then I when I switched to 0x for hex (so that I could write 0xABC instead of needing to write 0ABCH with a leading zero), it was easy to extend that scheme: 2x100 (4) Binary 3x100 (9) Ternary 4x100 (16) Quaternary 5x100 (25) etc 6x100 (36) 7x100 (49) 8x100 (64) Octal 9x100 (81) ... (Not implemented 11x to 15x, nor 10x or 16x) 0x100 (256) Hex I think Ada does something similar for example 2#100#. However I wouldn't be bothered at having to use for example OCT(377), HEX(FF), BIN(1111_1111) or even OCTAL(377), although it's a bit clunky. At least it will be obvious; more so than 0o100. -- bartc

2 1