[Python-Dev] RFC: PEP 608: Coordinated Python release
Hi, I just posted a new PEP for comments, please reply there, rather than by email: https://discuss.python.org/t/rfc-pep-608-coordinated-python-release/2539 PEP 608: Coordinated Python release https://www.python.org/dev/peps/pep-0608/ Abstract: Block a Python release until a compatible version of selected projects is available. The Python release manager can decide to release Python even if a project is not compatible, if they decide that the project is going to be fixed soon enough, or if the issue severity is low enough. Victor -- Night gathers, and now my watch begins. It shall not end until my death. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/C3KM3LZISKZOXA62OA5NSXREQ2MPDRON/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: RFC: PEP 608: Coordinated Python release
On 10/25/2019 07:25 AM, Victor Stinner wrote: I just posted a new PEP for comments, please reply there, rather than by email: https://discuss.python.org/t/rfc-pep-608-coordinated-python-release/2539 PEP 608: Coordinated Python release https://www.python.org/dev/peps/pep-0608/ Abstract: Block a Python release until a compatible version of selected projects is available. The Python release manager can decide to release Python even if a project is not compatible, if they decide that the project is going to be fixed soon enough, or if the issue severity is low enough. [replying here because not everybody uses discuss] -1000 We are not responsible for third-party projects, and allowing them to block our progress is counter-productive. -- ~Ethan~ ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/FELVCB36NNTMEKEN7MD2VM6IVFFPGJHB/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: RFC: PEP 608: Coordinated Python release
I think it is more important to have CI that clearly shows the impact of dev versions of the interpreter and core packages. Some of us in the Nixpkgs community had this idea for Python core packages as well (and potentially scientific computing packages, but that's out of scope here). This would need funding though https://discuss.python.org/t/funding-for-ci-for-integrating-development-versions-of-packages-and-interpreter-in-package-set/2540 . On Fri, Oct 25, 2019 at 4:29 PM Victor Stinner wrote: > Hi, > > I just posted a new PEP for comments, please reply there, rather than by > email: > https://discuss.python.org/t/rfc-pep-608-coordinated-python-release/2539 > > PEP 608: Coordinated Python release > https://www.python.org/dev/peps/pep-0608/ > > Abstract: > > Block a Python release until a compatible version of selected projects > is available. > > The Python release manager can decide to release Python even if a > project is not compatible, if they decide that the project is going to > be fixed soon enough, or if the issue severity is low enough. > > Victor > -- > Night gathers, and now my watch begins. It shall not end until my death. > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/C3KM3LZISKZOXA62OA5NSXREQ2MPDRON/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/H3C6PTOJBAZG5OGOFC6IRQO6B4OPQFLF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: RFC: PEP 608: Coordinated Python release
On Fri, 25 Oct 2019 at 16:16, Freddy Rietdijk wrote: > > I think it is more important to have CI that clearly shows the impact of dev > versions of the interpreter and core packages. Some of us in the Nixpkgs > community had this idea for Python core packages as well (and potentially > scientific computing packages, but that's out of scope here). This would need > funding though > https://discuss.python.org/t/funding-for-ci-for-integrating-development-versions-of-packages-and-interpreter-in-package-set/2540. Agreed - I would consider having some sort of integration testing for core Python beta and various "important" packages to be a *far* better investment here. As you say, though, it's a big enough piece of work that it probably requires funding in some form. It's also worth noting that even with pre-release testing, there's still the non-trivial problem of getting any necessary fixes implemented and co-ordinated. That's a people-management issue, though, and IMO needs handling flexibly and in a way that's sympathetic to the fact that most of the projects involved are volunteer-based and resource starved. One of my biggest reservations about Victor's proposal is that it's basically removing flexibility and demanding extra testing, with little or no explanation of how we'd make that sustainable. Paul ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/Y2O255G4LRGZH656IUZ2R5GPO7NY2O4G/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Helpers for dynamic bytecode generation
@jjevnik -- Oops! I meant to send it there and sent it here by mistake. But thank you, everyone, for the recommendations! I'll check them all out and (mercifully) will probably not try to write this from scratch. On Thu, Oct 24, 2019 at 11:05 PM Brandt Bucher wrote: > Interesting that you bring this up. Just earlier this week I published the > first version of a new package that lets you write compiled bytecode > instructions inline with pure-Python syntax. The code's still a bit messy, > being only a week old and all, but it works as advertised for CPython 3.6.2 > through 3.9.0a0, and even includes neat features like labeled jumps, unused > name/constant removal, stack size adjustments, etc... Perhaps it'll be > useful to you (or at least you'll find it interesting): > https://github.com/brandtbucher/hax > > Victor's Stinner's Bytecode package (already mentioned) is surely better > for *dynamic* generation... I've never used it personally, but it looks > great. > > Definitely not for the faint of heart, though! ;) > > Brandt > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/PAQUZZ4MHZ6TJFIBNCPZGZBW6DOZFUJG/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/YOQT3QSXUY3TI3FXOSHLRY24GJBJHLWG/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2019-10-18 - 2019-10-25)
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:
open7066 ( -8)
closed 43274 (+79)
total 50340 (+71)
Open issues with patches: 2793
Issues opened (51)
==
#30064: BaseSelectorEventLoop.sock_{recv,sendall}() don't remove their
https://bugs.python.org/issue30064 reopened by yselivanov
#38092: environment variables not passed correctly using new virtualen
https://bugs.python.org/issue38092 reopened by eryksun
#38519: Internal include files missing on Windows
https://bugs.python.org/issue38519 opened by steve.dower
#38520: There is no proper way to know if a process is the main one
https://bugs.python.org/issue38520 opened by Delgan
#38522: Py_USING_MEMORY_DEBUGGER is referenced in docs but not present
https://bugs.python.org/issue38522 opened by Sümer.Cip
#38523: ignore_dangling_symlinks in shutil.copytree does not apply rec
https://bugs.python.org/issue38523 opened by veaviticus
#38524: functools.cached_property is not supported for setattr
https://bugs.python.org/issue38524 opened by hongweipeng
#38526: zipfile.Path has the wrong method name
https://bugs.python.org/issue38526 opened by tritium
#38527: configure script fails to detect "float word ordering" on Sola
https://bugs.python.org/issue38527 opened by wiggin15
#38529: Python 3.8 improperly warns about closing properly closed stre
https://bugs.python.org/issue38529 opened by Ron Frederick
#38530: Offer suggestions on AttributeError
https://bugs.python.org/issue38530 opened by pablogsal
#38532: Missing decrefs in the _ctypes module
https://bugs.python.org/issue38532 opened by ZackerySpytz
#38533: v3.7.5 py script run ok with python.exe but not pythonw.exe (p
https://bugs.python.org/issue38533 opened by 4evermaat
#38534: Version 3.8.0 has released with a wrong MS KB number reference
https://bugs.python.org/issue38534 opened by seahoh
#38535: Incorrect col_offset for decorators with zero arguments (empty
https://bugs.python.org/issue38535 opened by alexmojaki
#38536: Trailing space in formatted currency with international=True a
https://bugs.python.org/issue38536 opened by Jonas Aschenbrenner
#38538: dictobject dictviews don't return NotImplemented for unrecogni
https://bugs.python.org/issue38538 opened by mdk
#38541: Performance degradation of attribute accesses in Python 3.7.4
https://bugs.python.org/issue38541 opened by ttrd
#38544: test_venv: test_isolation() failed on AMD64 Windows7 SP1 3.x:
https://bugs.python.org/issue38544 opened by vstinner
#38546: test_concurrent_futures: reap_children() warnings on RHEL7 and
https://bugs.python.org/issue38546 opened by vstinner
#38547: test_pty fails when using setsid()
https://bugs.python.org/issue38547 opened by vstinner
#38549: Compiler build paths and related environment variables are ign
https://bugs.python.org/issue38549 opened by Alex Grund
#38550: hashlib missing algorithms
https://bugs.python.org/issue38550 opened by floppymaster
#38552: Colored Prompt broken in REPL in Windows in 3.8
https://bugs.python.org/issue38552 opened by MinchinWeb
#38553: Document functools.cached_property supports value updating and
https://bugs.python.org/issue38553 opened by Epic_Wink
#38554: A fatal error in test_descr
https://bugs.python.org/issue38554 opened by ZackerySpytz
#38557: PyTuple_GetSlice docs minor inaccuracy
https://bugs.python.org/issue38557 opened by wim.glenn
#38558: Data Structures documentation out of sync with new Walrus oper
https://bugs.python.org/issue38558 opened by Matt Ward
#38560: Allow iterable argument unpacking after a keyword argument?
https://bugs.python.org/issue38560 opened by brandtbucher
#38561: multiprocessing.Queue fails intermittently with "Broken pipe"
https://bugs.python.org/issue38561 opened by Samuel Grayson
#38564: test_asyncio: test_run_coroutine_threadsafe_with_timeout() has
https://bugs.python.org/issue38564 opened by vstinner
#38565: Expose the value passed of typed passed to functools.lru_cache
https://bugs.python.org/issue38565 opened by Scott Sanderson2
#38566: Description of '\w' behavior is vague in `re` documentation
https://bugs.python.org/issue38566 opened by snoopjedi
#38567: urllib.parse.unquote_plus raises incorrect error message when
https://bugs.python.org/issue38567 opened by stein-k
#38569: Unknown distribution option: 'license_files'
https://bugs.python.org/issue38569 opened by Marco Sulla
#38570: Shlex does not parse commands containing single quotes correct
https://bugs.python.org/issue38570 opened by timonegk
#38571: Segfault with StopIteration
https://bugs.python.org/issue38571 opened by kchen
#38572: Misleading AttributeError accessing fileno attribute in tarfil
https://bugs.python.org/issue38572 opened by xtreak
#38573: Not Implemented Error in stdLib HTMLParser
https://bugs.py
[Python-Dev] Re: RFC: PEP 608: Coordinated Python release
I replied at https://discuss.python.org/t/rfc-pep-608-coordinated-python-release/2539/9 I would prefer to not split the discussion. I understood that discuss.python.org is now preferred to discuss PEPs. And I don't want to discuss here where PEPs should be discussed :-) Victor Le ven. 25 oct. 2019 à 17:37, Paul Moore a écrit : > > On Fri, 25 Oct 2019 at 16:16, Freddy Rietdijk wrote: > > > > I think it is more important to have CI that clearly shows the impact of > > dev versions of the interpreter and core packages. Some of us in the > > Nixpkgs community had this idea for Python core packages as well (and > > potentially scientific computing packages, but that's out of scope here). > > This would need funding though > > https://discuss.python.org/t/funding-for-ci-for-integrating-development-versions-of-packages-and-interpreter-in-package-set/2540. > > Agreed - I would consider having some sort of integration testing for > core Python beta and various "important" packages to be a *far* better > investment here. As you say, though, it's a big enough piece of work > that it probably requires funding in some form. > > It's also worth noting that even with pre-release testing, there's > still the non-trivial problem of getting any necessary fixes > implemented and co-ordinated. That's a people-management issue, > though, and IMO needs handling flexibly and in a way that's > sympathetic to the fact that most of the projects involved are > volunteer-based and resource starved. > > One of my biggest reservations about Victor's proposal is that it's > basically removing flexibility and demanding extra testing, with > little or no explanation of how we'd make that sustainable. > > Paul -- Night gathers, and now my watch begins. It shall not end until my death. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/4BL2545ZIOZP6D4C7YXICYLWCJUC4BQF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Helpers for dynamic bytecode generation
I think this probably belongs on python-list instead of python-dev because python-dev is for development _of_ python, not _with_ python. To answer your question though, there are a few tools that do this: - https://github.com/vstinner/bytecode - https://github.com/ll/codetransformer I am one of the authors of codetransformer, so I am more familiar with how to use that to generate bytecode, but the bytecode project may be easier for your use case. On Thu, Oct 24, 2019 at 8:59 PM Yonatan Zunger wrote: > Hi everyone, > > I've found myself recently writing Python code that dynamically generates > bytecode.¹ I now have yet another case where I'm having to do this, in > which my nice situation of being able to easily precompute all the jump > addresses no longer holds. So I'm starting to write a helper to make it > easy to write bytecode from Python, with its basic API calls being > write(opcode, arg) and nextLine(optional label). The argument can be an > int, name, local name, constant, label, etc., depending on the opcode, and > it maintains all the appropriate tables and finally dumps a code object at > the end. > > All of which is well and good and makes life much easier, but... I am > *not* looking forward to writing the logic that basically duplicates that > of assemble() in compile.c, of splitting all of this into basic blocks and > computing the correct jump positions and so on before finally dumping out > the bytecode. > > Has anyone already done this that people know of? (Searching the > Internetz didn't turn anything up) Failing that, to what extent is it > reasonable to either consider assemble() as some kind of sane API point > into compile.c, and/or add some new API in compile.h which implements all > of the stuff described above in C? > > (I'm fully expecting the answer to these latter questions to be "you have > got to be kidding me," but figured it was wiser to check than to reinvent > this particular wheel if it isn't necessary) > > Yonatan > > > > ¹ Not out of masochism, in case you're wondering; there was a real use > case. A storage system would receive a read request that specified a bunch > of (key, condition) pairs, where conditions where either return any value, > return an exact value, or return values in a range. It would then receive > between 1 and 1M (depending on the request parameters) candidate cells from > the underlying storage layers, each of which had a tuple of bytes as its > actual key values; it had to compare each of those tuples against the > request parameters, and yield the values which matched. Because it's an > inner loop and can easily be called 1M times, doing this in pure Python > slows things down by a lot. Because it's also only called once, doing some > really expensive overhead like synthesizing Python code and calling > compile() on it would also slow things down a lot. But converting a bunch > of (key, condition) pairs to a really efficient function from tuples of > bytes to bools was pretty easy. > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/E57DTM65LFEROFZLHKRV442JPPFAWNJU/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/TF5NLPS5DQVR3N75VHIXOGSK5APZMLGK/ Code of Conduct: http://python.org/psf/codeofconduct/
