This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author lemburg
Recipients dmi.baranov, doerwalter, ezio.melotti, lemburg, ncoghlan, paul.moore, vstinner
Date 2013-05-02.14:47:27
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <51827C7D.2080102@egenix.com>
In-reply-to <1367505704.87.0.654128646437.issue17878@psf.upfronthosting.co.za>
Content
On 02.05.2013 16:41, Nick Coghlan wrote:
> 
> Nick Coghlan added the comment:
> 
> This is actually similar to the problem with getting the list of modules an importer provides (that is, we don't currently have an officially defined method in the importer protocol for that, although pkgutil.iter_importer_modules implicitly looks for an "iter_modules" method, due to the old import emulation used until Python 3.2).
> 
> I see three possibilities:
> 
> 1. Use independent purpose specific protocols to get a list of entries out of these objects.
> 
> 2. Create a new, common protocol for extracting lists of entries from search hooks like importers and codec search functions
> 
> 3. Use the existing __iter__ protocol
> 
> I'm currently thinking option 3 might be a reasonable way forward. That is, if a codec search hook wants to provide a listing of available codecs, it can just define __iter__ in addition to __call__. Importers could define __iter__ in addition to the other methods in the importer API.
> 
> Thoughts?

Too obscure :-)

Let the object expose a method: .list_codecs() -> returns a list
of supported codecs as CodecInfo objects.

We may also deprecate the .__call__() in favor of:
.find_codec(encoding) -> return codec implementing encoding.
History
Date User Action Args
2013-05-02 14:47:27lemburgsetrecipients: + lemburg, doerwalter, paul.moore, ncoghlan, vstinner, ezio.melotti, dmi.baranov
2013-05-02 14:47:27lemburglinkissue17878 messages
2013-05-02 14:47:27lemburgcreate