[Python-Dev] Re: Advantages of pattern matching - a simple comparative analysis
Hi Eric,
On 23/11/2020 9:32 pm, Eric V. Smith wrote:
On 11/23/2020 3:44 PM, David Mertz wrote:
I have a little bit of skepticism about the pattern matching syntax,
for similar reasons to those Larry expresses, and that Steve Dower
mentioned on Discourse.
Basically, I agree matching/destructuring is a powerful idea. But I
also wonder how much genuinely better it is than a library that does
not require a language change. For example, I could create a library
to allow this:
m = Matcher(arbitrary_expression)
if m.case("StringNode(s)"):
process_string(m.val)
elif m.case("[a, 5, 6, b]"):
process_two_free_vars(*m.values)
elif m.case("PairNone(a, b)"):
a, b = m.values
process_pair(a, b)
elif m.case("DictNode"):
foo = {key, process_node(child_node) for key, child_node in
m.values.items()}
I don't disagree that the pattern mini-language looks nice as syntax.
But there's nothing about that mini-language that couldn't be put in a
library (with the caveat that patterns would need to be quoted in some
way).
I just commented on Steve's post over on Discourse. The problem with
this is that the called function (m.case, here) needs to have access to
the caller's namespace in order to resolve the expressions, such as
StringNode and PairNone. This is one of the reasons f-strings weren't
implemented as a function, and is also the source of many headaches with
string type annotations.
My conclusion is that if you want something that operates on DSLs
(especially ones that can't be evaluated as expressions), the compiler
is going to need to know about it somehow so it can help you with it. I
wish there were a general-purpose mechanism for this. Maybe it's PEP
638, although I haven't really investigated it much, and pattern
matching might be a bad fit for it.
Hygienic macros (PEP 638) solve two problems with a string based library
(in my obviously biased opinion).
1. The pattern is parsed by the normal parser, so must have correct
syntax, and the contents are visible to IDEs and editors.
if m.case("StringNode(s)"): the pattern is just a string.
case!(StringNode(s)): the pattern is validated Python syntax.
2. The transformation is done at compile time, so the generated code
will execute in the correct context. Basically, the macro generates the
correct series of if/elifs for you.
Cheers,
Mark.
Eric
___
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/CA6FJTECBEOZFKH3OC4YHT2QJWYKCTW5/
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/CSZHGSJ46KZF554AFCLD4FJDW42M7KH7/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Remove formatter module
Since importing the module emits a DeprecationWarning at runtime since Python 3.4 and the deprecation is properly documented, IMO it's fine to remove it right now: https://docs.python.org/dev/library/formatter.html I never used this module, I don't know what it is. "Formatter objects transform an abstract flow of formatting events into specific output events on writer objects." Victor Le mar. 24 nov. 2020 à 06:42, Dong-hee Na a écrit : > > A few days ago, Terry J. Reedy created the issue about the formatter module. > (https://bugs.python.org/issue42299) > > The issue is mainly about testing code but also discussing the removal of the > module. > I noticed that the formatter module was deprecated in 3.4 and it was > originally scheduled to be removed in 3.6. But the removal was delayed until > 2.7 EOL. > > Now 2.7 is EOL and there is no usage in stdlib. > So IMHO, it is good to remove the formatter module in 3.10 > > So before removing it, I would like to hear the concern. > > Regards, > Dong-hee > > > ___ > 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/ZEDIBBYCWI34GVOXDEUYXQY3LYXOFHA2/ > Code of Conduct: http://python.org/psf/codeofconduct/ -- Night gathers, and now my watch begins. It shall not end until my death. ___ 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/CG7C333BJADUZPNRPZH7FKYJ2VP5ZTK7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Remove formatter module
+1 vote on removal. No concerns. It's been deprecated for a long time now (since 3.4). On Tue, Nov 24, 2020 at 3:54 AM Victor Stinner wrote: > Since importing the module emits a DeprecationWarning at runtime since > Python 3.4 and the deprecation is properly documented, IMO it's fine > to remove it right now: > https://docs.python.org/dev/library/formatter.html > > I never used this module, I don't know what it is. > > "Formatter objects transform an abstract flow of formatting events > into specific output events on writer objects." > > Victor > > Le mar. 24 nov. 2020 à 06:42, Dong-hee Na a écrit > : > > > > A few days ago, Terry J. Reedy created the issue about the formatter > module. > > (https://bugs.python.org/issue42299) > > > > The issue is mainly about testing code but also discussing the removal > of the module. > > I noticed that the formatter module was deprecated in 3.4 and it was > originally scheduled to be removed in 3.6. But the removal was delayed > until 2.7 EOL. > > > > Now 2.7 is EOL and there is no usage in stdlib. > > So IMHO, it is good to remove the formatter module in 3.10 > > > > So before removing it, I would like to hear the concern. > > > > Regards, > > Dong-hee > > > > > > ___ > > 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/ZEDIBBYCWI34GVOXDEUYXQY3LYXOFHA2/ > > Code of Conduct: http://python.org/psf/codeofconduct/ > > > > -- > Night gathers, and now my watch begins. It shall not end until my death. > ___ > 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/CG7C333BJADUZPNRPZH7FKYJ2VP5ZTK7/ > 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/P2C64ZQSKYBHUB5I7CUHYD5INMNLDSCS/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Ideas for improving the contribution experience
Hi Tal, Thanks for driving such research, it's really interesting. Sadly, I'm not surprised by the results, since I'm already aware of these issues. IMHO the most promising way to get more review is to create groups where developers work on the same topic and review each other. Also, mentoring is great! I advice core developers to delegate their "boring tasks" to people willing to help. Many contributors are eager to take these new responsibilities. Delegating shortly gives more time to work on other topics where rare skills are needed. > * Hard to find where to contribute I believe that https://devguide.python.org/ could be enhanced to better explain this part. Here are my notes on this question: "Contribute to CPython: where should I start?" https://cpython-core-tutorial.readthedocs.io/en/latest/where_should_i_start.html > * Mentorship helps a lot, but is scarce Over the last 2 years, I mentored different contributors, some of them have been promoted as core developers, some of them moved to another project, some of them continue to contribute as contributors. Mentoring really accelerates the training to learn the most critical things that a developer must know about the Python development workflow, but also to build a trust relationship. I'm trying to communicate about mentorship and my success stories, but I chose to not communicate about people that I'm mentoring since it would put too much pressure on them. It's perfectly fine if a mentee doesn't become a core dev. The difficult part is to stop doing simple tasks and delegate them. It's difficult since mentoring does take more time in the short term, reviews require a lot of back-and-forth exchanges to reach the expected code quality. It's hard to foresee the benefit in the long term. In the past, I complained a lot about failing buildbots, the maintenance burden of the servers and analyzing every single failure. Thanks to mentoring, Pablo decided to help and I'm now really happy to distribute the workload with him! For one year, I'm working on https://bugs.python.org/issue1635741 which is a giant project (issue open for 13 years, tons of sub-issues, tons of commits). The idea is to modernize the code base of the 118 C extension modules of the Python standard library: convert static types to heap types, and convert extensions to the multi-phase initialization API (PEP 489). Required changes are complex and must be reviewed carefully. Also, a part of this work is boring since it's always the same things (repeat the same patterns). Dong-hee Na, Hai Shi, Mohamed Koubaa are collaborating with me, and we made significant progress in one year. When one of them writes a PR, I ask the others to review it. Since we are a small task force working on the same topic for one year, slowly everyone is able to spot the common mistakes. For example, forget to DECREF the type in the dealloc function when a static type becomes a heap type. I trust them and so it puts less pressure on my shoulders when I have to merge a PR. I also spend less time on reviewing, and no time on writing changes since others are writing these changes! IMO this collaboration is a success since the scope is limited, it's possible to work on a single file per PR (or even write multiple PRs per file). While changes are complex, once you understand what should be done, it's mostly a simple task of replacing a pattern with another (ok, it's a little bit more complex than that in practice ;-)). Le sam. 17 oct. 2020 à 00:30, Tal Einat a écrit : > 1. Generate reminders for reviewers (...) The root issue is the number of reviewers. Right now, it's mostly core devs who review changes. I'm not sure that forcing core developers will solve the root issue. > 3. Advertise something like a "2-for-1" standing offer for reviews. Right. That sounds like a better long term solution. We need to encourage contributors to review pull requests written by other contributors in similar areas. As I wrote, when I read a review from a contributor, even if they are a complete stranger to me, I'm more confident in reviewing a PR, since I expect that the first review layers have been checked. > 4. Encourage core devs to dedicate some of their time to working through > issues/PRs which are "ignored" or "stalled". I ignore many areas of Python on purpose. I don't have skills in these areas or simply no interest. I have a different idea. What about organizing weeks of review where we focus on a small set of topics. For example, organize an "IDLE" week where we invite everybody to review IDLE issues, triage IDLE bugs, or maybe write new PRs. To be efficient, we need core developers involved in the loop to merge PRs, core devs expert in this topic. Otherwise, we cannot reduce the number of open PRs. I propose a whole week since reviews always need many back-and-forth. Such week might be the opportunity for more information discussions on a dedicated chat where people can ask any question, especia
[Python-Dev] Re: Remove formatter module
Thanks everybody I will merge this PR until tomorrow ;) 2020년 11월 24일 (화) 오후 10:08, Stéfane Fermigier 님이 작성: > > > On Tue, Nov 24, 2020 at 12:51 PM Victor Stinner > wrote: > >> >> I never used this module, I don't know what it is. >> > > I've run a quick search on GitHub and the only meaningful reference I > could find is the Grail browser (which had its last release, AFAICT, in > 1999). > > http://grail.sourceforge.net/ > > S. > > -- > Stefane Fermigier - http://fermigier.com/ - http://twitter.com/sfermigier > - http://linkedin.com/in/sfermigier > Founder & CEO, Abilian - Enterprise Social Software - > http://www.abilian.com/ > Chairman, National Council for Free & Open Source Software (CNLL) - > http://cnll.fr/ > Founder & Organiser, PyParis & PyData Paris - http://pyparis.org/ & > http://pydata.fr/ > ___ 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/RPKOFZ6NZIIIF665UBVD3PKD4XUMJMSN/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Remove formatter module
On Tue, Nov 24, 2020 at 12:51 PM Victor Stinner wrote: > > I never used this module, I don't know what it is. > I've run a quick search on GitHub and the only meaningful reference I could find is the Grail browser (which had its last release, AFAICT, in 1999). http://grail.sourceforge.net/ S. -- Stefane Fermigier - http://fermigier.com/ - http://twitter.com/sfermigier - http://linkedin.com/in/sfermigier Founder & CEO, Abilian - Enterprise Social Software - http://www.abilian.com/ Chairman, National Council for Free & Open Source Software (CNLL) - http://cnll.fr/ Founder & Organiser, PyParis & PyData Paris - http://pyparis.org/ & http://pydata.fr/ ___ 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/FNMTOX37DMZLCJEHQ55VZO7K4PQHPL7B/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Remove formatter module
On Tue, Nov 24, 2020 at 10:59 AM Stéfane Fermigier wrote: > I've run a quick search on GitHub and the only meaningful reference I could > find is the Grail browser (which had its last release, AFAICT, in 1999). > > http://grail.sourceforge.net/ Oh, the memories! Looking at docs, I can vaguely recall using the API, but... it definitely doesn't belong in the stdlib. -Fred -- Fred L. Drake, Jr. "There is nothing more uncommon than common sense." --Frank Lloyd Wright ___ 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/2IBAT5XCAX4WZ4RHUR22IZ5A2B3U7KPW/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Distro packagers: PEP 615 and the tzdata dependency
> I'd love to have an easy way to keep them in the loop. I'm one of the maintainers on https://github.com/docker-library/python (which is what results in https://hub.docker.com/_/python), and I'd love to have an easy way to keep myself in the loop too! O:) Is there a lower-frequency mailing list where things like this are normally posted that I could follow? (I don't want to be a burden, although we'd certainly really love to have more upstream collaboration on that repo -- we do our best to represent upstream as correctly/accurately as possible, but we're not experts!) > would it make sense to add a packaging section to our documentation or > to write an informational PEP? FWIW, I love the idea of an explicit "packaging" section in the docs (or a PEP), but I've maintained that for other projects before and know it's not always easy or obvious. :) ♥, - Tianon 4096R / B42F 6819 007F 00F8 8E36 4FD4 036A 9C25 BF35 7DD4 PS. thanks doko for giving me a link to this thread! :D ___ 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/MVGTU4WY6VHPBQCWVQTQ3VJ44RWDINYC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Distro packagers: PEP 615 and the tzdata dependency
If enough people were interested we could create a "Distributors" category on discuss.python.org. On Tue, Nov 24, 2020 at 9:08 AM Tianon Gravi wrote: > > I'd love to have an easy way to keep them in the loop. > > I'm one of the maintainers on https://github.com/docker-library/python > (which is what results in https://hub.docker.com/_/python), and I'd > love to have an easy way to keep myself in the loop too! O:) > > Is there a lower-frequency mailing list where things like this are > normally posted that I could follow? > (I don't want to be a burden, although we'd certainly really love to > have more upstream collaboration on that repo -- we do our best to > represent upstream as correctly/accurately as possible, but we're not > experts!) > > > would it make sense to add a packaging section to our documentation or > > to write an informational PEP? > > FWIW, I love the idea of an explicit "packaging" section in the docs > (or a PEP), but I've maintained that for other projects before and > know it's not always easy or obvious. :) > > ♥, > - Tianon > 4096R / B42F 6819 007F 00F8 8E36 4FD4 036A 9C25 BF35 7DD4 > > PS. thanks doko for giving me a link to this thread! :D > ___ > 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/MVGTU4WY6VHPBQCWVQTQ3VJ44RWDINYC/ > 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/BT2E5SN3NMWGB26SM36FGHPBHIK5GKTD/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Advantages of pattern matching - a simple comparative analysis
David Mertz wrote:
> On Mon, Nov 23, 2020 at 9:02 PM Brian Coleman brianfcole...@gmail.com
> wrote:
> > Basically, I
> > agree matching/destructuring is a powerful idea. But I also
> > wonder how much genuinely better it is than a library that does not
> > require
> > a language change. For example, I could create a library to allow this:
> > m = Matcher(arbitrary_expression)
> > if m.case("StringNode(s)"):
> > process_string(m.val.s)
> > elif m.case("[a, 5, 6, b]"):
> > process_two_free_vars(m.val.a, m.val.b)
> > What you are proposing here is very similar in effect to executing pattern
> > matching statements using eval. What is the advantage of implementing the
> > pattern matching functionality in a library if the user interface for that
> > functionality has the same pitfalls as eval?
> > I don't understand the similarity with eval that you are
> suggesting.
> My hypothetical library would store the value passed as initializer to
> Matcher, and provide a method .case(). That method would need
> to do
> some moderately complicated parsing of the pattern passed into it, but
> using parsing techniques, not any eval() call. Btw. I modified my above
> strawman just slightly to what might be a bit better API.
> If there are any free variables in the pattern, they would be provided by
> the Matcher object. For example, they could be attributes of the property
> m.val. Or I suppose we could make them attributes of the Matcher object
> itself, e.g. m.a and m.b, but I think name conflicts with e.g.
> m.case. Anyway, it's a strawman not an API design.
> If the pattern looked kinda like a class constructor (i.e. exactly the same
> as PEP 634 rules), the .case() method would do an isinstance()
> check
> before doing its other stuff. If the pattern looks like a list, it would
> scan the freevars inside it and match the constant values. And so on.
> The actual return value from .m.case(...) would be True or False (or at
> least something truthy or falsy). However, it MIGHT create some new
> attributes (or keys, or something else) on the Matcher object if the
> pattern actually matched.
> I agree the above is slightly less readable than PEP 635 syntax, but it
> seems to have the entire power of the proposal without changing Python
> syntax.
Because syntax errors in the patterns passed to the `case` method are detected
at runtime, rather than at compile time, it is necessary to ensure that you
have code coverage of every call to a `case` method to be confident that there
are no syntax errors in the patterns.
By comparison, if the pattern matching syntax is built into the language, the
compiler will detect syntax errors in any and all patterns in `case` clauses. I
think that this is a major advantage as compared to implementing pattern
matching via a library.
___
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/Y4YU3QMQC6XYD6PAGFPGXNT6WZKDP7C4/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] A question about pattern matching
Excuse me, I have a question about pattern matching: is it used often in math language as Mathematica? May it help to translate code from such languages to Python? ___ 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/O3NFEFY56H7PDP57JOCWJXPIV24YU2LU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: A question about pattern matching
On 11/24/2020 4:40 PM, Marco Sulla wrote: I have a question about pattern matching: is it used often in math language as Mathematica? Yes, pattern matching is absolutely fundamental to Mathematica. See the `MatchQ` function: https://reference.wolfram.com/language/ref/MatchQ.html This works brilliantly. I would love for Python to rely on a function to test for matches. To see what match-based actions could then look like, take a look at `Replace`: https://reference.wolfram.com/language/ref/Replace.html fwiw, Alan Isaac ___ 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/VB4Y7CDVKGVNJNRG2NYHMFIJZAEO7OHW/ Code of Conduct: http://python.org/psf/codeofconduct/
