I may gotten more vehement than was called for. I apologize.
My irritation came from not understanding what the intent was for this feature since it was inserted without any advance discussion. Speaking for myself, when I have a "big"-ish idea, I tend to make a thread in Scripting Discussion where I lay out my thoughts and ask for feedback. For example
Overriding methods with typedef arguments or
Implicit conversion to strings.
I don't understand where (some of you) thought I was getting defensive about ASH. It is certainly a smaller language than, say, Java. I have certainly felt limited, sometimes, when coding in it. Fortunately, I have the power to improve it for my (and everybody's) advantage. heeheehee has done that as well; if I recall "array literals" were theirs, originally. I extended them to general maps and made them work in more contexts, and they are the cat's meow, to my eye. But I'm quite sure that I didn't intend to imply that ASH is the "one true language for scripting KoLmafia" - especially since it is "one of two languages" we provide.
But a strength - or weakness - of ASH is that it has a controlled and curated access to which features of KoLmafia - and therefore KoL - you can access.
The security issues that lost brought up? You can read or write files - from within KoLmafia's data directories, but cannot use general file system operations. We closed a security hole, years ago, where a script could set the "command to invoke an editor on a script" property to any shell command and then say "edit this script", which would execute that shell command. I know that Python has tons of libraries and built-in support for files and such. I (and lost) worried that if Jython has such file system access, that would reopen up that security hole
I looked a little at the doc for Jython and saw that it lets you "import" any Java class on your classpath. I note several issues with that. The first of which are security issues of the sort frono pointed out.
For example, KoLmafia certainly has the internal ability to do mall-bot stuff; when we look up the mall price for something, we get a page of results from KoL. You can see that on the Purchase frame. If you tell KoLmafia to buy something, it will get you the cheapest one. But if you ask for the current price, you get the fifth-cheapest price. You can't use that to detect a single mis-priced Mr. A, for example, and snatch it up.
If Jython can import any class in KoLmafia and call any method from a class, boom; that protection goes away.
Similarly, we also prevent chat scripts from spamming public channels - or harrassing individual players in chat. I don't know for sure, but I suspect we have internal methods which could be used for such.
My second observation is what prompted some of my vehemence: If Jython scripts can call ANY method on ANY class, that turns into a potential maintenance nightmare for the devs. If a knowledgable user sees a "useful" internal method they want to call, their expectation will be that it will persist. What if I - or any dev - wants to completely refactor some internal aspect of KoLmafia? I did that for paths and tower door locks recently, for example. I see old old code where we have arrays of Objects, which are eminently suitable for conversion to classes or enums. Well, some of those correspond to ASH data types. If I refactor the code to make it better and more maintainable Java, I fix ASH. But Jython scripts accessing such data (without the benefit of a built-in data type like ASH provides) will break. Or, perhaps I change an internal facility and add an argument to a method. I fix all the Java inside KoLmafia. I do not fix your Jython script. And I really, really, really do not want to get bug reports - or even simple forum posts - asking me to explain - or, worse, justify - such changes. If you are familiar enough with the codebase to call methods inside KoLmafia, you are familiar enough to follow change logs and figure it out yourself - until you publish (or otherwise share) your Jython script with a "civilian". So to speak.
We can discuss all of thse things. Let's just have the "specification" and "design" discussions up front.
Thanks.