Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #33600 > unrolled thread

10 sec poll - please reply!

Back to article view | Back to comp.lang.python

Contents

  10 sec poll - please reply! Michael Herrmann <michael.herrmann@getautoma.com> - 2012-11-20 04:18 -0800
    Re: 10 sec poll - please reply! Chris Angelico <rosuav@gmail.com> - 2012-11-20 23:23 +1100
    Re: 10 sec poll - please reply! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-11-20 13:09 +0000
    Re: 10 sec poll - please reply! Michael Herrmann <michael.herrmann@getautoma.com> - 2012-11-20 05:17 -0800
    Re: 10 sec poll - please reply! Michael Herrmann <michael.herrmann@getautoma.com> - 2012-11-20 05:20 -0800
    Re: 10 sec poll - please reply! Dave Angel <davea@dejaviewphoto.com> - 2012-11-20 08:39 -0500
      Re: 10 sec poll - please reply! Neil Cerutti <neilc@norwich.edu> - 2012-11-20 14:39 +0000
    Re: 10 sec poll - please reply! Michael Herrmann <michael.herrmann@getautoma.com> - 2012-11-20 07:18 -0800
      Re: 10 sec poll - please reply! MRAB <python@mrabarnett.plus.com> - 2012-11-20 15:59 +0000
      Re: 10 sec poll - please reply! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-11-20 16:21 +0000
        Re: 10 sec poll - please reply! Chris Angelico <rosuav@gmail.com> - 2012-11-21 07:57 +1100
        RE: 10 sec poll - please reply! "Prasad, Ramit" <ramit.prasad@jpmorgan.com> - 2012-11-20 21:08 +0000
          Re: 10 sec poll - please reply! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-11-21 01:20 +0000
            Re: 10 sec poll - please reply! Tim Chase <python.list@tim.thechases.com> - 2012-11-20 19:39 -0600
      Re: 10 sec poll - please reply! Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-11-20 16:31 +0000
      Re: 10 sec poll - please reply! Alan Meyer <ameyer2@yahoo.com> - 2012-11-20 18:46 -0500
        Re: Re: 10 sec poll - please reply! Evan Driscoll <driscoll@cs.wisc.edu> - 2012-11-20 19:51 -0600
      Re: 10 sec poll - please reply! Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-11-20 19:01 -0500
      Re: 10 sec poll - please reply! Alan Bawden <alan@scooby-doo.csail.mit.edu> - 2012-11-20 21:15 -0500
    Re: 10 sec poll - please reply! John Gordon <gordon@panix.com> - 2012-11-20 16:09 +0000
      Re: 10 sec poll - please reply! Dave Angel <d@davea.name> - 2012-11-20 11:19 -0500
    Re: 10 sec poll - please reply! emile <emile@fenx.com> - 2012-11-20 08:21 -0800
      Re: 10 sec poll - please reply! mherrmann.at@gmail.com - 2012-11-20 08:29 -0800
        How to use the python to do the unit test "yujian4newsgroup@gmail.com" <yujian4newsgroup@gmail.com> - 2012-11-21 01:40 +0800
        Re: How to use the python to do the unit test emile <emile@fenx.com> - 2012-11-20 09:51 -0800
        Re: 10 sec poll - please reply! xDog Walker <thudfoo@gmail.com> - 2012-11-20 13:33 -0800
        Re: How to use the python to do the unit test Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-11-20 22:02 +0000
      Re: 10 sec poll - please reply! mherrmann.at@gmail.com - 2012-11-20 08:29 -0800
    Re: 10 sec poll - please reply! Tim Chase <python.list@tim.thechases.com> - 2012-11-20 18:00 -0600
      Re: 10 sec poll - please reply! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-11-21 01:17 +0000
        Re: 10 sec poll - please reply! Tim Chase <python.list@tim.thechases.com> - 2012-11-20 19:30 -0600
        Re: 10 sec poll - please reply! Hans Mulder <hansmu@xs4all.nl> - 2012-11-21 13:33 +0100
    Re: 10 sec poll - please reply! rh <richard_hubbe11@lavabit.com> - 2012-11-20 21:25 -0800
    Re: 10 sec poll - please reply! Chris Angelico <rosuav@gmail.com> - 2012-11-21 17:35 +1100
      Re: 10 sec poll - please reply! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-11-21 07:01 +0000
        Re: 10 sec poll - please reply! Andrew Cooper <andrew@nospam.example.com> - 2012-11-21 22:24 +0000
    Re: 10 sec poll - please reply! markus.moldaschl@gmail.com - 2012-11-21 01:29 -0800
    Re: 10 sec poll - please reply! Michael Herrmann <michael.herrmann@getautoma.com> - 2012-11-21 09:19 -0800
    Re: 10 sec poll - please reply! Michael Herrmann <michael.herrmann@getautoma.com> - 2012-11-22 10:00 -0800
      Re: 10 sec poll - please reply! Chris Angelico <rosuav@gmail.com> - 2012-11-23 06:08 +1100
        Re: 10 sec poll - please reply! Michael Herrmann <michael.herrmann@getautoma.com> - 2012-11-22 13:45 -0800
        Re: 10 sec poll - please reply! Michael Herrmann <michael.herrmann@getautoma.com> - 2012-11-22 13:45 -0800
      Re: 10 sec poll - please reply! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-11-23 05:41 +0000
        Re: 10 sec poll - please reply! Michael Herrmann <michael.herrmann@getautoma.com> - 2012-11-23 01:08 -0800
          Re: 10 sec poll - please reply! Michael Herrmann <michael.herrmann@getautoma.com> - 2012-11-23 08:15 -0800
      Re: 10 sec poll - please reply! Michael Herrmann <michael.herrmann@getautoma.com> - 2012-11-23 05:42 -0800
        Re: 10 sec poll - please reply! Kwpolska <kwpolska@gmail.com> - 2012-11-23 17:42 +0100
          Re: 10 sec poll - please reply! Michael Herrmann <michael.herrmann@getautoma.com> - 2012-11-23 09:29 -0800
          Re: 10 sec poll - please reply! Michael Herrmann <michael.herrmann@getautoma.com> - 2012-11-23 09:29 -0800
        Re: 10 sec poll - please reply! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-11-23 22:30 +0000
          Re: 10 sec poll - please reply! Michael Herrmann <michael.herrmann@getautoma.com> - 2012-11-24 12:56 -0800
            Re: 10 sec poll - please reply! Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-11-24 18:22 -0500
              Re: 10 sec poll - please reply! Michael Herrmann <michael.herrmann@getautoma.com> - 2012-11-25 05:41 -0800
      Re: 10 sec poll - please reply! Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-11-23 17:10 -0500
        Re: 10 sec poll - please reply! Michael Herrmann <michael.herrmann@getautoma.com> - 2012-11-24 13:07 -0800
          Re: 10 sec poll - please reply! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-11-25 03:56 +0000
            Re: 10 sec poll - please reply! Michael Herrmann <michael.herrmann@getautoma.com> - 2012-11-25 05:45 -0800
        Re: 10 sec poll - please reply! Michael Herrmann <michael.herrmann@getautoma.com> - 2012-11-24 13:07 -0800
    Re: 10 sec poll - please reply! Michael Herrmann <michael.herrmann@getautoma.com> - 2012-11-24 13:59 -0800
    Re: 10 sec poll - please reply! ALeX inSide <alex.b.inside@gmail.com> - 2012-11-25 04:13 -0800
    Re: 10 sec poll - please reply! Michael Herrmann <michael.herrmann@getautoma.com> - 2012-11-29 03:45 -0800

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#33631

