Re: [Python-ideas] Fwd: Define a method or function attributeoutsideof a class with the dot operator

2017-02-14 Thread Random832
On Sun, Feb 12, 2017, at 21:55, Steven D'Aprano wrote: > But honestly, no. This is not going to happen. .Net VB and C# have > something like this, as does Lua, and people still write classes the > ordinary way 99.99% of the time. The VB/C# thing you are referring to is, I assume, extension

Re: [Python-ideas] Fwd: Define a method or function attributeoutsideof a class with the dot operator

2017-02-13 Thread Steven D'Aprano
On Sun, Feb 12, 2017 at 10:29:10PM +0100, Nick Coghlan wrote: [...] > Method injection is most attractive to me as a potential alternative > to mixin classes that has fewer runtime side effects by moving more of > the work to class definition time. > > More philosophically though, it offends my

Re: [Python-ideas] Fwd: Define a method or function attributeoutsideof a class with the dot operator

2017-02-13 Thread M.-A. Lemburg
On 13.02.2017 20:32, Joseph Hackman wrote: > I just wanted to ask: can someone point me to the reason Python doesn't > support referencing a class inside it's own definition? It seems like that > would solve some of the cases discussed here, and with Type hinting that > seems like something

Re: [Python-ideas] Fwd: Define a method or function attributeoutsideof a class with the dot operator

2017-02-13 Thread Matt Gilson
For whatever weight my opinion holds, I'm +0 on this one. In my estimation, in an ideal world it seems like: class Foo(object): def bar(self): """Bar!""" # Identical to: class Foo(object): pass def Foo.bar(self): """Bar!""" But I think that's

Re: [Python-ideas] Fwd: Define a method or function attributeoutsideof a class with the dot operator

2017-02-13 Thread Kyle Lahnakoski
On 2017-02-12 14:01, Joao S. O. Bueno wrote: > On 12 February 2017 at 14:51, Markus Meskanen > wrote: >> 1. Allowing the class to be used in the method's header, f.e. for typing and >> decorators: >> >> @decorate(MyClass) >> def MyClass.method(self, other:

Re: [Python-ideas] Fwd: Define a method or function attributeoutsideof a class with the dot operator

2017-02-12 Thread Joao S. O. Bueno
On 13 February 2017 at 00:55, Steven D'Aprano wrote: > On Sun, Feb 12, 2017 at 05:01:58PM -0200, Joao S. O. Bueno wrote: > >> You realize now that if we accept this change, and given your example, >> any "well behaved" Python code with markup will in a couple months >>

Re: [Python-ideas] Fwd: Define a method or function attributeoutsideof a class with the dot operator

2017-02-12 Thread Steven D'Aprano
On Sun, Feb 12, 2017 at 05:01:58PM -0200, Joao S. O. Bueno wrote: > You realize now that if we accept this change, and given your example, > any "well behaved" Python code with markup will in a couple months > required to be like > > class MyClass: > """Docstring.""" > > def

Re: [Python-ideas] Fwd: Define a method or function attributeoutsideof a class with the dot operator

2017-02-12 Thread Nick Coghlan
On 12 February 2017 at 12:38, Paul Moore wrote: > On 12 February 2017 at 04:37, Steven D'Aprano wrote: >>> Making a dedicated syntax or decorator for patching is saying that we >>> (the language) think you should do it. >> >> We already have that syntax:

Re: [Python-ideas] Fwd: Define a method or function attributeoutsideof a class with the dot operator

2017-02-12 Thread David Mertz
Oh, I probably want `return fn` inside my inner decorator. Otherwise, the defined name gets bound to None in the global scope. I'm not sure, maybe that's better... but most likely we should leave the name for other users. I just wrote it without testing. On Sun, Feb 12, 2017 at 10:19 AM, David

Re: [Python-ideas] Fwd: Define a method or function attributeoutsideof a class with the dot operator

2017-02-12 Thread Mark E. Haase
On Sun, Feb 12, 2017 at 11:51 AM, Markus Meskanen wrote: > > 2. To register callbacks to objects, i.e. plain out set an attribute for > an instance. I've used the menu example above: > > class Menu: > def __init__(self, items=None, select_callback=None): >

Re: [Python-ideas] Fwd: Define a method or function attributeoutsideof a class with the dot operator

2017-02-12 Thread David Mertz
I think the proposal, so far, seems to confuse two separate things. One is attaching a method to a class after definition. The second is attaching a method to an instance after creation. Or at least it is unclear to me which of those is the intention, since both seem to occur in the examples.

Re: [Python-ideas] Fwd: Define a method or function attributeoutsideof a class with the dot operator

2017-02-12 Thread Markus Meskanen
I will say, though, that you're right that we've over-reacted a bit to the monkeypatching use case. Although maybe that's because no-one can think of many *other* use cases that they'd need the new syntax for :-) Paul Hi Paul, I believe at least two other use cases than monkey patching have

Re: [Python-ideas] Fwd: Define a method or function attributeoutsideof a class with the dot operator

2017-02-12 Thread Paul Moore
On 12 February 2017 at 04:37, Steven D'Aprano wrote: >> Making a dedicated syntax or decorator for patching is saying that we >> (the language) think you should do it. > > We already have that syntax: > > anything.name = thing And the point here is that we don't need to

Re: [Python-ideas] Fwd: Define a method or function attributeoutsideof a class with the dot operator

2017-02-11 Thread Steven D'Aprano
On Fri, Feb 10, 2017 at 12:11:46PM -0600, Steve Dower wrote: > When you apply the "what if everyone did this" rule, it looks like a > bad idea (or alternatively, what if two people who weren't expecting > anyone else to do this did it). When you apply that rule, Python generally fails badly.

Re: [Python-ideas] Fwd: Define a method or function attributeoutsideof a class with the dot operator

2017-02-10 Thread Steve Dower
When you apply the "what if everyone did this" rule, it looks like a bad idea (or alternatively, what if two people who weren't expecting anyone else to do this did it). Monkeypatching is fairly blatantly taking advantage of the object model in a way that is not "supported" and cannot behave