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 maybe_async(fn)
Defining a single polymorphic function is easy at the library level.
For example, with asyncio:
def maybe_async(fn):
@functools.wraps(fn)
def wrapper(*args, **kwargs):
coro = fn(*args, **kwargs)
if asyncio.get_running_loop() is not None:
return coro
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
https://toolz.readthedocs.io/en/latest/api.html#toolz.dicttoolz.mer
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 syncrono
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 Pascal
> 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 pr
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 equ
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 --color=alwa
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 ha
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
>> itera
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 equiv
>
> 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 s
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 -
2019-03-05 0:34 UTC+01:00, Brandt Bucher :
>> Is there other built-in types which act differently if called with
>> the operator or augmented assignment version?
>
> list.__iadd__ and list.extend
2019-03-05 0:57 UTC+01:00, Guido van Rossum :
> Yes. The same happens for lists. [1] + 'a' is a TypeE
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
> implementa
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 they
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 add
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, o
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 want
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
theory
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
- Tea
> 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)
pri
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 requ
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 it
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 me
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.
See
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
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 so
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
> https://mail.python.or
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 different
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, to
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 t
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 somethi
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 alr
> * 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 Conduct:
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
([0
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(); d.upd
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 kee
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.
https://www.google.com/sea
50 matches
Mail list logo
