Re: Keeping the Console Open with IDLE
On Friday, February 20, 2009 9:41:42 AM UTC-6, David Smith wrote: What I meant was open open the command prompt, type cd, space, DO NOT hit enter yet. Drag the folder with your script into the command prompt window. Then go to the command prompt window and hit enter. This should compose a command similar to the following: And why the hell would you resort to such contrived contortions as that? Are you masochistic? DoubleClicking an icon will take me less that one second. How long does this sequence take: 1. Open a command prompt 2. type c 3. type d 4. type space 5. hover over the folder icon with your mouse 5.5. Oops, i missed. Go back to step 5! 6. Mouse click the file icon 7. Mouse drag the file icon 8. Position the mouse over prompt window 9. Release the icon 10. Press the Enter key Can anybody say !Ay, caramba!? Besides, you can skip most of those steps by Shift+RightClicking the file icon and choosing Open Command Window Here. But, why the hell would you EVEN do that when two simple clicks will suffice? practicality beats purity -- http://mail.python.org/mailman/listinfo/python-list
Re: howto do a robust simple cross platform beep
On Friday, July 13, 2012 8:00:05 PM UTC-5, gelonida wrote: I just want to use a beep command that works cross platform. [...] I just want to use them as alert, when certain events occur within a very long running non GUI application. I can see a need for this when facing a non GUI interface. But even IF you do manage to play a sound in a cross platform manner; if the speaker volume is too low, or the speakers are turned off, or the computer does not have speakers connected, etc... your user will never hear the alert! In this case, beeping the built-in speaker has the fail-safe advantage. Why not wrap up the functionality and release a module yourself? If you are not sure how to access the speaker on one or more OSs then ask on the list. I would love to see some community effort behind this. PS: Better make sure this module does not exist though ;-) -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter.event.widget: handler gets name instead of widget.
On Thursday, July 12, 2012 1:53:54 PM UTC-5, Frederic Rentsch wrote: The hit list is a table of investment titles (stock, funds, bonds) that displays upon entry of a search pattern into a respective template. The table displays the matching records: name, symbol, ISIN, CUSIP, Sec. Any line can be click-selected. So they are to look like buttons. Hmm. If they appear like a button widget anyway, then why not just use a button widget? Representing the mentioned names and id codes in Label widgets was the simplest way I could come up with to align them in columns, admittedly without the benefit of much experience. But it does look good. the layout is fine. But is it really the simplest? :) ## START CODE ## import Tkinter as tk from Tkconstants import * colWidths = (5,10,30,5) N_COLS = len(colWidths) N_ROWS = 6 root = tk.Tk() for r in range(N_ROWS): # Create some imaginary text to display in each column. # Also try using string methods center and rjust to # see alternative justification of text. lst = [str(r).ljust(colWidths[r]) for r in range(N_COLS)] b=tk.Button(root, text=''.join(lst)) b.pack(padx=5, pady=5) root.mainloop() ## END CODE ## You could easily expand that into something reusable. Now. If you need to place fancy borders around the texts, or use multiple fonts, or use images, or blah blah blah... then you may want to use the canvas items provided by the Tkinter.Canvas widget INSTEAD of buttons. With the canvas, you can create a simple rectangle (canvas.create_rectangle) that represents a button's outside dimension and give it a button styled border. Then you can bind click events to mimic the button press action. Then you can place canvas_text items on top of that fake button and configure them to be invisible to click events. These text items will not interfer like the Tkinter.Label widgets are currently doing. However, i would suggest the Tkinter.Button solution is the easiest by far. I find the Tkinter system quite challenging. Doing a layout isn't so much a matter of dimensioning and placing things as a struggle to trick a number of automatic dimensioning and placing mechanisms into obliging--mechanisms that are rather numerous and hard to remember. I don't think i agree with that assessment. ## START TANGENTIAL MEANDERINGS ## I find the geometry management of Tkinter to be quite powerful whilst being simultaneously simplistic. You only have three main types of management: Grid, Place, and Pack. Each of which has a very specific usage. One caveat to know is that you can NEVER mix Grid and Pack in the same container widget! I find myself using grid and pack the most, with grid being at the top of the list. Now, i will agree that grid can be confusing at first until you understand how to rowconfigure and columnconfigue the containing widget (be it a frame or a toplevel). There is also the sticky attribute to consider. ## END TANGENTIAL MEANDERINGS ## But all in all, i would say the most difficult part of the Tkinter geometry management API is coming to grips as to which of the three geometry managers is the best choice for the particular problem at hand -- and you will find yourself using more than one manager in a single GUI app! But i don't see you solving this problem by stacking one widget on another. I believe it's time to seek out a new solution. EASY: Using rows of Tkinter.Button coupled with a per-formatted text string. ADVANCED: Creating pseudo buttons on a canvas and stacking text objects (or whatever you like) on them. -- http://mail.python.org/mailman/listinfo/python-list
Re: Keeping the Console Open with IDLE
On Thursday, February 19, 2009 10:06:42 PM UTC-6, W. eWatson wrote: I'm using IDLE for editing, but execute programs directly. If there are execution or compile errors, the console closes before I can see what it contains. How do I prevent that? Q: If you are in fact using IDLE to edit your code file, then why not just run the files directly from the IDLE menu (Menu-Run-Run Module)? If you select this command, IDLE will display a shell window containing all the stdout and stderr messages. I think this would be the easiest approach for a neophyte administrator like yourself. See this tutorial for more info: https://hkn.eecs.berkeley.edu/~dyoo/python/idle_intro/index.html There are many methods of executing a python script. Using the IDLE run command is just one of them. Some others include: 1. Double clicking the file icon in a file browser 2. Typing the full path of the script into a windows Command Prompt. Considering i have a script in my C drive named foo.py, i could type the command C:\foo.py to execute the script from a windows command prompt. But my fingers don't need any exercise, so i just double click the icon or use the run command of my IDE. Done deal. -- http://mail.python.org/mailman/listinfo/python-list
Re: How to safely maintain a status file
On Thursday, July 12, 2012 10:13:47 PM UTC-5, Steven D#39;Aprano wrote: Rick has obviously never tried to open a file for reading when somebody else has it opened, also for reading, and discovered that despite Windows being allegedly a multi-user operating system, you can#39;t actually have multiple users read the same files at the same time. You misread my response. My comment was direct result of Christian stating: (paraphrase) On some systems you are not permitted to delete a file whilst the file is open ...which seems to be consistent to me. Why would *anybody* want to delete a file whilst the file is open? Bringing back the car analogy again: Would you consider jumping from a moving vehicle a consistent interaction with the interface of a vehicle? Of course not. The interface for a vehicle is simple and consistent: 1. You enter the vehicle at location A 2. The vehicle transports you to location B 3. You exit the vehicle At no time during the trip would anyone expect you to leap from the vehicle. But when you delete open files, you are essentially leaping from the moving vehicle! This behavior goes against all expectations of consistency in an API -- and against all sanity when riding in a vehicle! Opening files for exclusive read *by default* is a pointless and silly limitation. It#39;s also unsafe: if a process opens a file for exclusive read, and then dies, *no other process* can close that file. Oh come on. Are you actually going to use errors or unintended consequences, or even Acts of God to defend your argument? Okay. Okay. I suppose IF the car spontaneously combusted THEN the passengers would be wise to jump out, leaving the vehicle to the whims of inertia. One neat trick is to open a file, then delete it from disk while it is still open. So long as your process is still running, you can write to this ghost file, as normal, but no other process can (easily) see it. And when your process ends, the file contents is automatically deleted. Well neat tricks aside, I am of the firm belief that deleting files should never be possible whilst they are open. * Opening files requires that data exist on disk * Reading and writing files requires an open file obj * Closing files requires an open file object * And deleting files requires that the file NOT be open Would you also entertain the idea of reading or writing files that do not exist? (not including pseudo file objs like StringIO of course!). Summary: Neat tricks and Easter eggs are real hoot, but consistency in APIs is the key. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why has python3 been created as a seperate language where there is still python2.7 ?
On Monday, June 25, 2012 10:35:14 PM UTC-5, Steven D#39;Aprano wrote: (Rick, don't make me regret communicating with you again.) Well unfortunately Steven i am not sure what causes you to stop communicating with me for these seeming random periods of time -- although i can deduce from past experiences that you have difficulty accepting diverse opinions, then, your emotions take control causing you to wield the only weapon of recourse you have available to you: the kill file -- so in that sense, i cannot provide a solution for a problem that exists beyond my control. HTH. On Mon, 25 Jun 2012 19:28:01 -0700, rantingrickjohnson wrote: There's no real difference between typing print(...) and all the other functions in Python. Do you lament having to type len(obj) instead of len obj or list(zip(a, b, c)) instead of list zip a b c? No. I actually like the forced parenthesis -- even when on a function declaration with no arguments. I think this is a consistent approach. And boy do i love consistency! Making print a statement in the first place was a mistake, but fortunately it was a simple enough mistake to rectify once the need for backward compatibility was relaxed. Agreed. However, my comment was not a rant against the new print function, more that, it is a warning against pushing people to learn Python 2.x FIRST, and therby training them with the bad habit of using a naked print syntax that they will surely lament in the future. For me the print statement is like a big old delicious chocolate chip cookie and the print function is like a plate of leafy vegetables. I know i should eat my vegetables; but that damn cookie is just too tempting! -- http://mail.python.org/mailman/listinfo/python-list
Re: Why has python3 been created as a seperate language where there is still python2.7 ?
On Tuesday, June 26, 2012 1:24:43 AM UTC-5, Stefan Behnel wrote: Maybe we should add a remote error reporting mode to Python that sends all syntax error messages not only to the local screen but also directly to the PSF so that they can fund developers who are able to delete that error message from the interpreter based on real world statistical evidence. That would eventually make the language match the powerset of what all users have in their fingers. A very worthy goal, if you ask me. I'm sure you meant this a joke, however, some feedback like this would be greatly beneficial to the developers and community. It's not something you'd want to send each time an exception is thrown, but a log could be requested for delivery from time to time. I think it would be a great addition to any python editor; especially those geared toward neophytes: like IDLE and such. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why has python3 been created as a seperate language where there is still python2.7 ?
On Tuesday, June 26, 2012 1:34:03 AM UTC-5, Stefan Behnel wrote: First of all, the statement has a rather special syntax that is not obvious and practically non-extensible. It also has hidden semantics that are hard to explain and mixes formatting with output - soft-space, anyone? The function is straight forward, configurable, does one thing, works with help() and doesn't get in the way. And something as rarely[1] used as a print simply doesn't deserve special syntax. Oh, and, yes, you can even pass it into some code as callback, although I rarely had a need for that. Stefan [1] Seriously, it's not very helpful in interactive mode and too simplistic to be used in application code. Even scripts often work better with logging than with prints. Unfortunately, even though print is supposedly only used by the neophytes, the python3.0 stdlib is full of print statements. For instance, out of 3173 files, 986 contained the word print[1]. Heck just in the Lib folder alone (without recusing down sub directories) there are 1352 instances of print in a py file! Naive Nancy Mused: If only neophtes use print, and the Python Lib is full of prints statements, then the python developers must be...OH DEAR GAWD! [1] of course that is when using `filestr.count(print)` -- I assume that the word print is not used excessively in comments or docstrings. Someone else can do a less naive search if they like. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why has python3 been created as a seperate language where there is still python2.7 ?
On Monday, June 25, 2012 5:10:47 AM UTC-5, Michiel Overtoom wrote: It has not. Python2 and Python3 are very similar. It's not like if you learn Python using version 2, you have to relearn the language when you want to switch Python3. The syntax is the same, only 'print' is a function instead of a statement. However, there is something to be said for old habits die hard. I myself lament every time i must type-(, then blah, then-) AGAIN!. My fingers are hardwired for the old print statement. Damned that Guido and his mind games! http://www.youtube.com/watch?v=-Ny42Mdg5qo -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter binding question
On Wednesday, June 20, 2012 12:07:04 PM UTC-5, Frederic Rentsch wrote: [...] Googling I chanced on an excellent introduction Thinking in Tkinter [...] He sets out identifying a common problem with tutorials: The problem is that the authors of the books want to rush into telling me about all of the widgets in the Tkinter toolbox, but never really pause to explain basic concepts. They don't explain how to think in Tkinter. Well. I have not analyzed this tutorial myself but i can tell you one thing for sure; most of the confusion regarding Tkinter comes NOT from improperly written tutorials NO, it is a direct result of the poorly designed Tkinter API itself! = Some of the main problems follow: = *## 1. Failure to constrain event sequences:* Tkinter allows users to bind a virtual cornucopia of possible event sequences. Some say this is a good thing because it allows freedom, i say it is contributing to unreadable and unmaintainable code bases. There are literally thousands of possible combinations a user could bind. Sure, this freedom might make the user feel good, but i can guarantee his code will be a spaghetti mess! It is my firm belief, that only two Key Events and four Mouse Events should be allowed binding. Then, the callback should handle the dirty details -- which could include delegating details to one or many lower worker functions. In the real world you only need six possible events to process user input: * KeyPress(keyName) * KeyRelease(keyName) * MousePress(x, y, bNum) * MouseRelease(x, y, bNum) * MouseMotion(x, y, bNum) * MouseWheel(direction) Checking the state of modifiers like Control, Shift, or Alt should be handled via an event object. Actually, all events should be a subclass of an EventHandler object. *## Explicit parent/child relationships needs to be mandatory:* Tkinter allows users to be lazy and omit the parent of a widget to save a few keystrokes on tiny little throw away scripts. In the real world, and even in small GUI applications, you would never want to do such a thing. I believe this methodology does irreversible damage to a new users brain. He fails to see the app-subwin-widget hierarchy from day one. *## 2. Inconsistencies when constructing widgets:* Most widgets expect a parent argument as the first argument, but not the case for Dialogs and other classes which allow you to pass parent=blah as a kw option. Without a parent, a dialog can not set up a proper transient relationship OR position itself properly over the correct window. Allowing this slothful developer behavior contributes to many frustrating user experiences. *## 3. Inconsistencies between configuring widgets and configuring windows:* Windows don't have a config method for things like: title, size, etc. Instead they have methods like win.title(Title) or win.geometry(wxh+x+y); which again breaks the consistency that is so important in any API! Not to mention the unessesaryily cryptic nature of a few of these methods. *## 4. Failure to remove old tutorials from the web that are still teaching people to code Tkinter GUI's like it's 1991:* This is a sad result of a dead community. And the few people who are remaining have become so partisan that nothing can get accomplish except, well, nothing. Congratulations Guido, are you proud of what you have created? Or rather, or you proud of what this community had degenerated into? (BTW those are rhetorical questions.) I am still hoping beyond hope that some new blood will enter this community soon and inject some hope for the future. Guido is an old man. He has no passion anymore. I long for some new blood with a passion for consistency. People with the intuition required to create intuitive APIs. But most of all. People who have a can do community spirit. A boy can dream. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter binding question
On Tuesday, June 19, 2012 10:55:48 AM UTC-5, Frederic Rentsch wrote:
If I copy your event descriptors into my program, the button-release
callback still fails. It works in your code, not in mine. Here is what
my code now looks like. It is somewhat more complicated than yours,
because I bind Frames holding each a line (line_frame) and each frame
contains a few Labels side by side. The idea is to achieve a table with
vertically aligning columns each line of which I can click-select. (Is
there a better way?)
for line_frame in ...:
line_frame.bind ('Enter', self.color_selected)
line_frame.bind ('Leave', self.color_selectable)
line_frame.bind ('ButtonRelease-1', self.pick_record)
line_frame.bind ('ButtonRelease-3', self.info_profile)
line_frame.grid (row = n+1, column = 0)
for i in self.range_n_fields:
field = Label (line_frame, width = ..., text = ...
field.grid (row = 0, column = i, sticky = W)
...
def color_selected (self, event):
print 'hit list.color_selected ()'
def color_selectable (self, event):
print 'hit list.color_selectable ()'
def pick_record (self, event): # Nver gets called
print 'hit list.pick_record ()'
def info_profile (self, event):# Never gets called
print 'hit list.info_profile ()'
Events only fire for the widget that currently has focus. Frames, labels, and
other widgets do not receive focus simply by hovering over them. You can set
the focus manually by calling w.focus_set() -- where w is any Tkinter
widget. I can't be sure because i don't have enough of your code to analyze,
but I think you should bind (either globally or by class type) all Enter
events to a callback that sets the focus of the current widget under the mouse.
Experiment with this code and see if it is what you need:
## START CODE ##
from __future__ import print_function
import Tkinter as tk
def cb(event):
print(event.widget.winfo_class())
event.widget.focus_set()
root = tk.Tk()
root.geometry('200x200+20+20')
for x in range(10):
w = tk.Frame(root, width=20, height=20,bg='red')
w.grid(row=x, column=0, padx=5, pady=5)
w = tk.Frame(root, width=20, height=20,bg='green', highlightthickness=1)
w.grid(row=x, column=1, padx=5, pady=5)
w = tk.Button(root, text=str(x))
w.grid(row=x, column=2, padx=5, pady=5)
root.bind_all(Enter, cb)
root.mainloop()
## END CODE ##
You will see that the first column of frames are recieving focus but you have
no visual cues of that focus (due to a default setting). In the second column
you get the visual cue since i set highlightthicness=1. The third column is a
button widget which by default has visual focus cues.
Is this the problem?
PS: Also check out the w.bind_class() method.
Incidentally, my source of inspiration for chaining event descriptors
was the New Mexico Tech Tkinter 8.4 reference,
That's an excellent reference BTW. Keep it under your pillow. Effbot also has a
great tutorial.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter binding question
On Monday, June 18, 2012 1:21:02 PM UTC-5, Frederic Rentsch wrote:
Hi All,
For most of an afternoon I've had that stuck-in-a-dead-end feeling
probing to no avail all permutations formulating bindings, trying to
make sense of manuals and tutorials. Here are my bindings:
label_frame.bind ('Enter', self.color_selected)
label_frame.bind ('Leave', self.color_selectable)
label_frame.bind ('Button-1ButtonRelease-1', self.pick_record)
label_frame.bind ('Button-3ButtonRelease-3', self.info_profile)
This example is useless to me. As a matter of fact, your whole explanation of
the problem is ambitious at best. But you do realize that by binding both the
click and release of a mouse button to the same callback you will call the
callback twice?
Try to create a simplistic and generic example of the problem. Most times
you'll find the flaw. Most code should start as template that prints messages
to stdout. Large applications are built by taking babysteps. Not by jumping out
the fire and into the frying pan!
WARNING: Debugging large chucks of spaghetti code is bad for your brain! Tip of
the day: DIVIDE AND CONQUER!
## START CODE ##
from __future__ import print_function
import Tkinter as tk
root = tk.Tk()
root.geometry('200x200+20+20')
root.bind(Enter, lambda e:print(Enter))
root.bind(Leave, lambda e:print(Leave))
root.bind(ButtonRelease-1,
lambda e:print(ButtonOneRelease))
root.bind(ButtonRelease-3,
lambda e:print(ButtonThreeRelease))
root.mainloop()
## END CODE ##
Q1: Now, what exactly is the problem? Hmm???
Q2: Can you modify this code to correct the problem? Hmm???
Q3: Why are there so many inconsistencies in the Tkinter API? Hmm???
Tip: NEVER bind ButtonClick to trigger a callback (ESPECIALLY FOR A BUTTON
CALLBACK!!!). ONLY bind ButtonRelease. Why? Well because if the user
accidentally clicks the button, he can move his pointer beyond the boundaries
of the button and then release the mouse button WITHOUT triggering the
callback. All good GUI coders follow this design pattern. (Except in certain
cases where you want a mouse click to trigger an action quickly; like a Listbox
item or menu, or whatever.)
if GUI.ergonomics optimal:
raise NeophyteError(Do not pass GUI. Do not collect 100 dollars!)
Enter and Leave work fine. But when I try to select an entered item,
the moment I push the left or the right button, color_selectable ()
and color_selected () are called again in rapid succession.
That does not make sense. Are you calling the method w.update() anywhere in
the callback; or as a consequence of the callback?
The same
effect happens even when I push the middle mouse button which is
rather weird, because it has no binding.
Not necessarily. Many of the Tk widgets come prepackaged with annoying little
default bindings that would the test the patience of a saint. Like, for
example, the Tkinter.Text widget. It has a nasty little default binding to
paste the cut buffer contents when you press MouseButtonTwo. And since it also
has a default binding of using MouseButtonTwo+MouseMotion to scroll vertically,
you find yourself inserting cut buffers everywhere!
The behavior suggests that
no event can occur on an entered widget before it is left again and
if an event other that Leave comes in, the Leave callback gets
called automatically. That can't be right, though. It isn't possible
to click an item without entering it.
Interesting observation. I would say your code is too complicated to properly
debug. You need to divide and conquer this spaghetti mess.
--
http://mail.python.org/mailman/listinfo/python-list
Re: lazy evaluation of a variable
On Sunday, June 17, 2012 6:01:03 PM UTC-5, Steven D#39;Aprano wrote: One day, in my Copious Spare Time, I intend to write a proper feature request and/or PEP for such a feature. Obviously the absolute earliest such a feature could be introduced is Python 3.4, about 18 months from now. (Although frankly, I would imagine significant opposition from the more conservative Python developers.) Well these conservatives must have been suffering from chronic mononucleosis because i have never heard a peep from them! I wish they would grow a pair and speak up a bit more often because the language would benefit greatly from some austerity measures, strong leadership, and most of all; some Gawd damned consistency! -- http://mail.python.org/mailman/listinfo/python-list
