[Python-Dev] Codecs and StreamCodecs

Guido van Rossum guido@CNRI.Reston.VA.US
Wed, 17 Nov 1999 08:43:44 -0500


> Why a factory? I've got a simple encode() function. I don't need a
> factory. "flexibility" at the cost of complexity (IMO).

Unless there are certain cases where factories are useful.  But let's
read on...

> > 	action - a string stating the supported action:
> > 			'encode'
> > 			'decode'
> > 			'stream write'
> > 			'stream read'
> 
> This action thing is subject to error. *if* you're wanting to go this
> route, then have:
> 
> unicodec.register_encode(...)
> unicodec.register_decode(...)
> unicodec.register_stream_write(...)
> unicodec.register_stream_read(...)
> 
> They are equivalent. Guido has also told me in the past that he dislikes
> parameters that alter semantics -- preferring different functions instead.

Yes, indeed!  (But weren't we going to do away with the whole registry
idea in favor of an encodings package?)

> Not that I'm advocating it, but register() could also take a single
> parameter: if a class, then instantiate it and call methods for each
> action; if an instance, then just call methods for each action.

Nah, that's bad -- a class is just a factory, and once you are
allowing classes it's really good to also allowing factory functions.

> [ and the third/original variety: a function object as the first param is
>   the actual hook, and params 2 thru 4 (each are optional, or just the
>   stream funcs?) are the other hook functions ]

Fine too.  They should all be optional.

> > obj = factory_function_for_<action>(errors='strict')
> 
> Where does this "errors" value come from? How does a user alter that
> value? Without an ability to change this, I see no reason for a factory.
> [ and no: don't tell me it is a thread-state value :-) ]
> 
> On the other hand: presuming the "errors" thing is valid, *then* I see a
> need for a factory.

The idea is that various places that take an encoding name can also
take a codec instance.  So the user can call the factory function /
class constructor.

> Truly... I dislike factories. IMO, they just add code/complexity in many
> cases where the functionality isn't needed. But that's just me :-)

Get over it...  In a sense, every Python class is a factory for its
own instances!  I think you must be confusing Python with Java or
C++. :-)

--Guido van Rossum (home page: http://www.python.org/~guido/)