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

[Graham Fielding]

(This comes from my experience writing interactive fiction with the TADS workbench; YMMV) As a rule, it's generally unwise to modify built-in variables without thoroughly documenting your changes.  Your modifications might not hold up if the built-in definitions are revised (which would break your program) and you could introduce later version/compatibility issues with other things that use/need the 'standard' definitions. That said, if done cautiously, modifying the built-ins can have a net benefit; just be careful to indicate what you've changed so you can debug it properly, and -- if possible -- distribute yoru modified code along with a copy of the original, so that if issues arise, your users can restore the stable code without digging around in the guts of the software.
> > 
> > [...]
> > 
> > | 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
> > 
> > pythonic reasons.
> > 
> > 
> > 
> > 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:
> > 
> > 
> > 
> >   type(blah)
> > 
> > 
> > 
> > Is it at all possible to make all uses of your "type" function method
> > 
> > calls? Eg:
> > 
> > 
> > 
> >   something.type("text to type")
> > 
> > 
> > 
> > It avoids the overloading while keeping your desired name.
> > 
> > -- 
> > 
> > Cameron Simpson 
> > 
> > 
> > 
> > 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
> 
> -- 
> http://mail.python.org/mailman/listinfo/python-list
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20121124/efe2fd34/attachment.html>