Mailman 3 February 2021 - Python-Dev

PEP 654 -- Exception Groups and except* : request for feedback for SC submission
by Irit Katriel 18 Mar '21

18 Mar '21

Hi all, We would like to request feedback on PEP 654 -- Exception Groups and except*. https://www.python.org/dev/peps/pep-0654/ It proposes language extensions that allow programs to raise and handle multiple unrelated exceptions simultaneously, motivated by the needs of asyncio and other concurrency libraries, but with other use cases as well. * A new standard exception type, ExceptionGroup, to represent multiple exceptions with shared traceback. * Updates to the traceback printing code to display (possibly nested) ExceptionGroups. * A new syntax except* for handling ExceptionGroups. A reference implementation (unreviewed) can be found at: https://github.com/iritkatriel/cpython/pull/10 Thank you for your help Kind regards Irit, Yury & Guido

22 117

PEP 647 (type guards) -- final call for comments
by Guido van Rossum 14 Mar '21

14 Mar '21

I think we have reached consensus on PEP 647 in typing-sig. We have implementations for mypy and pyright, not sure about the rest. This PEP does not affect CPython directly except for the addition of one special item (TypeGuard) to typing.py -- it would be nice to get that in the 3.10 stdlib. I'm CC'ing python-dev here to see if there are any further comments; if not, we can initiate the approval process by creating an issue at https://github.com/python/steering-council. -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-…>

17 36

Acceptance of Pattern Matching PEPs 634, 635, 636, Rejection of PEPs 640 and 642
by Python Steering Council 12 Mar '21

12 Mar '21

