[Python-Dev] Please merge : bpo-34848
Hi, The PR - https://github.com/python/cpython/pull/9877 has been approved by Raymond long ago. Please merge or comment if not mergeable. Best Regards, Srinivas Reddy Thatipathy 7768044110. ___ 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] Please merge : bpo-34848
Looks like the failure is due to absence of a News entry. Maybe add a "skip news" label if this doesn't need to be documented? Kind regards. Steve Holden On Fri, May 3, 2019 at 9:48 AM Srinivas Reddy Thatiparthy < thatiparthysreeni...@gmail.com> wrote: > Hi, >The PR - https://github.com/python/cpython/pull/9877 has been > approved by Raymond long ago. Please merge or comment if not mergeable. > > Best Regards, > Srinivas Reddy Thatipathy > 7768044110. > > ___ > 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/steve%40holdenweb.com > ___ 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] Please merge : bpo-34848
Yes, I agree. Please do as I do not have permission. Best Regards, Srinivas Reddy Thatipathy On Fri, 3 May 2019 at 16:52, Steve Holden wrote: > Looks like the failure is due to absence of a News entry. Maybe add a > "skip news" label if this doesn't need to be documented? > > Kind regards. > Steve Holden > > > On Fri, May 3, 2019 at 9:48 AM Srinivas Reddy Thatiparthy < > thatiparthysreeni...@gmail.com> wrote: > >> Hi, >>The PR - https://github.com/python/cpython/pull/9877 has been >> approved by Raymond long ago. Please merge or comment if not mergeable. >> >> Best Regards, >> Srinivas Reddy Thatipathy >> 7768044110. >> >> ___ >> 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/steve%40holdenweb.com >> > ___ 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] Please merge : bpo-34848
Hi Srinivas, I merged your obvious doc fix, thanks. Does someone know how I can list pull requests which has been approved but not merged yet? Victor Le vendredi 3 mai 2019, Srinivas Reddy Thatiparthy < thatiparthysreeni...@gmail.com> a écrit : > Hi, >The PR - https://github.com/python/cpython/pull/9877 has been approved by Raymond long ago. Please merge or comment if not mergeable. > Best Regards, > Srinivas Reddy Thatipathy > 7768044110. > > -- Night gathers, and now my watch begins. It shall not end until my death. ___ 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] Please merge : bpo-34848
On 03. 05. 19 14:24, Victor Stinner wrote: Does someone know how I can list pull requests which has been approved but not merged yet? Add review:approved to the search filed. https://github.com/python/cpython/pulls?q=is%3Apr+is%3Aopen+review%3Aapproved Or click on **Reviews** in the top bar and select what you like. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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] Please merge : bpo-34848
The "awaiting merge" was originally created to help with this. On Fri., May 3, 2019, 08:51 Miro Hrončok, wrote: > On 03. 05. 19 14:24, Victor Stinner wrote: > > Does someone know how I can list pull requests which has been approved > but not > > merged yet? > > Add review:approved to the search filed. > > > https://github.com/python/cpython/pulls?q=is%3Apr+is%3Aopen+review%3Aapproved > > Or click on **Reviews** in the top bar and select what you like. > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > ___ > 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
[Python-Dev] PEP 580/590 proposals summary
Hello all, If we want to have a chance of implementing PEP 580/590 in Python 3.8, we shouldn't wait too long to make a decision on which proposal to accept. As a summary, below I'll write the four proposals together with a star "score" for 3 criteria (there is no obvious best proposal, all have advantages and disadvantages): - complexity: more stars is a protocol which is simpler to document and understand. - implementation: more stars is a simpler implementation of CPython (not just of the protocol itself, but also the code using the protocol). - performance: more stars is better performance for *existing* code. I'm using a minimum of 3 stars here, since the difference is not that big between the proposals. Criteria that I am NOT considering: - The performance for *new* code or the performance of wrappers generated by Argument Clinic: all proposals score excellent here. - Complexity of implementations of external classes: this is hard to judge, since that depends a lot on what those external classes (outside of CPython) want to do. - The work to implement the proposal in CPython: this is a one-time only thing that I'm volunteering to do anyway. - Extensibility of the protocol: first of all, it's hard to define what this means exactly. Second, using Petr's idea of putting the flags inside the instance, every proposal becomes extensible at little cost. Proposals: (A) PEP 580 complexity: * implementation: * performance:* (B) compromise: PEP 580 with a single calling convention complexity: *** implementation: performance: (C) PEP 590 with a single bound method class complexity: * implementation: *** performance:*** (D) PEP 590 complexity: * implementation: * performance: I consider Petr's proposal (a more extensible variant of PEP 590 with flags inside the instance) a minor variation of PEP 590 for this purpose and no need to score it differently than "plain" PEP 590. I tried to do this as unbiased as possible, even though I must admit that this is not really possible. I'm considering not just the PEP and the existing implementation as written, but also ideas that haven't been implemented yet such as: - proposals (A)-(C): rationalization of classes, in particular having a single class for bound methods (just like in PyPy). - proposals (B)-(D): Mark Shannon's idea of having a dedicated vectorcall wrapper for each calling convention (one for METH_O, one for METH_VARARGS|METH_KEYWORDS, ...). - using the protocol also for slot wrappers like object.__eq__ I'm NOT considering Petr's proposal of removing support for other calling conventions like METH_VARARGS because that won't happen any time soon. Cheers, 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] Please merge : bpo-34848
On 2019-05-03 14:24, Victor Stinner wrote: Hi Srinivas, I merged your obvious doc fix, thanks. Can you please do the same for https://github.com/python/cpython/pull/12784 ___ 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] Location of CI for Windows Embeddable Distro
Ok, disregard previous message. I fixed the PYTHONPATH in my command and the .pyc files and . I also saw that python36._pth is specifically only supported by windows. Now i'm moved on to the following error: zipimport.ZipImportError: can't decompress data; zlib not available I'm on Ubuntu. I've definitely got zlib1g-dev package installed, and I've recompiled a number of times trying to get it to work. I've tried Ubuntu 16 and 18. Is this just a limitation on linux? Gerald R. Wiltse jerrywil...@gmail.com On Thu, May 2, 2019 at 4:29 PM Gerald Wiltse wrote: > Just an update based on testing. If I zip the modules up into > python36.zip (whether in .py or .pyc form) the linux binary does not find > them. If I copy them into the embedded root, alongside the python > executable, it finds them as expected. > > This just makes it seem more like an issue where Linux binary does not > respect .zip file as a source of modules. > > Gerald R. Wiltse > jerrywil...@gmail.com > > > > On Thu, May 2, 2019 at 2:56 PM Gerald Wiltse > wrote: > >> With minimal patching of tools/msi/make_zip.py, I was able to create an >> equivalent zip package on Linux. It doesn't work out of the box of >> course. I had to do two commands >> >> My biggest concern is that even if the layout is "correct" on linux, the >> python runtime might not actually support being run like this on Linux. >> Perhaps the code for using python36.zip as a landmark and source of modules >> is only implemented on Windows. Do you know if that is the case? >> >> tmp$ export LD_LIBRARY_PATH=$(pwd) >> tmp$ export PYTHONHOME=$(pwd) >> tmp$ export PYTHONPATH=$(pwd) >> tmp$ ./python >> Fatal Python error: Py_Initialize: Unable to get the locale encoding >> ModuleNotFoundError: No module named 'encodings' >> >> Current thread 0x7fdde9eb1680 (most recent call first): >> Aborted (core dumped) >> >> Here's the full directory structure, error, and patch I created. Any >> additional feedback would be great. >> >> https://gist.github.com/solvingj/87305e0f70e14d738d6989ba2f41352f >> >> Gerald R. Wiltse >> jerrywil...@gmail.com >> >> >> >> On Thu, May 2, 2019 at 11:24 AM Gerald Wiltse >> wrote: >> >>> I've successfully automated the build of the embedded zip on Windows for >>> 3.6 on my internal CI using tools/msi script. >>> >>> Moving onto linux, can you please summarize the primary >>> challenges/differences for creating the embeddable zip for linux? >>> >>> Gerald R. Wiltse >>> jerrywil...@gmail.com >>> >>> >>> >>> On Wed, May 1, 2019 at 2:47 PM Gerald Wiltse >>> wrote: >>> Yes, I'll help with this, and I try to get signed up with an account for the issue tracker ASAP. I've just started trying to build create the embeddable package for windows locally (all from source). Once I have that automated, I'll take a naive stab at the Linux layout. I'm sure i'll soon hit the additional complications you're talking about and come back to you with questions. Gerald R. Wiltse jerrywil...@gmail.com On Wed, May 1, 2019 at 1:57 PM Steve Dower wrote: > On 01May2019 1305, Gerald Wiltse wrote: > > That does help, thanks so much for the fast response! I now see how > > it's executed on Azure pipelines also, so that should be enough for > me > > to reverse engineer the rest. > > > > Followup questions if you have time: > > 1. It seems that directory doesn't exist in the 3.6 branches/tags, > so it > > must have been done a different way back then. Do you think it's > > back-portable to 3.6? > > Yep, it should work with 3.6. There were scripts under Tools/msi back > then that did the same thing, but with the Store app I rewrote it to > be > more flexible. > > > 2. One of our objectives is to effectively create a nearly identical > > embeddable package for linux. Do you think the layout code is > generic > > enough to be modified to create a linux equivalent? > > Probably not, it's under the "PC" directory because it is entirely > CPython specific. > > I'd love to be able to have a similar embeddable distro for Linux (and > macOS), and I'll be investing some of my time in working towards this, > but it's far more complicated than simply laying out the right files. > If > you're interested in helping with this, then we're in the right place > to > discuss it, but we'll likely have to move to the issue tracker at some > point once we figure out who else wants/needs to be involved. > > > Obviously, there are many alternative methods and documents for > creating > > "embeddable" pythons on linux, but the windows package has all the > > characteristics we want, and of course we'd like our Windows and > Linux > > process build and packaging processes to be as similar as possible, > so > > it seems at
Re: [Python-Dev] Location of CI for Windows Embeddable Distro
I have it working on linux now. Is now a good time to open a ticket on Issue Tracker? Gerald R. Wiltse jerrywil...@gmail.com On Fri, May 3, 2019 at 11:55 AM Gerald Wiltse wrote: > Ok, disregard previous message. I fixed the PYTHONPATH in my command > and the .pyc files and . I also saw that python36._pth is specifically > only supported by windows. > > Now i'm moved on to the following error: > > zipimport.ZipImportError: can't decompress data; zlib not available > > I'm on Ubuntu. I've definitely got zlib1g-dev package installed, and I've > recompiled a number of times trying to get it to work. I've tried Ubuntu > 16 and 18. > > Is this just a limitation on linux? > > Gerald R. Wiltse > jerrywil...@gmail.com > > > > On Thu, May 2, 2019 at 4:29 PM Gerald Wiltse > wrote: > >> Just an update based on testing. If I zip the modules up into >> python36.zip (whether in .py or .pyc form) the linux binary does not find >> them. If I copy them into the embedded root, alongside the python >> executable, it finds them as expected. >> >> This just makes it seem more like an issue where Linux binary does not >> respect .zip file as a source of modules. >> >> Gerald R. Wiltse >> jerrywil...@gmail.com >> >> >> >> On Thu, May 2, 2019 at 2:56 PM Gerald Wiltse >> wrote: >> >>> With minimal patching of tools/msi/make_zip.py, I was able to create an >>> equivalent zip package on Linux. It doesn't work out of the box of >>> course. I had to do two commands >>> >>> My biggest concern is that even if the layout is "correct" on linux, the >>> python runtime might not actually support being run like this on Linux. >>> Perhaps the code for using python36.zip as a landmark and source of modules >>> is only implemented on Windows. Do you know if that is the case? >>> >>> tmp$ export LD_LIBRARY_PATH=$(pwd) >>> tmp$ export PYTHONHOME=$(pwd) >>> tmp$ export PYTHONPATH=$(pwd) >>> tmp$ ./python >>> Fatal Python error: Py_Initialize: Unable to get the locale encoding >>> ModuleNotFoundError: No module named 'encodings' >>> >>> Current thread 0x7fdde9eb1680 (most recent call first): >>> Aborted (core dumped) >>> >>> Here's the full directory structure, error, and patch I created. Any >>> additional feedback would be great. >>> >>> https://gist.github.com/solvingj/87305e0f70e14d738d6989ba2f41352f >>> >>> Gerald R. Wiltse >>> jerrywil...@gmail.com >>> >>> >>> >>> On Thu, May 2, 2019 at 11:24 AM Gerald Wiltse >>> wrote: >>> I've successfully automated the build of the embedded zip on Windows for 3.6 on my internal CI using tools/msi script. Moving onto linux, can you please summarize the primary challenges/differences for creating the embeddable zip for linux? Gerald R. Wiltse jerrywil...@gmail.com On Wed, May 1, 2019 at 2:47 PM Gerald Wiltse wrote: > Yes, I'll help with this, and I try to get signed up with an account > for the issue tracker ASAP. > > I've just started trying to build create the embeddable package for > windows locally (all from source). Once I have that automated, I'll take > a > naive stab at the Linux layout. I'm sure i'll soon hit the additional > complications you're talking about and come back to you with questions. > > Gerald R. Wiltse > jerrywil...@gmail.com > > > > On Wed, May 1, 2019 at 1:57 PM Steve Dower > wrote: > >> On 01May2019 1305, Gerald Wiltse wrote: >> > That does help, thanks so much for the fast response! I now see >> how >> > it's executed on Azure pipelines also, so that should be enough for >> me >> > to reverse engineer the rest. >> > >> > Followup questions if you have time: >> > 1. It seems that directory doesn't exist in the 3.6 branches/tags, >> so it >> > must have been done a different way back then. Do you think it's >> > back-portable to 3.6? >> >> Yep, it should work with 3.6. There were scripts under Tools/msi back >> then that did the same thing, but with the Store app I rewrote it to >> be >> more flexible. >> >> > 2. One of our objectives is to effectively create a nearly >> identical >> > embeddable package for linux. Do you think the layout code is >> generic >> > enough to be modified to create a linux equivalent? >> >> Probably not, it's under the "PC" directory because it is entirely >> CPython specific. >> >> I'd love to be able to have a similar embeddable distro for Linux >> (and >> macOS), and I'll be investing some of my time in working towards >> this, >> but it's far more complicated than simply laying out the right files. >> If >> you're interested in helping with this, then we're in the right place >> to >> discuss it, but we'll likely have to move to the issue tracker at >> some >> point once we figure out who else wants/needs
Re: [Python-Dev] Location of CI for Windows Embeddable Distro
Now that I have it working, I recall that the runtime challenge for a portable/embeddable distro on Linux is in the system configuration handling. This has always been a complicated fundamental behavior which has prevented or complicated many "portability" cases in the past. There are many projects which have managed to ship portable/relocatable python installations in the past. Maybe looking at them will be helpful in deciding how to deal with the situation here. Gerald R. Wiltse jerrywil...@gmail.com On Fri, May 3, 2019 at 1:02 PM Gerald Wiltse wrote: > I have it working on linux now. Is now a good time to open a ticket on > Issue Tracker? > > Gerald R. Wiltse > jerrywil...@gmail.com > > > > On Fri, May 3, 2019 at 11:55 AM Gerald Wiltse > wrote: > >> Ok, disregard previous message. I fixed the PYTHONPATH in my command >> and the .pyc files and . I also saw that python36._pth is specifically >> only supported by windows. >> >> Now i'm moved on to the following error: >> >> zipimport.ZipImportError: can't decompress data; zlib not available >> >> I'm on Ubuntu. I've definitely got zlib1g-dev package installed, and >> I've recompiled a number of times trying to get it to work. I've tried >> Ubuntu 16 and 18. >> >> Is this just a limitation on linux? >> >> Gerald R. Wiltse >> jerrywil...@gmail.com >> >> >> >> On Thu, May 2, 2019 at 4:29 PM Gerald Wiltse >> wrote: >> >>> Just an update based on testing. If I zip the modules up into >>> python36.zip (whether in .py or .pyc form) the linux binary does not find >>> them. If I copy them into the embedded root, alongside the python >>> executable, it finds them as expected. >>> >>> This just makes it seem more like an issue where Linux binary does not >>> respect .zip file as a source of modules. >>> >>> Gerald R. Wiltse >>> jerrywil...@gmail.com >>> >>> >>> >>> On Thu, May 2, 2019 at 2:56 PM Gerald Wiltse >>> wrote: >>> With minimal patching of tools/msi/make_zip.py, I was able to create an equivalent zip package on Linux. It doesn't work out of the box of course. I had to do two commands My biggest concern is that even if the layout is "correct" on linux, the python runtime might not actually support being run like this on Linux. Perhaps the code for using python36.zip as a landmark and source of modules is only implemented on Windows. Do you know if that is the case? tmp$ export LD_LIBRARY_PATH=$(pwd) tmp$ export PYTHONHOME=$(pwd) tmp$ export PYTHONPATH=$(pwd) tmp$ ./python Fatal Python error: Py_Initialize: Unable to get the locale encoding ModuleNotFoundError: No module named 'encodings' Current thread 0x7fdde9eb1680 (most recent call first): Aborted (core dumped) Here's the full directory structure, error, and patch I created. Any additional feedback would be great. https://gist.github.com/solvingj/87305e0f70e14d738d6989ba2f41352f Gerald R. Wiltse jerrywil...@gmail.com On Thu, May 2, 2019 at 11:24 AM Gerald Wiltse wrote: > I've successfully automated the build of the embedded zip on Windows > for 3.6 on my internal CI using tools/msi script. > > Moving onto linux, can you please summarize the primary > challenges/differences for creating the embeddable zip for linux? > > Gerald R. Wiltse > jerrywil...@gmail.com > > > > On Wed, May 1, 2019 at 2:47 PM Gerald Wiltse > wrote: > >> Yes, I'll help with this, and I try to get signed up with an account >> for the issue tracker ASAP. >> >> I've just started trying to build create the embeddable package for >> windows locally (all from source). Once I have that automated, I'll >> take a >> naive stab at the Linux layout. I'm sure i'll soon hit the additional >> complications you're talking about and come back to you with questions. >> >> Gerald R. Wiltse >> jerrywil...@gmail.com >> >> >> >> On Wed, May 1, 2019 at 1:57 PM Steve Dower >> wrote: >> >>> On 01May2019 1305, Gerald Wiltse wrote: >>> > That does help, thanks so much for the fast response! I now see >>> how >>> > it's executed on Azure pipelines also, so that should be enough >>> for me >>> > to reverse engineer the rest. >>> > >>> > Followup questions if you have time: >>> > 1. It seems that directory doesn't exist in the 3.6 branches/tags, >>> so it >>> > must have been done a different way back then. Do you think it's >>> > back-portable to 3.6? >>> >>> Yep, it should work with 3.6. There were scripts under Tools/msi >>> back >>> then that did the same thing, but with the Store app I rewrote it to >>> be >>> more flexible. >>> >>> > 2. One of our objectives is to effectively create a nearly >>> identical >>> > embeddable packa
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2019-04-26 - 2019-05-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: open7081 ( -2) closed 41454 (+52) total 48535 (+50) Open issues with patches: 2820 Issues opened (41) == #36356: Failure to build with address sanitizer https://bugs.python.org/issue36356 reopened by vstinner #36707: The "m" ABI flag of SOABI for pymalloc is no longer needed https://bugs.python.org/issue36707 reopened by ned.deily #36737: Warnings operate out of global runtime state. https://bugs.python.org/issue36737 opened by eric.snow #36738: Add 'array_hook' for json module https://bugs.python.org/issue36738 opened by matomatical #36739: "4.6. Defining Functions" should mention nonlocal https://bugs.python.org/issue36739 opened by pbhd0815 #36743: Docs: Descript __get__ signature defined differently across th https://bugs.python.org/issue36743 opened by jdufresne #36744: functools.singledispatch: Shouldn't require a positional argum https://bugs.python.org/issue36744 opened by KevinG #36746: Create test for fcntl.lockf() https://bugs.python.org/issue36746 opened by nanjekyejoannah #36748: Optimize textio write buffering https://bugs.python.org/issue36748 opened by inada.naoki #36749: PPC64 AIX 3.x: compilation issue, linker fails to locate symbo https://bugs.python.org/issue36749 opened by vstinner #36750: test_socket leaks file descriptors on macOS https://bugs.python.org/issue36750 opened by xtreak #36751: Changes in the inspect module for PEP 570 https://bugs.python.org/issue36751 opened by pablogsal #36752: test multiprocessing: test_rapid_restart() crash on AIX https://bugs.python.org/issue36752 opened by vstinner #36753: Python modules not linking to libpython causes issues for RTLD https://bugs.python.org/issue36753 opened by reimar #36754: Remove smart quotes in pydoc text https://bugs.python.org/issue36754 opened by steve.dower #36755: [2.7] test_httplib leaked [8, 8, 8] references with OpenSSL 1. https://bugs.python.org/issue36755 opened by vstinner #36756: tkinter tk.createcommand memory leak https://bugs.python.org/issue36756 opened by WKraus #36757: uuid constructor accept invalid strings (extra dash) https://bugs.python.org/issue36757 opened by Cédric Cabessa #36758: configured libdir not correctly passed to Python executable https://bugs.python.org/issue36758 opened by michael-o #36759: datetime: astimezone() results in OSError: [Errno 22] Invalid https://bugs.python.org/issue36759 opened by Snidhi #36760: subprocess.run fails with capture_output=True and stderr=STDOU https://bugs.python.org/issue36760 opened by Joe.Borg #36761: Extended slice assignment + iterable unpacking https://bugs.python.org/issue36761 opened by wim.glenn #36762: Teach "import *" to warn when overwriting globals or builtins https://bugs.python.org/issue36762 opened by rhettinger #36763: PEP 587: Rework initialization API to prepare second version o https://bugs.python.org/issue36763 opened by vstinner #36766: Typos in docs and code comments https://bugs.python.org/issue36766 opened by xtreak #36767: Segmentation fault when running c extension on macOS https://bugs.python.org/issue36767 opened by Senhui Guo #36768: distutils.util.convert_path mangles windows paths with forward https://bugs.python.org/issue36768 opened by LordAro #36769: doc Document that fnmatch.filter supports any kind of iterable https://bugs.python.org/issue36769 opened by adelfino #36770: stdlib - shutil.make_archive - add support for different ZIP c https://bugs.python.org/issue36770 opened by owenchia #36771: Feature Request: An option to os.walk() to return os.DirEntry https://bugs.python.org/issue36771 opened by apocalyptech #36772: Let lru_cache be used as a decorator with no arguments https://bugs.python.org/issue36772 opened by rhettinger #36773: Race condition during pickle.load() https://bugs.python.org/issue36773 opened by papad #36774: f-strings: Add a !d conversion for ease of debugging https://bugs.python.org/issue36774 opened by eric.smith #36777: unittest discover throws TypeError on empty packages https://bugs.python.org/issue36777 opened by xtreak #36778: test_site.StartupImportTests.test_startup_imports fails if def https://bugs.python.org/issue36778 opened by Paul Monson #36779: time.tzname returns empty string on Windows if default codepag https://bugs.python.org/issue36779 opened by Paul Monson #36780: Interpreter exit blocks waiting for futures of shut-down Threa https://bugs.python.org/issue36780 opened by hniksic #36781: Optimize sum() for bools https://bugs.python.org/issue36781 opened by serhiy.storchaka #36782: Add tests for the datetime C API https://bugs.python.org/issue36782 opened by p-ganssle #36783: No documentation for _FromXandFold C API functions https://bugs.python.org/issue36783
Re: [Python-Dev] PEP 574 ready for review
On Wed, 1 May 2019 12:49:24 -0700 Nick Coghlan wrote: > Thanks Antoine. > > As BDFL-Delegate I'm happy with this version of the PEP, so it's my > pleasure to accept it for inclusion in Python 3.8. Thank you Nick! The implementation has been posted for review at https://github.com/python/cpython/pull/7076 Regards Antoine. ___ 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] Unicode identifiers in test files?
Is there a policy against using Unicode identifiers in test files? As part of adding !d to f-strings, there's a code path that's only executed if the text of the expression is non-ascii. The easiest way to exercise it, and the way I found a bug, is by using an identifier with Unicode chars. I know we have a policy against this in Lib/, but what about Lib/test/? I could work around this with exec-ing some strings, but that seems like added confusion that I'd avoid with a real Unicode identifier. Eric ___ 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] Unicode identifiers in test files?
On Fri, May 3, 2019 at 10:46 PM Eric V. Smith wrote: > Is there a policy against using Unicode identifiers in test files? > > As part of adding !d to f-strings, there's a code path that's only > executed if the text of the expression is non-ascii. The easiest way to > exercise it, and the way I found a bug, is by using an identifier with > Unicode chars. I know we have a policy against this in Lib/, but what > about Lib/test/? > > I could work around this with exec-ing some strings, but that seems like > added confusion that I'd avoid with a real Unicode identifier. > At this point I'd just do it, make sure the file has an explicit coding utf-8 comment up top just so it is clear it is intentional but everything should be happy with it. -gps > > Eric > > ___ > 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/greg%40krypto.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] Unicode identifiers in test files?
On Fri, May 03, 2019 at 10:46:03PM -0400, Eric V. Smith wrote: > Is there a policy against using Unicode identifiers in test files? [...] > I could work around this with exec-ing some strings, but that seems like > added confusion that I'd avoid with a real Unicode identifier. "Look, that's why there's rules, understand? So that you *think* before you break 'em." -- Terry Pratchett, "The Thief Of Time" -- Steven ___ 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] Unicode identifiers in test files?
04.05.19 05:46, Eric V. Smith пише: Is there a policy against using Unicode identifiers in test files? As part of adding !d to f-strings, there's a code path that's only executed if the text of the expression is non-ascii. The easiest way to exercise it, and the way I found a bug, is by using an identifier with Unicode chars. I know we have a policy against this in Lib/, but what about Lib/test/? I could work around this with exec-ing some strings, but that seems like added confusion that I'd avoid with a real Unicode identifier. Could you use string literals with non-ascii characters? They are more used in tests. ___ 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
