Why can function definitions only use identifiers, and not attribute references or any other primaries?
Hi. I'm sure there've been debates about this before, but I can't seem
to figure out what to search for to pull them up, so I'm asking here.
It seems to me that a lot of things could be made much easier if you
could use primaries other than basic identifiers for the target of
function definitions. For example, if attribute references were
allowed I'd be able to do:
def foo.bar():
return("I'm a method!")
If we wanted to get even more liberal (which I don't see as a bad
thing, but I could see being found more objectionable by some), we
could allow the use of anything that's a valid assignment target. For
example:
def foo["bar']():
return("I'm a function referenced in a mapping object!")
In this case I could see there being a problem in that there's nothing
to get the function's __name__ from, but that doesn't apply for the
first example.
Many uses of this may not be Pythonic, but I'm sure there are many
that are. It just feels like an arbitrary restriction, preventing
users from doing something that may be useful.
Any feedback or direction to previous discussion on the subject would
be appreciated. Thanks!
--
http://mail.python.org/mailman/listinfo/python-list
Re: Why can function definitions only use identifiers, and not attribute references or any other primaries?
Thanks for your comments. On Thu, Apr 23, 2009 at 11:52, Gary Herron wrote: > > [...] > > There's no need for a specific addition to the syntax to do this. > > Try this: > > def foo_bar(): > return(...) > foo.bar = foo_bar > >> [...] > > and this: > > def foo_bar(): > return(...) > foo["bar"] = foo_bar > I understand that this is possible now, but I just don't see why it's necessary to do it at all. >> In this case I could see there being a problem in that there's nothing >> to get the function's __name__ from, but that doesn't apply for the >> first example. >> > > Not sure what you mean here. >>> def foo(): pass ... >>> bar = foo >>> bar.__name__ 'foo' >>> If I defined foo.bar it would know that the method name was "bar", but if I defined foo["bar"] there's be no clear identifier to use for the function's name. I don't see this as a great problem, since anonymous functions already exist, but I thought it was worth acknowledging. To be clear, I don't see this as a serious fault in the language, but as an unnecessary restriction that makes code a little less direct than it could be. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why can function definitions only use identifiers, and not attribute references or any other primaries?
> Things like your suggestion are called "syntactic-sugar" -- syntax that > adds a convenience, but *no* new functionality. Python has plenty of > "syntactic-sugar"s, and more will be added in the future. To make an > argument for such an addition, one would have to describe some compelling > (and general) use cases in a well-argued PEP. You're welcome to try, but be > forewarned, most PEP's (especially syntax changing PEPs) don't fly far. Thank you very much for the feedback. I might throw something at Python-Ideas if I think I can come up with an adequate justification and don't come accross a previous similar propsition (though if I do miss it I'm sure it will be pointed out to me fairly quickly). I fully appreciate the small chance of success, but it certainly couldn't hurt to give it a try. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why can function definitions only use identifiers, and not attribute references or any other primaries?
On Thu, Apr 23, 2009 at 13:03, John Krukoff wrote: > You probably want to be searching for multi-line lambda to find the past > decade or so of this argument, as that's where most people who argued > for this came from. But, if you'd just like a bit of discouragement, > here's GvR arguing that there's just no good way to mix statements and > expressions in python: > http://www.artima.com/weblogs/viewpost.jsp?thread=147358 I've read those discussion before, but somehow never made the connection between those and this. I'll give that article a read, it probably details exactly the perspective I'm looking for. Thank you! -- http://mail.python.org/mailman/listinfo/python-list
Re: Why can function definitions only use identifiers, and not attribute references or any other primaries?
On Apr 23, 5:23 pm, Terry Reedy wrote:
> Jeremy Banks wrote:
> > Hi. I'm sure there've been debates about this before, but I can't seem
> > to figure out what to search for to pull them up, so I'm asking here.
>
> > It seems to me that a lot of things could be made much easier if you
> > could use primaries other than basic identifiers for the target of
> > function definitions. For example, if attribute references were
> > allowed I'd be able to do:
>
> > def foo.bar():
> > return("I'm a method!")
>
> > If we wanted to get even more liberal (which I don't see as a bad
> > thing, but I could see being found more objectionable by some), we
> > could allow the use of anything that's a valid assignment target. For
> > example:
>
> > def foo["bar']():
> > return("I'm a function referenced in a mapping object!")
>
> > In this case I could see there being a problem in that there's nothing
> > to get the function's __name__ from, but that doesn't apply for the
> > first example.
>
> > Many uses of this may not be Pythonic, but I'm sure there are many
> > that are. It just feels like an arbitrary restriction, preventing
> > users from doing something that may be useful.
>
> > Any feedback or direction to previous discussion on the subject would
> > be appreciated. Thanks!
>
> There has been some discussion on py-dev and perhaps python-ideas, but I
> cannot remember any specifics as to why Guido was unpersuaded/negative.
>
> If one regards
>
> def name(params): body
>
> as syntantic sugar for a (somewhat hypothetical) assignment statement
>
> name = make_func('name', "params", "body")
>
> (there is a function_maker function in the new module, though with a
> more complicated interface), then generalizing the target would seem
> reasonable. The function's __name__ does not seem like an issue:
> "foo.bar" and "foo['bar']" both direct one to the proper definition code.
>
> Counter-argument: class and import are also implied assignments, and
> they also subject to the same limitation.
>
> Counter-counter-argument: a) doing actual assignments with name =
> type('name', bases, dict) and name = __import__('name',...) is more
> feasible, and b) the need for qualified names is less for class and
> probably for import and c) the restriction *could* also be lifted for
> those two statements also.
>
> For some, a plus for this proposal is that is directly binds the
> function to the target without introducing a spurious name into the
> local scope. It would thus reduce the perceived need for and hence
> pressure for generalized function expressions. I believe Guido would
> consider this last point a plus if so stated.
>
> I do not believe this recurring idea has been the subject of a PEP. If
> not, writing one might be a service, should you choose to do so, even if
> rejected.
>
> Terry Jan Reedy
Interesting, thank you very much for your suggestions. I'll try to put
together a draft.
--
http://mail.python.org/mailman/listinfo/python-list
Inquiry regarding the name of subprocess.Popen class
Hi. I wondered if anyone knew the rationale behind the naming of the Popen class in the subprocess module. Popen sounds like the a suitable name for a function that created a subprocess, but the object itself is a subprocess, not a "popen". It seems that it would be more accurate to just name the class Subprocess, can anyone explain why this is not the case? Thank you. -- http://mail.python.org/mailman/listinfo/python-list