On 11/20/2012 11:09 AM, John Gordon wrote:
> In <3d71f175-164e-494c-a521-2eaa5679b524@googlegroups.com> Michael Herrmann <michael.herrmann@getautoma.com> writes:
>
>> What, in your view, would be the most intuitive alternative name?
> keyboard_input().
>

Well, since Python already has input() and raw_input(), it would then be
clear that keyboard_input() would take some kind of data from the
keyboard, not send it.



-- 

DaveA

[toc] | [prev] | [next] | [standalone]

#33633

On 11/20/2012 04:18 AM, Michael Herrmann wrote:
> Hi,
>
> I'm developing a GUI Automation library (http://www.getautoma.com) and am having difficulty picking a name for the function that simulates key strokes. I currently have it as 'type' but that clashes with the built-in function. Example uses of 'type':
>
> type(ENTER)
>
> type("Hello World!")
>
> type(CTRL + 'a')
>
> What, in your view, would be the most intuitive alternative name?
>
> Here are my thoughts so far: I could call it 'press'

I have several tools that distinguish between press and release for 
this.  You may want to consider having both.

Emile

[toc] | [prev] | [next] | [standalone]

#33634

That's a very good suggestion Emile!! So I might eventually need both 'press' and 'release' (or press_key/release_key). Thanks for this!

