[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)
On 2020-08-03 05:21, Guido van Rossum wrote: Your point about wanting a way to use an unqualified name as a value pattern is not unreasonable, and as you may recall we had an elegant solution in version 1 of the PEP: a leading dot. However that was booed away by the critics, and there has been no consensus (not even close) on what to do instead. Any solution that involves special markup (like bringing back the leading dot, or backticks, or a question mark, or any other sigil) can easily be added in a future version of Python. There is one solution that I personally find acceptable but which found little support from the other PEP authors. It is a rule also adopted by Scala. This is to make it so that any identifier starting with a capital letter (possibly preceded by one or more underscores) is a value pattern. I note that in Scala, too, this is different in patterns than elsewhere in the language: Scala, like Python, allows identifiers starting with a capital letter to be assigned in other contexts -- just not in patterns. It also uses roughly the same *conventions* for naming things as PEP 8 (classes Capitalized, constants UPPERCASE, variables and methods lowercase). I also note that Scala allows backticks as another way to force interpretation as a value pattern (though apparently it's not used much for this purpose). [snip] A thought occurred to me. By default, the current rules of the PEP could apply, but why not allow prefixing with "as" for a capture and "is" for a value? Yes, I know, comparison of the values is not by identity, but "is" is a short keyword that already exists and matches up with "as". (After looking back through the thread it looks like Rob Cliffe has already had the same idea.) ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/XVAJ76OOVFT3RJXDJH3BRNEHOFS7PAJS/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Fwd: [pypi-announce] upgrade to pip 20.2 -- plus changes coming in 20.3
Thanks. It looks like we can do it later this week and make the next round of releases. Please let us know asap if anything comes up that you wouldn't want to be released. Cheers, Steve On 01Aug2020 1632, Sumana Harihareswara wrote: Steve Dower asked: Do you think we should be updating the version of pip bundled with Python 3.9 at this stage (for the first RC)? Similarly, is there a need to update Python 3.8 for its next release? Answered now in https://github.com/pypa/pip/issues/6536#issuecomment-666715283 -- yes, please do do. However, you may want to wait till Tuesday or so for our bugfix release https://github.com/pypa/pip/issues/8511#issuecomment-60644 . ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/AAJVOQELS4KEHRCMSB2TSSHSZSSRLJSI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 624: Remove Py_UNICODE encoder APIs
Hi, Lemburg. Thank you for organizing the EuroPython 2020. I enjoyed watching some sessions from home. I think current PEP 624 covers all your points and ready for Steering Council discussion. Would you like to review the PEP before it? Regards, On Thu, Jul 9, 2020 at 8:19 AM Inada Naoki wrote: > > On Thu, Jul 9, 2020 at 5:46 AM M.-A. Lemburg wrote: > > - the fact that the encode APIs encoding from a Unicode buffer > > to a bytes object; this is an important fact, since the removal > > removes access to this codec functionality for extensions > > > > - PyUnicode_AsEncodedString() is not a proper alternative, since > > it requires to create a temporary PyUnicode object, which is > > inefficient and wastes memory > > I wrote your points in the "Alternative Idea > Replace Py_UNICODE* > with Py_UCS4* " > section. I wrote "User can encode UCS-4 string in C without creating > Unicode object." in it. > > https://www.python.org/dev/peps/pep-0624/#replace-py-unicode-with-py-ucs4 > > Note that the current Py_UNICODE* encoder APIs create temporary > PyUnicode objects. > They are inefficient and wastes memory now. Py_UNICODE* may be UTF-16 on some > platforms (e.g. Windows) and builtin codecs don't support UTF-16 input. > > > > > > - the maintenance effect mentioned in the PEP does not really > > materialize, since the underlying functionality still exists > > in the codecs - only access to the functionality is removed > > > > In the same section, I described the maintenance cost as below. > > * Other Python implementations may not have builtin codec for UCS-4. > * If we change the Unicode internal representation to UTF-8, we need > to keep UCS-4 support only for these APIs. > > > - keeping just the generic PyUnicode_Encode() API would be a > > compromise > > > > - if we remove the codec specific PyUnicode_Encode*() APIs, why > > are we still keeping the specisl PyUnicde_Decode*() APIs ? > > > > OK, I will add "Discussions" section. (I don't like "FAQ" because some > question > are important even if it is not "frequently" asked.) > > Quick answer is: > > * They are stable ABI. (Py_UNICODE is excluded from stable ABI). > * Decoding from char* is more common and generic use case than encoding from > Py_UNICODE*. > * Other Python implementations using UTF-8 as internal representation > can implement > it easily. > > But I'm not opposite to remove it (especially for minor UTF-7 codec). > It is just out of scope of this PEP. > > > > - the deprecations were just done because the Py_UNICODE data > > type was replaced by a hybrid type. Using this as an argument > > for removing functionality is not really good practice, when > > these are ways to continue exposing the functionality using other > > data types. > > I hope the "Replace Py_UNICODE* with Py_UCS4* " section describe this. > > Regards, > > -- > Inada Naoki -- Inada Naoki ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/LXS6SXGX3HADR2GHWWC3C4Q3UGN4M2CR/ Code of Conduct: http://python.org/psf/codeofconduct/
