Useless if statement in yum source [closed]

up vote
5
down vote

favorite

I was curious about how something worked in yum so I was looking at some of its score code and I found this line in the erasePkgs function in cli.py.

if False: pass

elif basecmd in ('erase-n', 'remove-n'):

   rms = self.remove(name=arg)

.

.

.

The if False: pass does nothing correct? It never gets into that branch it always just skips to the next one doesn't it?

Here is the link to the source code: https://github.com/rpm-software-management/yum/blob/master/cli.py. It's on line 1268.

asked Nov 8 at 19:33

Willwsharp

364218

closed as off-topic by Iguananaut, mjhm, jonrsharpe, Prune, roganjosh Nov 8 at 19:52

This question does not appear to be about programming within the scope defined in the help center.

If this question can be reworded to fit the rules in the help center, please edit the question.

4

Probably was just some code that used to exist but maybe the branch got effectively "commented out" by putting in if False. Or maybe the developer had intentions to put something there but forgot. Who knows? It's just code rot. It doesn't do anything, as you say.
– Iguananaut
Nov 8 at 19:36

4

I'm voting to close this question as off-topic because we can't guess what some developer intended with random junk code.
– Iguananaut
Nov 8 at 19:37

1

@Iguananaut Well I wanted to ask here in case there was a reason that I wasn't aware of as I am not an expert in Python and I figured there could be a valid reason for that line to exist.
– Willwsharp
Nov 8 at 19:38

1

Nope. None whatsoever.
– Iguananaut
Nov 8 at 19:38

1

Eh, I don't think we need to guess the developer's intent to answer this. Either the answer is "yes, if False: pass followed by elif x: y() is identical to just if x: y()", or the answer is "here is a corner case where if False: pass may have a sensible purpose"
– Kevin
Nov 8 at 19:39

|
show 3 more comments

up vote
5
down vote

favorite

I was curious about how something worked in yum so I was looking at some of its score code and I found this line in the erasePkgs function in cli.py.

if False: pass

elif basecmd in ('erase-n', 'remove-n'):

   rms = self.remove(name=arg)

.

.

.

The if False: pass does nothing correct? It never gets into that branch it always just skips to the next one doesn't it?

Here is the link to the source code: https://github.com/rpm-software-management/yum/blob/master/cli.py. It's on line 1268.

asked Nov 8 at 19:33

Willwsharp

364218

closed as off-topic by Iguananaut, mjhm, jonrsharpe, Prune, roganjosh Nov 8 at 19:52

This question does not appear to be about programming within the scope defined in the help center.

If this question can be reworded to fit the rules in the help center, please edit the question.

4

Probably was just some code that used to exist but maybe the branch got effectively "commented out" by putting in if False. Or maybe the developer had intentions to put something there but forgot. Who knows? It's just code rot. It doesn't do anything, as you say.
– Iguananaut
Nov 8 at 19:36

4

I'm voting to close this question as off-topic because we can't guess what some developer intended with random junk code.
– Iguananaut
Nov 8 at 19:37

1

@Iguananaut Well I wanted to ask here in case there was a reason that I wasn't aware of as I am not an expert in Python and I figured there could be a valid reason for that line to exist.
– Willwsharp
Nov 8 at 19:38

1

Nope. None whatsoever.
– Iguananaut
Nov 8 at 19:38

1

Eh, I don't think we need to guess the developer's intent to answer this. Either the answer is "yes, if False: pass followed by elif x: y() is identical to just if x: y()", or the answer is "here is a corner case where if False: pass may have a sensible purpose"
– Kevin
Nov 8 at 19:39

|
show 3 more comments

up vote
5
down vote

favorite

I was curious about how something worked in yum so I was looking at some of its score code and I found this line in the erasePkgs function in cli.py.

if False: pass

elif basecmd in ('erase-n', 'remove-n'):

   rms = self.remove(name=arg)

.

.

.

The if False: pass does nothing correct? It never gets into that branch it always just skips to the next one doesn't it?

Here is the link to the source code: https://github.com/rpm-software-management/yum/blob/master/cli.py. It's on line 1268.

asked Nov 8 at 19:33

Willwsharp

364218

I was curious about how something worked in yum so I was looking at some of its score code and I found this line in the erasePkgs function in cli.py.

if False: pass

elif basecmd in ('erase-n', 'remove-n'):

   rms = self.remove(name=arg)

.

.

.

The if False: pass does nothing correct? It never gets into that branch it always just skips to the next one doesn't it?

Here is the link to the source code: https://github.com/rpm-software-management/yum/blob/master/cli.py. It's on line 1268.

python yum

asked Nov 8 at 19:33

Willwsharp

364218

asked Nov 8 at 19:33

Willwsharp

364218

asked Nov 8 at 19:33

Willwsharp

364218

asked Nov 8 at 19:33

Willwsharp

364218

asked Nov 8 at 19:33

Willwsharp

364218

closed as off-topic by Iguananaut, mjhm, jonrsharpe, Prune, roganjosh Nov 8 at 19:52

