uncompyle6 has no API stability statement about python-uncompyle6 HOT 6 CLOSED

I gather that uncompyle6 is mostly intended for command line use

Well, I use it as a library for deparsing fragments of text at runtime.

... but I'd like to use it as an API, and it's currently a little hard to do because there's no way to tell what APIs are "public" and how likely they are to break.

I'm not sure I follow. Are you suggesting you want me to start adding underscores lots of places? I'd rather not spend my time doing that when there's still a ton of bugs that need to be fixed. Wish I could get more help on that.

With respect to the underscores, let me tell you a little story... I'd love be able to use Python more orthogonally and reduce my mental effort to remember if a function is a top-level function versus a message-receiving method on an object.. Specifically, I.d like to write s.len() instead of len(s). Well, I suppose I can except some yazoo, probably this Guido guy has decoded to put the ugly double underscore characters there so I'd have to write s.__len__() instead and take chastisement from the bone-headed Python community.

And speaking of API and compatibility, Python as a language is by far one of the worse languages for this and I suspect this is why adoption to Python 3 has been so darn slow.

But that said, if there' s a particular set of functions you'd like to declared "sacred", why don't you declare that and/or write up some "API" document and I'll see if that those things are kept compatible. Likewise for API irregularities.

from python-uncompyle6.

I'm not sure I follow. Are you suggesting you want me to start adding underscores lots of places?

Nope. I'm just asking for some documented distinction between what's public and private API (usually "what's documented is public, everything else is private" works for this and is what I use), and a backwards compatibility statement on the public API. e.g. semver, or a time based statement like in attrs or Twisted.

And speaking of API and compatibility, Python as a language is by far one of the worse languages for this and I suspect this is why adoption to Python 3 has been so darn slow.

Absolutely. It's a total pain.

But that said, if there' s a particular set of functions you'd like to declared "sacred", why don't you declare that and/or write up some "API" document and I'll see if that those things are kept compatible.

The main function I'm interested in is deparse_code. I'm happy to help writing documentation, but it's not clear from me how much of the behaviour of that function you want to commit to, etc.

from python-uncompyle6.

uncompyle6, xdis, and spark_parser use the 3-level semantic versioning scheme and I try to follow that or at least not be incompatible with that. When I support a new bytecode level (which may happen a bit in the future) I bump the middle number although that might not strictly be necessary.

The main function I'm interested in is deparse_code.

Hmm, that function is a bit ugly right now probably precisely because I tried to keep it compatible, so new default parameters keep getting added, such as 'exec', and then 'ispypy'. It might be good at this point to create another routine that takes an options dictionary, or possibly that can already be done using **params on the caller side.

I'm happy to help writing documentation, but it's not clear from me how much of the behaviour of that function you want to commit to, etc.

I'm a "vote with your actions" kind of guy. If this is of interest and importance to you suggest something, write it up, and make a pull request. Unless it is unreasonable or and undue chore to follow and maintain, we'll do it! Thanks.

from python-uncompyle6.

uncompyle6, xdis, and spark_parser use the 3-level semantic versioning scheme and I try to follow that or at least not be incompatible with that. When I support a new bytecode level (which may happen a bit in the future) I bump the middle number although that might not strictly be necessary.

OK, but without anything declaring what the public API is there's not much to be semantically versioned in this case.

I'm a "vote with your actions" kind of guy. If this is of interest and importance to you suggest something, write it up, and make a pull request. Unless it is unreasonable or and undue chore to follow and maintain, we'll do it! Thanks.

Well, voting is all very well, but it requires me to make a number of decisions for you! e.g. you don't actually have any API documentation right now, so adding documentation for something requires me to decide what you do there. Do you just want it added to the README? Shall I set up sphinx? etc.

from python-uncompyle6.

OK, but without anything declaring what the public API is there's not much to be semantically versioned in this case.

Disagree a little here. If interfaces change incompatibly as they have. I bump the major number. When new major features or code is split off into other independent packages, I bump the middle number. For bug fixes, cleanup and stuff like that I bump the right-most number. There is always a public API. It may be ugly or messy or not crisply defined, but there is always an public API.

so adding documentation for something requires me to decide what you do there. Do you just want it added to the README? Shall I set up sphinx? etc.

Yes, please add create a sphinx document if you are up to that. I've been using http://readthedocs.org for other projects so that would be convenient me, but if you have another favorite public thing like that, I suppose that'd be fine too.

Thanks for undertaking to do this. All of my open-source projects get much better with the help of others, and I am grateful for this.

from python-uncompyle6.

Closed for lack of interest.

from python-uncompyle6.