On Fri, Apr 3, 2015 at 6:44 AM, Martin Teichmann
wrote:
> Nick, I couldn't agree more with you, yet I think PJ actually brought
> up a very interesting point. Post-processing is a very common thing
> these days, and has been re-written so many times that I think it is
> about time that something l
On Sat, Apr 4, 2015 at 6:40 PM, Greg Ewing wrote:
> Eric Snow wrote:
>>
>> I've felt for a long time that it would be helpful in some situations
>> to have a reverse descriptor protocol.
>
> Can you elaborate on what you mean by that?
Sure. It's more python-ideas territory (I posted about it a f
On Sat, Apr 4, 2015 at 9:33 PM, Nick Coghlan wrote:
> So actually reading https://gist.github.com/pjeby/75ca26f8d2a7a0c68e30
> properly, you're starting to convince me that a "noconflict" metaclass
> resolver would be a valuable and viable addition to the Python 3 type
> system machinery.
>
> The
On 5 April 2015 at 10:40, Greg Ewing wrote:
> Eric Snow wrote:
>>
>> I've felt for a long time that it would be helpful in some situations
>> to have a reverse descriptor protocol.
>
>
> Can you elaborate on what you mean by that?
My guess from the name and the context: having a way to notify
des
On 4 April 2015 at 06:36, PJ Eby wrote:
> On Fri, Apr 3, 2015 at 4:21 AM, Nick Coghlan wrote:
>> No, you can't do it currently without risking a backwards
>> incompatibility through the introduction of a custom metaclass.
>
> Right... which is precisely why I'm suggesting the `noconflict()`
> m
Eric Snow wrote:
I've felt for a long time that it would be helpful in some situations
to have a reverse descriptor protocol.
Can you elaborate on what you mean by that?
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.or
On Fri, Apr 3, 2015 at 6:44 AM, Martin Teichmann
wrote:
>> When I first wrote PEP 422 I was of the view that "Python 2 allows
>> class definition postprocessing injection, we should allow it in
>> Python 3 as well". I've since changed my view to "Having to declare
>> post-processing of a class def
On Fri, Apr 3, 2015 at 4:21 AM, Nick Coghlan wrote:
> That means I'm now OK with monkeypatching __build_class__ being the
> only way to get dynamic hooking of the class currently being defined
> from the class body - folks that really want that behaviour can
> monkeypatch it in, while folks that t
On Fri, Apr 3, 2015 at 11:04 AM, Nick Coghlan wrote:
> Extending the descriptor protocol to include a per-descriptor hook that's
> called at class definition time sounds like a potentially nice way to go to
> me. While you *could* still use it to arbitrarily mutate the class object,
> it's much cl
On Fri, Apr 3, 2015 at 8:44 AM, Martin Teichmann
wrote:
> This proposal can actually be seen as an extension to the __class__
> and super() mechanism of normal methods: methods currently have the
> priviledge to know which classes they are defined in, while descriptors
> don't. So we could unify a
On 4 Apr 2015 00:29, "Martin Teichmann" wrote:
>
> > When I first wrote PEP 422 I was of the view that "Python 2 allows
> > class definition postprocessing injection, we should allow it in
> > Python 3 as well". I've since changed my view to "Having to declare
> > post-processing of a class defini
> When I first wrote PEP 422 I was of the view that "Python 2 allows
> class definition postprocessing injection, we should allow it in
> Python 3 as well". I've since changed my view to "Having to declare
> post-processing of a class definition up front as a decorator, base
> class or metaclass is
On 3 April 2015 at 18:21, Nick Coghlan wrote:
> That means I'm now OK with monkeypatching __build_class__ being the
> only way to get dynamic hooking of the class currently being defined
> from the class body - folks that really want that behaviour can
> monkeypatch it in, while folks that think i
On 3 April 2015 at 11:32, PJ Eby wrote:
> On Thu, Apr 2, 2015 at 6:24 PM, Martin Teichmann
> wrote:
>> The whole point of PEP 487 was to reduce PEP 422 so much that
>> it can be written in python and back-ported.
>
> As I said earlier, it's a fine feature and should be in the stdlib for
> Python
On Thu, Apr 2, 2015 at 9:31 PM, Nick Coghlan wrote:
> On 3 April 2015 at 08:24, Martin Teichmann wrote:
> However, I'm also now wondering if it may be possible to reach out to
> the pylint authors (similar to what Brett did for the "pylint --py3k"
> flag) and ask for a way to make it easy to regi
On 04/03, Greg Ewing wrote:
> On 04/03/2015 02:31 PM, Nick Coghlan wrote:
>> If I'm understanding PJE's main concern correctly it's that this
>> approach requires explicitly testing that the decorator has been
>> applied correctly in your automated tests every time you use it, as
>> otherwise ther
On Thu, Apr 2, 2015 at 10:29 PM, Greg Ewing wrote:
> On 04/03/2015 02:31 PM, Nick Coghlan wrote:
>>
>> If I'm understanding PJE's main concern correctly it's that this
>> approach requires explicitly testing that the decorator has been
>> applied correctly in your automated tests every time you us
On 04/03/2015 02:31 PM, Nick Coghlan wrote:
If I'm understanding PJE's main concern correctly it's that this
approach requires explicitly testing that the decorator has been
applied correctly in your automated tests every time you use it, as
otherwise there's a risk of a silent failure when you u
On Thu, Apr 2, 2015 at 6:24 PM, Martin Teichmann
wrote:
> The whole point of PEP 487 was to reduce PEP 422 so much that
> it can be written in python and back-ported.
As I said earlier, it's a fine feature and should be in the stdlib for
Python 3. (But it should have a `noconflict` feature added
On 3 April 2015 at 08:24, Martin Teichmann wrote:
> Hi everyone,
>
>> > If the PEP 487 metaclass library,
>> > however, were to just port some bits of my code to Python 3 this could
>> > be a done deal already and available in *all* versions of Python 3,
>> > not just the next one.
>>
>> Just for
Hi everyone,
> > If the PEP 487 metaclass library,
> > however, were to just port some bits of my code to Python 3 this could
> > be a done deal already and available in *all* versions of Python 3,
> > not just the next one.
>
> Just for the heck of it, here's an actual implementation and demo of
Hi everyone,
for those new to the discussion, I am the author of PEP 487,
which has been discussed here:
https://mail.python.org/pipermail/python-ideas/2015-February/032249.html
> The concern is twofold: it breaks proper information hiding/DRY, *and*
> it fails silently. It should not be necessa
On Thu, Apr 2, 2015 at 1:42 PM, PJ Eby wrote:
> If the PEP 487 metaclass library,
> however, were to just port some bits of my code to Python 3 this could
> be a done deal already and available in *all* versions of Python 3,
> not just the next one.
Just for the heck of it, here's an actual imple
On Thu, Apr 2, 2015 at 4:46 AM, Nick Coghlan wrote:
> On 2 April 2015 at 16:38, PJ Eby wrote:
>>
>> IOW, there's no need to modify the core just to have *that* feature,
>> since if you control the base class you can already do what PEP 487
>> does in essentially every version of Python, ever. If
On Thu, Apr 02, 2015 at 06:46:11PM +1000, Nick Coghlan wrote:
> On 2 April 2015 at 16:38, PJ Eby wrote:
> > IOW, there's no need to modify the core just to have *that* feature,
> > since if you control the base class you can already do what PEP 487
> > does in essentially every version of Python,
On 2 April 2015 at 16:38, PJ Eby wrote:
>
> IOW, there's no need to modify the core just to have *that* feature,
> since if you control the base class you can already do what PEP 487
> does in essentially every version of Python, ever. If that's all PEP
> 487 is going to do, it should just be a P
On Wed, Apr 1, 2015 at 10:39 PM, Nick Coghlan wrote:
> On 2 April 2015 at 07:35, PJ Eby wrote:
>> I recently got an inquiry from some of my users about porting some of
>> my libraries to Python 3 that make use of the Python 2 __metaclass__
>> facility. While checking up on the status of PEP 422
On 2 April 2015 at 07:35, PJ Eby wrote:
> I recently got an inquiry from some of my users about porting some of
> my libraries to Python 3 that make use of the Python 2 __metaclass__
> facility. While checking up on the status of PEP 422 today, I found
> out about its recently proposed replacemen
I recently got an inquiry from some of my users about porting some of
my libraries to Python 3 that make use of the Python 2 __metaclass__
facility. While checking up on the status of PEP 422 today, I found
out about its recently proposed replacement, PEP 487.
While PEP 487 is a generally fine PE
29 matches
Mail list logo