To everyone else who has been so kind to reply thus far: What do you think of generate_keystrokes? It's a bit long but describes exactly what the function would be doing. 

All of you are a great help and I really appreciate it. Thank you!

Michael

On Tuesday, 20 November 2012 17:21:38 UTC+1, emile  wrote:
> On 11/20/2012 04:18 AM, Michael Herrmann wrote:
> 
> > Hi,
> 
> >
> 
> > I'm developing a GUI Automation library (http://www.getautoma.com) and am having difficulty picking a name for the function that simulates key strokes. I currently have it as 'type' but that clashes with the built-in function. Example uses of 'type':
> 
> >
> 
> > type(ENTER)
> 
> >
> 
> > type("Hello World!")
> 
> >
> 
> > type(CTRL + 'a')
> 
> >
> 
> > What, in your view, would be the most intuitive alternative name?
> 
> >
> 
> > Here are my thoughts so far: I could call it 'press'
> 
> 
> 
> I have several tools that distinguish between press and release for 
> 
> this.  You may want to consider having both.
> 
> 
> 
> Emile

[toc] | [prev] | [next] | [standalone]

#33639 — How to use the python to do the unit test

I write a mfc application, then I want to use the python to test this application. just as user  click that button.  Please tell me how to write the python application?

[toc] | [prev] | [next] | [standalone]

#33641 — Re: How to use the python to do the unit test

On 11/20/2012 09:40 AM, yujian4newsgroup@gmail.com wrote:
> I write a mfc application, then I want to use the python to test this application. just as user  click that button.  Please tell me how to write the python application?

