for -- else: what was the motivation?

Avi Gross avi.e.gross at gmail.com
Sun Oct 9 15:32:13 EDT 2022


Peter,

There can be excellent reasons to undo a pipeline like I described. I often
write it carefully in smaller chunks while debugging and make it more
elegant later ...

But someone amused me by explaining they were going to let people believe
the code was written by them so it had to fit their style and abilities.
That meant removing most of my comments, renaming some variables, taking
out code that checked things like whether a file existed before opening it
and of course no pipelines. It had to be downgraded and had I known, I
could have easily given them code written as if it was in some poorer
language.

Python has idioms often used in making pipes of a sort but in languages
with other forms, such as R, debugging is not that difficult as you can
insert functions in middle of a pipeline that print what you want but
return the data structure they were fed for the next step in the pipeline.
When done, remove the lines with such entries or change the function
definition or something like that.

Objects used as pipelines do not do this as easily as you may need to add
methods ...


On Sun, Oct 9, 2022, 1:17 PM Peter J. Holzer <hjp-python at hjp.at> wrote:

> On 2022-10-09 12:34:22 -0400, Avi Gross wrote:
> > I have seen programmers who have taken an elegant pipeline I have built
> > apart and made it into many lines of code reassignment the value of each
> > step to the same or different variables and other ways of lengthening or
> > obscuring my intent.
>
> I have certainly done that (not with your code, AFAIK). The problem with
> those beautiful one-liners is that they are really hard to debug. So if
> I can't convince myself that they are correct just by reading them I
> have to split them over multiple lines so I can add breakpoints or log
> messages. Of course I could put it together again afterwards, but I
> would argue that if I didn't understand it the first time it's probably
> better to leave it in its more verbose and debuggable state.
>
> Of course I have also done the opposite: Taken some messy and
> complicated code and simplified it into a simple generator expression.
> In fact I would say that I code tends to be shorter after I fixed a bug
> than before.
>
>
> > So although size may matter, so can sighs.
>
> :-)
>
>         hp
>
> --
>    _  | Peter J. Holzer    | Story must make more sense than reality.
> |_|_) |                    |
> | |   | hjp at hjp.at         |    -- Charles Stross, "Creative writing
> __/   | http://www.hjp.at/ |       challenge!"
> --
> https://mail.python.org/mailman/listinfo/python-list
>


More information about the Python-list mailing list