Re: [Python-Dev] BDFL-Delegate appointments for several PEPs
Hi Petr, On 27/03/2019 1:50 pm, Petr Viktorin wrote: On Sun, Mar 24, 2019 at 4:22 PM Mark Shannon wrote: Hi Petr, Regarding PEPs 576 and 580. Over the new year, I did a thorough analysis of possible approaches to possible calling conventions for use in the CPython ecosystems and came up with a new PEP. The draft can be found here: https://github.com/markshannon/peps/blob/new-calling-convention/pep-.rst I was hoping to profile a branch with the various experimental changes cherry-picked together, but don't seemed to have found the time :( I'd like to have a testable branch, before formally submitting the PEP, but I'd thought you should be aware of the PEP. Cheers, Mark. Hello Mark, Thank you for letting me know! I wish I knew of this back in January, when you committed the first draft. This is unfair to the competing PEP, which is ready and was waiting for the new govenance. We have lost three months that could be spent pondering the ideas in the pre-PEP. I realize this is less than ideal. I had planned to publish this in December, but life intervened. Nothing bad, just too busy. Do you think you will find the time to piece things together? Is there anything that you already know should be changed? I've submitted the final PEP and minimal implementation https://github.com/python/peps/pull/960 https://github.com/python/cpython/compare/master...markshannon:vectorcall-minimal Do you have any comments on [Jeroen's comparison]? It is rather out of date, but two comments. 1. `_PyObject_FastCallKeywords()` is used as an example of a call in CPython. It is an internal implementation detail and not a common path. 2. The claim that PEP 580 allows "certain optimizations because other code can make assumptions" is flawed. In general, the caller cannot make assumptions about the callee or vice-versa. Python is a dynamic language. The pre-PEP is simpler then PEP 580, because it solves simpler issues. The fundamental issue being addressed is the same, and it is this: Currently third-party C code can either be called quickly or have access to the callable object, not both. Both PEPs address this. I'll need to confirm that it won't paint us into a corner -- that there's a way to address all the issues in PEP 579 in the future. PEP 579 is mainly a list of supposed flaws with the 'builtin_function_or_method' class. The general thrust of PEP 579 seems to be that builtin-functions and builtin-methods should be more flexible and extensible than they are. I don't agree. If you want different behaviour, then use a different object. Don't try an cram all this extra behaviour into a pre-existing object. However, if we assume that we are talking about callables implemented in C, in general, then there are 3 key issues covered by PEP 579. 1. Inspection and documentation; it is hard for extensions to have docstrings and signatures. Worth addressing, but completely orthogonal to PEP 590. 2. Extensibility and performance; extensions should have the power of Python functions without suffering slow calls. Allowing the C code access to the callable object is a general solution to this problem. Both PEP 580 and PEP 590 do this. 3. Exposing the underlying implementation and signature of the C code, so that optimisers can avoid unnecessary boxing. This may be worth doing, but until we have an adaptive optimiser capable of exploiting this information, this is premature. Neither PEP 580 nor PEP 590 explicit allow or prevent this. The pre-PEP claims speedups of 2% in initial experiments, with expected overall performance gain of 4% for the standard benchmark suite. That's pretty big. That's because there is a lot of code around calls in CPython, and it has grown in a rather haphazard fashion. Victor's work to add the "FASTCALL" protocol has helped. PEP 590 seeks to formalise and extend that, so that it can be used more consistently and efficiently. As far as I can see, PEP 580 claims not much improvement in CPython, but rather large improvements for extensions (Mistune with Cython). Calls to and from extension code are slow because they have to use the `tp_call` calling convention (or lose access to the callable object). With a calling convention that does not have any special cases, extensions can be as fast as builtin functions. Both PEP 580 and PEP 590 attempt to do this, but PEP 590 is more efficient. The pre-PEP has a complication around offsetting arguments by 1 to allow bound methods forward calls cheaply. I fear that this optimizes for current usage with its limitations. It's optimising for the common case, while allowing the less common. Bound methods and classes need to add one additional argument. Other rarer cases, like `partial` may need to allocate memory, but can still add or remove any number of arguments. PEP 580's cc_parent allows bound methods to have access to the class, and through that, the module object where they are defined and the
Re: [Python-Dev] BDFL-Delegate appointments for several PEPs
On Mon, 25 Mar 2019 at 20:34, Cameron Simpson wrote: > Clearly the above needs to accomodate this, possibly with a fallback > guess. Is sniffing the end components of __file__ at all sane? ending in > idlelib/pyshell.py or pyshell.py? Or is that just getting baroque? > > I don't think these are strictly the same from some kind of purist > viewpoint: the path might be anything - _is_ it reasonable to suppose > that it has a module name (== importable/finding through the import > path)? Directly executing files from inside Python packages is explicitly unsupported, and nigh guaranteed to result in a broken import setup, as relative imports won't work, and absolute imports will most likely result in a second copy of the script module getting loaded. The problem is that __main__ always thinks it is a top-level module for directly executed scripts - it needs the package structure information from the "-m" switch to learn otherwise. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] BDFL-Delegate appointments for several PEPs
On 2019-03-27 14:50, Petr Viktorin wrote: The pre-PEP claims speedups of 2% in initial experiments, with expected overall performance gain of 4% for the standard benchmark suite. That's pretty big. I re-did my earlier benchmarks for PEP 580 and these are the results: https://gist.github.com/jdemeyer/f0d63be8f30dc34cc989cd11d43df248 In general, the PEP 580 timings seem slightly better than vanilla CPython, similar to what Mark got. I'm speculating that the speedup in both cases comes from the removal of type checks and dispatching depending on that, and instead using a single protocol that directly does what needs to be done. 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] BDFL-Delegate appointments for several PEPs
On Sun, Mar 24, 2019 at 4:22 PM Mark Shannon wrote: > > Hi Petr, > > Regarding PEPs 576 and 580. > Over the new year, I did a thorough analysis of possible approaches to > possible calling conventions for use in the CPython ecosystems and came > up with a new PEP. > The draft can be found here: > https://github.com/markshannon/peps/blob/new-calling-convention/pep-.rst > > I was hoping to profile a branch with the various experimental changes > cherry-picked together, but don't seemed to have found the time :( > > I'd like to have a testable branch, before formally submitting the PEP, > but I'd thought you should be aware of the PEP. > > Cheers, > Mark. Hello Mark, Thank you for letting me know! I wish I knew of this back in January, when you committed the first draft. This is unfair to the competing PEP, which is ready and was waiting for the new govenance. We have lost three months that could be spent pondering the ideas in the pre-PEP. Do you think you will find the time to piece things together? Is there anything that you already know should be changed? Do you have any comments on [Jeroen's comparison]? The pre-PEP is simpler then PEP 580, because it solves simpler issues. I'll need to confirm that it won't paint us into a corner -- that there's a way to address all the issues in PEP 579 in the future. The pre-PEP claims speedups of 2% in initial experiments, with expected overall performance gain of 4% for the standard benchmark suite. That's pretty big. As far as I can see, PEP 580 claims not much improvement in CPython, but rather large improvements for extensions (Mistune with Cython). The pre-PEP has a complication around offsetting arguments by 1 to allow bound methods forward calls cheaply. I fear that this optimizes for current usage with its limitations. PEP 580's cc_parent allows bound methods to have access to the class, and through that, the module object where they are defined and the corresponding module state. To support this, vector calls would need a two-argument offset. (That seems to illustrate the main difference between the motivations of the two PEPs: one focuses on extensibility; the other on optimizing existing use cases.) The pre-PEP's "any third-party class implementing the new call interface will not be usable as a base class" looks quite limiting. [Jeroen's comparison]: https://mail.python.org/pipermail/python-dev/2018-July/154238.html ___ 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] BDFL-Delegate appointments for several PEPs
On Sun, Mar 24, 2019 at 2:03 PM Terry Reedy wrote: > On 3/24/2019 8:21 AM, Nick Coghlan wrote: > > > We'll be announcing those appointments as we go, so I'm happy to > > report that I will be handling the BDFL-Delegate responsibilities for > > the following PEPs: > > Where do we discuss these? > Either as a topic on discuss.python.org or as a separate thread here on python-dev. -Brett > > If a delegate has a provisional view, it might help focus discussion if > that were known. > > > * PEP 499: Binding "-m" executed modules under their module name as > > well as `__main__` > > My brief response: +1 unless there is a good reason not. There have > been multiple double module problems reported on python-list and likely > stackoverflow. And would there be any impact on circular imports? > > -- > Terry Jan Reedy > > ___ > 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/brett%40python.org > ___ 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] BDFL-Delegate appointments for several PEPs
On 25Mar2019 03:52, Terry Reedy wrote:
On 3/25/2019 12:27 AM, Cameron Simpson wrote:
I was thinking about IDLE and its tangled web of circular inports,
but I am now convinced that this change will not affect it. Indeed,
idlelib/pyshell.py already implements idea of the proposal, ending
with
if __name__ == "__main__":
sys.modules['pyshell'] = sys.modules['__main__']
main()
After more investigation, I realized that to stop having duplicate
modulue:
1. The alias should be 'idlelib.pyshell', not 'pyshell', at least
when imports are all absolute.
The PEP499 patch effectively uses __main__.__spec__.name for the name
of the alias. Does that simplify your issue?
[...]
What about (untested):
if __name__ == '__main__':
if __spec__.name not in sys.modules:
sys.modules[__spec__.name] = sys.modules['__main__']
When I start pyshell in my master repository directory on windows with
python -m idlelib.pyshell
__spec__.name is 'idlelib.pyshell, which I currently hard-coded.
When I start with what should be equivalent
python f:/dev/3x/lib/idlelib/pyshell.py
__spec__ is None and __spec__.name an attribute error.
Um, yes. I presume that since no "import" has been done, there's no
import spec (.__spec__).
Clearly the above needs to accomodate this, possibly with a fallback
guess. Is sniffing the end components of __file__ at all sane? ending in
idlelib/pyshell.py or pyshell.py? Or is that just getting baroque?
I don't think these are strictly the same from some kind of purist
viewpoint: the path might be anything - _is_ it reasonable to suppose
that it has a module name (== importable/finding through the import
path)?
If I run python f:/dev/3x/lib/idlelib/pyshell.py, the PEP patch would
have to notice that pyshell is a module within idlelib and alias
'__main__' to 'idlelib.pyshell', not 'pyshell'. Would the same be
true if within-package import were all relative?
I think so because we're using .__spec__.name, which I though was
post import name resolution.
You must be doing something different when __spec__ is None ;-). I
tested the patch and it does not raise AttributeError with the command
above.
Indeed. I may have fudged a bit when I said "The PEP499 patch
effectively uses __main__.__spec__.name". It modifies runpy.py's
_run_module_as_main function, and that is called for the "python -m
module_name" invocation, so it can get the module spec because it has a
module name.
So the patch doesn't have to cope with __spec__ being None.
As you say, __spec__ is None for "python path/to/file.py" so __spec__
isn't any use there. Apologies.
[...]
Test 3, with the pyshell.py sys.modules assignment commented out:
[~/src/cpython-cs@github(git:PEP499-cs)]fleet*> PYTHONPATH=$PWD/Lib
./python.exe -i -m idlelib.pyshell
[...]
>>> sys.modules['__main__']
>>> sys.modules['pyshell']
Traceback (most recent call last):
File "", line 1, in
KeyError: 'pyshell'
>>> sys.modules['idlelib.pyshell']
>>> id(sys.modules['__main__'])
4552379336
>>> id(sys.modules['idlelib.pyshell'])
4552379336
Here we've got __main__ and idlelib.pyshell the same module and no
'pyshell' in sys.modules.
I don't think I understand your "relative import" scenario.
If files other that pyshell used relative 'import ./pyshell' instead
of absolute 'import idlelib.pyshell', would the sys.modules key still
be 'idlelib.pyshell' or 'pyshell'? Which is to ask, would the alias
needed to avoid a second pyshell module still be 'idlelib.pyshell' or
'pyshell'?
Ok.
As I understand it Python 3 imports are absolute: without a leading dot
a name is absolute, so "import pyshell" should install
sys.module['pyshell'] _provided_ that 'pyshell' can be found in the
module search path.
Conversely, an "import .pyshell" is an import relative to the current
module's package name, equivalent to an import of the absolute path
"package.name.pyshell", for whatever the package name is. So (a) you can
only import '.pyshell' from within a package containing a 'pyshell.py'
file and (b) you can't import import '.pyshell' if you're not in a
package.
I stuffed a "test2.py" into the local idlelib like this:
import sys
print("running", __file__, __name__)
print(repr(sorted(sys.modules)))
print(repr(sys.paht))
from pyshell import idle_showwarning
print(repr(sorted(sys.modules)))
and fiddled with the "from pyshell import idle_showwarning" line.
(I'm presuming this is what you have in mind, since "import ./pyshell"
elicits a syntax error.)
Using "./python.exe -m idlelib.test2":
Plain "pyshell" gets an ImportError - no such module.
Using ".pyshell" imports the pyshell module as "idlelib.pyshell" in
sys.modules.
Which was encouraging until I went "./python.exe Lib/idlelib/test2.py".
This puts Lib/idlelib (as an absolute path) at the start of sys.path.
A plain "pyshell" import works and installs sys.modules['pyshell'].
Re: [Python-Dev] BDFL-Delegate appointments for several PEPs
On 3/25/2019 12:27 AM, Cameron Simpson wrote:
On 24Mar2019 23:22, Terry Reedy wrote:
On 3/24/2019 10:01 PM, Terry Reedy wrote:
On 3/24/2019 7:00 PM, Cameron Simpson wrote:
Did you have a specific scenario in mind?
I was thinking about IDLE and its tangled web of circular inports,
but I am now convinced that this change will not affect it. Indeed,
idlelib/pyshell.py already implements idea of the proposal, ending with
if __name__ == "__main__":
sys.modules['pyshell'] = sys.modules['__main__']
main()
After more investigation, I realized that to stop having duplicate
modulue:
1. The alias should be 'idlelib.pyshell', not 'pyshell', at least when
imports are all absolute.
The PEP499 patch effectively uses __main__.__spec__.name for the name of
the alias. Does that simplify your issue?
The current PR is here if you want to look at it:
https://github.com/python/cpython/pull/12490
The new test passes on Win10.
2. It should be done at the top of the file, before the import of
modules that import pyshell.
Hmm, if PEP499 comes in you shouldn't need to do this at all. If PEP499
gets delayed or rejected I guess you're supporting this without it. Yes,
you'll want to do it before any other imports happen (well, as you say,
before any which import pyshell).
What about (untested):
if __name__ == '__main__':
if __spec__.name not in sys.modules:
When I start pyshell in my master repository directory on windows with
python -m idlelib.pyshell
__spec__.name is 'idlelib.pyshell, which I currently hard-coded.
When I start with what should be equivalent
python f:/dev/3x/lib/idlelib/pyshell.py
__spec__ is None and __spec__.name an attribute error.
sys.modules[__spec__.name] = sys.modules['__main__']
as a forward compatible setup?
If I run python f:/dev/3x/lib/idlelib/pyshell.py, the PEP patch would
have to notice that pyshell is a module within idlelib and alias
'__main__' to 'idlelib.pyshell', not 'pyshell'. Would the same be
true if within-package import were all relative?
I think so because we're using .__spec__.name, which I though was post
import name resolution.
You must be doing something different when __spec__ is None ;-). I
tested the patch and it does not raise AttributeError with the command
above.
Testing in my PEP499 branch:
Test 1:
[~/src/cpython-cs@github(git:PEP499-cs)]fleet*> ./python.exe -i
Lib/idlelib/pyshell.py
Traceback (most recent call last):
File "", line 1, in
ModuleNotFoundError: No module named 'run'
This is because of an obsolete 'command = ...' around 420. The if line
is correct always and the if/then not needed.
>>> sys.modules['__main__']
object at 0x1088e6040>)>
>>> sys.modules['pyshell']
object at 0x1088e6040>)>
>>> sys.modules['idlelib.pyshell']
'/Users/cameron/src/cpython-cs@github/Lib/idlelib/pyshell.py'>
So pyshell and idlelib.pyshell are distinct here.
I verified that the module was being executed twice by putting
print('running') at the top.
__main__ and pyshell
are the same module, courtesy of your sys.modules assignment at the
bottom of pyshell.py.
Obsolete and removed.
Test 3 below will be with that commented out.
Test 2:
[~/src/cpython-cs@github(git:PEP499-cs)]fleet*> PYTHONPATH=$PWD/Lib
./python.exe -i -m idlelib.pyshell
Traceback (most recent call last):
File "", line 1, in
ModuleNotFoundError: No module named 'run'
>>> sys.modules['__main__']
'/Users/cameron/src/cpython-cs@github/Lib/idlelib/pyshell.py'>
>>> sys.modules['pyshell']
'/Users/cameron/src/cpython-cs@github/Lib/idlelib/pyshell.py'>
>>> sys.modules['idlelib.pyshell']
'/Users/cameron/src/cpython-cs@github/Lib/idlelib/pyshell.py'>
>>> id(sys.modules['__main__'])
4551072712
>>> id(sys.modules['pyshell'])
4551072712
>>> id(sys.modules['idlelib.pyshell'])
4551072712
So this has __main__ and idlelib.pyshell the same module from the PEP499
patch and pyshell also the same from your sys.modules assignment.
Test 3, with the pyshell.py sys.modules assignment commented out:
[~/src/cpython-cs@github(git:PEP499-cs)]fleet*> PYTHONPATH=$PWD/Lib
./python.exe -i -m idlelib.pyshell
Traceback (most recent call last):
File "", line 1, in
ModuleNotFoundError: No module named 'run'
>>> sys.modules['__main__']
'/Users/cameron/src/cpython-cs@github/Lib/idlelib/pyshell.py'>
>>> sys.modules['pyshell']
Traceback (most recent call last):
File "", line 1, in
KeyError: 'pyshell'
>>> sys.modules['idlelib.pyshell']
'/Users/cameron/src/cpython-cs@github/Lib/idlelib/pyshell.py'>
>>> id(sys.modules['__main__'])
4552379336
>>> id(sys.modules['idlelib.pyshell'])
4552379336
Here we've got __main__ and idlelib.pyshell the same module and no
'pyshell' in sys.modules.
I don't think I understand your "relative import" scenario.
If files other
Re: [Python-Dev] BDFL-Delegate appointments for several PEPs
On 3/24/2019 10:01 PM, Terry Reedy wrote: On 3/24/2019 7:00 PM, Cameron Simpson wrote: Did you have a specific scenario in mind? I was thinking about IDLE and its tangled web of circular inports, but I am now convinced that this change will not affect it. Indeed, idlelib/pyshell.py already implements idea of the proposal, ending with if __name__ == "__main__": sys.modules['pyshell'] = sys.modules['__main__'] main() After more investigation, I realized that to stop having duplicate modulue: 1. The alias should be 'idlelib.pyshell', not 'pyshell', at least when imports are all absolute. 2. It should be done at the top of the file, before the import of modules that import pyshell. If I run python f:/dev/3x/lib/idlelib/pyshell.py, the PEP patch would have to notice that pyshell is a module within idlelib and alias '__main__' to 'idlelib.pyshell', not 'pyshell'. Would the same be true if within-package import were all relative? (It turns out that this fails for other reasons, which I am looking into. Since starting IDLE with pyshell once worked in the past, it appears to be because the startup command for run.py was outdated. Will fix. -- Terry Jan Reedy ___ 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] BDFL-Delegate appointments for several PEPs
On 3/24/2019 7:00 PM, Cameron Simpson wrote: On 24Mar2019 17:02, Terry Reedy wrote: On 3/24/2019 8:21 AM, Nick Coghlan wrote: * PEP 499: Binding "-m" executed modules under their module name as well as `__main__` My brief response: +1 unless there is a good reason not. There turn out to be some subtle side effects. The test suite turned up one (easily fixed) in pdb, but there are definitely some more things to investigate. Nick has pointed out pickle and the "python -i" option. I'm digging into these. (Naturally, I have _never_ before used the pdb or pickle modules, or the -i option :-) There have been multiple double module problems reported on python-list and likely stackoverflow. And would there be any impact on circular imports? Well, by binding the -m module to both __main__ and its name as denoted on the command line one circular import is directly short circuited. Aside from the -m module itself, I don't think there should be any other direct effect on circular imports. Did you have a specific scenario in mind? I was thinking about IDLE and its tangled web of circular inports, but I am now convinced that this change will not affect it. Indeed, idlelib/pyshell.py already implements idea of the proposal, ending with if __name__ == "__main__": sys.modules['pyshell'] = sys.modules['__main__'] main() (It turns out that this fails for other reasons, which I am looking into. The current recommendation is to start IDLE by runing any of __main__.py (via python -m idlelib), idle.py, idlew.py, or idle.bat.) -- Terry Jan Reedy ___ 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] BDFL-Delegate appointments for several PEPs
On 24Mar2019 17:02, Terry Reedy wrote: On 3/24/2019 8:21 AM, Nick Coghlan wrote: * PEP 499: Binding "-m" executed modules under their module name as well as `__main__` My brief response: +1 unless there is a good reason not. There turn out to be some subtle side effects. The test suite turned up one (easily fixed) in pdb, but there are definitely some more things to investigate. Nick has pointed out pickle and the "python -i" option. I'm digging into these. (Naturally, I have _never_ before used the pdb or pickle modules, or the -i option :-) There have been multiple double module problems reported on python-list and likely stackoverflow. And would there be any impact on circular imports? Well, by binding the -m module to both __main__ and its name as denoted on the command line one circular import is directly short circuited. Aside from the -m module itself, I don't think there should be any other direct effect on circular imports. Did you have a specific scenario in mind? Cheers, Cameron Simpson ___ 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] BDFL-Delegate appointments for several PEPs
On 3/24/2019 8:21 AM, Nick Coghlan wrote: We'll be announcing those appointments as we go, so I'm happy to report that I will be handling the BDFL-Delegate responsibilities for the following PEPs: Where do we discuss these? If a delegate has a provisional view, it might help focus discussion if that were known. * PEP 499: Binding "-m" executed modules under their module name as well as `__main__` My brief response: +1 unless there is a good reason not. There have been multiple double module problems reported on python-list and likely stackoverflow. And would there be any impact on circular imports? -- Terry Jan Reedy ___ 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] BDFL-Delegate appointments for several PEPs
On 2019-03-24 16:22, Mark Shannon wrote: The draft can be found here: https://github.com/markshannon/peps/blob/new-calling-convention/pep-.rst I think that this is basically a better version of PEP 576. The idea is the same as PEP 576, but the details are better. Since it's not fundamentally different from PEP 576, I think that this comparison still stands: https://mail.python.org/pipermail/python-dev/2018-July/154238.html ___ 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] BDFL-Delegate appointments for several PEPs
On 2019-03-24 16:22, Mark Shannon wrote: Hi Petr, Regarding PEPs 576 and 580. Over the new year, I did a thorough analysis of possible approaches to possible calling conventions for use in the CPython ecosystems and came up with a new PEP. The draft can be found here: https://github.com/markshannon/peps/blob/new-calling-convention/pep-.rst Thanks for that. Is this new PEP meant to supersede PEP 576? I'd like to have a testable branch, before formally submitting the PEP, but I'd thought you should be aware of the PEP. If you want to bring up this PEP now during the PEP 576/580 discussion, maybe it's best to formally submit it now? Having an official PEP number might simplify the discussion. If it turns out to be a bad idea after all, you can still withdraw it. In the mean time, I remind you that PEP 576 also doesn't have a complete reference implementation (the PEP links to a "reference implementation" but it doesn't correspond to the text of the PEP). 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] BDFL-Delegate appointments for several PEPs
Hi Petr, Regarding PEPs 576 and 580. Over the new year, I did a thorough analysis of possible approaches to possible calling conventions for use in the CPython ecosystems and came up with a new PEP. The draft can be found here: https://github.com/markshannon/peps/blob/new-calling-convention/pep-.rst I was hoping to profile a branch with the various experimental changes cherry-picked together, but don't seemed to have found the time :( I'd like to have a testable branch, before formally submitting the PEP, but I'd thought you should be aware of the PEP. Cheers, Mark. On 24/03/2019 12:21 pm, Nick Coghlan wrote: Hi folks, With the revised PEP 1 published, the Steering Council members have been working through the backlog of open PEPs, figuring out which ones are at a stage of maturity where we think it makes sense to appoint a BDFL-Delegate to continue moving the PEP through the review process, and eventually make the final decision on whether or not to accept or reject the change. We'll be announcing those appointments as we go, so I'm happy to report that I will be handling the BDFL-Delegate responsibilities for the following PEPs: * PEP 499: Binding "-m" executed modules under their module name as well as `__main__` * PEP 574: Pickle protocol 5 with out of band data I'm also pleased to report that Petr Viktorin has agreed to take on the responsibility of reviewing the competing proposals to improve the way CPython's C API exposes callables for direct invocation by third party low level code: * PEP 576: Exposing the internal FastCallKeywords convention to 3rd party modules * PEP 580: Revising the callable struct hierarchy internally and in the public C API * PEP 579: Background information for the problems the other two PEPs are attempting to address Regards, Nick. ___ 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
