I believe I'm -0 for modifying the existing add() and +0 for a new function.
By the way, a good phrasing of the general mutating/non-mutating convention
opens the built-in types section of the docs:
"Some collection classes are mutable. The methods that add, subtract, or
rearrange their members
Oh, that's definitely part of the problem, but that is *far* beyond my
ability to fix. Right now I'm still working on getting its owners to do
things like "could you please log somewhere when you kill jobs, and maybe
even indicate why the job was killed?".
The main time that signals show up in
On Thu, Jun 25, 2020 at 5:09 PM Yonatan Zunger via Python-ideas <
python-ideas@python.org> wrote:
> Hey everyone,
>
> I've been developing code which (alas) needs to operate in a runtime
> environment which is quite *enthusiastic* about sending SIGTERMs and the
> like, and where there are
On 26/06/20 4:01 am, Steele Farnsworth wrote:
My point was only that, as far as I know, all the methods for built in
container types that serve only to change what is contained return None,
and that this was an intentional design choice, so changing it in one
case would have to evoke a larger
On 26/06/20 2:45 am, Steele Farnsworth wrote:
Personally, I'd want to see mutator methods return `self` so you can do
more than one mutation in a statement, but the convention is that all
the mutator methods return `None`.
I would say the convention is that mutator methods don't return
Absolutely, but I figured the natural thing to expose from the C API was a
very minimal function, and then put a context manager in the Python layer.
The actual context manager implementation I would use would be a bit
smarter than a bare set/reset -- it would use an unbounded semaphore and
only
On 2020-06-25 21:05, Yonatan Zunger via Python-ideas wrote:
Hey everyone,
I've been developing code which (alas) needs to operate in a runtime
environment which is quite /enthusiastic/ about sending SIGTERMs and the
like, and where there are critical short sections of code that, if
Hey everyone,
I've been developing code which (alas) needs to operate in a runtime
environment which is quite *enthusiastic* about sending SIGTERMs and the
like, and where there are critical short sections of code that, if
interrupted, are very hard to resume without some user-visible anomaly
Hi Ben
You've definitely got a point. When you do
seen.add(key)
it's sometimes important to know if this changes 'seen'.
Here's a one-liner that does what you want:
key in seen or seen.add(key)
It's a bit obscure, and perhaps a bit too much
https://en.wikipedia.org/wiki/Code_golf. So
On Thu, Jun 25, 2020 at 10:10 AM Ben Avrahami
wrote:
> On Thu, Jun 25, 2020 at 7:55 PM Christopher Barker
> wrote:
>
>> On Thu, Jun 25, 2020 at 9:02 AM Steele Farnsworth
>> wrote:
>> indeed -- and that is pretty darn baked in to Python, so I don't think
>> it's going to change.
>>
>
30 years
On Thu, Jun 25, 2020 at 7:55 PM Christopher Barker
wrote:
> On Thu, Jun 25, 2020 at 9:02 AM Steele Farnsworth
> wrote:
> indeed -- and that is pretty darn baked in to Python, so I don't think
> it's going to change.
>
>
Except this convention doesn't hold for dict.setvalue (which I did
On Thu, Jun 25, 2020 at 9:02 AM Steele Farnsworth
wrote:
> My point was only that, as far as I know, all the methods for built in
> container types that serve only to change what is contained return None,
> and that this was an intentional design choice, so changing it in one case
> would have
On Thu, Jun 25, 2020 at 6:44 PM Alex Hall wrote:
> Previous discussions on this:
>
>
> https://mail.python.org/archives/list/python-ideas@python.org/thread/ASHOHN32BQPBVPIGBZQRS24XHXFMB6XZ/
>
> https://mail.python.org/archives/list/python-ideas@python.org/thread/K5SS62AB5DFFZIJ7ASKPLB2P3XGSYFPC/
My point was only that, as far as I know, all the methods for built in
container types that serve only to change what is contained return None,
and that this was an intentional design choice, so changing it in one case
would have to evoke a larger discussion about what those sorts of methods
Previous discussions on this:
https://mail.python.org/archives/list/python-ideas@python.org/thread/ASHOHN32BQPBVPIGBZQRS24XHXFMB6XZ/
https://mail.python.org/archives/list/python-ideas@python.org/thread/K5SS62AB5DFFZIJ7ASKPLB2P3XGSYFPC/
(seems
like part of the above discussion that got separated)
Personally, I'd want to see mutator methods return `self` so you can do
more than one mutation in a statement, but the convention is that all the
mutator methods return `None`.
On Thu, Jun 25, 2020, 10:28 AM Ben Avrahami wrote:
> Hey all,
> Often I've found this kind of code:
>
> seen = set()
>
Hey all,
Often I've found this kind of code:
seen = set()
for i in iterable:
if i in seen:
... # do something in case of duplicates
else:
seen.add(i)
... # do something in case of first visit
This kind of code appears whenever one needs to check for duplicates in
case of a
17 matches
Mail list logo
