Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Is it bad style to override the built-in function `type`?

Reply
Thread Tools

Is it bad style to override the built-in function `type`?

 
 
Cameron Simpson
Guest
Posts: n/a
 
      11-24-2012
On 24Nov2012 14:32, Michael Herrmann <(E-Mail Removed)> wrote:
| 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!

+1
--
Cameron Simpson <(E-Mail Removed)>

Cars making a sudden U-turn are the most dangerous. They may cut you off
entirely, blocking the whole roadway and leaving you no place to go.
- MSF Motorcycle Operator Manual, sixth rev. 1991, page 21
 
Reply With Quote
 
 
 
 
Steven D'Aprano
Guest
Posts: n/a
 
      11-25-2012
On Sat, 24 Nov 2012 14:32:19 -0800, Michael Herrmann wrote:

> 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:

[quote]
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.



--
Steven
 
Reply With Quote
 
 
 
 
Cameron Simpson
Guest
Posts: n/a
 
      11-25-2012
On 25Nov2012 04:06, Steven D'Aprano <(E-Mail Removed)> wrote:
| On Sat, 24 Nov 2012 14:32:19 -0800, Michael Herrmann wrote:
| > 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".

Which is actually an argument _for_ his suggestion.

[...]
| 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. [...]
| 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:

Again, an argument _for_ his suggestion.

|
| There is far more opportunity for confusion with the name "write" than
| "type":
[...]
| * but a call to your proposed function "write(string)" does look
| very similar, if not identical, to a typical call to write.

Again, an argument _for_ his suggestion.

Why do I find these reasons to be plusses while you find them minuses?
Because you're conveniently glossing over the fact that almost all
uses of "write" in the library and common code have an object for
context.

And I find his suggestion good because for us old UNIX heads, the way you
present typed text to a terminal is usually to write it to the master
side of a pseudotty, thus:

pty.write("typed text here!")

The usage is _exactly_ analogous to the conventional uses of write(),
because "everything is a file" (one of the UNIX mantras). Writing typed
text is the natural way to express this stuff.

Your argument seems to be that because his write looks and acts like
other write()s it is cause for confusion. My argument is that using the
name "write" is a good thing, _because_ his usage looks and acts like
the other common uses of write.

So I maintain it should cause less confusion.

Cheers,
--
Cameron Simpson <(E-Mail Removed)>

It is a tale told by an idiot, full of sound and fury, signifying nothing.
- William Shakespeare
 
Reply With Quote
 
Ramchandra Apte
Guest
Posts: n/a
 
      11-25-2012
