> I can't see any, but then I couldn't see the security consequences of
> predictable string hashes until they were pointed out to me. So it would
> be really good to have some security experts comment on whether this is
> safe or not.
I can't either. I can point out that the complexity attack
[Oscar Benjamin]
> (If you think that there might be a
> performance penalty then you haven't understood the suggestion!)
Then I don't understand the question, and I will refrain from participating
further in this discussion.
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is
On Tue, Nov 29, 2022 at 02:07:34AM +, Oscar Benjamin wrote:
> Let's split this into two separate questions:
Let's not. Your first question about non-deterministic set order being
"innately good" is a straw man: as we've already discussed, set order is
not non-deterministic (except in the
On Tue, 29 Nov 2022 at 13:12, Oscar Benjamin wrote:
> As for point 2. the fact that sets are currently non-deterministic is
> actually a relatively new thing in Python. Before hash-randomisation
> set and dict order *was* deterministic but with an arbitrary order.
> That was only changed because
On Tue, 29 Nov 2022 at 01:33, Steven D'Aprano wrote:
>
> On Mon, Nov 28, 2022 at 11:13:34PM +, Oscar Benjamin wrote:
> > On Mon, 28 Nov 2022 at 22:56, Brett Cannon wrote:
>
> As I understand it, we could make sets ordered, but only at the cost of
> space (much more memory) or time (slower)
On Tue, Nov 29, 2022 at 01:34:54PM +1300, Greg Ewing wrote:
> I got the impression that there were some internal language reasons
> to want stable dicts, e.g. so that the class dict passed to __prepare__
> preserves the order in which names are assigned in the class body. Are
> there any such use
For what it's worth, as a user of the language I would like sets to behave
as much as possible as-if they were basically dicts that map all elements
to `()`. That way I'd have to keep one less mental model in my head.
I deliberately say 'as-if' because when I'm a user of the language, I don't
On Mon, Nov 28, 2022 at 11:13:34PM +, Oscar Benjamin wrote:
> On Mon, 28 Nov 2022 at 22:56, Brett Cannon wrote:
> > That's actually by design. Sets are not meant to be deterministic
> > conceptually as they are essentially a bag of stuff. If you want
> > deterministic ordering you should
Nah, `__prepare__` very much predates stable dicts and that problem was
solved differently.
On Mon, Nov 28, 2022 at 4:46 PM Greg Ewing wrote:
> On 29/11/22 12:51 pm, Guido van Rossum wrote:
> > "Sets weren't meant to be deterministic" sounds like a remnant of
> > the old philosophy, where we
On 29/11/22 12:51 pm, Guido van Rossum wrote:
"Sets weren't meant to be deterministic" sounds like a remnant of
the old philosophy, where we said the same about dicts -- until they
became deterministic without slowing down, and then everybody loved it.
I got the impression that there were
To stir up some more fire, I would personally be fine with sets having the
same ordering guarantees as dicts, *IF* it can be done without performance
degradations. So far nobody has come up with a way to ensure that. "Sets
weren't meant to be deterministic" sounds like a remnant of the old
On Mon, 28 Nov 2022 at 22:56, Brett Cannon wrote:
>
> On Sun, Nov 27, 2022 at 11:36 AM Yoni Lavi wrote:
>>
>> All it takes is for your program to compute a set somewhere with affected
>> keys, and iterate on it - and determinism is lost.
>
> That's actually by design. Sets are not meant to be
On Tue, 29 Nov 2022 at 09:51, Brett Cannon wrote:
> ... we worked hard to stop people from relying on consistent
> hashing/iteration from random-access data structures like dict and set.
>
Say what? Who's been working hard to stop people from relying on
consistent iteration order for a dict?
On Sun, Nov 27, 2022 at 11:36 AM Yoni Lavi wrote:
> I wrote a doc stating my case here:
>
> https://docs.google.com/document/d/1et5x5HckTJhUQsz2lcC1avQrgDufXFnHMin7GlI5XPI/edit#
>
> Briefly,
>
> 1. The main motivation for it is to allow users to get a predictable
> result on a given input (for
14 matches
Mail list logo