[Python-Dev] Re: Optional arguments for str.encode /.decode
Tim Hochberg
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...?
<unlurk>
FWIW,
If keyword arg collisions are still a concern, it seem it should be
possible to make the following work without too much trouble::
s.encode(codec.zlib(level=9))
These codec objects could be simple classes that stash away their args
and kwargs to pass on to the underlying encode::
class CodecObj:
def __init__(self, *args, **kwargs):
self.name = self.__class__.__name___
self.args = args
self.kargs = kargs
class zlib(CodecObj):
pass
# ....
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::
s.encode(codec.zlib)
wouldn't work. One would probably have to use the more verbose syntax::
s.encode(codec.zlib())
-tim
</unlurk>
>>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)...
>
>
> Alex
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
>
More information about the Python-Dev
mailing list