[Tutor] this group and one liners

[avi.e.gross at gmail.com]

What sometimes amazes me, Max, is how some functions people write get adjusted to support more and more options. It can be as simple as setting a default value for missing options, or the ability to support more kinds of data and converting it to the type needed, or an argument to specify how many significant digits you want in the output and lots more you can imagine.

Now if you built a one-liner or even a very condensed multi-line version, fitting in additional options becomes a challenge. You may introduce errors by shoehorning in something without enough consideration and testing.

Building your code more loosely and more step by step, can make it far easier to modify cleanly and maybe easier to document as you have some room for comments and so on.

What you are talking about may well be a different idea at times, that a function that is too long and complex might better be re-written as a collection of smaller functions so each part of the task is done at a level of abstraction and comprehension that makes sense. That can be taken too far, as well, especially if the names and ideas are not at the level people think at. And, of course, it can lead to errors if someone just copies a function without the parts it depends on.

So a dumb question is whether you approve of defining functions within a function just to be used ONCE within the function but that makes it easier to read when you finally get to the meat and are able to say something somewhat meaningful like:

If (is_X((data) and is_Y(data) and not is_empty(data)): pass

If the functions are not that useful for anything else, this keeps them all together, albeit there may be some overhead if the main function is called repeatedly, or will there be if it is properly interpreted and pseudo-compiled?

I think it is high time I dropped this diversion and waited for a person asking for actual help. 😉



-----Original Message-----
From: Tutor <tutor-bounces+avi.e.gross=gmail.com at python.org> On Behalf Of Mats Wichmann
Sent: Thursday, July 7, 2022 11:38 AM
To: tutor at python.org
Subject: Re: [Tutor] this group and one liners


On 7/6/22 11:02, avi.e.gross at gmail.com wrote:

Boy, we "old-timers" do get into these lengthy discussions...  having read several comments here, of which this is only one:

> The excuse for many one-liners is often that they are in some ways better as in use less memory or are faster in some sense.
> 
> Although that can be true, I think it is reasonable to say that often the exact opposite is true.
> 
> In order to make a compact piece of code, you often twist the problem around in a way that makes it possible to leave out some cases or not need to handle errors and so on. I did this a few days ago until I was reminded max(..., default=0) handled my need. Some of my attempts around it generated lots of empty strings which were all then evaluated as zero length and then max() processed a longer list with lots of zeroes.


After a period when they felt awkward because lots of my programming background was in languages that didn't have these, I now use simple one-liners extensively - comprehensions and ternary expressions.  If they start nesting, probably not.  Someone mentioned a decent metric - if a code formatter like Black starts breaking your comprehension into four lines, it probably got too complex.

My take on these is you can write a more compact function this way - you're more likely to have the meat of what's going on right there together in a few lines, rather than building mountain ranges of indentation - and this can actually *improve* readability, not obscure it.  I agree "clever" one-liners may be a support burden, but anyone with a reasonable amount of Python competency (which I'd expect of anyone in a position to maintain my code at a later date) should have no trouble recognizing the intent of simple ones.

Sometimes thinking about how to write a concise one-liner exposes a failure to have thought through what you're doing completely - so unlike what is mentioned above - twisting a problem around unnaturally (no argument that happens too), you might actually realize that there's a simpler way to structure a step.

Just one more opinion.
_______________________________________________
Tutor maillist  -  Tutor at python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor