Hey everyone,
this is my final mail. With all your help we have decided on names for our
function. It was a surprisingly difficult process but your inputs helped
tremendously. I have described our experiences (very good ones here, but
somewhat mixed ones with StackOverflow) in a blog entry:
press_keys()
On Tuesday, November 20, 2012 2:18:38 PM UTC+2, 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
On Sunday, November 25, 2012 12:23:13 AM UTC+1, Dennis Lee Bieber wrote:
...
Pardon? In ASCII (and encodings that share the first 128 positions),
a TAB is x09.
def show(c):
... print %r is 0x%2.2X % (c, ord(c))
...
show(raw_input()[0])
i
'i' is 0x69
On Sunday, November 25, 2012 4:56:49 AM UTC+1, Steven D'Aprano wrote:
Michael, please trim your replies. There is no need to quote nearly 200
lines of previous emails that you don't make direct reference to in your
response. We prefer inline quoting here (where you interleave quoted text
Hi Steven,
press('s') is allowed. So is press('S') - it presses shift for you and is thus
equivalent to press(SHIFT + 's'). You can write press('f', 's'). You cannot
write press('fs') because that's what enter(...) is for. If you try - or, as I
would deem more likely, happen do to it by
Thanks for your reply Dennis,
the commands sounding like they should be commands to a user is the whole point
of the exercise: In doing so, we hope to make the API accessible also to users
from a less technical background. You are perfectly right that system events
are being generated and
Hey,
how about 'write' instead of 'enter'?
write(Hello World!)
write(Brick Lane, into=Street)
This avoids the ambiguity of whether 'enter' ends by pressing ENTER or not.
Thanks,
Michael
On Tuesday, November 20, 2012 1:18:38 PM UTC+1, Michael Herrmann wrote:
Hi,
I'm
Dear all,
the emails are getting kind of long so to ask you briefly: What do you think of
splitting `type` into two functions `press` and `enter`? Their use cases are:
press(CTRL + 'a')
press(ENTER)
press(ALT + 'f', 's')
enter(Hello World!)
Hi again,
Steven's points and the feeling for `type` are very good and maybe the
problems I mentioned can be ramified. I therefore opened a new thread to find
out what the general public thinks about overwriting built-in functions such as
`type` here:
On Fri, Nov 23, 2012 at 2:42 PM, Michael Herrmann
michael.herrm...@getautoma.com wrote:
Dear all,
the emails are getting kind of long so to ask you briefly: What do you think
of splitting `type` into two functions `press` and `enter`? Their use cases
are:
press(CTRL + 'a')
Hi,
I see your concern with having two functions that have to be separately
remembered... I personally would also be fine with type(), however some people
are violently against it. I opened a new thread
(https://groups.google.com/forum/?fromgroups=#!topic/comp.lang.python/GjZ2hAS1Wyk)
to ask
On Fri, 23 Nov 2012 05:42:22 -0800, Michael Herrmann wrote:
Dear all,
the emails are getting kind of long so to ask you briefly: What do you
think of splitting `type` into two functions `press` and `enter`?
This invites confusion as to the rules of when you can call `press` and
when you
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
On Fri, Nov 23, 2012 at 5:00 AM, Michael Herrmann
michael.herrm...@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')
Hi,
thanks for your prompt reply; I agree that there is also this ambiguity. This
would go away if we were to use `type` but as I said we don't dare to do that.
That's the problem with short names - they're always ambiguous at least to some
extent.
The only alleviation I can offer for the
On Thu, 22 Nov 2012 10:00:54 -0800, Michael Herrmann wrote:
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:
I don't think it is difficult to name at all.
On the one hand, it allows you to enter plain
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
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
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
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
On Tue, Nov 20, 2012 at 11:18 PM, Michael Herrmann
michael.herrm...@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
You know, you would probably get more responses if you picked a
descriptive subject line that didn't look like spam. I only read your
post because I accidentally clicked on it.
On Tue, 20 Nov 2012 04:18:38 -0800, Michael Herrmann wrote:
I'm developing a GUI Automation library
Hi,
thank you for your replies. So far two people said 'send_keys' and one person
said 'type'.
Steven, thanks for your reply. Sorry if the message title disturbed you. My
personal feelings aren't too strongly against 'type' either, but then I'm
afraid it might bother more experienced Python
P.S.: The website is back online; our hosting provider was having technical
problems...
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
On 11/20/2012 07: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
On 2012-11-20, Dave Angel da...@dejaviewphoto.com wrote:
I also vote for send_keys(), even before I saw Chris' reply.
'type' is too overloaded a word. For example, in Windows, it's
the command to display the contents of a file - it types it to
the screen.
type is a nice verb, but since it's
Thanks again for your further replies. So far, it's 4 votes for 'send_keys' and
1 vote for 'type'.
Regarding 'send_keys': To me personally it makes sense to send keys _to_
something. However, in our API, send_keys would not be called on an object or
with a parameter indicating the target. It
On 2012-11-20 15:18, Michael Herrmann wrote:
Thanks again for your further replies. So far, it's 4 votes for 'send_keys' and
1 vote for 'type'.
Regarding 'send_keys': To me personally it makes sense to send keys _to_
something. However, in our API, send_keys would not be called on an object
In 3d71f175-164e-494c-a521-2eaa5679b...@googlegroups.com Michael Herrmann
michael.herrm...@getautoma.com writes:
What, in your view, would be the most intuitive alternative name?
keyboard_input().
--
John Gordon A is for Amy, who fell down the stairs
gor...@panix.com
On 11/20/2012 11:09 AM, John Gordon wrote:
In 3d71f175-164e-494c-a521-2eaa5679b...@googlegroups.com Michael Herrmann
michael.herrm...@getautoma.com writes:
What, in your view, would be the most intuitive alternative name?
keyboard_input().
Well, since Python already has input() and
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
On 20/11/2012 15:18, Michael Herrmann wrote:
Thanks again for your further replies. So far, it's 4 votes for 'send_keys' and
1 vote for 'type'.
Regarding 'send_keys': To me personally it makes sense to send keys _to_
something. However, in our API, send_keys would not be called on an object
On Tue, 20 Nov 2012 07:18:42 -0800, Michael Herrmann wrote:
Thanks again for your further replies. So far, it's 4 votes for
'send_keys' and 1 vote for 'type'.
Regarding 'send_keys': To me personally it makes sense to send keys _to_
something. However, in our API, send_keys would not be
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
On 20 November 2012 16:19, Dave Angel d...@davea.name wrote:
On 11/20/2012 11:09 AM, John Gordon wrote:
In 3d71f175-164e-494c-a521-2eaa5679b...@googlegroups.com Michael
Herrmann michael.herrm...@getautoma.com writes:
What, in your view, would be the most intuitive alternative name?
On Wed, Nov 21, 2012 at 3:21 AM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
On Tue, 20 Nov 2012 07:18:42 -0800, Michael Herrmann wrote:
Thanks again for your further replies. So far, it's 4 votes for
'send_keys' and 1 vote for 'type'.
Regarding 'send_keys': To me personally
On Tuesday 2012 November 20 08:29, mherrmann...@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() ?
Steven D'Aprano wrote:
On Tue, 20 Nov 2012 07:18:42 -0800, Michael Herrmann wrote:
Thanks again for your further replies. So far, it's 4 votes for
'send_keys' and 1 vote for 'type'.
Regarding 'send_keys': To me personally it makes sense to send keys _to_
something. However, in our
On 11/20/2012 11:29 AM, mherrmann...@gmail.com wrote:
... generate_keystrokes? ...
Not bad. gen_keystrokes, or even keystrokes might also do.
I suggest using a name that is unique enough that you can grep through
piles of code and find where it's used. type fails that test.
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
--
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
On Tue, 20 Nov 2012 21:08:24 +, Prasad, Ramit wrote:
I believe that your initial instinct for the name of this function was
correct. It automates typing, so you should call it type or (for
those paranoid about shadowing the built-in, type_str.
I can too easily see somebody doing from
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'):
On 11/20/12 19:20, Steven D'Aprano wrote:
*Accidental* shadowing of names is a bad thing, because you get
unexpected bugs. *Deliberate* shadowing is not. We're all
consenting adults here, if somebody calls from module import
type, and shadows the builtin type, that's their right to shoot
On 11/20/2012 05:46 PM, Alan Meyer wrote:
On 11/20/2012 11:29 AM, mherrmann...@gmail.com wrote:
... generate_keystrokes? ...
Not bad. gen_keystrokes, or even keystrokes might also do.
I would emphatically vote no for keystrokes. That's a noun, not a
verb. What does it do? Tell you if its
Since the event being generated is commonly called a keystroke, and since
my dictionary defines the noun stroke as being: the act of striking, a
good verb to choose for the action itself would seem to be strike:
strike('a')
--
http://mail.python.org/mailman/listinfo/python-list
On Wed, Nov 21, 2012 at 4:25 PM, rh richard_hubb...@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
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
48 matches
Mail list logo
