Hi,
how about "write" instead of "type"? Just came to me in a flash of
inspiration. I know it's also pretty general but at least it's not a
built-in!
"write" is an extremely common operation with a signature very similar to
that of your function you want. The typical use of your function:
automata.write("Hello world") # or whatever your module is called
looks exactly like writing to the file referred to by the name "automata".
Writing to files is *far* more common than using type. Using the standard
library for a rough-and-ready test:
[steve@ando python3.3]$ grep "[.( ]write(" *.py | wc -l
475
[steve@ando python3.3]$ grep "[.( ]type(" *.py | wc -l
161
If it isn't obvious what I am doing, I am using the Linux "grep" utility
to search the Python 3.3 standard library for calls to functions or
methods called "write" vs "type". There are nearly three times as many
calls to "write".
If I inspect the way that the functions are used, the difference is
clear: write is nearly always used as a procedure, while type is used as
a function. Here are a couple of typical examples:
copy.py: return type(x)(x.__func__, deepcopy(x.__self__, memo))
datetime.py: if type(other) != timezone:
Your "simulate typing" function does not look like this. It doesn't
return anything. It usually gets used as a procedure, not a function,
just like the write method:
base64.py: output.write(line)
formatter.py: write(word)
There is far more opportunity for confusion with the name "write" than
"type":
* writing to files is much more common than calling type, even in
expert-level code;
* beginners are even less likely to be using builtin type;
* a call to your proposed function "type(string)" does not look
like a typical call to the builtin type function;
* but a call to your proposed function "write(string)" does look
very similar, if not identical, to a typical call to write.
This is why I maintain that fear of shadowing builtins often becomes
superstition, not reasonable, reasoned advice. For fear of one (unlikely)
source of confusion, you are prepared to accept a (more likely) source of
greater confusion.
Writing to files is a very common thing to do. Calling type() is not. Way
back in the early days of Python, it was common to use code like:
if type(obj) is type([]): ...
but that is usually wrong (it rejects subclasses) and inelegant. Normally
people will use:
if isinstance(obj, list): ...
or better still, avoid type-testing altogether. One thing that *doesn't*
get done is call builtin type on a literal string, then ignore the result:
type("Hello world!")
What would be the point? That would be better written:
str
or even better still, not written at all, since it does nothing sensible.
But calling file method "write" with a string, or a string literal, is
extremely common, and sensible. Your proposed "write" will look just like
writing to a file, when it does something completely different. A couple
of days ago I said:
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.
[end quote]
Your proposal to use "write" is exactly the sort of reasonable confusion
that I was talking about.
