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

[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 up again, and I'm sure
it has (but my memory gets fuzzy more than a few months back)

It would be great to document it even if it is headed for rejection.

-CHB


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 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 the beginning of the
>> definition of a function called foo. I'm not sure whether
>> the parser would cope with that.
>
> Forget the parser. I know *I* can't cope with that.
>
> *wink*

So you think the language should prevent silly assignments?

>>> stuff = [None] * 10
>>> def foo(): return stuff
...
>>> for x, foo()[x] in enumerate(range(len(stuff))): pass
...
>>> stuff
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]

Given that Python is happy to do these kinds of assignments in 'for'
statements, I don't see any reason to prevent them in 'def'
statements. It's not the language's job to prevent abuse; at best,
that's a job for a style guide.

ChrisA
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 be acceptable, because foo(x)[5] is something
> assignable, but foo(x) looks like the beginning of the
> definition of a function called foo. I'm not sure whether
> the parser would cope with that.

Forget the parser. I know *I* can't cope with that.

*wink*


-- 
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 acceptable, because foo(x)[5] is something
> assignable, but foo(x) looks like the beginning of the
> definition of a function called foo. I'm not sure whether
> the parser would cope with that.

We could require parentheses to be used anywhere the grammar otherwise
couldn't handle it, like yielding a tuple from a generator expression.

def (whatever)(args):

