Is it bad style to override the built-in function `type`?
cs at zip.com.au
Fri Nov 23 23:30:11 CET 2012
On 23Nov2012 10:41, Michael Herrmann <michael.herrmann at getautoma.com> wrote:
| I know it's a common beginner's mistake to incautiously override
| built-in functions. However, we put in a lot of research and have come to
| the conclusion that, if Python had not already defined it, `type` would
| be the best name. We are now trying to evaluate how bad the disadvantages
| you mention are in comparison to the advantage to having a name that is
| more intuitive to use in the problem domain.
| Can you somehow relate to my explanations, or are your experiences
| with overwriting built-in variables so bad that you would advise to
| never ever do it?
My own experience says that it is a thing best avoiding without a truly
amazing reason not to.
I urge you not to: type(foo) is a very basic Python idiom and you're
breaking it. One day it _will_ bite you or your users. You will
understand, but I would give goods odds that some of your users will not
the day they go to examine the type of an object for perfectly normal
Example: I have a module that stores "objects" and they have as a
primary key a "name" and a "type" - not Python types, just strings.
Accordingly I have a similar situation to yours: the desire to use the
word "type". Fortunately for me, as an attribute in (usually small) code
chunks I can usually go:
t = foo.type
... work with t here ...
Where I must pass one as a parameter I use the common convention of
naming the parameter "type_" at the receiving end.
For the calling end, as in your case, you want to use:
Is it at all possible to make all uses of your "type" function method
something.type("text to type")
It avoids the overloading while keeping your desired name.
Cameron Simpson <cs at zip.com.au>
Wouldn't it be great if all emergency stopping situations occurred on your
favourite bit of road......you'd probably know about it before it happened
and would be able to take other evasive action.
- Neville Brabet <idiot at melbourne.DIALix.oz.au>
More information about the Python-list