[Python-Dev] Re: Optional arguments for str.encode /.decode
tim.hochberg at ieee.org
Fri Nov 7 11:11:13 EST 2003
Alex Martelli wrote:
> On Friday 07 November 2003 04:14 pm, Barry Warsaw wrote:
>>Actually what I was complaining about probably is too late to "fix". It
> We must keep supporting that approach, yes (alas), but maybe it's
> not too late to encourage another alternative style instead? E.g., have
> some object exposing attributes corresponding to those strings that
> do name codecs, so that while e.g.
> s.encode('zlib', level=9)
> would have to keep working, the officially encouraged style would be:
> s.encode(codec.zlib, level=9)
> or something of that ilk...?
If keyword arg collisions are still a concern, it seem it should be
possible to make the following work without too much trouble::
These codec objects could be simple classes that stash away their args
and kwargs to pass on to the underlying encode::
def __init__(self, *args, **kwargs):
self.name = self.__class__.__name___
self.args = args
self.kargs = kargs
In the encode method, the codec name, args and kargs would be grabbed
from the corresponding attributes of the CodecObj (Unless the object was
a string, in which case the old behaviour would be used).
This would have the added advantage of pushing people to the new syntax.
The downside is that::
wouldn't work. One would probably have to use the more verbose syntax::
>>was the use of a string for the first argument to .encode() and
>>.decode(). I dislike that for the same reason we don't do
>>obj.__dict__['attribute'] on a regular basis. ;)
> So my suggestion would take us back to obj.attribute style (as a
> preferred alternative to using 'attribute' overtly as a dict key)...
> Python-Dev mailing list
> Python-Dev at python.org
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
More information about the Python-Dev