After much deliberation, the Python Steering Council is happy to announce that we have chosen to accept PEP 634, and its companion PEPs 635 and 636, collectively known as the Pattern Matching PEPs. We acknowledge that Pattern Matching is an extensive change to Python and that reaching consensus across the entire community is close to impossible. Different people have reservations or concerns around different aspects of the semantics and the syntax (as does the Steering Council). In spite of this, after much deliberation, reviewing all conversations around these PEPs, as well as competing proposals and existing poll results, and after several in-person discussions with the PEP authors, we are confident that Pattern Matching as specified in PEP 634, et al, will be a great addition to the Python language. We also recognize that such a large new feature needs to be accompanied by comprehensive documentation and specification, both in the tutorial section of the documentation and in the language reference. We consider that the presence of such high-quality documentation must be present on the first release of Python 3.10, and therefore its absence should be considered a release blocker. We do not consider the PEPs or any possible external documentation to be sufficient. At the same time, we’re rejecting PEPs 640 and 642. Both PEPs have received little support from core developers. PEP 642’s proposed syntax does not seem like the right way to solve the jagged edges in PEP 634’s syntax, although the SC understands the desire to improve those aspects of the Pattern Matching proposal. Regarding that, we would also like to mention that changes building on top of PEP 634 (even PEPs 640 and 642 if they now gain support) can still be submitted via the PEP process for review using the regular channels (discussions in python-dev or the https://discuss.python.org/ server), followed by a formal submission to the Steering Council for consideration, taking into account that backwards-incompatible changes can only be made before the feature freeze point of Python 3.10. See PEP 619 (https://www.python.org/dev/peps/pep-0619/) for details on the release schedule for Python 3.10. We know that Pattern Matching has been a challenging feature that has sparked considerable discussions and design conversations, leading to several revisions from feedback stemming from the community, core devs, and the Steering Council. We are very happy to see that the Python developer community remains passionate and respectful, and we are sure that the result has benefited a lot because of it. Congratulations to the PEP(s) authors: Guido, Brandt, Tobias, Daniel, Talin, and everyone that participated in the discussion and implementation of this important new feature! -The Python Steering Council

5 4

Re: PEP 637 - Support for indexing with keyword arguments: request for feedback for SC submission
by Thor Whalen 02 Mar '21

02 Mar '21

Finally! One of my top python wishes! Where can I vote? How can I get my hands on a back port? How can I help getting this sooner?

3 3

Which thing is "Development Mode"
by Coyot Linden 02 Mar '21

02 Mar '21

As of 3.7, there is now a python feature called Development Mode: https://docs.python.org/3/library/devmode.html#devmode Which has a confusingly similar and nearly identical name to a setuptools feature: https://packaging.python.org/guides/distributing-packages-using-setuptools/… It seems like a bit of bikeshedding could create a name for one of them that disambiguates them. Best, coyot

7 8

Have virtual environments led to neglect of the actual environment?
by Random832 28 Feb '21

28 Feb '21

I was reading a discussion thread <https://gist.github.com/tiran/2dec9e03c6f901814f6d1e8dad09528e> about various issues with the Debian packaged version of Python, and the following statement stood out for me as shocking: Christian Heimes wrote: > Core dev and PyPA has spent a lot of effort in promoting venv because we don't want users to break their operating system with sudo pip install. I don't think sudo pip install should break the operating system. And I think if it does, that problem should be solved rather than merely advising users against using it. And why is it, anyway, that distributions whose package managers can't coexist with pip-installed packages don't ever seem to get the same amount of flak for "damaging python's brand" as Debian is getting from some of the people in the discussion thread? Why is it that this community is resigned to recommending a workaround when distributions decide the site-packages directory belongs to their package manager rather than pip, instead of bringing the same amount of fiery condemnation of that practice as we apparently have for *checks notes* splitting parts of the stdlib into optional packages? Why demand that pip be present if we're not going to demand that it works properly? I think that installing packages into the actual python installation, both via distribution packaging tools and pip [and using both simultaneously - the Debian model of separated dist-packages and site-packages folders seems like a reasonable solution to this problem] can and should be a supported paradigm, and that virtual environments [or more extreme measures such as shipping an entire python installation as part of an application's deployment] should ideally be reserved for the rare corner cases where that doesn't work for some reason. How is it that virtual environments have become so indispensable, that no-one considers installing libraries centrally to be a viable model anymore? Are library maintainers making breaking changes too frequently, reasoning that if someone needs the old version they can just venv it? Is there some other cause?

21 51

Re: Moving threadstate to thread-local storage.
by 谢俊逸 26 Feb '21

26 Feb '21

On MacOS & iOS, __thread variable is 35% faster than using pthread_getspecific. getSpecific cost: 0.000649 getTLS cost: 0.000423 - (void)test { double t1 = CFAbsoluteTimeGetCurrent(); for (int i = 0; i < 100000; i++) { [self getSpecific]; } double t2 = CFAbsoluteTimeGetCurrent(); printf("getSpecific cost: %f\n", t2 - t1); double t3 = CFAbsoluteTimeGetCurrent(); for (int i = 0; i < 100000; i++) { [self getTLS]; } double t4 = CFAbsoluteTimeGetCurrent(); printf("getTLS cost: %f\n", t4 - t3); } - (int)getSpecific { int * value = pthread_getspecific(tlsKey); return *value; } - (int)getTLS { return *tlv_v5; }

2 1

Summary of Python tracker Issues
by Python tracker 26 Feb '21

26 Feb '21

ACTIVITY SUMMARY (2021-02-19 - 2021-02-26) 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: open 7430 ( +2) closed 47636 (+58) total 55066 (+60) Open issues with patches: 2946 Issues opened (40) ================== #23882: unittest discovery doesn't detect namespace packages when give https://bugs.python.org/issue23882 reopened by terry.reedy #26600: Thread safety issue with MagickMock __str__: sometimes returns https://bugs.python.org/issue26600 reopened by iritkatriel #43271: AMD64 Windows10 3.x crash with Windows fatal exception: stack https://bugs.python.org/issue43271 opened by vstinner #43273: Mock `_mock_wraps` is undocumented and inconsistently named https://bugs.python.org/issue43273 opened by Woodz #43279: Update code taken from Keccak Code Package https://bugs.python.org/issue43279 opened by illia-v #43281: Walrus comprehension rebind checking behavior https://bugs.python.org/issue43281 opened by gousaiyang #43282: Add split install targets to install tests separately from lib https://bugs.python.org/issue43282 opened by eschwartz #43284: Wrong windows build in 20H2 https://bugs.python.org/issue43284 opened by bugale bugale #43285: ftplib use host from PASV response https://bugs.python.org/issue43285 opened by ricexdream #43286: Clarify that Popen.returncode does not get auto-set when the p https://bugs.python.org/issue43286 opened by Antony.Lee #43287: Use PEP 590 vectorcall to speed up calls to filter() https://bugs.python.org/issue43287 opened by corona10 #43288: test_importlib failure due to missing skip() method https://bugs.python.org/issue43288 opened by nascheme #43289: step bug in turtle's for loop https://bugs.python.org/issue43289 opened by Yehuda #43292: xml.ElementTree iterparse filehandle left open https://bugs.python.org/issue43292 opened by vkisforever #43295: datetime.strptime emits IndexError on parsing 'z' as %z https://bugs.python.org/issue43295 opened by itchyny #43296: [sqlite3] Fix sqlite3_value_blob() usage https://bugs.python.org/issue43296 opened by erlendaasland #43298: Windows build cannot detect missing Windows SDK https://bugs.python.org/issue43298 opened by mytechnotalent #43299: pyclbr.readmodule_ex traversing "import __main__": dies with V https://bugs.python.org/issue43299 opened by kxrob #43300: "bisect" module should support reverse-sorted sequences https://bugs.python.org/issue43300 opened by mCoding #43305: A typo in /Modules/_io/bufferedio.c https://bugs.python.org/issue43305 opened by malin #43306: Error in multiprocessing.Pool's initializer doesn't stop execu https://bugs.python.org/issue43306 opened by nemeskeyd #43307: Sync site.py and sysconfig.py with PyPy https://bugs.python.org/issue43307 opened by mattip #43308: subprocess.Popen leaks file descriptors opened for DEVNULL or https://bugs.python.org/issue43308 opened by cptpcrd #43311: bpo-43311: PyInterpreterState_New use thread-specific data tst https://bugs.python.org/issue43311 opened by JunyiXie #43312: Interface to select preferred "user" or "home" sysconfig schem https://bugs.python.org/issue43312 opened by uranusjr #43313: feature: support pymalloc for subinterpreters. each subinterpr https://bugs.python.org/issue43313 opened by JunyiXie #43315: Decimal.__str__ has no way to force exact decimal representati https://bugs.python.org/issue43315 opened by sim1234 #43318: pdb can't output the prompt message when successfully clear br https://bugs.python.org/issue43318 opened by hjzin #43319: A possible misleading expression in the Virtual Environment Tu https://bugs.python.org/issue43319 opened by cmhzc #43320: test test_webbrowser "can't locate runnable browser" with enab https://bugs.python.org/issue43320 opened by swamper123 #43321: PyArg_ParseTuple() false-returns SUCCESS though SystemError an https://bugs.python.org/issue43321 opened by kxrob #43322: Inconsistent '#include' notation in extensions tutorial doc https://bugs.python.org/issue43322 opened by mhughes #43323: UnicodeEncodeError: surrogates not allowed when parsing invali https://bugs.python.org/issue43323 opened by andersk #43324: asyncio https://bugs.python.org/issue43324 opened by AliyevH #43325: Documentation should warn that 'is' is not a safe comparison o https://bugs.python.org/issue43325 opened by anthony-flury #43326: About Zipfile https://bugs.python.org/issue43326 opened by Fcscanf #43327: The docs falsely state that PyImport_ImportFrozenModuleObject( https://bugs.python.org/issue43327 opened by ZackerySpytz #43328: make test errors https://bugs.python.org/issue43328 opened by asholomitskiy84 #43329: Multiprocessing Manager Client Not Reconnecting https://bugs.python.org/issue43329 opened by boom0192 #43330: xmlrpc.Server URI query and fragment are discarded from HTTP q https://bugs.python.org/issue43330 opened by Julien Castiaux Most recent 15 issues with no replies (15) ========================================== #43330: xmlrpc.Server URI query and fragment are discarded from HTTP q https://bugs.python.org/issue43330 #43329: Multiprocessing Manager Client Not Reconnecting https://bugs.python.org/issue43329 #43328: make test errors https://bugs.python.org/issue43328 #43327: The docs falsely state that PyImport_ImportFrozenModuleObject( https://bugs.python.org/issue43327 #43325: Documentation should warn that 'is' is not a safe comparison o https://bugs.python.org/issue43325 #43324: asyncio https://bugs.python.org/issue43324 #43323: UnicodeEncodeError: surrogates not allowed when parsing invali https://bugs.python.org/issue43323 #43322: Inconsistent '#include' notation in extensions tutorial doc https://bugs.python.org/issue43322 #43320: test test_webbrowser "can't locate runnable browser" with enab https://bugs.python.org/issue43320 #43319: A possible misleading expression in the Virtual Environment Tu https://bugs.python.org/issue43319 #43313: feature: support pymalloc for subinterpreters. each subinterpr https://bugs.python.org/issue43313 #43308: subprocess.Popen leaks file descriptors opened for DEVNULL or https://bugs.python.org/issue43308 #43307: Sync site.py and sysconfig.py with PyPy https://bugs.python.org/issue43307 #43306: Error in multiprocessing.Pool's initializer doesn't stop execu https://bugs.python.org/issue43306 #43305: A typo in /Modules/_io/bufferedio.c https://bugs.python.org/issue43305 Most recent 15 issues waiting for review (15) ============================================= #43327: The docs falsely state that PyImport_ImportFrozenModuleObject( https://bugs.python.org/issue43327 #43324: asyncio https://bugs.python.org/issue43324 #43321: PyArg_ParseTuple() false-returns SUCCESS though SystemError an https://bugs.python.org/issue43321 #43318: pdb can't output the prompt message when successfully clear br https://bugs.python.org/issue43318 #43312: Interface to select preferred "user" or "home" sysconfig schem https://bugs.python.org/issue43312 #43311: bpo-43311: PyInterpreterState_New use thread-specific data tst https://bugs.python.org/issue43311 #43308: subprocess.Popen leaks file descriptors opened for DEVNULL or https://bugs.python.org/issue43308 #43307: Sync site.py and sysconfig.py with PyPy https://bugs.python.org/issue43307 #43299: pyclbr.readmodule_ex traversing "import __main__": dies with V https://bugs.python.org/issue43299 #43295: datetime.strptime emits IndexError on parsing 'z' as %z https://bugs.python.org/issue43295 #43288: test_importlib failure due to missing skip() method https://bugs.python.org/issue43288 #43287: Use PEP 590 vectorcall to speed up calls to filter() https://bugs.python.org/issue43287 #43279: Update code taken from Keccak Code Package https://bugs.python.org/issue43279 #43265: [sqlite3] Improve backup error handling https://bugs.python.org/issue43265 #43251: [sqlite3] sqlite3_column_name() failures should raise MemoryEr https://bugs.python.org/issue43251 Top 10 most discussed issues (10) ================================= #42128: Structural Pattern Matching (PEP 634) https://bugs.python.org/issue42128 14 msgs #43251: [sqlite3] sqlite3_column_name() failures should raise MemoryEr https://bugs.python.org/issue43251 12 msgs #43263: threading module unable to run https://bugs.python.org/issue43263 9 msgs #23882: unittest discovery doesn't detect namespace packages when give https://bugs.python.org/issue23882 6 msgs #43179: Remove 31/32-bit s390 Linux support (s390-linux-gnu triplet) https://bugs.python.org/issue43179 6 msgs #43265: [sqlite3] Improve backup error handling https://bugs.python.org/issue43265 6 msgs #29399: python3.dll export forwarders not resolved in all situations d https://bugs.python.org/issue29399 5 msgs #42990: Improve the C code for calling Python code: _PyEval_EvalCode() https://bugs.python.org/issue42990 5 msgs #43292: xml.ElementTree iterparse filehandle left open https://bugs.python.org/issue43292 5 msgs #43312: Interface to select preferred "user" or "home" sysconfig schem https://bugs.python.org/issue43312 5 msgs Issues closed (56) ================== #16954: Add docstrings for ElementTree module https://bugs.python.org/issue16954 closed by nascheme #17213: ctypes loads wrong version of C runtime, leading to error mess https://bugs.python.org/issue17213 closed by eryksun #20010: time.strftime('%z') didn't make +HHMM return in windows xp https://bugs.python.org/issue20010 closed by eryksun #20140: UnicodeDecodeError in ntpath.py when home dir contains non-asc https://bugs.python.org/issue20140 closed by eryksun #22961: ctypes.WinError & OSError https://bugs.python.org/issue22961 closed by eryksun #22976: multiprocessing Queue empty() is broken on Windows https://bugs.python.org/issue22976 closed by eryksun #23634: os.fdopen reopening a read-only fd on windows https://bugs.python.org/issue23634 closed by eryksun #24493: subprocess with env=os.environ doesn't preserve environment va https://bugs.python.org/issue24493 closed by eryksun #24977: shutil copy to non-existant directory https://bugs.python.org/issue24977 closed by eryksun #26111: On Windows, os.scandir will keep a handle on the directory unt https://bugs.python.org/issue26111 closed by eryksun #26658: test_os fails when run on Windows ramdisk https://bugs.python.org/issue26658 closed by eryksun #26866: Inconsistent environment in Windows using "Open With" https://bugs.python.org/issue26866 closed by eryksun #26968: glob.glob incorrect results under windows when pathname exists https://bugs.python.org/issue26968 closed by eryksun #27646: doc: yield from expression can be any iterable https://bugs.python.org/issue27646 closed by terry.reedy #27889: ctypes interfers with signal handling https://bugs.python.org/issue27889 closed by eryksun #28364: Windows - Popen (subprocess.py) does not call _handle.Close() https://bugs.python.org/issue28364 closed by eryksun #30460: file opened for updating cannot write after read https://bugs.python.org/issue30460 closed by eryksun #30480: samefile and sameopenfile fail for WebDAV mapped drives https://bugs.python.org/issue30480 closed by steve.dower #30979: the winapi fails to run shortcuts (because considers a shortcu https://bugs.python.org/issue30979 closed by eryksun #36636: Inner exception is not being raised using asyncio.gather https://bugs.python.org/issue36636 closed by iritkatriel #41859: IDLE: ValueError; Completions not working right on macOS https://bugs.python.org/issue41859 closed by terry.reedy #42151: Pure Python xml.etree.ElementTree is missing default attribute https://bugs.python.org/issue42151 closed by corona10 #42338: Enable Debug Build For Python Native Modules in Windows, with https://bugs.python.org/issue42338 closed by steve.dower #42405: Add distutils mvsccompiler support for Windows ARM64 build https://bugs.python.org/issue42405 closed by steve.dower #42808: Add PyType_Type.tp_vectorcall for type(obj) performance https://bugs.python.org/issue42808 closed by corona10 #42825: Build libraries with "/OPT:REF" linker optimization on Windows https://bugs.python.org/issue42825 closed by steve.dower #42981: Error messages raised by _hashlib_scrypt_impl() are slightly m https://bugs.python.org/issue42981 closed by illia-v #43042: Augment tutorial sentence. https://bugs.python.org/issue43042 closed by terry.reedy #43144: test_unicodedata: test_normalization uses network but doesn't https://bugs.python.org/issue43144 closed by corona10 #43146: 3.10a5 regression: AttributeError: 'NoneType' object has no at https://bugs.python.org/issue43146 closed by iritkatriel #43202: Cleanup codeop._maybe_compile https://bugs.python.org/issue43202 closed by terry.reedy #43209: system cannot find the file specified in subprocess.py https://bugs.python.org/issue43209 closed by josh.r #43260: Never release buffer when MemoryError in print() https://bugs.python.org/issue43260 closed by methane #43269: [sqlite3] Clean up function scoping https://bugs.python.org/issue43269 closed by berker.peksag #43272: AMD64 Arch Linux VintageParser 3.9: test_fstring test_named_ex https://bugs.python.org/issue43272 closed by pablogsal #43274: Backlinks Strong decouverte SSL https://bugs.python.org/issue43274 closed by ned.deily #43275: [venv] Add a `.gitignore` file with content `*` in the root fo https://bugs.python.org/issue43275 closed by star2000 #43276: add `false` and `true` keywords (aliases) for True and False https://bugs.python.org/issue43276 closed by serhiy.storchaka #43277: Add PySet_CheckExact https://bugs.python.org/issue43277 closed by pablogsal #43278: unnecessary leading '\n' from Py_GetCompiler() when build wit https://bugs.python.org/issue43278 closed by miss-islington #43280: additional argument for str.join() https://bugs.python.org/issue43280 closed by steven.daprano #43283: IDLE: Explain print slowness and speedup method https://bugs.python.org/issue43283 closed by terry.reedy #43290: [sqlite3] remove legacy code from pysqlite_step https://bugs.python.org/issue43290 closed by berker.peksag #43291: elementary multiplication by 0.01 error https://bugs.python.org/issue43291 closed by rhettinger #43293: Move note about GIL to top of threading module https://bugs.python.org/issue43293 closed by pablogsal #43294: [sqlite3] unused variables in Connection begin, commit, and ro https://bugs.python.org/issue43294 closed by berker.peksag #43297: bz2.open modes behaving differently than standard open() modes https://bugs.python.org/issue43297 closed by rhettinger #43301: Update form create for android https://bugs.python.org/issue43301 closed by eric.araujo #43302: spam https://bugs.python.org/issue43302 closed by eryksun #43303: ASAN : Memory leak in compilation https://bugs.python.org/issue43303 closed by Ramin Farajpour Cami #43304: THONNY 3.3.0 failing to install package MULTIPROCESSING https://bugs.python.org/issue43304 closed by mark.dickinson #43309: str.replace() TypeError exception message backward https://bugs.python.org/issue43309 closed by bland328 #43310: Method __del__ with callable https://bugs.python.org/issue43310 closed by mark.dickinson #43314: [sqlite3] remove pre SQLite 3.7.7 support code https://bugs.python.org/issue43314 closed by berker.peksag #43316: python -m gzip handles error incorrectly https://bugs.python.org/issue43316 closed by methane #43317: python -m gzip could use a larger buffer https://bugs.python.org/issue43317 closed by methane

1 0

Steering Council update for January
by Thomas Wouters 25 Feb '21

25 Feb '21

The Steering Council just published the community update for January (covering November/December as well): https://github.com/python/steering-council/blob/master/updates/2021-01-stee… (included verbatim below). We'll be trying to keep this up monthly from now on. I'll note that January was a very busy month with a lot happening, but not a lot of long-term planning. I hope we'll be able to get back to that soon. # November - Steering Council discussed PEP 634 (Structural Pattern Matching) and decided it would not make a decision on it, since this SC is on its way out. Instead, the SC will make a recommendation to the next Steering Council. Brett sent a note to the PEP authors. - SC reviewed Ewa's proposed CPython sponsorship benefits and everyone is fine with it as is. We will have each SC review the benefits especially the benefit pertaining to meeting with the Steering Council. - SC discussed the internship priority update to [PEP 594](https://www.python.org/dev/peps/pep-0594/) and everyone is fine with it. - SC discussed the draft response to the proposal for funded CPython optimisation work, and decided it was fine to send. Thomas can also publish his blog. Thomas will wait for Victor to chime in on the Community Updates before sending them out. - SC discussed the Pattern Matching PEPs again, and put out a discuss.python.org poll to see if there is consensus among core developers. - SC discussed adding platform.freedesktop_os_release() (https://bugs.python.org/issue28468), and approved it. - SC discussed PEPs 634-636 (Structural Pattern Matching) yet again. The SC decided to recommended to the 2021 SC that they accept PEP 634. Brett [drafted an announcement]( https://mail.python.org/archives/list/steering-council@python.org/thread/I7… ). - Google sponsored the Core Dev sprint and chose the SC chat as its reward. Thomas is going to schedule a chat between the SC and Google for Dec 14 # December - Steering Council worked on a final announcement to python-dev@ about PEP 634. - SC voted on PEP 632 and will get Victor's vote before Brett sends a note to the PEP author. - SC is fine with Barry's & Brett's response to https://github.com/python/steering-council/issues/41 so Brett closed the issue. - Barry gave an overview of the PSF, SC meeting with Seagate. - SC discussed the elections and possible improvements that would be made to PEP 13 around the election timelines, staggered terms. SC also decided it would not have anymore meetings in 2020. Ewa will send a Doodle out for the first week of January once the new SC members are known for a handoff meeting. - SC had their first sponsor meeting with Google per their Core Dev Sprint sponsorship. # January ## January 7 - The Steering Council had a hand-off meeting with both Victor and Pablo, covering current goings on and how the SC normally operates. - SC decided on communication platform for meetings and out of bounds communications. - SC discussed PEP 632, deprecating distutils. - SC discussed PEP 634/635/636, Structural Pattern Matching, and brought Pablo up to date on previous discussions. - SC discussed community updates, decided to aim for once a month. Pablo and Thomas will alternate duty on this. - SC collectively and individually thanked Victor for all his work on the SC. ## January 11 - Carol [shared the Documentation WG charter]( https://docs.google.com/document/d/175bjJA7hKRaqvLjiRXSvUxKgGWGJ5RMuW-jYKUs… ) and Steering Council members should review it. - SC reviewed the Developer-in-Residence job description that is left over from the CZI grant application. The Steering Council decided how this role needs to do certain analysis and capture certain metrics to determine where the impact will be. Ewa will update the job description. - SC discussed delaying the removal of ABC aliases from collections. It was decided it would be removed in 3.10 as scheduled. Pablo will comment on the issue. - SC discussed how to handle differences between accepted PEPs and implementation. It was decided that any changes should be decided between at least two people (i.e. the author and PEP delegate). If an agreement cannot be reached, it should be sent to the Steering Council for review. ## January 18 - Steering Council reviewed PEP 632 (Deprecating distutils) and agreed distutils should be deprecated. Brett will email Barry (who was absent from the meeting) for his input. - SC reviewed PEP 634 (Structural Pattern Matching) and decided that the major hold up is the load/store confusion. Brett will ask if Guido could join next week to discuss this. - SC reviewed PEP 642 (Explicit Pattern Syntax for Pattern Matching), and decided to reject it. Brett will email Barry about it and Thomas will help draft the response to the PEP author. - SC discussed how Debian (and thus Ubuntu) ships Python, in particular how this affects users and their view of Python. SC decided that the SC should explicitly list the issues and send them to the project leader. SC will talk about this again next week when Barry is back. - SC discussed the Documentation WG. Carol will review Brett's notes from the Document WG charter and then will send an email to the Steering Council for approval. - SC briefly discussed docs on mobile and Carol stated that a lot could be improved with a more modern theme. ## January 25 - Guido attended today's meeting to talk through the load/store confusion of PEP 634 (Structural Pattern Matching). The Steering Council has decided to take a week to think it over and consideration of the PEP will be at the top of next week's agenda. - Thomas brought up PEP 651 and how quickly it was put up for SC consideration. It was decided that Pablo will email the author, asking them to discuss things more thoroughly on python-dev@ before asking the SC to pronounce on it. - The Steering Council discussed the issue of how Debian ships Python, and how the gist discussion has evolved. It was decided that Thomas would start a draft to the gist to explain the SC point of view. - All other items up for discussion got pushed to next week because we went 30 minutes over. -- Thomas Wouters <thomas(a)python.org> Hi! I'm an email virus! Think twice before sending your email to help me spread!

1 0

Re: [Python-ideas] Re: Re: Have virtual environments led to neglect of the actual environment?
by Paul Moore 24 Feb '21

24 Feb '21

On Wed, 24 Feb 2021 at 13:12, Antoine Pitrou <antoine(a)python.org> wrote: > > On Wed, 24 Feb 2021 13:47:40 +0100 > Stéfane Fermigier <sf(a)fermigier.com> wrote: > > The 3rd solution is probably the best of the 3, but the sharing mechanism > > still needs to be specified (and, if needed, implemented) properly. > > I wouldn't want to repeat myself too often, but conda and conda-based > distributions already have sharing through hardlinks (or, on Windows, > whatever is available) baked-in, assuming you install your software > from conda packages. > > That also applies to non-Python packages, and to python itself (which > is just a package like any other). I'm not sure conda solves the problem of *application* distribution, though, so I think it's addressing a different problem. Specifically, I don't think conda addresses the use case pipx is designed for. Although to be fair, this conversation has drifted *way* off the original topic. Going back to that, my view is that Python does not have a good solution to the "write your application in Python, and then distribute it" scenario. Shipping just the app to be run on an independently installed runtime results in the conflicting dependencies issue. Shipping the app with bundled dependencies is clumsy, mostly because no-one has developed tools to make it easier. It also misses opportunities for sharing libraries (reduced maintenance, less disk usage...). Shipping the app with a bundled interpreter and libraries is safest, but hard to do and even more expensive than the "bundled libraries" approach. I'd love to see better tools for this, but the community preferred approach seems to be "ship your app as a PyPI package with a console entry point" and that's the approach pipx supports. I don't use Linux much, and I'm definitely not familiar with Linux distribution tools, but from what I can gather Linux distributions have made the choices: 1. Write key operating system utilities in Python. 2. Share the Python interpreter and libraries. 3. Expose that Python interpreter as the *user's* default Python. IMO, the mistake is (3) - because the user wants to install Python packages, and not all packages are bundled by the distribution (or if they are, they aren't updated quickly enough for the user), users want to be able to install packages using Python tools. That risks introducing unexpected library versions and/or conflicts, which breaks the OS utilities, which expect their requirements to be respected (that's what the OS packaging tools do). Hindsight is way too easy here, but if distros had a "system Python" package that OS tools depend on, and which is reserved for *only* OS tools, and a "user Python" package that users could write their code against, we'd probably have had far fewer issues (and much less FUD about the "using sudo pip breaks your OS" advice). But it's likely way too late to argue for such a sweeping change. *Shrug* I'm not the person to ask here. My view is that I avoid using Python on Linux, because it's *way* too hard. I find it so much easier to work on Windows, where I can install Python easily for myself, and I don't have to fight with system package managers, or distribution-patched tools that don't work the way I expect. And honestly, on Windows, there's no "neglect of the system environment" to worry about - if you want to install Python, and use pip to install packages into that environment for shared use, it works fine. People (including me) use virtual environments for *convenience* on Windows, not because it's a requirement. Paul

2 1