[Python-Dev] Azure Pipelines PR: Unresponsive agent
In a recent PR (https://github.com/python/cpython/pull/18057), I received the following error message in the Azure Pipelines build results: ##[error]We stopped hearing from agent Azure Pipelines 5. Verify the agent machine is running and has a healthy network connection. Anything that terminates an agent process, starves it for CPU, or blocks its network access can cause this error. For more information, see: https://go.microsoft.com/fwlink/?linkid=846610 Build: https://dev.azure.com/Python/cpython/_build/results?buildId=57319=results Is there something on our end we can do to bring the agent back online, or should I simply wait a while and then try to restart the PR checks? Normally I'd avoid doing that, but in this case it's entirely unrelated to the PR. ___ 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/2NSPJUEWULTLLALR3HY3H2PRYAUT474C/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Request to postpone some Python 3.9 incompatible changes to Python 3.10
On 2020-01-31 19:58, Ethan Furman wrote: On 01/31/2020 10:47 AM, Mike Miller wrote: On 2020-01-23 07:20, Victor Stinner wrote: Python 3.9 introduces many small incompatible changes which broke tons There's a well-known and established way of signaling breaking changes in software platforms—it is to increment the major version number. Rather than debating the merits of breaking code on 3.9 or 3.10, wouldn't it make more sense to do it in a Python 4.0 instead? I've gotta say, I like that plan. Instead of going to x.10, go to x+1.0. Every ten years we bump the major version and get rid of all the deprecations. It has a certain appeal for me too. ___ 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/Q24LBBZ4P2PAUBU5B2K7HNXP3HJXFBEP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Maintenance of multiprocessing module: there are a few stalled issues/patches
On 1/31/2020 1:27 PM, mailer@app.tempr.email wrote: Couldn't help but notice that there are quite a few stalled issues/patches, some of them for years even. :-/ So I thought, it might help to bump them here on the mailing list. https://bugs.python.org/issue28053 https://github.com/python/cpython/pull/9959 https://github.com/python/cpython/pull/15058 https://bugs.python.org/issue30256 https://github.com/python/cpython/pull/4819 https://github.com/python/cpython/pull/16341 https://bugs.python.org/issue31171 https://github.com/python/cpython/pull/3054 https://github.com/python/cpython/pull/10563 https://github.com/python/cpython/pull/13353 https://bugs.python.org/issue35727 https://github.com/python/cpython/pull/11538 Did you help move the issues forward by reviewing and testing the patches, or otherwise commenting? If the multiple PRs on an issue are either/or, which seems better? -- Terry Jan Reedy ___ 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/K4CHLCXROCWBP3QQ35KUGLOBKHOM3WCB/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Request to postpone some Python 3.9 incompatible changes to Python 3.10
On 01/31/2020 10:47 AM, Mike Miller wrote: On 2020-01-23 07:20, Victor Stinner wrote: Python 3.9 introduces many small incompatible changes which broke tons There's a well-known and established way of signaling breaking changes in software platforms—it is to increment the major version number. Rather than debating the merits of breaking code on 3.9 or 3.10, wouldn't it make more sense to do it in a Python 4.0 instead? I've gotta say, I like that plan. Instead of going to x.10, go to x+1.0. Every ten years we bump the major version and get rid of all the deprecations. -- ~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/FBRKF3UKABFHEQYSFJSM6ED2QQSBK6DC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Request to postpone some Python 3.9 incompatible changes to Python 3.10
On 2020-01-23 07:20, Victor Stinner wrote: > Python 3.9 introduces many small incompatible changes which broke tons There's a well-known and established way of signaling breaking changes in software platforms—it is to increment the major version number. Rather than debating the merits of breaking code on 3.9 or 3.10, wouldn't it make more sense to do it in a Python 4.0 instead? Well, either of these strategies sound logical to me: - Python 4.0 with removal of all of the Python 3-era deprecations - Continuing Python 3.1X with no breaks In other words, we should keep compatibility, or not. In any case, from the looks of it these will be tiny breaks compared to the Unicode transition. Cheers, -Mike ___ 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/OUHSUXWDWQ2TL7ZESB5WODLNHKMBZHYH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Maintenance of multiprocessing module: there are a few stalled issues/patches
Couldn't help but notice that there are quite a few stalled issues/patches, some of them for years even. :-/ So I thought, it might help to bump them here on the mailing list. https://bugs.python.org/issue28053https://github.com/python/cpython/pull/9959https://github.com/python/cpython/pull/15058https://bugs.python.org/issue30256https://github.com/python/cpython/pull/4819https://github.com/python/cpython/pull/16341https://bugs.python.org/issue31171https://github.com/python/cpython/pull/3054https://github.com/python/cpython/pull/10563https://github.com/python/cpython/pull/13353https://bugs.python.org/issue35727https://github.com/python/cpython/pull/11538 ___ 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/MFAZVOP2CQWJ7F2WEEAFYCFHHNJBSFSG/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2020-01-24 - 2020-01-31)
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:
open7300 (+15)
closed 43962 (+52)
total 51262 (+67)
Open issues with patches: 2858
Issues opened (56)
==
#36051: Drop the GIL during large bytes.join operations?
https://bugs.python.org/issue36051 reopened by skip.montanaro
#39350: Remove deprecated fractions.gcd()
https://bugs.python.org/issue39350 reopened by mark.dickinson
#39391: Nondeterministic Pydoc output on functions that have functions
https://bugs.python.org/issue39391 reopened by peteroupc
#39435: pickle: inconsistent arguments pickle.py vs _pickle.c vs docs
https://bugs.python.org/issue39435 reopened by pitrou
#39445: h5py not playing nicely with subprocess and mpirun
https://bugs.python.org/issue39445 opened by Rafael Laboissière
#39447: imaplib documentation claims that commands return a string, bu
https://bugs.python.org/issue39447 opened by dkg
#39448: Add regen-frozen makefile target
https://bugs.python.org/issue39448 opened by nascheme
#39450: unittest TestCase shortDescription does not strip whitespace
https://bugs.python.org/issue39450 opened by scirelli
#39451: enum.Enum reference count leaks
https://bugs.python.org/issue39451 opened by dan.g...@gmail.com
#39452: Improve the __main__ module documentation
https://bugs.python.org/issue39452 opened by maggyero
#39453: Use-after-free in list contain
https://bugs.python.org/issue39453 opened by corona10
#39454: when \\u in byte_string ,byte_string.decode('raw_unicode_escap
https://bugs.python.org/issue39454 opened by yayiba1223
#39456: Make IDLE calltip tests work when there are no docstrings
https://bugs.python.org/issue39456 opened by terry.reedy
#39457: Add an autocommit property to sqlite3.Connection with a PEP 24
https://bugs.python.org/issue39457 opened by maggyero
#39460: test_zipfile: test_add_file_after_2107() sometimes fails on Fe
https://bugs.python.org/issue39460 opened by vstinner
#39461: [RFE] os.environ should support Path-like values, like subproc
https://bugs.python.org/issue39461 opened by Antony.Lee
#39462: DataClass typo-unsafe attribute creation & unexpected behaviou
https://bugs.python.org/issue39462 opened by marcelpvisser
#39463: ast.Constant, bytes, and ast.unparse
https://bugs.python.org/issue39463 opened by Tal Ben-Nun
#39464: Allow translating argparse error messages
https://bugs.python.org/issue39464 opened by DjMorgul
#39465: Design a subinterpreter friendly alternative to _Py_IDENTIFIER
https://bugs.python.org/issue39465 opened by ncoghlan
#39467: Allow to deprecate CLI arguments in argparse
https://bugs.python.org/issue39467 opened by 4383
#39468: Improved the site module's permission handling while writing .
https://bugs.python.org/issue39468 opened by opensource-assist
#39469: Support for relative home path in pyvenv.cfg
https://bugs.python.org/issue39469 opened by Jeff.Edwards
#39470: Indicate that os.makedirs is equivalent to Path.mkdir
https://bugs.python.org/issue39470 opened by nanjekyejoannah
#39471: Meaning and clarification of PyBuffer_Release()
https://bugs.python.org/issue39471 opened by seberg
#39472: IDLE: improve handling of int entry in settings dialog
https://bugs.python.org/issue39472 opened by terry.reedy
#39473: Enable import behavior consistency option
https://bugs.python.org/issue39473 opened by bluelantern
#39474: col_offset for parenthesized expressions looks weird
https://bugs.python.org/issue39474 opened by BTaskaya
#39475: window.getmaxyx() doesn't return updated height when window is
https://bugs.python.org/issue39475 opened by nova
#39477: multiprocessing Pool maxtasksperchild=0 raises exception with
https://bugs.python.org/issue39477 opened by jeyekomon
#39479: [RFE] Add math.lcm() function: Least Common Multiple
https://bugs.python.org/issue39479 opened by Ananthakrishnan
#39480: referendum reference is needlessly annoying
https://bugs.python.org/issue39480 opened by diziet
#39481: Implement PEP 585 (Type Hinting Generics In Standard Collectio
https://bugs.python.org/issue39481 opened by gvanrossum
#39482: Write 2to3 fixer for collections.abc imports
https://bugs.python.org/issue39482 opened by opoplawski
#39483: Proposial add loop parametr to run in asyncio
https://bugs.python.org/issue39483 opened by heckad
#39484: time_ns() and time() cannot be compared on windows
https://bugs.python.org/issue39484 opened by vxgmichel
#39486: bug in %-formatting in Python, related to escaped %-characters
https://bugs.python.org/issue39486 opened by Carl.Friedrich.Bolz
#39488: test_largefile: TestSocketSendfile.test_it() uses too much dis
https://bugs.python.org/issue39488 opened by vstinner
#39489: Remove COUNT_ALLOCS special build
https://bugs.python.org/issue39489 opened by vstinner
#39490: Python Uninstaller
[Python-Dev] Limited API, MetaClasses, and ExtensionMetaClasses
Hi all, I may be thinking in the wrong direction, but right now `PyType_Type.tp_new` will resolves the `metaclass` from the bases and call: type = (PyTypeObject *)metatype->tp_alloc(metatype, nslots); where `metatype` is actually resolved from the metatype of the bases. In contrast `PyType_FromSpecWithBases` immediately calls: res = (PyHeapTypeObject*)PyType_GenericAlloc(_Type, 0); So I am curious whether `PyType_FromSpecWithBases` should not do the same thing, or as to why it does not? I would also assume that it actually fails to inherit a possible MetaClass completely, but I have not checked that. That is the first question. The second, more important one, is whether ExtensionMetaClasses are a thing at all? Is it reasonable to explore them, or should I rather give up and use something more like ABCMeta, which stores information in the `HeapType->tp_dict`, plus tag on information to the actual instances as needed? Right now it seems completely fine to me, except that the creation itself is complicated (and a confusing, but its MetaClasses...). I am exploring this for NumPy. PySIDE is using such things and wrangled it into the limited API [1] (PySIDE needs to store a QT pointer additionally). When I looked the code, I was fairly sure that this only happened to work because Python allocates a slightly larger space (effectively making it `nslots+1`, or 1 above). As far as I can see, the only thing that happens if I use such an ExtensionMetaClass is that I have a HeapType with a different tp_basicsize. And I do not see why that should be any different than a normal Python object. Best, Sebastian [1] https://github.com/pyside/pyside2-setup/blob/5.11/sources/shiboken2/libshiboken/pep384impl_doc.rst#diversification signature.asc Description: This is a digitally signed message part ___ 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/4Z47VDZUOEYBWFDKOKUBITG2PFRAWH23/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Request to postpone some Python 3.9 incompatible changes to Python 3.10
I think this particular mess was caused by the hiding of “DeprecationWarning”s by default: If you don’t see any warnings cropping up in your production code, you don’t know you have to fix something. Some languages handle it like this: 1. Silent deprecation warning (deprecated in docs and/or hidden like in Python, the most eagle-eyed maintainers will see it and fix it) 2. Visible deprecation warning (people start seeing it and bug you in issues) 3. Hide things behind a flag: You’ll have breakage but you get a grace perior by enabling some scary looking environment variable or so (nobody can deny that things are getting serious) 4. Removal Going from 1 to 4 is of course pretty harsh, and this is what we’re doing. I propose that at least in the future, we have a schedule for every single deprecation to go to a gradual process like above. Best, Phil Am Fr., 31. Jan. 2020 um 05:21 Uhr schrieb Stephen J. Turnbull < turnbull.stephen...@u.tsukuba.ac.jp>: > Dima Tisnek writes: > > > I thought that collections compatibility was kept up to 3.8 > > specifically because py2 was alive. > > No that that requirement is gone, so should the shim, right? > > Python 2 is still very much alive (even in a Python 3 venv :-þ): > > (analysis.venv) 01 16:56$ /usr/bin/python > Python 2.7.10 (default, Feb 22 2019, 21:55:15) > [GCC 4.2.1 Compatible Apple LLVM 10.0.1 (clang-1001.0.37.14)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> ^D > > We have stopped supporting Python 2 in the sense that we are no longer > going to release source updates to Python 2. That doesn't necessarily > mean we don't consider the needs of users who continue to depend on > Python 2 for one reason or another, excellent or totally (in our > oh-so-ever-'umble opinion) mistaken though that reason may be. > > > Ofc., my assumption could be just wrong... > > It might be, it might not be, it might be situation-dependent (ie, > decisions should be made case by case on a cost to Python core > developers versus benefits to Python 2 users and those who support > them in their libraries etc basis). > > I think it would certainly be reasonable to make the decision that > we're going to go full speed ahead with Python 3 and start stripping > out Python 2-only features in the stdlib code. I don't support that, > but I'm not a core developer, so that's a +1.0e-17 for keeping the > code. I get the feeling that Guido is also not in favor of a > Procrustean[1] approach to Python 2 support in the Python 3 stdlib, > but I could be wrong. Since he's not BDFL, that's merely indicative, > but IMO it's a pretty strong indicator. > > What would really distress me however, is if we forget that we're not > supporting *code*, we're supporting *users* by creating and > maintaining code. Of course we can choose that user base, and may > have to make painful decisions. But this community is about people > supporting people, just like any community. > > Footnotes: > [1] Look up "Procrustes" in Wikipedia. It's not a story to tell in > this family setting. ;-) > ___ > 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/WX4LA55VR35LEAM46WWMQHS2T5DZOZII/ > 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/N5XWYZJEZRSMLG43BAL65YGLXDSVKS6C/ Code of Conduct: http://python.org/psf/codeofconduct/
