05.05.18 09:23, Tim Peters пише:
[Tim]
... I liked the way he _reached_ that conclusion: by looking at real-
life Python code that may have been written instead to use constructs
"like this". I find such examination far more persuasive than abstract
arguments or made-up examples.
[Serhiy Sto
[Tim]
>> ... I liked the way he _reached_ that conclusion: by looking at real-
>> life Python code that may have been written instead to use constructs
>> "like this". I find such examination far more persuasive than abstract
>> arguments or made-up examples.
[Serhiy Storchaka ]
> I would like t
On Fri, May 4, 2018 at 6:56 PM, Alexander Belopolsky
wrote:
> On Fri, May 4, 2018 at 8:06 AM, Nick Coghlan wrote:
>> ...
>> With that spelling, the three examples above would become:
>>
>> # Exactly one branch is executed here
>> if m given m = pattern.search(data):
>> ...
>>
[Nick Coghlan ]
> ...
> The essence of the given clause concept would be to modify *these specific
> cases* (at least initially) to allow the condition expression to be followed
> by an inline assignment, of the form "given TARGET = EXPR".
I'm not clear on what "these specific cases" are, specific
On Fri, May 4, 2018 at 8:06 AM, Nick Coghlan wrote:
> ...
> With that spelling, the three examples above would become:
>
> # Exactly one branch is executed here
> if m given m = pattern.search(data):
> ...
> elif m given m = other_pattern.search(data)):
> ...
> else
On Fri, May 4, 2018 at 2:58 PM, Guido van Rossum wrote:
> First, "start executing immediately" is an overstatement, right? They won't
> run until the caller executes a (possibly unrelated) `await`.
Well, traditional Future-returning functions often do execute some
logic immediately, but right, wh
First, "start executing immediately" is an overstatement, right? They won't
run until the caller executes a (possibly unrelated) `await`. And I'm still
unclear why anyone would care, *except* in the case where they've somehow
learned by observation that "real" coroutines don't start immediately and
Hi all,
This is a bit of a wacky idea, but I think it might be doable and have
significant benefits, so throwing it out there to see what people
think.
In asyncio, there are currently three kinds of calling conventions for
asynchronous functions:
1) Ones which return a Future
2) Ones which retur
I hope Python never has to go there. It's a tooling nightmare.
On Fri, May 4, 2018 at 2:11 PM, Nathaniel Smith wrote:
> On Fri, May 4, 2018 at 1:53 PM, Tim Peters wrote:
> > [Tim]
> >>> ...
> >>> It's no longer the case that Python avoided that entirely, since
> >>> "async def", "async for", an
On Fri, May 4, 2018 at 1:53 PM, Tim Peters wrote:
> [Tim]
>>> ...
>>> It's no longer the case that Python avoided that entirely, since
>>> "async def", "async for", and "async with" statements were added
>>> _without_ making "async" a new reserved word. It may require pain in
>>> the parser, but
[Tim]
>> ...
>> It's no longer the case that Python avoided that entirely, since
>> "async def", "async for", and "async with" statements were added
>> _without_ making "async" a new reserved word. It may require pain in
>> the parser, but it's often doable anyway. At this stage in Python's
>> li
On Sat, May 5, 2018 at 5:27 AM, Matt Arcidy wrote:
>> I'd also say that the difficulty of Googling for the meaning of ":="
>> shouldn't be exaggerated. Currently you can search for "python operators"
>> and get tons of sites that list all operators.
>
>
> Without adding hits to the search algorith
On Fri, May 4, 2018, 11:35 Guido van Rossum wrote:
> On Fri, May 4, 2018 at 11:11 AM, Tim Peters wrote:
>
>> [Nick Coghlan ]
>> > ...
>> > Using a new keyword (rather than a symbol) would make the new construct
>> > easier to identify and search for, but also comes with all the
>> downsides of
>
On Fri, May 4, 2018 at 11:11 AM, Tim Peters wrote:
> [Nick Coghlan ]
> > ...
> > Using a new keyword (rather than a symbol) would make the new construct
> > easier to identify and search for, but also comes with all the downsides
> of
> > introducing a new keyword.
>
> That deserves more thought.
04.05.18 20:48, Tim Peters пише:
[Guido]
Can I recommend going slow here? This is a very interesting topic where many
languages have gone before. I liked Daniel F Moisset's analysis about the
choices of a language designer and his conclusion that match should be a
statement.
Just to be annoyin
[Nick Coghlan ]
> ...
> Using a new keyword (rather than a symbol) would make the new construct
> easier to identify and search for, but also comes with all the downsides of
> introducing a new keyword.
That deserves more thought. I started my paying career working on a
Fortran compiler, a langua
[Guido]
> Can I recommend going slow here? This is a very interesting topic where many
> languages have gone before. I liked Daniel F Moisset's analysis about the
> choices of a language designer and his conclusion that match should be a
> statement.
Just to be annoying ;-) , I liked the way he _r
04.05.18 15:06, Nick Coghlan пише:
Recapping the use cases where the inline assignment capability received
the most agreement regarding being potentially more readable than the
status quo:
Sorry, but these examples don't look as good examples for inline
assignments to me. I think that all the
Thanks! Perhaps the most useful bit of this post is the clear list of use
cases (a useful summary of the motivational part of PEP 572).
On Fri, May 4, 2018 at 5:06 AM, Nick Coghlan wrote:
> (Note: Guido's already told me off-list that he doesn't like the way this
> spelling reads, but I wanted t
Can I recommend going slow here? This is a very interesting topic where
many languages have gone before. I liked Daniel F Moisset's analysis about
the choices of a language designer and his conclusion that match should be
a statement.
I just noticed the very similar proposal for JavaScript linked
On 2018-05-04 08:26, Jacco van Dorp wrote:
> Would this be valid?
>
> # Pattern matching with guards
> x = 'three'
>
> number = match x:
> 1 => "one"
> y if y is str => f'The string is {y}'
> z if z is int => f'the int is {z}'
> _ => "anything"
>
> print(number) # The string is
On Sat, May 5, 2018 at 12:45 AM, Daniel Moisset wrote:
>> (3) Unlike a case/switch statement, there's no implication that the
>> compiler could optimise the order of look-ups; it is purely top to
>> bottom.
>
>
> [we are talking about a multi-branch pattern matching statement now, not
> just "aptt
This email from Steve has some good questions, let me try to help organize
ideas:
On 4 May 2018 at 13:11, Steven D'Aprano wrote:
> I'll make a start, and you can correct me if I get any of it wrong.
>
> (1) Pattern matching takes a value, and compares it to a series of
> *patterns* until the fir
Note that most languages that you mentioned as references are functional
(so they don't have a statement/expression distinction like Python has),
and those that are not, have matching statements. The only exception is
Javascript, but in Javascript the distinction is not that
hard given that it has
On Thu, May 03, 2018 at 11:36:27AM -0700, Robert Roskam wrote:
> So I started extremely generally with my syntax, but it seems like I should
> provide a lot more examples of real use.
Yes, real-life examples will be far more compelling and useful than made
up examples and pseudo-code.
Also, I
(Note: Guido's already told me off-list that he doesn't like the way this
spelling reads, but I wanted to share it anyway since it addresses one of
the recurring requests in the PEP 572 discussions for a more targeted
proposal that focused specifically on the use cases that folks had agreed
were re
On Thu, May 03, 2018 at 09:04:40PM +0100, Ed Kellett wrote:
> On 2018-05-03 19:57, Chris Angelico wrote:
> > Got it. Well, I don't see why we can't use Python's existing primitives.
> >
> > def hyperop(n, a, b):
> > if n == 0: return 1 + b
> > if n == 1: return a + b
> > if n == 2: ret
Would this be valid?
# Pattern matching with guards
x = 'three'
number = match x:
1 => "one"
y if y is str => f'The string is {y}'
z if z is int => f'the int is {z}'
_ => "anything"
print(number) # The string is three
If so, why are y and z both valid here ? Is the match variab
28 matches
Mail list logo
