Nick Coghlan wrote:
Having to mess around with __import__ just to support a "choose
compression method" configuration option would be fairly annoying.
Perhaps, but even then, I'm not sure it makes sense to
lump them all into the same namespace.
If you're choosing a compression method, it make
On 2008-05-17 10:26, Greg Ewing wrote:
Nick Coghlan wrote:
Having to mess around with __import__ just to support a "choose
compression method" configuration option would be fairly annoying.
Perhaps, but even then, I'm not sure it makes sense to
lump them all into the same namespace.
Note th
Greg Ewing wrote:
Nick Coghlan wrote:
Having to mess around with __import__ just to support a "choose
compression method" configuration option would be fairly annoying.
Perhaps, but even then, I'm not sure it makes sense to
lump them all into the same namespace.
If you're choosing a compress
Greg Ewing writes:
> If you're choosing a compression method, it makes sense
> to choose 'zip', 'gzip', or 'bzip2', but less sense to
> choose 'hex' or 'base64',
Doesn't "consenting adults" cover choosing a nonsensical compressor?
Do you really think that .transform clients will really choose
Stephen J. Turnbull wrote:
Do you really think that .transform clients will really choose
'base64' when they want 'lzma'?
It depends on who the "client" is. An application popping
up a list of compression methods is just going to confuse
users if it lists "base64" as a possibility.
So it alre
Greg Ewing writes:
> So it already needs some application-specific notion of
> what constitutes a probable compression method built
> into it, and if that list is to be extensible, it needs
> an application-specific registry to manage it. Once
> you've got that, the general codec registry doe
