[Python-ideas] Inline Functions - idea

Chris Angelico rosuav at gmail.com
Wed Feb 5 16:28:48 CET 2014


On Thu, Feb 6, 2014 at 2:15 AM, Alex Rodrigues <lemiant at hotmail.com> wrote:
> I had never really considered using closures that way (I haven't really used
> them much at all), that is extremely cool! It does exactly what I was
> envisioning as long as you only need it in one spot. If inline function got
> implemented I'm sure they would steal a lot of code from closures.

Or, maintain compatibility with older versions of Python by simply
using closures :) Remember, something discussed here has to then be
coded, be accepted into trunk, be tested, and eventually be
distributed in a new version. You can't possibly get something like
this added to Python 3.3 or earlier; 3.4 is already too close to add
something like this to; so you'd be looking at 3.5 at the absolute
soonest. Maybe that's not a problem, if your code's for you and nobody
else (you can run a Python alpha or even a modified Python with
additional code in it), but if you want to distribute your code and
have people install Python and run your program, you'd be waiting an
absolute minimum of 2-3 years for this to happen. And the consequence
of that is that a proposed new feature really has to be all that
awesome; it has to be worth waiting several years for (and probably
putting in some coding work to create, unless you can excite someone
else enough to have him/her write it for you). That's a pretty steep
hump to get over.

> The remaining use cases for inline functions are times when you would need
> the same capabilities in multiple functions (calling in multiple methods of
> a class for example), or when you wish to define what is essentially a
> closure at the first level of execution, since closures are not possible
> when you are not in a function.

The nearest concept I can think of to your proposed inline functions
is a preprocessor macro. Effectively, you create a simple token that
expands to a block of source code, and it's handled prior to the
parsing and compilation of the code. There are times when that sort of
thing is really useful, but it's oh so easy to make horribly
unreadable code. (Plus, it'd be hard to get indentation right, if the
different contexts are indented to different levels.)

There's usually some other way to do what you want. Python's pretty
amazingly dynamic (often at the cost of performance); offer a specific
use-case (maybe on python-list rather than here) and there's a
reasonable chance someone can suggest a way to refactor it. Post
actual working code (in the verbose form), highlighting the duplicated
bits, and see what people offer. You'd be amazed what the language
already has!

> I always knew you could do it the way skip showed, but I feel like that is a
> bit clunky. This would allow you to do that in a more straight-forward way.

Yes, that proposal is VERY clunky. Passing locals() around is almost
always a baaaad idea :)

ChrisA


More information about the Python-ideas mailing list