Small fixes to python_dev_meeting branch

[billsacks]

There were a few minor outstanding changes in ESCOMP#1461 that I thought would be easier to fix myself rather than comment on. See comments in the individual commits for details.

[ekluzek]

These make sense to me. Since, Python doesn't have a sense of type putting the type in the name seems appropriate to me. I also like adding the on/off option since we use that in other places.

[billsacks]

Since, Python doesn't have a sense of type

This is getting tangential, but actually, part of my motivation for this was that python can have a sense of type (see https://docs.python.org/3/library/typing.html). @adrifoster and I have had some very preliminary discussions about moving towards using more type annotations in our python code. With or without that, though, it seems confusing to me to change the type of a variable within a function.

[negin513]

@billsacks
Thanks for your input. I agree with most of your changes (i.e. on off option and small changes in docstings). But I respectfully disagree with one of your changes in variable names. Please see my review below. I am interested to hear your thoughts if I am missing something.

[billsacks]

@negin513 I'm not seeing any review.

[negin513]

First, changing variable name from plon to plon_float is not a big deal and I can change this easily...

But I don't understand the motivation behind changing it and I want to clarify why...

1. Python variable re-binding is allowed and in some cases saves memory.
   For example:

a= '5'
a = int(5)

is allowed in Python because it is a dynamic programming language.
Please see: https://stackoverflow.com/questions/48224911/is-it-good-practice-to-change-the-type-of-a-variable-in-python

In fact this (dynamic typing) is one of the features of Python, so why not use it?
https://www.pythontutorial.net/advanced-python/dynamic-typing-in-python/

2. When the type of a variable changes it is recommended to use another name only when the old variable (with old type) is being used in the code again, which is not the case here...

3. Now, let's look at this function closely. It is a function that is only used in the argparser type:

        pt_parser.add_argument('--lon',
                    help='Single point longitude. [default: %(default)s]', 
                    action="store",
                    dest="plon",
                    required=False,
                    **type = plon_type,**
                    default= 287.8 )

So the parser return to the user has a variable called plon (i.e. destination variable des=plon) with type float. So the user does not see/interact with string form of plon at all.... This is not a function that the user calls to change the variable for them rather it is a small helper function called by the argparse (with the method recommended by Python argparse).

4. Finally, in Python it is always better to avoid using types in names to improve code readability... (hence the introduction of type hinting in python v3.6)...

• It is advised in Python to avoid using the types in variable names because it is potentially dangerous and reduces readability.
  https://docs.quantifiedcode.com/python-anti-patterns/readability/putting_type_information_in_a_variable_name.html

• On the other hand, if there are two different variables with two types needed in the code by all means, it would have made sense to create plon_str or plon_float or whatever names...

Please check the accepted response here:
https://stackoverflow.com/questions/25489118/same-variable-name-for-different-types-in-python

• Using type hinting, this is also 100% allowed :

def just_test(var: int) -> str:
    var = 'Printing: '+ str(var)
    print (var)
    return var 
 
# first var is integer:
var = 2 
var = just_test(var)  

[ekluzek]

This is all good discussion. I feel like for a different language I would know the answer for certain. And in FORTRAN for example it does often make sense to have the type in a variable name. Which is why my initial read is to endorse @billsacks suggested change. However dynamic scripting languages are completely different, and python has some real interesting subtleties to how it handles typing. So I think this is another thing that we should discuss as a group. I don't think this should be an issue, but we should discuss it, so I'll add it to an upcoming CTSM software meeting.

[billsacks]

@negin513 thank you very much for sharing your rationale with this detailed post. I can see how this would be a matter where there are opinions on both sides (which I guess is why https://stackoverflow.com/questions/48224911/is-it-good-practice-to-change-the-type-of-a-variable-in-python was closed as opinion-based). My feelings on this emerged from two places:

(1) My experience working with large python code bases (mainly CIME), where I have found that reusing a variable name for a different purpose / type can make it more difficult to read and understand code. This function is small enough that it doesn't matter, but I'm thinking more about general rules here.

(2) A long-term hope that we can have type hinting in our code along with using a checker like mypy. You pointed out that you can change the type of a variable and python will still run the code, but I don't think you can do this if you want to use static checkers like mypy (see https://adamj.eu/tech/2021/05/23/python-type-hints-mypy-doesnt-allow-variables-to-change-type/ ) or IDE features that leverage mypy or use similar techniques for checking code correctness. In fact, I'm not sure that python itself checks any type hinting for correctness: I think it is just intended for use with a tool like mypy (see https://www.blog.pythonlibrary.org/2020/04/15/type-checking-in-python , for example).

If you run your code snippet through mypy, you get:

testing.py:2: error: Incompatible types in assignment (expression has type "str", variable has type "int")
testing.py:4: error: Incompatible return value type (got "int", expected "str")
testing.py:8: error: Incompatible types in assignment (expression has type "str", variable has type "int")

You raise some good points about the dynamic typing nature of python. This is a much bigger discussion that I don't want to get into right now, but I have come to feel that, for large and/or jointly-developed code bases, python's dynamic typing is a weakness rather than a strength, and that is why I hope we can move towards using type annotations together with a static type checker eventually.

A few articles that express my views well are:

• https://realpython.com/lessons/pros-and-cons-type-hints for the value of type hints
• The accepted answer in https://softwareengineering.stackexchange.com/questions/187332/is-changing-the-type-of-a-variable-partway-through-a-procedure-in-a-dynamically for rationale on why it is problematic to change the type of a variable mid-way through a procedure

All that said, I'm fine deferring to you, @ekluzek and possibly @adrifoster if she wants to share any feelings on this.

[adrifoster]

I tend to agree with @billsacks that changing the type of a variable can lead to confusion in large code bases. I think in this instance since the function is so few lines it's not a huge deal. I'll also say that even if you don't change the variable name (and just change the type), Python still has to create a new object/memory allocation under the hood, so I'm not sure how much memory we are saving one way or the other. Though in this instance I don't think it really matters very much since it is such a short function and small object types.

I do really like the idea to start using type hinting. In terms of static type checking and using IDEs, I'll say that an IDE like Pycharm doesn't have an issue with plon = float(plon) even if you do use type hinting (def plon_type(plon: str) -> float:). Though if I try to return a string ( return str(plon_out)) I do get an IDE warning. So I'm guessing Pycharm is not using static type checking here.

I think the main benefit to using type hinting is that you know from looking at the function what the function needs and what you are getting out of it. I like the general rule of being explicit instead of implicit with coding.

I also found this interesting stack exchange convo on dynamic vs. static typing: https://softwareengineering.stackexchange.com/questions/122205/what-is-the-supposed-productivity-gain-of-dynamic-typing

For my part I like static typing, but this is likely because I use Fortran so much. I think in many cases we don't need to strictly follow all rules and guidelines if it makes more sense for our group to do something different.

I'm happy to discuss this more at an SE meeting in the future.

[negin513]

Thanks @billsacks for your response.
I also think using type hinting is a great feature and addition in python but this is not about type hinting at all. Type hinting is good if you use Pycharm or IDE for writing codes. But Type hinting does not mean adding _str or _int to the end of each variable. This is about variable names and dynamic typing in python which is perfectly allowed and is sometimes recommended to improve readability.

• The accepted answer in https://softwareengineering.stackexchange.com/questions/187332/is-changing-the-type-of-a-variable-partway-through-a-procedure-in-a-dynamically for rationale on why it is problematic to change the type of a variable mid-way through a procedure

As someone said in the answers, this particular example is not about type casting at all: "The problem with your example isn't because of dynamic typing, but because you use the same variable to refer to three different things."

I can see how this would be a matter where there are opinions on both sides (which I guess is why https://stackoverflow.com/questions/48224911/is-it-good-practice-to-change-the-type-of-a-variable-in-python was closed as opinion-based).

To quote yourself (and also re-iterating your point) this is probably more opinion-based.

Python is a strongly, dynamically typed. The strong part refers to exactly this: "Strong typing means that the type of a value doesn't change in unexpected ways. A string containing only digits doesn't magically become a number, as may happen in Perl. Every change of type requires an explicit conversion."

https://dev.to/icncsx/python-is-strongly-dynamically-typed-what-does-that-mean-5810
https://stackoverflow.com/questions/11328920/is-python-strongly-typed

Again, I just want to clarify that I am all for type hinting which does not contradict with what I am saying. Type hinting does not mean adding _str or _int to the end of each variable. It is not good practice to name the variables as var_str and var_int or str_var and int_var :
https://docs.quantifiedcode.com/python-anti-patterns/readability/putting_type_information_in_a_variable_name.html
https://stackoverflow.com/questions/111933/why-shouldnt-i-use-hungarian-notation
https://www.oreilly.com/library/view/how-to-make/9781492048275/ch03.html

[billsacks]

Thanks for these thoughts, @adrifoster and @negin513.

I should have said up-front that I am not at all tied to this variable name. I used the easiest thing that I could think of, but I didn't mean to argue that we should have a convention of using Hungarian Notation in any widespread sense, and I'm sorry if any of my comments gave that impression. I do think it's important to distinguish between two situations here, though: Convincing arguments I've read against using Hungarian Notation are ones that assume you are using it as a convention on every variable. I don't think those same arguments apply in the situation where you have two variables that represent the same thing other than their type: in that situation I feel like using the type in the variable name is often the most logical way to distinguish between the two variables. But again, I'm not at all tied to that if you can think of a more clear way to distinguish the variables.

But truly, please do whatever you prefer here. I don't think this specific case is worth arguing over further, and I'm really fine with whatever you decide. I don't want to hold this up any further, so please go ahead and make any changes you want to my branch (you should have permission to push to it) or after merging my branch into yours.