On Friday, 23 November 2012 21:42:39 UTC+5:30, Michael Herrmann wrote:
> Hi,
>
>
>
> do you think it's bad style to override the built-in function `type`? I'm co-developing a GUI automation library called Automa (http://www.getautoma.com) and 'type' would be a very fitting name for a function that generates artificial key strokes.
>
>
>
> This post is motivated by an already lengthy discussion on this mailing list (http://bit.ly/10aOy4H), where we tried to find alternative names for `type`. Many were found, but none are quite as fitting as 'type'.
>
>
>
> For the sake of avoiding a discussion that is already being lead elsewhere please confine this thread to what you generally think about overriding `type`, and post suggestions for alternative names or solutions in the other thread.
>
>
>
> Thank you very much!
>
> Michael


Deleting getattr causes problems with IDLE.
Also, the accepted answer to http://stackoverflow.com/questions/9...-or-method-ide is not correct.
See http://bugs.python.org/issue15113#msg163272 .
 
Reply With Quote
 
Michael Herrmann
Guest
Posts: n/a
 
      11-29-2012
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: http://www.getautoma.com/blog/New-ve...h-improved-API

I will now stop spamming this list. Thank you so much again! If you're interested in how we're getting on in the future, do follow us on Twitter @BugFreeSoftware or on our blog http://www.getautoma.com/blog!

Thanks again,
Michael
Co-founder and lead developer
@BugFreeSoftware
http://www.getautoma.com

On Friday, November 23, 2012 5:12:39 PM UTC+1, Michael Herrmann wrote:
> Hi,
>
>
>
> do you think it's bad style to override the built-in function `type`? I'mco-developing a GUI automation library called Automa (http://www.getautoma..com) and 'type' would be a very fitting name for a function that generatesartificial key strokes.
>
>
>
> This post is motivated by an already lengthy discussion on this mailing list (http://bit.ly/10aOy4H), where we tried to find alternative names for `type`. Many were found, but none are quite as fitting as 'type'.
>
>
>
> For the sake of avoiding a discussion that is already being lead elsewhere please confine this thread to what you generally think about overriding `type`, and post suggestions for alternative names or solutions in the otherthread.
>
>
>
> Thank you very much!
>
> Michael

 
Reply With Quote
 
rusi
Guest
Posts: n/a
 
      11-30-2012
On Nov 23, 9:12*pm, Michael Herrmann <(E-Mail Removed)>
wrote:
> Hi,
>
> do you think it's bad style to override the built-in function `type`? I'mco-developing a GUI automation library called Automa (http://www.getautoma..com) and 'type' would be a very fitting name for a function that generatesartificial key strokes.
>
> This post is motivated by an already lengthy discussion on this mailing list (http://bit.ly/10aOy4H), where we tried to find alternative names for `type`. Many were found, but none are quite as fitting as 'type'.
>
> For the sake of avoiding a discussion that is already being lead elsewhere please confine this thread to what you generally think about overriding `type`, and post suggestions for alternative names or solutions in the otherthread.
>
> Thank you very much!
> Michael


Im entering this thread late (was off mail for a week), so pardon me
if someone has already said this -- but have you looked at the
difference between internal and external dsls:
http://martinfowler.com/bliki/Domain...cLanguage.html (and links
therein) ?

Roughly speaking if what you are making is an external dsl, then its
not really python (it may be python-inspired but thats not really
germane) and so reusing python lexemes/structures etc in ways not
exactly consistent with python usage should be no issue

If its an internal DSL, you are headed for causing/suffering grief.

I looked at your site [yes it looked almost interesting -- if only it
ran on linux ] and I cant really decide whether to classify it as
external or internal
 
Reply With Quote
 
Michael Herrmann
Guest
Posts: n/a
 
      12-03-2012
Hi Rusi,

> Im entering this thread late (was off mail for a week), so pardon me
> if someone has already said this -- but have you looked at the
> difference between internal and external dsls:
> http://martinfowler.com/bliki/Domain...cLanguage.html (and links
> therein) ?
> Roughly speaking if what you are making is an external dsl, then its
> not really python (it may be python-inspired but thats not really
> germane) and so reusing python lexemes/structures etc in ways not
> exactly consistent with python usage should be no issue
>
> If its an internal DSL, you are headed for causing/suffering grief.
>
> I looked at your site [yes it looked almost interesting -- if only it
> ran on linux ] and I cant really decide whether to classify it as
> external or internal


We want to capitalize on all of Python's advantages (tool/IDE support, available libraries etc) and are thus strictly offering an internal DSL (see http://www.getautoma.com/features/python_integration). As you pointed out, that's why it's important to stay consistent with Python's conventions.

I agree it'd be nice to have Automa run on Linux, but unfortunately that's still a long time away...

Best,
Michael
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Bad media, bad files or bad Nero? John Computer Information 23 01-08-2008 09:17 PM
How override ALL function calls? (Is there a "function call function"?) seberino@spawar.navy.mil Python 2 08-01-2005 12:38 PM
ActiveX apologetic Larry Seltzer... "Sun paid for malicious ActiveX code, and Firefox is bad, bad bad baad. please use ActiveX, it's secure and nice!" (ok, the last part is irony on my part) fernando.cassia@gmail.com Java 0 04-16-2005 10:05 PM
24 Season 3 Bad Bad Bad (Spoiler) nospam@nospam.com DVD Video 12 02-23-2005 03:28 AM
24 Season 3 Bad Bad Bad (Spoiler) nospam@nospam.com DVD Video 0 02-19-2005 01:10 AM



Advertisments