Eric V. Smith wrote:
> > Formatter.ALLOW_LEADING_UNDERSCORES
> > Formatter.CHECK_UNUSED_POSITIONAL
> > Formatter.CHECK_UNUSED_NAME
> I'm not sure I'm wild about these flags which would have to be or'd
> together, as opposed to discrete parameters. I realize have a single
> flag field is likely more extensible, but my impression of the
> standard library is a move away from bitfield flags. Perhaps that's
> only in my own mind, though!
>
> Also, why put this in the base class at all? These could all be
> implemented in a derived class (or classes), which would leave the
> base class state-free and therefore without a constructor.
I think the dict/defaultdict cooperative implementation based on the
__missing__ method is a good guide to follow here. Instead of having
flags to the constructor, instead define methods that the base class
invokes to deal with the relevant checks - subclasses can then override
them as they see fit.
A couple of possible method signatures:
def allowed_name(self, name):
"Return True if name is allowed, False otherwise"
# default implementation return False if name starts with '_'
def allow_unused(self, unused_args, unused_kwds):
"Return True if unused args/names are allowed, False otherwise"
# default implementation always returns True
Subclasses can then either return False to get a standard 'disallowed'
exception, or else raise their own exception explicitly.
A few common alternate implementations of the latter method would be:
def allow_unused(self, unused_args, unused_kwds):
# All positional arguments must be used
return not unused_args
def allow_unused(self, unused_args, unused_kwds):
# All keyword arguments must be used
return not unused_kwds
def allow_unused(self, unused_args, unused_kwds):
# All arguments must be used
return not unused_args and not unused_kwds
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
