[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