On 14 September 2017 at 11:44, Eric Snow wrote:
> About Subinterpreters
> =
>
> Shared data
> ---
[snip]
> To make this work, the mutable shared state will be managed by the
> Python runtime, not by any of the interpreters. Initially we will
> support only one type o
On 15 September 2017 at 12:04, Nathaniel Smith wrote:
> On Thu, Sep 14, 2017 at 5:44 PM, Nick Coghlan wrote:
>> The reason we're OK with this is that it means that only reading a new
>> message from a channel (i.e creating a cross-interpreter view) or
>> discarding a previously read message (i.e.
On Thu, Sep 14, 2017 at 5:44 PM, Nick Coghlan wrote:
> On 14 September 2017 at 15:27, Nathaniel Smith wrote:
>> I don't get it. With bytes, you can either share objects or copy them and
>> the user can't tell the difference, so you can change your mind later if you
>> want.
>> But memoryviews req
On 15 September 2017 at 02:56, Mike Miller wrote:
>
> On 2017-09-12 19:09, Nick Coghlan wrote:
>>
>> On 13 September 2017 at 02:01, Chris Barker - NOAA Federal
>> wrote:
>>>
>>> This really does match well with the record concept in databases, and
>>> most
>>> people are familiar with that.
>>
>>
On 14 September 2017 at 15:27, Nathaniel Smith wrote:
> On Sep 13, 2017 9:01 PM, "Nick Coghlan" wrote:
>
> On 14 September 2017 at 11:44, Eric Snow
> wrote:
>>send(obj):
>>
>>Send the object to the receiving end of the channel. Wait until
>>the object is received. If the ch
On 14 September 2017 at 23:02, Ivan Levkivskyi wrote:
> On 14 September 2017 at 22:07, Ethan Furman wrote:
>
>> For comparison's sake, what would the above look like using __class__
>> assignment? And what is the performance difference?
>>
>>
> FWIW I found a different solution:
>
> # file mod.
On 14 September 2017 at 22:07, Ethan Furman wrote:
> For comparison's sake, what would the above look like using __class__
> assignment? And what is the performance difference?
>
>
FWIW I found a different solution:
# file mod.py
from typing_extensions import allow_forward_references
allow_for
Let's all please take a time out from the naming discussion.
On Sep 14, 2017 11:15 AM, "Stefan Krah" wrote:
> On Thu, Sep 14, 2017 at 11:06:15AM -0700, Mike Miller wrote:
> > On 2017-09-14 10:45, Stefan Krah wrote:
> > >I'd expect something like a C struct or an ML record.
> >
> > Struct is take
On 14 September 2017 at 22:21, Ivan Levkivskyi wrote:
> On 14 September 2017 at 22:07, Ethan Furman wrote:
>
>>
>> For comparison's sake, what would the above look like using __class__
>> assignment? And what is the performance difference?
>>
>>
> Actually I tried but I can't implement this wit
On 14 September 2017 at 22:07, Ethan Furman wrote:
>
> For comparison's sake, what would the above look like using __class__
> assignment? And what is the performance difference?
>
>
Actually I tried but I can't implement this without module __getattr__
so that one can just write:
from typing_e
On 09/14/2017 12:08 PM, Ivan Levkivskyi wrote:
On 14 September 2017 at 01:13, Guido van Rossum wrote:
That last sentence is a key observation. Do we even know whether there are
(non-toy) things that you can do *in
principle* with __class__ assignment but which are too slow *in practice* to
b
(sorry for obvious mistakes in the example in previous e-mail)
On 14 September 2017 at 21:08, Ivan Levkivskyi wrote:
> On 14 September 2017 at 01:13, Guido van Rossum wrote:
>
>>
>> That last sentence is a key observation. Do we even know whether there
>> are (non-toy) things that you can do *i
On 14 September 2017 at 01:13, Guido van Rossum wrote:
>
> That last sentence is a key observation. Do we even know whether there are
> (non-toy) things that you can do *in principle* with __class__ assignment
> but which are too slow *in practice* to bother? And if yes, is __getattr__
> fast eno
On Thu, Sep 14, 2017 at 11:06:15AM -0700, Mike Miller wrote:
> On 2017-09-14 10:45, Stefan Krah wrote:
> >I'd expect something like a C struct or an ML record.
>
> Struct is taken, and your second example is record.
*If* the name were collections.record, I'd expect collections.record to
be someth
On Sep 14, 2017, at 09:56, Mike Miller wrote:
> Record is the most common name for this ubiquitous concept.
Mind if we call them Eric Classes to keep it clear? Because if its name is not
Eric Classes, it will cause a little confusion.
g’day-bruce-ly y’rs,
-Barry
signature.asc
Description:
On 2017-09-14 10:45, Stefan Krah wrote:
I'd expect something like a C struct or an ML record.
Struct is taken, and your second example is record.
from dataclass import dataclass
This is more intuitive, since the PEP example also has attached methods
like total_cost(). I don't think t
On Thu, Sep 14, 2017 at 10:24:52AM -0700, Mike Miller wrote:
> An elegant name can make the difference between another obscure
> module thrown in the stdlib to be never seen again and one that gets
> used every day. Which is more intuitive?
>
> from collections import record
I'd expect somet
On 2017-09-12 21:05, Guido van Rossum wrote:
It's ironic that some people dislike "data classes" because these are regular
classes, not just for data, while others are proposing alternative names that
emphasize the data container aspect. So "data classes" splits the difference, by
referring to
On 2017-09-12 19:09, Nick Coghlan wrote:
On 13 September 2017 at 02:01, Chris Barker - NOAA Federal
wrote:
This really does match well with the record concept in databases, and most
people are familiar with that.
No, most people aren't familiar with that - they only become familiar
with it *
19 matches
Mail list logo
