added note about the need of more introspective features: listing available modules and data files.
This commit is contained in:
parent
74737f0d45
commit
e7d8b40694
|
@ -502,6 +502,14 @@ Open Issues
|
||||||
us nothing extra. Whether loaders will ever need to carry so much
|
us nothing extra. Whether loaders will ever need to carry so much
|
||||||
independent state for this to become a real issue is questionable.
|
independent state for this to become a real issue is questionable.
|
||||||
|
|
||||||
|
It was suggested on python-dev that it would be useful to be able to
|
||||||
|
receive a list of available modules from an importer and/or a list
|
||||||
|
of available data files for use with the get_data() method. The
|
||||||
|
protocol could grow two additional extensions, say list_modules()
|
||||||
|
and list_files(). The latter makes sense on loader objects with a
|
||||||
|
get_data() method. However, it's a bit unclear which object should
|
||||||
|
implement list_modules(): the importer or the loader or both?
|
||||||
|
|
||||||
|
|
||||||
Implementation
|
Implementation
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue