Hello,
On Mon, 16 Nov 2020 08:39:30 +1100
Steven D'Aprano wrote:
[]
> > The baseline of my version is much simpler:
> >
> > # This makes "const" a kind of hard keyword for this module
> > from __future__ import const
> >
> > FOO: const = 1 # obviously, this is constant
> Oh, well,
To
Jim J. Jewett writes:
> What advantage can there be in re-using syntax to mean something
> opposite to what it normally does?
In math, it allows us to write "solve c = f(x) for x". That doesn't
mean "bind c to the value f(x)", it means exactly the opposite. No
problem here, I suppose. So
case mylib.STATUS_OK, >result:
case mylib.STATUS_OK, >>result:
case mylib.STATUS_OK, ->result:
The second problem with those is that ">" has a very strong tie to "greater
than".
I think -> or even >> *might* be enough to overcome that, but I'm not
comfortable.
(The first problem, of
Matching *should* look like instantiation ...
case Point(2, 4)
*should* mean "Does it match the object that Point(2, 4) would create?".
case Point(2, y=4)
is less crucial, because they *could* rewrite the call -- but why should they
have to? Changing from constants, and
case
On 15/11/20 10:48 pm, Paul Sokolovsky wrote:
> [from PEP 635]
Pattern matching is complimentary to the object-oriented paradigm.
BTW, there seems to be a typo here -- I think it's
meant to be "complementary".
please explain why you chose to proceed anyway (and apply workarounds),
instead of
On Sun, Nov 15, 2020 at 03:18:29PM +0300, Paul Sokolovsky wrote:
> > > amount of work to implement pattern matching is certainly an order
> > > of magnitude larger than to introduce constants
[...]
[Steve]
> > Here's a toy proposal,
> []
>
> The baseline of my version is much simpler:
>
> #
Hello,
On Sun, 15 Nov 2020 16:58:09 +
MRAB wrote:
[]
> >> Pattern matching is complimentary to the object-oriented
> >> paradigm.
> >
> That looks like a mistake to me; it should be "complementary".
This way or that, my point is that even the word "orthogonal" wouldn't
give it
Reminder: the deadline for nomination is tonight, hurry up ;-)
Current candidates can be found at:
https://discuss.python.org/c/core-dev/steering-council-nominations/21
Victor
Le mer. 28 oct. 2020 à 20:55, Ewa Jodlowska a écrit :
>
> Hi!
>
> The timeline for this year's election will be the
Le sam. 14 nov. 2020 à 14:43, Nick Coghlan a écrit :
> > My remaining problem is that my PR changes PyConfig_Read(): it no
> > longer computes the Python Path Configuration, since it is now
> > implemented in Python. IMO it's an acceptable drawback compared to the
> > benefit of these new
On 2020-11-15 09:48, Paul Sokolovsky wrote:
Hello,
As was mentioned many times on the list, PEP634-PEP636 are thoroughly
prepared and good materials, many thanks to their authors. PEP635
"Motivation and Rationale" (https://www.python.org/dev/peps/pep-0635/)
stands out among the 3 however: while
Complimentary != Complementary
On Sun, Nov 15, 2020, 4:51 AM Paul Sokolovsky wrote:
> Hello,
>
> As was mentioned many times on the list, PEP634-PEP636 are thoroughly
> prepared and good materials, many thanks to their authors. PEP635
> "Motivation and Rationale"
Hello Tobias,
On Sun, 15 Nov 2020 13:22:07 +0100
Tobias Kohn wrote:
> Hi Paul,
>
> Thank you for your comments on the DLS'20 paper. I am glad to hear
> that it helps paint a clear(er) picture of pattern matching in
> Python. However, please let me set the record straight in a few
>
Hi Paul,
Thank you for your comments on the DLS'20 paper. I am glad to hear
that it helps paint a clear(er) picture of pattern matching in
Python. However, please let me set the record straight in a few
regards.
First, there is no 'shoehorning' or 'deception' in our pattern
matching
Hello,
On Sun, 15 Nov 2020 22:05:46 +1100
Steven D'Aprano wrote:
> On Sun, Nov 15, 2020 at 12:48:50PM +0300, Paul Sokolovsky wrote:
>
> > Just to give one example, literally at the very beginning, at the
> > "Pattern Matching and OO" section (3rd heading) it says:
>
> If it's the third
On Sun., 15 Nov. 2020, 5:25 pm Guido van Rossum, wrote:
> But Point(x as a) already has a meaning in PEP 634; it’s a positional
> argument captured in x *and* in a. (Previously spelled as Point(a := x).
> The phrase ‘as a’ can be added after any pattern to *also* capture it in
> ‘a’. More
On Sun, Nov 15, 2020 at 12:48:50PM +0300, Paul Sokolovsky wrote:
> Just to give one example, literally at the very beginning, at the
> "Pattern Matching and OO" section (3rd heading) it says:
If it's the third heading, it's not *literally* at the very beginning.
> > Pattern matching is
Hello,
As was mentioned many times on the list, PEP634-PEP636 are thoroughly
prepared and good materials, many thanks to their authors. PEP635
"Motivation and Rationale" (https://www.python.org/dev/peps/pep-0635/)
stands out among the 3 however: while reading it, chances that you'll
get a feeling
Hello,
On Sun, 15 Nov 2020 00:22:01 -0500
Kyle Stanley wrote:
[]
> FWIW, I'd like to add my +1 to usage of "as" for spelling class
> capture patterns.
If you want to use "as" in spelling of class capture patterns, you
don't need to worry about anything, because PEP634 already allows that:
18 matches
Mail list logo
