You are absolutely right, of course. It was a wild idea, and a bad one.
I find myself moving towards supporting the OP. I can't see anything
terrible about the hash of None always being 0, or perhaps better some
other arbitrary constant.
Rob
On 04/12/2022 03:20, Steven D'Aprano wrote:
On
You're right of course. Oh well, it *was* a wild idea.
Rob Cliffe
On 04/12/2
On 04/12/2022 18:16, Chris Angelico wrote:
On Mon, 5 Dec 2022 at 05:11, Rob Cliffe via Python-Dev
wrote:
Wild suggestion:
Make None.__hash__ writable.
E.g.
None.__hash__ = lambda : 0 # Currently raises
On Thu, Dec 01, 2022 at 10:18:49PM +, Rob Cliffe via Python-Dev wrote:
> Wild suggestion:
> Make None.__hash__ writable.
> E.g.
> None.__hash__ = lambda : 0 # Currently raises AttributeError:
> 'NoneType' object attribute '__hash__' is read-only
You would have to write to
On Mon, 5 Dec 2022 at 05:11, Rob Cliffe via Python-Dev
wrote:
>
> Wild suggestion:
> Make None.__hash__ writable.
> E.g.
> None.__hash__ = lambda : 0 # Currently raises AttributeError:
> 'NoneType' object attribute '__hash__' is read-only
Hashes have to be stable. If you change the
Wild suggestion:
Make None.__hash__ writable.
E.g.
None.__hash__ = lambda : 0 # Currently raises AttributeError:
'NoneType' object attribute '__hash__' is read-only
Best wishes
Rob Cliffe
On 01/12/2022 11:02, Oscar Benjamin wrote:
On Thu, 1 Dec 2022 at 06:56, Chris Angelico wrote:
On 29/11/2022 00:51, Guido van Rossum wrote:
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
On Sat, 3 Dec 2022 at 14:46, Yoni Lavi wrote:
> > 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
> 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.
>
On Sat, 3 Dec 2022 at 10:57, Yoni Lavi wrote:
> 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
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
On Mon, Nov 28, 2022 at 6:45 PM Steven D'Aprano wrote:
> 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
On 11/30/2022 8:48 PM, Rob Cliffe via Python-Dev wrote:
Thank you for this very clear analysis, Oscar.
It seems to me that this strengthens the OP's case. I am curious as to
whether others agree.
I do.
On 30/11/2022 13:35, Oscar Benjamin wrote:
On Tue, 29 Nov 2022 at 23:46, Steven D'Aprano
Thank you for this very clear analysis, Oscar.
It seems to me that this strengthens the OP's case. I am curious as to
whether others agree.
Best wishes
Rob Cliffe
On 30/11/2022 13:35, Oscar Benjamin wrote:
On Tue, 29 Nov 2022 at 23:46, Steven D'Aprano wrote:
On Tue, Nov 29, 2022 at
On Thu, 1 Dec 2022 at 06:56, Chris Angelico wrote:
>
> On Thu, 1 Dec 2022 at 17:26, Yoni Lavi wrote:
> >
> > So it's not like it's even possible to require this generally for all
> > objects.
>
> Well, I mean, in theory you could require that objects whose hash
> isn't otherwise defined get
> 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
On Thu, 1 Dec 2022 at 17:26, Yoni Lavi wrote:
>
> > 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
>
> 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
On Tue, Nov 29, 2022 at 12:58 PM Yoni Lavi wrote:
> It does make your argument invalid though,
It makes that single sentence invalid, but the rest of my points still
hold, e.g. the language makes no guarantee about hash consistency between
executions, set order is not guaranteed, etc. are all
On Tue, 29 Nov 2022 at 23:46, Steven D'Aprano wrote:
>
> On Tue, Nov 29, 2022 at 08:51:09PM -, Yoni Lavi wrote:
>
> > 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
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
On Wed, 30 Nov 2022 at 10:48, Steven D'Aprano wrote:
> Let's consider a thought-experiment: suppose we agree to your proposal
> to make hash(None) return a constant, but at the same time modify the
> set iteration algorithm so that it starts from a different position each
> time you iterate,
> it [randomising iteration order or sets] would also break the invariant
that `repr(data) == repr(data)` but it
is times like this that I feel that it would be worth it.
But it wouldn't -- equality of sets doesn't depend on iteration order. And
even if you are talking about other types (this
On Tue, Nov 29, 2022 at 08:51:09PM -, Yoni Lavi wrote:
> 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.
Yoni,
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
On Mon, Nov 28, 2022 at 5:38 PM 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:
>
> > > That's actually by design. Sets are not meant to be deterministic
> > > conceptually as they are essentially a
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
[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
40 matches
Mail list logo
