(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
--
http://mail.python.org/mailman/listinfo/python-list