This does raise the question though of what the function's name/qualname
would be. It's cosmetic, but it's also the only real difference between
def and an assignment *now*, so it's worth considering. In the case
where the last element of the expression is an attribute, the name would
simply be the attribute, but would the class portion of the qualname
(and the name when it's not an attribute) need to depend on the runtime
value of what is being assigned, or would it simply use a string of
exactly "foo(x)[5]"?
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 the beginning of the
definition of a function called foo. I'm not sure whether
the parser would cope with that.

--
Greg
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 trick, e.g.,

class Spam(metaclass=ABCMeta):
@abstractmethod
def func(self):
pass

def Spam.func(self):
return __class__


An abstractfunction should not become a concrete function on the 
abstract class - the right way to do this is to use a subclass.


class SpamBase(metaclass=ABCMeta):
@abstractmethod
def func(self):
pass

class Spam(SpamBase):
def func(self):
return __class__


If you want to define parts of the class in separate modules, use mixins:

from myarray.transforms import MyArrayTransformMixin
from myarray.arithmetic import MyArrayArithmeticMixin
from myarray.constructors import MyArrayConstructorsMixin

class MyArray(MyArrayConstructorsMixin, MyArrayArithmeticMixin, 
MyArrayTransformMixin):

pass


The big different between these approaches and the proposal is that the 
proposal does not require both parties to agree on the approach. This is 
actually a terrible idea, as subclassing or mixing in a class that 
wasn't meant for it leads to all sorts of trouble unless the end user is 
very careful. Providing first-class syntax or methods for this 
discourages carefulness. (Another way of saying it is that directly 
overriding class members should feel a bit dirty because it *is* a bit 
dirty.)


As Paul said in an earlier email, the best use of non-direct assignment 
in function definitions is putting it into a dispatch dictionary, and in 
this case making a decorator is likely cleaner than adding new syntax.


But by all means, let's have a PEP. It will simplify the discussion when 
it comes up in six months again (or whenever the last time this came up 
was - less than a year, I'm sure).


Cheers,
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 identical to:
>
> class Spam:
> def func(self):
> return __class__
>

Yes, this is exactly what I would hope/expect to see.

One use case for this functionality is defining classes with an extensive
method-based API with a sane dependency graph. For example, consider
writing a class like numpy.ndarray
 or
pandas.DataFrame

with dozens of methods. You could argue that using so many methods is an
anti-pattern, but nonetheless it's pretty common and hard to avoid in some
cases (e.g., for making number-like classes that support arithmetic and
comparisons).

For obvious reasons, the functionality for these classes does not all live
in a single module. But the modules that define helper functions for most
methods also depend on the base class, so many of them need to get imported
inside method definitions

to
avoid circular imports. The result is pretty ugly, and files defining the
class still get gigantic.

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 trick, e.g.,

class Spam(metaclass=ABCMeta):
@abstractmethod
def func(self):
pass

def Spam.func(self):
return __class__

And finally, it's quite possible that there's a clean metaclass based
solution for extending Spam in another file, I just don't know it yet.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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)):
   ...

See: https://gist.github.com/stephanh42/97b47506e5e416f97f5790c070be7878

Stephan


2017-02-10 19:48 GMT+01:00 Nick Timkovich :

> 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). If you
> have multiple modules/packages, horrors can evolve where a class method
> could be patched in an unknown location by any loaded module (or you could
> even introduce order-of-import sensitivities).
>
> For testing, this can be a necessary evil which is OK so long as the patch
> is limited/apparent, and some other very narrow cases (setuptools something
> something?). That said, I don't want their use condoned or eased for fear
> of proliferation of these "antiprogrammer land mines" that I might trip
> over in the future.
>
> On Fri, Feb 10, 2017 at 12:15 PM, Joshua Morton  > wrote:
>
>> 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 definition, will not have side effects. This potentially changes
>> that since
>>
>> def Foo.foo(self):
>> ...
>>
>> could be a descriptor. Even if it doesn't, its possible that `Foo.foo` is
>> actually resolved from `Foo._foo`, and so this potentially further confuses
>> the naming considerations.
>>
>> Then we have metaclasses. Prior to this change, it would be fully the
>> monkeypatcher's responsibility to do any metaclass level changes if they
>> were necessary when monkeypatching. However, since we are potentially
>> adding a first class support for certain monkeypatches, It raises a
>> question about some first class way to handle monkeypatched methods. Do we
>> need to provide some kind of method to a metaclass writer that allows them
>> to handle methods that are patched on later? Or does the language still
>> ignore it?
>>
>> --Josh
>>
>> On Fri, Feb 10, 2017 at 12:20 PM Nick Coghlan  wrote:
>>
>>> 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 parenthesis. __qualname__ would be built
>>> >> the exact same way it currently is, based on that __name__.
>>> >
>>> > If I'm reading this right, you want this behaviour:
>>> >
>>> > class Spam:
>>> > pass
>>> >
>>> > def Spam.func(self): pass
>>> >
>>> > assert 'Spam.func' not in Spam.__dict__
>>> > assert 'func' in Spam.__dict__
>>> >
>>> > assert Spam.func.__name__ == 'Spam.func'
>>> > assert Spam.func.__qualname__ == 'Spam.Spam.func'
>>> >
>>> > If that's the case, I can only ask... what advantage do you see from
>>> > this? Because I can see plenty of opportunity for confusion, and no
>>> > advantage.
>>>
>>> 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 identical to:
>>>
>>> class Spam:
>>> def func(self):
>>> return __class__
>>>
>>> such that:
>>>
>>>   * __name__ is set based on the method name after the dot
>>>   * __qualname__ is set based on the __name__ of the given class
>>>   * __set_owner__ is called after any function decorators are applied
>>>   * zero-argument super() and other __class__ references work properly
>>> from the injected method
>>>
>>> Potentially, RuntimeError could be raised if the reference before the
>>> dot is not to a type instance.
>>>
>>> If it *doesn't* do that, then I'd be -1 on the proposal, since it
>>> doesn't add enough expressiveness to the language to be worth the
>>> extra syntax. By contrast, if it *does* do it, then it makes class
>>> definitions more decomposable, by providing post-definition access to
>>> parts of the machinery that are currently only accessible during the
>>> process of defining the class.
>>>
>>> The use case would be to make it easier to inject descriptors when
>>> writing class decorators such that they behave essentially the same as
>>> they do when defined in the class body:
>>>
>>> def my_class_decorator(cls):
>>> def cls.injected_method(self):
>>> # Just write injected methods the same way you would in a
>>> class body
>>> 

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

[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 class
 method could be patched in an unknown location by any loaded module (or
 you could even introduce order-of-import sensitivities).


Folks can still do that nightmare right now.

I'm -0.5 on it -- I don't think the payoff is worth the pain.

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!)

--
~Ethan~
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 function's header; for example in a decorator and during
typing.

No additional "fancy" features are intended, it would simply replace this:

foo = Bar()
def f():
...
foo.f = f

With syntax sugar, similar to how decorators replaced this:

def f():
...
f = decorate(f)

On Feb 10, 2017 20:50, "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). If you
> have multiple modules/packages, horrors can evolve where a class method
> could be patched in an unknown location by any loaded module (or you could
> even introduce order-of-import sensitivities).
>
> For testing, this can be a necessary evil which is OK so long as the patch
> is limited/apparent, and some other very narrow cases (setuptools something
> something?). That said, I don't want their use condoned or eased for fear
> of proliferation of these "antiprogrammer land mines" that I might trip
> over in the future.
>
> On Fri, Feb 10, 2017 at 12:15 PM, Joshua Morton  > wrote:
>
>> 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 definition, will not have side effects. This potentially changes
>> that since
>>
>> def Foo.foo(self):
>> ...
>>
>> could be a descriptor. Even if it doesn't, its possible that `Foo.foo` is
>> actually resolved from `Foo._foo`, and so this potentially further confuses
>> the naming considerations.
>>
>> Then we have metaclasses. Prior to this change, it would be fully the
>> monkeypatcher's responsibility to do any metaclass level changes if they
>> were necessary when monkeypatching. However, since we are potentially
>> adding a first class support for certain monkeypatches, It raises a
>> question about some first class way to handle monkeypatched methods. Do we
>> need to provide some kind of method to a metaclass writer that allows them
>> to handle methods that are patched on later? Or does the language still
>> ignore it?
>>
>> --Josh
>>
>> On Fri, Feb 10, 2017 at 12:20 PM Nick Coghlan  wrote:
>>
>>> 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 parenthesis. __qualname__ would be built
>>> >> the exact same way it currently is, based on that __name__.
>>> >
>>> > If I'm reading this right, you want this behaviour:
>>> >
>>> > class Spam:
>>> > pass
>>> >
>>> > def Spam.func(self): pass
>>> >
>>> > assert 'Spam.func' not in Spam.__dict__
>>> > assert 'func' in Spam.__dict__
>>> >
>>> > assert Spam.func.__name__ == 'Spam.func'
>>> > assert Spam.func.__qualname__ == 'Spam.Spam.func'
>>> >
>>> > If that's the case, I can only ask... what advantage do you see from
>>> > this? Because I can see plenty of opportunity for confusion, and no
>>> > advantage.
>>>
>>> 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 identical to:
>>>
>>> class Spam:
>>> def func(self):
>>> return __class__
>>>
>>> such that:
>>>
>>>   * __name__ is set based on the method name after the dot
>>>   * __qualname__ is set based on the __name__ of the given class
>>>   * __set_owner__ is called after any function decorators are applied
>>>   * zero-argument super() and other __class__ references work properly
>>> from the injected method
>>>
>>> Potentially, RuntimeError could be raised if the reference before the
>>> dot is not to a type instance.
>>>
>>> If it *doesn't* do that, then I'd be -1 on the proposal, since it
>>> doesn't add enough expressiveness to the language to be worth the
>>> extra syntax. By contrast, if it *does* do it, then it makes class
>>> definitions more decomposable, by providing post-definition access to
>>> parts of the machinery that are currently only accessible during the
>>> process of defining the class.
>>>
>>> The use case would be to make it easier to inject descriptors when
>>> writing class decorators such that they behave essentially the same as
>>> they 

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

[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 definition, will not have side effects. This potentially changes
that since

def Foo.foo(self):
...

could be a descriptor. Even if it doesn't, its possible that `Foo.foo` is
actually resolved from `Foo._foo`, and so this potentially further confuses
the naming considerations.

Then we have metaclasses. Prior to this change, it would be fully the
monkeypatcher's responsibility to do any metaclass level changes if they
were necessary when monkeypatching. However, since we are potentially
adding a first class support for certain monkeypatches, It raises a
question about some first class way to handle monkeypatched methods. Do we
need to provide some kind of method to a metaclass writer that allows them
to handle methods that are patched on later? Or does the language still
ignore it?

--Josh

On Fri, Feb 10, 2017 at 12:20 PM Nick Coghlan  wrote:

> 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 parenthesis. __qualname__ would be built
> >> the exact same way it currently is, based on that __name__.
> >
> > If I'm reading this right, you want this behaviour:
> >
> > class Spam:
> > pass
> >
> > def Spam.func(self): pass
> >
> > assert 'Spam.func' not in Spam.__dict__
> > assert 'func' in Spam.__dict__
> >
> > assert Spam.func.__name__ == 'Spam.func'
> > assert Spam.func.__qualname__ == 'Spam.Spam.func'
> >
> > If that's the case, I can only ask... what advantage do you see from
> > this? Because I can see plenty of opportunity for confusion, and no
> > advantage.
>
> 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 identical to:
>
> class Spam:
> def func(self):
> return __class__
>
> such that:
>
>   * __name__ is set based on the method name after the dot
>   * __qualname__ is set based on the __name__ of the given class
>   * __set_owner__ is called after any function decorators are applied
>   * zero-argument super() and other __class__ references work properly
> from the injected method
>
> Potentially, RuntimeError could be raised if the reference before the
> dot is not to a type instance.
>
> If it *doesn't* do that, then I'd be -1 on the proposal, since it
> doesn't add enough expressiveness to the language to be worth the
> extra syntax. By contrast, if it *does* do it, then it makes class
> definitions more decomposable, by providing post-definition access to
> parts of the machinery that are currently only accessible during the
> process of defining the class.
>
> The use case would be to make it easier to inject descriptors when
> writing class decorators such that they behave essentially the same as
> they do when defined in the class body:
>
> def my_class_decorator(cls):
> def cls.injected_method(self):
> # Just write injected methods the same way you would in a
> class body
> return __class__
> return cls
>
> (Actually doing this may require elevating super and __class__ to true
> keyword expressions, rather than the pseudo-keywords they are now)
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 parenthesis. __qualname__ would be built
>> the exact same way it currently is, based on that __name__.
>
> If I'm reading this right, you want this behaviour:
>
> class Spam:
> pass
>
> def Spam.func(self): pass
>
> assert 'Spam.func' not in Spam.__dict__
> assert 'func' in Spam.__dict__
>
> assert Spam.func.__name__ == 'Spam.func'
> assert Spam.func.__qualname__ == 'Spam.Spam.func'
>
> If that's the case, I can only ask... what advantage do you see from
> this? Because I can see plenty of opportunity for confusion, and no
> advantage.

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 identical to:

class Spam:
def func(self):
return __class__

such that:

  * __name__ is set based on the method name after the dot
  * __qualname__ is set based on the __name__ of the given class
  * __set_owner__ is called after any function decorators are applied
  * zero-argument super() and other __class__ references work properly
from the injected method

Potentially, RuntimeError could be raised if the reference before the
dot is not to a type instance.

If it *doesn't* do that, then I'd be -1 on the proposal, since it
doesn't add enough expressiveness to the language to be worth the
extra syntax. By contrast, if it *does* do it, then it makes class
definitions more decomposable, by providing post-definition access to
parts of the machinery that are currently only accessible during the
process of defining the class.

The use case would be to make it easier to inject descriptors when
writing class decorators such that they behave essentially the same as
they do when defined in the class body:

def my_class_decorator(cls):
def cls.injected_method(self):
# Just write injected methods the same way you would in a class body
return __class__
return cls

(Actually doing this may require elevating super and __class__ to true
keyword expressions, rather than the pseudo-keywords they are now)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 on that __name__.

If I'm reading this right, you want this behaviour:

class Spam:
pass

def Spam.func(self): pass

assert 'Spam.func' not in Spam.__dict__
assert 'func' in Spam.__dict__

assert Spam.func.__name__ == 'Spam.func'
assert Spam.func.__qualname__ == 'Spam.Spam.func'

If that's the case, I can only ask... what advantage do you see from 
this? Because I can see plenty of opportunity for confusion, and no 
advantage.


For what its worth, Lua already has this feature:

http://www.lua.org/pil/6.2.html

Lib = {}
function Lib.foo (x,y)
  return x + y
end

If we define that function foo inside the Lib table, and then cause an 
error, the Lua interpreter tells us the function name:

> Lib.foo('a', 1)
stdin:2: attempt to perform arithmetic on local 'x' (a string value)
stack traceback:
stdin:2: in function 'foo'
stdin:1: in main chunk
[C]: in ?


-- 
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 `class' but
> realistically
> I am now going to blight Stackoverflow with my questions.
[…]

but this is definitely not a reason to dismiss a proposal. A language is
aimed at evolves and introduce new syntax features, and yes,
stackoverflow will get questions about it, blog articles written and
RTFW updated, so you'll get the info you'll need fastly.

Cheers,

-- 
Guyzmo
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 scope?
>
> What happens if you attempt to use zero-argument super() when *not* at
> class scope?
>
> These are *answerable* questions...

... and are exactly why I asked the OP to write up a PEP. This isn't
my proposal, so it's not up to me to make the decisions.

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 on that __name__.

Zero-argument super() would behave exactly the way it would if you
used a simple name. This just changes the assignment, not the creation
of the function. So if you're inside a class, you could populate a
lookup dictionary with method-like functions. Abuse this, and you're
only shooting your own foot.

Zero-argument super() outside of a class, just as currently, would be
an error. (Whatever kind of error it currently is.)

Maybe there are better answers to these questions, I don't know.
That's what the PEP's for.

ChrisA
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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"] = lambda a, b: a+b
>> def func_table["bar"] (a,b):
>> return a-b
>>
>> pretty quickly. How would you respond to those? (Setting up function
>> tables is a much more common and reasonable need than monkeypatching
>> classes).
>
> Which is why these proposals always seem to gravitate to "anything you
> can assign to", which is at least easy enough to explain. All your
> examples would be completely acceptable.under that system.

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 scope?

What happens if you attempt to use zero-argument super() when *not* at
class scope?

These are *answerable* questions (and injecting the right __class__
cell reference for zero-argument super() support is a compelling
technical argument in favour of this feature over ordinary attribute
binding operations), but there's a lot more to the proposal than just
relaxing a syntactic restriction in the language grammar.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 post. And apart from one
>> explicit -1, I read most of them as neutral, not in favour.
>
>
> Yeah I worded that poorly, more like most people didn't turn me down which I
> was a bit afraid of.

To be clear, I'm -1 on the proposal.

As I said, I can see a small attraction in the *idea*, but for me, the
practical considerations seem too great.
Paul
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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") but the idea never
seems to stick, as people keep forgetting to consider it when
proposing new ideas.

With this proposal the only thing you can search for is "def", and
you're going to mostly find sites that explain the current syntax. So
anyone looking for understanding of the new construct will likely end
up even more confused after searching than they were before.

Markus - if you do write up a PEP, please make sure this point is
noted and addressed.

Paul
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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.
>

Yeah I worded that poorly, more like most people didn't turn me down which
I was a bit afraid of.


> I'm one of the neutral parties, perhaps just a tiny bit positive +0, but
> only for the original proposal.
>
> I am -1000 on allowing arbitrary assignment targets. I believe that the
> cost in readability far outweighs the usefulness of allowing things
> like:
>
> def mydict[key].attr[-1](arg): ...


Do not worry, I will not propose the advanced method, only dot notation!
That being said, I don't think it's up to the language if someone wants to
write ugly code like that, you can already do way uglier stuff with the
existing features. I don't really see people doing this either:

mydict[key].attr[-1].append(my_func)

So why would they if we suddenly introduce this to functions? Anyways
that's not a worry of this to-be PEP.

- Markus
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 requires one to figure out what the
decorator does first."

My point would be that the new syntax *also* requires one to figure out
what the new syntax does.
And unfortunately, syntax is much less discoverable than decorators.
For a decorator, I can do `help(decorator)' or search the python library
reference or probably
just mouse-hover over the name in my favourite editor/IDE.

But if I don't understand the dot in `class foo.bar:', then what?
It's probably somewhere buried in the language spec for `class' but
realistically
I am now going to blight Stackoverflow with my questions.

Stephan

2017-02-10 13:13 GMT+01:00 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 way of thinking of inline
> definition of multiline functions -
> which is another requested and unresolved thing in Python.
>
> (But we might require the `def` statement to still be aligned, at
> least style-wise, and require
> people to write
>
> Foo.foo =\
> def (self, ...): ...
>
> )
>
> That said, this possibility in Javascript is the source of severe
> inconsistencies in how functions are declared across different
> libraries and projects, and IMHO, makes reading (and writting) a real pain.
>
> (And, as stated above, a two line decorator could make for the patching -
> it does not need to have such an ugly name as "monkey_patch" - it
> could be just "assign" instead)
>
>  js
> -><-
>
> On 10 February 2017 at 09:51, Steven D'Aprano  wrote:
> > 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 might be thinking of __qualname__:
> >
> > py> Ham.spam.__qualname__
> > 'Ham.spam'
> >
> >
> >> Or say you have "def x[0]():" - is the name "x[0]" or
> >> something else?
> >
> > I wouldn't allow that. I feel that "any assignment target at all" is an
> > over-generalisation, a case of YAGNI.
> >
> > It is relatively easy to change our mind and add additional cases in the
> > future, but very difficult to remove them if they turn out to be a
> > mistake.
> >
> > My intuition tells me that we should allow :
> >
> > def name dot name (args):
> >
> > possibly even more than one dot:
> >
> > def name dot name dot name ... (args):
> >
> >
> > but no additional cases:
> >
> > # syntax error
> > def spam[0]function(): ...
> >
> >
> >
> >
> > --
> > Steve
> > ___
> > Python-ideas mailing list
> > Python-ideas@python.org
> > https://mail.python.org/mailman/listinfo/python-ideas
> > Code of Conduct: http://python.org/psf/codeofconduct/
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 
explicit -1, I read most of them as neutral, not in favour.

Of course you are perfectly entitled to start work on a PEP at any time, 
but don't get your hopes up.

I'm one of the neutral parties, perhaps just a tiny bit positive +0, but 
only for the original proposal.

I am -1000 on allowing arbitrary assignment targets. I believe that the 
cost in readability far outweighs the usefulness of allowing things 
like:

def mydict[key].attr[-1](arg): ...


-- 
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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
> 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 way of thinking of inline
> definition of multiline functions -
> which is another requested and unresolved thing in Python.
>
> (But we might require the `def` statement to still be aligned, at
> least style-wise, and require
> people to write
>
> Foo.foo =\
> def (self, ...): ...
>
> )
>
> That said, this possibility in Javascript is the source of severe
> inconsistencies in how functions are declared across different
> libraries and projects, and IMHO, makes reading (and writting) a real pain.
>
> (And, as stated above, a two line decorator could make for the patching -
> it does not need to have such an ugly name as "monkey_patch" - it
> could be just "assign" instead)
>
>  js
> -><-
>
> On 10 February 2017 at 09:51, Steven D'Aprano  wrote:
> > 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 might be thinking of __qualname__:
> >
> > py> Ham.spam.__qualname__
> > 'Ham.spam'
> >
> >
> >> Or say you have "def x[0]():" - is the name "x[0]" or
> >> something else?
> >
> > I wouldn't allow that. I feel that "any assignment target at all" is an
> > over-generalisation, a case of YAGNI.
> >
> > It is relatively easy to change our mind and add additional cases in the
> > future, but very difficult to remove them if they turn out to be a
> > mistake.
> >
> > My intuition tells me that we should allow :
> >
> > def name dot name (args):
> >
> > possibly even more than one dot:
> >
> > def name dot name dot name ... (args):
> >
> >
> > but no additional cases:
> >
> > # syntax error
> > def spam[0]function(): ...
> >
> >
> >
> >
> > --
> > Steve
> > ___
> > Python-ideas mailing list
> > Python-ideas@python.org
> > https://mail.python.org/mailman/listinfo/python-ideas
> > Code of Conduct: http://python.org/psf/codeofconduct/
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 way of thinking of inline
definition of multiline functions -
which is another requested and unresolved thing in Python.

(But we might require the `def` statement to still be aligned, at
least style-wise, and require
people to write

Foo.foo =\
def (self, ...): ...

)

That said, this possibility in Javascript is the source of severe
inconsistencies in how functions are declared across different
libraries and projects, and IMHO, makes reading (and writting) a real pain.

(And, as stated above, a two line decorator could make for the patching -
it does not need to have such an ugly name as "monkey_patch" - it
could be just "assign" instead)

 js
-><-

On 10 February 2017 at 09:51, Steven D'Aprano  wrote:
> 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 might be thinking of __qualname__:
>
> py> Ham.spam.__qualname__
> 'Ham.spam'
>
>
>> Or say you have "def x[0]():" - is the name "x[0]" or
>> something else?
>
> I wouldn't allow that. I feel that "any assignment target at all" is an
> over-generalisation, a case of YAGNI.
>
> It is relatively easy to change our mind and add additional cases in the
> future, but very difficult to remove them if they turn out to be a
> mistake.
>
> My intuition tells me that we should allow :
>
> def name dot name (args):
>
> possibly even more than one dot:
>
> def name dot name dot name ... (args):
>
>
> but no additional cases:
>
> # syntax error
> def spam[0]function(): ...
>
>
>
>
> --
> Steve
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 else?
>
> I'd say 'spam' in the first case, and a special value like ' function>' in the latter. You already can't rely on __name__ being a
> usable name in arbitrary callables:
>
> x[0] = lambda: 0
> x[0].__name__ == ''

And this is exactly why this wants a PEP - to collect decisions and
arguments on all of these bikesheds.

ChrisA
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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. You already can't rely on __name__ being a
usable name in arbitrary callables:

x[0] = lambda: 0
x[0].__name__ == ''
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 might be thinking of __qualname__:

py> Ham.spam.__qualname__
'Ham.spam'


> Or say you have "def x[0]():" - is the name "x[0]" or
> something else?

I wouldn't allow that. I feel that "any assignment target at all" is an 
over-generalisation, a case of YAGNI.

It is relatively easy to change our mind and add additional cases in the 
future, but very difficult to remove them if they turn out to be a 
mistake.

My intuition tells me that we should allow :

def name dot name (args): 

possibly even more than one dot:

def name dot name dot name ... (args): 


but no additional cases:

# syntax error
def spam[0]function(): ...




-- 
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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"] = lambda a, b: a+b
>> def func_table["bar"] (a,b):
>> return a-b
>>
>> pretty quickly. How would you respond to those? (Setting up function
>> tables is a much more common and reasonable need than monkeypatching
>> classes).
>
> Which is why these proposals always seem to gravitate to "anything you
> can assign to", which is at least easy enough to explain. All your
> examples would be completely acceptable.under that system.

Precisely.
Paul
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 quickly. How would you respond to those? (Setting up function
> tables is a much more common and reasonable need than monkeypatching
> classes).

Which is why these proposals always seem to gravitate to "anything you
can assign to", which is at least easy enough to explain. All your
examples would be completely acceptable.under that system.

ChrisA
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 been
> since long ago.

In implementation terms, the syntax change is not as minor as you
suggest. At the moment, the syntax for a "def" statement is:

funcdef ::= [decorators] "def" funcname "(" [parameter_list] ")" ["->"
expression] ":" suite
funcname  ::=  identifier

You're proposing replacing "identifier" as the definition of a
"funcname" with... what? dotted_name might work, but that opens up the
possibility of

class Foo:
pass

foo = Foo

def foo.a(self): pass

(note I'm defining a method on the *instance*, not on the class). Do
you want to allow that? What about "def a.b.c.d.e(): pass" (no self as
argument, deeply nested instance attribute).

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 quickly. How would you respond to those? (Setting up function
tables is a much more common and reasonable need than monkeypatching
classes).

Your proposal is clear enough in terms of your intent, but the
implementation details are non-trivial.

Paul

PS Personally, I'm slightly in favour of the idea in principle, but I
don't think it's a useful enough addition to warrant having to deal
with all the questions I note above.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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* 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 been
> since long ago.
>

Every now and then, we get a proposal along these lines. I think it's
about time a PEP got written.

The usual way this is explained is that a function name can be
anything you can assign to. Currently, a function has to have a simple
name, and it then gets created with that as its __name__ and bound to
that name in the current namespace (module, class, or function). To
achieve what you're looking for, the syntax would be defined in terms
of assignment, same as a 'for' loop's iteration variable is:

# Perfectly legal
for spam.ham in iter: pass

# Not currently legal
def ham.spam(): pass

Markus, do you want to head this up? I'll help out with any editorial
work you have trouble with (as a PEP editor, I can assign it a number
and so on).

Considerations:

* 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?
* Are there any syntactic ambiguities? Any special restrictions?
* Exactly what grammar token would be used? Currently NAME; might become 'test'?
* Will there be any possible backward incompatibilities?

Create a pull request against https://github.com/python/peps - looks
like the next number is 542.

Any questions, I'm happy to help.

ChrisA
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/