> On 30 Jan 2018, at 18:42, Chris Barker wrote:
>
> Ned,
>
> It looks like you're still building OS-X the same way as in the past:
>
> Intel 32+64 bit, 10.6 compatibility
>
> Is that right?
>
> Might it be time for an update?
>
> Do we still need to support 32 bit? From:
>
> https://appl
> On 1 Feb 2018, at 02:34, Ned Deily wrote:
>
> […]
>
> Attention macOS users: with 3.7.0b1, we are providing a choice of
> two binary installers. The new variant provides a 64-bit-only
> version for macOS 10.9 and later systems; this variant also now
> includes its own built-in version of Tc
>> IMO, the danger of
>> "@dataclass(hash=True)" far overweighs whatever convenience it might
>> provide.
Is there any reason specifying has=True could set frozen=True unless
the user specifically sets frozen=False?
Or is that already the case?
I think the folks that are concerned about this iss
On Sun, Feb 4, 2018 at 11:59 AM, Chris Barker - NOAA Federal <
chris.bar...@noaa.gov> wrote:
> I think the folks that are concerned about this issue are quite right
> — most Python users equate immutable and hashable—so the dataclass API
> should reflect that.
>
Since they are *not* equivalent (c
On behalf of the Python development community, I'm happy to announce the
availability of Python 3.4.8 and Python 3.5.5.
Both Python 3.4 and 3.5 are in "security fixes only" mode. Both
versions only accept security fixes, not conventional bug fixes, and
both releases are source-only.
You
On 5 February 2018 at 08:31, Guido van Rossum wrote:
> On Sun, Feb 4, 2018 at 11:59 AM, Chris Barker - NOAA Federal
> wrote:
>>
>> I think the folks that are concerned about this issue are quite right
>> — most Python users equate immutable and hashable—so the dataclass API
>> should reflect that
I understand auto-generating the __hash__ (and __eq__) for a frozen
container; that is just convenient.
But why is there any desire to autogenerate a __hash__ for something
that isn't frozen? Like a list or dict, the normal case would be for
it not to have a hash at all, and the author *should* w
That's a lot to read between the lines. I was unhappy that Chris took the
statement that immutability and hashability are equivalent, claimed that
most people think of it that way, and did not point out that it was false,
thereby making the impression that he wasn't aware of the difference.
The wa
Looks like this is turning into a major flamewar regardless of what I say.
:-(
I really don't want to lose the ability to add a hash function to a mutable
dataclass by flipping a flag in the decorator. I'll explain below. But I am
fine if this flag has a name that clearly signals it's an unsafe th
+1 using unsafe_hash as a name addresses my concern. It's a good signal
that there are caveats worth considering.
-gps
On Sun, Feb 4, 2018, 9:50 PM Guido van Rossum wrote:
> Looks like this is turning into a major flamewar regardless of what I say.
> :-(
>
> I really don't want to lose the abil
On Sun, Feb 4, 2018 at 7:54 PM, Nick Coghlan wrote:
> On 5 February 2018 at 08:31, Guido van Rossum wrote:
> > On Sun, Feb 4, 2018 at 11:59 AM, Chris Barker - NOAA Federal
> > wrote:
> >>
> >> I think the folks that are concerned about this issue are quite right
> >> — most Python users equate
On Sun, Feb 4, 2018 at 11:57 PM, Gregory P. Smith wrote:
> +1 using unsafe_hash as a name addresses my concern.
>
mine too -- anyone surprised by using this deserves what they get :-)
-CHB
On Sun, Feb 4, 2018, 9:50 PM Guido van Rossum wrote:
>
>> Looks like this is turning into a major flamew
On 2/4/2018 9:49 PM, Guido van Rossum wrote:
A frozen class requires a lot of discipline, since you have to compute
the values of all fields before calling the constructor. A mutable
class allows other initialization patterns, e.g. manually setting some
fields after the instance has been constr
13 matches
Mail list logo
