On Fri, Feb 02, 2018 at 01:53:00AM -0500, Terry Reedy wrote:
> >>> object.__doc__
> 'The most base type'
[...]
> I have suggested
> "The superclass for all Python classes."
> "The starting base class of all types and classes other than itself."
>
> I intended to pick the second, but Serhiy Storcha
>>> object.__doc__
'The most base type'
I and several people on python-list thread "interactive help on the base
object" (Dec 2013) thought this could be improved. On
https://bugs.python.org/issue20285 and
https://github.com/python/cpython/pull/4759
After some research, I believe the follow
On 2 February 2018 at 11:49, Elvis Pranskevichus wrote:
> In my experience this type of breakage is so subtle that people will
> happily write code lots of code like this without noticing. My main
> objection here is that the dataclass does not go far enough to prevent
> obviously wrong behaviour
On Thursday, February 1, 2018 8:37:41 PM EST Eric V. Smith wrote:
> > hash=None and compare=True leads to the same result, which, I
> > think is even worse.
>
> Have you actually tried that?
I meant this:
@dataclasses.dataclass(hash=True)
class A:
foo: int = dataclasses.field(compare=True)
On 2/1/2018 8:29 PM, Elvis Pranskevichus wrote:
On Thursday, February 1, 2018 8:21:03 PM EST Eric V. Smith wrote:
I should add: This is why you shouldn't override the default
(hash=None) unless you know what the consequences are. Can I ask
why you want to specify hash=True?
hash=None and compa
On Thursday, February 1, 2018 8:21:03 PM EST Eric V. Smith wrote:
> I should add: This is why you shouldn't override the default
> (hash=None) unless you know what the consequences are. Can I ask
> why you want to specify hash=True?
hash=None and compare=True leads to the same result, which, I thi
On 2/1/2018 8:17 PM, Eric V. Smith wrote:
On 2/1/2018 7:34 PM, Elvis Pranskevichus wrote:
There appears to be a critical omission from the current dataclass
implementation: it does not make hash=True fields immutable.
Per Python spec:
"the implementation of hashable collections requires that a
On 2/1/2018 7:34 PM, Elvis Pranskevichus wrote:
There appears to be a critical omission from the current dataclass
implementation: it does not make hash=True fields immutable.
Per Python spec:
"the implementation of hashable collections requires that a key’s hash
value is immutable (if the obje
There appears to be a critical omission from the current dataclass
implementation: it does not make hash=True fields immutable.
Per Python spec:
"the implementation of hashable collections requires that a key’s hash
value is immutable (if the object’s hash value changes, it will be in
the w
>> Ned Deily is in charge of the Mac build (as well as current release
> manager). Within the last week, he revised the official builds (now two, I
> believe) for 3.7.0b1, due in a day or so. One will be a future oriented
> 64-bit build. The PR and What's New have more.
>
What's New doesn't men
> I would also point out that CPython (distutils, specifically)
supported mingw builds (that's the original mingw 32-bit version) for
a long time. Support for that bit-rotted as the mingw project
fragmented with various 64-bit versions, and slow progress from the
mingw project(s) for supporting new
On Feb 1, 2018, at 04:19, Oleg Sivokon wrote:
>
> Oh, so this is the real reason... well, corporate interests are hard to argue
> against. But, this is an interesting statistic nevertheless. Thanks for
> letting me know.
Maybe it hasn’t happened because no volunteer has stepped up to do it.
> As much as Steve is unlikely to do the work to initiate and
> maintain support of these other tools—whether due to his employer's
> interests or his own—I too was unlikely to do work like this thread is
> asking. In fact, the chances I would have done it were zero because I was
> sitting on my co
On Thu, Feb 1, 2018 at 4:19 AM, Oleg Sivokon wrote:
>
> > so why shouldn’t the one with the most users?
>
> Because it makes compilation difficult, and cross-compilatin completely
> impossible? Why is it difficult: a package maintainer needs to (1) buy MS
> Windows (2) create a special workflow
On 2018-02-01 10:19, Oleg Sivokon wrote:
>
>> so why shouldn’t the one with the most users?
>
> Because it makes compilation difficult, and cross-compilatin completely
> impossible? Why is it difficult: a package maintainer needs to (1) buy MS
> Windows (2) create a special workflow for compil
> so why shouldn’t the one with the most users?
Because it makes compilation difficult, and cross-compilatin completely
impossible? Why is it difficult: a package maintainer needs to (1) buy MS
Windows (2) create a special workflow for compiling on a different machine.
This is both costly an
On Thu, Feb 1, 2018 at 12:18 AM, Chris Barker wrote:
> On Wed, Jan 31, 2018 at 3:13 AM, Joni Orponen
> wrote:
>
>> On Wed, Jan 31, 2018 at 12:43 AM, Chris Barker - NOAA Federal <
>> chris.bar...@noaa.gov> wrote:
>>
>>> And maybe we could even get rid of the "Framework" builds..
>>>
>>>
On 1 February 2018 at 00:42, Gregory P. Smith wrote:
> TL;DR of Steve's post - MSVC is the compiler of choice for most serious
> software on Windows. So we use it to best integrate with the world. There is
> no compelling reason to change that.
>
> The free-as-in-beer MSVC community edition is fin
18 matches
Mail list logo
