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".
> on the other hand, it lets you press single keys,
That would be called "typing".
> 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".
> 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.
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."
> 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 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)
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).
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
