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

2017-02-23 Thread Chris Barker
Has this REALLY not been discussed and rejected long ago? > But I'm +1 on writing a PEP -- collect all these pros and cons in one > place to save on future discussion. (And (good) PEP writing is a way to > earn valuable Python Points!) > Exactly -- this is obvious enough that it WILL come

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

2017-02-11 Thread Chris Angelico
On Sun, Feb 12, 2017 at 3:38 PM, Steven D'Aprano wrote: > On Sat, Feb 11, 2017 at 06:33:39PM +1300, Greg Ewing wrote: >> Chris Angelico wrote: >> >Which is why these proposals always seem to gravitate to "anything you >> >can assign to", >> >> There might be some parsing

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

2017-02-11 Thread Steven D'Aprano
On Sat, Feb 11, 2017 at 06:33:39PM +1300, Greg Ewing wrote: > Chris Angelico wrote: > >Which is why these proposals always seem to gravitate to "anything you > >can assign to", > > There might be some parsing difficulties with that, e.g. > >def foo(x)[5](y, z): > ... > > That should

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

2017-02-11 Thread Random832
On Sat, Feb 11, 2017, at 00:33, Greg Ewing wrote: > Chris Angelico wrote: > > Which is why these proposals always seem to gravitate to "anything you > > can assign to", > > There might be some parsing difficulties with that, e.g. > > def foo(x)[5](y, z): >... > > That should be

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

2017-02-11 Thread Greg Ewing
Chris Angelico wrote: Which is why these proposals always seem to gravitate to "anything you can assign to", There might be some parsing difficulties with that, e.g. def foo(x)[5](y, z): ... That should be acceptable, because foo(x)[5] is something assignable, but foo(x) looks like

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

2017-02-10 Thread Steve Dower
On 10Feb2017 1400, Stephan Hoyer wrote: An important note is that ideally, we would still have way of indicating that Spam.func should exists in on the Spam class itself, even if it doesn't define the implementation. I suppose an abstractmethod overwritten by the later definition might do the

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

2017-02-10 Thread Stephan Hoyer
On Fri, Feb 10, 2017 at 9:20 AM, Nick Coghlan wrote: > What I would personally hope to see from the proposal is that given: > > class Spam: > pass > > def Spam.func(self): > return __class__ > > the effective runtime behaviour would be semantically

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

2017-02-10 Thread Stephan Houben
Hi all, For what it's worth, I believe that the "class extension" scenario from Nick can be supported using plain ol' metaclasses. Not sure if this covers all desired capabilities, but at least the super() mechanism works correctly. Syntax is like this: class Foo(metaclass=class_extend(Foo)):

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

2017-02-10 Thread Ethan Furman
On 02/10/2017 10:48 AM, Nick Timkovich wrote: If everything was contained right in the same file, this is sanctioning another way to do it (when there should only be one obvious way). No worries, this way is not obvious. If you have multiple modules/packages, horrors can evolve where a

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

2017-02-10 Thread Markus Meskanen
Please keep in mind that this idea was not created to improve monkey patching, it just happens to be one of the side effects due to classes being objects. The main use case is the ability to set an instance's callback function (see the Menu example), and to allow the class being referenced in the

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

2017-02-10 Thread Joshua Morton
One thing that I don't think has been mentioned, but that brings me from a +0 to a more negative outlook, is the interaction between this proposal and some of python's existing class-related features, metaclasses and descriptors. That is currently we know that function definition, and even method

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

2017-02-10 Thread Nick Coghlan
On 10 February 2017 at 16:25, Steven D'Aprano wrote: > On Sat, Feb 11, 2017 at 01:25:40AM +1100, Chris Angelico wrote: > >> For what it's worth, my answers would be: >> >> __name__ would be the textual representation of exactly what you typed >> between "def" and the open

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

2017-02-10 Thread Steven D'Aprano
On Sat, Feb 11, 2017 at 01:25:40AM +1100, Chris Angelico wrote: > For what it's worth, my answers would be: > > __name__ would be the textual representation of exactly what you typed > between "def" and the open parenthesis. __qualname__ would be built > the exact same way it currently is, based

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

2017-02-10 Thread Guyzmo via Python-ideas
Hi list, I'm quite neutral to this proposition, as it's not a use case I see often myself needing. On Fri, Feb 10, 2017 at 02:55:31PM +0100, Stephan Houben wrote: […] > But if I don't understand the dot in `class foo.bar:', then what? > It's probably somewhere buried in the language spec for

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

2017-02-10 Thread Chris Angelico
On Sat, Feb 11, 2017 at 1:16 AM, Nick Coghlan wrote: > But what do __name__ and __qualname__ get set to? > > What happens if you do this at class scope, rather than at module > level or inside another function? > > What happens to the zero-argument super() support at class

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

