Re: [Python-Dev] Error message for wrong number of arguments
On 08/01/2018 02:40 PM, Armin Rigo wrote: I think that argument clinic knows if the built-in function is supposed to be a method or a function. Yes, Argument Clinic knows. Clinic's "Function" instances have a "cls" member, and if that's set to a Clinic "Class" instance--and it's not one of the special methods like new or init--then it's a normal method. It doesn't look too hard to add a new flag METH_IS_METHOD or something, which would be taken in consideration in the common cases, and which can be added manually OR used automatically by argument clinic. Yes, Clinic could easily automatically generate such a flag. //arry/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Error message for wrong number of arguments
Actually, I just realized that it's not really possible to fix the error messages for built-in methods. The problem is that Argument Clinic does not know whether a function or method is being handled. For example, there is no indication at all that this is a method (note that the name "list.insert" might refer to a function "insert" inside a module called "list" or a method "insert" or a class "list"): /*[clinic input] list.insert index: Py_ssize_t object: object / Insert object before index. [clinic start generated code]*/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Error message for wrong number of arguments
Actually, scratch that, I posted too soon. There is also a block /*[clinic input] class list "PyListObject *" "&PyList_Type" [clinic start generated code]*/ So it could work. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2018-07-27 - 2018-08-03)
Python tracker at https://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open6759 (+19)
closed 39323 (+63)
total 46082 (+82)
Open issues with patches: 2692
Issues opened (60)
==
#34097: ZIP does not support timestamps before 1980
https://bugs.python.org/issue34097 reopened by vstinner
#34177: test_site fails in macOS-PR VSTS builds for 3.7 branch
https://bugs.python.org/issue34177 reopened by pablogsal
#34252: Bunch of path leaks on Python 3.7 on Release
https://bugs.python.org/issue34252 opened by illera88
#34253: Tkinter- On windows, calling filedialog or messagebox before t
https://bugs.python.org/issue34253 opened by nyt
#34254: Include type annotations in error messages for better errors
https://bugs.python.org/issue34254 opened by xtreak
#34255: test_embed skipped when srcdir != builddir
https://bugs.python.org/issue34255 opened by ronaldoussoren
#34256: Python treats ASCII record seperator ('\x1e') as a newline
https://bugs.python.org/issue34256 opened by timClicks
#34259: Improve docstring of list.sort
https://bugs.python.org/issue34259 opened by timhoffm
#34260: shutil.copy2 is not the same as cp -p
https://bugs.python.org/issue34260 opened by csernazs
#34261: Add description to clinic.py
https://bugs.python.org/issue34261 opened by timhoffm
#34262: Asyncio test fails under Win 7
https://bugs.python.org/issue34262 opened by pansen
#34264: Inconsistency between stack size in main thread and secondary
https://bugs.python.org/issue34264 opened by ronaldoussoren
#34266: Bad behavior with "restart \" or "restart "" in pdb
https://bugs.python.org/issue34266 opened by ppperry
#34267: find_python.bat doesn't find installed Python 3.7
https://bugs.python.org/issue34267 opened by Segev Finer
#34268: run pool.submit in callback when future.set_result
https://bugs.python.org/issue34268 opened by gaoxinge
#34270: Add names to asyncio tasks
https://bugs.python.org/issue34270 opened by alex.gronholm
#34271: Please support logging of SSL master secret by env variable SS
https://bugs.python.org/issue34271 opened by jmfrank63
#34272: Reorganize C API tests
https://bugs.python.org/issue34272 opened by serhiy.storchaka
#34273: %f is confusingly associated with fixed point format
https://bugs.python.org/issue34273 opened by MikeFoxtrot
#34274: Python launcher behavior with "#!/usr/bin/env python" shebang
https://bugs.python.org/issue34274 opened by Segev Finer
#34276: urllib.parse doesn't round-trip file URI's with multiple leadi
https://bugs.python.org/issue34276 opened by chris.jerdonek
#34278: Documentation: os.waitid and os.WNOHANG
https://bugs.python.org/issue34278 opened by crzbear
#34279: RFC: issue a warning in regrtest when no tests have been execu
https://bugs.python.org/issue34279 opened by vstinner
#34282: Enum._convert shadows members named _convert
https://bugs.python.org/issue34282 opened by orlnub123
#34283: [Windows] Python 2 mishandles console code page after setlocal
https://bugs.python.org/issue34283 opened by Segev Finer
#34284: Nonsensical exception message when calling `__new__` on non-in
https://bugs.python.org/issue34284 opened by ppperry
#34285: regrtest: in case of test failure, add "always look on the bri
https://bugs.python.org/issue34285 opened by vstinner
#34286: lib2to3 tests fail on the 3.7 branch (used to work with 3.7.0)
https://bugs.python.org/issue34286 opened by doko
#34288: Declare sethostname in socketmodule.c for SOLARIS
https://bugs.python.org/issue34288 opened by rbelio
#34290: _ctypes PyCField_new doesn't do anything
https://bugs.python.org/issue34290 opened by bup
#34292: test_compile hangs in AMD Ubuntu buildbots
https://bugs.python.org/issue34292 opened by pablogsal
#34293: DOC: Makefile inherits a Sphinx 1.5 bug regarding PAPER envvar
https://bugs.python.org/issue34293 opened by jfbu
#34294: re.finditer and lookahead bug
https://bugs.python.org/issue34294 opened by beardypig
#34296: Speed up python startup by pre-warming the vm
https://bugs.python.org/issue34296 opened by cykerway
#34297: Windows py.exe launcher fail to handle quote correctly
https://bugs.python.org/issue34297 opened by copelnug
#34300: gcc 7.3 causes a warning when compiling getpath.c in python 2.
https://bugs.python.org/issue34300 opened by tzickel
#34302: Avoid inefficient way to find start point in deque.index
https://bugs.python.org/issue34302 opened by ksg97031
#34303: micro-optimizations in functools.reduce()
https://bugs.python.org/issue34303 opened by sir-sigurd
#34305: inspect.getsourcefile and inspect.getcomments do not work with
https://bugs.python.org/issue34305 opened by Eric.Wieser
#34306: minidom: wrong processing of xmlns attributes
https://bugs.python.org/issue34306 opened by porton
#34308: shutil.copystat fails in dockered Linux
Re: [Python-Dev] New _Py_InitializeFromConfig() function (PEP 432)
Before I dive in, I'll say that I'd really like to hear Nick's opinion on all this. :) On Thu, Aug 2, 2018 at 9:59 AM Victor Stinner wrote: > 2018-08-02 1:18 GMT+02:00 Eric Snow : > > The "core" config is basically the config for the runtime. In fact, > > PEP 432 renamed "core" to "runtime". Please keep the firm distinction > > between the runtime and the (main) interpreter. > > There is already something called _PyRuntime but it's shared between > all interpreters. _PyRuntime is a static global of type PyRuntimeState. It is where I consolidated (nearly) all the global runtime state last September. > _PyCoreConfig is already *per* interpreter. This was done as part of the PEP 432 implementation, which I landed during PyCon 2017. If PyRuntimeState had existed already I'm sure it would be there instead. > Would you mind to elaborate what you mean by the "main interpreter"? I > don't see anything obvious in the current code about what is a "main > interpreter". Technically, I don't see anything like that. The main interpreter is the first one created (during runtime initialization). It is special for a variety of reasons. Here are the ones I could think of: 1. the "main" thread will always belong to the main interpreter since it is the first PyThreadState created 2. runtime initialization uses the main interpreter exclusively 3. the first phase of runtime initialization (pre-initialization) ends with the main interpreter being *partially* configured 4. during the second phase (initializing), the partially-configured main interpreter facilitates the use of most of the C-API and may be used by embedders * this is the only time that an interpreter may be used in this way, and it only happens with the main interpreter 5. runtime finalization takes place using the main interpreter 6. the main interpreter is the last one destroyed during finalization 7. the REPL runs only in the main interpreter 8. the Python CLI is run in the main interpreter (i.e. in its __main__ module) 9. the main interpreter cannot be destroyed (except during finalization) 10. in Python code the main interpreter will always exist 11. it is the parent of all subinterpreters created in Python code (via PEP 554) 12. signals are handled only in the main interpreter 13. all single-threaded Python code is run in the main interpreter Note that there isn't anything special to the interpreter itself, but rather in where and how it's used. However, that matters and the runtime needs to treat it specially. I expect all this isn't well-documented because it is relevant to very few people. > I'm still not convinced that we need _PyMainInterpreterConfig: Let's step back a moment and consider the course of events: 1. PEP 432 was created nearly 6 years ago to address the tangle that runtime initialization had become, with the intent of helping both the CPython maintainers and embedders 2. Nick did some re-organization around then (e.g. factoring out pylifecycle.c) to facilitate an implementation of the PEP 3. Nick implemented PEP 432, with a plan to merge it as a *private* API regardless of whether or not the PEP was accepted (with general consensus that doing so was a good idea) * see https://bitbucket.org/ncoghlan/cpython_sandbox/branch/pep432_modular_bootstrap * landing the private API would allow us to iron out the details of the PEP * work happened in spurts in 2013, 2015, and 2016; I kept poking Nick because the implementation was a big blocker for my multi-core/subinterpreters project 4. leading up to (and at) PyCon 2017, I forked Nick's branch, moved it to github, rebased it onto master, got it working again, created a PR, and finally landed it 5. since then the implementation has changed a bunch (due to Victor's much appreciate efforts) and has diverged from the PEP * notably it's unclear that code (especially pymain) strictly conforms to the phases in the PEP At this point the PEP is out of date. There have been several mailing list threads (all python-dev, IIRC) and some BPO issues where Victor solicited clarification or expressed a desire to change things and Nick gave feedback. None of that made it into the PEP. :( Consequently the PEP is inconsistent with the actual target. Furthermore, as was intended, we've learned of a few ways that the PEP could be improved. We *really* need to get the PEP updated so we can be sure everyone has all the info. Regarding the justification for the "main interpreter" config, the implementation has diverged from the original intent of the PEP: * the core/runtime config was meant to hold the minimal data needed to bootstrap/initialize the basic (limited) functionality of the C-API, including a restricted main interpreter + the struct members were strictly C plain-old-types since using PyObject would require the runtime to already be (partially) initialized + in the last year a lot of data has been added to this config; I don't know how much is strictly necessary to bootstrap
Re: [Python-Dev] Error message for wrong number of arguments
On 2018-07-30 17:28, Nick Coghlan wrote: I would, and I think it would make sense for the PEP to cite improving consistency (and reducing code duplication?) in that regard as an advantage of the PEP. I'm not sure to which PEP you are referring (PEP 580 or a new PEP?). After thinking a bit about the issue of error messages, I realized that PEP 580 would make this easier to fix (to be clear: there are ways to fix it without PEP 580, I'm just saying that PEP 580 makes it easier). There are two related reasons for this: * The existing code which calls the actual underlying C function doesn't have access to the Python-level function object. So it can't know whether it's a function (where self doesn't count) or a method (where self counts). * Armin Rigo suggested to use a new flag to indicate this difference: that would certainly work for Argument Clinic (just have Argument Clinic add that flag). For methods defined without Argument Clinic, we cannot require such a new flag though. We could still add the flag at runtime, but it's far from clear if we can freely change the flags inside a PyMethodDef at runtime (at least, no existing code that I know does that). PEP 580 solves the first issue by having the function object available and it solves the second issue by not relying on PyMethodDef at all for calling functions/methods. The second issue especially can be generalized as: PEP 580 makes the implementation of functions/methods much less rigid, making it easier to change the implementation. So maybe this can be seen as yet another advantage of PEP 580. Jeroen. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Finding Guido's replacement
On Mon, Jul 23, 2018 at 6:12 AM, Chris Angelico wrote: > Guido's term as Benevolent Dictator For Life has been a long one, but > in the wake of his resignation, we have an opportunity to correct some > fundamental flaws in the system. Among them: > > * Guido lacks patience, as evidenced by the brevity of his acceptance > posts. See > https://mail.python.org/pipermail/python-dev/2017-December/151038.html > and https://mail.python.org/pipermail/python-dev/2011-November/114545.html > and particularly > https://mail.python.org/pipermail/python-dev/2016-May/144646.html > where Guido specifically cites his own lack of patience. > > * Lately, all Guido's actions have been to benefit his employer, not > the Common Pythonista. We have proof of this from reliable reporting > sources such as Twitter and social media. > > * Finally, "For Life" is far too long. We need to change our rulers > periodically. > > I propose a new way to appoint a project head. All candidates shall be > flown to an island owned by the Python Secret Underground (which > emphatically does NOT exist, but an island that would be owned by it > if it did), whereupon they parachute down, search for guns, and > proceed to fight each other until only one is left alive. The survivor > shall be treated to a chicken dinner and proclaimed Patient, > Understanding, Benevolent Governor, a title which shall be retained > for one fortnight, after which we repeat the exercise. > > If this plan meets with broad approval, I shall write up PEP 3401, in > honour of the prior art in PEP 401. For those who didn't pick up on ANY of the hints: THE ABOVE WAS A JOKE. Please do not take it seriously. I apologize for assuming that people would think this funny, which was an error of judgement on my part. Finding Guido's replacement is being handled seriously elsewhere, not here, and would not be done in any manner akin to the above. ChrisA ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Finding Guido's replacement
On Mon, Jul 23, 2018 at 6:12 AM, Chris Angelico wrote: > Guido's term as Benevolent Dictator For Life has been a long one, but > in the wake of his resignation, we have an opportunity to correct some > fundamental flaws in the system. Among them: > > * Guido lacks patience, as evidenced by the brevity of his acceptance > posts. See > https://mail.python.org/pipermail/python-dev/2017-December/151038.html > and https://mail.python.org/pipermail/python-dev/2011-November/114545.html > and particularly > https://mail.python.org/pipermail/python-dev/2016-May/144646.html > where Guido specifically cites his own lack of patience. > > * Lately, all Guido's actions have been to benefit his employer, not > the Common Pythonista. We have proof of this from reliable reporting > sources such as Twitter and social media. > > * Finally, "For Life" is far too long. We need to change our rulers > periodically. > > I propose a new way to appoint a project head. All candidates shall be > flown to an island owned by the Python Secret Underground (which > emphatically does NOT exist, but an island that would be owned by it > if it did), whereupon they parachute down, search for guns, and > proceed to fight each other until only one is left alive. The survivor > shall be treated to a chicken dinner and proclaimed Patient, > Understanding, Benevolent Governor, a title which shall be retained > for one fortnight, after which we repeat the exercise. > > If this plan meets with broad approval, I shall write up PEP 3401, in > honour of the prior art in PEP 401. More specifically: It has been brought to my attention that the content of this post may have been offensive to some. This was NOT my intention, and for this I apologize. It was a failed attempt to make people laugh, and I did not want at any time to cause pain. Please accept my apologies, and the withdrawal of the jest. ChrisA ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New _Py_InitializeFromConfig() function (PEP 432)
It seems like the PEP 432 proposes an API designed from scratch as the target API. I started from the 28 years old C code and I tried to cleanup the code. Our method is different, so it's not surprising that the result is different :-) My intent is to get: * a function to read *all* configuration with no side effect and put it into a single structure: _PyCoreConfig * modify Py_Main() and all variants of Py_Initialize() to always end in the same code path using _PyCoreConfig I'm open to change to move the current implementation closer to the PEP 432. But it seems like I don't understand well the subtle parts of this PEP. > * core/runtime config > + minimal I'm not sure of what you mean by "minimum". I collected *all* parameters need to initialize Python and there are something like 40 parameters or more. But _PyCoreConfig has enough parameters to initialize a full Python with a working importlib and a REPL, for example. Where do you put the limit for "minimal"? > * main interpreter config > + includes everything needed to finish full runtime initialization For practical reason, I prefer to be able to pass the "path configuration" at the C level to be able to initialize importlib. IMHO it makes the current code base simpler, since the path computation is fully implemented in C. For example, it allows embedders to use a fixed sys.path in C. IMHO a good example is to imagine a Python runtime with *no* filesystem access, where everything is built into the binary. So we have to skip completly the code computing the path configuration, since this operating access the filesystem as well! Maybe something should be changed here? > The duplication is due to there being C and PyObject versions. It is > for the sake of embedders (and a little bit of sanity). The big > reason why it shouldn't be a problem is because > PyMainInterpreterConfig is generated directly from PyRuntimeConfig > (AKA PyCoreConfig) and only *after* we've used the runtime config to > bootstrap the limited runtime (after which it shouldn't be modified > ever). So there's no risk of inconsistency, right? Currently, core_config and main_config can be modified, as global variables: some parameters exist in 3 versions, each is modified. And it's unclear which one has the highest priority. For example, if we decide to always rely on core_config, we have to modify the C code to not longer access Py_VerboseFlag after Py_Initialize(). I'm talking about the current C code, not your theorical API. > Perhaps it would make sense to only keep a const copy of both, to > avoid modification? Maybe. But currently, some flags are modified after Py_Initialize(), especially Py_InspectFlag in main.c. I would prefer to keep a read-only configuration to reflect what sys.flags contains and know how Python has been initialized. > As noted above, the core/runtime config should probably be on > PyRuntimeState instead. For me it doesn't make sense to put all _PyCoreConfig parameters into PyRuntimeState. PyRuntimeState seems to be a singleton, so it means that all interepreters would have the same configuration. Whereas I like the idea of having a different verbose and/or sys.path per intepreter. Or maybe I misunderstood what you mean by "core config". I'm talking about the _current_ _PyCoreConfig in master. Victor ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
