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

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

But they're really very different when you look at it. Extension methods
are only used when the namespace containing them has been imported, and
are based on the static type of the object they are being called on.
They also have no access to the object's private members.

Python doesn't have static types and doesn't have private members, and
using this would make a real modification to the type the method is
being added to rather than relying on namespaces being imported, so
there would be fewer barriers to "use this for everything" than "use
extension methods for everything in C#".
___
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 attributeoutsideof a class with the dot operator

[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 language design
> sensibilities that we have so much magic bound up in class definitions
> that we don't expose for procedural access post-definition time -
> there's a whole lot of behaviours that "just happen" when a method is
> defined lexically inside a class body that can't readily be emulated
> for callables that are defined outside it.

If the OP is willing to write a PEP, I think it is worth taking a 
three-part approach:

- expose the class definition magic that Nick refers to;

- which will allow writing a proper inject_method() decorator;

- or allow def Class.method syntax.

I think I would prefer 

def Class.method ...

over

@inject_method(Class)
def method ...
del method

but given how high the barrier to new syntax is, perhaps we should be 
willing to take the decorator approach and leave the syntax for the 
future, once people have got used to the idea that extension methods 
won't cause the fall of civilization as we know it :-)


> However, even with that, I'm still only +0 on the idea - if folks
> really want it, `types.new_class` can already be used to creatively to
> address most of these things, and it's not exactly a problem that
> comes up very often in practice.

Swift and Objective-C users might, I think, disagree with that: they 
even have a term for this, "swizzling". This is part of the 
"Interceptor" design pattern:

https://en.wikipedia.org/wiki/Interceptor_pattern



-- 
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 attributeoutsideof a class with the dot operator

[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 that maybe should be considered?

The class doesn't exist yet, while Python is running the code
in its definition block.

You can play some tricks with meta classes exposing a .__prepare__()
method. This will receive the name of the to-be-created class
and allows returning a custom namespace in which the code is
run.

https://docs.python.org/3.6/reference/datamodel.html#preparing-the-class-namespace

The meta class docs have more details on how all this works:

https://docs.python.org/3.6/reference/datamodel.html#metaclasses

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Feb 13 2017)
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> Python Database Interfaces ...   http://products.egenix.com/
>>> Plone/Zope Database Interfaces ...   http://zope.egenix.com/


::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
  http://www.malemburg.com/

___
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 attributeoutsideof a class with the dot operator

[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 going to be hard to achieve given implicit binding of
`super` (as some have already mentioned) and more mind-bendingly when
user-defined metaclasses are in play.  Indeed, with metaclasses, it seems
like it become impossible to actually guarantee the equality of the above
two blocks of code.  Maybe the PEP writers are OK with that, but that
should be decided at the outset...

Also note that if users start adopting this as their default mode of class
creation (rather than just *class extending*), code-folding in a lot of
IDEs won't handle it gracefully (at least not for quite a while).

On Mon, Feb 13, 2017 at 11:32 AM, Joseph Hackman 
wrote:

> Generally speaking, I'm +1 on this idea, I think it would make code more
> readable, especially for tools like IDEs.
>
> 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 that maybe should be considered?
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>



-- 

[image: pattern-sig.png]

Matt Gilson // SOFTWARE ENGINEER

E: m...@getpattern.com // P: 603.892.7736

We’re looking for beta testers.  Go here
 to sign up!
___
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 attributeoutsideof a class with the dot operator

[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: MyClass) -> List[MyClass]:
>>   ...
>>
>> This is useful since you can't refer the class itself inside of its body. At
>> the moment the way to use typing is to write the class's name as a string...
>> It feels awful.
> 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 MyClass.__init__(self: MyClass, ...) -> None:
>  ...
>
> # add other methods here.

I am for method-outside-of-class form: If it is allowed, I will use it
extensively:

* instance methods and extension methods have the same form
* less lines between the line you are looking at and the name of the class
* explicit class name helps with searching for methods
* reduces indentation

thanks





___
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 attributeoutsideof a class with the dot operator

[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
>> required to be like
>>
>> class MyClass:
>>   """Docstring."""
>>
>> def MyClass.__init__(self: MyClass, ...) -> None:
>>  ...
>>
>> # add other methods here.
>
> This is pure and unadulterated FUD.
>
> Nobody is going to use this as the standard way of writing classes. That
> would be silly: you end up repeating the class name over and over and
> over again.

Sorry - but the I just pointed the effect. The person saying
that would start writing classes this way is
the grand-parent poster:

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: MyClass) -> List[MyClass]:
>   ...
>
> This is useful since you can't refer the class itself inside of its body. At
> the moment the way to use typing is to write the class's name as a string...
> It feels awful.


You are correct in your message, and thank you for calming me down,
 - but one thing remains: I was really scared by the grand parent poster -
and I still  prefer this possibility would not exist.

(And yes, I have code in which I needed doing what is proposed:
 the extra assignment line did not hurt me at all)


js
  -><-
>
> And to say that this will happen "in a couple [of] months" is totally
> unrealistic. Although, I suppose that if the entire Python community did
> drop 2.7-3.6 and move to 3.7 within just one or two months so they could
> use this syntax, that would certainly vindicate the (hypothetical)
> decision to add this syntax.
>
> 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 chances of this becoming the required, or even the recommended, way
> to write methods is much less than the chances of President Trump
> introducing Sharia law to the United States.
>
>
>> And all it will  take is some bureaucratic minded person to put that as 
>> default
>> option in some highly used linter, like the one that 
>> used-to-be-known-as-pep8.
>
> Do you *really* think that a linter that used to be called "PEP8" is
> going to require as a default syntax which (1) doesn't work before
> Python 3.7 at the earliest, and (2) has no support in PEP-8?
>
> It's one thing to question whether this feature is useful enough to be
> worth adding. It's another to make panicky claims that the Sky Will Fall
> if it is accepted.
>
>
> --
> 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 attributeoutsideof a class with the dot operator

[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 MyClass.__init__(self: MyClass, ...) -> None:
>  ...
> 
> # add other methods here.

This is pure and unadulterated FUD.

Nobody is going to use this as the standard way of writing classes. That 
would be silly: you end up repeating the class name over and over and 
over again.

And to say that this will happen "in a couple [of] months" is totally 
unrealistic. Although, I suppose that if the entire Python community did 
drop 2.7-3.6 and move to 3.7 within just one or two months so they could 
use this syntax, that would certainly vindicate the (hypothetical) 
decision to add this syntax.

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 chances of this becoming the required, or even the recommended, way 
to write methods is much less than the chances of President Trump 
introducing Sharia law to the United States.


> And all it will  take is some bureaucratic minded person to put that as 
> default
> option in some highly used linter, like the one that used-to-be-known-as-pep8.

Do you *really* think that a linter that used to be called "PEP8" is 
going to require as a default syntax which (1) doesn't work before 
Python 3.7 at the earliest, and (2) has no support in PEP-8?

It's one thing to question whether this feature is useful enough to be 
worth adding. It's another to make panicky claims that the Sky Will Fall 
if it is accepted.


-- 
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 attributeoutsideof a class with the dot operator

[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:
>>
>> anything.name = thing
>
> And the point here is that we don't need to extend def, because we
> already have that syntax. Adding new syntax for something that we can
> already do is generally accepted when the "thing we can already do" is
> deemed sufficiently important that it's worth making it a language
> feature in its own right. Decorators are a prime example of this -
> before the decorator syntax was added, decorating functions was just
> something that people occasionally did, but it wasn't a specific
> "concept".

Note that true method injection would *NOT* be the same as binding a
callable as a class attribute after the fact:

- attribute assignment doesn't modify __name__
- attribute assignment doesn't modify __qualname__
- attribute assignment doesn't call __set_owner__
- attribute assignment doesn't adjust the __class__ cell reference

Any method injection syntax worthy of the name would need to do those
things (probably via a new __setdescriptor__ magic method that is a
counterpart to PEP 447's __getdescriptor__).

> I'd argue that method injection (to use your phrase) isn't
> sufficiently important to warrant promotion to language syntax.

There's a lot to be said for implementing mixin behaviour by way of
definition time method injection rather than via MRO traversal when
looking up method names (although __init_subclass__ took away one of
the arguments in favour of it, since mixins can check their invariants
at definition time now).

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

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 language design
sensibilities that we have so much magic bound up in class definitions
that we don't expose for procedural access post-definition time -
there's a whole lot of behaviours that "just happen" when a method is
defined lexically inside a class body that can't readily be emulated
for callables that are defined outside it.

However, even with that, I'm still only +0 on the idea - if folks
really want it, `types.new_class` can already be used to creatively to
address most of these things, and it's not exactly a problem that
comes up very often in practice.

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 attributeoutsideof a class with the dot operator

[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 Mertz  wrote:
>
> But we already *have* decorators!  Here's a nice factory for them:
>
> def attach_to(thing, name=None):
>
> def decorator(fn):
>
> if name is None:
>
> name = fn.__name__
>
> setattr(thing, name, fn)
>
> return decorator
>
>
> This does everything you are asking for, e.g.:
>
> my_menu = Menu()
>
> @attach_to(my_menu)
> def callback(self, ...)
> ...
>
>
> I got extra fancy with two lines to allow you to either use the same name
> as the function itself or pick a custom name for the attribute.
>

-- 
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.
___
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 attributeoutsideof a class with the dot operator

[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):
>   self.items = items if items is not None else []
>   self.select_callback = select_callback
>
>   my_menu = Menu(['Pizza', 'Cake', 'Pasta'])
>   def my_menu.select_callback(item_index):
>   if item_index == 0:  # Pizza
>   serve_food(pizza)
>   else:  # Cake or Pasta
>   ...
> This is just one example of using it to set an instance's variable to a
> callback. It's just shorthand for:
>
>   def select_callback(item_index):
>   ...
>   my_menu.select_callback = select_callback
>

One issue that has been overlooked so far in this thread is that
hypothetical use cases are not as important as real-world use cases. One
way that PEPs can demonstrate real-world relevance is by demonstrating the
effect on some important libraries, e.g. the standard library.

For example, asyncio.Future (and concurrent.futures.Future) has a list of
callbacks and the API has add_done_callback() and remove_done_callback()
functions for manipulating the callback list. The proposed syntax doesn't
cooperate with these callbacks:

  f = asyncio.Future()

  def my_callback(x):
...

  f.add_done_callback(my_callback)

How should I write this using the proposed syntax? If the proposal doesn't
generalize well enough to cover existing callback patterns in Python's own
standard library, then that is a significant weakness.

Please keep this in mind as you write the PEP.
___
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 attributeoutsideof a class with the dot operator

[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.
Or maybe it's both, but those feel like fairly different use cases.

Which is to say, we really need a PEP.  As it stands, I'm somewhere around
-0.75 on the idea.

  @decorate(MyClass)
>   def MyClass.method(self, other: MyClass) -> List[MyClass]:
>

In this case, the syntax is 100% superfluous.  One can simply write:

  @decorate(MyClass)
  def method(self, other: MyClass) -> List[MyClass]:

The class is already mentioned in the decorator.  If the intention is to
add the method to the class, that's fine, and something a decorator can
do.  Perhaps the spelling for this decorator-factory could be `enhance`.
Or more verbosely `inject_method`.  Spelling aside, the syntax adds nothing.

  my_menu = Menu(['Pizza', 'Cake', 'Pasta'])
>   def my_menu.select_callback(item_index):
>   if item_index == 0:  # Pizza
>   serve_food(pizza)
>   else:  # Cake or Pasta
>   ...
>

Attaching to the instance is fine too.  But I prefer the current spelling
so far:

my_menu1 = Menu(['Pizza', 'Cake', 'Pasta'])

my_menu2 = Menu(...)


def callback1(self, ...):
...
def callback2(self, ...):
...

my_menu1.callback = callback2

my_menu2.callback = callback1


Under the current approach, you can flexibly define callbacks outside of
the scope of any particular instance or class, and attach them as needed to
instances.  Obviously the new syntax would not *remove* this option, but it
would cover only a narrow subset of what we can already do... and the way
we do it now feels much better self-documenting as to intent.

Yours, David...

-- 
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.
___
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 attributeoutsideof a class with the dot operator

[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
been mentioned already:

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

This is useful since you can't refer the class itself inside of its body.
At the moment the way to use typing is to write the class's name as a
string... It feels awful.

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):
  self.items = items if items is not None else []
  self.select_callback = select_callback

  my_menu = Menu(['Pizza', 'Cake', 'Pasta'])
  def my_menu.select_callback(item_index):
  if item_index == 0:  # Pizza
  serve_food(pizza)
  else:  # Cake or Pasta
  ...

This is just one example of using it to set an instance's variable to a
callback. It's just shorthand for:

  def select_callback(item_index):
  ...
  my_menu.select_callback = select_callback

This reads much easier and saves us from typing the same thing three times
(see decorators).
___
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 attributeoutsideof a class with the dot operator

[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 extend def, because we
already have that syntax. Adding new syntax for something that we can
already do is generally accepted when the "thing we can already do" is
deemed sufficiently important that it's worth making it a language
feature in its own right. Decorators are a prime example of this -
before the decorator syntax was added, decorating functions was just
something that people occasionally did, but it wasn't a specific
"concept".

I'd argue that method injection (to use your phrase) isn't
sufficiently important to warrant promotion to language syntax.

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
___
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 attributeoutsideof a class with the dot operator

[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. In theory, 
Python is the worst possible language to be programming in, because the 
introspection capabilities are so powerful, the data hiding so feeble, 
the dynamicism of the language so great that almost anything written in 
pure-Python can be poked and prodded, bits deleted and new bits 
inserted. Python doesn't even have constants!!!

import math
math.pi = 3.0 # change the very geometry of spacetime


And yet, in practice this is a problem more in theory than in practice. 
While you are right to raise this as a possible disadvantage of the 
proposal ("may ever-so-slightly encourage monkey-patching, by making it 
seem ever-so-slightly less mucky") I don't think you are right to weigh 
it as heavily as you appear to be doing.

Python has had setattr() forever, and the great majority of Python 
programmers manage to avoid abusing it.


> Monkeypatching is fairly blatantly taking advantage of the object 
> model in a way that is not "supported" and cannot behave well in the 
> context of everyone doing it, whereas inheritance or mixins are safe.

That's an extremely optimistic view of things.

Guido has frequently eluded to the problems with inheritance (you can't 
just inherit from anything and expect your code to work), and he's 
hardly the only one that has pointed out that inheritance and OOP hasn't 
turned out to be the panacea that people hoped. As for mixins, Michele 
Simionato has written a series of blog posts about the dangers of mixins 
and multiple inheritance, and suggesting traits as a more restricted and 
safer alternative. Start here:

http://www.artima.com/weblogs/viewpost.jsp?thread=246488

 
> 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


> (The extension_method decorator 
> sends exactly the wrong message about what it's doing.)

Are you refering to a decorator something like this?

@extend(TheClass)
def method(self, arg):
...

assert TheClass.method is method

Arguments about what it should be called aside, what is the wrong 
message you see here?


> Enabling a __class__ variable within the scope of the definition would 
> also solve the motivating example, 

Can you elaborate on that a bit more?

Given the current idiom for injecting a method:

class MyClass:
...

# Later on...
def method(self, arg):
   ...

MyClass.method = method
del method


where does the __class__ variable fit into this?




-- 
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 attributeoutsideof a class with the dot operator

[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 well in the context of everyone 
doing it, whereas inheritance or mixins are safe. Making a dedicated syntax or 
decorator for patching is saying that we (the language) think you should do it. 
(The extension_method decorator sends exactly the wrong message about what it's 
doing.)

Enabling a __class__ variable within the scope of the definition would also 
solve the motivating example, and is less likely to lead to code where you need 
to review multiple modules and determine whole-program import order to figure 
out why your calls do not work.

Top-posted from my Windows Phone

-Original Message-
From: "Markus Meskanen" 
Sent: ‎2/‎10/‎2017 10:18
To: "Paul Moore" 
Cc: "Python-Ideas" ; "Steve Dower" 

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

Well yes, but I think you're a bit too fast on labeling it a mistake to use 
monkey patching...




On Feb 10, 2017 18:15, "Paul Moore"  wrote:

On 10 February 2017 at 16:09, Markus Meskanen  wrote:
> But if people are gonna do it anyways with the tools provided (monkey
> patching), why not provide them with better tools?


Because encouraging and making it easier for people to make mistakes
is the wrong thing to do, surely?

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/