[issue41895] PyMethodDef does NOT have any field contains context in embedded C
New submission from dexter :
I am trying to create app embedded python as interpreter, and I use
PyImport_AppendInittab to import some helper functions to python. on website
the example is excellent when you already know how many functions we want to
import. but when my functions are based on a runtime dynamic list, even I
create all PyModuleDef and PyMethodDef, but when the function all goes to
PyCFunction which only has two PyObject* and return PyObject* i lost context
information about C. may be I am not clear, but what I am expecting is
PyMethodDef should define like
struct PyMethodDef {
const char *ml_name; /* The name of the built-in function/method */
PyCFunction ml_meth;/* The C function that implements it */
int ml_flags; /* Combination of METH_xxx flags, which mostly
describe the args expected by the C func */
const char *ml_doc;/* The __doc__ attribute, or NULL */
void* extra; /* <= here is NEW */
};
and PyCFunction should define like
typedef PyObject *(*PyCFunction)(PyObject *, PyObject *, void * /* for extra
void* */);
--
components: C API
messages: 377714
nosy: dexter
priority: normal
severity: normal
status: open
title: PyMethodDef does NOT have any field contains context in embedded C
type: enhancement
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue41895>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41895] PyMethodDef does NOT have any fields contain context in embedded C
Change by dexter : -- title: PyMethodDef does NOT have any field contains context in embedded C -> PyMethodDef does NOT have any fields contain context in embedded C ___ Python tracker <https://bugs.python.org/issue41895> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41895] PyMethodDef does NOT have any fields contain context in embedded C
dexter added the comment:
for example, there are some of shared libs, all these libs have a function
named getList() exported. and getList() will return a list of names which also
as a function name been exported.
shared lib A
export getList() -> return ["aaa", "bbb"]
export aaa()
export bbb();
shared lib A
export getList() -> return ["xyz", "abc", "mno"]
export xyz()
export abc();
export mno();
and I want expose shared lib A aaa, bbb or shared lib B xyz abc mno when I load
them, (maybe A, maybe B, or maybe both if they exists, work like plugins)
I have a loop like
for (int i = 0; i < length_of_list; ++i) {
char* funcName = getName(i);
PyMethodDef def { funcName, fooCall, MATH_VARARGS, nullptr, /* funcname
here */};
///
}
PyObject* fooCall(PyObject* self, PyObject* args, void* context) {
char* funcname = (char*) context;
/// load func based on name.
}
--
___
Python tracker
<https://bugs.python.org/issue41895>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35203] Windows Installer Ignores Launcher Installer Options Where The Python Launcher Is Already Present
New submission from Dexter : When installing Python 3.7 from the Windows Installer in a restricted environment the installer appears to ignore the InstallLauncherAllUsers=0 and Include_launcher=0 flags if the launcher is already present from a previous install. I am on a machine where the system python is centrally controlled and cannot be modified by me. In previous versions I have installed personal copies using the InstallLauncherAllUsers=0 InstallAllUsers=0 as exemplified in the docs or just unticking in the UI. However in 3.7 the tick-box for the launcher is ticked but greyed out in the UI. I am unable to de-select it and, as I do not have permission to modify the system wide launcher, I cannot install Python 3.7. My suspicion is that the box is greyed out if someone has installed the site wide version to ensure the site wide version is in-line with the installer but: a) What if this is an older version and I do not want it replaced. b) What if a user like me can't upgrade that script and is happy to have a version that will not be understood by the launcher for other purposes. Assuming there is no current workaround. I propose that either we remove this restriction or at least allow an override. e.g. ForceExistingLauncherUpgrade=1 by default to preserve current behaviour and if 0 then allow the other launcher exclusions to apply. -- components: Windows messages: 329550 nosy: gr-dexterl, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Windows Installer Ignores Launcher Installer Options Where The Python Launcher Is Already Present type: behavior versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue35203> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35203] Windows Installer Ignores Launcher Installer Options Where The Python Launcher Is Already Present
Dexter added the comment: Sadly due to the secure environment I'm unable to attach the log. The exact error is: "You must be an Administrator to remove this application. To remove this application you can log on as an Administrator, or contact your technical support group for assistance." This is when installing to an arbitrary folder under my control. This is exactly what happens with the 3.5 installer which I also need because of third party apps with hard coded pyenv versions. The difference is that I can simply un-tick the launcher for all users box to allow the install. Given that this is for a specific third party app I don't actually have any need of the launcher knowing about this version at all. If you can tell me what part of the installer log is of interest I may be able to send an anonymised snippet. The error code is: 0x80070643 - Fatal Error During Installation. The point in the log where I see an error is: Error 0x80070643: Failed to uninstall MSI package. Error 0x80070643: Failed to execute MSI package. Error 0x80070643: Failed to configure per-machine MSI package. Applied execute package: core_AllUsers, result: 0x80070643, restart: None Error 0x80070643: Failed to execute MSI package. This is just after: "Verified existing payload: pip_JustForMe" I'm not quite sure what you mean though. What is the difference between "the launcher will be installed at the end of setup" and "the installer is going to try and install the launcher" if you mean it's a separate process that'll still never work for a restricted environment like this. It's basically a problem that the "for all users (requires elevation)" tickbox is selected. The launcher but not for all users might work but the fact that I can't un-tick something that says it requires elevation when I can't have elevation is a full blocker no matter what. Also under advanced options for Python itself I can un-tick the for all users just not for the launcher. The specific fail point is not exactly an upgrade it claims it doesn't have permission to uninstall something. Given that the launcher is the only thing I can't un-tick and launcher only fails in the same way I'm assuming it's the all-users launcher. But yeah I'm in a situation where I will never have permission to uninstall nor upgrade nor modify that file in any way so having it force an upgrade means I can't install the newer Python versions. I had the same issue in 3.5 but there the InstallLauncherAllUsers=0 InstallAllUsers=0 flags were sufficient to allow an isolated install. -- ___ Python tracker <https://bugs.python.org/issue35203> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41454] while loop bug on list
New submission from Dexter Ramos : The output should have no duplicates but it has. When I added another "5" on the list it goes okay and is still okay if I add more. But when there is only two 5's it won't do its job. -- components: Windows files: app.py messages: 374661 nosy: Dexter Ramos, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: while loop bug on list type: behavior versions: Python 3.8 Added file: https://bugs.python.org/file49356/app.py ___ Python tracker <https://bugs.python.org/issue41454> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41454] while loop bug on list
Dexter Ramos added the comment: Thank you Mr. Erick Smith. Now I know. I also tried to find the hard way like this: finding nemo- [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 1, 2, 3, 4] --->index [4, 1, 2, 5, 7, 4, 2, 8, 9, 5, 3, 2, 4, 6] --->original list / --->started at index 0 with value of 4 [1, 2, 5, 7, 2, 8, 9, 5, 3, 2, 6, 4] --->1st iteration, all 4's are removed then appended so the index adjusted /--->next at index 1 with a value of 2 (whereas value 1 was skipped which had index 1 originally; this is not seen on the output because it has no duplicate) [1, 5, 7, 8, 9, 5, 3, 6, 4, 2] --->3rd iteration / --->next at index 2 with value of 7; value 5 was skipped which had the index 2 originally; cause found! [1, 5, 8, 9, 5, 3, 6, 4, 2, 7] --->4th ... ... ---nemo found--- Credits to you. Here is the new working code: ---code bunchofnumbers = [4, 1, 2, 5, 7, 4, 2, 8, 9, 5, 3, 2, 4, 6] for eachnumber in bunchofnumbers.copy(): while eachnumber in bunchofnumbers: bunchofnumbers.remove(eachnumber) bunchofnumbers.append(eachnumber) bunchofnumbers.sort() ---end of code- OUTPUT: [1, 2, 3, 4, 5, 6, 7, 8, 9] print(bunchofnumbers) -- ___ Python tracker <https://bugs.python.org/issue41454> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
