[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)
On 07Aug2020 2133, Joao S. O. Bueno wrote: Enough cheaptalk - links are here: tests: https://github.com/jsbueno/terminedia/blob/fa5ac012a7b93a2abe26ff6ca41dbd5f5449cb0b/tests/test_utils.py#L356 Branch comparison for the match/case version: https://github.com/jsbueno/terminedia/compare/patma I haven't been following this thread too closely, but that looks pretty nice to me. Not obvious enough for me to write my own just from reading an example, and I'd hesitate before trying to modify it at all, but I can at least read the pre- and post-conditions more easily than in the original. (all said, I think I still miss a way to mark variables that are assigned in the case clauses, just for the record :-) ) Yeah, the implicit variable assignments seem like the most confusing bit (based solely on looking at just one example). I think I'd be happy enough just knowing that "kw" matches the pattern, and then manually extracting individual values from it. (But I guess for that we'd only need a fancy "if_match(kw, 'expression')" function... hmm...) Cheers, Steve ___ 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/AU6YADGMSOYOIPKNKFWFGC5XEEVOYDO7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)
Just taking a ride on the thread here, I made a quick talk on the proposed feature for a local group, and in the process I refactored a "real world" class I have in a project, which features a complicated __init__ due having lots of different, optional, ways to be initialized. I can tell I liked what could be done - reducing roughly 60 loc packed with "isinstance" calls, "if/elif" blocks, temporary, intermediate state variables, into 25 lines including 10 case-clauses that are very straightforward to read. Sorry for whoever would like an example differing much of the "point2d" examples on the PEP, but the class in question IS geometry related and is a Rectangle - I am not yet testing (neither on the 'normal' if/else version) _invalid_ arguments - there are a lot of way to pass conflicting arguments to __init__ - and the if/elif logic to handle those properly is not in place. The match/case version for handling these invalid combinations would be very straight forwad, on the other hand . (all said, I think I still miss a way to mark variables that are assigned in the case clauses, just for the record :-) ) Enough cheaptalk - links are here: tests: https://github.com/jsbueno/terminedia/blob/fa5ac012a7b93a2abe26ff6ca41dbd5f5449cb0b/tests/test_utils.py#L356 Branch comparison for the match/case version: https://github.com/jsbueno/terminedia/compare/patma You will notice one "real world" pattern that was needed there: as the case clauses had to be aware of values spread across different keyword-parameters, I had to prepend a "packing" of all function arguments into a mapping to match against. If I would not care for the function signature, I could just get "**kwargs" and match against that. On Thu, 6 Aug 2020 at 14:09, Brett Cannon wrote: > > > On Thu, Aug 6, 2020 at 3:46 AM Mark Shannon wrote: > >> Hi Barry, >> >> How long do we have to present objections to PEP 622? >> > > We haven't discussed a timeline among ourselves yet (unless it was > discussed at the last meeting which missed ). > > >> >> I don't feel that the PEP gives adequate prominence to the objections so >> far raised, and there are more issues I would like to bring up. >> > > I don't think we would want to keep pushing out every time someone has > more to say as that would mean this would never end. But I doubt we will > be making a decision next week, so if you can get any comments in between > now and the 17th you will probably get it in before the earliest we will > very optimistically make a decision. > > -Brett > > >> >> Cheers, >> Mark. >> >> >> On 05/08/2020 5:58 pm, Barry Warsaw wrote: >> > PEP 622 is already on the SC’s agenda for review. >> > >> > -Barry >> > >> >> On Aug 5, 2020, at 09:47, Ethan Furman wrote: >> >> >> >> On 7/30/20 8:35 AM, Rob Cliffe via Python-Dev wrote: >> >> >> >>> The debate is still going on as to whether "capture" variables should >> be marked... >> >> I don't think the PEP authors are debating it any more. Quite >> frankly, I wish they would present to the SC and get accepted so we can get >> Pattern Matching added to 3.10. :) >> >> >> >> -- >> >> ~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/PGEVEI2W7L32FFCLFOWGFRANMBZHPILQ/ >> >> 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/CVYGPSODOHTLEGPRM4EI5GTMR6PHSZLF/ >> > 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/OSDBFZRZFJVSZ5ZBJ6QFRPWEGL2FJCJZ/ >> 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/ESAKYRYV6L6ZMMXO4NTMYOD6OBSOBRQO/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2020-07-31 - 2020-08-07) 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: open7598 (+14) closed 45647 (+39) total 53245 (+53) Open issues with patches: 3098 Issues opened (34) == #41075: IDLE: Better support history navigation https://bugs.python.org/issue41075 reopened by terry.reedy #41453: A possible reference leak in _locale.localeconv() https://bugs.python.org/issue41453 opened by ZackerySpytz #41455: Python Devguide differs from python docs https://bugs.python.org/issue41455 opened by ypank #41458: Avoid overflow/underflow in math.prod() https://bugs.python.org/issue41458 opened by rhettinger #41459: pickle.load raises SystemError on malformed input https://bugs.python.org/issue41459 opened by Guillaume #41460: Translation Error in in Functional Programming HOWTO page https://bugs.python.org/issue41460 opened by mydairyyao #41461: test_pathlib assumes underlying filesystem permits creation wi https://bugs.python.org/issue41461 opened by Michael.Felt #41462: os.set_blocking() raises OSError on VxWorks RTOS https://bugs.python.org/issue41462 opened by pxinwr #41463: Avoid duplicating jump information from opcode.py in compile.c https://bugs.python.org/issue41463 opened by Mark.Shannon #41468: Unrecoverable server exiting https://bugs.python.org/issue41468 opened by albertpython #41470: smtplib.SMTP should reset internal 'helo' and 'ehlo' state wit https://bugs.python.org/issue41470 opened by Dadeos #41471: After installing python 3.x on Mac pip doesn't work at all https://bugs.python.org/issue41471 opened by peteje66 #41472: webbrowser uses deprecated env variables to detect desktop typ https://bugs.python.org/issue41472 opened by Trevinho #41473: test_gdb fails on AMD64 Fedora Rawhide 3.x https://bugs.python.org/issue41473 opened by vstinner #41474: Missing dependency on Include/cpython/frameobject.h https://bugs.python.org/issue41474 opened by skip.montanaro #41475: __future__.annotations set to become default in Python 4.0? https://bugs.python.org/issue41475 opened by cool-RR #41477: test_genericalias fails if ctypes is missing https://bugs.python.org/issue41477 opened by vstinner #41478: Empty representation of AssertionError https://bugs.python.org/issue41478 opened by Ilya Kamenshchikov #41482: docstring errors in ipaddress.IPv4Network https://bugs.python.org/issue41482 opened by eric.frederich #41483: Do not acquire lock in MemoryHandler.flush() if no target defi https://bugs.python.org/issue41483 opened by ankostis #41486: Add _BlocksOutputBuffer for bz2/lzma/zlib module https://bugs.python.org/issue41486 opened by malin #41487: Builtin bigint modulo operation can be made faster when the ba https://bugs.python.org/issue41487 opened by shlomif2 #41489: HTMLParser : HTMLParser.error creating multiple errors. https://bugs.python.org/issue41489 opened by AbcSxyZ #41490: Update bundled pip to 20.2.1 and setuptools to 49.2.1 https://bugs.python.org/issue41490 opened by steve.dower #41491: plistlib can't load macOS BigSur system LaunchAgent https://bugs.python.org/issue41491 opened by jckwhet #41492: Fix signing description for Windows release builds https://bugs.python.org/issue41492 opened by steve.dower #41494: Add window resizing support [ SIGWINCH ] to Lib/pty https://bugs.python.org/issue41494 opened by soumendra #41496: Create public API for typing._eval_type https://bugs.python.org/issue41496 opened by Dominik V. #41497: Potential UnicodeDecodeError in dis https://bugs.python.org/issue41497 opened by zkonge #41498: Undefinied _Py_Sigset_Converter function when HAVE_SIGSET_T no https://bugs.python.org/issue41498 opened by Roman Yurchak #41499: logging nested file path https://bugs.python.org/issue41499 opened by Norfeldt #41501: 0x80070643, can't install any version https://bugs.python.org/issue41501 opened by BSMMedia #41502: Option for Colored Logging in http.server Module https://bugs.python.org/issue41502 opened by alichtman #41503: Race between setTarget and flush in logging.handlers.MemoryHan https://bugs.python.org/issue41503 opened by iritkatriel Most recent 15 issues with no replies (15) == #41503: Race between setTarget and flush in logging.handlers.MemoryHan https://bugs.python.org/issue41503 #41502: Option for Colored Logging in http.server Module https://bugs.python.org/issue41502 #41501: 0x80070643, can't install any version https://bugs.python.org/issue41501 #41498: Undefinied _Py_Sigset_Converter function when HAVE_SIGSET_T no https://bugs.python.org/issue41498 #41496: Create public API for typing._eval_type https://bugs.python.org/issue41496 #41494: Add window resizing support [ SIGWINCH ] to Lib/pty https://bugs.python.org/issue41494 #41489: HTMLParser : HTMLParser.error creating
[Python-Dev] Re: Pay for PR review and merging for VxWorks RTOS
> Buildbot is also not a problem. The early issue from the core developer side, it would be helpful to review if the Buildbot is supported by Wind River for VxWorks. 2020년 8월 6일 (목) 오후 1:16, Xin, Peixing 님이 작성: > > Hi, Stanley: > > > > Thanks for your comments. > > > > Almost all the patches are simple compatibility patch. But the subprocess > module is an exception. Like windows, VxWorks have no fork/exec API provided. > Instead, VxWorks uses rtpSpawn() to spawn a new process. So we have to > implement VxWorks’ own extension modules to support subprocess module. > However, this is not significant amount of codes, just around 500 lines of C > codes. Hopes any core dev could help to review and merge the simple > compatibility patches. If I can be granted the commit privileges, that will > be great. To ensure the quality, I will get the patches reviewed enough well > before merging. > > For long term support for VxWorks RTOS, I am an engineer from Wind River. > Wind River is willing to officially provide the support and I am willing to > be the maintainer. Buildbot is also not a problem. Once the patches have been > merging done, we will connect the buildbot for VxWorks. > > > > Thanks, > > Peixing > > > > From: Kyle Stanley > Sent: Thursday, August 6, 2020 9:27 AM > To: Xin, Peixing > Cc: python-dev@python.org; Meng, Bin > Subject: Re: [Python-Dev] Pay for PR review and merging for VxWorks RTOS > > > > What exactly does the PR involve? Is it a relatively simple compatibility > patch or something that adds significant amounts of platform-specific code? > The former can be reviewed (and potentially merged) by any core dev > knowledgeable in the areas being changed, but the latter requires long-term > support for the platform. > > > > In order to provide support for a new platform that we don't presently have > support for in CPython, it requires the following: > > > > 1) An existing core developer willing to provide long-term support for the > platform. Alternatively, someone else can be granted commit privileges, for > the purpose of maintaining that platform and fixing any issues that come up > in that CI that are specific to it. However, this is done on a case-by-case > basis, as it still requires a decent amount of trust with that individual. > > > > 2) A stable buildbot provided, to test against new changes made to CPython. > > > > The purpose of the above is to ensure that any substantial platform-specific > code added to CPython receives proper care; this is opposed to a large > addition of new code for a platform that has nobody to take care of it when > issues come up. Especially as a group of mostly volunteers (and those paid by > their employers to contribute), the latter wouldn't be sustainable. I > personally think it would be fantastic to have official support for real-time > OSs in CPython, but in this ecosystem, it requires being able to place trust > in someone that's willing and adequately proficient in the related areas to > provide long-term support for them. > > > > For more details, see PEP 11: > https://www.python.org/dev/peps/pep-0011/#supporting-platforms. > > > > > > On Wed, Aug 5, 2020 at 7:44 AM Xin, Peixing wrote: > > Hi, Python developers: > > > > Anyone interested in PR review and merging for VxWorks RTOS? We can give a > proper pay for that. Contact me if you have interest. > > > > Thanks, > > Peixing > > > > ___ > 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/HATTYX3BWEIPVVUL7FMSNSCFYOBPS6OD/ > 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/TJM24KANKBKLQSFZIH42V4G4WLZ7MGO3/ > Code of Conduct: http://python.org/psf/codeofconduct/ -- Software Development Engineer at Kakao corp. Tel: +82 010-3353-9127 Email: donghee.n...@gmail.com | denn...@kakaocorp.com Linkedin: https://www.linkedin.com/in/dong-hee-na-2b713b49/ ___ 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/XE6YSMZME4LQMY47IOHV2HTRIIEKIRKW/ Code of Conduct: http://python.org/psf/codeofconduct/
