Currently one can do week = d.isocalendar()[1]
The iso definition of a week number has some nice properties.
robertvandeneynde.be
On Fri, 1 Mar 2019, 11:44 Antonio Galán, wrote:
> The week number is usually refered to the week of the year, but the week
> of the month is also interesting, for
The week number is usually refered to the week of the year, but the week of
the month is also interesting, for example for some holiday which depend on
the week number of the month, so in analogy with "weekday" we can use
"yearweek" and "monthweek"
El vie., 1 de marzo de 2019 9:33, Adrien
On Fri, Mar 01, 2019 at 08:47:36AM +0200, Serhiy Storchaka wrote:
> Currently Counter += dict works and Counter + dict is an error. With
> this change Counter + dict will return a value, but it will be different
> from the result of the += operator.
That's how list.__iadd__ works too:
On Thu, Feb 28, 2019 at 07:40:25AM -0500, James Lu wrote:
> I agree with Storchaka here. The advantage of existing dict merge
> syntax is that it will cause an error if the object is not a dict or
> dict-like object, thus preventing people from doing bad things.
What sort of "bad things" are
I dislike adding more operator overload to builtin types.
str is not commutative, but it satisfies a in (a+b), and b in (a+b).
There are no loss.
In case of dict + dict, it not only sum. There may be loss value.
{"a":1} + {"a":2} = ?
In case of a.update(b), it's clear that b wins.
In case
Serhiy Storchaka wrote:
And this opens a non-easy problem: how to create a mapping of the same
type?
That's the responsibility of the class implementing the + operator.
There doesn't have to be any guarantee that a subclass of it will
automatically return an instance of the subclass (many
While working through my implementation, I've come across a couple of
inconsistencies with the current proposal:
> The merge operator will have the same relationship to the dict.update
method as the list concatenation operator has to list.extend, with dict
difference being defined analogously.
I
I’ve never been part of this process before, but I’m interested in learning and
helping any way I can.
My addition implementation is attached to the bpo, and I’m working today on
bringing it in line with the PEP in its current form (specifically, subtraction
operations).
Rémi Lapeyre schrieb am 01.03.19 um 16:44:
> Le 1 mars 2019 à 16:04:47, Stefan Behnel a écrit:
>> I think the behaviour makes sense when you know how it's implemented (keys
>> are stored separately from values).
>
> Is a Python user expected to know the implementation details of all mappings
>
Attached is a draft PEP on adding + and - operators to dict for
discussion.
This should probably go here:
https://github.com/python/peps
but due to technical difficulties at my end, I'm very limited in what I
can do on Github (at least for now). If there's anyone who would like to
co-author
> 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.org/pipermail/python-dev/2018-October/155435.html
are about kwargs. I
Hi, Steven.
I can help you with it. I added it as PEP 584. I had to add the PEP
headers, but didn't do any other editing.
I'm going to be out of town for the next 2 weeks, so I might be slow in
responding.
Eric
On 3/1/2019 11:26 AM, Steven D'Aprano wrote:
Attached is a draft PEP on
>
> OK, thanks for explaining! So more formally speaking, you want to say that
> for other examples of '+' in Python
> x1 + y == x2 + y if and only if x1 == x2, while for the proposed '+' for
> dicts there may be many different x_i such that
> x_i + y gives the same result.
>
It's bit different
Looks like a good start.
I think you should replace all of the lines:
if isinstance(other, dict):
with
if isinstance(self, type(other)):
Since if other is an instance of a dict subclass, he should be the one to
process the addition. On the other hand, if self is an instance of the
derived
Thanks -- FYI I renamed the file to .rst (per convention for PEPs in ReST
format) and folded long text lines.
On Fri, Mar 1, 2019 at 8:53 AM Eric V. Smith wrote:
> Hi, Steven.
>
> I can help you with it. I added it as PEP 584. I had to add the PEP
> headers, but didn't do any other editing.
>
>
On Thu, Feb 28, 2019 at 10:30 PM Serhiy Storchaka
wrote:
> 28.02.19 23:19, Greg Ewing пише:
> > Serhiy Storchaka wrote:
> >> I do not understand why we discuss a new syntax for dict merging if we
> >> already have a syntax for dict merging: {**d1, **d2} (which works with
> >> *all* mappings).
>
On Fri, Mar 1, 2019 at 8:50 AM Brandt Bucher wrote:
> I’ve never been part of this process before, but I’m interested in
> learning and helping any way I can.
>
Thanks!
>
> My addition implementation is attached to the bpo, and I’m working today
> on bringing it in line with the PEP in its
I think that sequence should be fixed.
On Fri., Mar. 1, 2019, 7:12 p.m. Brandt Bucher,
wrote:
> While working through my implementation, I've come across a couple of
> inconsistencies with the current proposal:
>
> > The merge operator will have the same relationship to the dict.update
> method
Executive summary:
- I'm going to argue for subclass-preserving behaviour;
- I'm not wedded to the idea that dict += should actually call the
update method, so long as it has the same behaviour;
- __iadd__ has no need to return NotImplemented or type-check its
argument.
Details below.
On
Hi, datetime.date.today() (or other day) has attributes .year and .month
wich return the year and the month of that date, also it has a function
weekday() wich return the number of the day in the week.
I think it is a good idea add a function or attribute "week" wich return
the number of the
On Thu, 28 Feb 2019 at 07:18, Serhiy Storchaka wrote:
> [...]
>
> I do not understand why we discuss a new syntax for dict merging if we
> already have a syntax for dict merging: {**d1, **d2} (which works with
> *all* mappings). Is not this contradicts the Zen?
>
FWIW there are already three
On Fri, Mar 01, 2019 at 09:58:08PM +0900, INADA Naoki wrote:
> >>> {1} <= ({1} | {1.0})
> True
> >>> {1.0} <= ({1} | {1.0})
> True
>
> So dict + dict is totally different than set | set.
> dict + dict has los at equality level.
Is that an invariant you expect to apply to other uses of the +
On Fri, Mar 1, 2019 at 11:00 PM INADA Naoki wrote:
>
> I dislike adding more operator overload to builtin types.
>
> str is not commutative, but it satisfies a in (a+b), and b in (a+b).
> There are no loss.
>
> In case of dict + dict, it not only sum. There may be loss value.
>
>{"a":1} +
>
>
> Is that an invariant you expect to apply to other uses of the +
> operator?
>
> py> x = -1
> py> x <= (x + x)
> False
>
> py> [999] <= ([1, 2, 3] + [999])
> False
>
Please calm down. I meant each type implements "sum"
in semantics of the type, in lossless way.
What "lossless" means is
On Fri, Mar 01, 2019 at 08:59:45PM +0900, INADA Naoki wrote:
> I dislike adding more operator overload to builtin types.
>
> str is not commutative, but it satisfies a in (a+b), and b in (a+b).
> There are no loss.
Is this an invariant you expect to apply for other classes that support
the
On Fri, Mar 1, 2019 at 10:10 PM Steven D'Aprano wrote:
>
> On Fri, Mar 01, 2019 at 08:59:45PM +0900, INADA Naoki wrote:
> > I dislike adding more operator overload to builtin types.
> >
> > str is not commutative, but it satisfies a in (a+b), and b in (a+b).
> > There are no loss.
>
> Is this an
On Fri, 1 Mar 2019 at 14:50, Eric V. Smith wrote:
> On 3/1/2019 9:38 AM, INADA Naoki wrote:
> > Sorry, I'm not good at English enough to explain my mental model.
> >
> > I meant no skip, no ignorance, no throw away.
> >
> > In case of 1+2=3, both of 1 and 2 are not skipped, ignored or thrown
>
Eric V. Smith schrieb am 01.03.19 um 15:49:
> I understand Inada to be saying that each value on the LHS (as shown above)
> affects the result on the RHS. That's the case with addition of ints and
> other types, but not so with the proposed dict addition. As he says, the
> {a:1} doesn't affect the
I’m having issues to understand the semantics of d1 + d2.
I think mappings are more complicated than sequences it some things
seems not obvious to me.
What would be OrderedDict1 + OrderedDict2, in which positions would be
the resulting keys, which value would be used if the same key is
present
Rémi Lapeyre schrieb am 01.03.19 um 15:06:
> I’m having issues to understand the semantics of d1 + d2.
>
> I think mappings are more complicated than sequences it some things
> seems not obvious to me.
>
> What would be OrderedDict1 + OrderedDict2, in which positions would be
> the resulting
Rémi Lapeyre schrieb am 01.03.19 um 15:50:
> Le 1 mars 2019 à 15:41:52, Stefan Behnel a écrit:
>
>> Rémi Lapeyre schrieb am 01.03.19 um 15:06:
>>> I’m having issues to understand the semantics of d1 + d2.
>>>
>>> I think mappings are more complicated than sequences it some things
>>> seems not
On Fri, 1 Mar 2019 at 13:48, INADA Naoki wrote:
> >
> >
> > Is that an invariant you expect to apply to other uses of the +
> > operator?
> >
> > py> x = -1
> > py> x <= (x + x)
> > False
> >
> > py> [999] <= ([1, 2, 3] + [999])
> > False
> >
>
> Please calm down. I meant each type implements
On 01/03/2019 14:06, Rémi Lapeyre wrote:
I’m having issues to understand the semantics of d1 + d2.
That's understandable, clouds of confusion have been raised. As far as
I can tell it's pretty straightforward: d = d1 + d2 is equivalent to:
>>> d = d1.copy()
>>> d.update(d2)
All of your
Sorry, I'm not good at English enough to explain my mental model.
I meant no skip, no ignorance, no throw away.
In case of 1+2=3, both of 1 and 2 are not skipped, ignored or thrown away.
On the other hand, in case of {a:1, b:2}+{a:2}={a:2, b:2}, I feel {a:1} is
skipped, ignored, or thrown away.
On Friday, March 1, 2019 at 5:47:06 AM UTC-5, Steven D'Aprano wrote:
>
> On Fri, Mar 01, 2019 at 08:47:36AM +0200, Serhiy Storchaka wrote:
>
> > Currently Counter += dict works and Counter + dict is an error. With
> > this change Counter + dict will return a value, but it will be different
>
On 3/1/19 8:19 AM, Ivan Levkivskyi wrote:
On Fri, 1 Mar 2019 at 13:48, INADA Naoki wrote:
>
>
> Is that an invariant you expect to apply to other uses of the +
> operator?
>
> py> x = -1
> py> x <= (x + x)
> False
>
> py> [999] <= ([1, 2, 3] + [999])
> False
>
Please calm down. I meant each
On 3/1/2019 9:38 AM, INADA Naoki wrote:
Sorry, I'm not good at English enough to explain my mental model.
I meant no skip, no ignorance, no throw away.
In case of 1+2=3, both of 1 and 2 are not skipped, ignored or thrown away.
On the other hand, in case of {a:1, b:2}+{a:2}={a:2, b:2}, I feel
37 matches
Mail list logo
