On Wed, 17 Nov 1999, Mark Hammond wrote:
>...
> Would it be possible to define a "standard package" called
> "encodings", and when we need an encoding, we simply attempt to load a
> module from that package? The key benefits I see are:
>...
> Is this worthy of consideration?
Absolutely!
You will need to provide a way for a module (in the "codec" package) to
state *beforehand* that it should be loaded for the X, Y, and Z encodings.
This might be in terms of little "info" files that get dropped into the
package. The __init__.py module scans the directory for the info files and
loads them to build an encoding => module-name mapping.
The alternative would be to have stub modules like:
iso-8859-1.py:
import unicodec
def encode_1(...)
...
def encode_2(...)
...
...
unicodec.register('iso-8859-1', encode_1, decode_1)
unicodec.register('iso-8859-2', encode_2, decode_2)
...
iso-8859-2.py:
import iso-8859-1
I believe that encoding names are legitimate file names, but they aren't
necessarily Python identifiers. That kind of bungs up "import
codec.iso-8859-1". The codec package would need to programmatically import
the modules. Clients should not be directly importing the modules, so I
don't see a difficult here.
[ if we do decide to allow clients access to the modules, then maybe they
have to arrive through a "helper" module that has a nice name, or the
codec package provides a "module = code.load('iso-8859-1')" idiom. ]
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4