Is this what syncer does with a sync() function? Why isn't this a built-in?
https://github.com/miyakogi/syncer
On Wednesday, March 6, 2019, Nathaniel Smith wrote:
> Defining a single polymorphic function is easy at the library level.
> For example, with asyncio:
>
>
>
> def
dicttoolz has functions for working with these objects; including
dicttoolz.merge (which returns a reference to the merged dicts but does not
mutate the arguments passed).
https://toolz.readthedocs.io/en/latest/api.html#dicttoolz
I was doing some async networking and I wondered, why I have to use 2
different api for making the same things in async or sync regime.
Even if we make 2 perfectly identical api (except function will be sync and
async), it will still 2 different code).
So I first thinked to allow await in
On Tue, Mar 5, 2019 at 6:07 PM Raymond Hettinger <
raymond.hettin...@gmail.com> wrote:
>
> > On Mar 5, 2019, at 2:13 PM, Greg Ewing
> wrote:
> >
> > Rhodri James wrote:
> >> I have to go and look in the documentation because I expect the union
> operator to be '+'.
> >
> > Anyone raised on
> On Mar 5, 2019, at 2:13 PM, Greg Ewing wrote:
>
> Rhodri James wrote:
>> I have to go and look in the documentation because I expect the union
>> operator to be '+'.
>
> Anyone raised on Pascal is likely to find + and * more
> natural. Pascal doesn't have bitwise operators, so it
> re-uses
On Wed, Mar 6, 2019 at 12:08 AM Guido van Rossum wrote:
> On Tue, Mar 5, 2019 at 3:50 PM Josh Rosenberg <
> shadowranger+pythonid...@gmail.com> wrote:
>
>>
>> On Tue, Mar 5, 2019 at 11:16 PM Steven D'Aprano
>> wrote:
>>
>>> On Sun, Mar 03, 2019 at 09:28:30PM -0500, James Lu wrote:
>>>
>>> > I
On Tue, Mar 5, 2019 at 3:50 PM Josh Rosenberg <
shadowranger+pythonid...@gmail.com> wrote:
>
> On Tue, Mar 5, 2019 at 11:16 PM Steven D'Aprano
> wrote:
>
>> On Sun, Mar 03, 2019 at 09:28:30PM -0500, James Lu wrote:
>>
>> > I propose that the + sign merge two python dictionaries such that if
>> >
On Tue, Mar 5, 2019 at 11:16 PM Steven D'Aprano wrote:
> On Sun, Mar 03, 2019 at 09:28:30PM -0500, James Lu wrote:
>
> > I propose that the + sign merge two python dictionaries such that if
> > there are conflicting keys, a KeyError is thrown.
>
> This proposal is for a simple, operator-based
On Mon, Mar 04, 2019 at 08:01:38PM -0500, James Lu wrote:
>
> > On Mar 4, 2019, at 11:25 AM, Steven D'Aprano wrote:
> > Another example would be when reading command line options, where the
> > most common convention is for "last option seen" to win:
> >
> > [steve@ando Lib]$ grep
On Sun, Mar 03, 2019 at 09:28:30PM -0500, James Lu wrote:
> I propose that the + sign merge two python dictionaries such that if
> there are conflicting keys, a KeyError is thrown.
This proposal is for a simple, operator-based equivalent to
dict.update() which returns a new dict. dict.update
Actually, this was made even more condition-y in 3.8. Now we check __iter__
too:
D.update([E, ]**F) -> None. Update D from dict/iterable E and F.
If E is present, has a .keys() method, is a subclass of dict, and hasn't
overridden __iter__, then does: for k in E: D[k] = E[k]
If E is present, has
>
> Should our __sub__ behavior be the same...
Sorry, our "__isub__" behavior. Long day...
On Tue, Mar 5, 2019 at 2:47 PM Brandt Bucher wrote:
> These semantics are intended to match those of update as closely as
>> possible. For the dict built-in itself, calling keys is redundant as
>>
Christopher Barker wrote:
That violates an important convention in Python: mutating methods do not
return self. We really want to preserve that convention.
Smalltalk has an abbreviated way of writing a series of method
calls to the same object:
x doThis; doThatWith: y; doTheOther.
is
>
> These semantics are intended to match those of update as closely as
> possible. For the dict built-in itself, calling keys is redundant as
> iteration over a dict iterates over its keys; but for subclasses or other
> mappings, update prefers to use the keys method.
>
> The above paragraph may
Steven D'Aprano wrote:
The question is, is [recursive merge] behaviour useful enough and
> common enough to be built into dict itself?
I think not. It seems like just one possible way of merging
values out of many. I think it would be better to provide
a merge function or method that lets you
Rhodri James wrote:
I have to go and look in the documentation because I
expect the union operator to be '+'.
Anyone raised on Pascal is likely to find + and * more
natural. Pascal doesn't have bitwise operators, so it
re-uses + and * for set operations. I like the economy
of this arrangement
There was a thread for the topic.
https://mail.python.org/pipermail/python-dev/2018-October/155435.html
2019年3月6日(水) 2:02 Anders Hovmöller :
>
> On a related note: **kwargs, should they support arbitrary strings as
> keys? I depend on this behavior in production code and all python
>
On Tue, Mar 5, 2019 at 9:02 AM Anders Hovmöller wrote:
> On a related note: **kwargs, should they support arbitrary strings as
> keys? I depend on this behavior in production code and all python
> implementations handle it.
>
The ice is much thinner there, but my position is that as long as
I thank Guido and Christopher for their thoughtful comments. You
certainly found some weak points. I chose the name 'flow' to match:
https://en.wikipedia.org/wiki/Fluent_interface#Python
Instead of my previous
arg = defaults.copy().flow_update(options)
one could instead from somewhere import
> I'd like to remove all doubt: {**d1} needs to work regardless of the key
> type, as long as it's hashable (d1 could be some mapping implemented without
> hashing, e.g. using a balanced tree, so that it could support unhashable
> keys).
>
> If there's doubt about this anywhere, we could
On Tue, Mar 5, 2019 at 2:38 AM Inada Naoki wrote:
> On Tue, Mar 5, 2019 at 7:26 PM Steven D'Aprano
> wrote:
> >
> > On Sat, Mar 02, 2019 at 01:47:37AM +0900, INADA Naoki wrote:
> > > > If the keys are not strings, it currently works in CPython, but it
> may not work with other implementations,
On Tue, Mar 5, 2019 at 12:53 AM Jonathan Fine wrote:
> SUMMARY
> Instead of using dict + dict, perhaps use dict.flow_update. Here,
> flow_update is just like update, except that it returns self.
That violates an important convention in Python: mutating methods do not
return self. We really
On Tue, Mar 05, 2019 at 08:11:29AM -0500, David Shawley wrote:
> "Putting Metaclasses to Work" (ISBN-13 978-0201433050) presents a more
> mathematical view of programming language types that includes two
> distinct operations for combining dictionaries -- merge and recursive
> merge.
>
> For two
If you have to tell such a long and convoluted story to explain a name that
you've picked out of the blue and that has no equivalent in other Python
data types, it's probably a bad idea. If you're proposing that other
mutating methods also gain a flow_XXX variant, please, no! That's like the
On Mon, Mar 4, 2019 at 10:00 PM Steve Barnes wrote:
> If anybody is looking for such components then wx.DateTime
>
There has got to be a stand alone python library for that!
Anyone know the status of the venerable mxDateTime?
-CHB
--
Christopher Barker, PhD
Python Language Consulting
-
> Does anyone have an example of another programming language that
> allows for addition of dictionaries/mappings?
>
kotlin does that (`to` means `:`) :
fun main() {
var a = mutableMapOf("a" to 1, "b" to 2)
var b = mutableMapOf("c" to 1, "b" to 3)
println(a)
println(b)
On Mar 4, 2019, at 4:51 AM, Stefan Behnel wrote:
>
> I think the main intentions is to close a gap in the language.
>
>[1,2,3] + [4,5,6]
>
> works for lists and tuples,
>
>{1,2,3} | {4,5,6}
>
> works for sets, but joining two dicts isn't simply
>
>{1:2, 3:4} + {5:6}
>
> but
On 05/03/2019 09:42, Jimmy Girardet wrote:
Indeed the "obscure" argument should be thrown away.
The `|` operator in sets seems to be evident for every one on this list
but I would be curious to know how many people first got a TypeError
doing set1 + set2 and then found set1 | set2 in the doc.
I just wanted to mention this since it hasn't been brought up, but neither
of these work
a.keys() + b.keys()
a.values() + b.values()
a.items() + b.items()
However, the following do work:
a.keys() | b.keys()
a.items() | b.items()
Perhaps they work by coincidence (being set types), but I think
On Tue, Mar 5, 2019 at 7:59 PM Steven D'Aprano wrote:
>
> On Tue, Mar 05, 2019 at 06:04:40PM +0900, INADA Naoki wrote:
> [...]
> > One obvious merit of d.merge(...) is it returns same type of d.
> > `type(d1)(d1, d2)` looks ugly.
> >
> > But people just want dict instead of some subtype of dict.
On Tue, Mar 05, 2019 at 06:04:40PM +0900, INADA Naoki wrote:
[...]
> One obvious merit of d.merge(...) is it returns same type of d.
> `type(d1)(d1, d2)` looks ugly.
>
> But people just want dict instead of some subtype of dict.
> This merit is not so important.
Not to me! It *is* important to
04.03.19 15:29, Serhiy Storchaka пише:
Using "|" looks more natural to me than using "+". We
should look at discussions for using the "|" operator for sets, if the
alternative of using "+" was considered, I think the same arguments for
preferring "|" for sets are applicable now for dicts.
Python C API has PyDict_Merge
(https://docs.python.org/3/c-api/dict.html#c.PyDict_Merge) function
which has different behavior than the proposed Python level method
(doesn't copy but merge in-place).
This is a red flag for me.
On Tue, Mar 5, 2019 at 12:24 PM fhsxfhsx wrote:
>
> I agree so much
On Tue, Mar 5, 2019 at 7:26 PM Steven D'Aprano wrote:
>
> On Sat, Mar 02, 2019 at 01:47:37AM +0900, INADA Naoki wrote:
> > > If the keys are not strings, it currently works in CPython, but it may
> > > not work with other implementations, or future versions of CPython[2].
> >
> > I don't think
On Sat, Mar 02, 2019 at 01:47:37AM +0900, INADA Naoki wrote:
> > If the keys are not strings, it currently works in CPython, but it may not
> > work with other implementations, or future versions of CPython[2].
>
> I don't think so. https://bugs.python.org/issue35105 and
>
I agree so much on your opinion that I was just to create a topic about this if
you didn't.
I also propose here a small modification to make it more general which adds an
argument `how` (name to be discussed), telling how to merge the dicts, as many
have pointed out that there could be
On Mon, Mar 04, 2019 at 10:18:13PM -0800, Amber Yust wrote:
> Adding the + operator for dictionaries feels like it would be a mistake in
> that it offers at most sugar-y benefits, but introduces the significant
> drawback of making it easier to introduced unintended errors.
What sort of errors?
On Mon, Mar 04, 2019 at 03:33:36PM -0500, Neil Girdhar wrote:
> Maybe, but reading through the various replies, it seems that if you
> are adding "-" to be analogous to set difference, then the combination
> operator should be analogous to set union "|".
That's the purpose of this discussion,
On Tue, Mar 5, 2019 at 6:42 PM Jimmy Girardet wrote:
>
> Indeed the "obscure" argument should be thrown away.
>
> The `|` operator in sets seems to be evident for every one on this list
> but I would be curious to know how many people first got a TypeError
> doing set1 + set2 and then found set1
This is mainly for Steve, as the author of PEP 584.
I'm grateful to Steve for preparing the current draft. Thank you.
It's strong on implementation, but I find it weak on motivation. I
hope that when time is available you (and the other contributors)
could transfer some motivating material into
Indeed the "obscure" argument should be thrown away.
The `|` operator in sets seems to be evident for every one on this list
but I would be curious to know how many people first got a TypeError
doing set1 + set2 and then found set1 | set2 in the doc.
Except for math geek the `|` is always
On Mon, Mar 04, 2019 at 09:34:34PM +, Paul Moore wrote:
> On Mon, 4 Mar 2019 at 20:42, Guido van Rossum wrote:
> >
> > Honestly I would rather withdraw the subtraction operators than
> > reopen the discussion about making dict more like set.
As some people have repeatedly pointed out, we
> * Type of returned value is always same to d1.copy(). No issubclass,
> no __iadd__.
I'm sorry, I meant __radd__, not __iadd__.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of
On Tue, Mar 5, 2019 at 5:50 PM Nathaniel Smith wrote:
>
> On Mon, Mar 4, 2019 at 11:41 PM INADA Naoki wrote:
> > Then, I propose `dict.merge` method. It is outer-place version
> > of `dict.update`, but accepts multiple dicts. (dict.update()
> > can be updated to accept multiple dicts, but it's
SUMMARY
Instead of using dict + dict, perhaps use dict.flow_update. Here,
flow_update is just like update, except that it returns self.
BACKGROUND
There's a difference between a sorted copy of a list, and sorting the
list in place.
>>> items = [2, 0, 1, 9]
>>> sorted(items), items
On Mon, Mar 4, 2019 at 11:41 PM INADA Naoki wrote:
> Then, I propose `dict.merge` method. It is outer-place version
> of `dict.update`, but accepts multiple dicts. (dict.update()
> can be updated to accept multiple dicts, but it's not out of scope).
>
> * d = d1.merge(d2) # d = d1.copy();
On Tue, Mar 5, 2019 at 5:23 PM Chris Angelico wrote:
>
> On Tue, Mar 5, 2019 at 6:40 PM INADA Naoki wrote:
> > This is why function and methods are better:
> >
> > * Easy to search.
> >
> > ## Merits of dict.merge() over operator +
> >
> > * Easy to Google (e.g. "python dict merge").
>
> This
On Tue, Mar 5, 2019 at 6:40 PM INADA Naoki wrote:
> This is why function and methods are better:
>
> * Easy to search.
>
> ## Merits of dict.merge() over operator +
>
> * Easy to Google (e.g. "python dict merge").
This keeps getting thrown around. It's simply not true.
48 matches
Mail list logo
