Deprecate Public RunString

[vmuriart]

Deprecate Public API RunString to internal use and encourage use of RunSimpleString, Eval, Exec.
See #389 (comment) for related discussion.

Would use:

[Obsolete("Public use of RunString is deprecated, use Exec/Eval instead.")]
public static PyObject RunString(

[filmor]

Can't we remove it immediately? Didn't I introduce this for the setargv branch, at least in the extended form?

[vmuriart]

@filmor correct, you introduced the extended form in that pr. The previous form was there before though. I think we should give users atleast 1 release to migrate over if they are using it.

[filmor]

But we should only have the previous form public. I think we should hide all functions that operate on pointers directly (like this one does through use of locals and globals.

[den-run-ai]

Actuall RunString was used quite a bit, but mostly reporting issues:

http://stackoverflow.com/questions/15749028/would-you-share-your-idea-how-to-call-python-command-from-embedded-python-net

https://mail.python.org/pipermail/pythondotnet/2007-March/000592.html

https://mail.python.org/pipermail/pythondotnet/2008-January/000766.html

https://mail.python.org/pipermail/pythondotnet/2006-October/000559.html

[yagweb]

@vmuriart When implemented the methods Eval and Exec, I thought the better design is using PyDict instead of IntPtr? as the data type of their arguments globals and locals. However considering RunString may be widely used, keep using IntPtr? can simplify the code migration by directly replacing RunString with Exec. If the PyScope function in this PR is accomplished, people may prefer to use the Eval and Exec in it instead of this Eval and Exec.

@denfromufa It seems like many people including me think the docs for embedding Python in .Net is too simple. Many sample code were added in the unit test project lately. Maybe I can help supplement this part of the docs after I have more practice.

[vmuriart]

@yagweb admitting, our docs are thin and outdated. We just migrated them from an old html file to an md file so that its easier to version control. We would definitely appreciate any help on this.

@filmor good point. We can recreate the old public api and make the newer one internal. Looking back on 9912712 though we used to expose the IntPtr's api as well so won't be able to remove immediately either. @yagweb makes a good point that using PyDict makes more sense for this function signature too.

I can open the pr if everyone agrees on the following.

• Make current RunString method internal.
• Add overload RunString with the old signatures, make public and deprecation notice for removal on a few releases

In another pr (once we settle PyEngine, vs Py, vs ...)

• Add some documentation to give visibility to newer methods.

[den-run-ai]

@yagweb I agree that embedding docs are very thin. Which methods do you think need to be exposed in the API docs for embedding? I opened a separate issue for methods that need to added in docs: #410