On 03/26/2013 08:04 AM, Michael Herrmann wrote:
On Tuesday, March 26, 2013 11:26:30 AM UTC+1, Dave Angel wrote:
...
Seems to me that the official interface should all be methods. However,
you could have a new object which always represents the "focus" window.
Then the USER could define trivial functions:
def write(*args):
focused.write(*args)
It's an interesting idea. But why not give this write(...) to them in the first
place?
Just to be clear, I was avoiding the problem of having two ways of
accessing each function, since most of us prefer the methods, and you
have some users who prefer simple functions.
Am I the only one who appreciates the simplicity of
start("Notepad")
write("Hello World!")
press(CTRL + 's')
write("test.txt", into="File name")
click("Save")
press(ALT + F4)
over
notepad = start("Notepad")
notepad.write("Hello World!")
notepad.press(CTRL + 's')
notepad.write("test.txt", into="File name")
notepad.click("Save")
notepad.press(ALT + F4)?
Somewhere in this thread you mention that save() creates a new window,
so a method-oriented approach would require that the user get that
window object, and call its methods rather than the original window's.
I say that's a very good thing, since the things you send may very well
have very different meanings to the save dialog than they do in the
original one.
save() is not a function, but I assume you mean the action that opens the
"Save" dialogue (I think that'd be `press(CTRL + 's')`). You are right that
it's nice for it to be explicit. However, in 95% of cases, the window you want the next
action to be performed in is the window that is currently active. I appreciate the
explicitness, but to force it on the user for only 5% of cases seems a bit much.
Another concern I'd have is what happens if the user changes focus with
his mouse? Does that change the meaning you had for focus() in the
above exchange? Do you want your press() method to apply to a different
window when the user changes to that window?
No. Internally, we remember which window is the currently active window. If you
just run a script without user-intervention, this will be the respective
foreground window. If some other window is in the foreground - which most
typically happens when the user is interactively entering commands one after
the other, so the foreground window is the console window, we do switch to the
window that's supposed to be the active one. It may sound like black magic, but
it works very well in practice, and really is not too ambiguous. When you read
a script like
start("Notepad")
write("Hello World")
press(CTRL + 's')
write("test.txt", into="File name")
click("Save")
click("Close")
I hold that you intuitively know what's going on, without even thinking about
window switching.
Until the program you're scripting makes some minor change in its
interface, or has something conditional on an attribute not intuitively
obvious.
Also, it seems that in this thread, we are using "window" both to refer
to a particular application instance (like Notepad1 and Notepad2), and
to refer to windows within a single application.
Anyway, if you're only automating a few specific apps, you're not likely
to run into the problems that methods were intended to address. After
all, Notepad's bugs haven't seemed to change for a couple of decades, so
why should they fix anything now?
Having a selected window be an implied object for those global functions
yields at least the same problems as any writable global.
Multithreading, unexpected side effects from certain functions,
callbacks, etc.
As long as you know the program is going to be simple, pile on the
globals. But as soon as it advances, each of them is a trap to fall into.
--
DaveA
--
http://mail.python.org/mailman/listinfo/python-list
