Re: [Python-ideas] Return for assignment blocks
Calvin Spealman wrote: You know what, I /can't/ think of other good examples than slightly improved decorators. So, maybe its not that great an idea if it can't be applied to at least a few more use cases. The class version might be useful for things like namedtuple that dynamically create classes. But that's even rarer than decorators. -- 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] Return for assignment blocks
On Thu, Oct 25, 2018 at 08:44:44AM -0400, Calvin Spealman wrote: > On Wed, Oct 24, 2018 at 4:41 PM Steven D'Aprano wrote: [...] > > I *think* you are proposing the following syntax. Am I right? > > > > > > return def (func): > > # body of func > > > > which is equivalent to: > > > > def func: > > # body of func > > return func [...] > > Aside from saving one line, what is the purpose of this? > > > > The point is not saving a line or typing, but saving a thought. Expressing > the intent of the factory function more clearly. I don't find that it expresses the intent clearly. Perhaps because I have read, and written, many factory functions that post-process the inner function in some fashion, to me creating the inner function is just one step out of possibly many steps, no more special than the others and not deserving of any special syntax. To give a toy example, adding an extra attribute to the function: def factory(argument): def inner(): ... inner.spam = "spam" return inner Another common pattern for me is changing the name of the inner function. Most of the time wraps() does this, but if the factory doesn't wrap another function, I frequently change the inner function name manually: inner.__name__ = some_name() or "default" Admittedly even for me, the pattern of returning the function immediately after it is created (usually after being decorated by functools.wraps) is very *common*, but I don't find it *special* enough to justify dedicated syntax. > Decorators don't do more than "saving one line", either. I didn't say they did. > But the biggest reason I'd like something like this is that it solves a > *specific* version of the multi-line anonymous function that comes up over > and over and over again, and maybe by chipping away at those use-cases we > can stop seeing *that* debate over and over and over again. :-) I don't see the connection. "def" will still be a statement, not an expression, so you can't put it in expressions with or without a leading "return" statement: x = [spam, eggs, return def func(): block, aardvark] nor can you put it in a lambda. So I don't see why this would help with the anonymous code block requests. > So, no, it doesn't save a lot of typing, but I'm never interested in that. > I don't spend a lot of time typing code, I spend it reading code, and > something like this would certainly help there, imho. I don't think it will "certainly" help. I think you're projecting your own opinion onto others. I don't find it very readable, and neither have some others who commented. When I read a function def, I read it as short for "define", an imperative command. "return def(ine)" doesn't read like English to me. I also see return, expect an expression, and instead find a statement, so I find it jarring. If *everything was an expression* in Python, perhaps I would agree with you, but then we wouldn't need special syntax because we could already write "return def ...". But given that we do have the statement vs expression dichotomy in Python, making def a special case but only in return statements causes an exception in my brain when I read it :-) -- 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] Return for assignment blocks
On Thu, Oct 25, 2018 at 7:41 AM Calvin Spealman wrote: > > On Thu, Oct 25, 2018 at 9:28 AM Anders Hovmöller > wrote: > >> [Calvin] >> > The point is not saving a line or typing, but saving a thought. >> Expressing the intent of the factory function more clearly. >> > [...] > You know what, I *can't* think of other good examples than slightly > improved decorators. So, maybe its not that great an idea if it can't be > applied to at least a few more use cases. > I appreciate that you're saving a thought, and I think it isn't a bad idea. It is indeed a very common pattern in decorators. But it would be a bit of a one-trick pony, since there aren't many *other* situations where it's useful. Compared to decorators themselves (which also, as was pointed out, do so much more than "saving a line") the use case is just much narrower. So unless we find more use cases, or until we can convince ourselves that we can use `def (args): block` in all expression contexts, I guess it'll have to remain an idea. Thank you though! It was a fascinating one. -- --Guido van Rossum (python.org/~guido) ___ 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] Return for assignment blocks
On Thu, Oct 25, 2018 at 9:28 AM Anders Hovmöller wrote: > > > The point is not saving a line or typing, but saving a thought. > Expressing the intent of the factory function more clearly. > > Could you give some other usage examples? > > To me it seems like a nicer and less confusing way to create decorators is > warranted but could then be more specialized and this much nicer. We > wouldn't necessarily get to that future point by adding super tiny > improvements to what we have, but instead take a step back and rethink what > the syntax could be. Personally I often just copy paste an existing > decorator and then tweak it instead of writing from scratch because it's > too confusing and error prone to do that. > You know what, I *can't* think of other good examples than slightly improved decorators. So, maybe its not that great an idea if it can't be applied to at least a few more use cases. / Anders ___ 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] Return for assignment blocks
> The point is not saving a line or typing, but saving a thought. Expressing > the intent of the factory function more clearly. Could you give some other usage examples? To me it seems like a nicer and less confusing way to create decorators is warranted but could then be more specialized and this much nicer. We wouldn't necessarily get to that future point by adding super tiny improvements to what we have, but instead take a step back and rethink what the syntax could be. Personally I often just copy paste an existing decorator and then tweak it instead of writing from scratch because it's too confusing and error prone to do that. / Anders ___ 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] Return for assignment blocks
On Wed, Oct 24, 2018 at 4:41 PM Steven D'Aprano wrote: > On Wed, Oct 24, 2018 at 09:18:14AM -0400, Calvin Spealman wrote: > > I'd like to suggest what I think would be a simple addition to `def` and > > `class` blocks. I don't know if calling those "Assignment Blocks" is > > accurate, but I just mean to refer to block syntaxes that assign to a > name. > > Anyway, I propose a combined return-def structure, and optionally also > > allowing a return-class version. Omitting the name would be allowable, as > > well. > > > > This would only apply to a `def` or `class` statement made as the last > part > > of the function body, of course. > > > > def ignore_exc(exc_type): > > return def (func): > > @wraps(func) > > return def (*args, **kwargs): > > try: > > return func(*args, **kwargs) > > except exc_type: > > pass > > Your example is too complex for me this early in the morning -- I can't > tell what it actually *does*, as it is obscured by what looks like a > bunch of irrelevent code. > > I *think* you are proposing the following syntax. Am I right? > > > return def (func): > # body of func > > which is equivalent to: > > def func: > # body of func > return func > > And similar for classes: > > return class (K): > # body of K > > being equivalent to: > > class K: > # body of K > return K > > > Is it intentional that your example function takes no arguments? If the > function did, where would the parameter list go in your syntax? > > Aside from saving one line, what is the purpose of this? > The point is not saving a line or typing, but saving a thought. Expressing the intent of the factory function more clearly. Decorators don't do more than "saving one line", either. But the biggest reason I'd like something like this is that it solves a *specific* version of the multi-line anonymous function that comes up over and over and over again, and maybe by chipping away at those use-cases we can stop seeing *that* debate over and over and over again. :-) So, no, it doesn't save a lot of typing, but I'm never interested in that. I don't spend a lot of time typing code, I spend it reading code, and something like this would certainly help there, imho. > -- > 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] Return for assignment blocks
On 25/10/2018 02:15, Virendra Tripathi wrote: In addition to what GVR wrote, a generator function would have to have its own syntax - backward compatibility would be another issue. No it wouldn't. This is about returning the function/generator/class itself, not its results. I still don't think it's worth it, mind you. On Wed, Oct 24, 2018 at 2:31 PM Greg Ewing wrote: Calvin Spealman wrote: def ignore_exc(exc_type): return def (func): > ... Something very similar has been suggested before, you might like to review the previous discussion. -- Rhodri James *-* Kynesim Ltd ___ 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] Return for assignment blocks
In addition to what GVR wrote, a generator function would have to have its own syntax - backward compatibility would be another issue. Virendra Tripathi Santa Clara, CA 415-910-4955 trip...@gmail.com On Wed, Oct 24, 2018 at 2:31 PM Greg Ewing wrote: > Calvin Spealman wrote: > > > def ignore_exc(exc_type): > > return def (func): > > ... > > Something very similar has been suggested before, you might > like to review the previous discussion. > > -- > 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/ > ___ 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] Return for assignment blocks
On Wed, Oct 24, 2018 at 09:18:14AM -0400, Calvin Spealman wrote: > I'd like to suggest what I think would be a simple addition to `def` and > `class` blocks. I don't know if calling those "Assignment Blocks" is > accurate, but I just mean to refer to block syntaxes that assign to a name. > Anyway, I propose a combined return-def structure, and optionally also > allowing a return-class version. Omitting the name would be allowable, as > well. > > This would only apply to a `def` or `class` statement made as the last part > of the function body, of course. > > def ignore_exc(exc_type): > return def (func): > @wraps(func) > return def (*args, **kwargs): > try: > return func(*args, **kwargs) > except exc_type: > pass Your example is too complex for me this early in the morning -- I can't tell what it actually *does*, as it is obscured by what looks like a bunch of irrelevent code. I *think* you are proposing the following syntax. Am I right? return def (func): # body of func which is equivalent to: def func: # body of func return func And similar for classes: return class (K): # body of K being equivalent to: class K: # body of K return K Is it intentional that your example function takes no arguments? If the function did, where would the parameter list go in your syntax? Aside from saving one line, what is the purpose of 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] Return for assignment blocks
On 24/10/2018 15:04, Calvin Spealman wrote: My idea is not "assignment blocks" those already exist. `def` and `class` blocks are both syntaxes that assign to some name. I'm just using the term to refer to them as a group. The proposal is just being able to return them. These two examples become equivalent: def ignore_exc(exc_type): return def (func): @wraps(func) return def (*args, **kwargs): try: return func(*args, **kwargs) except exc_type: pass def ignore_exc(exc_type): def decorator(func): @wraps(func) def wrapped_func(*args, **kwargs): try: return func(*args, **kwargs) except exc_type: pass return wrapped_func return decorator Essentially this is a limited multi-line lambda. Either people are going to be surprised that you can only use it in a return statement or you have to open the whole can of worms about multi-line lambdas. Good luck on the latter. -- Rhodri James *-* Kynesim Ltd ___ 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] Return for assignment blocks
My idea is not "assignment blocks" those already exist. `def` and `class`
blocks are both syntaxes that assign to some name. I'm just using the term
to refer to them as a group.
The proposal is just being able to return them. These two examples become
equivalent:
def ignore_exc(exc_type):
return def (func):
@wraps(func)
return def (*args, **kwargs):
try:
return func(*args, **kwargs)
except exc_type:
pass
def ignore_exc(exc_type):
def decorator(func):
@wraps(func)
def wrapped_func(*args, **kwargs):
try:
return func(*args, **kwargs)
except exc_type:
pass
return wrapped_func
return decorator
On Wed, Oct 24, 2018 at 9:51 AM Benedikt Werner <1benediktwer...@gmail.com>
wrote:
> Would you mind providing a bit more details about your proposal?
>
> What exactly are those "Assignment Blocks" supposed to do?
>
> If I understand your proposal correctly you want this:
>
> def my_func():
> return def():
> print("abc")
>
> to be the same as this:
>
> def my_func():
> def inner_func():
> print("abc")
> return inner_func
>
> But this is only my assumption as your proposal doesn't give very much
> details.
> Maybe you should provide a few simple examples and explain what they are
> supposed to do or what they should be equivalent to.
>
> Your example is quite complex and to me it's not clear at all what it is
> supposed to mean.
>
> Also and probably most importantly what is the reason you want this? Are
> there any good usecases where this would help?
>
> If my assumption above is correct this just looks like a bit of syntactic
> sugar that IMO isn't really neccessary. It doesn't really improve
> readability or save many characters. The existing way to do this is totally
> fine.
>
> Benedikt
>
> Am 24.10.2018 um 15:18 schrieb Calvin Spealman:
>
> I'd like to suggest what I think would be a simple addition to `def` and
> `class` blocks. I don't know if calling those "Assignment Blocks" is
> accurate, but I just mean to refer to block syntaxes that assign to a name.
> Anyway, I propose a combined return-def structure, and optionally also
> allowing a return-class version. Omitting the name would be allowable, as
> well.
>
> This would only apply to a `def` or `class` statement made as the last
> part of the function body, of course.
>
> def ignore_exc(exc_type):
> return def (func):
> @wraps(func)
> return def (*args, **kwargs):
> try:
> return func(*args, **kwargs)
> except exc_type:
> pass
>
> Thanks for considering and for any comments, thoughts, or feedback on the
> idea!
>
>
> ___
> Python-ideas mailing
> listPython-ideas@python.orghttps://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] Return for assignment blocks
Would you mind providing a bit more details about your proposal?
What exactly are those "Assignment Blocks" supposed to do?
If I understand your proposal correctly you want this:
def my_func():
return def():
print("abc")
to be the same as this:
def my_func():
def inner_func():
print("abc")
return inner_func
But this is only my assumption as your proposal doesn't give very much
details.
Maybe you should provide a few simple examples and explain what they are
supposed to do or what they should be equivalent to.
Your example is quite complex and to me it's not clear at all what it is
supposed to mean.
Also and probably most importantly what is the reason you want this? Are
there any good usecases where this would help?
If my assumption above is correct this just looks like a bit of
syntactic sugar that IMO isn't really neccessary. It doesn't really
improve readability or save many characters. The existing way to do this
is totally fine.
Benedikt
Am 24.10.2018 um 15:18 schrieb Calvin Spealman:
I'd like to suggest what I think would be a simple addition to `def`
and `class` blocks. I don't know if calling those "Assignment Blocks"
is accurate, but I just mean to refer to block syntaxes that assign to
a name. Anyway, I propose a combined return-def structure, and
optionally also allowing a return-class version. Omitting the name
would be allowable, as well.
This would only apply to a `def` or `class` statement made as the last
part of the function body, of course.
def ignore_exc(exc_type):
return def (func):
@wraps(func)
return def (*args, **kwargs):
try:
return func(*args, **kwargs)
except exc_type:
pass
Thanks for considering and for any comments, thoughts, or feedback on
the idea!
___
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] Return for assignment blocks
I'd like to suggest what I think would be a simple addition to `def` and `class` blocks. I don't know if calling those "Assignment Blocks" is accurate, but I just mean to refer to block syntaxes that assign to a name. Anyway, I propose a combined return-def structure, and optionally also allowing a return-class version. Omitting the name would be allowable, as well. This would only apply to a `def` or `class` statement made as the last part of the function body, of course. def ignore_exc(exc_type): return def (func): @wraps(func) return def (*args, **kwargs): try: return func(*args, **kwargs) except exc_type: pass Thanks for considering and for any comments, thoughts, or feedback on the idea! ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
