@Simon wow 5 years?

@AndrasDeak :D

cbg

@abarnert The original problem was that given: x = []; x.append(x); ForcedHash(x) == ForcedHash(x) we get a RecursionError again. But I think the conclusion is that it just makes sense that the limitation of this class is the same as the ones of the == operator

I am also unsure why that suddenly got downvoted so hard

@OlivierMelançon Well, this is one of those “you almost always shouldn’t do this” questions, and a lot of people tend to downvote those unless you give a really good reason why you have an exception.

I disagree with he fact this one is a "almost always shouldn't" it is not the first time I implement a dict with mutable keys, it does have a lot of uses, especially performance-wise

And the design decision I ended up taking, by the way, is to simply let the exception be raised. One of the initial goals was to see if a list contains equal (possibly mutable) objects in O(n). Since [[...]] is simply not equatable, it makes sense for the algorithm to fail to handle.

As long as you can guarantee the lists aren’t mutated while the dict is alive, of course it’s reasonable. But in most such problems, the question is why not just use tuples. The reason I assumed you had an answer to that is that the people who asked the other 100 questions on how to use a list as a dict key wouldn’t have even been able to think of the problems you’d already solved.

But I think a lot of people don’t read carefully; they see the 101st question on hashing lists, no explanation for why you need to do it, and just downvote and move on.

Anyway, the most interesting remaining question to me is what made me think that d{x:0} == d{y:0} ought to return False for distinct self-containing x and y. I can't think of any good reason for that, and yet, before thinking about it, I was pretty sure that was the obvious right answer…

The exact reason I do not use tuple is because (1, 2, 3) != [1, 2, 3]. This information is lost when simply casting to the mutable equivalent type

The parallel between my code and deepcopy's memo seemed pretty clear to you. Since deepcopy is id based, I assume this is what made you think the objects should not be equal

@abarnert Did you really went on nesting a tuple in itself to see what would happen? That's pretty cool!

Yeah, but that's only for the underlying memo for catching self-recursive objects; it was pretty clear that just using id-hashing for the top-level dict wasn't going to solve your problem (or you would have just done that and saved yourself a lot of trouble). But maybe that's what misled me here…

static PyObject *tuply_make(PyObject *self, PyObject *args) {
  PyObject *tup = PyTuple_New(1);
  if (!tup) return NULL;
  if (PyTuple_SetItem(tup, 0, tup)) return NULL;
  return tup;
}

Oh I see

Every time someone has a question about the C API, I tell them they should be using PyCxx or Cython or Pyd or rust-python, but when I want to slap something together, I run my silly makecboilerplate.py script and edit it manually, because I never listen to myself…

If you want to know the whole story of my hash question, this is what made me think of it: stackoverflow.com/q/50976187/5079316

My though was the following: "why not just convert the list to a str, use replace and convert it back"

Depends on whether your list values are restricted to things that are valid JSON/valid ast.literal_eval literals/something stringable, doesn't it?

Well, if you are able to make everything hashable, then all they need is to be equatable

I'll actually add an answer on that question, just because it sounds fun

If your values are comparable, it's probably easier to just use a nice wide tree so it's technically logarithmic time but practically about as fast as a hash table.

blist, sortedcontainers, pyrsistent, whatever.

Oh, wait, you meant just equality-comparable, not totally-ordered, right?

yes

sorry, I wrote comparable there for a moment and edited after

Anyway, looks like dawg came up with your string answer.

It's pretty similar yes

But mine is way more complex, way less readable and probably a bit slower

But yes, the point is that I expect str.replace to be blazing fast comparared to anything else written in Python

Doing the same algorithm as str.compare but genrically and recursively might be slow as hell in CPython, but in PyPy it should be decent, right?

I have to admit I never PyPyed

Heard good things

I've never gotten to use it in a project for work, but for personal stuff, I use it quite a bit. I'm sometimes amazed at what it can optimize. And even after trying to read all the whitepapers and the source code (and I even worked on a tracing JIT for JavaScript/ActionScript…), I remained amazed. I suspect the truth is that Armin is a wizard.

Of course it is a bit annoying to drop back from Python 3.7 to 3.5.

Python 3.6 was the best update

Is there tail-recursion in PyPy?

Nope.

There was one of those "I'll do an experimental fork if anyone will pay me" proposals, but $0. My conspiracy theory is that Guido threatened the break the kneecaps of anyone who contributed.

Although Armin spending his time on STM instead was a lot more interesting, even if that fork seems to be stagnant now.

My str.replace solution. You might see why I was asking about mutable hashed objects earlier

I once saw that decorator someone wrote to make a function tail recursive, but lost track of it

Anyway, as much as I love f-strings, I think the best updates were 3.3 and 2.3.

I was not around at 2.3

I believe I started coding around 2.6

Maybe 2.5

I see 3.3 is the 'yield from' version

Without surprise it got downvoted straight up

Yeah, yield from. But also a lot of little things. Memory view, import hooks, stuff that made porting from 2.x a lot less painful (u prefixes, callable), and lots of optimizations (compact unicode strings, decimals that are almost fast enough to use, faster comprehensions on 64-bit systems, …).

I was not a mature enough dev at the time so I was not following updates, but yes that is definitely a nice one

It's getting late here, rbrb

cabbaze