This question does not appear to be about programming within the scope defined in the help center.

If this question can be reworded to fit the rules in the help center, please edit the question.

closed as off-topic by Iguananaut, mjhm, jonrsharpe, Prune, roganjosh Nov 8 at 19:52

This question does not appear to be about programming within the scope defined in the help center.

If this question can be reworded to fit the rules in the help center, please edit the question.

4

Probably was just some code that used to exist but maybe the branch got effectively "commented out" by putting in if False. Or maybe the developer had intentions to put something there but forgot. Who knows? It's just code rot. It doesn't do anything, as you say.
– Iguananaut
Nov 8 at 19:36

4

I'm voting to close this question as off-topic because we can't guess what some developer intended with random junk code.
– Iguananaut
Nov 8 at 19:37

1

@Iguananaut Well I wanted to ask here in case there was a reason that I wasn't aware of as I am not an expert in Python and I figured there could be a valid reason for that line to exist.
– Willwsharp
Nov 8 at 19:38

1

Nope. None whatsoever.
– Iguananaut
Nov 8 at 19:38

1

Eh, I don't think we need to guess the developer's intent to answer this. Either the answer is "yes, if False: pass followed by elif x: y() is identical to just if x: y()", or the answer is "here is a corner case where if False: pass may have a sensible purpose"
– Kevin
Nov 8 at 19:39

|
show 3 more comments

4

Probably was just some code that used to exist but maybe the branch got effectively "commented out" by putting in if False. Or maybe the developer had intentions to put something there but forgot. Who knows? It's just code rot. It doesn't do anything, as you say.
– Iguananaut
Nov 8 at 19:36

4

I'm voting to close this question as off-topic because we can't guess what some developer intended with random junk code.
– Iguananaut
Nov 8 at 19:37

1

@Iguananaut Well I wanted to ask here in case there was a reason that I wasn't aware of as I am not an expert in Python and I figured there could be a valid reason for that line to exist.
– Willwsharp
Nov 8 at 19:38

1

Nope. None whatsoever.
– Iguananaut
Nov 8 at 19:38

1

Eh, I don't think we need to guess the developer's intent to answer this. Either the answer is "yes, if False: pass followed by elif x: y() is identical to just if x: y()", or the answer is "here is a corner case where if False: pass may have a sensible purpose"
– Kevin
Nov 8 at 19:39

Probably was just some code that used to exist but maybe the branch got effectively "commented out" by putting in if False. Or maybe the developer had intentions to put something there but forgot. Who knows? It's just code rot. It doesn't do anything, as you say.
– Iguananaut
Nov 8 at 19:36

I'm voting to close this question as off-topic because we can't guess what some developer intended with random junk code.
– Iguananaut
Nov 8 at 19:37

@Iguananaut Well I wanted to ask here in case there was a reason that I wasn't aware of as I am not an expert in Python and I figured there could be a valid reason for that line to exist.
– Willwsharp
Nov 8 at 19:38

Nope. None whatsoever.
– Iguananaut
Nov 8 at 19:38

Eh, I don't think we need to guess the developer's intent to answer this. Either the answer is "yes, if False: pass followed by elif x: y() is identical to just if x: y()", or the answer is "here is a corner case where if False: pass may have a sensible purpose"
– Kevin
Nov 8 at 19:39

|
show 3 more comments

1 Answer
1

active

oldest

votes

up vote
5
down vote

accepted

This appears to be the developer's idiom for a generalized switch statement.

        if False: pass

        elif basecmd in ('erase-n', 'remove-n'):

            rms = self.remove(name=arg)

        elif basecmd in ('erase-na', 'remove-na'):

            ...

        elif basecmd in ('erase-nevra', 'remove-nevra'):

            ...

        else:

            ...

which is ever so slightly more readable than

        if basecmd in ('erase-n', 'remove-n'):

            rms = self.remove(name=arg)

        elif basecmd in ('erase-na', 'remove-na'):

            ...

        elif basecmd in ('erase-nevra', 'remove-nevra'):

            ...

        else:

            ...

answered Nov 8 at 19:50

mjhm

13.6k93655

Huh that's interesting, the readability doesn't seem much better/worse either way for me. Thanks for your insight.
– Willwsharp
Nov 8 at 19:51

2

I suppose it's "slightly more readable" only because all the conditions have the same elif prefix, analogous to the way a switch/case in other languages has a consistent case prefix. But the added confusion from the first line probably negates any of that benefit, except to the original author who's familiar with his own style.
– Barmar
Nov 8 at 20:00

add a comment |

1 Answer
1

active

oldest

votes

1 Answer
1

active

oldest

votes

up vote
5
down vote

accepted

This appears to be the developer's idiom for a generalized switch statement.

        if False: pass

        elif basecmd in ('erase-n', 'remove-n'):

            rms = self.remove(name=arg)

        elif basecmd in ('erase-na', 'remove-na'):

            ...

        elif basecmd in ('erase-nevra', 'remove-nevra'):

            ...

        else:

            ...

