> I think this is over-complicating things. I think the key merit of your
> original proposal was its simplicity. Proposing more complicated ways of
> getting the result you want is (IMO) unlikely to succeed, and is only
> likely to cause people to become even more entrenched in their positions.
>
There's a number of Core devs that have taken strong positions against this
change, citing various reasons ranging from "the addition of a function that
returns a constant will cause bloat in the interpreter / needs to be tested /
etc" to "what you really mean to ask for is set iteration stabili
> Whether determinism is fundamentally good or fundamentally bad depends
> heavily on context.
Agreed 100%. Unfortunately in Python, you cannot choose your hashing function
depending on context.
Also, once you've decided to violate determinism somewhere, it's gone. There is
no way, in the gener
> the language makes no guarantee about hash consistency between
executions
because it's futile in the general case, even if objects were to get a serial
`id` and hash by it for example, any change in the number of objects created
across all of Python (including its builtin modules and various l
I stand by what I said, there is absolutely nothing disingenious about it.
> Over on the Discuss threads,
> you have made it clear that the primary reason why you want hash(None)
> to return a constant value is so that set iteration order will be
> consistent from one run to another.
No, it's s
It does make your argument invalid though, since it's based on this assumption
that I was asking for a requirement on iteration order (e.g. like dict's
iteration order = insertion order guarantee), which is not the case.
Again, determinism means that given all input data and commands fed to a da
Looks like it's just miscommunication.
There is the original proposal I made, strictly about how None is ought to be
hashed, and then there is the separate topic of changing the stability
properties of iteration on sets, and whether that can be made with/without a
performance regression...
> 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 via
> 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 via
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 programs that are doing pure compute, in domains like
operations res
10 matches
Mail list logo
