Is the project still maintained?

[aurelg]

Thanks @Technologicat for this project, it's so useful and lightweight ! The latest commit happened a while ago, and 3 PRs have been waiting for a while. Is it still maintained? Or are you looking for a new maintainer?

[lmmx]

The docstrings say "tested on Python 3.6", I think it's dangling by a thread and should be forked and ressurected.

[Technologicat]

I agree it might be best for someone else to take over the maintenance at this point :)

Basically, I have updated pyan whenever I've needed its capabilities myself, but it's now been a rather long since the last time I have needed to familiarize myself with anyone else's Python codebase - hence no updates to pyan in a long while.

I invited @jdb78 and @johnyf as new maintainers a while back, but I suspect the situation for them is similar to mine. I see there is a significant need in the Python community for this kind of static analysis tool, but not so much interest in maintaining one.

For anyone interested in taking over, there are some technical and philosophical issues to consider. I'm writing them here to emphasize that pyan would benefit from much more than a simple minimal update:

• First and foremost, when I did most of my work on pyan, I hadn't previously written any formal static analysis tools, so it wasn't completely clear to me at that time which features of the code being analyzed should be considered static and which should be considered dynamic. This effectively resulted in pyan developing a perl-ish DWIM mindset instead of the pythonic refuse the temptation to guess.
  • While Python is a highly dynamic language (e.g. almost anything can be arbitrarily monkey-patched at run time), in practice it is mostly used like a static one - so by intentionally confusing the static and dynamic features, it is possible to analyze a codebase almost as if it was written in a static language, which is what pyan currently does.
  • If an analysis claims to be static, it should look at the code lexically (similarly to how scope analysis works), ignoring the dynamic environment. This would do much less than pyan already does; I'm not sure whether it would be at all useful. So some thought is needed as to what pyan should do.
• Python has pretty good support for metaprogramming - enough to change the language semantics (e.g. auto-lazify, or introduce continuations), or to package abstractions into syntactic macros. Ideally, if an analyzer claims to be general, it should support at least basic uses of such features.
  • What should be supported? Personally, I'd draw the line at "no longer semantically Python" - macro dependencies should be analyzed, but dialects might deviate from standard Python too much (that is indeed their entire point).
• Subtleties of the tuple-assignment syntax are not treated correctly. The "last seen value" mechanism should be completely scrapped in favor of a proper local analysis of the subtree. "Last seen value" is mutable state, and mutable state makes code very difficult to keep bug-free. Working on the two projects linked above has taught me that AST walks need to be very carefully controlled to avoid losing relevant context.
• Analysis granularity needs adjustment. Sometimes, a file-level analysis (see modvis.py in the repo) or perhaps even a package-level analysis is sufficient; sometimes, a class-level analysis would be nice; and sometimes, a function-level analysis is the most appropriate one. Ideally, it should be possible to do a more detailed analysis for only parts of the codebase.
• The AST representation has changed in pretty much every 3.x release of Python. To keep the analyzer working reliably, it needs constant maintenance to account for this. See #51.

[esmiralha]

Even if you no longer maintain it, please publish the fix to #72 to PyPi...

[MartinThoma]

If anybody ever gets this up again + adds some unit tests + documentation: https://github.com/jazzband might be a good place for this project (shared ownership so that it isn't abandoned again)