On 26/06/20 1:08 pm, Paul Svensson wrote:
We already allow (x, x) = (1, 2)
So, why do we need to disallow binding several values to the same name ?
I think it was done because people might expect that to match
only if the *same* value appears in both places. Some other
languages have pattern ma
On 26/06/20 2:10 pm, Gregory P. Smith wrote:
match get_shape() as shape:
case start, end := Line@(shape):
This looks just as inscrutable to me in its own way.
--
Greg
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an emai
On 26/06/20 2:18 pm, Gregory P. Smith wrote:
Regardless i don't see how an anti-pep would work much better, but I
also don't see anything stopping anyone from trying one. I worry that
it'll fragment conversation even more and separate discussions so that
everyone is even more confused about ov
On 26/06/20 5:45 pm, Ned Deily wrote:
Hasn't "|" been used in a similar way for decades in Unix/POSIX shell patterns,
including with the shell case statement?
Yes, but I regard Unix shell syntaxes as just plain weird
and not a good model for designing a language on.
--
Greg
__
On 26/06/20 6:21 am, Pablo Galindo Salgado wrote:
Which means that users can do a positional match against the proxy with
a name pattern:
match input:
case datetime.date(dt):
print(f"The date {dt.isoformat()}"
I think that would be an incorrect way for matching on datetime
to be
Some proof-reading of the PEP. I apologise if this is out of date.
1) In the beginning of the "Mapping Pattern" section:
"{" (pattern ":" pattern)+ "}"
This is spelt inconsistently: there is a `+` before the closing `}`
but not after the opening `{`.
2) The second code snippe
On Fri, Jun 26, 2020 at 12:42 AM Rob Cliffe via Python-Dev <
python-dev@python.org> wrote:
> 1) In the beginning of the "Mapping Pattern" section:
> "{" (pattern ":" pattern)+ "}"
> This is spelt inconsistently: there is a `+` before the closing `}`
> but not after the opening `{`
On Fri, 26 Jun 2020 at 02:42, Raymond Hettinger
wrote:
>
> > it is hard to make a decision between the pros and cons,
> > when the pros are in a single formal document and the
> > cons are scattered across the internet.
>
> Mark, I support your idea. It is natural for PEP authors to not fully
>
On Fri, 26 Jun 2020 at 03:37, Gregory P. Smith wrote:
>
> Litmus test: Give someone who does not know Python this code example from the
> PEP and ask them what it does and why it does what it does:
>
> match get_shape():
> case Line(start := Point(x, y), end) if start == end:
> print(
[apologies for the duplicate to Guido, used reply instead of reply to all]
To summarize my previous unanswered post, I posted a +1 to the "defaulting
to binding vs interpreting NAME as a constant" is a dangerous default. And
I submitted a couple of alternate syntactic ways to denote "capture is
de
On Fri, 26 Jun 2020 at 11:29, Daniel Moisset wrote:
>
> I think roughly half of the uses will actually be for "the switch statement
> we never had", where all branches would be constants. I've been writing a lot
> of code like that these last couple of weeks, so I may be biased (although
> the
Just a minor editorial thing on the PEP text:
The section https://www.python.org/dev/peps/pep-0622/#case-clauses presents
a simplified syntax. That one mentions "group_pattern", but the document
never mentions (in prose) what a group pattern is. It confused me until I
found the definition in the f
On Fri, Jun 26, 2020 at 3:47 AM Paul Moore wrote:
> For me, this prompts the question (which I appreciate is more about
> implementation than design) - would there be any (significant)
> performance difference between [...]
> In C, the switch statement was explicitly intended to be faster by
>
On 25/06/2020 23:20, Emily Bowman wrote:
On my personal "potentially inscrutable uses of a tool" this still rates
well below list comprehensions, so there's that; the biggest pet peeve I
Clearly YMMV. To me list comprehensions like "[f(x) for x in l]" were
obviously related to the "f(x) ∀ x ∊
This one is new but I think unrelated and unmentioned:
Why is the mapping match semantics non-strict about keys? Besides the
"asymmetry" with sequence matches, I think a strict match should be useful
sometimes (quickly deconstructing JSON data comes to my mind, where I want
to know that I didn't g
,Hi Carl,
Le ven. 26 juin 2020 à 07:36, Carl Shapiro a écrit :
> It would be very helpful to broaden the objective of avoiding functions
> returning PyObject** to other types of pointers. I have in mind several
> functions in the C-API that return a char* pointer to the contents of an
> objec
On 23/06/2020 20:35, Chris Angelico wrote:
On Wed, Jun 24, 2020 at 5:30 AM Rob Cliffe via Python-Dev
wrote:
The PEP is great, but this strikes me as horribly confusing, given that
401|403|404 is already legal syntax.
IIUC any legal expression can come between `case` and `:`, but expressions
Hi,
For a PEP to succeed it needs to show two things.
1. Exactly what problem is being solved, or need is to be fulfilled, and
that is a sufficiently large problem, or need, to merit the proposed change.
2. That the proposed change is the best known solution for the problem
being addressed.
Yes, my brain went through the same path.
Another minor nitpick: It would be kinda nice if the various types of
pattern were listed in the grammar in the same order as the
corresponding paragraphs subsequently appear.
On 26/06/2020 11:53, Daniel Moisset wrote:
Just a minor editorial thing on
On Fri, 26 Jun 2020 at 09:07, Greg Ewing
wrote:
> On 26/06/20 2:10 pm, Gregory P. Smith wrote:
> > match get_shape() as shape:
> >case start, end := Line@(shape):
>
> This looks just as inscrutable to me in its own way.
>
Absolutely, but that's kind of the point I think: no possible way to
u
On Fri, Jun 26, 2020 at 3:38 PM Mark Shannon wrote:
>
> What does "static and dynamic specifications" mean? Surely, there are
> just specifications.
>
There are specifications for both the runtime and the static aspects of the
Python programming language.
> Python does not have a static checki
On 2020-06-26 16:54, Stéfane Fermigier wrote:
[...]
Here's one example:
https://github.com/clojure/core.match (in particular:
https://github.com/clojure/core.match/wiki/Understanding-the-algorithm ).
Alson some insights from
https://softwareengineering.stackexchange.com/questions/237023/pa
On Thu, Jun 25, 2020 at 7:29 PM Gregory P. Smith wrote:
>
> On Thu, Jun 25, 2020 at 6:49 PM Raymond Hettinger <
> raymond.hettin...@gmail.com> wrote:
>
>> > it is hard to make a decision between the pros and cons,
>> > when the pros are in a single formal document and the
>> > cons are scattered
On Thu, Jun 25, 2020 at 1:37 PM Chris Jerdonek
wrote:
> On Thu, Jun 25, 2020 at 11:52 AM Brett Cannon wrote:
>
>> On Thu, Jun 25, 2020 at 5:45 AM Antoine Pitrou
>> wrote:
>>
>>> I don't think this really works. A PEP has to present a consistent
>>> view of the world, and works as a cohesive wh
ACTIVITY SUMMARY (2020-06-19 - 2020-06-26)
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:
open7490 (+14)
closed 45380 (+75)
total 52870 (+89)
Open issues wi
On Tue, Jun 23, 2020 at 7:52 AM Stefan Behnel wrote:
> I agree that this is more explicit when it comes to resource management,
> but there is nothing that beats direct native data structure access when it
> comes to speed.
>From the perspective of the function that wants to get access to the
c
Victor Stinner schrieb am 26.06.20 um 14:39:
> Well, the general problem is to track when the caller ends using a resource.
Although that is less of a problem if you only allow exposing the internal
data representation and nothing else. In that case, you can tie the
lifetime of the data access to
On Fri, Jun 26, 2020 at 6:42 AM Mark Shannon wrote:
>
> > Let us start from some anecdotal evidence: isinstance() is one of the
> most called functions in large scale Python code-bases (by static call
> count). In particular, when analyzing some multi-million line production
> code base, it was d
28 matches
Mail list logo