I currently use MacroScheduler (http://www.mjtnet.com/) then write 
macros from within python and run them using the commands module to  test.

Emile

[toc] | [prev] | [next] | [standalone]

#33664

On Tuesday 2012 November 20 08:29, mherrmann.at@gmail.com wrote:
> To everyone else who has been so kind to reply thus far: What do you think
> of generate_keystrokes? It's a bit long but describes exactly what the
> function would be doing.

If not already offered and rejected,
how about enter() ?

-- 
Yonder nor sorghum stenches shut ladle gulls stopper torque wet 
strainers.

[toc] | [prev] | [next] | [standalone]

#33672 — Re: How to use the python to do the unit test

On 20/11/2012 17:40, yujian4newsgroup@gmail.com wrote:
> I write a mfc application, then I want to use the python to test this application. just as user  click that button.  Please tell me how to write the python application?
>

Easy, open your favourite editor and start typing, what's the problem?

-- 
Cheers.

Mark Lawrence.

[toc] | [prev] | [next] | [standalone]

#33636

That's a very good suggestion Emile!! So I might eventually need both 'press' and 'release' (or press_key/release_key). Thanks for this!

To everyone else who has been so kind to reply thus far: What do you think of generate_keystrokes? It's a bit long but describes exactly what the function would be doing. 

All of you are a great help and I really appreciate it. Thank you!

Michael

On Tuesday, 20 November 2012 17:21:38 UTC+1, emile  wrote:
> On 11/20/2012 04:18 AM, Michael Herrmann wrote:
> 
> > Hi,
> 
> >
> 
> > I'm developing a GUI Automation library (http://www.getautoma.com) and am having difficulty picking a name for the function that simulates key strokes. I currently have it as 'type' but that clashes with the built-in function. Example uses of 'type':
> 
> >
> 
> > type(ENTER)
> 
> >
> 
> > type("Hello World!")
> 
> >
> 
> > type(CTRL + 'a')
> 
> >
> 
> > What, in your view, would be the most intuitive alternative name?
> 
> >
> 
> > Here are my thoughts so far: I could call it 'press'
> 
> 
> 
> I have several tools that distinguish between press and release for 
> 
> this.  You may want to consider having both.
> 
> 
> 
> Emile

[toc] | [prev] | [next] | [standalone]

#33685

On 11/20/12 06:18, Michael Herrmann wrote:
> am having difficulty picking a name for the function that
> simulates key strokes. I currently have it as 'type' but that
> clashes with the built-in function.

Just to add one more to the pot, Vim uses "feedkeys()" for a similar
purpose.

-tkc

[toc] | [prev] | [next] | [standalone]

#33688

On Tue, 20 Nov 2012 18:00:59 -0600, Tim Chase wrote:

> On 11/20/12 06:18, Michael Herrmann wrote:
>> am having difficulty picking a name for the function that simulates key
>> strokes. I currently have it as 'type' but that clashes with the
>> built-in function.
> 
> Just to add one more to the pot, Vim uses "feedkeys()" for a similar
> purpose.

What does it feed to the keys?

Hypercard and other XTalk languages use "type" to simulate typing.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#33691

On 11/20/12 19:17, Steven D'Aprano wrote:
> On Tue, 20 Nov 2012 18:00:59 -0600, Tim Chase wrote:
>> Just to add one more to the pot, Vim uses "feedkeys()" for a similar
>> purpose.
> 
> What does it feed to the keys?

In Vim's case, the signature would be something like

  def feedkeys(str, mode='m'):
    ...

where the 'mode' parameter specifies whether keystrokes should be
passed through the key-remapping functionality, and whether they
should be treated as typed or as a mapping-unit (which affects undo
behavior, whether each key is undoable, or if it's undone as a chunk)

Vim has the advantage that feedkeys() only has to deal with the keys
that Vim sees, which doesn't distinguish keydown/keyup events, or
the presses of modifier keys.

> Hypercard and other XTalk languages use "type" to simulate typing.

However, I suspect that they don't _also_ have a type() function to
dynamically determine the class of an object (or, if they do, it's
called something other than type() :-)

-tkc

[toc] | [prev] | [next] | [standalone]

#33728

On 21/11/12 02:17:26, Steven D'Aprano wrote:
> On Tue, 20 Nov 2012 18:00:59 -0600, Tim Chase wrote:
> 
>> On 11/20/12 06:18, Michael Herrmann wrote:
>>> am having difficulty picking a name for the function that simulates key
>>> strokes. I currently have it as 'type' but that clashes with the
>>> built-in function.
>>
>> Just to add one more to the pot, Vim uses "feedkeys()" for a similar
>> purpose.
> 
> What does it feed to the keys?

Spam, spam, spam, eggs, and spam.

-- HansM

[toc] | [prev] | [next] | [standalone]

#33704

On Tue, 20 Nov 2012 04:18:38 -0800 (PST)
Michael Herrmann <michael.herrmann@getautoma.com> wrote:

> Hi, 
> 
> I'm developing a GUI Automation library (http://www.getautoma.com)
> and am having difficulty picking a name for the function that
> simulates key strokes. I currently have it as 'type' but that clashes
> with the built-in function. Example uses of 'type': 
> 
> type(ENTER)
> 
> type("Hello World!")
> 
> type(CTRL + 'a')
> 
> What, in your view, would be the most intuitive alternative name?

keybot()
or 
kbbot()

To counter your question.  10 sec. poll for the name for the law that
states that people will discuss/argue the most over those things 
having little or no significance.

> 
> Here are my thoughts so far: I could call it 'press' but then our GUI
> automation tool also allows you to click things and then "press"
> might be mistaken for "pressing a button". A less ambiguous
> alternative is "type_keys" but that is rather long and doesn't read
> as well, for instance in type_keys(ENTER).
> 
> Thank you very much!


-- 

[toc] | [prev] | [next] | [standalone]

#33705

On Wed, Nov 21, 2012 at 4:25 PM, rh <richard_hubbe11@lavabit.com> wrote:
> To counter your question.  10 sec. poll for the name for the law that
> states that people will discuss/argue the most over those things
> having little or no significance.

You mean bikeshedding? Parkinson's Law of something-or-other... not
the Law of Inverse Relevance, though the two do discuss the same sorts
of things.

And yet, trivial though it may seem, function naming in a permanent
API is pretty important. Threads like this can be the difference
between coherent and useful APIs and veritable piles of excrement.

ChrisA

[toc] | [prev] | [next] | [standalone]

#33706

On Wed, 21 Nov 2012 17:35:27 +1100, Chris Angelico wrote:

> And yet, trivial though it may seem, function naming in a permanent API
> is pretty important. Threads like this can be the difference between
> coherent and useful APIs and veritable piles of excrement.


"There are only two hard problems in Computer Science: cache invalidation 
and naming things." -- Phil Karlton



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#33775

On 21/11/2012 07:01, Steven D'Aprano wrote:
> On Wed, 21 Nov 2012 17:35:27 +1100, Chris Angelico wrote:
> 
>> And yet, trivial though it may seem, function naming in a permanent API
>> is pretty important. Threads like this can be the difference between
>> coherent and useful APIs and veritable piles of excrement.
> 
> 
> "There are only two hard problems in Computer Science: cache invalidation 
> and naming things." -- Phil Karlton
> 

"counting" is missing from that list of two hard problems.

~Andrew

[toc] | [prev] | [next] | [standalone]

#33711

Am Dienstag, 20. November 2012 13:18:38 UTC+1 schrieb Michael Herrmann:
> Hi, 
> 
> 
> 
> I'm developing a GUI Automation library (http://www.getautoma.com) and am having difficulty picking a name for the function that simulates key strokes. I currently have it as 'type' but that clashes with the built-in function. Example uses of 'type': 
> 
> 
> 
> type(ENTER)
> 
> 
> 
> type("Hello World!")
> 
> 
> 
> type(CTRL + 'a')
> 
> 
> 
> What, in your view, would be the most intuitive alternative name?
> 
> 
> 
> Here are my thoughts so far: I could call it 'press' but then our GUI automation tool also allows you to click things and then "press" might be mistaken for "pressing a button". A less ambiguous alternative is "type_keys" but that is rather long and doesn't read as well, for instance in type_keys(ENTER).
> 
> 
> 
> Thank you very much!

I would expect 'type' or 'press'. 'type' is maybe not the best solution because of overloading. I like 'press'.

Good luck, Mr. Michael ;-)

[toc] | [prev] | [next] | [standalone]

#33752

Dear all,

thanks so much for your replies. Based on your inputs, we have started to experiment with changes to our API. I hope to be able to present the results to you tomorrow.

Thanks again,
Michael

On Tuesday, November 20, 2012 1:18:38 PM UTC+1, Michael Herrmann wrote:
> Hi, 
> 
> 
> 
> I'm developing a GUI Automation library (http://www.getautoma.com) and am having difficulty picking a name for the function that simulates key strokes. I currently have it as 'type' but that clashes with the built-in function. Example uses of 'type': 
> 
> 
> 
> type(ENTER)
> 
> 
> 
> type("Hello World!")
> 
> 
> 
> type(CTRL + 'a')
> 
> 
> 
> What, in your view, would be the most intuitive alternative name?
> 
> 
> 
> Here are my thoughts so far: I could call it 'press' but then our GUI automation tool also allows you to click things and then "press" might be mistaken for "pressing a button". A less ambiguous alternative is "type_keys" but that is rather long and doesn't read as well, for instance in type_keys(ENTER).
> 
> 
> 
> Thank you very much!

[toc] | [prev] | [next] | [standalone]

#33810

Dear all,

thank you for your replies. After experimenting with your suggestions, we have arrived at a solution that we believe fits well with our existing API. However, before we implement this solution, we would like to ask you one last time to sign off on our proposal or raise any serious problems you see with it.

We took the fact that naming our one function 'type' was so difficult to name as an indicator that it may be trying to do too many things: On the one hand, it allows you to enter plain text as in `type("Hello World!")`; on the other hand, it lets you press single keys, possibly in combination with control keys as for instance in `type(CTRL + 'a')`. We believe it won't normally be necessary to combine the two. For instance, while you could see what
	type(CTRL + 'a' + "Hello World!")
does, we think you would be more likely to use the two separate calls
	type(CTRL + 'a')
	type("Hello World!")

One of the main goals of our automation product is that using it should feel like giving instructions to a human being looking over their shoulder at a screen. For this reason, it's very useful for us if the function names in our API are short, if possible without underscores, and close to the vocabulary you would use in an everyday conversation. We hope that by offering an API with this property, we can not only make it easier to use for experienced programmers such as yourself, but also be approachable for people from a less technical background.

In our gut feeling, the words apart from `type` that would most normally be used in an everyday conversation to express the three examples I have given in my first mail are:
	press(CTRL + 'a')
	enter("Hello World")
	press(ENTER)

We really quite like the word `type`, and a few people here seem to favour it too. In particular, Steven: We're glad you accidentally clicked on our mail. Thank you for your inputs and the great quote by Phil Karlton. We think you were right in everything you said. However, some people seem to be *really* put off when you override a built-in function. Even though of course you can avoid the overriding by saying
	from automa.api import type *as* ...,
(as Tim pointed out) we'd like to avoid irritating those people. For this reason, we would rather not use `type`.

Many people here voted for send_keys(...). We agree with Dave and Neil that `type` may have too many uses already. As Chris and MRAB pointed out, 'send_keys' is used in many other automation tools. This makes it intuitive for people with knowledge of such tools. However, as I said above (and should have probably said earlier), we are also trying to reach users from a less technical background. Since these people would not normally use 'send_keys' in an everyday conversion, we are afraid that it would not be an intuitive name for them. A similar argument applies to some extent to our 'type_keys', to our 'generate_keystrokes', Ramit's 'simulate_keypress', 'simulate_key(s)_down', 'send_kb_press', 'fake_typing' and 'send_char(s)' and Tim's 'feedkeys'. We thank you for your suggestions. Hopefully you can also agree with our choice!

Some suggestions were very nice, short and pretty unambiguous, such as Dennis' `emit` and particularly Alan's `strike`. However, they're unfortunately also rather rarely used and we'd be afraid that it'd be hard to remember them. Thank you though!

A final point that Evan made and that also we find very important is to have verbs in our function names. 

Our proposed solution is to split what we previously called `type` into two functions, 'press' and 'enter' (proposed by xDog Walker). 'press' could be used to press single keys or combinations of them, at once:
	press(CTRL + 'a')
	press(ENTER)
To open a menu via the keyboard, you could also supply several key combinations to be pressed, in sequence:
	press(ALT + 'f', 's')
'enter' on the other hand would be used to enter longer strings of plain text:
	enter("Hello World!")
With a functionality we already have, you could supply an optional 'into' parameter that selects a text field into which the text is entered:
	enter("test.txt", into="File name")
'enter' currently does involve generating same system events that are fired when pressing (and releasing) sequences of keys. However, we did not want to include this technical detail in the function name - it keeps the name shorter, makes it more intuitive for users from a less technical background and also leaves us to change this implementation detail in the future.

These names aren't perfect. As Emile rightly pointed out, several tools distinguish between 'press' and 'release' and a user might wonder how to release a key that was pressed using 'press'. That's an ambiguity that is certainly there, however we hope that once the user has at least seen
	press(ENTER)
it is clear what is meant. Distinguishing between pressing and releasing could we think easily be done with, say
	hold_down(SHIFT)
	...
	release(SHIFT)
Another ambiguity of 'press' that I pointed out in my original mail is that it could also be understood as "pressing a button". The current idea is to raise a ValueError if the user supplies a string that is longer than one character:
	>>> press("OK")
	ValueError: 'press' generates keystrokes and can only press single letters at a time. Did you maybe mean click("OK") or press('O', 'K')?

What do you think of this solution? I hope anybody read this far. I probably shouldn't have written that much but wanted to do justice to your inputs.

Thanks!

Michael

On Tuesday, November 20, 2012 1:18:38 PM UTC+1, Michael Herrmann wrote:
> Hi, 
> 
> 
> 
> I'm developing a GUI Automation library (http://www.getautoma.com) and am having difficulty picking a name for the function that simulates key strokes. I currently have it as 'type' but that clashes with the built-in function. Example uses of 'type': 
> 
> 
> 
> type(ENTER)
> 
> 
> 
> type("Hello World!")
> 
> 
> 
> type(CTRL + 'a')
> 
> 
> 
> What, in your view, would be the most intuitive alternative name?
> 
> 
> 
> Here are my thoughts so far: I could call it 'press' but then our GUI automation tool also allows you to click things and then "press" might be mistaken for "pressing a button". A less ambiguous alternative is "type_keys" but that is rather long and doesn't read as well, for instance in type_keys(ENTER).
> 
> 
> 
> Thank you very much!

[toc] | [prev] | [next] | [standalone]

#33815

On Fri, Nov 23, 2012 at 5:00 AM, Michael Herrmann
<michael.herrmann@getautoma.com> wrote:
> In our gut feeling, the words apart from `type` that would most normally be used in an everyday conversation to express the three examples I have given in my first mail are:
>         press(CTRL + 'a')
>         enter("Hello World")
>         press(ENTER)

Looks fairly good, except for one possible problem: The verb "enter"
often means "type this, and then press the Enter key". (For instance,
"open up a terminal/shell and enter this command".) Is that likely to
be a point of confusion?

It's plenty plausible either way. I like the multiple-keystrokes version:
>         press(ALT + 'f', 's')
and the split API does make good sense.

ChrisA

[toc] | [prev] | [next] | [standalone]

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

Back to top | Article view | comp.lang.python

csiph-web