[Tutor] A required question

[Avi Gross]

Just to be different, and perhaps return to the purpose of this group, I have a question.

 

Is there some functionality available in Python that you could put in the beginning of a program so it aborts with a message if the version of R being run is not acceptable?

 

Let me elaborate. There seem to be new features added as you move up. I mean 2.2, 2.3, … 3.0 and so on.

 

But there also seem to be features deprecated then removed.

 

To make it crazier, some features are back-ported into later releases of 2.X while some features are activated only in you import the right things from __FUTURE__ .

 

Add to that the fact that various modules may exist or not exist on your machine in your search PATH and they may import yet others, and it gets crazy. Even weirder is that you can probably download a missing file as the program runs and then import it and probably many other scenarios where you own program writes a module and then imports it!

 

What I was thinking was the ability to do something like this:

 

import ReChoir as require

 

require.version(condition, before=True, after=False)

require.modules(module list, recursive=True)

require.os([“Eunuchs”, “Windblows”])

require.functionality(“print3”)

 

I hope you get the idea. Any one of the statements above might be made anywhere in your program but is best near the top of the main program perhaps after any imports from the dunder FUTURE.

 

I am not designing it. I am giving a very silly example and also suggesting a possible scenario like this:

 

if ! require( <<at least version 3.6>> ):

                print(“Sorry, your system is too primitive to use this snazzy software.”)

                print(“In a moment, you will be re-directed to a dumber version written”)

                print(“stone age tools. Please upgrade sooooooooon.”

                print(“running program paleo.py for you with same arguments.”

                sleep(5)

                exit( os.system(<<<“call to python to run paleo.py with same args using argv …”>>>) )

 

So in some cases, you quit with a message saying why you quit. In the example at the end, you may call alternate functionality, perhaps a shell-script rather than python, that does something for them. In an extreme case, the script would download a later version of Python as a sort of bootstrap. 😊

 

Yes, tons of holes in here and implementation details. For example, some features are only needed if the command line or data lead you down some path. No need to abort most of the time and not easy or even possible to see if you might need it.

 

So is there anything interesting out there already, designed to not so much make python portable, but to prevent things from running and then dying in middle of something important. 

 

Yes, I know there is an assert command you can use and there are system variables you can query to see what version of Python you are running on what OS and so on. No doubt there are tools you can use to see if everything imported exists (maybe not the right file) somewhere in the path. The latter alone is a huge issue as there have been changes in how you import including some really odd ones where they broke old functionality. 

 

There may come a day when 2.X is as extinct as polio (stubbornly hanging in there as some refuse to vaccinate) but I do not foresee the march of changes slowing in 3.x, let alone 4.x^2 and beyond.

 

Such a tool might make it easier for people to use new features with less fear.

 

One more thought. Such a function set might simply try new features inside a “try” and catch the error so they can gracefully annoy the user with a snide remark and even tell them what is missing. For example a line with a := in it should fail everywhere now but might work later. An f”string” is not that old. A line using open() in an iterator context would fail somewhere back in 2.x. In theory, you can make a list of testable new features and even give them names you can ask for such as the “print3” above.

 

Why do I ask? I had a great day today except it followed a horrible day yesterday. I did a bunch of work in R but the main point could just as easily happen in Python. I wanted various packages to do various things. Some had broken for me in the last year or so and been replaced with something that refused to work. In English, it was supposed to take a linear model generated from data and calculate some predicted info from it and make a nice graph with lines showing the impact of another variable at the mean and +/- a standard deviation. The problem is that I had the latest version of R installed but some of the many packages required were not yet available or their dependencies were either not available or of the wrong date. This happens with Python modules too. With lots of research, I loaded some things from alternate places and backed up to older versions and then forward and eventually had a brainstorm of figuring out what to feed the needed function so it worked. But a second problem remained with a different package I had tried, and a variant of the same problem in the current package for other functionality. The complaint was that the regression was expecting a vector at one point within a data.frame but say a one-dimensional matrix. Weird as I did not create it that way. Traced the problem to the rescaling function an fixed that by resetting it to a numeric vector afterward and suddenly all kinds of things worked. Then I had the usual other problem of saving data in yet another format and finding it hard to use package after package because it was not available for my version. Persistence worked, though.

 

And, yes, my next plan was to move into finding some similar functionality in Python. Why break when you can brake and after a break can bend and find a plan B?

 

This led to some of the above thoughts. Wouldn’t it be nice to state what must be there in front of a program and be sure it was before doing the rest?