On 2018-04-12 18:03, Guido van Rossum wrote:
It's a slippery slope indeed. While having to change update() alone wouldn't
worry me, the subclass constructors do seem like they are going to want changing
too, and that's indeed a bit much. So let's back off a bit. Not every three
lines of code ne
I usually go with + only to find out that dict was something special
here. ;-)
Then, I use .update only to find out, that it's in-place and I need to
join more than two.
Then, I use some sort of dict comprehension or the dict constructor etc.
Naively, I would say + is what comes to mind easily.
Oh, I get it now, thanks!
On Fri, Apr 13, 2018 at 2:11 AM, Serhiy Storchaka
wrote:
> 12.04.18 22:42, Andrés Delfino пише:
>
>> I think the update method can (and personally, should) stay unchanged:
>>
>> spam.update(dict(x, y))
>>
>> seems succinct and elegant enough, with the proposed construct
12.04.18 22:42, Andrés Delfino пише:
I think the update method can (and personally, should) stay unchanged:
spam.update(dict(x, y))
seems succinct and elegant enough, with the proposed constructor syntax.
Sorry my ignorance, do (Mutable)Mapping ABC say anything about
constructors?
Mapping a
It's a slippery slope indeed. While having to change update() alone
wouldn't worry me, the subclass constructors do seem like they are going to
want changing too, and that's indeed a bit much. So let's back off a bit.
Not every three lines of code need a built-in shorthand.
On Thu, Apr 12, 2018 at
I think the update method can (and personally, should) stay unchanged:
spam.update(dict(x, y))
seems succinct and elegant enough, with the proposed constructor syntax.
Sorry my ignorance, do (Mutable)Mapping ABC say anything about
constructors?
On Thu, Apr 12, 2018 at 12:45 PM, Serhiy Storchak
There's a long thread about the subject:
https://mail.python.org/pipermail/python-ideas/2015-February/031748.html
I suggest to avoid the matter altogether :)
On Thu, Apr 12, 2018 at 4:15 PM, Mike Miller
wrote:
> While we're on the subject, I've tried to add dicts a few times over the
> years to
While we're on the subject, I've tried to add dicts a few times over the years
to get a new one but it doesn't work:
d3 = d1 + d2 # TypeError
Thinking a bit, set union is probably a better analogue, but it doesn't work
either:
d3 = d1 | d2 # TypeError
Where the last value of any du
09.04.18 00:18, Andrés Delfino пише:
I thought that maybe dict could accept several mappings as positional
arguments, like this:
class Dict4(dict):
def __init__(self, *args, **kwargs):
if len(args) > 1:
if not all([isinstance(arg, dict) for arg in args
12.04.18 17:34, Ed Kellett пише:
It allows for creating a flattened dict from an iterable of dicts, too,
which I've occasionally wanted:
configs = {'a': 'yes'}, {'b': 'no'}, {'c': 3}
dict(*configs)
{'a': 'yes', 'b': 'no', 'c': 3}
versus:
dict(chain.from_iterable(c.items() for c in configs))
On Thu, Apr 12, 2018 at 7:34 AM, Ed Kellett
wrote:
> On 2018-04-12 14:46, Andrés Delfino wrote:
> > Extending the original idea, IMHO it would make sense for the dict
> > constructor to create a new dictionary not only from several mappings,
> but
> > mixing mappings and iterables too.
> >
> > Co
On 2018-04-12 14:46, Andrés Delfino wrote:
> Extending the original idea, IMHO it would make sense for the dict
> constructor to create a new dictionary not only from several mappings, but
> mixing mappings and iterables too.
>
> Consider this example:
>
> x = [(1, 'one')]
> y = {2: 'two'}
>
> N
Extending the original idea, IMHO it would make sense for the dict
constructor to create a new dictionary not only from several mappings, but
mixing mappings and iterables too.
Consider this example:
x = [(1, 'one')]
y = {2: 'two'}
Now: {**dict(x), **y}
Proposed: dict(x, y)
I think this extensi
Ok, we can haggle the finer details and I admit once you learn the syntax it
isn't substantially harder. Simply, I've found the dict() a bit easier to
mentally parse at a glance. Also, to add I've always expected multiple args to
work with it, and am always surprised when it doesn't.
Would n
On Wed, Apr 11, 2018 at 2:44 PM, Steven D'Aprano wrote:
> On Wed, Apr 11, 2018 at 02:22:08PM +1000, Chris Angelico wrote:
>
>> > dict(d1, d2, d3)
>>
>> That's more readable than {**d1, **d2, **d3} ? Doesn't look materially
>> different to me.
>
> It does to me.
>
> On the one hand, we have a f
On Wed, Apr 11, 2018 at 02:22:08PM +1000, Chris Angelico wrote:
> > dict(d1, d2, d3)
>
> That's more readable than {**d1, **d2, **d3} ? Doesn't look materially
> different to me.
It does to me.
On the one hand, we have a function call (okay, technically a type...)
"dict()" that can be goog
On Wed, Apr 11, 2018 at 11:19 AM, Mike Miller wrote:
>
> On 2018-04-09 04:23, Daniel Moisset wrote:
>>
>> In which way would this be different to {**mapping1, **mapping2,
>> **mapping3} ?
>
>
> That's possible now, but believe the form mentioned previously would be more
> readable:
>
> dict(d1
On 2018-04-09 04:23, Daniel Moisset wrote:
In which way would this be different to {**mapping1, **mapping2, **mapping3} ?
That's possible now, but believe the form mentioned previously would be more
readable:
dict(d1, d2, d3)
-Mike
___
Pytho
No worries, already implemented features happens so often in this list that
there's a story about Guido going back in a time machine to implement them
;-)
Just wanted to check that I had understood what you suggested correctly
On 9 April 2018 at 12:42, Andrés Delfino wrote:
> Sorry, I didn't kn
Sorry, I didn't know that kwargs unpacking in dictionaries displays don't
raise a TypeError exception.
On Mon, Apr 9, 2018 at 8:23 AM, Daniel Moisset
wrote:
> In which way would this be different to {**mapping1, **mapping2,
> **mapping3} ?
>
> On 8 April 2018 at 22:18, Andrés Delfino wrote:
>
>
In which way would this be different to {**mapping1, **mapping2,
**mapping3} ?
On 8 April 2018 at 22:18, Andrés Delfino wrote:
> Hi!
>
> I thought that maybe dict could accept several mappings as positional
> arguments, like this:
>
> class Dict4(dict):
>> def __init__(self, *args, **kwargs)
21 matches
Mail list logo
