On Fri, 23 Oct 2020 at 08:06, Random832 wrote:
> On Thu, Oct 22, 2020, at 21:00, Steven D'Aprano wrote:
> I suspect that calling this particular syntax ugly is picking at a bit of
> an open wound in the history f-string implementation... consider precisely
> why the escaping syntax is {{}} instea
On Thu, Oct 22, 2020 at 09:11:57PM -0700, Guido van Rossum wrote:
> Oh, that's quite different than mapping patterns in PEP 634. :-(
That wasn't intentional, and to be honest I hadn't noticed the mapping
patterns in 634 as yet. (There's a lot in that PEP.)
Having read that now, I think I see th
On Fri, 23 Oct 2020 at 06:59, Henk-Jaap Wagenaar
wrote:
>
> On Fri, 23 Oct 2020 at 06:35, Random832 wrote:
>>
>> Does anyone else remember when xkcd first mentioned python? The main selling
>> point it had for it [and the one that was actually literally true, vs
>> 'import antigravity' which wa
On Fri, Oct 23, 2020 at 5:27 AM Steven D'Aprano wrote:
> Background
> --
>
> Iterable unpacking assignment:
>
> values = (1, 2, 3)
> a, b, c = *values
>
> is a very successful and powerful technique in Python.
>
Your proposed syntax seems to rest on being similar to this syntax f
On Fri, Oct 23, 2020 at 10:19:07AM +0200, Alex Hall wrote:
> On Fri, Oct 23, 2020 at 5:27 AM Steven D'Aprano wrote:
>
> > Background
> > --
> >
> > Iterable unpacking assignment:
> >
> > values = (1, 2, 3)
> > a, b, c = *values
> >
> > is a very successful and powerful technique i
For what it's worth, I was just writing the following today, and Steven's
proposal came to mind.
If we ignore the set of questionable (but realistic) decisions that led to
me having to do the following, and the discussion on how the unpacking
syntax would look:
---[ wot I wrote ] ---
if reque
On Fri, 23 Oct 2020 at 09:39, Steven D'Aprano wrote:
> Using PEP 634 syntax, I could write:
>
>
> def method(self, **kwargs):
> {'spam': spam, 'eggs': eggs, **kw} = **kwargs
> process(spam, eggs)
> super().method(**kw)
>
I like that.
__
On Fri, 23 Oct 2020 at 10:18, Marco Sulla wrote:
>
> On Fri, 23 Oct 2020 at 09:39, Steven D'Aprano wrote:
>>
>> Using PEP 634 syntax, I could write:
>>
>>
>> def method(self, **kwargs):
>> {'spam': spam, 'eggs': eggs, **kw} = **kwargs
>> process(spam, eggs)
>> super().
On Fri, Oct 23, 2020 at 11:10 AM Steven D'Aprano
wrote:
> > but that doesn't make it make sense to write `... = **values` as you
> > suggest.
>
> Iterator unpacking on a dict already works:
>
> py> d = {'a': 10, 'b': 20}
> py> spam, eggs = d
> py> spam, eggs
> ('a', 'b')
>
> so we
On Fri, Oct 23, 2020 at 02:23:58AM -0400, David Mertz wrote:
> See my very detailed posts on EXACTLY the concepts you discuss.
>
> "whether 'bar' is a name"? It is definitely a name, what you have no means
> > to know is whether it has been assigned a value. I suspect you're trying to
> > do the t
Fwiw, although I see how PEP 634 has the potential to be incredibly
powerful and I'm not opposed to it, I've tried to read and understand it
twice and it is so overwhelming I still find the syntax inscrutable (I'm
sure I'll get it eventually). I think Steven's proposed idea has a lot of
merit even
On Fri, Oct 23, 2020, 5:41 AM Alex Hall wrote:
> On Fri, Oct 23, 2020 at 11:10 AM Steven D'Aprano
> wrote:
>
>> > but that doesn't make it make sense to write `... = **values` as you
>> > suggest.
>>
>> Iterator unpacking on a dict already works:
>>
>> py> d = {'a': 10, 'b': 20}
>> py> s
SUMMARY:
I share with you extracts from a personal email Rick Teachey sent me, on my
involvement in PEP 637 (keyword arguments in item access), and my answers
to some important questions he asks.
BACKGROUND:
Last week, prior to my publicly stating my resignation as a co-author of
PEP 637, Ricky Te
On Fri, Oct 23, 2020, 5:44 AM Alex Hall
> (Heretical question: do we *really* need to distinguish it in syntax?
> Iterator unpacking a dict seems like a dumb idea, I wouldn't be sad if we
> broke compatibility there)
>
Breaking millions of lines of idiomatic code seems like a bad idea.
a, b, c =
Jonathan thanks for your desire to make PEP 637, and kwd arguments in
subscripting in general, as good as possible.
I am bowing out of the conversation from this point on though. I am very
happy you found my comments helpful and if there is a second competing PEP,
I'll be very interested to read i
On Fri, Oct 23, 2020 at 5:43 PM David Mertz wrote:
> On Fri, Oct 23, 2020, 5:44 AM Alex Hall
>
>> (Heretical question: do we *really* need to distinguish it in syntax?
>> Iterator unpacking a dict seems like a dumb idea, I wouldn't be sad if we
>> broke compatibility there)
>>
>
> Breaking millio
On Fri, Oct 23, 2020, 1:28 PM Alex Hall
> Breaking millions of lines of idiomatic code seems like a bad idea.
>>
>> a, b, c = mydict
>>
>> Mary not be so very common, but this is ubiquitous:
>>
>> for k in mydict: ...
>>
>
> What I mean is that maybe `a, b = foo` could first test if `foo` is a
> m
On Thu, Oct 22, 2020 at 11:08 PM Random832 wrote:
> (with the PEG parser, incidentally, I wonder if it may be time to revisit
> certain limitations in f-string syntax, though that particular one
> technically presents a backward compatibility problem that the rest don't)
>
That's been worked on
That makes me think of ruby where you can omit some of the function call.
On Wed, Jun 10, 2020, 02:08 Guido van Rossum wrote:
> In Python 3.10 we will no longer be burdened by the old parser (though 3rd
> party tooling needs to catch up).
>
> One thing that the PEG parser makes possible in about
Pattern-matching is great. I think PEP 634 is on the right track, but it
would be a waste to only use pattern-matching for choosing a branch in a
match statement.
Let’s look at Rust:
if let [x, y] = my_array {
...
}
Rust "if let" constructs are an alternative to full-blown mat
If you look in PEP 622 you'll see that there was a rejected idea `if match
...` that's pretty similar. We nixed it because it just made the PEP
larger. For 3.11 we can consider something like this.
On Fri, Oct 23, 2020 at 4:12 PM Valentin Berlier
wrote:
> Pattern-matching is great. I think PEP 6
On 2020-10-23 23:25, Valentin Berlier wrote:
Pattern-matching is great. I think PEP 634 is on the right track, but it
would be a waste to only use pattern-matching for choosing a branch in a
match statement.
Let’s look at Rust:
if let [x, y] = my_array {
...
}
Rust "if le
22 matches
Mail list logo
