[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