Currently when working with interactive sessions using the dir() or dir(module) built in is incredibly useful for exploring what functionality is available in a module. (Especially the regrettable libraries or modules that add really valuable functionality but have no or limited docstrings). However I often find that when a module adds a lot of functions I need to filter those entries to be able to find the one that I need, e.g.:
What I would really like to do is:
dir(mpmath.*sin*)
However, I know that the interpreter will hit problems with one or more operators being embedded in the module name. What I would like to suggest is extending the dir built-in to allow an optional filter parameter that takes fnmatch type wild card as an optional filter. Then I could use:
dir(mpmath, "*sin*")
To narrow down the candidates. Ideally, this could have a recursive variant that would also include listing, (and filtering), any sub-packages. -- Steve (Gadget) Barnes Any opinions in this message are my personal opinions and do not reflect those of my employer. --- This email has been checked for viruses by AVG. https://www.avg.com
On Thu, Jun 14, 2018 at 09:27:05AM +0000, Steve Barnes wrote: [...]
I have exactly that in my Python startup file. It monkey-patches the builtin dir with a custom wrapper function that has signature: edir( [object, [glob='',]] *, meta=False, dunder=True, private=True) For the glob, I support the following metacharacters: - Reverse matching: if the glob begins with '!' or '!=', the sense of the match is reversed to "don't match". - Case-sensitive matching: if the glob begins with '=' or '!=', perform a case-sensitive match. Otherwise filters are case- insensitive by default. - Wildcards: '?' to match a single character, '*' to match zero or more characters. - Character sets: e.g. '[abc]' to match any of 'a', 'b', 'c', or '[!abc]' to match any character except 'a', 'b', 'c'. If the glob argument contains no metacharacters apart from the ! and = flags, a straight substring match is performed. So there's no need to match on a glob "*foo*", I can just use "foo". If there is interest in this, I will clean it up for public consumption, and publish it somewhere as a third-party module, and for consideration for the stdlib. -- Steve
On 14/06/2018 13:33, Steven D'Aprano wrote:
Obviously, I personally would be interested (probably goes without saying). -- Steve (Gadget) Barnes Any opinions in this message are my personal opinions and do not reflect those of my employer. --- This email has been checked for viruses by AVG. https://www.avg.com
On Fri, Jun 15, 2018 at 10:10:19AM +0200, Michel Desmoulin wrote:
Fantastic idea. Would this make sense on var() too ? It's not exactly the same usage context.
No. The point of vars() is to return the actual namespace dict used by an object. It's not primarily an introspection tool, it is the public interface for accessing __dict__ without using the dunder directly. vars() and dir() have completely different purposes, and they do very different things. -- Steve
On Thu, Jun 14, 2018 at 09:27:05AM +0000, Steve Barnes wrote: [...]
I have exactly that in my Python startup file. It monkey-patches the builtin dir with a custom wrapper function that has signature: edir( [object, [glob='',]] *, meta=False, dunder=True, private=True) For the glob, I support the following metacharacters: - Reverse matching: if the glob begins with '!' or '!=', the sense of the match is reversed to "don't match". - Case-sensitive matching: if the glob begins with '=' or '!=', perform a case-sensitive match. Otherwise filters are case- insensitive by default. - Wildcards: '?' to match a single character, '*' to match zero or more characters. - Character sets: e.g. '[abc]' to match any of 'a', 'b', 'c', or '[!abc]' to match any character except 'a', 'b', 'c'. If the glob argument contains no metacharacters apart from the ! and = flags, a straight substring match is performed. So there's no need to match on a glob "*foo*", I can just use "foo". If there is interest in this, I will clean it up for public consumption, and publish it somewhere as a third-party module, and for consideration for the stdlib. -- Steve
On 14/06/2018 13:33, Steven D'Aprano wrote:
Obviously, I personally would be interested (probably goes without saying). -- Steve (Gadget) Barnes Any opinions in this message are my personal opinions and do not reflect those of my employer. --- This email has been checked for viruses by AVG. https://www.avg.com
On Fri, Jun 15, 2018 at 10:10:19AM +0200, Michel Desmoulin wrote:
Fantastic idea. Would this make sense on var() too ? It's not exactly the same usage context.
No. The point of vars() is to return the actual namespace dict used by an object. It's not primarily an introspection tool, it is the public interface for accessing __dict__ without using the dunder directly. vars() and dir() have completely different purposes, and they do very different things. -- Steve
participants (4)
-
Michel Desmoulin -
Rob Cliffe -
Steve Barnes -
Steven D'Aprano