Re: [Python-Dev] Submitting PEP 422 (Simple class initialization hook) for pronouncement
On Tue, Feb 12, 2013 at 8:35 AM, Guido van Rossum wrote: > On Mon, Feb 11, 2013 at 2:29 PM, Nick Coghlan wrote: >> 4.__class__ is already bound as soon as we have a class object to bind it >> to, so we can't move it any earlier. However, it's already early enough to >> let references to it from the new method (including the implied one in >> zero-arg super) work properly. The black magic that is zero-arg super also >> deals with PJE's concern about propagating the actual class up the MRO (as >> it is equivalent to "super(__class__, first_argument)"). > > So where is it not bound when a metaclass runs? I guess in the metaclass's > __new__()? Because in the metaclass's __init__() it should exist IIUC. I stand corrected, we don't *quite* bind it as soon as the class object exists - we bind it as soon as the call to the metaclass returns. So even though the class object exists when __init__ runs, it isn't bound to __class__ yet. Given that the class construction machinery treats the metaclass constructor as an opaque callable, trying to get the cell binding to happen between the call to __new__ and the one to __init__ would be rather challenging (Translation: I'm not sure where you would even start...). Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Submitting PEP 422 (Simple class initialization hook) for pronouncement
On 12/02/13 10:56, Jan Kaliszewski wrote: Wouldn't __initclass__ be readable enough? IMHO it could spare users trouble with remembering special case. +1 I approve of the colour of this bikeshed. __init_class__ has too many underscores. -- Steven ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Submitting PEP 422 (Simple class initialization hook) for pronouncement
11.02.2013 23:29, Nick Coghlan wrote: 3. I'm trying to avoid any custom magic specific to this method, but making it implicitly a static or class method is fairly easy if we so choose - the standard retrieval code during class creation can just bypass the descriptor machinery, and wrap it in staticmethod or classmethod if it isn't already. Given that __new__ is already implicitly static, it may be easier to follow that precedent here rather than trying to explain why an explicit @classmethod is needed in one case but not the other. Though __new__ is implicitly a *static* rather than a *class* method (so we can use it e.g. by calling object.__new__(MyClass), though -- besides -- in Py3k unbound methods have gone so the difference between static and non-static-and-non-class-methods is smaller than in Py2.x), in case of __init_class__ + super() it'd have to be called: super().__init_class__(__class__) ...and it seems to me a bit awkward. And making it implicitly a *class* rather than a *static* method whould make *impossible* to do calls such as: ExplicitAncestor.__init_class__(ExplicitDescendant) ...though I'm not sure we'd ever need such a call. If not -- implicit *class* method may be a good idea, but if we would? *** On the margin: is that middle underscore in '__init_class__' necessary? We had __metaclass__, not __meta_class__... OK, it's one world, but still we also have __getattr__, __getattribute__, __getitem__, __instancecheck__, __qualname__, __truediv__ etc. (not __get_attr__, __instance_check__ etc.). [I remember only one exception: __reduce_ex__, rather rarely used, and easy to defend against weird __reduceex__]. Wouldn't __initclass__ be readable enough? IMHO it could spare users trouble with remembering special case. Cheers. *j ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Submitting PEP 422 (Simple class initialization hook) for pronouncement
On Mon, Feb 11, 2013 at 2:29 PM, Nick Coghlan wrote: > > On 12 Feb 2013 07:44, "Guido van Rossum" wrote: > > > > On Mon, Feb 11, 2013 at 12:57 PM, PJ Eby wrote: > >> > >> On Mon, Feb 11, 2013 at 12:44 PM, Guido van Rossum > wrote: > >> > Hi Nick, > >> > > >> > I think this will make a fine addition to the language. I agree that > >> > it is superior to the alternatives and fulfills a real (if rare) need. > >> > > >> > I only have a few nits/questions/suggestions. > >> > > >> > - With PJE, I think __init_class__ should automatically be a class > >> > method. > >> > >> Actually, I didn't say that as such, because I'm not sure how the heck > >> we'd implement that. ;-) > >> > >> For example, at what point is it converted to a classmethod? Is it > >> going to be a slot method with special C-level handling? Handled by > >> the compiler? What happens if somebody makes it a > >> > >> > The same way that __new__ is automatically a class method. > >> > >> Actually, isn't it automatically a staticmethod? Oh crap. Now that > >> I'm thinking about it, doesn't this *have* to be a static method, > >> explicitly passing in the class? I mean, otherwise, won't calling > >> super().__init_class__() invoke it on the base class, rather than the > >> current class? > >> > >> ISTM that EIBTI argues for the __new__/staticmethod approach, > >> especially if you're returning the class (per below) > > > > > > Let's see what Nick and the implementer say. > > I think these are some interesting ideas and it's going to take me a while > to digest them and update the PEP :) > Heh. :-) > A few random thoughts: > > 1. I like the idea of a metaprogramming "howto" that provides advice on > choosing a suitable level of metaprogramming (with the default choice being > "use existing decorators", then escalating through creating custom > decorators all the way to creating custom metaclasses). I don't think the > PEP needs to be conditional on writing that, but I will at least add PJE's > list to the PEP itself. > Sure. > 2. I see the new method as more analogous to__init__ than to__new__, so > the __decorate_class__ idea makes me nervous, as it's closer to a __new__ > method. Composition gets a *lot* harder when your parent class can switch > out the object on you. > Fair enough. > 3. I'm trying to avoid any custom magic specific to this method, but > making it implicitly a static or class method is fairly easy if we so > choose - the standard retrieval code during class creation can just bypass > the descriptor machinery, and wrap it in staticmethod or classmethod if it > isn't already. Given that __new__ is already implicitly static, it may be > easier to follow that precedent here rather than trying to explain why an > explicit @classmethod is needed in one case but not the other. > Also fair enough. > 4.__class__ is already bound as soon as we have a class object to bind it > to, so we can't move it any earlier. However, it's already early enough to > let references to it from the new method (including the implied one in > zero-arg super) work properly. The black magic that is zero-arg super also > deals with PJE's concern about propagating the actual class up the MRO (as > it is equivalent to "super(__class__, first_argument)"). > So where is it not bound when a metaclass runs? I guess in the metaclass's __new__()? Because in the metaclass's __init__() it should exist IIUC. > 5. Implicitly walking the MRO bothers me, as it becomes a special case for > people to learn. We don't do that for __init__ or __new__, so I don't think > it makes sense to do it here. We can include a recommended structure in the > docs, where the first step is calling the parent through. As PJE suggested, > a no-op method on type will make that simple and fairly safe (people using > a metaclass hierarchy not anchored on type can figure out their own > equivalent) > Agreed. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Submitting PEP 422 (Simple class initialization hook) for pronouncement
On 12 Feb 2013 07:44, "Guido van Rossum" wrote: > > On Mon, Feb 11, 2013 at 12:57 PM, PJ Eby wrote: >> >> On Mon, Feb 11, 2013 at 12:44 PM, Guido van Rossum wrote: >> > Hi Nick, >> > >> > I think this will make a fine addition to the language. I agree that >> > it is superior to the alternatives and fulfills a real (if rare) need. >> > >> > I only have a few nits/questions/suggestions. >> > >> > - With PJE, I think __init_class__ should automatically be a class >> > method. >> >> Actually, I didn't say that as such, because I'm not sure how the heck >> we'd implement that. ;-) >> >> For example, at what point is it converted to a classmethod? Is it >> going to be a slot method with special C-level handling? Handled by >> the compiler? What happens if somebody makes it a >> >> > The same way that __new__ is automatically a class method. >> >> Actually, isn't it automatically a staticmethod? Oh crap. Now that >> I'm thinking about it, doesn't this *have* to be a static method, >> explicitly passing in the class? I mean, otherwise, won't calling >> super().__init_class__() invoke it on the base class, rather than the >> current class? >> >> ISTM that EIBTI argues for the __new__/staticmethod approach, >> especially if you're returning the class (per below) > > > Let's see what Nick and the implementer say. I think these are some interesting ideas and it's going to take me a while to digest them and update the PEP :) A few random thoughts: 1. I like the idea of a metaprogramming "howto" that provides advice on choosing a suitable level of metaprogramming (with the default choice being "use existing decorators", then escalating through creating custom decorators all the way to creating custom metaclasses). I don't think the PEP needs to be conditional on writing that, but I will at least add PJE's list to the PEP itself. 2. I see the new method as more analogous to__init__ than to__new__, so the __decorate_class__ idea makes me nervous, as it's closer to a __new__ method. Composition gets a *lot* harder when your parent class can switch out the object on you. 3. I'm trying to avoid any custom magic specific to this method, but making it implicitly a static or class method is fairly easy if we so choose - the standard retrieval code during class creation can just bypass the descriptor machinery, and wrap it in staticmethod or classmethod if it isn't already. Given that __new__ is already implicitly static, it may be easier to follow that precedent here rather than trying to explain why an explicit @classmethod is needed in one case but not the other. 4.__class__ is already bound as soon as we have a class object to bind it to, so we can't move it any earlier. However, it's already early enough to let references to it from the new method (including the implied one in zero-arg super) work properly. The black magic that is zero-arg super also deals with PJE's concern about propagating the actual class up the MRO (as it is equivalent to "super(__class__, first_argument)"). 5. Implicitly walking the MRO bothers me, as it becomes a special case for people to learn. We don't do that for __init__ or __new__, so I don't think it makes sense to do it here. We can include a recommended structure in the docs, where the first step is calling the parent through. As PJE suggested, a no-op method on type will make that simple and fairly safe (people using a metaclass hierarchy not anchored on type can figure out their own equivalent) Cheers, Nick. > >> >> > - Would it make any sense to require that __init_class__ *returns* the >> > new class object (to complete the similarity with class decorators)? >> >> It would certainly be quite useful to do so, but in that case, perhaps >> the method should be named __decorate_class__? And in that event the >> standard usage would look like: >> >> def __decorate_class__(cls): >> cls = super().__decorate_class__(cls) >> # do stuff >> return cls >> >> On the other hand, one could just drop the super() requirement and >> make the usage even simpler by having the class machinery walk the MRO >> and pass each method the result of invoking the previous one. Then >> the methods are short and sweet, and super() and __class__ don't come >> into it. (Though I guess the class machinery could keep setting >> __class__ to whatever the last-returned class was.) >> >> In his first draft, Nick implemented inheritable decorators instead, >> using a __decorators__ attribute in the class body, or something like >> that. While that approach had an issue or two of its own, it's >> possible that just going with a single __decorate_class__ method would >> work out better. > > > Half-baked idea: Maybe the base class __decorate_class__ would call the class decorators? Or does that not make sense? > > -- > --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailm
Re: [Python-Dev] Submitting PEP 422 (Simple class initialization hook) for pronouncement
On Mon, Feb 11, 2013 at 12:57 PM, PJ Eby wrote: > On Mon, Feb 11, 2013 at 12:44 PM, Guido van Rossum > wrote: > > Hi Nick, > > > > I think this will make a fine addition to the language. I agree that > > it is superior to the alternatives and fulfills a real (if rare) need. > > > > I only have a few nits/questions/suggestions. > > > > - With PJE, I think __init_class__ should automatically be a class > > method. > > Actually, I didn't say that as such, because I'm not sure how the heck > we'd implement that. ;-) > > For example, at what point is it converted to a classmethod? Is it > going to be a slot method with special C-level handling? Handled by > the compiler? What happens if somebody makes it a > > > The same way that __new__ is automatically a class method. > > Actually, isn't it automatically a staticmethod? Oh crap. Now that > I'm thinking about it, doesn't this *have* to be a static method, > explicitly passing in the class? I mean, otherwise, won't calling > super().__init_class__() invoke it on the base class, rather than the > current class? > > ISTM that EIBTI argues for the __new__/staticmethod approach, > especially if you're returning the class (per below) > Let's see what Nick and the implementer say. > > - Would it make any sense to require that __init_class__ *returns* the > > new class object (to complete the similarity with class decorators)? > > It would certainly be quite useful to do so, but in that case, perhaps > the method should be named __decorate_class__? And in that event the > standard usage would look like: > > def __decorate_class__(cls): > cls = super().__decorate_class__(cls) > # do stuff > return cls > > On the other hand, one could just drop the super() requirement and > make the usage even simpler by having the class machinery walk the MRO > and pass each method the result of invoking the previous one. Then > the methods are short and sweet, and super() and __class__ don't come > into it. (Though I guess the class machinery could keep setting > __class__ to whatever the last-returned class was.) > > In his first draft, Nick implemented inheritable decorators instead, > using a __decorators__ attribute in the class body, or something like > that. While that approach had an issue or two of its own, it's > possible that just going with a single __decorate_class__ method would > work out better. > Half-baked idea: Maybe the base class __decorate_class__ would call the class decorators? Or does that not make sense? -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Submitting PEP 422 (Simple class initialization hook) for pronouncement
On Mon, Feb 11, 2013 at 12:44 PM, Guido van Rossum wrote: > Hi Nick, > > I think this will make a fine addition to the language. I agree that > it is superior to the alternatives and fulfills a real (if rare) need. > > I only have a few nits/questions/suggestions. > > - With PJE, I think __init_class__ should automatically be a class > method. Actually, I didn't say that as such, because I'm not sure how the heck we'd implement that. ;-) For example, at what point is it converted to a classmethod? Is it going to be a slot method with special C-level handling? Handled by the compiler? What happens if somebody makes it a > The same way that __new__ is automatically a class method. Actually, isn't it automatically a staticmethod? Oh crap. Now that I'm thinking about it, doesn't this *have* to be a static method, explicitly passing in the class? I mean, otherwise, won't calling super().__init_class__() invoke it on the base class, rather than the current class? ISTM that EIBTI argues for the __new__/staticmethod approach, especially if you're returning the class (per below) > - Would it make any sense to require that __init_class__ *returns* the > new class object (to complete the similarity with class decorators)? It would certainly be quite useful to do so, but in that case, perhaps the method should be named __decorate_class__? And in that event the standard usage would look like: def __decorate_class__(cls): cls = super().__decorate_class__(cls) # do stuff return cls On the other hand, one could just drop the super() requirement and make the usage even simpler by having the class machinery walk the MRO and pass each method the result of invoking the previous one. Then the methods are short and sweet, and super() and __class__ don't come into it. (Though I guess the class machinery could keep setting __class__ to whatever the last-returned class was.) In his first draft, Nick implemented inheritable decorators instead, using a __decorators__ attribute in the class body, or something like that. While that approach had an issue or two of its own, it's possible that just going with a single __decorate_class__ method would work out better. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] My CLA
On Monday, February 11, 2013 at 2:23 PM, Antoine Pitrou wrote: > On Mon, 11 Feb 2013 22:07:50 +0300 > anatoly techtonik mailto:techto...@gmail.com)> wrote: > > On Mon, Feb 11, 2013 at 9:27 PM, Guido van Rossum > (mailto:gu...@python.org)> wrote: > > > > > Anatoly, stop this discussion *NOW*. It is not appropriate for python-dev > > > and you risk being banned from python-dev if you keep it up. > > > > > > > > It is not a problem for me to keep silence for another couple of months. > > But this weekend there will be an open source conference in Belarus [1], > > and I will need to explain what this specific CLA is about in > > developer-friendly language translated to Russian. > > > > The Python contributor agreement allows the PSF to safely redistribute > your contributions under its own license, the PSF license. > > The Python contributor agreement is *not* a copyright assignment: you > legally remain the author of the code you contributed (i.e. you can also > publish it elsewhere under any license you want). > > Regards > > Antoine. > FWIW: Django's FAQ spells out the same reasons we have one for Python: https://www.djangoproject.com/foundation/cla/faq/ just s/Django/Python/ and s/Django Software Foundation/Python Software Foundation/ - it's a good concise FAQ. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] My CLA
On Mon, 11 Feb 2013 22:07:50 +0300 anatoly techtonik wrote: > On Mon, Feb 11, 2013 at 9:27 PM, Guido van Rossum wrote: > > > Anatoly, stop this discussion *NOW*. It is not appropriate for python-dev > > and you risk being banned from python-dev if you keep it up. > > > > It is not a problem for me to keep silence for another couple of months. > But this weekend there will be an open source conference in Belarus [1], > and I will need to explain what this specific CLA is about in > developer-friendly language translated to Russian. The Python contributor agreement allows the PSF to safely redistribute your contributions under its own license, the PSF license. The Python contributor agreement is *not* a copyright assignment: you legally remain the author of the code you contributed (i.e. you can also publish it elsewhere under any license you want). Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] My CLA
On Mon, Feb 11, 2013 at 9:27 PM, Guido van Rossum wrote: > Anatoly, stop this discussion *NOW*. It is not appropriate for python-dev > and you risk being banned from python-dev if you keep it up. > It is not a problem for me to keep silence for another couple of months. But this weekend there will be an open source conference in Belarus [1], and I will need to explain what this specific CLA is about in developer-friendly language translated to Russian. So what would be the best place to discuss the matter in public, so that I can give a link to the discussion afterwards? 1. http://lvee.org/en/main ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Question regarding: Lib/_markupbase.py
Warning: see http://bugs.python.org/issue17170. Depending on the length of
the string being scanned and the probability of finding the specific
character, the proposed change could actually be a *pessimization*. OTOH if
the character occurs many times, the slice will actually cause O(N**2)
behavior. So yes, it depends greatly on the distribution of the input data.
On Mon, Feb 11, 2013 at 4:37 AM, Oleg Broytman wrote:
> On Mon, Feb 11, 2013 at 12:16:48PM +, Developer Developer <
> just_another_develo...@yahoo.de> wrote:
> > I was having a look at the file: Lib/_markupbase.py (@ 82151), function:
> "_parse_doctype_element" and have seen something that has caught my
> attention:
> >
> > if '>' in rawdata[j:]:
> > return rawdata.find(">", j) + 1
> >
> >
> > Wouldn't it be better to do the following?
> > pos = rawdata.find(">", j)
> > if pos != -1:
> > return pos + 1
> >
> > Otherwise I think we are scanning rawdata[j:] twice.
>
>Is it really a significant optimization? Can you do an experiment and
> show figures?
>
> Oleg.
> --
> Oleg Broytmanhttp://phdru.name/p...@phdru.name
>Programmers don't die, they just GOSUB without RETURN.
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/guido%40python.org
>
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] My CLA
On Mon, Feb 11, 2013 at 12:30 PM, Oleg Broytman wrote: > On Mon, Feb 11, 2013 at 09:18:58PM +0300, anatoly techtonik > wrote: >> On Mon, Feb 11, 2013 at 4:01 PM, Oleg Broytman wrote: >> >> > On Mon, Feb 11, 2013 at 03:49:39PM +0300, anatoly techtonik < >> > techto...@gmail.com> wrote: >> > > Python Contributor Agreement >> > > >> > > I allow PSF to release all my code that I submitted to >> > > it, under any open source license. >> > >> >Good intention but wrong way of expressing it. Please do it properly -- >> > via a signed paper. You can send it by snail mail, or you can scan it >> > and send by email. >> >> What's wrong with it? Is the text not clear? Or there is a problem to >> threat email as a document? > >Yes, email is not a legally recognized document. Electronic signature > *could* make it legally recognizable but it very much depends on the > organization where you send email to and on the certificate you use to > sign mail. >Contact PSF for details. I doubt python-dev is a proper list to > discuss PSF-related legal issues. There are no further details. Either the proper document is signed or it isn't. Hopefully this is the end of the discussion. Brian Curtin Director Python Software Foundation ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Question regarding: Lib/_markupbase.py
On Mon, Feb 11, 2013 at 12:16:48PM +, Developer Developer
wrote:
> I was having a look at the file: Lib/_markupbase.py (@ 82151), function:
> "_parse_doctype_element" and have seen something that has caught my attention:
>
> if '>' in rawdata[j:]:
> return rawdata.find(">", j) + 1
>
>
> Wouldn't it be better to do the following?
> pos = rawdata.find(">", j)
> if pos != -1:
> return pos + 1
>
> Otherwise I think we are scanning rawdata[j:] twice.
Is it really a significant optimization? Can you do an experiment and
show figures?
Oleg.
--
Oleg Broytmanhttp://phdru.name/p...@phdru.name
Programmers don't die, they just GOSUB without RETURN.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] My CLA
On Mon, Feb 11, 2013 at 09:18:58PM +0300, anatoly techtonik wrote: > On Mon, Feb 11, 2013 at 4:01 PM, Oleg Broytman wrote: > > > On Mon, Feb 11, 2013 at 03:49:39PM +0300, anatoly techtonik < > > techto...@gmail.com> wrote: > > > Python Contributor Agreement > > > > > > I allow PSF to release all my code that I submitted to > > > it, under any open source license. > > > >Good intention but wrong way of expressing it. Please do it properly -- > > via a signed paper. You can send it by snail mail, or you can scan it > > and send by email. > > What's wrong with it? Is the text not clear? Or there is a problem to > threat email as a document? Yes, email is not a legally recognized document. Electronic signature *could* make it legally recognizable but it very much depends on the organization where you send email to and on the certificate you use to sign mail. Contact PSF for details. I doubt python-dev is a proper list to discuss PSF-related legal issues. Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] My CLA
Anatoly, stop this discussion *NOW*. It is not appropriate for python-dev and you risk being banned from python-dev if you keep it up. On Mon, Feb 11, 2013 at 10:18 AM, anatoly techtonik wrote: > On Mon, Feb 11, 2013 at 4:01 PM, Oleg Broytman wrote: > >> On Mon, Feb 11, 2013 at 03:49:39PM +0300, anatoly techtonik < >> techto...@gmail.com> wrote: >> > Python Contributor Agreement >> > >> > I allow PSF to release all my code that I submitted to >> > it, under any open source license. >> >>Good intention but wrong way of expressing it. Please do it properly -- >> via a signed paper. You can send it by snail mail, or you can scan it >> and send by email. > > > What's wrong with it? Is the text not clear? Or there is a problem to > threat email as a document? > > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > > -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] My CLA
2013/2/11 anatoly techtonik > On Mon, Feb 11, 2013 at 4:01 PM, Oleg Broytman wrote: > >> On Mon, Feb 11, 2013 at 03:49:39PM +0300, anatoly techtonik < >> techto...@gmail.com> wrote: >> > Python Contributor Agreement >> > >> > I allow PSF to release all my code that I submitted to >> > it, under any open source license. >> >>Good intention but wrong way of expressing it. Please do it properly -- >> via a signed paper. You can send it by snail mail, or you can scan it >> and send by email. > > > What's wrong with it? Is the text not clear? Or there is a problem to > threat email as a document? > See the "Submission Instructions" there: http://www.python.org/psf/contrib/ The Contributor Agreement is part of a formal process. It's necessary to follow the rules, even if they were written by a lawyer and we don't understand all the reasons. -- Amaury Forgeot d'Arc ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] My CLA
On Mon, Feb 11, 2013 at 4:01 PM, Oleg Broytman wrote: > On Mon, Feb 11, 2013 at 03:49:39PM +0300, anatoly techtonik < > techto...@gmail.com> wrote: > > Python Contributor Agreement > > > > I allow PSF to release all my code that I submitted to > > it, under any open source license. > >Good intention but wrong way of expressing it. Please do it properly -- > via a signed paper. You can send it by snail mail, or you can scan it > and send by email. What's wrong with it? Is the text not clear? Or there is a problem to threat email as a document? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Submitting PEP 422 (Simple class initialization hook) for pronouncement
Hi Nick, I think this will make a fine addition to the language. I agree that it is superior to the alternatives and fulfills a real (if rare) need. I only have a few nits/questions/suggestions. - With PJE, I think __init_class__ should automatically be a class method. The same way that __new__ is automatically a class method. - Would it make any sense to require that __init_class__ *returns* the new class object (to complete the similarity with class decorators)? Frankly, I lost track of things when you were discussing the exact point in time where __class__ is added to the class. (This may place me outside the set of people who fully understand Python's metaclasses. So be it. :-) Perhaps some explanation of the existing mechanism would be in place? It would be nice if you explained reason for why __class__ cannot be set earlier in the game (otherwise the response to this argument would be "so fix it", but somehow I doubt that is possible). I think it may also be unclear at all times whether __class__, when referenced, is meant to refer to the metaclass or to the class under construction. - I wouldn't add the OrderedMeta/OrderedClass to the PEP. Keep it focused on enabling. - Adding more examples would be great. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Question regarding: Lib/_markupbase.py
Thank you David, I didn't think of the issue tracker.
I have just done it.
Guido
- Ursprüngliche Message -
Von: R. David Murray
An: Developer Developer
CC: "python-dev@python.org"
Gesendet: 16:59 Montag, 11.Februar 2013
Betreff: Re: [Python-Dev] Question regarding: Lib/_markupbase.py
If these don't get reported as tracker issues they will probably get
lost.
--David
On Mon, 11 Feb 2013 14:47:00 +, Developer Developer
wrote:
> Same thing in the function: "_parse_doctype_attlist":
>
> if ")" in rawdata[j:]:
> j = rawdata.find(")", j) + 1
> else:
> return -1
>
> I would change it to:
> pos = rawdata.find(")", j)
> if pos != -1:
> j = pos + 1
> else:
> return -1
>
>
> Best regards,
> Guido
>
>
> - Ursprüngliche Message -
> Von: Fred Drake
> An: Developer Developer
> CC: "python-dev@python.org"
> Gesendet: 15:10 Montag, 11.Februar 2013
> Betreff: Re: [Python-Dev] Question regarding: Lib/_markupbase.py
>
> On Mon, Feb 11, 2013 at 7:16 AM, Developer Developer
> wrote:
> > Wouldn't it be better to do the following?
> ...
> > Otherwise I think we are scanning rawdata[j:] twice.
>
> Yes, that would be better, and avoids a string object creation as well.
>
>
> -Fred
>
> --
> Fred L. Drake, Jr.
> "A storm broke loose in my mind." --Albert Einstein
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/rdmurray%40bitdance.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Question regarding: Lib/_markupbase.py
If these don't get reported as tracker issues they will probably get
lost.
--David
On Mon, 11 Feb 2013 14:47:00 +, Developer Developer
wrote:
> Same thing in the function: "_parse_doctype_attlist":
>
> if ")" in rawdata[j:]:
> Â Â j = rawdata.find(")", j) + 1
> else:
> Â Â return -1
>
> I would change it to:
> pos =Â rawdata.find(")", j)
> if pos != -1:
> Â Â j = pos + 1
> else:
> Â Â return -1
>
>
> Best regards,
> Guido
>
>
> - Ursprüngliche Message -
> Von: Fred Drake
> An: Developer Developer
> CC: "python-dev@python.org"
> Gesendet: 15:10 Montag, 11.Februar 2013
> Betreff: Re: [Python-Dev] Question regarding: Lib/_markupbase.py
>
> On Mon, Feb 11, 2013 at 7:16 AM, Developer Developer
> wrote:
> > Wouldn't it be better to do the following?
> ...
> > Otherwise I think we are scanning rawdata[j:] twice.
>
> Yes, that would be better, and avoids a string object creation as well.
>
>
> Â -Fred
>
> --
> Fred L. Drake, Jr. Â
> "A storm broke loose in my mind."Â --Albert Einstein
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/rdmurray%40bitdance.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] checking what atexit handlers are registered in Python 3
On Feb 10, 2013, at 10:36 AM, Chris Withers wrote: >One rough edge I've hit: I see the atexit module has moved to be C-based and, >as far as I can tell, no longer allows you to introspect what atexit >functions have been registered. > >If I'm writing tests for code that registers atexit handlers, how can I check >that they've been correctly registered? Looks like you can't through the atexit module. Even though Python 2's atexit._exithandlers is a private, undocumented attribute, the lack of an introspection API in Python 3's atexit seems like a functional regression. Please file a bug, although it will have to be a new feature for Python 3.4. Cheers, -Barry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Submitting PEP 422 (Simple class initialization hook) for pronouncement
Le Mon, 11 Feb 2013 10:15:36 -0500, Barry Warsaw a écrit : > On Feb 10, 2013, at 03:28 PM, Antoine Pitrou wrote: > > >Sure, every little addition is "trivial". At the end you have a scary > >monster made of many little trivial additions along the years, and > >everyone has to take care not to break it. > > Why Antoine, that surely isn't the case with the import system! > . Nor with pythonrun.c. I wouldn't even mention typeobject.c or the build system ;-) Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Submitting PEP 422 (Simple class initialization hook) for pronouncement
On Feb 11, 2013, at 08:33 PM, Nick Coghlan wrote: >I like that. Perhaps the PEP should propose some additional guidance >in PEP 8 regarding class based metaprogramming? I wouldn't put it in PEP 8, since it'll glaze the eyes of all but 6 people on the planet. Probably better as a HOWTO in the documentation. Cheers, -Barry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Submitting PEP 422 (Simple class initialization hook) for pronouncement
On Feb 10, 2013, at 02:34 PM, Antoine Pitrou wrote: >zope.interface has been ported to Python 3, so the annoyance can't be >very blocking. The syntax is different, but I actually prefer the Python 3-compatible syntax better. It uses a class decorator instead of a magic class attribute, so it's much clearer IMHO. Works in Python 2, too, fsvo. -Barry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Submitting PEP 422 (Simple class initialization hook) for pronouncement
On Feb 10, 2013, at 03:28 PM, Antoine Pitrou wrote: >Sure, every little addition is "trivial". At the end you have a scary >monster made of many little trivial additions along the years, and >everyone has to take care not to break it. Why Antoine, that surely isn't the case with the import system! . -Barry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (3.3): Reject float as uid or gid.
On 11.02.13 01:06, Eric V. Smith wrote: > Instead of special-casing float, isn't using __index__ the preferred way > to do this? Perhaps. I just copied this code from PyArg_ParseTuple*() for 'l' format. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Question regarding: Lib/_markupbase.py
Same thing in the function: "_parse_doctype_attlist":
if ")" in rawdata[j:]:
j = rawdata.find(")", j) + 1
else:
return -1
I would change it to:
pos = rawdata.find(")", j)
if pos != -1:
j = pos + 1
else:
return -1
Best regards,
Guido
- Ursprüngliche Message -
Von: Fred Drake
An: Developer Developer
CC: "python-dev@python.org"
Gesendet: 15:10 Montag, 11.Februar 2013
Betreff: Re: [Python-Dev] Question regarding: Lib/_markupbase.py
On Mon, Feb 11, 2013 at 7:16 AM, Developer Developer
wrote:
> Wouldn't it be better to do the following?
...
> Otherwise I think we are scanning rawdata[j:] twice.
Yes, that would be better, and avoids a string object creation as well.
-Fred
--
Fred L. Drake, Jr.
"A storm broke loose in my mind." --Albert Einstein
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] _not_found attribute on ImportError
On Mon, Feb 11, 2013 at 9:23 AM, Barry Warsaw wrote: > On Feb 11, 2013, at 09:23 PM, Nick Coghlan wrote: > > >On Mon, Feb 11, 2013 at 8:58 PM, Chris Withers > wrote: > >> Have any other exceptions grown new attributes in Python 3? > > > >Off the top of my head, ImportError grew "name" and "path" attributes > >in 3.3, everything grew __cause__, __context__ and __traceback__ > >attributes in 3.0 and the __suppress_context__ attribute in 3.3. > > > >PEP 3151 may have moved a few attributes around in 3.3 as well. > > > >If there are any others, you'll need to trawl the What's New documents > >looking for them. > > Those public attributes should be documented. They are: http://docs.python.org/3.4/library/exceptions.html?highlight=importerror#ImportError > _not_found should not be since > it's an implementation detail. Yep, hence the leading underscore. > Also, Brett has left little TODO easter eggs > in the code which clearly indicate changes he plans for 3.4, although I > don't > know where the plans for ModuleNotFound are documented. > http://bugs.python.org/issue15767 Basically it's a matter of choosing ModuleNotFound vs. ModuleNotFoundError and then writing the code. -Brett > > In the meantime, I just ran a test against trunk, with the following change > and nothing broke afaict. > > diff -r a79650aacb43 Lib/importlib/_bootstrap.py > --- a/Lib/importlib/_bootstrap.py Mon Feb 11 13:33:00 2013 + > +++ b/Lib/importlib/_bootstrap.py Mon Feb 11 09:16:51 2013 -0500 > @@ -1640,6 +1640,7 @@ > # TODO(brett): In Python 3.4, have import raise > # ModuleNotFound and catch that. > if getattr(exc, '_not_found', False): > +del exc._not_found > if exc.name == from_name: > continue > raise > > I won't commit this, but it really needs another hasattr() check to be > completely valid. > > Cheers, > -Barry > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/brett%40python.org > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] _not_found attribute on ImportError
On Feb 11, 2013, at 09:23 PM, Nick Coghlan wrote: >On Mon, Feb 11, 2013 at 8:58 PM, Chris Withers wrote: >> Have any other exceptions grown new attributes in Python 3? > >Off the top of my head, ImportError grew "name" and "path" attributes >in 3.3, everything grew __cause__, __context__ and __traceback__ >attributes in 3.0 and the __suppress_context__ attribute in 3.3. > >PEP 3151 may have moved a few attributes around in 3.3 as well. > >If there are any others, you'll need to trawl the What's New documents >looking for them. Those public attributes should be documented. _not_found should not be since it's an implementation detail. Also, Brett has left little TODO easter eggs in the code which clearly indicate changes he plans for 3.4, although I don't know where the plans for ModuleNotFound are documented. In the meantime, I just ran a test against trunk, with the following change and nothing broke afaict. diff -r a79650aacb43 Lib/importlib/_bootstrap.py --- a/Lib/importlib/_bootstrap.py Mon Feb 11 13:33:00 2013 + +++ b/Lib/importlib/_bootstrap.py Mon Feb 11 09:16:51 2013 -0500 @@ -1640,6 +1640,7 @@ # TODO(brett): In Python 3.4, have import raise # ModuleNotFound and catch that. if getattr(exc, '_not_found', False): +del exc._not_found if exc.name == from_name: continue raise I won't commit this, but it really needs another hasattr() check to be completely valid. Cheers, -Barry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Question regarding: Lib/_markupbase.py
On Mon, Feb 11, 2013 at 7:16 AM, Developer Developer wrote: > Wouldn't it be better to do the following? ... > Otherwise I think we are scanning rawdata[j:] twice. Yes, that would be better, and avoids a string object creation as well. -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] Daily reference leaks (b53b029895df): sum=2
On Sun, Feb 10, 2013 at 9:00 PM, wrote: > results for b53b029895df on branch "default" > > > test_concurrent_futures leaked [2, 1, -1] memory blocks, sum=2 > > When did this start happening? Eli ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] My CLA
On Mon, Feb 11, 2013 at 03:49:39PM +0300, anatoly techtonik wrote: > Python Contributor Agreement > > I allow PSF to release all my code that I submitted to > it, under any open source license. Good intention but wrong way of expressing it. Please do it properly -- via a signed paper. You can send it by snail mail, or you can scan it and send by email. Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] My CLA
Python Contributor Agreement I allow PSF to release all my code that I submitted to it, under any open source license. -- anatoly t. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Question regarding: Lib/_markupbase.py
Hello all,
I was having a look at the file: Lib/_markupbase.py (@ 82151), function:
"_parse_doctype_element" and have seen something that has caught my attention:
if '>' in rawdata[j:]:
return rawdata.find(">", j) + 1
Wouldn't it be better to do the following?
pos = rawdata.find(">", j)
if pos != -1:
return pos + 1
Otherwise I think we are scanning rawdata[j:] twice.
Best regards
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] _not_found attribute on ImportError
On Mon, Feb 11, 2013 at 8:58 PM, Chris Withers wrote: > Have any other exceptions grown new attributes in Python 3? Off the top of my head, ImportError grew "name" and "path" attributes in 3.3, everything grew __cause__, __context__ and __traceback__ attributes in 3.0 and the __suppress_context__ attribute in 3.3. PEP 3151 may have moved a few attributes around in 3.3 as well. If there are any others, you'll need to trawl the What's New documents looking for them. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] _not_found attribute on ImportError
On 11/02/2013 10:54, Nick Coghlan wrote: On Mon, Feb 11, 2013 at 6:08 PM, Chris Withers wrote: Hi All, I see in Python 3, some ImportErrors have grown a '_not_found' attribute. What's the significance of this attribute and where/how is it added? The only way I can seem to create this attribute is: ex = ImportError ex._not_found = True It's something importlib does to get fromlists to behave the same way they did in the C implementation. It is set here: http://hg.python.org/cpython/file/3.3/Lib/importlib/_bootstrap.py OK. Have any other exceptions grown new attributes in Python 3? cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] _not_found attribute on ImportError
On Mon, Feb 11, 2013 at 6:08 PM, Chris Withers wrote: > Hi All, > > I see in Python 3, some ImportErrors have grown a '_not_found' attribute. > What's the significance of this attribute and where/how is it added? > > The only way I can seem to create this attribute is: > > ex = ImportError > ex._not_found = True It's something importlib does to get fromlists to behave the same way they did in the C implementation. It is set here: http://hg.python.org/cpython/file/3.3/Lib/importlib/_bootstrap.py To make these pass: http://hg.python.org/cpython/file/3.3/Lib/test/test_importlib/import_/test_fromlist.py You'd have to ask Brett which specific test is affected, or else you could comment out the line that sets _not_found and see what breaks (you may need to refreeze _frozen_importlib first). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Submitting PEP 422 (Simple class initialization hook) for pronouncement
On Mon, Feb 11, 2013 at 7:41 AM, PJ Eby wrote:
> On Sun, Feb 10, 2013 at 11:48 AM, Stefan Behnel wrote:
>> So, the way to explain it to users would be 1) don't use it, 2) if you
>> really need to do something to a class, use a decorator, 3) if you need to
>> decide dynamically what to do, define __init_class__() and 4) don't forget
>> to call super's __init_class__() in that case, and 5) only if you need to
>> do something substantially more involved and know what you're doing, use a
>> metaclass.
>
> I'd revise that to:
>
> 1) if there's no harm in forgetting to decorate a subclass, use a
> class decorator
> 2) if you want to ensure that a modification is applied to every
> subclass of a single common base class, define __init_class__ (and
> always call its super)
> 3) If you need to make the class object *act* differently (not just
> initialize it or trigger some other side-effect at creation time), or
> if you want the class suite to return some other kind of object,
> you'll need a metaclass.
I like that. Perhaps the PEP should propose some additional guidance
in PEP 8 regarding class based metaprogramming?
> Essentially, this change fixes a hole in class decorators that doesn't
> exist with function decorators: if you need the decoration applied to
> subclasses, you can end up with silent failures right now.
> Conversely, if you try prevent such failures using a metaclass, you
> not only have a big hill to climb, but the resulting code will be
> vulnerable to metaclass conflicts.
>
> The proposed solution neatly fixes both of these problems, providing
> One Obvious Way to do subclass initialization.
I also realised last night that one significant benefit of cleanly
separating class creation from class initialisation (as __new__ and
__init__ separate instance creation and initialisation) is the ability
to create a shared metaclass that just changes the namespace type with
__prepare__, and then use __init_class__ to control what you do with
it.
Here's the more extended example I'm now considering adding to the PEP in
order to show the improved composability the PEP offers (writing the below
example with only metaclasses would be... challenging). It's still a
toy example, but I don't believe there is any non-toy use case for
metaclass composition that is going to be short enough to fit in a PEP:
# Define a metaclass as in Python 3.3 and earlier
import collections
class OrderedMeta(type):
def __prepare__(self, *args, **kwds):
return collections.OrderedDict()
# Won't be needed if we add a noop __init_class__ to type
def __init_class__(cls):
pass
class OrderedClass(metaclass=OrderedMeta):
pass
# Easily supplement the metaclass behaviour in a class definition
class SimpleRecord(OrderedClass):
"""Simple ordered record type (inheritance not supported)"""
@classmethod
def __init_class__(cls):
super().__init_class__()
cls.__fields = fields = []
for attr, obj in cls.__dict__.items():
if attr.startswith("_") or callable(obj):
continue
fields.append(attr)
def __init__(self, *values):
super().__init__(*values)
for attr, obj in zip(self.__fields, values):
setattr(self, attr, obj)
def to_dict(self):
fields = ((k, getattr(self, k)) for k in self.__fields)
return collections.OrderedDict(fields)
# Supplement the metaclass differently in another class definition
class InheritableRecord(OrderedClass):
"""More complex record type that supports inheritance"""
@classmethod
def __init_class__(cls):
super().__init_class__()
cls.__fields = fields = []
for mro_cls in cls.mro():
for attr, obj in cls.__dict__.items():
if attr.startswith("_") or callable(obj):
continue
fields.append(attr)
def __init__(self, *values):
super().__init__(*values)
for attr, obj in zip(self.__fields, values):
setattr(self, attr, obj)
def to_dict(self):
fields = ((k, getattr(self, k)) for k in self.__fields)
return collections.OrderedDict(fields)
# Compared to custom metaclasses, composition is much simpler
class ConfusedRecord(InheritableRecord, SimpleRecord):
"""Odd record type, only included to demonstrate composition"""
# to_dict is inherited from InheritableRecord
def to_simple_dict(self):
return SimpleRecord.to_dict(self)
Perhaps it would sweeten the deal if the PEP also provided
types.OrderedMeta and types.OrderedClass, such that inheriting from
types.OrderedClass and defining __init_class__ became the
one-obvious-way to do order dependent class bodies? (I checked, we can
make types depend on collec
[Python-Dev] _not_found attribute on ImportError
Hi All, I see in Python 3, some ImportErrors have grown a '_not_found' attribute. What's the significance of this attribute and where/how is it added? The only way I can seem to create this attribute is: ex = ImportError ex._not_found = True cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Submitting PEP 422 (Simple class initialization hook) for pronouncement
On Sun, 10 Feb 2013 16:27:49 -0500
PJ Eby wrote:
> On Sun, Feb 10, 2013 at 7:32 AM, Nick Coghlan wrote:
> >class Example:
> >@classmethod
> >def __init_class__(cls):
>
> Is the @classmethod required? What happens if it's not present?
>
> Second, will type have a default __init_class__? (IMO, it should,
> otherwise it will be impossible to write co-operative __init_class__
> functions.)
>
> Only other comment is that the PEP could use a more concrete use case, e.g.:
>
> class Record:
> __fields = {}
>
> @classmethod
> def __init_class__(cls):
> cls.__fields = dict(cls.__fields) # inherited fields
> cls.__fields.update({attr:val for attr, val in
> cls.__dict__.iteritems() if isinstance(val, Field)})
> super().__init_class__() # be co-operative
>
> # ...other methods that use the __fields attribute
>
> class SomeRecord(Record):
> foo = Field(int)
> bar = Field(str)
>
> Putting something like this early on might help to demonstrate the
> usefulness of the feature on its own merits, independent of the
> porting issue, etc. ;-)
Can you explain what the example does / is supposed to do?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
