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 user-s
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()
>
Previous discussions on this:
https://mail.python.org/archives/list/[email protected]/thread/ASHOHN32BQPBVPIGBZQRS24XHXFMB6XZ/
https://mail.python.org/archives/list/[email protected]/thread/K5SS62AB5DFFZIJ7ASKPLB2P3XGSYFPC/
(seems
like part of the above discussion that got separated)
h
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
should
On Thu, Jun 25, 2020 at 6:44 PM Alex Hall wrote:
> Previous discussions on this:
>
>
> https://mail.python.org/archives/list/[email protected]/thread/ASHOHN32BQPBVPIGBZQRS24XHXFMB6XZ/
>
> https://mail.python.org/archives/list/[email protected]/thread/K5SS62AB5DFFZIJ7ASKPLB2P3XGSYFPC/
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 to
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
misspell,
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 of
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 her
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
happ
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
interrupte
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 u
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 'self'.
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 d
On Thu, Jun 25, 2020 at 5:09 PM Yonatan Zunger via Python-ideas <
[email protected]> 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
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 lif
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 i
17 matches
Mail list logo
