Re: [Python-Dev] PEP 487: Simpler customization of class creation

OK, I see this point now. Still looking for time to review the rest of your PEP! --Guido (mobile) On Jul 3, 2016 3:29 PM, "Martin Teichmann" wrote: > Hi Guido, > > sorry I missed your post... > > >> One of the big issues that makes library authors reluctant to use > >> metaclasses > >> (even whe

Re: [Python-Dev] PEP 487: Simpler customization of class creation

Hi Guido, sorry I missed your post... >> One of the big issues that makes library authors reluctant to use >> metaclasses >> (even when they would be appropriate) is the risk of metaclass conflicts. > > Really? I've written and reviewed a lot of metaclasses and this has never > worried me. The pr

Re: [Python-Dev] PEP 487: Simpler customization of class creation

> One of the big issues that makes library authors reluctant to use metaclasses > (even when they would be appropriate) is the risk of metaclass conflicts. Really? I've written and reviewed a lot of metaclasses and this has never worried me. The problem is limited to multiple inheritance, right?

Re: [Python-Dev] PEP 487: Simpler customization of class creation

Hi Nick, hi List, thanks for the good comments! I'll update the PEP and the implementation soon, as discussed at the end, I'll do it in C this time. For now just some quick responses: > This part isn't entirely clear to me, so you may want to give some > Python pseudo-code that: I will actually

Re: [Python-Dev] PEP 487: Simpler customization of class creation

I think in any case Type is a bad name, since we now have typing.Type (and it is completely different) I could imagine a lot of confusion. -- Ivan On 25 June 2016 at 00:17, Eric Snow wrote: > On Fri, Jun 24, 2016 at 1:50 PM, Nick Coghlan wrote: > > Honestly though, I'm not sure this addition

Re: [Python-Dev] PEP 487: Simpler customization of class creation

On Fri, Jun 24, 2016 at 1:50 PM, Nick Coghlan wrote: > Honestly though, I'm not sure this additional user-visible complexity > is worth it - "The default type metaclass has this new behaviour" is a > lot easier to document and explain than "We added a new opt-in > alternate metaclass that you can

Re: [Python-Dev] PEP 487: Simpler customization of class creation

On 24 June 2016 at 00:41, Martin Teichmann wrote: > Hi list, > > just recently, I posted about the implementation of PEP 487. The > discussion quickly diverted to PEP 520, which happened to be > strongly related. > > Hoping to get some comments about the rest of PEP 487, I took > out the part that

[Python-Dev] PEP 487: Simpler customization of class creation

Hi list, just recently, I posted about the implementation of PEP 487. The discussion quickly diverted to PEP 520, which happened to be strongly related. Hoping to get some comments about the rest of PEP 487, I took out the part that is also in PEP 520. I attached the new version of the PEP. The i

Re: [Python-Dev] PEP 487: Simpler customization of class creation

On Wed 2016-06-22 Eric Snow [mailto:ericsnowcurren...@gmail.com] wrote: > The problem I have with this is that it still doesn't give any strong > relationship with the class definition. > Certainly in most cases it will amount to the same thing. However, there is > no way to know if cls.__dict__

Re: [Python-Dev] PEP 487: Simpler customization of class creation

Nick Coghlan wrote: Something that isn't currently defined in PEP 520 ... is where descriptors implicitly defined via __slots__ will appear relative to other attributes. In the place where the __slots__ attribute appears? -- Greg ___ Python-Dev maili

Re: [Python-Dev] PEP 487: Simpler customization of class creation

On Tue, Jun 21, 2016 at 3:01 PM, Nick Coghlan wrote: > RIght, if *tp_dict itself* on type objects is guaranteed to be > order-preserviing, then we don't need to do anything except perhaps > provide a helper method or descriptor on type that automatically > filters out the dunder-attributes, and sp

Re: [Python-Dev] PEP 487: Simpler customization of class creation

On Tue, Jun 21, 2016 at 11:18 AM, Guido van Rossum wrote: > If we had had these semantics in the language from the start, there would have > been plenty uses of this order, and I suspect nobody would have considered > asking for __definition_order__. True. The key thing that __definition_order__

Re: [Python-Dev] PEP 487: Simpler customization of class creation

On Wed, Jun 22, 2016 at 2:50 AM, Raymond Hettinger wrote: > >> On Jun 21, 2016, at 10:18 AM, Guido van Rossum wrote: >> >> Judging from Inada's message there seems to be some confusion about how well >> the compact dict preserves order (personally I think if it doesn't guarantee >> order after

Re: [Python-Dev] PEP 487: Simpler customization of class creation

On 21 June 2016 at 10:18, Guido van Rossum wrote: > On Tue, Jun 21, 2016 at 10:12 AM, Eric Snow > wrote: >> >> On Mon, Jun 20, 2016 at 12:31 PM, Nikita Nemkin wrote: >> > Right. Ordered by default is a very serious implementation constraint. >> > It's only superior in a sense that it completely

Re: [Python-Dev] PEP 487: Simpler customization of class creation

> On Jun 21, 2016, at 10:18 AM, Guido van Rossum wrote: > > Judging from Inada's message there seems to be some confusion about how well > the compact dict preserves order (personally I think if it doesn't guarantee > order after deletions it's pretty useless). Inada should follow PyPy's impl

Re: [Python-Dev] PEP 487: Simpler customization of class creation

On Tue, Jun 21, 2016 at 10:12 AM, Eric Snow wrote: > On Mon, Jun 20, 2016 at 12:31 PM, Nikita Nemkin wrote: > > Right. Ordered by default is a very serious implementation constraint. > > It's only superior in a sense that it completely subsumes/obsoletes > > PEP 520. > > Just to be clear, PEP 52

Re: [Python-Dev] PEP 487: Simpler customization of class creation

On Mon, Jun 20, 2016 at 12:31 PM, Nikita Nemkin wrote: > Right. Ordered by default is a very serious implementation constraint. > It's only superior in a sense that it completely subsumes/obsoletes > PEP 520. Just to be clear, PEP 520 is more than just OrderedDict-by-default. In fact, the key poi

Re: [Python-Dev] PEP 487: Simpler customization of class creation

> On Jun 20, 2016, at 5:41 PM, Tim Delaney wrote: > > Although not a Jython developer, I've looked into the code a few times. > > The major stumbling block as I understand it will be that Jython uses a > ConcurrentHashMap as the underlying structure for a dictionary. This would > need to chan

Re: [Python-Dev] PEP 487: Simpler customization of class creation

On 21 June 2016 at 06:12, Guido van Rossum wrote: > OK, basically you're arguing that knowing the definition order of class > attributes is often useful when (ab)using Python for things like schema or > form definitions. There are a few ways to go about it: > > 1. A hack using a global creation c

Re: [Python-Dev] PEP 487: Simpler customization of class creation

OK, basically you're arguing that knowing the definition order of class attributes is often useful when (ab)using Python for things like schema or form definitions. There are a few ways to go about it: 1. A hack using a global creation counter

Re: [Python-Dev] PEP 487: Simpler customization of class creation

On Mon, Jun 20, 2016 at 9:48 PM, Guido van Rossum wrote: > On Thu, Jun 16, 2016 at 3:24 PM, Nikita Nemkin wrote: >> >> I didin't know that PyPy has actually implemented packed ordered dicts! >> >> https://morepypy.blogspot.ru/2015/01/faster-more-memory-efficient-and-more.html >> https://mail.pyth

Re: [Python-Dev] PEP 487: Simpler customization of class creation

On Thu, Jun 16, 2016 at 3:24 PM, Nikita Nemkin wrote: > On Fri, Jun 17, 2016 at 2:36 AM, Nick Coghlan wrote: > > On 16 June 2016 at 14:17, Martin Teichmann > wrote: > > > An implementation like PyPy, with an inherently ordered standard dict > > implementation, can just rely on that rather than

Re: [Python-Dev] PEP 487: Simpler customization of class creation

On Fri, Jun 17, 2016 at 2:36 AM, Nick Coghlan wrote: > On 16 June 2016 at 14:17, Martin Teichmann wrote: > An implementation like PyPy, with an inherently ordered standard dict > implementation, can just rely on that rather than being obliged to > switch to their full collections.OrderedDict typ

Re: [Python-Dev] PEP 487: Simpler customization of class creation

On Thu, Jun 16, 2016 at 3:36 PM, Nick Coghlan wrote: > I don't think that's a side note, I think it's an important point (and > relates to one of Nikita's questions as well): we have the option of > carving out certain aspects of PEP 520 as CPython implementation > details. > > In particular, the

