Here's one argument why sequence unpacking is more important than dict
unpacking.
Without sequence unpacking, you have a long sequence, to get at a specific
item you'd need to use indexing, where you often end up having to remember
the indices for each type of information. Say you have points of t
I must say I can't really see the point either. If you say like:
> {'a': a, 'b': b, **c} = {'a': 1, **{'b': 2}}
Do you basically mean:
c = {'a': 1, **{'b': 2}}
a = c.pop("a")
b = c.pop("b") # ?
That's the only thing I could think of.
I think most of these problems could be solved with pop a
On Tue, Apr 10, 2018 at 03:29:08PM +0800, Thautwarm Zhao wrote:
> I'm focused on the consistency of the language itself.
Consistency is good, but it is not the only factor to consider. We must
guard against *foolish* consistency: adding features just for the sake
of matching some other, often b
Your library seems difficult to extract values from nested dictionary, and
when the key is not an identifier it's also embarrassed.
For sure we can have a library using graphql syntax to extract data from
the dict of any schema, but that's not my point.
I'm focused on the consistency of the lan
On 9 April 2018 at 22:10, Brett Cannon wrote:
>
>
> On Mon, 9 Apr 2018 at 05:18 Joao S. O. Bueno wrote:
>>
>> we could even call this approach a name such as "function call".
>
>
> The harsh sarcasm is not really called for.
Indeed - on rereading, I have to agree on that.
I do apologize for th
On Mon, 9 Apr 2018 at 05:18 Joao S. O. Bueno wrote:
> I have an idea for an inovative, unanbiguous, straightforward and
> backwards compatible syntax for that,
> that evena llows one to pass metadata along the operation so that the
> results can be tweaked acording
> to each case's needs.
>
> Wha
I have an idea for an inovative, unanbiguous, straightforward and
backwards compatible syntax for that,
that evena llows one to pass metadata along the operation so that the
results can be tweaked acording
to each case's needs.
What about:
new_data = dict_feed({
"direct": "some data",
There was a long thread last year on a subject, titled "Dictionary
destructing and unpacking.":
https://mail.python.org/pipermail/python-ideas/2017-June/045963.html
You might want to read through it and see what ideas and problems were
raised then.
In that discussion, there's also a link to a
And this should print:
'some data'
1
2
3
On Sat, Apr 7, 2018 at 4:16 PM, Nikolas Vanderhoof <
nikolasrvanderh...@gmail.com> wrote:
> This would be a very handy feature, but Coconut (which is just python with
> some extra functional-style features) also has support for this kind of
> pattern-matc
Although that particular example once compiled to python will generate many
many lines of code:
On Sat, Apr 7, 2018 at 4:17 PM, Nikolas Vanderhoof <
nikolasrvanderh...@gmail.com> wrote:
> And this should print:
>
> 'some data'
> 1
> 2
> 3
>
> On Sat, Apr 7, 2018 at 4:16 PM, Nikolas Vanderhoof
This would be a very handy feature, but Coconut (which is just python with
some extra functional-style features) also has support for this kind of
pattern-matching:
http://coconut-lang.org
Since Coconut will compile to Python (2 or 3) you can just write in
Coconut and use the resulting code in y
We know that Python support the destructing of iterable objects.
m_iter = (_ for _ in range(10))
a, *b, c = m_iter
That's pretty cool! It's really convenient when there're many corner cases to
handle with iterable collections.
However destructing in Python could be more convenient if we support di
12 matches
Mail list logo