2017-02-10 Thread Nick Coghlan
On 10 February 2017 at 12:16, Chris Angelico wrote: > On Fri, Feb 10, 2017 at 10:13 PM, Paul Moore wrote: >> Furthermore, once we open up this possibility, I would expect requests >> for things like >> >> func_table = {} >> func_table["foo"] =

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

2017-02-10 Thread Paul Moore
On 10 February 2017 at 14:00, Markus Meskanen wrote: >> > I've started working on a PEP for this since most people seem to be for >> > it. >> >> I don't know how you get "most people" -- there's only been a handful of >> responses in the few hours since the original

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

2017-02-10 Thread Paul Moore
On 10 February 2017 at 13:55, Stephan Houben wrote: > My point would be that the new syntax *also* requires one to figure out what > the new syntax does. This is an extremely good point. It is mentioned when new syntax is proposed (the term often used is "discoverability")

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

2017-02-10 Thread Markus Meskanen
> > > I've started working on a PEP for this since most people seem to be for > it. > > I don't know how you get "most people" -- there's only been a handful of > responses in the few hours since the original post. And apart from one > explicit -1, I read most of them as neutral, not in favour. >

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

2017-02-10 Thread Stephan Houben
Hi all, I would like to add one more generic remark about syntax extensions, regarding something Markus said and which has bothered me before, also related to other syntax proposals. "Decorator approach is no different from doing `Foo.bar = bar` under the function definition I think, except it

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

2017-02-10 Thread Steven D'Aprano
On Fri, Feb 10, 2017 at 02:28:25PM +0200, Markus Meskanen wrote: > I've started working on a PEP for this since most people seem to be for it. I don't know how you get "most people" -- there's only been a handful of responses in the few hours since the original post. And apart from one

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

2017-02-10 Thread Markus Meskanen
I've started working on a PEP for this since most people seem to be for it. Will see how it turns out. On Fri, Feb 10, 2017 at 2:13 PM, Joao S. O. Bueno wrote: > I am definetelly -1 to this idea. > > But since you are discussing this seriously, one nice thing is to >

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

2017-02-10 Thread Joao S. O. Bueno
I am definetelly -1 to this idea. But since you are discussing this seriously, one nice thing is to recall how Javascript does that: `function () ` is an expression that returns the created function, and thus can be assigned to anything on the left side. Of course, that would throw us back to a

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

2017-02-10 Thread Chris Angelico
On Fri, Feb 10, 2017 at 11:02 PM, Thomas Kluyver wrote: > On Fri, Feb 10, 2017, at 11:05 AM, Chris Angelico wrote: >> * What would the __name__ be? In "def ham.spam():", is the name "spam" >> or "ham.spam"? Or say you have "def x[0]():" - is the name "x[0]" or >> something

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

2017-02-10 Thread Thomas Kluyver
On Fri, Feb 10, 2017, at 11:05 AM, Chris Angelico wrote: > * What would the __name__ be? In "def ham.spam():", is the name "spam" > or "ham.spam"? Or say you have "def x[0]():" - is the name "x[0]" or > something else? I'd say 'spam' in the first case, and a special value like '' in the latter.

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

2017-02-10 Thread Steven D'Aprano
On Fri, Feb 10, 2017 at 10:05:30PM +1100, Chris Angelico wrote: > * What would the __name__ be? In "def ham.spam():", is the name "spam" > or "ham.spam"? "spam" of course, just like it is now: py> class Ham: ... def spam(self): ... ... ... py> py> Ham.spam.__name__ 'spam' You

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

2017-02-10 Thread Paul Moore
On 10 February 2017 at 11:16, Chris Angelico wrote: > On Fri, Feb 10, 2017 at 10:13 PM, Paul Moore wrote: >> Furthermore, once we open up this possibility, I would expect requests >> for things like >> >> func_table = {} >> func_table["foo"] =

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

2017-02-10 Thread Chris Angelico
On Fri, Feb 10, 2017 at 10:13 PM, Paul Moore wrote: > Furthermore, once we open up this possibility, I would expect requests > for things like > > func_table = {} > func_table["foo"] = lambda a, b: a+b > def func_table["bar"] (a,b): > return a-b > > pretty

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

2017-02-10 Thread Paul Moore
On 10 February 2017 at 10:45, Markus Meskanen wrote: > Keep in mind that the extra syntax is *very* minor, and goes hand-to-hand > with the existing attribute access syntax. Basically it's taking the > existing syntax to one more place, where it in my opinion should have

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

2017-02-10 Thread Chris Angelico
On Fri, Feb 10, 2017 at 9:45 PM, Markus Meskanen wrote: >> That saves one line, at the cost of introducing even more complexity to >> the language. >> >> Are these use-cases common enough to justify the extra syntax? > > > Keep in mind that the extra syntax is *very*