On Tue, Jul 7, 2020 at 12:53 PM Stephen J. Turnbull
wrote:
>
> Christopher Barker writes:
>
> > I meant in the context of putting things in, or testing whether they are
> > in, sets. Not in any other context.
>
> OK, but restricting context that way is asking for eventual trouble,
> because
Christopher Barker writes:
> I meant in the context of putting things in, or testing whether they are
> in, sets. Not in any other context.
OK, but restricting context that way is asking for eventual trouble,
because there's one more thing you can do with sets: get stuff out of
them (by
Sorry, this got lost in the shuffle without being sent, and the
conversation seems to have died down. but since I wrote it ...
On Sat, Jul 4, 2020 at 8:25 AM Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:
> Christopher Barker writes:
>
> > I am really confused here -- I'm
On Mon, Jun 29, 2020, at 04:51, Stephen J. Turnbull wrote:
> Of course, we may prefer a boolean return, despite the general rule
> about returning elements. I'm single-threaded, and so agnostic on
> that. :-) But if it turns out that somebody *wants* to check "2 is
> 2.0",
> this .add_unique
Christopher Barker writes:
> On Mon, Jun 29, 2020 at 1:53 AM Stephen J. Turnbull <
> turnbull.stephen...@u.tsukuba.ac.jp> wrote:
> > But if it turns out that somebody *wants* to check "2 is 2.0",
> > this .add_unique can serve both purposes.
> can it though?
Yes.
> (or should it?)
YMMV,
On Mon, Jun 29, 2020 at 1:53 AM Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:
> But if it turns out that somebody *wants* to check "2 is 2.0",
> this .add_unique can serve both purposes.
>
can it though? (or should it?) -- the fact is that it was decided the 2 and
2.0 are
Bar Harel writes:
> The original example of "if dict.setdefault()" is problematic as well for
> the exact same reason. You can't tell if the default value was already
> there in the first place.
That's not a problem. In both cases if you need an object that can't
possibly be there, you have
On Sun, Jun 28, 2020 at 3:39 AM Steven D'Aprano wrote:
>
> TL;DR
>
> If the `set.add` feature can return a flag stating whether or not the
> element was previously present or not cheaply and atomically, without
> slowing down the single-threaded case with locks, then that's great (as
> I already
TL;DR
If the `set.add` feature can return a flag stating whether or not the
element was previously present or not cheaply and atomically, without
slowing down the single-threaded case with locks, then that's great (as
I already stated...) and this entire subthread about threading is
>
> Given dict.setdefault, a parallel method like set.add_unique, which
> returns the existing element or None, might be the better approach.
>
Although it breaks the convention of these methods returning the item, I'm
not sure returning the element is a good idea.
"set.add_unique(None)" will
Dan Sommers writes:
> Perhaps by your standard [it's not EAFP]. The code I wrote[:]
already_there = seen.add(element)
if already_there:
# handle the duplicate case
> performs an operation, and then asks whether or not some condition
> was met, as opposed to asking whether
On Sat, Jun 27, 2020 at 10:06 PM Rob Cliffe wrote:
>
>
>
> On 27/06/2020 05:33, Chris Angelico wrote:
> > On Sat, Jun 27, 2020 at 2:29 PM Steven D'Aprano wrote:
> >> Seriously, I genuinely thought that the existing behaviour was the
> >> opposite and that `add` unconditionally added the element.
On Saturday, June 27, 2020, at 03:46 -0500, Chris Angelico wrote:
I grew up with concurrency being a perfectly normal thing. To
me,
EVERYTHING is concurrent. (Back then, it was single-core CPUs,
so
technically most machine code instructions could be assumed to
be
atomic, but at any higher
On Friday, June 26, 2020, at 23:25 -0500, Steven D'Aprano wrote:
On Fri, Jun 26, 2020 at 06:16:05AM -0500, Dan Sommers wrote:
>already_there = seen.add(element)
>if already_there:
># handle the duplicate case
>
>Who thinks like that? *wink*
Anyone who practices EAFP rather
On Sat, Jun 27, 2020 at 4:54 PM Steven D'Aprano wrote:
>
> On Fri, Jun 26, 2020 at 10:10:22PM +1000, Chris Angelico wrote:
> > On Fri, Jun 26, 2020 at 7:58 PM Steven D'Aprano wrote:
> > > Most importantly, it matches the way people think about the task:
> > >
> > > # Task: look for
On Sat, Jun 27, 2020 at 04:57:32PM +1000, Steven D'Aprano wrote:
> I did find one thing... I was removing an unorded sequence by dropping
> the elements into a set then converting back to a list, and documented
> it as "last seen wins" in the case of duplicates.
Sheesh, I was removing
On Sat, Jun 27, 2020 at 06:09:02PM +1200, Greg Ewing wrote:
> On 27/06/20 4:25 pm, Steven D'Aprano wrote:
> >Seriously, I genuinely thought that the existing behaviour was the
> >opposite and that `add` unconditionally added the element. "Last seen
> >wins".
>
> The fact that you haven't noticed
On Fri, Jun 26, 2020 at 10:10:22PM +1000, Chris Angelico wrote:
> On Fri, Jun 26, 2020 at 7:58 PM Steven D'Aprano wrote:
> > Most importantly, it matches the way people think about the task:
> >
> > # Task: look for duplicates
> > if element in seen:
> > # it's a duplicate
> >
On 27/06/20 4:25 pm, Steven D'Aprano wrote:
Seriously, I genuinely thought that the existing behaviour was the
opposite and that `add` unconditionally added the element. "Last seen
wins".
The fact that you haven't noticed until now suggests that
you've never written any code that depends on
On Sat, Jun 27, 2020 at 2:29 PM Steven D'Aprano wrote:
> Seriously, I genuinely thought that the existing behaviour was the
> opposite and that `add` unconditionally added the element. "Last seen
> wins". If I was designing sets, that's probably how I would design it.
> After all, it's called
On Fri, Jun 26, 2020 at 06:16:05AM -0500, Dan Sommers wrote:
> >already_there = seen.add(element)
> >if already_there:
> ># handle the duplicate case
> >
> >Who thinks like that? *wink*
>
> Anyone who practices EAFP rather than LBYL? Or is that why you're
> winking?
That
On Fri, Jun 26, 2020 at 7:58 PM Steven D'Aprano wrote:
> Most importantly, it matches the way people think about the task:
>
> # Task: look for duplicates
> if element in seen:
> # it's a duplicate
> ...
> else:
> # never seen before, so remember it
>
On Friday, June 26, 2020, at 04:54 -0500, Steven D'Aprano wrote:
On Thu, Jun 25, 2020 at 05:27:16PM +0300, Ben Avrahami wrote:
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)
On Thu, Jun 25, 2020 at 05:27:16PM +0300, Ben Avrahami wrote:
> 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
>
>
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
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
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()
>
35 matches
Mail list logo
