I'm not a fan, sorry.
On Tue, Feb 6, 2018 at 7:33 PM, Ethan Furman wrote:
> On 02/06/2018 06:48 PM, Guido van Rossum wrote:
>
> That seems a rare case (though I hadn't thought of it). I had thought of
>> the use case where you want a frozen type
>> without a hash; that you can presumably impleme
On 02/06/2018 06:48 PM, Guido van Rossum wrote:
That seems a rare case (though I hadn't thought of it). I had thought of the
use case where you want a frozen type
without a hash; that you can presumably implement using
def __hash__(self): raise TypeError("not hashable")
We can do a similar th
That seems a rare case (though I hadn't thought of it). I had thought of
the use case where you want a frozen type without a hash; that you can
presumably implement using
def __hash__(self): raise TypeError("not hashable")
We can do a similar thing to preserve the superclass __hash__ if it's rare
Sorry for the late reply. Still recovering from a computer failure.
My only concern with this approach is: what if you don’t want any __hash__
added? Say you want to use your base class’s hashing. I guess you could always
“del cls.__hash__” after the class is created, but it’s not elegant.
Th
>
>
> https://refi64.com/posts/the-magic-of-rpython.html
>
> Note that this was written back when I used "like" and "really" in every
> sentence, and when I used to think that Python copied tuples (don't ask).
>
Thanks! And thanks for making the RPython language a bit more explicit for the
re
> Message-ID: <20180206034013.gz26...@ando.pearwood.info>
>
> On Sat, Feb 03, 2018 at 11:45:15AM +0100, asrp wrote:
>
> > > Can you give an example of how you would do that? I don't mean the
> > > mechanism used, I mean how would a developer implement a new syntactic
> > > feature. Suppose I wa
On Tue, Feb 6, 2018 at 12:44 PM, Ethan Furman wrote:
> Although, couldn't we add a field-level frozen attribute (using property
> for the implementation), and check that all equality fields are properties
> as well as hashable?
>
That would be a totally unrelated feature request. Let's wait whet
On 02/06/2018 12:24 PM, Guido van Rossum wrote:
On Tue, Feb 6, 2018 at 11:40 AM, Ethan Furman wrote:
It sounds like `unsafe_hash=True` indicates a truly unsafe hash (that is,
>> mutable data is involved in the hash calculation), but there still seems
>> to be one possibility for an "unsafe_ha
On Tue, Feb 6, 2018 at 11:40 AM, Ethan Furman wrote:
> It sounds like `unsafe_hash=True` indicates a truly unsafe hash (that is,
> mutable data is involved in the hash calculation), but there still seems to
> be one possibility for an "unsafe_hash" to actually be safe -- that is, if
> only immuta
That's much less self-descriptive and harder to search Google or
StackOverflow for. It's also easier to overlook. We really want to send the
signal that this is unsafe and requires serious consideration before it is
turned on.
On Tue, Feb 6, 2018 at 11:57 AM, David Mertz wrote:
> Honestly, the n
On 2/6/18 2:40 PM, Ethan Furman wrote:
On a different note, should the PEP be updated with the current
signature? It still talks about hash=None being the default.
Once we've reached an agreement, I'll update the PEP. I don't think
we're there quite yet.
Eric
___
Honestly, the name I would most want for the keyword argument is '_hash'.
That carries the semantics I desire.
On Feb 6, 2018 10:13 AM, "Ethan Furman" wrote:
> On 02/06/2018 09:38 AM, Guido van Rossum wrote:
>
> Where do you get the impression that one would have to explicitly request
>> __hash_
On 02/06/2018 11:18 AM, Guido van Rossum wrote:
We may be in violent agreement.
I propose *not* to add a way to *disable* hashing when the rest of the flags to
@dataclass() would indicate that it's
safe to add a __hash__ method.
Okay.
I propose that with @dataclass(unsafe_hash=False) (the
We may be in violent agreement.
I propose *not* to add a way to *disable* hashing when the rest of the
flags to @dataclass() would indicate that it's safe to add a __hash__
method.
I propose that with @dataclass(unsafe_hash=False) (the default), a __hash__
method is added when the following condi
On 02/06/2018 09:38 AM, Guido van Rossum wrote:
Where do you get the impression that one would have to explicitly request
__hash__ if frozen=True is set? To the
contrary, my proposal is for @dataclass to automatically add a __hash__ method
when frozen=True is set. This is what the
code current
Where do you get the impression that one would have to explicitly request
__hash__ if frozen=True is set? To the contrary, my proposal is for
@dataclass to automatically add a __hash__ method when frozen=True is set.
This is what the code currently released as 3.7.0b1 does if hash=None (the
default
On Mon, Feb 05, 2018 at 10:50:21AM -0800, David Mertz wrote:
> Absolutely I agree. 'unsafe_hash' as a name is clear warning to users.
(I don't mean to pick on David specifically, I had to reply to some
message in this thread and I just picked his.)
I'm rather gobsmacked at the attitudes of many
To add a counter-example that I'm painfully familiar with: the old Thrift for
Python makes its (mutable) structures hashable. This is "useful" because you
can memoize functions that take Thrift structures as arguments. You can key
dictionaries with them. And so on.
Unfortunately, more often the
On Tue, Feb 6, 2018 at 3:40 AM, Steven D'Aprano wrote:
> On Sat, Feb 03, 2018 at 11:45:15AM +0100, asrp wrote:
>
> [...]
>
> Here's a faked session showing the sort of thing I am referring to.
> (Note that this is just an example, not a proposal for a new language
> feature.)
>
> for x in [1,
On Mon, Feb 5, 2018 at 10:55 PM, Ethan Smith wrote:
> This list is for the discussion of development *of* Python. For
> discussion of development *with* Python, you want python-list.
>
... Whose web page can be found at
https://mail.python.org/mailman/listinfo/python-list
Steve Holden
20 matches
Mail list logo
