[Python-ideas] Fwd: Extremely weird itertools.permutations

Oscar Benjamin oscar.j.benjamin at gmail.com
Mon Oct 14 02:20:19 CEST 2013


On 14 October 2013 01:15, Tim Peters <tim.peters at gmail.com> wrote:
> [Oscar Benjamin]
>> ...
>> Damn, you're right. I obviously didn't think that one through hard
>> enough. Okay how about this?
>> d = TransformDict(lambda x: (tuple(map(type, x)), tuple(x)))
>
> Oscar, please give this up - it's not going to work.  `x` can be any
> object whatsoever, with arbitrarily complex internal structure, and
> the user can have an arbitrarily convoluted idea of what "equal"
> means.  Did I mention that these lists don't *only* have ints and
> floats as elements, but also nested sublists?  Oh ya - they also want
> a float and a singleton list containing the same float to be
> considered equal ;-)  Etc.

That does seem contrived but then I guess the whole problem is however....

> Besides, you're trying to solve a problem I didn't have to begin with
> ;-)  That is, I don't care much about the cost of building equivalence
> classes - it's a startup cost for the generator, not an "inner loop"
> cost.  Even if you could bash every case into a different convoluted
> hashable tuple, in general it's going to be - in this specific problem
> - far easier for the user to define an equal() function they like,
> working directly on the two objects.  That doesn't require an endless
> sequence of tricks.

okay I see what you mean.


Oscar


More information about the Python-ideas mailing list