On Oct 25, 9:04 pm, rh0dium <steven.kl...@gmail.com> wrote:
> On Oct 22, 9:05 pm, Carl Banks <pavlovevide...@gmail.com> wrote:
> > This should suffice for you:
>
> > class Borg(object):
> > __shared_state = {}
> > def __init__(self, noSend=False,reportLevel=30,
> > reportMethods="BaseReport",
> > contacts=None):
> > self.__dict__ = self.__shared_state
> > self.noSend = noSend
> > self.reportLevel = reportLevel
> > self.reportMethods = reportMethods
> > self.contacts = contacts
>
> > This (as well as your class) will update the shared state for all Borg
> > objects whenever you instantiate a new Borg object. That might be
> > what you want, but be aware.
>
> Now the real question I have on this is scalability. The real
> advantage to using *args and **kwargs is that down the road (through
> inheritance/polymorphism) I may not know what I'm being given (isn't
> that the essence of duck-typing).
No, duck-typing means you don't necessarily know the types of
arguments you're getting. Not knowing the number, pattern, or usage
of the arguments you're getting is something else.
> My long standing belief is that by
> using *args and **kwargs I plan for future additions with minimal
> changes to my code. So doesn't restricting this just defeat the
> purpose?
If that's your intended purpose down the road, feel free to do it.
(Not sure why you would do that with a singleton, but that's your
business.)
Personally, I wouldn't recommend replacing regular arguments with
*args and **kwargs unless there was a specific reason to believe that
this class would be used in a heirarchy where it's expected to pass on
arguments it doesn't know about. If it just "might someday" be used
that way, I'd say it's a lot of unnecessary caution.
One place I do recommend using *args and **kwargs is with mixin
classes, because mixins usually are required to pass along unknown
arguments, not just "might be someday".
> > The fact is, object.__new__ does nothing at all with the args and
> > kwargs arguments, it just ignores them. So, when calling
> > object.__new__, don't pass them to it.
>
> So what is the point of using __new__?
It's mostly for types written in C, or for subclassing types written
in C. Advanced programmers can take advantage of it to do some
interesting things, but most of the time __init__ suffices.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
