[Python-ideas] PEP x: Static module/package inspection

Michael Foord fuzzyman at gmail.com
Wed Dec 28 16:28:44 CET 2011

On 28 December 2011 10:15, anatoly techtonik <techtonik at gmail.com> wrote:

> (reposting this from Google Group once more as the previous post missed
> Mailing List, because I was not subscribed in Mailman)
> *Static module/package inspection*
> Abstract:
>  - static: without execution (as opposed to dynamic)
>  - module/package: .py or __init__.py file
>  - inspection: get an overview of the contents
> *What should this do?*
> *
> *
> The proposal to add a mechanism to Python interpreter to get an outline of
> module/package contents without importing or executing module/package. The
> outline includes names of classes, functions, variables. It also should
> contain values for variables that could be provided without sophisticated
> calculations (e.g. a string, integer, but probably not expressions as it
> may lead to security leaks).
> *Why?*
> *
> *
> *user story PEPx.001:*
> As a Python package maintainer, I find it bothersome to repeatedly write
> bolierplate code (e.g. setup.py) to package my single file module. The
> reason I should write setup.py is to provide version and description info.
> This info is already available in my module source code. So I need to
> either copy/paste the info from the module manually, or to import (and
> hence execute) my module during packaging and installation, which I don't
> want either, because modules are often installed with root privileges.
> With this PEP, packing tool will be able to extract meta information from
> my module without executing it or without me manually copying version
> fields into some 'package configuration file'.
> *user story PEPx.002:*
> As a Python Application developer, I find it really complicated to provide
> plugin extension subsystem for my users. Users need a mechanism to switch
> between different versions of the plugin, and this mechanism is usually
> provided by external tool such as setuptools to manage and install multiple
> versions of plugins in local Python package repository. It is rather hard
> to create an alternative approach, because you are forced to maintain
> external meta-data about your plugin modules even in case it is already
> available inside the module.
> With this PEP, Python Application will be able to inspect
> meta-data embedded inside of plugins before choosing which version to load.
> This will also provide a standard mechanism for applications to check
> modules returned by packaging tools without executing them. This will
> greatly simplify writing and debugging custom plugins loaders on different
> platforms.
> *Feedback goal*
> At this stage I'd like to a community response to two separate questions:
> 1. If everybody feels this functionality will be useful for Python
> 2. If the solution is technically feasible

On a simple level, all of this is already "obtainable" by using the ast
module that can parse Python code. I would love to see a "python-object"
layer on top of this that will take an ast for a module (or other object)
and return something that represents the same object as the ast.

So all module level objects will have corresponding objects - where they
are Python objects (builtin-literals) then they will represented exactly.
For classes and functions you'll get an object back that has the same
attributes plus some metadata (e.g. for functions /  methods what arguments
they take etc).

That is certainly doable and would make introspecting-without-executing a
lot simpler.

I think your specific use cases are better served by adding functionality
to the packaging (distutils2) package however. I'd particularly like to see
plugin support in packaging (a cutdown version of setuptools entry points).

All the best,


> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas



May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20111228/6f2bca25/attachment.html>

More information about the Python-ideas mailing list