10 sec poll - please reply!

[Michael Herrmann]

Hi Steven,

On Friday, November 23, 2012 6:41:35 AM UTC+1, Steven D'Aprano wrote:
> 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 text as in `type("Hello
> 
> > World!")`; 
> 
> 
> 
> That would be called "typing".

I agree that "typing" might be more common in this context. However, you also understand me when I say "enter".

> 
> 
> 
> > on the other hand, it lets you press single keys, 
> 
> 
> 
> That would be called "typing".

Here, I disagree. You "press" enter and you "press" ALT+TAB. You might be able to say "type ENTER" but that is much less common. Google agrees: http://bit.ly/10o8yAQ vs. http://bit.ly/WmVwyU.

> 
> 
> 
> > possibly in combination with control keys as for instance in 
> 
> > `type(CTRL + 'a')`. 
> 
> 
> 
> That would be called "prestidigitation".
> 
> 
> 
> Nah, just kidding. That would also be called "typing".

Here too Google favours "press ctrl+a" over "type ctrl+a".

> 
> 
> 
> 
> 
> 
> 
> > We believe it won't normally be necessary to combine the two.
> 
> 
> 
> I can't imagine why you say that. You even go ahead and give a perfectly 
> 
> fine example of combining a control character with plain text.
> 
> 
> 
> I don't know what operating system you are using, but under Linux, people 
> 
> often use strings of regular characters mixed in with control- or alt-
> 
> characters. E.g. I in the shell, I might type Alt-B Shift-' END Shift-' 
> 
> to jump backwards one word (Alt-B), insert a double quote mark (Shift-'), 
> 
> jump to the end of the line I am editing (END), and insert another double 
> 
> quote mark.

Unfortunately, I didn't explain what I mean by "plain text". Your example could be implemented with the "press" from our proposal, as follows:
	press(ALT + 'B', '"', END, '"')
What I meant when I said that "press" could not be used to enter plain text was that it would not be possible to enter a sequence of multiple normal letters enclosed in single quotes, as in
	press("Hello World")
If in your example you had wanted to add more than just a single character to the beginning or end of the line, this means you would have to write
	press(ALT + 'B')
	enter("beginning of line")
	press(END)
	enter("end of line")
I agree that the following would read better here:
	press(ALT + 'B')
	type("beginning of line")
	press(END)
	type("end of line")
However like Google above, I would disagree with
	type(ALT + 'B')
	type("beginning of line")
	type(END)
	type("end of line")
or even
	type(ALT + 'B' + "beginning of line" + END + "end of line")


> 
> 
> 
> It is a needless restriction to assume that every control character must 
> 
> only be part of a single key press event. I even remember a Mac 
> 
> application back in the early 1990s or late 1980s that used combinations 
> 
> like Ctrl-A Y to perform commands. (Actually, such older Macs didn't have 
> 
> a Control key, they used Command instead, but the principle is the same.)
> 
> 
> 
> 
> 
> > 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.
> 
> 
> 
> In a word processor, I might say
> 
> 
> 
> "Type Ctrl-A Ctrl-X to cut all the text from the document."
> 
> 
> 
> rather than
> 
> 
> 
> "Press Ctrl-A. Now press Ctrl-X."
> 

With the current proposal, it'd be
	press(CTRL + 'A', CTRL + 'X')
Forgetting about `type` vs `press` for a moment, chaining the key combinations like this is OK, isn't it?

> 
> 
> > 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`.
> 
> 
> 
> You need to ask yourself, who is your primary audience for your software?
> 
> 
> 
> Is it ... ?
> 
> 
> 
> a) non-technical people who aren't very familiar with Python, and might 
> 
> not even know that there is a built-in function also called "type", or 
> 
> care if they do know;
> 
> 
> 
> b) Python programmers who have embraced the concept of namespaces and 
> 
> have no fear about x.foo clashing with y.foo;
> 
> 
> 
> c) Python programmers with a superstitious dread of using any name which 
> 
> is not global unique, just in case somebody accidentally shadows one 
> 
> function "foo" with another function "foo".
> 

I agree that this is an important question to ask. however we unfortunately cannot answer it yet. We think our software should be usable by people from all three groups, but which group will use it the most we don't know yet.

> 
> I think it is downright silly to avoid using the descriptive and simple 
> 
> name "type" out of some superstition against re-using names which have 
> 
> been used elsewhere, even in the builtins.
> 
> 
> 
> If it were possible to be confused by the two types, e.g. if they took 
> 
> the same arguments but did radically different things, then I would 
> 
> accept that it was too dangerous/confusing to re-use the name. Reasonable 
> 
> fears about shadowing and confusion are, well, reasonable. But nobody is 
> 
> going to confuse your use of type as a command:
> 
> 
> 
> type(some_string)
> 
> 
> 
> with the built-in use as a function
> 
> 
> 
> if type(something) is list:
> 
>     MyClass = type(x, y, z)

Actually, when I first read your example, I was confused. I guess it's because the two different meanings of `type` were so close together I still had the first in mind when encountering the second. Nevertheless, it did confuse me. 

That's actually a key point: You are not confused or irritated by giving `type` a new meaning, and you have very valid reasons why. However, several people we asked in other places were surprised or irritated. You have very good points, but we won't get a chance to explain them to these other users when they first see our API. As the API designers, we have to try to find a solution that's acceptable for most people, and will therefore not be perfect for everyone. 

> 
> I don't think there is any point in having two functions that do exactly 
> 
> the same thing. Expect your users to develop all sorts of superstitions 
> 
> like "you can only use press() with a single key at a time", and get 
> 
> confused as to when you are supposed to use enter() and when press() (for 
> 
> whatever names you eventually choose).
> 

I agree that it's not good to have two functions do exactly the same thing. However, it also has to be pointed out that it's not good for one function to do too many things. An example like
	type(ALT + 'B' + "beginning of line" + END + "end of line")
imho tries to do too much in one go. With things like this, that you could not forbid with having only one function `type` that does everything, you would soon run into problems like "does it now press ALT all the time, or just for the first 'B'? Then your syntax/API pretty quickly explodes and you end up having to add some form of bracketing, escape sequences etc etc. That's something the splitting should hopefully avoid.

Again, it's a long(ish) mail, and that's because it's very interesting to bounce our ideas off of you. Thank you for giving us a chance to do this!

Michael