[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 <jsbueno at python.org.br>:

> 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 <name> () ` 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 <steve at pearwood.info> 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 at python.org
> > https://mail.python.org/mailman/listinfo/python-ideas
> > Code of Conduct: http://python.org/psf/codeofconduct/
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20170210/3c2950be/attachment.html>