Considering migrating to Python from Visual Basic 6 for engineering applications

[Jussi Piitulainen]

BartC writes:

> But this is not so much to do with VB6, but with a very fundamental
> capability that seems missing in modern languages.

All that's missing is a minor convenience that turns out to be mainly
awkward. Not at all fundamental.

The capability of parsing simple input formats is easily composed of
more generally useful components that are available. As demonstrated in
this thread.

I get a bit carried away about input() below, but really, it's the
abstraction and composition of programs that is fundamental and
exciting, Python has *that*, and that makes it possible to define the
desired input parsers in a couple of lines. Simply.

> IIRC, the first programming exercise I ever did (in 1976 using Algol
> 60) involved reading 3 numbers from the teletype and working out if
> those could form sides of a triangle.

That was a lousy user interface even then - an inflexible user
interaction without even a possibility of handling errors interactively?
Command line arguments would have been better (if available, that is).

In Python, use the interactive loop instead (or command line arguments,
of course, or input(), and I think it's slightly simpler to use input()
three times than instruct the user about how to separate the three
numbers).

> It might have started off like this (I can't remember Algol 60):
>
>   print "Type 3 numbers:"
>   read a, b, c
>
> In Basic, that last line might be:
>
>   input a, b, c
>
> instead (reading here as floats probably).
>
> Now, nearly 40 years later, I don't actually know how to do that in
> Python! Sure, I can cobble something together, with all sorts of
> functions and string operations (and I would need to go and look them
> up). But it's not just /there/ already.

It seems you'd need to look them up in Algol 60 and Basic, too. Nothing
wrong with that.

You can ask for a line of input with input('>>> ') in Python 3. The
methods of parsing simple input formats, such as those in this thread,
with or without validation, are generally useful, composable, flexible,
and not at all difficult. You'll get far by line.split(), splitting at
any amount of whitespace by default (note that the .strip() in the
line.strip().split() that someone posted is redundant).

It's *good* to be able to cobble together a simple one-liner that does
what you want with fundamental, reusable components. Or a three-liner if
you *want* something more complex. Or a page of code to fake something
that is really AI-complete, if *that's* what you want. But mainly I mean
that the present problem is just trivial, and what do you do with the
Basic command if you have a slightly different input format - does it
scale at all? If there is extra text on the line before the numbers? If
the numbers are separated by commas, or semicolons?

> If you gave this a Python exercise to a class of students, you'd end
> up with 30 different solutions just for the first, easy part of the
> exercise! In fact it would be far more challenging than the triangle
> problem. That can't be right.

You mean those students who have never even started a program from a
command line? Whose first command-line interface ever is the Python
interactive loop in IDLE or some other such integrated environment where
they still don't learn to start a program from a command line? Those
students?

Well, why would they write code that asks for interactive input at all?
They can simply call their triangle-testing function in the Python
interactive loop and specify the integers as arguments:

>>> def istriangle(*threeintegers):
        a,b,c = sorted(threeintegers)
        return a*a + b*b == c*c

>>> istriangle(3,4,5)
True
>>> istriangle(3,1,4)
False

The development environment probably lets them send their code to the
interaction window from an editor window. Some might be able to learn
the advanced techniques required to import a program file into an
interactive session launched in a terminal window.

You insist on them asking for input anyway? How about telling them that
they can get a line of input (if they have some sort of console
available, I suppose) by calling, er, input, and the simplest way to
parse a string, call it s, as an integer is int(s)? (Tell them that if
they just guess that the input method might be called input they can get
their guess confirmed by trying help(input). Another useful skill.)

>>> def awkward():
        a = int(input('int> '))
        b = int(input('int> '))
        c = int(input('int> '))
        istriangle(a, b, c)
 
>>> awkward()
int> 3
int> 1
int> 4
>>> # oops

>>> def awkward():
        a = int(input('int> '))
        b = int(input('int> '))
        c = int(input('int> '))
        return istriangle(a, b, c)
 
>>> awkward()
int> 5
int> 4
int> 3
True
>>> 

Point out that it's a good idea to have a separate function to check for
triangularity of the triple of numbers: it'll be composable with other,
better sources of such triples (web form? command line arguments? random
numbers? loop over a million random triples and calculate the proportion
of triangles? database query?) and other consumers of such judgments
(like that proportion calculator), and its easy to write tests for it
(it's not easy to write automatic tests for functions that require
interaction). Point out that the input-prompting interface is lousy
(oops, wrong key, too late) and doing better is (1) far from trivial and
either (2) already available to them in the Python interactive loop or
(3) a number of separate topics.

And then there are all the common data sources and formats (CSV, JSON,
XML, ...) that change the game altogether. All the functions and
expression types used to parse the simple input lines in this thread are
still useful, but what use is that very special Basic input command now?
None whatsoever.