Re: [Python-Dev] PEP 554 v3 (new interpreters module)

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

Re: [Python-Dev] PEP 554 v3 (new interpreters module)

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 >>

Re: [Python-Dev] PEP 554 v3 (new interpreters module)

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

Re: [Python-Dev] PEP 557: Data Classes

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

Re: [Python-Dev] PEP 554 v3 (new interpreters module)

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

Re: [Python-Dev] PEP 549: Instance Properties (aka: module properties)

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

Re: [Python-Dev] PEP 549: Instance Properties (aka: module properties)

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

Re: [Python-Dev] PEP 557: Data Classes

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.

Re: [Python-Dev] PEP 549: Instance Properties (aka: module properties)

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? >> >> >

Re: [Python-Dev] PEP 549: Instance Properties (aka: module properties)

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

Re: [Python-Dev] PEP 549: Instance Properties (aka: module properties)

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

Re: [Python-Dev] PEP 549: Instance Properties (aka: module properties)

(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

Re: [Python-Dev] PEP 549: Instance Properties (aka: module properties)

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

Re: [Python-Dev] PEP 557: Data Classes

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

Re: [Python-Dev] PEP 557: Data Classes

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

Re: [Python-Dev] PEP 557: Data Classes

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

Re: [Python-Dev] PEP 557: Data Classes

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

Re: [Python-Dev] PEP 557: Data Classes

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

Re: [Python-Dev] PEP 557: Data Classes

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