[Python-Dev] Re: PEP 642 v3: Explicit patterns for structured pattern matching
Hello, On Sun, 10 Jan 2021 12:08:05 +1000 Nick Coghlan wrote: [] > PEP 634 doesn't have that feature for class patterns in general, only > for classes like data classes, where the constructor signature is > carefully aligned with the match arguments. You see, if PEP622/PEP634 contained clause like: "class patterns may be applied only to namedtuple types (and their subclasses) and dataclasses (and their subclasses)", then I personally would be happy. But if PEP622 draft would have contained such a clause, it would be removed before publishing anyway, because: 1. Enforcing such a check is more trouble/overhead. 2. There's no need to police users such deep, e.g. what if someone writes a class which has API *like* namedtuple/dataclasses, without formally being one? And that's the point. If you have a class: class MyCls: def __init__(self, val, nm): self.val = val; self.name = nm , and you normally use it like: MyCls(nm="foo", val=123), then when you'll try to use it with pattern matching, you'll immediately see what's wrong with your class: you need to use the same name for constructor arg and a related attribute (if you don't want to see funky discrepancies). To come to that, you don't need to read anything, it'll come naturally. In full accordance with Python approach of "gentle, but exciting (not depressing) and eventually high, learning curve", where next step is naturally guided by your previous steps. And of course, for people who prefer to read, PEP634/etc. in "informational" part should have a recommendation like "Class pattern matching syntax best works with namedtuples and dataclasses, or classes which follow their design pattern of "no data hiding", e.g. names of attributes should match names of constructor arguments, as both are public interface of such a class". > For positional args, PEP 642 would also align in those carefully > constructed cases, so it's only the new syntax for attribute matching > where things differ. And that's the biggest trouble with PEP642. "Conflating set syntax with dict semantics" is an easy case (to both see and fix), that's why I talked about it first. Introducing 2nd syntax to match against objects, so, there're two syntaxes to use against objects, and one of them is completely new to Python - that's the real problem of PEP642. And I patiently continue this thread, hoping that people whose argument would be along the lines of "I teach Python, and I don't want to teach my students 2 ways of doing the same thing, and which way use when. Why, if PEP634 offers just one way?" -- Best regards, Paul mailto:[email protected] ___ 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/CVSPPY6B7NTY6CP7K77YLYHHRUB7PKLS/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: unittest of sequence equality
On Sat, Jan 09, 2021 at 07:56:24AM -0500, Alan G. Isaac wrote: > This comment misses the key point, which is: > `assertSequenceEqual` should not rely > on behavior that is not ensured for typing.Sequence, > but it currently does. The failure on a numpy array > simply exposes this problem. You are making that as a definitive statement of fact, but it's not clear to me that this is actually true. There are at least two problems with your position: (1) The Sequence ABC requires only the *presence* of certain methods, not their semantics. We're entitled to assume the obvious, implicit, sequence-like semantics. If a class implements the methods, but provides unexpected semantics, anything could happen. (2) Equality is a fundament operation that we are entitled to assume that *all* objects support. See above: we're entitled to assume the standard semantics for equality too. Objects which have unusual semantics for equality, such as float NANs, may behave in unexpected ways. So I don't think that we are *required* to support unusual sequences like numpy. On the other hand, I think that we can extend assertSequenceEqual to support numpy arrays quite easily. A quick glance at the source code: https://github.com/python/cpython/blob/3.9/Lib/unittest/case.py suggests that all we need do is catch a potential ValueError around the sequence equality test, and fall back on the element by element processing: try: if seq1 == seq1: return except ValueError: # Possibly a numpy array? pass I don't think that this is a breaking change, and I think it should do what you expect. I don't believe that we need to accept your reasoning regarding the Sequence ABC to accept this enhancement. One need only accept that although numpy's array equality semantics are non-standard and unhelpful, numpy is an important third-party library, and the cost of supporting sequences like numpy arrays is negligible. -- Steve ___ 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/75ZQVUDIXIUS6EWTJWPA6II2KU55J6IH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] why include cpython/*.h, Need this macro ? # error "this header file must not be included directly"
#ifndef Py_LIMITED_API # define Py_CPYTHON_FILEOBJECT_H # include "cpython/fileobject.h" # undef Py_CPYTHON_FILEOBJECT_H #endif cpython/fileobject.h ``` #ifndef Py_CPYTHON_FILEOBJECT_H # error "this header file must not be included directly" #endif ``` why not use #ifndef #define cpython/fileobject.h #ifndef Py_CPYTHON_FILEOBJECT_H #define Py_CPYTHON_FILEOBJECT_H #endif /* Py_CPYTHON_FILEOBJECT_H */ ___ 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/WME3T6N3XQ6GP7GXBBRHTCH3O37IJK5K/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Upcoming 3.7.10 and 3.6.13 Security Releases
We are planning to produce the next security-fix rollup releases for Python 3.7.x and 3.6.x on 2021-01-15. The most recent releases for these versions were on 2020-08-17. There has not been a lot of activity for either branch since then. Core developers: if you know of any additional security issues that should be addressed in these releases, please mark the relevant bpo issues as "release blocker" and, if possible, submit PRs for review prior to the end of 2021-01-14 AOE. Thanks! -- Ned Deily [email protected] -- [] signature.asc Description: Message signed with OpenPGP ___ 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/4FE3TGR73Z3P4O6XQV5W22JWI4NCDUP6/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: why include cpython/*.h, Need this macro ? # error "this header file must not be included directly"
10.01.21 09:53, junyixie пише: > #ifndef Py_LIMITED_API > # define Py_CPYTHON_FILEOBJECT_H > # include "cpython/fileobject.h" > # undef Py_CPYTHON_FILEOBJECT_H > #endif > > cpython/fileobject.h > ``` > #ifndef Py_CPYTHON_FILEOBJECT_H > # error "this header file must not be included directly" > #endif > ``` > > why not use #ifndef #define > cpython/fileobject.h > #ifndef Py_CPYTHON_FILEOBJECT_H > #define Py_CPYTHON_FILEOBJECT_H > > #endif /* Py_CPYTHON_FILEOBJECT_H */ Because it will not produce compile-time error when you include that header files directly. The division of these declarations on few files is a deep implementation detail. Header file "cpython/fileobject.h" is not a part of API and we do not want users to use them directly and then fail because in next feature (or even bugfix) release some declarations have been moved to other files. ___ 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/UCKJUHCR4JLSPJKKQBKSUSRTNDBNARVI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Extending python's graphlib module
It was really good to see Python 3.9 adding the topological sort algorithm. What other algorithms might come next to the graphlib module? I think the basic ones like BFS, DFS, Bellman Ford's shortest path algorithm will be quite useful to have. Let me know if contributions are welcome. Thanks! ___ 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/I7AQRDKEUEQN6XHTQL6VKGCKUGJXKD24/ Code of Conduct: http://python.org/psf/codeofconduct/