Re: [Python-Dev] PEP 487: Simpler customization of class creation

On 16 June 2016 at 14:17, Martin Teichmann wrote: > As a side note, you propose to use OrderedDict as the class definition > namespace, and this is exactly how I implemented it. Nonetheless, I > would like to keep this fact as an implementation detail, such that > other implementations of Python (

Re: [Python-Dev] PEP 487: Simpler customization of class creation

Hi Eric, hi List, > I'd be glad to give feedback on this, probably later today or > tomorrow. In particular, I'd like to help resolve the intersection > with PEP 520. :) Thanks in advance! Let me already elaborate on the differences, so that others can follow: You chose the name "__definition_o

Re: [Python-Dev] PEP 487: Simpler customization of class creation

On Thu, Jun 16, 2016 at 12:56 PM, Martin Teichmann wrote: > I am looking forward to a lot of comments on this! I'd be glad to give feedback on this, probably later today or tomorrow. In particular, I'd like to help resolve the intersection with PEP 520. :) -eric

[Python-Dev] PEP 487: Simpler customization of class creation

Hi list, using metaclasses in Python is a very flexible method of customizing class creation, yet this customization comes at a cost: once you want to combine two classes with different metaclasses, you run into problems. This is why I proposed PEP 487 (see https://github.com/tecki/peps/blob/pep4