Repository navigation
Deprecate Public RunString #401
Description
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(
Activity
filmor commentedon Feb 24, 2017
Can't we remove it immediately? Didn't I introduce this for the setargv branch, at least in the extended form?
vmuriart commentedon Feb 24, 2017
@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 commentedon Feb 24, 2017
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
localsandglobals.den-run-ai commentedon Feb 24, 2017
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 commentedon Feb 24, 2017
@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 commentedon Feb 24, 2017
@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
publicapi and make the newer oneinternal. Looking back on 9912712 though we used to expose theIntPtr's api as well so won't be able to remove immediately either. @yagweb makes a good point that usingPyDictmakes more sense for this function signature too.I can open the pr if everyone agrees on the following.
RunStringmethodinternal.RunStringwith the old signatures, makepublicand deprecation notice for removal on a few releasesIn another
pr(once we settle PyEngine, vs Py, vs ...)den-run-ai commentedon Feb 27, 2017
@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
Deprecate public RunString
Deprecate public RunString
Rebase with master (#2)
add a scope class to manage the context of interaction with Python an… (
add a scope class to manage the context of interaction with Python an… (