which is ever so slightly more readable than

        if basecmd in ('erase-n', 'remove-n'):

            rms = self.remove(name=arg)

        elif basecmd in ('erase-na', 'remove-na'):

            ...

        elif basecmd in ('erase-nevra', 'remove-nevra'):

            ...

        else:

            ...

answered Nov 8 at 19:50

mjhm

13.6k93655

Huh that's interesting, the readability doesn't seem much better/worse either way for me. Thanks for your insight.
– Willwsharp
Nov 8 at 19:51

2

I suppose it's "slightly more readable" only because all the conditions have the same elif prefix, analogous to the way a switch/case in other languages has a consistent case prefix. But the added confusion from the first line probably negates any of that benefit, except to the original author who's familiar with his own style.
– Barmar
Nov 8 at 20:00

add a comment |

up vote
5
down vote

accepted

This appears to be the developer's idiom for a generalized switch statement.

        if False: pass

        elif basecmd in ('erase-n', 'remove-n'):

            rms = self.remove(name=arg)

        elif basecmd in ('erase-na', 'remove-na'):

            ...

        elif basecmd in ('erase-nevra', 'remove-nevra'):

            ...

        else:

            ...

which is ever so slightly more readable than

        if basecmd in ('erase-n', 'remove-n'):

            rms = self.remove(name=arg)

        elif basecmd in ('erase-na', 'remove-na'):

            ...

        elif basecmd in ('erase-nevra', 'remove-nevra'):

            ...

        else:

            ...

answered Nov 8 at 19:50

mjhm

13.6k93655

Huh that's interesting, the readability doesn't seem much better/worse either way for me. Thanks for your insight.
– Willwsharp
Nov 8 at 19:51

2

I suppose it's "slightly more readable" only because all the conditions have the same elif prefix, analogous to the way a switch/case in other languages has a consistent case prefix. But the added confusion from the first line probably negates any of that benefit, except to the original author who's familiar with his own style.
– Barmar
Nov 8 at 20:00

add a comment |

up vote
5
down vote

accepted

This appears to be the developer's idiom for a generalized switch statement.

        if False: pass

        elif basecmd in ('erase-n', 'remove-n'):

            rms = self.remove(name=arg)

        elif basecmd in ('erase-na', 'remove-na'):

            ...

        elif basecmd in ('erase-nevra', 'remove-nevra'):

            ...

        else:

            ...

which is ever so slightly more readable than

        if basecmd in ('erase-n', 'remove-n'):

            rms = self.remove(name=arg)

        elif basecmd in ('erase-na', 'remove-na'):

            ...

        elif basecmd in ('erase-nevra', 'remove-nevra'):

            ...

        else:

            ...

answered Nov 8 at 19:50

mjhm

13.6k93655

This appears to be the developer's idiom for a generalized switch statement.

        if False: pass

        elif basecmd in ('erase-n', 'remove-n'):

            rms = self.remove(name=arg)

        elif basecmd in ('erase-na', 'remove-na'):

            ...

        elif basecmd in ('erase-nevra', 'remove-nevra'):

            ...

        else:

            ...

which is ever so slightly more readable than

        if basecmd in ('erase-n', 'remove-n'):

            rms = self.remove(name=arg)

        elif basecmd in ('erase-na', 'remove-na'):

            ...

        elif basecmd in ('erase-nevra', 'remove-nevra'):

            ...

        else:

            ...

answered Nov 8 at 19:50

mjhm

13.6k93655

answered Nov 8 at 19:50

mjhm

13.6k93655

answered Nov 8 at 19:50

mjhm

13.6k93655

answered Nov 8 at 19:50

mjhm

13.6k93655

Huh that's interesting, the readability doesn't seem much better/worse either way for me. Thanks for your insight.
– Willwsharp
Nov 8 at 19:51

2

I suppose it's "slightly more readable" only because all the conditions have the same elif prefix, analogous to the way a switch/case in other languages has a consistent case prefix. But the added confusion from the first line probably negates any of that benefit, except to the original author who's familiar with his own style.
– Barmar
Nov 8 at 20:00

add a comment |

Huh that's interesting, the readability doesn't seem much better/worse either way for me. Thanks for your insight.
– Willwsharp
Nov 8 at 19:51

2

I suppose it's "slightly more readable" only because all the conditions have the same elif prefix, analogous to the way a switch/case in other languages has a consistent case prefix. But the added confusion from the first line probably negates any of that benefit, except to the original author who's familiar with his own style.
– Barmar
Nov 8 at 20:00

Huh that's interesting, the readability doesn't seem much better/worse either way for me. Thanks for your insight.
– Willwsharp
Nov 8 at 19:51

I suppose it's "slightly more readable" only because all the conditions have the same elif prefix, analogous to the way a switch/case in other languages has a consistent case prefix. But the added confusion from the first line probably negates any of that benefit, except to the original author who's familiar with his own style.
– Barmar
Nov 8 at 20:00

add a comment |

This page is only for reference, If you need detailed information, please check here

搜尋此網誌

Xtykutl