Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[Gregory Ewing]

BartC wrote:
Our system must have been more advanced then, or designed for training. 
We used a time-sharing 'dec-system 10' and it was usually accessed via 
interactive terminals, either teletypes or the odd VDU.


According to Wikipedia the first interactive version of
Dartmouth BASIC appeared in 1964:

https://en.wikipedia.org/wiki/Dartmouth_BASIC

Also, the *very* earliest computer systems were all
interactive -- you sat in front of a panel flipping
switches and reading lights!

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[BartC]

On 22/02/2016 10:46, Steven D'Aprano wrote:

On Mon, 22 Feb 2016 08:52 am, Jussi Piitulainen wrote:


BartC writes:



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).


Jussi, I think you have an inflated expectation of what was available in
1976. Command line? What's that? Programs ran in batch mode,
and 'interactive' meant that you could easily slip out one punched card,
replace it with a different one, and run the program again.


Our system must have been more advanced then, or designed for training. 
We used a time-sharing 'dec-system 10' and it was usually accessed via 
interactive terminals, either teletypes or the odd VDU.


It still supported punched cards but that was more because they were 
still being used in the real world.


--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[Random832]

On Mon, Feb 22, 2016, at 05:46, Steven D'Aprano wrote:
> Jussi, I think you have an inflated expectation of what was available in
> 1976. Command line? What's that? Programs ran in batch mode,
> and 'interactive' meant that you could easily slip out one punched card,
> replace it with a different one, and run the program again.

User experience was hardly uniform across different systems in that era.
The book "Hackers", for example, describes an interactive computer that
was used at MIT in *1959*. More relevantly to the lineage of the systems
we use today, PDP-7 Unix was first developed in 1969 - and PDP-11 6th
Edition Unix, very close to a recognizable modern system, was released
in 1975.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[Chris Angelico]

On Mon, Feb 22, 2016 at 11:51 PM, BartC  wrote:
> Yes, I mentioned that point. In the OP's language, the variables can be
> declared as a particular type; in Python they could perhaps be 'declared' by
> first assigning with 0, 0.0 or "" for example. But that would need reference
> parameters to make use of tidily.

What you could do is something like this:

def read_values(file, values):
"""Read one line from file and parse it into the given list.

Prepopulate values with a series of types or instances of types.
The line of text read will be parsed accordingly.

Returns the number of elements successfully read.
"""
line = file.readline()
for idx, val in enumerate(values):
if not isinstance(val, type):
val = type(val)
# Now add the logic to read an int, a float,
# a str, a Fraction, etc etc etc, from the line,
# breaking out of the loop if one can't be
# read, and stashing the result into values[idx]
# if it can.
return idx

with open("inputfile") as f:
values = [int, int, float, Fraction, str]
while read_values(f, values) == 5:
[index, level, percent, ratio, message] = values


This lets you "declare" the values' types, and use an input/output
parameter. It's not exactly the most Pythonic of techniques, but it
does kinda work. I suspect, though, that what you'd _really_ want is
something more like a sscanf string, or a "typed regex", which would
allow you to specify a bit more flexibly what you're looking for. You
could easily make a template string that has magic markers for "take
an integer", which would insert [0-9]+ (or something more elaborate)
and then capture it and call int() on the string before returning it.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[BartC]

On 22/02/2016 11:16, Steven D'Aprano wrote:

On Mon, 22 Feb 2016 12:16 am, BartC wrote:

[...]

No need for anyone to re-invent the
wheel!  ;-)


I keep seeing this in the thread. Python has all this capability, yet it
still requires a lot of fiddly code to be added to get anywhere near as
simple as this:

read f, a, b, c


I can't say I really know what that means. My guess is that reads three
things (a, b and c) from a file f, but what those things are (strings,
binary blobs, floats, ints, something else?) is a mystery.


Yes, I mentioned that point. In the OP's language, the variables can be 
declared as a particular type; in Python they could perhaps be 
'declared' by first assigning with 0, 0.0 or "" for example. But that 
would need reference parameters to make use of tidily.


But even when declared, sometimes additional formatting info is needed 
(numbers might be in hex or binary for example).



One of the major problems with output parameters is that it isn't obvious
what is an output parameter and what isn't. When it comes to read, perhaps
you can guess, but when it comes to arbitrary functions, who can tell what
is output and what is input?

fromaginate m, x, y, z, a, b


Whereas a functional design makes it obvious: output is on the left of the
assignment symbol, input is on the right.

x, y, z = fromaginate m, a, b


Old-style /statements/ such as 'read' aren't functional. Then it is easy 
to specify that the parameters need to be l-values.



readline(f, a, b, c)

I can't see a straightforward way of making this possible while still
keeping a, b and c simple integer, float or string types (because
Python's reference parameters don't work quite the right way).


Python doesn't have reference parameters.

Please feel free to discuss further if you disagree, or want additional
explanation.


Well, I've just finished reimplementing a language so that it uses 
CPython-like references for objects (not, however, for types such as 
small integers which stay as value types).


But that language retains the use of pointers which can be used /as well 
as/ references to provide pass-by-reference, even for integers.


Then it is possible to write a function which can be called like: 
readline(f,a,b,c) and which would update the caller's a,b,c variables.


Python can't do this, even with 100% reference objects. This is because 
most types are immutable and their values can be shared across unrelated 
variables. Try and change one of those, and all would be changed!


In any case, doing an assignment to a parameter just replaces its local 
value. Caller's data can only be changed via an in-place modification of 
the parameter, which I believe only works for lists.


(Maybe, something like this can be done with classes, but I did say you 
can't do it with simple types.)


--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[BartC]

On 22/02/2016 08:50, Jussi Piitulainen wrote:

BartC writes:



Reading stuff from an interactive console or terminal, is such an
important part of the history of computing, still being used now, that
you'd think a language would provide simple, ready-to-use methods ways
to do it.


I think it does. Do you at least agree that it provides a reasonably
simple way to ask for a single line of text?

stuff = input()

Is that already too obscure or advanced for you? Because surely not?


That's a good starting point. It reads an entire line of text, as a 
string. So that's part of the job done. The rest of it needs some string 
processing.


But even 'input' has some issues. While it seemed to work, the docs I 
looked at suggested it interpreted the input as an expression, and I 
needed to use raw_input().


Was this a Python 2/3 problem? The docs I used 
(https://en.wikibooks.org/wiki/Python_Programming/Input_and_Output) 
didn't appear to mention that, not in the title or around the edges 
anyway! Eventually I saw that as a italicised note within the text.


So, it's input() on 3.x and raw_input() on 2.x.

But another thing is that it doesn't scale up to read from a file, as 
far as I can see. File reading is rather different, and it behaves 
differently regarding line endings.


(For comparison, here's how it works on another language I use:

 readln a,b,c

This waits for a line of input (it becomes the read buffer), then reads 
three integers from the buffer.


 read d,e

This reads two more integers from that buffer (if there is no more data, 
it reads zeros).


 readln @f,a,b,c

This does the same, from file handle f.

The equivalent of Python's input() might be:

 s := sreadln()# from console
 s := sreadln(f)   # from a file
 s := sreadln("10,20") # from a string

but the entire line is also placed into the read buffer so that 
subsequent read commands (or sread() function calls) can read individual 
values as before.


Reading anything other than integers is bit more fiddly (you can't have 
everything!) So that means using something like this:


 read a:"r", b:"h", c:"s", d:"n"

So reading as a float, an int using hexadecimal, a string (delimited by 
white space or punctuation, or quoted), a name (file names etc), and so on.


There are limitations, but this stuff is there when I don't need 
anything more sophisticated.)


--
Bartc


--
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[Jussi Piitulainen]

Steven D'Aprano writes:

> On Mon, 22 Feb 2016 08:52 am, Jussi Piitulainen wrote:
>
>> BartC writes:
>
>>> 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).
>
> Jussi, I think you have an inflated expectation of what was available
> in 1976. Command line? What's that? Programs ran in batch mode, and
> 'interactive' meant that you could easily slip out one punched card,
> replace it with a different one, and run the program again.

You are probably right. I was thinking ten years off. Sorry.

But if that's how one worked a teletype, then it sounds similar to
command line arguments to me. Or to a configuration file that the
program then when run. Not the interaction-prompting interface that I
was thinking of when I called it lousy.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[Steven D'Aprano]

On Mon, 22 Feb 2016 12:16 am, BartC wrote:

[...]
>> No need for anyone to re-invent the
>> wheel!  ;-)
> 
> I keep seeing this in the thread. Python has all this capability, yet it
> still requires a lot of fiddly code to be added to get anywhere near as
> simple as this:
> 
>read f, a, b, c

I can't say I really know what that means. My guess is that reads three
things (a, b and c) from a file f, but what those things are (strings,
binary blobs, floats, ints, something else?) is a mystery.

One of the major problems with output parameters is that it isn't obvious
what is an output parameter and what isn't. When it comes to read, perhaps
you can guess, but when it comes to arbitrary functions, who can tell what
is output and what is input?

fromaginate m, x, y, z, a, b


Whereas a functional design makes it obvious: output is on the left of the
assignment symbol, input is on the right.

x, y, z = fromaginate m, a, b



> And this is code that is not going to be obvious to anyone starting out.
> Even accepting that syntax limitations might require this to be written
> as:
> 
>readline(f, a, b, c)
> 
> I can't see a straightforward way of making this possible while still
> keeping a, b and c simple integer, float or string types (because
> Python's reference parameters don't work quite the right way).

Python doesn't have reference parameters.

Please feel free to discuss further if you disagree, or want additional
explanation.


> (There is also the question of 'readline' knowing what types of values
> to read. This information would not be needed in Fortran or Basic but
> somehow needs to be supplied here, if a particular set of types is to
> imposed on the input.)
> 
> In other words, it seems this particular wheel does require re-inventing!

Hmmm, well, yes, I think perhaps it is fair to say that there is middle
ground where Python misses out.

Python's raw IO is quite powerful, and it can handle unstructured binary of
text files with no difficulty.

It also comes with libraries for certain common file formats, like CSV, XML,
JSON and others.

But there's a middle ground, of *minimally structured* text files, where
Python leaves it up to you. Admittedly it's not difficult, any minimally
competent Python programmer should be able to read a bunch of ints or
floats from a text file without working up a sweat, but beginners may find
this tricky.

So I think you are right: there is a narrow, but useful, niche of
semi-structured textual data that BASIC and VB support that Python doesn't
support out of the box.


-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[Steven D'Aprano]

On Mon, 22 Feb 2016 08:52 am, Jussi Piitulainen wrote:

> BartC writes:

>> 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).

Jussi, I think you have an inflated expectation of what was available in
1976. Command line? What's that? Programs ran in batch mode,
and 'interactive' meant that you could easily slip out one punched card,
replace it with a different one, and run the program again.



-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[Jussi Piitulainen]

BartC writes:

> On 21/02/2016 21:52, Jussi Piitulainen wrote:

[...]

> def istriangle(*threeintegers):
>>  a,b,c = sorted(threeintegers)
>>  return a*a + b*b == c*c
>
> (That detects right-angled triangles. I think 'return a+b>c' is the
> correct test for any triangle. It becomes trivial when you have sort
> available, but that's part of the point of the exercise.)

Sorry about that. (Non-positive sides should also be ruled out.)

[...]

> Reading stuff from an interactive console or terminal, is such an
> important part of the history of computing, still being used now, that
> you'd think a language would provide simple, ready-to-use methods ways
> to do it.

I think it does. Do you at least agree that it provides a reasonably
simple way to ask for a single line of text?

stuff = input()

Is that already too obscure or advanced for you? Because surely not?

It can be used piecemeal:

print("a b c = ")
stuff = input()
parts = stuff.split()
a = int(parts[0])
b = int(parts[1])
c = int(parts[2])

The same can be done in one statement:

a, b, c = map(int, input("a b c = ").split())

Here's a simpler user interface:

a = int(input("a = "))
b = int(input("b = "))
c = int(input("c = "))

These building blocks can be used to define more complex dialogues in
obvious ways, probably using exception handling.

def please(*types, *, prompt = None):
"""Repeatedly prompts the console user for space-separated values in
one line until an input line matches the given types. Returns the
corresponding values. At end of input, raises UpsetException."""
...

a, b, c = please(int, int, int, prompt = "a b c = ")

def readWithDWIM(source, *types):
"""Reads and returns whitespace-separated values from text source.
Parses each as the corresponding type by calling the type on it. For
invalid or missing values, substitutes the value of calling the type
without arguments, or None if even that fails. May or may not
discard the remaining part of the line that contained the last
value. Use at your own risk!"""
...

from itertools import repeat
with open("f.txt" as f:
a, b, c = readWithDWIM(f, int, int, int))
xs = readWithDWIM(f, *repeat(float, b))

If there really is demand for these, they should be all over the web
already. I don't see why there should be demand. The simple case is
simple enough, more complex specifications are either still simple
enough to write from scratch, or too specific, or insane.

[...]
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[Denis Akhiyarov]

Note that you can continue using your existing vb6 code from python through COM 
using pywin32 or pythonnet, until you decide to rewrite it.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[BartC]

On 21/02/2016 21:52, Jussi Piitulainen wrote:

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.


It /is/ fundamental because it mimics how humans interact:

"Give me 3 numbers:"

"OK: ten, twenty and twenty-nine."

"Yeah, they'd make a triangle."


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


Yes, by having a box of parts you first have to figure out how to put 
together!



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).


The big deal about that kind of interface was it that it /was/ 
interactive (compared with batch processing or job control or whatever. 
I remember using punched cards; those certainly weren't).


Command line arguments are not interactive. If the name of the program 
is Triangle, and someone types:


>Triangle

the probably nothing happens. Or it generates an error message. Or it 
appears to hang.



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).


Basics also used to use interactive loops. Separating the numbers I 
don't think has ever been a big problem. Obviously you can't type ten, 
twenty and thirty as 102030, but will need to use white-space or 
punctuation. It doesn't take long to figure out! (And how do you 
separate command-line arguments? Have you even thought about it?)



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.


Yes, and it would say use 'readln' or 'input' or whatever. In Python, 
I'd get two-inch-thick manual full of library functions and modules I 
can use to /implement/ 'readln' or 'input'!



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.


But this is advanced stuff for a beginner. (I'm not a beginner and it's 
advanced for /me/! Well, more of a nuisance when I want to quickly do X 
but first need to figure out Y, some input routine.)


 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?


I don't know the details of how Basic does it. But it seems to allow any 
reasonable separator, while asking for more input than is provided on 
the line sets those extra variables to 0 or "".



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!



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


(That detects right-angled triangles. I think 'return a+b>c' is the 
correct test for any triangle. It becomes trivial when you have sort 
available, but that's part of the point of the exercise.)



istriangle(3,4,5)

True

istriangle(3,1,4)

False


Yes, this is a good next step, to separate the logic from the job of 
acquiring the data (and to learn about with subroutines or functions).


But this way, you're putting off the job of requesting interactive data 
from a user. If A is the chap writing the program and using the tools, 
he might want B to be the one running the program and entering the data. 
B won't be running the interactive loop; he won't even know what 
language it's in. (And the OP wants B to run an EXE.)



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 

Re: 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 

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[Tim Chase]

On 2016-02-21 13:16, BartC wrote:
> > No need for anyone to re-invent the
> > wheel!  ;-)
> 
> I keep seeing this in the thread. Python has all this capability,
> yet it still requires a lot of fiddly code to be added to get
> anywhere near as simple as this:
> 
>read f, a, b, c
> 
> And this is code that is not going to be obvious to anyone starting
> out. Even accepting that syntax limitations might require this to
> be written as:
> 
>readline(f, a, b, c)

Well, if you know what the line is going to contain, that can be
written as

  a, b, c = f.readline().split()

> I can't see a straightforward way of making this possible while
> still keeping a, b and c simple integer, float or string types
> (because Python's reference parameters don't work quite the right
> way).

However, that does give you byte-strings since that's what comes out
of files.  If you know they're ints, you can force that:

  a, b, c = map(int, f.readline().split())

> (There is also the question of 'readline' knowing what types of
> values to read. This information would not be needed in Fortran or
> Basic but somehow needs to be supplied here, if a particular set of
> types is to imposed on the input.)
> 
> In other words, it seems this particular wheel does require
> re-inventing!

In both Fortran & BASIC, you specify that information somewhere as
well.  However, it sounds like you define those at the
variable-definition level (it's been over a decade since I done any
BASIC and far longer since I've even touched any Fortran, so forgive
me if I'm a tad rusty) instead of where its read from the file.

-tkc






-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[BartC]

On 21/02/2016 15:08, Jussi Piitulainen wrote:

BartC writes:



In other words, it seems this particular wheel does require
re-inventing!


It's hardly Python's problem if an engineer is worried about some VB not
being there in its current form in the future. The sample code upthread
seemed gibberish to me


I don't know VB6 but:

 Open "N020S.TXT" For Input As #8

 Input #8, ND, NIN, NT ' all integers

seems clear enough: read 3 integers from the text file just opened on 
channel 8, and store them in variables ND, NIN and NT.


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


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. 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.


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.


--
Bartc


--
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[Christian Gollwitzer]

Am 21.02.16 um 14:16 schrieb BartC:

Even accepting that syntax limitations might require this to be written as:

   readline(f, a, b, c)

I can't see a straightforward way of making this possible while still
keeping a, b and c simple integer, float or string types (because
Python's reference parameters don't work quite the right way).

(There is also the question of 'readline' knowing what types of values
to read. This information would not be needed in Fortran or Basic but
somehow needs to be supplied here, if a particular set of types is to
imposed on the input.)


Are you sure that in Basic or Fortran the expected type is not supplied? 
I'm not too familiar with either, but I think that in Fortran the 
compiler deduces it from the (compile-time) static type of the variable, 
while in BASIC there used to be sigils (A$, A# etc.) to denote the type. 
A pythonic input function would look like this IMHO:


a,b,c = readline(f, int, float, str)


In other words, it seems this particular wheel does require re-inventing!


Yes, but the above seems quite trivial:

Apfelkiste:Tests chris$ cat parseline.py
def readline(f, *args):
line=f.readline().split()
return [type(x) for type,x in zip(args,line)]

with open("mydata.dat", "r") as f:
ND, NINT, NT=readline(f, int, int, int)
# next line holds NINT floats
dincol=readline(f, *NINT*[float])
# next line holds a string
text=f.readline()

print("Read: ", ND, NINT, NT)
print(dincol)
print(text)

Apfelkiste:Tests chris$ cat mydata.dat
 106 1
8.65  0.2192347   3.33E-444 0.00516
String
Apfelkiste:Tests chris$ python parseline.py
('Read: ', 10, 6, 1)
[8.65, 0.2192347, 0.000333, 44.0, 0.0051, 6.0]
String

Apfelkiste:Tests chris$

Christian

--
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[Jussi Piitulainen]

BartC writes:

> On 21/02/2016 07:28, Larry Hudson wrote:
>> On 02/20/2016 10:38 AM, wrong.addres...@gmail.com wrote:
>
>>> Or can I write my own reading subroutines which can then be called like
>>> ReadVBstyle 8, ND, NIN, NT
>>> to make the code more readable?
>
>> ABSOLUTELY!!  Most Python programming consists of defining the functions
>> and classes needed, which definitely makes Python more readable.
>
>> No need for anyone to re-invent the
>> wheel!  ;-)
>
> I keep seeing this in the thread. Python has all this capability, yet
> it still requires a lot of fiddly code to be added to get anywhere
> near as simple as this:
>
>   read f, a, b, c
>
> And this is code that is not going to be obvious to anyone starting
> out. Even accepting that syntax limitations might require this to be
> written as:
>
>   readline(f, a, b, c)
>
> I can't see a straightforward way of making this possible while still
> keeping a, b and c simple integer, float or string types (because
> Python's reference parameters don't work quite the right way).
>
> (There is also the question of 'readline' knowing what types of values
> to read. This information would not be needed in Fortran or Basic but
> somehow needs to be supplied here, if a particular set of types is to
> imposed on the input.)
>
> In other words, it seems this particular wheel does require
> re-inventing!

It's hardly Python's problem if an engineer is worried about some VB not
being there in its current form in the future. The sample code upthread
seemed gibberish to me - anybody capable of learning *that* should be
*able* to also learn Python, and then the input parsing business is not
only simple but also flexible, as already demonstrated by others. The
following assumes that the author of the code knows the desired types,
and does not assume a working DWIM feature. I wouldn't name things quite
like that in real code.

from io import StringIO

def funcall(f, x):
return f(x)

def Input(source, *dims):
return tuple(map(funcall, dims, next(source).split()))

def Vector(dim, times):
return tuple([dim] * times)

N020SdotTXT = ''' 106 1 
8.65  0.2192347   3.33E-444 0.00516 
9 
 1 
2 1 
 3 '''

Number8 = StringIO(N020SdotTXT)

ND, NIN, NT = Input(Number8, int, int, int)
DINCOL = Input(Number8, *Vector(float, NIN))
[NINE] = Input(Number8, int)
[ONE] = Input(Number8, float)
TWO = Input(Number8, float, int)
[THREE] = Input(Number8, str)

Hash = dict

print('ND = {}, NIN = {}, NT = {}'.format(ND, NIN, NT),
  DINCOL,
  Hash(NINE = NINE, ONE = ONE, TWO = TWO, THREE = THREE),
  sep = '\n')

# Output:
# ND = 10, NIN = 6, NT = 1
# (8.65, 0.2192347, 0.000333, 44.0, 0.0051, 6.0)
# {'NINE': 9, 'TWO': (2.0, 1), 'ONE': 1.0, 'THREE': '3'}

/s
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[Chris Angelico]

On Mon, Feb 22, 2016 at 12:16 AM, BartC  wrote:
> On 21/02/2016 07:28, Larry Hudson wrote:
>>
>> On 02/20/2016 10:38 AM, wrong.addres...@gmail.com wrote:
>
>
>>> Or can I write my own reading subroutines which can then be called like
>>> ReadVBstyle 8, ND, NIN, NT
>>> to make the code more readable?
>
>
>> ABSOLUTELY!!  Most Python programming consists of defining the functions
>> and classes needed, which definitely makes Python more readable.
>
>
>> No need for anyone to re-invent the
>> wheel!  ;-)
>
>
> I keep seeing this in the thread. Python has all this capability, yet it
> still requires a lot of fiddly code to be added to get anywhere near as
> simple as this:
>
>   read f, a, b, c
>
> And this is code that is not going to be obvious to anyone starting out.
> Even accepting that syntax limitations might require this to be written as:
>
>   readline(f, a, b, c)
>
> I can't see a straightforward way of making this possible while still
> keeping a, b and c simple integer, float or string types (because Python's
> reference parameters don't work quite the right way).

How about:

a, b, c = readline(f)

> (There is also the question of 'readline' knowing what types of values to
> read. This information would not be needed in Fortran or Basic but somehow
> needs to be supplied here, if a particular set of types is to imposed on the
> input.)

You'd still need to solve that, one way or another. But the Pythonic
way is to distinguish between "input" and "output" parameters by
having the input parameters as parameters, and the output parameters
as the return value. And personally, I find it *way* more readable
that way; while it's perfectly possible to pass a list as a parameter
and have the function append to it, it's much clearer if your return
values are on the left of the equals sign.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[BartC]

On 21/02/2016 07:28, Larry Hudson wrote:

On 02/20/2016 10:38 AM, wrong.addres...@gmail.com wrote:



Or can I write my own reading subroutines which can then be called like
ReadVBstyle 8, ND, NIN, NT
to make the code more readable?



ABSOLUTELY!!  Most Python programming consists of defining the functions
and classes needed, which definitely makes Python more readable.



No need for anyone to re-invent the
wheel!  ;-)


I keep seeing this in the thread. Python has all this capability, yet it 
still requires a lot of fiddly code to be added to get anywhere near as 
simple as this:


  read f, a, b, c

And this is code that is not going to be obvious to anyone starting out. 
Even accepting that syntax limitations might require this to be written as:


  readline(f, a, b, c)

I can't see a straightforward way of making this possible while still 
keeping a, b and c simple integer, float or string types (because 
Python's reference parameters don't work quite the right way).


(There is also the question of 'readline' knowing what types of values 
to read. This information would not be needed in Fortran or Basic but 
somehow needs to be supplied here, if a particular set of types is to 
imposed on the input.)


In other words, it seems this particular wheel does require re-inventing!

--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[Larry Hudson via Python-list]

On 02/20/2016 10:38 AM, wrong.addres...@gmail.com wrote:
[snip]

How complicated could this get in Python? Reading the numbers is one thing, and 
then placing the values in text boxes of the GUI.


If that is the only object of using these values, there is no conversions necessary.  The data 
is read as text (strings), and you could simply write them directly into the text boxes.  Of 
course, this is unlikely -- you surely want the actual numeric values for other purposes.  As 
already pointed out, if you know in advance what the data types are, the necessary conversions 
are trivial.  Just slightly more complex if you don't know the types in advance.


OTOH, the conversion from int or float back to strings is also trivial.  It's as simple as 
writing str(n), where n is an int OR a float -- it works automatically with either.  (Data 
typing in Python is dynamic, you generally don't need to specify the types.)  But if you want 
the strings to be in a specific format, this is also possible with a different syntax that lets 
you specify the output format.  As an example, assume the variable val is 1.97834, and the 
formatting string is "${:.2f}".format(val) -- this will give you the string '$1.98'.  This 
expression breaks down to:

$   ->  a literal dollar sign
{}  ->  a placeholder, it is where the formatted data will be put
:   ->  what follows is formatting code
.2  ->  round to, and print, two decimal places
f   ->  the data is a float
.format(val)  ->  the data to format

BTW, this leaves the variable val unchanged -- it is NOT rounded, it still holds its original 
precision.  It only affects how it is displayed.  You CAN round it if you want, but that's an 
entirely different function.


Naturally, learning all the formatting codes takes some effort, but it allows defining the 
appearance of the resulting strings in a very detailed and complete manner.  [Aside:  this is 
the "new" formatting method.  Python also supports an "old" method, which is very much like the 
way strings are formatted in the C language.]



Or can I write my own reading subroutines which can then be called like
ReadVBstyle 8, ND, NIN, NT
to make the code more readable?


ABSOLUTELY!!  Most Python programming consists of defining the functions and classes needed, 
which definitely makes Python more readable.  (Classes imply Object Oriented Programming. 
Python _allows_ OOP but does not _require_ it -- and is irrelevant here.  Ignore anything I say 
about classes and OOP!)  For your example here, it wouldn't _match_ the BASIC syntax, but would 
be used in an equivalent way.


In fact, if you find yourself writing functions (or classes) that could be general-purpose 
routines, it is a trivial matter to put them into a personal library which you can then use in 
future programs.  You don't need to rewrite them, just use them.


Now, in practice, it takes a little care to write them as library functions.  That is, the 
original version may rely on some details of the original program, so the library version will 
need to be tweaked a bit to remove these 'local' dependencies.  But this is generally easily 
handled through the parameters to the functions.  Also they are probably written with a bit more 
care to handle error conditions (which Python calls exceptions, Python has very extensive 
exception handling).  This capability (a personal library) is enormously convenient.  While I am 
saying 'personal', I really mean library(s) available to everyone involved in a programming 
project.  No need for anyone to re-invent the wheel!  ;-)Python calls them modules rather 
than libraries, but it's the same thing.


 -=- Larry -=-

--
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[Mike S via Python-list]

On 2/19/2016 8:58 PM, Denis Akhiyarov wrote:

On Wednesday, February 17, 2016 at 1:49:44 PM UTC-6, wrong.a...@gmail.com wrote:

I am mostly getting positive feedback for Python.

It seems Python is used more for web based applications. Is it equally fine for 
creating stand-alone *.exe's? Can the same code be compiled to run on Linux or 
Android or web-based?

Is it possible to create GUI elements with a good IDE? Can they be defined like 
in Visual Basic with given sizes, fonts, visible/invisible, etc.?

Is it easy to do matrix operations in Python? Or do I need to write subroutines 
like in Visual Basic?

Could someone kindly tell me advantages and disadvantages of Python? Or any 
better options? I have like 40-50 VB Forms and may be around 2 lines of 
code. It will be a task to learn a new language and translate/re-write that 
code.

Thanks for your responses.


I'm surprised that no one mentioned this tool called vb2py.
> It looks outdated, but I actually used it successfully to convert vba 
code to python,> once all dependencies were installed correctly :)

http://vb2py.sourceforge.net/
You can also understand how vb objects map to python objects.
vb2py has also minimal support for GUI conversion.
Someone has even forked it on github recently:
https://github.com/reingart/vb2py


Thanks! I have a lot of VB6 and VB.NET code and I'm learning Python 
thinking about doing machine learning, this might come in handy for 
other programs!

--
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[Roel Schroeven]

wrong.addres...@gmail.com schreef op 2016-02-19 11:47:

Thanks. The data I will often have to read from text files could read like

2 12.657823 0.1823467E-04 114 0
3 4 5 9 11
"Lower"
278.15

Is it straightforward to read this, or does one have to read one character at a 
time and then figure out what the numbers are?


The question is: what is known about the format of the data? Is it 
fixed, or does the code need to be smart enough to be able to deal with 
varying formats?


If we can assume that there are 4 lines, of which the first line 
contains floating point numbers, the second contains integers, the third 
contains one string and the fourth contains one floating point number, 
it's pretty easy. For example:


def readinput(filename):
with open(filename, 'rt') as f:
lines = f.readlines()
line0 = [float(part) for part in lines[0].split()]
line1 = [int(part) for part in lines[1].split()]
line2 = lines[2].strip()[1:-1]
line3 = float(lines[3])
return line0, line1, line2, line3

line0, line1, line2, line3 = readinput('input.txt')
print(line0)
print(line1)
print(line2)
print(line3)

Output:

[2.0, 12.657823, 1.823467e-05, 114.0, 0.0]
[3, 4, 5, 9, 11]
Lower
278.15

This basically splits the two first line by whitespace, then converts 
each part (or the whole line in case of the last two lines) into the 
desired data type.


--
The saddest aspect of life right now is that science gathers knowledge
faster than society gathers wisdom.
  -- Isaac Asimov

Roel Schroeven

--
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[Christian Gollwitzer]

Am 20.02.16 um 19:45 schrieb wrong.addres...@gmail.com:

On Saturday, 20 February 2016 09:54:15 UTC+2, Steven D'Aprano  wrote:

To answer your question "Do I need something fancy...?", no, of course not,
reading a line of numbers from a text file is easy.

with open("numbers.txt", "r") as f:
 for line in f:
 numbers = [int(s) for s in split(line)]



This looks good enough. This does not seem complicated (although I still 
understand almost nothing of what is written). I was simply not expressing 
myself in a way you people would understand.



will read and convert integer-valued numbers separated by whitespace like:

 123 654 9374 1 -45 3625


one line at a time. You can then collate them for later use, or process them
as you go. If they're floating point numbers, change the call to int() to a
call to float().



And I guess if the first three numbers are integers and the fourth is a float, 
then also there must be some equally straightforward way.


If you know in advance, what you expect, then it is easy. Most people 
who gave you answers assumed that you have a messy file and don't know 
if an int or float follows, and you want a program which decides by 
itself whether to read an int, float or string.


Whereas, if the format is fixed, for 3 ints and 1 float, you could do:

str='1 2 3 3.14159' # some example
fmt=(int,int,int,float) # define format
a,b,c,d=[type(x) for (type,x) in zip(fmt, str.split())]

It's one line, but it might look involved and actually it uses a list 
comprehension, tuple unpacking and first class functions, so it's 
certainly not comprehensible from the first Python lesson. Another 
alternative would be sscanf. This is a 3rd party module which simulates 
C sscanf, optimized more or less for this kind of number parsing:


https://hkn.eecs.berkeley.edu/~dyoo/python/scanf/

After installing that, you can do:

from scanf import sscanf
str='1 2 3 3.14159'
a,b,c,d=sscanf(str, '%d %d %d %f')

whereby '%d' means integer and '%f' is float. sscanf also handles 
fixed-width columns which you often get from Fortran programs.


Christian


--
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[wrong . address . 1]

On Saturday, 20 February 2016 06:58:39 UTC+2, Denis Akhiyarov  wrote:
> On Wednesday, February 17, 2016 at 1:49:44 PM UTC-6, wrong.a...@gmail.com 
> wrote:
> > I am mostly getting positive feedback for Python.
> > 
> > It seems Python is used more for web based applications. Is it equally fine 
> > for creating stand-alone *.exe's? Can the same code be compiled to run on 
> > Linux or Android or web-based?
> > 
> > Is it possible to create GUI elements with a good IDE? Can they be defined 
> > like in Visual Basic with given sizes, fonts, visible/invisible, etc.?
> > 
> > Is it easy to do matrix operations in Python? Or do I need to write 
> > subroutines like in Visual Basic?
> > 
> > Could someone kindly tell me advantages and disadvantages of Python? Or any 
> > better options? I have like 40-50 VB Forms and may be around 2 lines of 
> > code. It will be a task to learn a new language and translate/re-write that 
> > code.
> > 
> > Thanks for your responses.
> 
> I'm surprised that no one mentioned this tool called vb2py. It looks 
> outdated, but I actually used it successfully to convert vba code to python, 
> once all dependencies were installed correctly :)
> 
> http://vb2py.sourceforge.net/
> 
> You can also understand how vb objects map to python objects.
> 
> vb2py has also minimal support for GUI conversion.
> 
> Someone has even forked it on github recently:
> 
> https://github.com/reingart/vb2py

This will definitely be useful to me in the early phase.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[wrong . address . 1]

On Saturday, 20 February 2016 09:54:15 UTC+2, Steven D'Aprano  wrote:
> On Fri, 19 Feb 2016 10:53 pm, wrong.addres...@gmail.com wrote:
> 
> >> See http://nedbatchelder.com/text/python-parsers.html for a list of
> >> parsers that can do all sorts for you.  Or the stdlib re module
> > 
> > I am an engineer, and do not understand most of the terminology used
> > there. 
> 
> Google, or the search engine of your choice, is your friend.
> 
> https://duckduckgo.com/html/
> 
> https://startpage.com/eng/?
> 
> 
> Wikipedia even more so: Wikipedia has lots of good, useful articles on
> computing concepts.
> 
> https://en.wikipedia.org/wiki/Category:Computing
> 
> And use the search box visible at the top of every page.
> 
> Or ask here.
> 
> 
> 
> > And do I need something fancy to read a line of numbers? Should it 
> > not be built into the language?
> 
> In your own words:
> 
> "I will have to read data given to me by people, which may not come in nice
> formats like CSV"
> 
> I trust that you don't expect the language to come with pre-written
> functions to read numbers in every imaginable format. If you do, you will
> be disappointed -- no language could possible do this.
> 
> To answer your question "Do I need something fancy...?", no, of course not,
> reading a line of numbers from a text file is easy.
> 
> with open("numbers.txt", "r") as f:
> for line in f:
> numbers = [int(s) for s in split(line)]
> 

This looks good enough. This does not seem complicated (although I still 
understand almost nothing of what is written). I was simply not expressing 
myself in a way you people would understand.

> 
> will read and convert integer-valued numbers separated by whitespace like:
> 
> 123 654 9374 1 -45 3625
> 
> 
> one line at a time. You can then collate them for later use, or process them
> as you go. If they're floating point numbers, change the call to int() to a
> call to float().
> 

And I guess if the first three numbers are integers and the fourth is a float, 
then also there must be some equally straightforward way.

Thanks for this explanation, which changes my view about reading numbers in 
Python.

> 
> 
> 
> 
> 
> -- 
> Steven
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[wrong . address . 1]

On Saturday, 20 February 2016 18:23:26 UTC+2, nholtz  wrote:
> On Wednesday, February 17, 2016 at 2:49:44 PM UTC-5, wrong.a...@gmail.com 
> wrote:
> > I am mostly getting positive feedback for Python.
> > ...
> 
> I'm surprised no one has mentioned jupyter yet, so here goes ...
> 
> A browser-based notebook, see http://www.jupyter.org
> 
> I think this is an unparalleled way to learn Python, by experimentation at 
> the start and for development later.  As an example, I wanted to do some table
> processing, so a couple of lines to experiment with Pandas reading CSV files, 
> then a couple of more lines to start processing the data ... What a wonderful 
> way to experimentally develop software ...
> 
> Can even develop simple GUIs *really* easily (but packaging for distribution 
> is probably not easy, unless distribution is only within an organization and 
> that organization can run a private notebook server).
> 
> If you want to try it, this page
> 
> http://jupyter.readthedocs.org/en/latest/install.html
> 
> recommends installing Anaconda Python which installs a *lot* of stuff (numpy, 
> scipy, sympy, pandas, etc. etc.)
> 
> I highly recommend both (I use them for Civil Engineering (structures) 
> software and teach a related university course)

Thanks. This gives me some more confidence that it will be a good choice for my 
work as well.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[wrong . address . 1]

On Saturday, 20 February 2016 09:49:17 UTC+2, Larry Hudson  wrote:
> On 02/19/2016 10:14 AM, wrong.addres...@gmail.com wrote:
> [snip]
> >
> > This is precisely reading one character at a time. If not exactly reading 
> > one character, it is effectively looking at each character to assemble the 
> > number. Not a good sign. I guess there might be libraries which will help 
> > read numbers better, but I would expect a good language to be able to 
> > handle this basic thing for engineers - to read numbers like Fortran and 
> > Basic do.
> >
> > Still, if I have misunderstood something, I will be glad to be corrected. I 
> > would generally know that the first three numbers will be floating point, 
> > the next will be something and then the next will be something else, etc. 
> > Does that help or does one still have to look at each character and 
> > determine how to place it in a number?
> >
> > Thanks for your patience. I don't want surprises later on, which is why I 
> > am asking very stupid questions.
> >
> It absolutely does NOT require reading a character at a time!  You are 
> reading the data from a 
> text file, which means everything is a string.  These strings (or 
> sub-strings) can represent 
> integers, floats, dates, phone numbers or whatever.  Your example data 
> implies a free-form 
> style, where it is then necessary to determine the data type for each of 
> these (sub)strings 
> individually.  Of course, if your data has a defined fixed format, this is 
> simplified -- but 
> they are still initially strings that have to be converted.  String 
> processing in Python is very 
> powerful and versatile.
> 
> BTW, it does no good to continue to think strictly in BASIC techniques.  
> Python is a different 
> language with a different approach to attacking problems.  If you try to 
> write BASIC (or C or 
> Java or ...) programs in Python syntax you'll just get bad programs.  Forget 
> trying to find 
> features in Python that are identical to the features of BASIC.  Python 
> requires a different 
> mind-set to use it properly -- just like any other language.
> 
> Here is a rather naive somewhat brute-force way to read your example data.  
> I'm using a Python 
> list here to simulate the file reading.  (Actually, using read() instead of 
> readline() will also 
> give this list.)  Python lists are essentially the same as arrays in other 
> languages, but much 
> more powerful and versatile.  Two examples of the differences between arrays 
> and lists are:  can 
> use mixed data types, you are not restricted to all the same data type, and 
> the size of lists 
> are dynamic -- they grow or shrink as necessary.
> 
> Comments start with a #
> Strings in Python can be delimited by single-quotes ('), double-quotes (") or 
> triple-quotes (""" 
> or ''').  Triple-quoted strings can be multi-line text.  The triple-quote 
> here is used as what 
> Python calls a docstring, which it saves internally for documenting your 
> program.
> 
> 
> #   Define a function to determine the data type a string represents
> def chktyp(s):
>  """Check string s for int, float or string.  Returns the data and a type 
> code"""
>  try:
>  return int(s), 'int'  #  Try to convert to int, return it if 
> successful
>  except ValueError:#  No, it's not an int
>  pass  #  Drop into float test
>  try:
>  return float(s), 'float'  #  Try to convert to float, return it if 
> successful
>  except ValueError:#  No, it's not a float
>  return s, 'str'   #  It must be a string
> 
> #   Here is your (simulated) data as a list of strings
> data = [
>  '2 12.657823 0.1823467E-04 114 0',
>  '3 4 5 9 11',
>  '"Lower"',#  Could be left simply as "Lower"
>  '278.15']
> 
> #   Process the data
> for line in data: #  For each line of the data
>  dat = line.split()#  Make a list of the sub-strings in the 
> line
>  for stng in dat:  #  For each substring
>  dt, tp = chktyp(stng) #  Get the data and the type
>  print('{} is a {}'.format(dt, tp))#  Print this data
> 
> 
> Running this example gives this result:
> 
> 2 is a int
> 12.657823 is a float
> 1.823467e-05 is a float
> 114 is a int
> 0 is a int
> 3 is a int
> 4 is a int
> 5 is a int
> 9 is a int
> 11 is a int
> "Lower" is a str
> 278.15 is a float
> 
> I hope this gives you a slight hint about the Python way of doing things.  
> Yes, of course it's 
> very different from BASIC, but if you can pick up on the Pythonic way of 
> doing things I think 
> you might at least find it useful.
> 
>   -=- Larry -=-

I realise that this file i/o will have to be thought of in a different way if I 
start to use Python. This may still be worthwhile inspite of the complexity and 
loss in readability of the code.

To give an example of the kind of things I have to read (and I have 

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[nholtz]

On Wednesday, February 17, 2016 at 2:49:44 PM UTC-5, wrong.a...@gmail.com wrote:
> I am mostly getting positive feedback for Python.
> ...

I'm surprised no one has mentioned jupyter yet, so here goes ...

A browser-based notebook, see http://www.jupyter.org

I think this is an unparalleled way to learn Python, by experimentation at the 
start and for development later.  As an example, I wanted to do some table
processing, so a couple of lines to experiment with Pandas reading CSV files, 
then a couple of more lines to start processing the data ... What a wonderful 
way to experimentally develop software ...

Can even develop simple GUIs *really* easily (but packaging for distribution is 
probably not easy, unless distribution is only within an organization and that 
organization can run a private notebook server).

If you want to try it, this page

http://jupyter.readthedocs.org/en/latest/install.html

recommends installing Anaconda Python which installs a *lot* of stuff (numpy, 
scipy, sympy, pandas, etc. etc.)

I highly recommend both (I use them for Civil Engineering (structures) software 
and teach a related university course)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[Steven D'Aprano]

On Fri, 19 Feb 2016 10:53 pm, wrong.addres...@gmail.com wrote:

>> See http://nedbatchelder.com/text/python-parsers.html for a list of
>> parsers that can do all sorts for you.  Or the stdlib re module
> 
> I am an engineer, and do not understand most of the terminology used
> there. 

Google, or the search engine of your choice, is your friend.

https://duckduckgo.com/html/

https://startpage.com/eng/?


Wikipedia even more so: Wikipedia has lots of good, useful articles on
computing concepts.

https://en.wikipedia.org/wiki/Category:Computing

And use the search box visible at the top of every page.

Or ask here.



> And do I need something fancy to read a line of numbers? Should it 
> not be built into the language?

In your own words:

"I will have to read data given to me by people, which may not come in nice
formats like CSV"

I trust that you don't expect the language to come with pre-written
functions to read numbers in every imaginable format. If you do, you will
be disappointed -- no language could possible do this.

To answer your question "Do I need something fancy...?", no, of course not,
reading a line of numbers from a text file is easy.

with open("numbers.txt", "r") as f:
for line in f:
numbers = [int(s) for s in split(line)]


will read and convert integer-valued numbers separated by whitespace like:

123 654 9374 1 -45 3625


one line at a time. You can then collate them for later use, or process them
as you go. If they're floating point numbers, change the call to int() to a
call to float().






-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[Larry Hudson via Python-list]

On 02/19/2016 10:14 AM, wrong.addres...@gmail.com wrote:
[snip]


This is precisely reading one character at a time. If not exactly reading one 
character, it is effectively looking at each character to assemble the number. 
Not a good sign. I guess there might be libraries which will help read numbers 
better, but I would expect a good language to be able to handle this basic 
thing for engineers - to read numbers like Fortran and Basic do.

Still, if I have misunderstood something, I will be glad to be corrected. I 
would generally know that the first three numbers will be floating point, the 
next will be something and then the next will be something else, etc. Does that 
help or does one still have to look at each character and determine how to 
place it in a number?

Thanks for your patience. I don't want surprises later on, which is why I am 
asking very stupid questions.

It absolutely does NOT require reading a character at a time!  You are reading the data from a 
text file, which means everything is a string.  These strings (or sub-strings) can represent 
integers, floats, dates, phone numbers or whatever.  Your example data implies a free-form 
style, where it is then necessary to determine the data type for each of these (sub)strings 
individually.  Of course, if your data has a defined fixed format, this is simplified -- but 
they are still initially strings that have to be converted.  String processing in Python is very 
powerful and versatile.


BTW, it does no good to continue to think strictly in BASIC techniques.  Python is a different 
language with a different approach to attacking problems.  If you try to write BASIC (or C or 
Java or ...) programs in Python syntax you'll just get bad programs.  Forget trying to find 
features in Python that are identical to the features of BASIC.  Python requires a different 
mind-set to use it properly -- just like any other language.


Here is a rather naive somewhat brute-force way to read your example data.  I'm using a Python 
list here to simulate the file reading.  (Actually, using read() instead of readline() will also 
give this list.)  Python lists are essentially the same as arrays in other languages, but much 
more powerful and versatile.  Two examples of the differences between arrays and lists are:  can 
use mixed data types, you are not restricted to all the same data type, and the size of lists 
are dynamic -- they grow or shrink as necessary.


Comments start with a #
Strings in Python can be delimited by single-quotes ('), double-quotes (") or triple-quotes (""" 
or ''').  Triple-quoted strings can be multi-line text.  The triple-quote here is used as what 
Python calls a docstring, which it saves internally for documenting your program.



#   Define a function to determine the data type a string represents
def chktyp(s):
"""Check string s for int, float or string.  Returns the data and a type 
code"""
try:
return int(s), 'int'  #  Try to convert to int, return it if 
successful
except ValueError:#  No, it's not an int
pass  #  Drop into float test
try:
return float(s), 'float'  #  Try to convert to float, return it if 
successful
except ValueError:#  No, it's not a float
return s, 'str'   #  It must be a string

#   Here is your (simulated) data as a list of strings
data = [
'2 12.657823 0.1823467E-04 114 0',
'3 4 5 9 11',
'"Lower"',#  Could be left simply as "Lower"
'278.15']

#   Process the data
for line in data: #  For each line of the data
dat = line.split()#  Make a list of the sub-strings in the line
for stng in dat:  #  For each substring
dt, tp = chktyp(stng) #  Get the data and the type
print('{} is a {}'.format(dt, tp))#  Print this data


Running this example gives this result:

2 is a int
12.657823 is a float
1.823467e-05 is a float
114 is a int
0 is a int
3 is a int
4 is a int
5 is a int
9 is a int
11 is a int
"Lower" is a str
278.15 is a float

I hope this gives you a slight hint about the Python way of doing things.  Yes, of course it's 
very different from BASIC, but if you can pick up on the Pythonic way of doing things I think 
you might at least find it useful.


 -=- Larry -=-

--
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[Denis Akhiyarov]

On Wednesday, February 17, 2016 at 1:49:44 PM UTC-6, wrong.a...@gmail.com wrote:
> I am mostly getting positive feedback for Python.
> 
> It seems Python is used more for web based applications. Is it equally fine 
> for creating stand-alone *.exe's? Can the same code be compiled to run on 
> Linux or Android or web-based?
> 
> Is it possible to create GUI elements with a good IDE? Can they be defined 
> like in Visual Basic with given sizes, fonts, visible/invisible, etc.?
> 
> Is it easy to do matrix operations in Python? Or do I need to write 
> subroutines like in Visual Basic?
> 
> Could someone kindly tell me advantages and disadvantages of Python? Or any 
> better options? I have like 40-50 VB Forms and may be around 2 lines of 
> code. It will be a task to learn a new language and translate/re-write that 
> code.
> 
> Thanks for your responses.

I'm surprised that no one mentioned this tool called vb2py. It looks outdated, 
but I actually used it successfully to convert vba code to python, once all 
dependencies were installed correctly :)

http://vb2py.sourceforge.net/

You can also understand how vb objects map to python objects.

vb2py has also minimal support for GUI conversion.

Someone has even forked it on github recently:

https://github.com/reingart/vb2py
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[William Ray Wing]

> On Feb 19, 2016, at 8:13 PM, Steven D'Aprano  wrote:
> 
> On Sat, 20 Feb 2016 12:27 am, Dennis Lee Bieber wrote:
> 
> 
>> Then the best suggestion I have would be to take a weekend and just
>> read the language reference manual (it used to be about an 80-page PDF
>> file, but has no doubt grown into some less handy dynamically linked
>> HTML/"help" file). Then add the section of the library reference manual
>> that discusses data types. And while in that manual, scan the table of
>> contents -- you may find there are modules in the standard library that
>> already do what you need.
> 
> Surely you should start with the tutorial, not the reference manual.
> 
> 
> 
> -- 
> Steven
> 
> -- 
> https://mail.python.org/mailman/listinfo/python-list

Plus +1.  The ref manual would be like learning English from a dictionary

Bill

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[Steven D'Aprano]

On Sat, 20 Feb 2016 12:27 am, Dennis Lee Bieber wrote:


> Then the best suggestion I have would be to take a weekend and just
> read the language reference manual (it used to be about an 80-page PDF
> file, but has no doubt grown into some less handy dynamically linked
> HTML/"help" file). Then add the section of the library reference manual
> that discusses data types. And while in that manual, scan the table of
> contents -- you may find there are modules in the standard library that
> already do what you need.

Surely you should start with the tutorial, not the reference manual.



-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[BartC]

On 19/02/2016 18:14, wrong.addres...@gmail.com wrote:

On Friday, 19 February 2016 16:08:46 UTC+2, Tim Chase  wrote:



All this I could do with one Read or Input statement in Fortran and Basic.


I agree with you completely. This stuff is far more complicated than it 
need be. And the fact that there a hundred possible ways of doing it 
doesn't help!


It seems modern languages don't like having i/o as part of the language 
but prefer to have function libraries deal with it. And it still seems 
to be largely DIY...


Although the approach used by Peter Otten doesn't seem too bad. Then you 
would end up writing something like this:


a,b,c,d,e = readline(f, "iffii")

with f being a file handle. You'd need to deal with tokens (in the 
implementation of readline), but not individual characters of each number.


(Remember that Fortran and VB6 are be statically typed, so the language 
knows what types to read into each of those variables. And the Fortran 
might have a 'format' to help out, unless they've got rid of those since 
1979...)


--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[wrong . address . 1]

On Friday, 19 February 2016 16:08:46 UTC+2, Tim Chase  wrote:
> On 2016-02-19 02:47, wrong.addres...@gmail.com wrote:
> > 2 12.657823 0.1823467E-04 114 0
> > 3 4 5 9 11
> > "Lower"
> > 278.15
> > 
> > Is it straightforward to read this, or does one have to read one
> > character at a time and then figure out what the numbers are? -- 
> 
> It's easy to read.  What you do with that mess of data is the complex
> part.  They come in as byte-strings, but you'd have to convert them
> to the corresponding formats:
> 
>   from shlex import shlex
>   USE_LEX = True # False
>   with open('data.txt') as f:
> for i, line in enumerate(f, 1):
>   if USE_LEX:
> bits = shlex(line)
>   else:
> bits = line.split()
>   for j, bit in enumerate(bits, 1):
> if bit.isdigit():
>   result = int(bit)
>   t = "an int"
> elif '"' in bit:
>   result = bit
>   t = "a string"
> else:
>   result = float(bit)
>   t = "a float"
> print("On line %i I think that item %i %r is %s: %r" % (
>   i,
>   j,
>   bit,
>   t,
>   result,
>   ))
> 

All this I could do with one Read or Input statement in Fortran and Basic.

> The USE_LEX controls whether the example code uses string-splitting
> on white-space, or uses the built-in "shlex" module to parse for
> quoted strings that might contain a space.  The naive way of
> string-splitting will be faster, but choke on string-data containing
> spaces.
> 
> You'd have to make up your own heuristics for determining what type
> each data "bit" is, parsing it out (with int(), float() or whatever),
> but the above gives you some rough ideas with at least one known
> bug/edge-case.  But we can't do *all* the work for you ;-)
> 
> -tkc

This is precisely reading one character at a time. If not exactly reading one 
character, it is effectively looking at each character to assemble the number. 
Not a good sign. I guess there might be libraries which will help read numbers 
better, but I would expect a good language to be able to handle this basic 
thing for engineers - to read numbers like Fortran and Basic do.

Still, if I have misunderstood something, I will be glad to be corrected. I 
would generally know that the first three numbers will be floating point, the 
next will be something and then the next will be something else, etc. Does that 
help or does one still have to look at each character and determine how to 
place it in a number?

Thanks for your patience. I don't want surprises later on, which is why I am 
asking very stupid questions.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[Grant Edwards]

On 2016-02-19, BartC  wrote:
>
>> IOW, you're expected to do things correctly
>
> You mean pedantically.

:)

> In real life, names generally are not case sensitive. I can call
> myself bart or Bart or BART or any of the remaining 13 combinations,
> without anyone getting confused (but they might be puzzled as to why
> I'd choose to spell it bArT).

You probably answer to half-a-dozen others things as well.  Such
natural-language concepts just don't work in code.

> And in speech there is no distinction between case (so anyone using
> voice-to-text is going to have trouble with writing code).

That's a good point.

> Even in computing, many kinds of names are case-insensitive, emails and 
> website names for example. I think even MS would struggle to register 
> all the 32768 upper and lower case combinations of www dot microsoft dot 
> com. It becomes nonsensical.

True.

>> [OK, I may be a bit touchy on this subject from dealing with code
>> written by people used to working on Windows where they assume that
>> file names are case insensitive, so therefore seem to feel the need to
>> spice up life by using a variety of spellings for the same damned
>> file.]
>
> But they're all the same file?

Yes.  Sometimes three or four different spellings scattered over
multiple domains (Makefile, C source (e.g. #include directives), and
the filesystem).

-- 
Grant Edwards   grant.b.edwardsYow! I'd like some JUNK
  at   FOOD ... and then I want to
  gmail.combe ALONE --
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[Matt Wheeler]

On 19 February 2016 at 14:58, Peter Otten <__pete...@web.de> wrote:
> Tim Chase wrote:
>> [a long thing]
>
> Or just tell the parser what to expect:
>
> [another long thing]

If you're sure all of the words on a line are going to be numbers then

>>> [float(x) for x in '2 12.657823 0.1823467E-04 114 0'.split()]
[2.0, 12.657823, 1.823467e-05, 114.0, 0.0]

This will of course break if anything on the line *doesn't* look like
a float, but rather than jumping straight into a giant engineering
exercise I'd probably start there.

I'm sure there was a recent thread about returning the best fit type
(i.e. int, if not then float, if not then str)?

-- 
Matt Wheeler
http://funkyh.at
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[Chris Angelico]

On Sat, Feb 20, 2016 at 3:32 AM, BartC  wrote:
> In real life, names generally are not case sensitive. I can call myself bart
> or Bart or BART or any of the remaining 13 combinations, without anyone
> getting confused (but they might be puzzled as to why I'd choose to spell it
> bArT).

There are other conflations, too. You might transliterate your name
into another script, or represent it using only sounds found in a
particular language, to introduce yourself in a completely different
culture. Would you expect a computer to recognize all those as
identical, too? Should the computer treat "Dad" and "John" as the same
variable, since my father's name happens to be John? (Or should it
treat them as distinct, because the _computer's_ father wasn't named
John?)

> And in speech there is no distinction between case (so anyone using
> voice-to-text is going to have trouble with writing code).

That's true of all sorts of other spoken parallels too, though. If
you're using speech-to-text to enter code, you will have to cope with
those, and it's no extra complexity to cope with mixed case.

> Even in computing, many kinds of names are case-insensitive, emails and
> website names for example. I think even MS would struggle to register all
> the 32768 upper and lower case combinations of www dot microsoft dot com. It
> becomes nonsensical.

DNS is a bit of a special case. It has a bizarre mess of ASCII-only
and full-Unicode naming, such that it really shouldn't be held up as a
model for programming language identifiers.

> It's just a popular fad in programming languages, probably originating in C
> and/or Unix, and doing a good job of infesting everything else.

Go ask a German how ß should be capitalized. Then ask if it's
identical to "ss", which also uppercases to "SS". Now, how do you feel
about that whole case sensitivity thing? And is "Ö" equivalent to "O"
or to "OE" or neither? (Answer: It depends on context.)

Everyone I've heard arguing in favour of programming language case
insensitivity has assumed ASCII-only (and English-only). It's 2016.
Time to stop making that assumption.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[BartC]

On 19/02/2016 15:59, Grant Edwards wrote:

On 2016-02-19, BartC  wrote:

On 17/02/2016 19:49, wrong.addres...@gmail.com wrote:


Could someone kindly tell me advantages and disadvantages of Python?


Something I don't think anyone has mentioned is that Python is
case-sensitive.


That's an _advantage_ not a disadvantage.

Anybody who writes code that depends on the assumption that FOOBAR
foobar and FooBar are identical deserves to have his keyboard explode
under his fingertips.


So keywords, identifiers, library functions and so on have to be
written just right.


IOW, you're expected to do things correctly


You mean pedantically.

In real life, names generally are not case sensitive. I can call myself 
bart or Bart or BART or any of the remaining 13 combinations, without 
anyone getting confused (but they might be puzzled as to why I'd choose 
to spell it bArT).


And in speech there is no distinction between case (so anyone using 
voice-to-text is going to have trouble with writing code).


Even in computing, many kinds of names are case-insensitive, emails and 
website names for example. I think even MS would struggle to register 
all the 32768 upper and lower case combinations of www dot microsoft dot 
com. It becomes nonsensical.


It's just a popular fad in programming languages, probably originating 
in C and/or Unix, and doing a good job of infesting everything else.



rather that have the
compiler try to guess the intent of your inept typing.


That's not being very helpful then. Do I type help, Help or HELP? Or 
would it be a better idea to recognise all of them, instead of 
stubbornly refusing to work until I get it exactly right?



[OK, I may be a bit touchy on this subject from dealing with code
written by people used to working on Windows where they assume that
file names are case insensitive, so therefore seem to feel the need to
spice up life by using a variety of spellings for the same damned
file.]


But they're all the same file?

If I had to give you the name of a file over the phone, wouldn't it make 
life much easier if I didn't have to describe, letter by letter, which 
was upper case and which was lower?


[Most of the code I write uses lower-case anyway, but I also like to 
write temporary or debugging code in upper-case. That won't work in a 
language like Python. But it's also a nuisance in remembering if it's 
tkinter or Tkinter. Or are there actually two different packages 
differing only in the case of one letter of their names?]


--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[Grant Edwards]

On 2016-02-19, Chris Angelico  wrote:

> and of course you wouldn't expect that to collide with something
> written in a completely different script. As far as the interpreter's
> concerned, "P" and "p" are just as different as are "A", "Α", "А", and
> [...]

...and a, ã, á, ä, â, à, ą, å, æ, etc.

[Just wanted to see if I remembered how to do that...]

-- 
Grant Edwards   grant.b.edwardsYow! I like your SNOOPY
  at   POSTER!!
  gmail.com
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[Grant Edwards]

On 2016-02-19, BartC  wrote:
> On 17/02/2016 19:49, wrong.addres...@gmail.com wrote:
>
>> Could someone kindly tell me advantages and disadvantages of Python?
>
> Something I don't think anyone has mentioned is that Python is 
> case-sensitive.

That's an _advantage_ not a disadvantage.

Anybody who writes code that depends on the assumption that FOOBAR
foobar and FooBar are identical deserves to have his keyboard explode
under his fingertips.

> So keywords, identifiers, library functions and so on have to be
> written just right.

IOW, you're expected to do things correctly rather that have the
compiler try to guess the intent of your inept typing.

[OK, I may be a bit touchy on this subject from dealing with code
written by people used to working on Windows where they assume that
file names are case insensitive, so therefore seem to feel the need to
spice up life by using a variety of spellings for the same damned
file.]

-- 
Grant Edwards   grant.b.edwardsYow! I would like to
  at   urinate in an OVULAR,
  gmail.comporcelain pool --
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[Chris Angelico]

On Sat, Feb 20, 2016 at 2:34 AM, BartC  wrote:
> On 17/02/2016 19:49, wrong.addres...@gmail.com wrote:
>
>> Could someone kindly tell me advantages and disadvantages of Python?
>
>
> Something I don't think anyone has mentioned is that Python is
> case-sensitive.
>
> So keywords, identifiers, library functions and so on have to be written
> just right. (For example the identifier "abcdef" can be written 64 different
> ways, such as "aBCdEf", and they will all be different symbols.)
>
> This is a complete pain if you're used to a language that ignores case
> (except in data). But pretty much every language now is the same, you can't
> do much about it, you just need to be aware of it.

Indeed. Most languages are case sensitive, because it's too risky to
do anything else. Python 3 allows you to use other scripts than the
basic Latin letters in the ASCII set:

>>> привет = "hello"

and of course you wouldn't expect that to collide with something
written in a completely different script. As far as the interpreter's
concerned, "P" and "p" are just as different as are "A", "Α", "А", and
so on.

Like with Fortran's peculiar freedom in whitespace, case insensitivity
in identifiers is an unwanted relic of a past age.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[BartC]

On 17/02/2016 19:49, wrong.addres...@gmail.com wrote:


Could someone kindly tell me advantages and disadvantages of Python?


Something I don't think anyone has mentioned is that Python is 
case-sensitive.


So keywords, identifiers, library functions and so on have to be written 
just right. (For example the identifier "abcdef" can be written 64 
different ways, such as "aBCdEf", and they will all be different symbols.)


This is a complete pain if you're used to a language that ignores case 
(except in data). But pretty much every language now is the same, you 
can't do much about it, you just need to be aware of it.


--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[Peter Otten]

Tim Chase wrote:

> On 2016-02-19 02:47, wrong.addres...@gmail.com wrote:
>> 2 12.657823 0.1823467E-04 114 0
>> 3 4 5 9 11
>> "Lower"
>> 278.15
>> 
>> Is it straightforward to read this, or does one have to read one
>> character at a time and then figure out what the numbers are? --
> 
> It's easy to read.  What you do with that mess of data is the complex
> part.  They come in as byte-strings, but you'd have to convert them
> to the corresponding formats:
> 
>   from shlex import shlex
>   USE_LEX = True # False
>   with open('data.txt') as f:
> for i, line in enumerate(f, 1):
>   if USE_LEX:
> bits = shlex(line)
>   else:
> bits = line.split()
>   for j, bit in enumerate(bits, 1):
> if bit.isdigit():
>   result = int(bit)
>   t = "an int"
> elif '"' in bit:
>   result = bit
>   t = "a string"
> else:
>   result = float(bit)
>   t = "a float"
> print("On line %i I think that item %i %r is %s: %r" % (
>   i,
>   j,
>   bit,
>   t,
>   result,
>   ))
> 
> The USE_LEX controls whether the example code uses string-splitting
> on white-space, or uses the built-in "shlex" module to parse for
> quoted strings that might contain a space.  The naive way of
> string-splitting will be faster, but choke on string-data containing
> spaces.
> 
> You'd have to make up your own heuristics for determining what type
> each data "bit" is, parsing it out (with int(), float() or whatever),
> but the above gives you some rough ideas with at least one known
> bug/edge-case.  

Or just tell the parser what to expect:

$ cat read_data_shlex2.py
import shlex

CONVERTERS = {
"i": int,
"f": float,
"s": str
}


def parse_line(types, line=None, file=None):
if line is None:
line = file.readline()
values = shlex.split(line)
if len(values) != len(types):
raise ValueError("Too few/many values %r <-- %r" % (types, values))
return tuple(CONVERTERS[t](v) for t, v in zip(types, values))


with open("data.txt") as f:
print(parse_line("iffii", file=f))
print(parse_line("i", file=f))
print(parse_line("s", file=f))
print(parse_line("fsi", file=f))
print(parse_line("ff", file=f))
$ cat data.txt
2 12.657823 0.1823467E-04 114 0
3 4 5 9 11
"Lower"
1.2 "foo \" bar \\ baz" 42
278.15
$ python3 read_data_shlex2.py 
(2, 12.657823, 1.823467e-05, 114, 0)
(3, 4, 5, 9, 11)
('Lower',)
(1.2, 'foo " bar \\ baz', 42)
Traceback (most recent call last):
  File "read_data_shlex2.py", line 24, in 
print(parse_line("ff", file=f))
  File "read_data_shlex2.py", line 15, in parse_line
raise ValueError("Too few/many values %r <-- %r" % (types, values))
ValueError: Too few/many values 'ff' <-- ['278.15']
$ 


But we can't do *all* the work for you ;-)

If this thread goes long enough eventually we will ;)

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[Tim Chase]

On 2016-02-19 02:47, wrong.addres...@gmail.com wrote:
> 2 12.657823 0.1823467E-04 114 0
> 3 4 5 9 11
> "Lower"
> 278.15
> 
> Is it straightforward to read this, or does one have to read one
> character at a time and then figure out what the numbers are? -- 

It's easy to read.  What you do with that mess of data is the complex
part.  They come in as byte-strings, but you'd have to convert them
to the corresponding formats:

  from shlex import shlex
  USE_LEX = True # False
  with open('data.txt') as f:
for i, line in enumerate(f, 1):
  if USE_LEX:
bits = shlex(line)
  else:
bits = line.split()
  for j, bit in enumerate(bits, 1):
if bit.isdigit():
  result = int(bit)
  t = "an int"
elif '"' in bit:
  result = bit
  t = "a string"
else:
  result = float(bit)
  t = "a float"
print("On line %i I think that item %i %r is %s: %r" % (
  i,
  j,
  bit,
  t,
  result,
  ))

The USE_LEX controls whether the example code uses string-splitting
on white-space, or uses the built-in "shlex" module to parse for
quoted strings that might contain a space.  The naive way of
string-splitting will be faster, but choke on string-data containing
spaces.

You'd have to make up your own heuristics for determining what type
each data "bit" is, parsing it out (with int(), float() or whatever),
but the above gives you some rough ideas with at least one known
bug/edge-case.  But we can't do *all* the work for you ;-)

-tkc




-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[wrong . address . 1]

On Friday, 19 February 2016 13:24:46 UTC+2, Mark Lawrence  wrote:
> On 19/02/2016 10:47, wrong.addres...@gmail.com wrote:
> >
> > 2 12.657823 0.1823467E-04 114 0
> > 3 4 5 9 11
> > "Lower"
> > 278.15
> >
> > Is it straightforward to read this, or does one have to read one character 
> > at a time and then figure out what the numbers are?
> >
> 
> One character at a time in a high level language like Python, please. 

That is what VB.net seems designed for. I know nothing about Python, and have 
to decide soon, so I am asking these *very stupid* questions.

> See http://nedbatchelder.com/text/python-parsers.html for a list of 
> parsers that can do all sorts for you.  Or the stdlib re module 

I am an engineer, and do not understand most of the terminology used there. And 
do I need something fancy to read a line of numbers? Should it not be built 
into the language?

The new languages are not designed by engineers or for engineers, so it is 
likely that what we take for granted may not be easy in Python. It was 
different when there was no such thing called "computer science" in the 1960s.

> https://docs.python.org/3/library/re.html.  Or a likely replacement for 
> the re module https://pypi.python.org/pypi/regex.
> 

Thanks.

> -- 
> My fellow Pythonistas, ask not what our language can do for you, ask
> what you can do for our language.
> 
> Mark Lawrence

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[Tony van der Hoff]

On 19/02/16 11:23, Mark Lawrence wrote:

On 19/02/2016 10:47, wrong.addres...@gmail.com wrote:


2 12.657823 0.1823467E-04 114 0
3 4 5 9 11
"Lower"
278.15

Is it straightforward to read this, or does one have to read one
character at a time and then figure out what the numbers are?



One character at a time in a high level language like Python, please.
See http://nedbatchelder.com/text/python-parsers.html for a list of
parsers that can do all sorts for you.  Or the stdlib re module
https://docs.python.org/3/library/re.html.  Or a likely replacement for
the re module https://pypi.python.org/pypi/regex.


Am I alone in thinking that this wrongaddress character is trolling?

How much effort can it be to just install python, and try out these 
simple things *before* asking trivia here?


--
Tony van der Hoff| mailto:t...@vanderhoff.org
Buckinghamshire, England |
--
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[Mark Lawrence]

On 19/02/2016 10:47, wrong.addres...@gmail.com wrote:


2 12.657823 0.1823467E-04 114 0
3 4 5 9 11
"Lower"
278.15

Is it straightforward to read this, or does one have to read one character at a 
time and then figure out what the numbers are?



One character at a time in a high level language like Python, please. 
See http://nedbatchelder.com/text/python-parsers.html for a list of 
parsers that can do all sorts for you.  Or the stdlib re module 
https://docs.python.org/3/library/re.html.  Or a likely replacement for 
the re module https://pypi.python.org/pypi/regex.


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[wrong . address . 1]

On Friday, 19 February 2016 03:06:58 UTC+2, Steven D'Aprano  wrote:
> On Fri, 19 Feb 2016 02:35 am, wrong.addres...@gmail.com wrote:
> 
> > I am almost eager to do this but want to be sure that I know the pitfalls
> > in using Python for my purposes. Thanks for your encouraging response.
> 
> Honestly "wrong.address.1", the ONLY pitfall you need to be aware of is to
> beware of trying to write VB code using Python's interpreter. Python has
> it's own way of doing things, and if you insist on doing them "just like
> VB" you will end up with horrible, slow, inefficient, unusable code. 

This I am aware of. And it is not a problem.

> That's
> not to say that VB is worse, or Python is worse, just that they are
> different. You don't use a hammer the same was a screwdriver.
> 
> Python is a 20+ year old language used by millions of professionals all over
> the world for everything from quick scripting, scientific computing, web
> applications, long-running server applications, and everything in between.
> The answer to every one of your questions "Can Python do X?" will be one
> of:
> 
> (1) Yes it can.
> 
> (2) No, but instead it will do Y which gives you the same result.
> 
> 
> I'll be frank, to come here and ask a bunch of questions like:
> 
> "Is it necessary to read one character at a time...?"
> 
> is a little bit rude. I don't want to discourage you from asking questions,
> but think about *how* you ask them. What you're doing is a little bit like
> going to a car dealer, looking at the cars, then asking a bunch of
> questions:

No, I first saw this trouble in VB.net. Later I found there was an input 
command which allowed me to read numbers in varying formats more or less like 
in Fortran or Basic. I really hope Python has decent ways of reading numeric 
data which may not follow regular formats.

> 
> "So... does this car have a reverse gear or can it only go forward? Do the
> doors open for entry, or do I have to squeeze through the windows? Can I
> use the radio while driving, or is there only enough power for one at a
> time?"
> 
> In most programming communities, if you start asking questions like that,
> you can expect to be ignored or abused. Good thing we're a friendly
> bunch :-)

I hope it was not rude. At least I did not mean to be. 

> 
> 
> Instead, a good question is:
> 
> "How do I read a bunch of numbers from a text file?"
> 
> 
> I'll show you, not only how to read a bunch of numbers, but how to write
> them first.
> 
> Of course there are a million different ways you can do this, and for
> serious use you will probably want to use something like a CSV (Comma
> Separated Values) file like Excel produces, but for a quick idea of how
> Python works, let's write some numbers to a file, one per line. Comments
> start with # and have no effect. Remember that indentation is meaningful:
> you must use the same number of spaces as shown in my code.
> 
> Copy and paste this code into the Python interpreter:
> 
> 
> 
> # = cut =
> 
> # Define some numbers.
> numbers = [1, 45, 38, 99, 1002, 83025, 234, 55, 273, 2]
> # Open a file for writing.
> with open("myfile.txt", "w") as f:
> # Write each number to the file, one per line.
> for number in numbers:
> print("Writing %d to the file." % number)
> f.write(str(number) + "\n")
> 
> # = cut =
> 
> 
> 
> And that's done. Five lines of code, ignoring comments. Now let's read them
> back and see if they're the same:
> 
> 
> # = cut =
> 
> # Prepare a list to hold the numbers.
> data = []
> # Open a file for reading.
> with open("myfile.txt", "r") as f:
> # Read each line.
> for line in f:
> value = line.strip()  # Get rid of trailing newline.
> print("Read %s from the file." % value)
> data.append(int(value))
> 

I have not yet learnt any Python so I do not understand almost anything. 
Besides, I will have to read data given to me by people, which may not come in 
nice formats like CSV, or pre-written by Python.

> # Confirm the numbers read in are the same as those written out.
> if data != numbers:
> print("mismatch in values")
> 
> # Print the sorted values.
> print(sorted(data))
> 
> # = cut =
> 
> 
> 
> Does this help?
> 

Yes. Thanks for your response. I am clear about that I will have to think in a 
different way and not try to convert VB to Python line by line.

> 
> 
> -- 
> Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[wrong . address . 1]

On Thursday, 18 February 2016 21:31:20 UTC+2, Tim Chase  wrote:
> On 2016-02-18 07:33, wrong.addres...@gmail.com wrote:
> > Another question I have is regarding reading numerical data from
> > text files. Is it necessary to read one character at a time, or can
> > one read like in Fortran and Basic (something like Input #5, X1,
> > X2, X3)?
> 
> A lot of my work is extracting data from text files.  If it's
> CSV-format data, Python's "csv" module in the standard library offers
> some nice tools for doing this.
> 
> If the numbers are in plain-text, but at fixed column-offsets, I
> usually create a mapping of slices to make it easier to work with.
> If this is the case and you want some example code, I can dig some up.
> 
> Finally, if the data is actually binary, Python's "struct" module
> (also in the standard library) makes it a lot easier to work with such
> data.
> 
> -tkc

Thanks. The data I will often have to read from text files could read like

2 12.657823 0.1823467E-04 114 0
3 4 5 9 11
"Lower"
278.15

Is it straightforward to read this, or does one have to read one character at a 
time and then figure out what the numbers are?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[Steven D'Aprano]

On Fri, 19 Feb 2016 01:14 pm, BartC wrote:

> On 19/02/2016 00:30, Steven D'Aprano wrote:
[...]
>> "Then don't do that. What if you pass the source code through a system
>> that strips out braces?"
> 
> Python doesn't use braces, so that's not a problem!


mydict = {23: 'twenty-three', 17: 'seventeen'}
myset = {1, 2, 4, 8}

:-)



-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[BartC]

On 19/02/2016 00:30, Steven D'Aprano wrote:

On Thu, 18 Feb 2016 10:32 pm, Chris Angelico wrote:


The biggest disadvantage of Python is that, in a number of ways, it
surprises people. Significant whitespace bugs a lot of experienced
programmers


This is why we cannot have nice things.

"But what if we pass the source code through a system that strips out
leading whitespace?"

"Then don't do that. What if you pass the source code through a system that
strips out braces?"


Python doesn't use braces, so that's not a problem!

--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[Steven D'Aprano]

On Fri, 19 Feb 2016 02:35 am, wrong.addres...@gmail.com wrote:

> I am almost eager to do this but want to be sure that I know the pitfalls
> in using Python for my purposes. Thanks for your encouraging response.

Honestly "wrong.address.1", the ONLY pitfall you need to be aware of is to
beware of trying to write VB code using Python's interpreter. Python has
it's own way of doing things, and if you insist on doing them "just like
VB" you will end up with horrible, slow, inefficient, unusable code. That's
not to say that VB is worse, or Python is worse, just that they are
different. You don't use a hammer the same was a screwdriver.

Python is a 20+ year old language used by millions of professionals all over
the world for everything from quick scripting, scientific computing, web
applications, long-running server applications, and everything in between.
The answer to every one of your questions "Can Python do X?" will be one
of:

(1) Yes it can.

(2) No, but instead it will do Y which gives you the same result.


I'll be frank, to come here and ask a bunch of questions like:

"Is it necessary to read one character at a time...?"

is a little bit rude. I don't want to discourage you from asking questions,
but think about *how* you ask them. What you're doing is a little bit like
going to a car dealer, looking at the cars, then asking a bunch of
questions:

"So... does this car have a reverse gear or can it only go forward? Do the
doors open for entry, or do I have to squeeze through the windows? Can I
use the radio while driving, or is there only enough power for one at a
time?"

In most programming communities, if you start asking questions like that,
you can expect to be ignored or abused. Good thing we're a friendly
bunch :-)


Instead, a good question is:

"How do I read a bunch of numbers from a text file?"


I'll show you, not only how to read a bunch of numbers, but how to write
them first.

Of course there are a million different ways you can do this, and for
serious use you will probably want to use something like a CSV (Comma
Separated Values) file like Excel produces, but for a quick idea of how
Python works, let's write some numbers to a file, one per line. Comments
start with # and have no effect. Remember that indentation is meaningful:
you must use the same number of spaces as shown in my code.

Copy and paste this code into the Python interpreter:



# = cut =

# Define some numbers.
numbers = [1, 45, 38, 99, 1002, 83025, 234, 55, 273, 2]
# Open a file for writing.
with open("myfile.txt", "w") as f:
# Write each number to the file, one per line.
for number in numbers:
print("Writing %d to the file." % number)
f.write(str(number) + "\n")

# = cut =



And that's done. Five lines of code, ignoring comments. Now let's read them
back and see if they're the same:


# = cut =

# Prepare a list to hold the numbers.
data = []
# Open a file for reading.
with open("myfile.txt", "r") as f:
# Read each line.
for line in f:
value = line.strip()  # Get rid of trailing newline.
print("Read %s from the file." % value)
data.append(int(value))

# Confirm the numbers read in are the same as those written out.
if data != numbers:
print("mismatch in values")

# Print the sorted values.
print(sorted(data))

# = cut =



Does this help?



-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[Mark Lawrence]

On 18/02/2016 11:32, Chris Angelico wrote:

On Thu, Feb 18, 2016 at 10:11 PM,   wrote:

Almost everything points positively for Python. Thanks to all of you who have 
responded. But please also tell me the disadvantages of Python. If I start 
using Python, I should be aware of the price I am paying. Speed is not a big 
problem for me, so an interpreted language is fine. Is packaging/installing 
very messy? Do I create dozens of files for a simple program calculating the 
sum of two numbers and product of two numbers in text boxes with one command to 
be clicked? Can I learn this much in the first couple of hours?



There are a few warts, particularly on Windows, as regards packaging
and third-party modules. Anything that's written in pure Python is
fairly easy; stuff that's written in C is sometimes a bit hairy. But
that's a limitation on the "extended library" of PyPI, not the stuff
that comes with Python itself.



The vast majority of C code that you're ever likely to need can be 
obtained here http://www.lfd.uci.edu/~gohlke/pythonlibs/ if there isn't 
a whl file on pypi.  The site might be headed "Unofficial Windows 
Binaries for Python Extension Packages" but it's as safe as houses, I've 
been using it for years without any problems at all.


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[Chris Angelico]

On Fri, Feb 19, 2016 at 11:30 AM, Steven D'Aprano  wrote:
> On Thu, 18 Feb 2016 10:32 pm, Chris Angelico wrote:
>
>> The biggest disadvantage of Python is that, in a number of ways, it
>> surprises people. Significant whitespace bugs a lot of experienced
>> programmers
>
> This is why we cannot have nice things.
>
> "But what if we pass the source code through a system that strips out
> leading whitespace?"
>
> "Then don't do that. What if you pass the source code through a system that
> strips out braces?"

You may note that I didn't say that this was a flaw in Python. And
it's not a tooling issue either (that was mentioned as a parenthesis,
but wasn't my main point). I'm talking about how people, those bags of
flesh and thoughts, are bugged out by the notion that *whitespace*
should matter (other than the mere presence/absence of it). It's the
price you pay for being different - people will have trouble
comprehending you.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[Steven D'Aprano]

On Thu, 18 Feb 2016 10:32 pm, Chris Angelico wrote:

> The biggest disadvantage of Python is that, in a number of ways, it
> surprises people. Significant whitespace bugs a lot of experienced
> programmers

This is why we cannot have nice things.

"But what if we pass the source code through a system that strips out
leading whitespace?"

"Then don't do that. What if you pass the source code through a system that
strips out braces?"



-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[Dietmar Schwertberger]

On 18.02.2016 18:49, wrong.addres...@gmail.com wrote:

What do I lose by using an external library?
With using matplotlib for your plots, you can easily create many kinds 
of plots.
On the other hand, if integration with MS Office is a concern, other 
options may be more suitable for you as matplotlib can not export 
EMF/WMF files any more. (Using svg or pdf as intermediate format is 
possible, but no fun.)
With the drawing function of e.g. wxPython or PyQt you can either draw 
on the screen or into a Metafile context using the same code. So you can 
easily export high quality vector graphics via clipboard or file.


Regards,

Dietmar
--
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[Tim Chase]

On 2016-02-18 07:33, wrong.addres...@gmail.com wrote:
> Another question I have is regarding reading numerical data from
> text files. Is it necessary to read one character at a time, or can
> one read like in Fortran and Basic (something like Input #5, X1,
> X2, X3)?

A lot of my work is extracting data from text files.  If it's
CSV-format data, Python's "csv" module in the standard library offers
some nice tools for doing this.

If the numbers are in plain-text, but at fixed column-offsets, I
usually create a mapping of slices to make it easier to work with.
If this is the case and you want some example code, I can dig some up.

Finally, if the data is actually binary, Python's "struct" module
(also in the standard library) makes it a lot easier to work with such
data.

-tkc



-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[Tim Chase]

On 2016-02-18 09:58, wrong.addres...@gmail.com wrote:
> How long can I depend on VB?

Are you talking the VB6-and-before, or VB.Net?  Given that MS dropped
support for the VB6 line a decade ago (2005-2008 depending on whether
you had extended support) with little to no help in transitioning to
VB.Net which (pejoratively called "Visual Fred" because it's so
different), I wouldn't want to depend on it at all.  Especially since
VB.Net is so radically different from VB6.  As it seems you've found.

> I don't really mind learning one more language if there is
> sufficient utility of it. Besides, I hear that Python is relatively
> easy to learn compared to C++ or Java.

I find that Python is much more readable than the C-flavored
languages.  Also, while there are language gotchas in all of them,
Python's make a lot more sense to me compared to those in the
C-flavored languages.

> I have some smaller VB programs (single form, little math) for my
> own use. I could convert those first and get a feel of how it is
> going to be with larger programs with thousands of lines.

Excellent plan.

-tkc




-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[wrong . address . 1]

On Thursday, 18 February 2016 18:24:55 UTC+2, Dan Strohl  wrote:
> I totally agree with Chris here, try it out, do some simpler things to get 
> your feet wet before committing to redoing hundreds of thousands of lines of 
> code in it.  Find a few of the "deal breakers" and try to solve them in 
> Python (create a hello world app in python, then package it in an exe and 
> distribute it to some friends).. VB is a fine language, and is likely to suit 
> your needs as well... even if we all believe that Python is better, the 
> effort to convert from one to the other may not make sense.
> 

How long can I depend on VB? I don't really mind learning one more language if 
there is sufficient utility of it. Besides, I hear that Python is relatively 
easy to learn compared to C++ or Java.

I have some smaller VB programs (single form, little math) for my own use. I 
could convert those first and get a feel of how it is going to be with larger 
programs with thousands of lines.

> I would also suggest taking a few steps back and seeing if there is a 
> different overall architectural approach that makes sense.  If you are using 
> a heavy weight local app, what about a web app? 

Some things I do can be done in a web app, but the important stuff has to be 
put into *.exe files for myself and others to use.

> What about doing a combination approach?  Have a back end running on a server 
> with Python, that feeds a VB app on a client for displaying and manipulating 
> data? (then a Java app for mobile clients or Linux ones?)
> 

I do not know Java, and don't feel inclined to learn that. If I could use VB 
for years, I need not consider moving over to Python. The trouble is that I 
don't think we can trust VB (VB6 particularly, but even VB.net) for too long.

> Also, looking at existing frameworks and expandable apps out there that you 
> might be able to do less work but still meet your goals with because 80% of 
> the work was done for you... things like django, splunk, tableau, etc...
> 
> Dan
> 

Thanks.

> 
> > -Original Message-
> > From: Python-list [mailto:python-list-bounces+d.strohl=f5@python.org] On
> > Behalf Of Chris Angelico
> > Sent: Thursday, February 18, 2016 8:06 AM
> > Cc: python-list@python.org
> > Subject: Re: Considering migrating to Python from Visual Basic 6 for 
> > engineering
> > applications
> > 
> > On Fri, Feb 19, 2016 at 2:49 AM,  <wrong.addres...@gmail.com> wrote:
> > > Thanks. You have guided me quite well, and I am almost ready to declare 
> > > that I
> > will use Python for the next few decades.
> > >
> > 
> > Don't declare like that - just start using it, and see what you think
> > :) But I would be very much surprised if Python doesn't get added to your
> > toolbelt. A good programmer should always keep a selection of tools handy -
> > seldom is one tool the right one for every job.
> > 
> > > Imagine I want to read in two (or a few) numbers from a text file, 
> > > display them
> > in two (or more) text boxes, calculate their sums and products, may be take
> > logarithms of them, and display them in other two text boxes or labels, and
> > make some bar charts, scatter plots, and later draw curves and surfaces on a
> > computer screen. Do I really need PyPi or other external stuff for this? Is 
> > Python
> > well equipped for this?
> > >
> > 
> > You could do all of that with just the standard library, but then your only 
> > choice
> > of GUI library is Tkinter, which is derived from Tcl/Tk.
> > If you don't like how that looks (either in your code, or in the resulting 
> > GUI),
> > you'll need to turn to PyPI for an alternative (eg something derived from 
> > GTK or
> > wxWindows or Qt). I'm not sure how the graphing capabilities of Tkinter 
> > are, so
> > you might want to grab matplotlib too - again, it'll give you a lot more 
> > flexibility
> > than you would have if you restrict yourself to *just* the standard library.
> > But I think you could do all of that - certainly most of it - with just the 
> > language
> > and standard library.
> > 
> > > I will have to learn GUI creating quickly after I know the basics of 
> > > reading and
> > writing text files, and doing simple mathematical calculations.
> > >
> > 
> > Reading and writing text files is easy, as is basic mathematics.
> > You'll have that down in an hour or two, most likely, and then you'll have 
> > time to
> > play GUIs.
> > 
> > > Later I can imagine using things like sending an SMS from a phone running 
> > > this
> > on Android, or placing a graph in a WhatsApp message, make a call to someone
> > and tell him the temperature is now too high, etc. These things might need
> > external libraries, but I can learn this later on.
> > >
> > 
> > Those things will most likely require external libraries. But most of them 
> > are
> > probably possible.
> > 
> > ChrisA
> > --
> > https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[wrong . address . 1]

On Thursday, 18 February 2016 18:06:29 UTC+2, Chris Angelico  wrote:
> On Fri, Feb 19, 2016 at 2:49 AM,   wrote:
> > Thanks. You have guided me quite well, and I am almost ready to declare 
> > that I will use Python for the next few decades.
> >
> 
> Don't declare like that - just start using it, and see what you think
> :) But I would be very much surprised if Python doesn't get added to
> your toolbelt. A good programmer should always keep a selection of
> tools handy - seldom is one tool the right one for every job.
> 
> > Imagine I want to read in two (or a few) numbers from a text file, display 
> > them in two (or more) text boxes, calculate their sums and products, may be 
> > take logarithms of them, and display them in other two text boxes or 
> > labels, and make some bar charts, scatter plots, and later draw curves and 
> > surfaces on a computer screen. Do I really need PyPi or other external 
> > stuff for this? Is Python well equipped for this?
> >
> 
> You could do all of that with just the standard library, but then your
> only choice of GUI library is Tkinter, which is derived from Tcl/Tk.
> If you don't like how that looks (either in your code, or in the
> resulting GUI), you'll need to turn to PyPI for an alternative (eg
> something derived from GTK or wxWindows or Qt). I'm not sure how the
> graphing capabilities of Tkinter are, so you might want to grab
> matplotlib too - again, it'll give you a lot more flexibility than you
> would have if you restrict yourself to *just* the standard library.
> But I think you could do all of that - certainly most of it - with
> just the language and standard library.
> 

What do I lose by using an external library? Bigger size of the *.exe is not a 
problem, neither is speed an issue. It might even be easier to learn with these 
external libraries, and produce more readable code.

> > I will have to learn GUI creating quickly after I know the basics of 
> > reading and writing text files, and doing simple mathematical calculations.
> >
> 
> Reading and writing text files is easy, as is basic mathematics.
> You'll have that down in an hour or two, most likely, and then you'll
> have time to play GUIs.

That is good.

> 
> > Later I can imagine using things like sending an SMS from a phone running 
> > this on Android, or placing a graph in a WhatsApp message, make a call to 
> > someone and tell him the temperature is now too high, etc. These things 
> > might need external libraries, but I can learn this later on.
> >
> 
> Those things will most likely require external libraries. But most of
> them are probably possible.
> 
> ChrisA

Thanks again for your input.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[wrong . address . 1]

On Thursday, 18 February 2016 18:01:17 UTC+2, Dan Strohl  wrote:
> Disadvantages of python... (compared to VB)
> 
> That's a hard one, but here are my thoughts:  (keep in mind that these kinds 
> of discussions are subjective and much is based on the background and 
> experience of the coder, these are also assuming that 100% of your audience 
> is on windows, as soon as you start talking about cross platform support, VB 
> gets much harder to use (yes, you could use it on Linus, via a web based app, 
> or an emulator if you HAD to).
> 
> - I find that VB is much easier at making quick GUI apps (for windows).

Yes, and I have used it for about 20 years. VB2 was wonderful for my work. VB3 
was fine. VB6 is also OK, but VB.net is too bloated. But can I count on using 
VB6 for the next five years? Or more?

> 
> - VB is easier to integrate with office apps and other windows specific 
> things (there are some python modules that will access office files etc, but 
> if you want to have an engineering app that directly integrates / interacts 
> with excel, VB is probably better.
> 

Python will read *.csv, and that will be enough. I guess writing *.csv will 
also be easy.

> - I find VB is easier to package and distribute.  (there are some good 
> utilities that will take Python and package it into an exe, along with all of 
> the needed pieces, interpreter, etc, but those all require some level of work 
> to setup and make work... not a lot sometimes, but certainly more than "click 
> compile" and copy the .exe file.
> 

Is Python packaging a lot more complicated than VB.net?

> - VB is often, for simple apps, often simpler to learn for non-programmers.  
> (I know I will get slammed for that one).  For complex apps, I find VB harder 
> to do things than Python, but for example, if I wanted to make a quick 
> windows calculator, I would probably go to VB first.)
> 
> My approach is generally:
> 
> I use Python for:
> - server apps, web based apps, plugins, modules, library development, or apps 
> that I want to be able to expand later with plugins, console apps and 
> utilities (things that I am only going to run from the CLI anyway),  
> performance focused apps (unless I need to go all the way to C for 
> performance), anything that might ever need to be cross platform, apps that 
> interact with other (non-Microsoft) apps.
> 

For me, none of these things are very interesting.

> I use VB for:
> Quick user focused, non-web apps, apps that are used in or directly with 
> Microsoft Office apps, apps that I am developing for someone else that is a 
> VB programmer (or non-programmer but might poke at them).. apps that I need 
> to distribute to lots of less controlled workstations that don't have python 
> on them already.
> 
> These days, I find that I am using VB much less than Python, most of the 
> reasons that I would pick VB can be overcome by developing a cloud app 
> instead of a local app, but there are still times that VB is the right tool 
> (for me at least).
> 

But how long can I continue to use VB6?

> > --
> > https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[wrong . address . 1]

On Thursday, 18 February 2016 17:59:59 UTC+2, William Ray Wing  wrote:
> > On Feb 18, 2016, at 10:33 AM, wrong.addres...@gmail.com wrote:
> > 
> > torstai 18. helmikuuta 2016 17.21.32 UTC+2 Oscar Benjamin kirjoitti:
> >> On 18 February 2016 at 11:32, Chris Angelico  wrote:
> >> 
> 
> [byte]
> 
> >> It sounds to me as if all of your needs can be solved in pure Python
> >> code possibly using some of the popular extension modules from PyPI.
> >> In this case it's actually very easy to package/install. You can
> >> package your code simply by zipping it up with a __main__.py file.
> >> Someone who wants to install it will simply have a two step process:
> >> first install Python (and possibly a few dependencies) and then obtain
> >> the zip file with your code in it.
> >> 
> >> --
> >> Oscar
> > 
> > This form of packing is not desirable. I can't ask other people to install 
> > Python on their machines, and I also would not want show most of the code 
> > doing the calculations.
> > 
> 
> Now things get tricky.  I can understand you not wanting to force people to 
> pre-install Python in order for your code to run, but just how deeply do you 
> want to hide or obfuscate it? 

I don't have to hide it very carefully. If it creates machine code which can be 
decompiled, I am not very bothered, but I do not want to show many of the 
equations I will embed in the code, very openly. These will be different for 
different people, so nobody will have much motivation to break open the code. 
One *.exe is likely to be used by 2 or 3 people, and then for someone else, I 
would create another very similar *.exe with somewhat different equations. This 
is just one of the things I intend to do. Then there are several calculation 
and plotting routines for my work, which won't be given to anyone, where the 
issue of secrecy does not arise.

> Is this potentially a commercial application to be sold, or are you simply 
> trying to keep things clean and tidy within various divisions of your 
> company.  I'd hope not the former, because even VB can get you into tricky 
> licensing issues (and in any case - even fully compiled code in any language 
> these days can be de-compiled into logically correct source code, although 
> with less than obvious variable names). 

Decompiling machine code I am not at all worried about. The decompiled code 
will be too messy for people to study. (I won't be writing simple algebraic 
equations in one or two lines.)

> At the other extreme, there are packaging programs (py2exe comes to mind, 
> although I have no experience with it).  These wrap the whole python 
> interpreter, your code, and any needed libraries into an executable 
> (clickable) package.  Their only downside is that the output packages they 
> produce tend to be large.  However, any sophisticated user who digs into them 
> WILL be able to find your source code, possibly only slightly obfuscated by 
> being zipped.
> 

This is not good if the source code with actual variable names becomes visible. 
Then I would have to use misleading variable names, and call temperature a flow 
rate, and pressure a magnetic field; stuff a lot of matrix equations which do 
nothing but get the decoders to waste a huge amount of time.

> > Another question I have is regarding reading numerical data from text 
> > files. Is it necessary to read one character at a time, or can one read 
> > like in Fortran and Basic (something like Input #5, X1, X2, X3)?
> 
> Python can read lines of text or whole blocks of text from source files.  If 
> those files are in more or less well-understood form (csv for example) it has 
> libraries specifically designed for reading and extracting data from them 
> (including VERY nice facilities for doing arithmetic and otherwise 
> manipulating time and date data).
> 

That is good. VB.net also has, but in the beginning I got the impression that 
you could read only one character as a time in a stream.

> Bill
> 
> > -- 
> > https://mail.python.org/mailman/listinfo/python-list

-- 
https://mail.python.org/mailman/listinfo/python-list

RE: Considering migrating to Python from Visual Basic 6 for engineering applications

[Dan Strohl]

I totally agree with Chris here, try it out, do some simpler things to get your 
feet wet before committing to redoing hundreds of thousands of lines of code in 
it.  Find a few of the "deal breakers" and try to solve them in Python (create 
a hello world app in python, then package it in an exe and distribute it to 
some friends).. VB is a fine language, and is likely to suit your needs as 
well... even if we all believe that Python is better, the effort to convert 
from one to the other may not make sense.

I would also suggest taking a few steps back and seeing if there is a different 
overall architectural approach that makes sense.  If you are using a heavy 
weight local app, what about a web app?  What about doing a combination 
approach?  Have a back end running on a server with Python, that feeds a VB app 
on a client for displaying and manipulating data? (then a Java app for mobile 
clients or Linux ones?)

Also, looking at existing frameworks and expandable apps out there that you 
might be able to do less work but still meet your goals with because 80% of the 
work was done for you... things like django, splunk, tableau, etc...

Dan


> -Original Message-
> From: Python-list [mailto:python-list-bounces+d.strohl=f5@python.org] On
> Behalf Of Chris Angelico
> Sent: Thursday, February 18, 2016 8:06 AM
> Cc: python-list@python.org
> Subject: Re: Considering migrating to Python from Visual Basic 6 for 
> engineering
> applications
> 
> On Fri, Feb 19, 2016 at 2:49 AM,  <wrong.addres...@gmail.com> wrote:
> > Thanks. You have guided me quite well, and I am almost ready to declare 
> > that I
> will use Python for the next few decades.
> >
> 
> Don't declare like that - just start using it, and see what you think
> :) But I would be very much surprised if Python doesn't get added to your
> toolbelt. A good programmer should always keep a selection of tools handy -
> seldom is one tool the right one for every job.
> 
> > Imagine I want to read in two (or a few) numbers from a text file, display 
> > them
> in two (or more) text boxes, calculate their sums and products, may be take
> logarithms of them, and display them in other two text boxes or labels, and
> make some bar charts, scatter plots, and later draw curves and surfaces on a
> computer screen. Do I really need PyPi or other external stuff for this? Is 
> Python
> well equipped for this?
> >
> 
> You could do all of that with just the standard library, but then your only 
> choice
> of GUI library is Tkinter, which is derived from Tcl/Tk.
> If you don't like how that looks (either in your code, or in the resulting 
> GUI),
> you'll need to turn to PyPI for an alternative (eg something derived from GTK 
> or
> wxWindows or Qt). I'm not sure how the graphing capabilities of Tkinter are, 
> so
> you might want to grab matplotlib too - again, it'll give you a lot more 
> flexibility
> than you would have if you restrict yourself to *just* the standard library.
> But I think you could do all of that - certainly most of it - with just the 
> language
> and standard library.
> 
> > I will have to learn GUI creating quickly after I know the basics of 
> > reading and
> writing text files, and doing simple mathematical calculations.
> >
> 
> Reading and writing text files is easy, as is basic mathematics.
> You'll have that down in an hour or two, most likely, and then you'll have 
> time to
> play GUIs.
> 
> > Later I can imagine using things like sending an SMS from a phone running 
> > this
> on Android, or placing a graph in a WhatsApp message, make a call to someone
> and tell him the temperature is now too high, etc. These things might need
> external libraries, but I can learn this later on.
> >
> 
> Those things will most likely require external libraries. But most of them are
> probably possible.
> 
> ChrisA
> --
> https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[Chris Angelico]

On Fri, Feb 19, 2016 at 2:49 AM,   wrote:
> Thanks. You have guided me quite well, and I am almost ready to declare that 
> I will use Python for the next few decades.
>

Don't declare like that - just start using it, and see what you think
:) But I would be very much surprised if Python doesn't get added to
your toolbelt. A good programmer should always keep a selection of
tools handy - seldom is one tool the right one for every job.

> Imagine I want to read in two (or a few) numbers from a text file, display 
> them in two (or more) text boxes, calculate their sums and products, may be 
> take logarithms of them, and display them in other two text boxes or labels, 
> and make some bar charts, scatter plots, and later draw curves and surfaces 
> on a computer screen. Do I really need PyPi or other external stuff for this? 
> Is Python well equipped for this?
>

You could do all of that with just the standard library, but then your
only choice of GUI library is Tkinter, which is derived from Tcl/Tk.
If you don't like how that looks (either in your code, or in the
resulting GUI), you'll need to turn to PyPI for an alternative (eg
something derived from GTK or wxWindows or Qt). I'm not sure how the
graphing capabilities of Tkinter are, so you might want to grab
matplotlib too - again, it'll give you a lot more flexibility than you
would have if you restrict yourself to *just* the standard library.
But I think you could do all of that - certainly most of it - with
just the language and standard library.

> I will have to learn GUI creating quickly after I know the basics of reading 
> and writing text files, and doing simple mathematical calculations.
>

Reading and writing text files is easy, as is basic mathematics.
You'll have that down in an hour or two, most likely, and then you'll
have time to play GUIs.

> Later I can imagine using things like sending an SMS from a phone running 
> this on Android, or placing a graph in a WhatsApp message, make a call to 
> someone and tell him the temperature is now too high, etc. These things might 
> need external libraries, but I can learn this later on.
>

Those things will most likely require external libraries. But most of
them are probably possible.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

RE: Considering migrating to Python from Visual Basic 6 for engineering applications

[Dan Strohl]

Disadvantages of python... (compared to VB)

That's a hard one, but here are my thoughts:  (keep in mind that these kinds of 
discussions are subjective and much is based on the background and experience 
of the coder, these are also assuming that 100% of your audience is on windows, 
as soon as you start talking about cross platform support, VB gets much harder 
to use (yes, you could use it on Linus, via a web based app, or an emulator if 
you HAD to).

- I find that VB is much easier at making quick GUI apps (for windows).

- VB is easier to integrate with office apps and other windows specific things 
(there are some python modules that will access office files etc, but if you 
want to have an engineering app that directly integrates / interacts with 
excel, VB is probably better.

- I find VB is easier to package and distribute.  (there are some good 
utilities that will take Python and package it into an exe, along with all of 
the needed pieces, interpreter, etc, but those all require some level of work 
to setup and make work... not a lot sometimes, but certainly more than "click 
compile" and copy the .exe file.

- VB is often, for simple apps, often simpler to learn for non-programmers.  (I 
know I will get slammed for that one).  For complex apps, I find VB harder to 
do things than Python, but for example, if I wanted to make a quick windows 
calculator, I would probably go to VB first.)

My approach is generally:

I use Python for:
- server apps, web based apps, plugins, modules, library development, or apps 
that I want to be able to expand later with plugins, console apps and utilities 
(things that I am only going to run from the CLI anyway),  performance focused 
apps (unless I need to go all the way to C for performance), anything that 
might ever need to be cross platform, apps that interact with other 
(non-Microsoft) apps.

I use VB for:
Quick user focused, non-web apps, apps that are used in or directly with 
Microsoft Office apps, apps that I am developing for someone else that is a VB 
programmer (or non-programmer but might poke at them).. apps that I need to 
distribute to lots of less controlled workstations that don't have python on 
them already.

These days, I find that I am using VB much less than Python, most of the 
reasons that I would pick VB can be overcome by developing a cloud app instead 
of a local app, but there are still times that VB is the right tool (for me at 
least).





> -Original Message-
> From: Python-list [mailto:python-list-bounces+d.strohl=f5@python.org] On
> Behalf Of wrong.addres...@gmail.com
> Sent: Thursday, February 18, 2016 7:33 AM
> To: python-list@python.org
> Subject: Re: Considering migrating to Python from Visual Basic 6 for 
> engineering
> applications
> 
> torstai 18. helmikuuta 2016 17.21.32 UTC+2 Oscar Benjamin kirjoitti:
> > On 18 February 2016 at 11:32, Chris Angelico <ros...@gmail.com> wrote:
> > > On Thu, Feb 18, 2016 at 10:11 PM,  <wrong.addres...@gmail.com> wrote:
> > >> Almost everything points positively for Python. Thanks to all of you who
> have responded. But please also tell me the disadvantages of Python. If I 
> start
> using Python, I should be aware of the price I am paying. Speed is not a big
> problem for me, so an interpreted language is fine. Is packaging/installing 
> very
> messy? Do I create dozens of files for a simple program calculating the sum of
> two numbers and product of two numbers in text boxes with one command to
> be clicked? Can I learn this much in the first couple of hours?
> > >>
> > >
> > > There are a few warts, particularly on Windows, as regards packaging
> > > and third-party modules. Anything that's written in pure Python is
> > > fairly easy; stuff that's written in C is sometimes a bit hairy. But
> > > that's a limitation on the "extended library" of PyPI, not the stuff
> > > that comes with Python itself.
> >
> > For packaging/installing it really depends on what you're trying to
> > do. You have to understand that Python is used in many very different
> > ways in different environments and ecosystems so there just isn't a
> > single way of doing it.
> >
> > It sounds to me as if all of your needs can be solved in pure Python
> > code possibly using some of the popular extension modules from PyPI.
> > In this case it's actually very easy to package/install. You can
> > package your code simply by zipping it up with a __main__.py file.
> > Someone who wants to install it will simply have a two step process:
> > first install Python (and possibly a few dependencies) and then obtain
> > the zip file with your code in it.
> >
> > --
> > Oscar
> 
> This form of packing is not desirable. I can't ask othe

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[William Ray Wing]

> On Feb 18, 2016, at 10:33 AM, wrong.addres...@gmail.com wrote:
> 
> torstai 18. helmikuuta 2016 17.21.32 UTC+2 Oscar Benjamin kirjoitti:
>> On 18 February 2016 at 11:32, Chris Angelico  wrote:
>> 

[byte]

>> It sounds to me as if all of your needs can be solved in pure Python
>> code possibly using some of the popular extension modules from PyPI.
>> In this case it's actually very easy to package/install. You can
>> package your code simply by zipping it up with a __main__.py file.
>> Someone who wants to install it will simply have a two step process:
>> first install Python (and possibly a few dependencies) and then obtain
>> the zip file with your code in it.
>> 
>> --
>> Oscar
> 
> This form of packing is not desirable. I can't ask other people to install 
> Python on their machines, and I also would not want show most of the code 
> doing the calculations.
> 

Now things get tricky.  I can understand you not wanting to force people to 
pre-install Python in order for your code to run, but just how deeply do you 
want to hide or obfuscate it?  Is this potentially a commercial application to 
be sold, or are you simply trying to keep things clean and tidy within various 
divisions of your company.  I’d hope not the former, because even VB can get 
you into tricky licensing issues (and in any case - even fully compiled code in 
any language these days can be de-compiled into logically correct source code, 
although with less than obvious variable names).  At the other extreme, there 
are packaging programs (py2exe comes to mind, although I have no experience 
with it).  These wrap the whole python interpreter, your code, and any needed 
libraries into an executable (clickable) package.  Their only downside is that 
the output packages they produce tend to be large.  However, any sophisticated 
user who digs into them WILL be able to find your source code, possibly only 
slightly obfuscated by being zipped.

> Another question I have is regarding reading numerical data from text files. 
> Is it necessary to read one character at a time, or can one read like in 
> Fortran and Basic (something like Input #5, X1, X2, X3)?

Python can read lines of text or whole blocks of text from source files.  If 
those files are in more or less well-understood form (csv for example) it has 
libraries specifically designed for reading and extracting data from them 
(including VERY nice facilities for doing arithmetic and otherwise manipulating 
time and date data).

Bill

> -- 
> https://mail.python.org/mailman/listinfo/python-list

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[wrong . address . 1]

On Thursday, 18 February 2016 13:32:58 UTC+2, Chris Angelico  wrote:
> On Thu, Feb 18, 2016 at 10:11 PM,   wrote:
> > Almost everything points positively for Python. Thanks to all of you who 
> > have responded. But please also tell me the disadvantages of Python. If I 
> > start using Python, I should be aware of the price I am paying. Speed is 
> > not a big problem for me, so an interpreted language is fine. Is 
> > packaging/installing very messy? Do I create dozens of files for a simple 
> > program calculating the sum of two numbers and product of two numbers in 
> > text boxes with one command to be clicked? Can I learn this much in the 
> > first couple of hours?
> >
> 
> There are a few warts, particularly on Windows, as regards packaging
> and third-party modules. Anything that's written in pure Python is
> fairly easy; stuff that's written in C is sometimes a bit hairy. But
> that's a limitation on the "extended library" of PyPI, not the stuff
> that comes with Python itself.
> 
> Your simple example could easily be a single file. Python tends to
> eschew boilerplate; its motto comes from Baloo - look for the bare
> necessities of life.
> 
> For a first couple of hours, I would recommend working at the console
> or in Idle, rather than creating a GUI; a window takes a bit of extra
> effort (plus you have choices in how to do that), so just learn the
> language first. But you could easily advance to building a GUI within
> your first day of learning Python, if that's the direction you want to
> go.
> 
> The biggest disadvantage of Python is that, in a number of ways, it
> surprises people. Significant whitespace bugs a lot of experienced
> programmers (and some tools, too), and there are a few other ways that
> you may find a team of people revile against it. But if you can deal
> with the social aspects, it's a solid language.
> 
> ChrisA

Thanks. You have guided me quite well, and I am almost ready to declare that I 
will use Python for the next few decades.

Imagine I want to read in two (or a few) numbers from a text file, display them 
in two (or more) text boxes, calculate their sums and products, may be take 
logarithms of them, and display them in other two text boxes or labels, and 
make some bar charts, scatter plots, and later draw curves and surfaces on a 
computer screen. Do I really need PyPi or other external stuff for this? Is 
Python well equipped for this?

I will have to learn GUI creating quickly after I know the basics of reading 
and writing text files, and doing simple mathematical calculations.

Later I can imagine using things like sending an SMS from a phone running this 
on Android, or placing a graph in a WhatsApp message, make a call to someone 
and tell him the temperature is now too high, etc. These things might need 
external libraries, but I can learn this later on.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[Oscar Benjamin]

On 18 February 2016 at 15:33,   wrote:
>> It sounds to me as if all of your needs can be solved in pure Python
>> code possibly using some of the popular extension modules from PyPI.
>> In this case it's actually very easy to package/install. You can
>> package your code simply by zipping it up with a __main__.py file.
>> Someone who wants to install it will simply have a two step process:
>> first install Python (and possibly a few dependencies) and then obtain
>> the zip file with your code in it.
>
> This form of packing is not desirable. I can't ask other people to install 
> Python on their machines, and I also would not want show most of the code 
> doing the calculations.

This is what sometimes makes packaging Python apps difficult.
Distributing code as a zip file is easy and works out of the box.
However a lot of people are very insistent that asking the end user to
first install Python is unacceptable. That's why I said it depends
what you're trying to do. I guess from your description that you want
other people to be able to install and use your proprietary
applications on whatever OS they're using.

You would probably want to use something like pyinstaller then as this
bundles a Python interpreter with your code. For Windows there's also
the embedded Python distribution which you can ship as part of an
installer for your program. For OSX/Linux Python is most likely
already installed so this may be unnecessary.

In terms of hiding the code doing the calculations: it doesn't work
like that in Python. The code is not compiled so if the end user has
your app then they have your code. You could probably use something
like Cython to obfuscate it but then this means that your compiled
code is architecture/platform dependent so you need to compile it
separately for each platform and there are other problems.

> Another question I have is regarding reading numerical data from text files. 
> Is it necessary to read one character at a time, or can one read like in 
> Fortran and Basic (something like Input #5, X1, X2, X3)?

There are loads of ways to read your data in from text files. I don't
know how it works in Fortran and Basic but I'm sure there will be
something that does what you want.

--
Oscar
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[wrong . address . 1]

torstai 18. helmikuuta 2016 16.08.05 UTC+2 William Ray Wing kirjoitti:
> > On Feb 17, 2016, at 2:49 PM, wrong.addres...@gmail.com wrote:
> > 
> > I am mostly getting positive feedback for Python.
> > 
> > It seems Python is used more for web based applications. Is it equally fine 
> > for creating stand-alone *.exe's? Can the same code be compiled to run on 
> > Linux or Android or web-based?
> > 
> > Is it possible to create GUI elements with a good IDE? Can they be defined 
> > like in Visual Basic with given sizes, fonts, visible/invisible, etc.?
> > 
> > Is it easy to do matrix operations in Python? Or do I need to write 
> > subroutines like in Visual Basic?
> > 
> > Could someone kindly tell me advantages and disadvantages of Python? Or any 
> > better options? I have like 40-50 VB Forms and may be around 2 lines of 
> > code. It will be a task to learn a new language and translate/re-write that 
> > code.
> > 
> 
> At this point you've probably heard more than you wanted to *about* Python.  
> The next step really ought to be simply to invest a few minutes in looking at 
> the language itself.
> Start here by downloading a copy of the Python interpreter:
> 
>   https://www.python.org/downloads/windows/
> 
> Then, there is an extensive list of on-line tutorial material here:
> 
>   https://wiki.python.org/moin/BeginnersGuide/Programmers
> 
> I'd recommend simply picking one and diving in. If you have questions (and 
> you surely will), come back here or, at least initially, send them to the 
> Python Tutor list (tu...@python.org).
> 
> Good luck and have fun,
> Bill
> 
> 
> > Thanks for your responses. 
> > -- 
> > https://mail.python.org/mailman/listinfo/python-list

I am almost eager to do this but want to be sure that I know the pitfalls in 
using Python for my purposes. Thanks for your encouraging response.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[wrong . address . 1]

torstai 18. helmikuuta 2016 17.21.32 UTC+2 Oscar Benjamin kirjoitti:
> On 18 February 2016 at 11:32, Chris Angelico  wrote:
> > On Thu, Feb 18, 2016 at 10:11 PM,   wrote:
> >> Almost everything points positively for Python. Thanks to all of you who 
> >> have responded. But please also tell me the disadvantages of Python. If I 
> >> start using Python, I should be aware of the price I am paying. Speed is 
> >> not a big problem for me, so an interpreted language is fine. Is 
> >> packaging/installing very messy? Do I create dozens of files for a simple 
> >> program calculating the sum of two numbers and product of two numbers in 
> >> text boxes with one command to be clicked? Can I learn this much in the 
> >> first couple of hours?
> >>
> >
> > There are a few warts, particularly on Windows, as regards packaging
> > and third-party modules. Anything that's written in pure Python is
> > fairly easy; stuff that's written in C is sometimes a bit hairy. But
> > that's a limitation on the "extended library" of PyPI, not the stuff
> > that comes with Python itself.
> 
> For packaging/installing it really depends on what you're trying to
> do. You have to understand that Python is used in many very different
> ways in different environments and ecosystems so there just isn't a
> single way of doing it.
> 
> It sounds to me as if all of your needs can be solved in pure Python
> code possibly using some of the popular extension modules from PyPI.
> In this case it's actually very easy to package/install. You can
> package your code simply by zipping it up with a __main__.py file.
> Someone who wants to install it will simply have a two step process:
> first install Python (and possibly a few dependencies) and then obtain
> the zip file with your code in it.
> 
> --
> Oscar

This form of packing is not desirable. I can't ask other people to install 
Python on their machines, and I also would not want show most of the code doing 
the calculations.

Another question I have is regarding reading numerical data from text files. Is 
it necessary to read one character at a time, or can one read like in Fortran 
and Basic (something like Input #5, X1, X2, X3)?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[Oscar Benjamin]

On 18 February 2016 at 11:32, Chris Angelico  wrote:
> On Thu, Feb 18, 2016 at 10:11 PM,   wrote:
>> Almost everything points positively for Python. Thanks to all of you who 
>> have responded. But please also tell me the disadvantages of Python. If I 
>> start using Python, I should be aware of the price I am paying. Speed is not 
>> a big problem for me, so an interpreted language is fine. Is 
>> packaging/installing very messy? Do I create dozens of files for a simple 
>> program calculating the sum of two numbers and product of two numbers in 
>> text boxes with one command to be clicked? Can I learn this much in the 
>> first couple of hours?
>>
>
> There are a few warts, particularly on Windows, as regards packaging
> and third-party modules. Anything that's written in pure Python is
> fairly easy; stuff that's written in C is sometimes a bit hairy. But
> that's a limitation on the "extended library" of PyPI, not the stuff
> that comes with Python itself.

For packaging/installing it really depends on what you're trying to
do. You have to understand that Python is used in many very different
ways in different environments and ecosystems so there just isn't a
single way of doing it.

It sounds to me as if all of your needs can be solved in pure Python
code possibly using some of the popular extension modules from PyPI.
In this case it's actually very easy to package/install. You can
package your code simply by zipping it up with a __main__.py file.
Someone who wants to install it will simply have a two step process:
first install Python (and possibly a few dependencies) and then obtain
the zip file with your code in it.

--
Oscar
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[William Ray Wing]

> On Feb 17, 2016, at 2:49 PM, wrong.addres...@gmail.com wrote:
> 
> I am mostly getting positive feedback for Python.
> 
> It seems Python is used more for web based applications. Is it equally fine 
> for creating stand-alone *.exe's? Can the same code be compiled to run on 
> Linux or Android or web-based?
> 
> Is it possible to create GUI elements with a good IDE? Can they be defined 
> like in Visual Basic with given sizes, fonts, visible/invisible, etc.?
> 
> Is it easy to do matrix operations in Python? Or do I need to write 
> subroutines like in Visual Basic?
> 
> Could someone kindly tell me advantages and disadvantages of Python? Or any 
> better options? I have like 40-50 VB Forms and may be around 2 lines of 
> code. It will be a task to learn a new language and translate/re-write that 
> code.
> 

At this point you’ve probably heard more than you wanted to *about* Python.  
The next step really ought to be simply to invest a few minutes in looking at 
the language itself.
Start here by downloading a copy of the Python interpreter:

https://www.python.org/downloads/windows/

Then, there is an extensive list of on-line tutorial material here:

https://wiki.python.org/moin/BeginnersGuide/Programmers

I’d recommend simply picking one and diving in. If you have questions (and you 
surely will), come back here or, at least initially, send them to the Python 
Tutor list (tu...@python.org).

Good luck and have fun,
Bill


> Thanks for your responses. 
> -- 
> https://mail.python.org/mailman/listinfo/python-list

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[Chris Angelico]

On Thu, Feb 18, 2016 at 10:11 PM,   wrote:
> Almost everything points positively for Python. Thanks to all of you who have 
> responded. But please also tell me the disadvantages of Python. If I start 
> using Python, I should be aware of the price I am paying. Speed is not a big 
> problem for me, so an interpreted language is fine. Is packaging/installing 
> very messy? Do I create dozens of files for a simple program calculating the 
> sum of two numbers and product of two numbers in text boxes with one command 
> to be clicked? Can I learn this much in the first couple of hours?
>

There are a few warts, particularly on Windows, as regards packaging
and third-party modules. Anything that's written in pure Python is
fairly easy; stuff that's written in C is sometimes a bit hairy. But
that's a limitation on the "extended library" of PyPI, not the stuff
that comes with Python itself.

Your simple example could easily be a single file. Python tends to
eschew boilerplate; its motto comes from Baloo - look for the bare
necessities of life.

For a first couple of hours, I would recommend working at the console
or in Idle, rather than creating a GUI; a window takes a bit of extra
effort (plus you have choices in how to do that), so just learn the
language first. But you could easily advance to building a GUI within
your first day of learning Python, if that's the direction you want to
go.

The biggest disadvantage of Python is that, in a number of ways, it
surprises people. Significant whitespace bugs a lot of experienced
programmers (and some tools, too), and there are a few other ways that
you may find a team of people revile against it. But if you can deal
with the social aspects, it's a solid language.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[wrong . address . 1]

Almost everything points positively for Python. Thanks to all of you who have 
responded. But please also tell me the disadvantages of Python. If I start 
using Python, I should be aware of the price I am paying. Speed is not a big 
problem for me, so an interpreted language is fine. Is packaging/installing 
very messy? Do I create dozens of files for a simple program calculating the 
sum of two numbers and product of two numbers in text boxes with one command to 
be clicked? Can I learn this much in the first couple of hours?

torstai 18. helmikuuta 2016 12.16.30 UTC+2 Chris Angelico kirjoitti:
> On Thu, Feb 18, 2016 at 7:17 PM,   wrote:
> > Thanks to all of you who have responded. One point two of you ask me is why 
> > I want to shift from Visual Basic.
> >
> > Most of my software is in VB6 (and VB3), and converting to VB.net is not 
> > very pleasant. I have learnt enough VB.net to manage most of the things I 
> > will need, but it always gives me a feeling that it is not meant for the 
> > kind of things I am doing. And you never know when Microsoft will kick us 
> > out of VB.net also. For the sake of keeping software compatible with new 
> > versions of Windows, you need to keep changing things in the software, 
> > which takes too much time. You might ask if it is really necessary to move 
> > from VB6 to VB.net because Microsoft will still not be able to kill VB6 
> > very soon, thanks to VBA used in Excel. If my reasoning is wrong, please 
> > correct me. I am just an engineer, not a good programmer.
> >
> 
> Very fair point. And I fully support your move, here. Just make sure
> you start on the latest Python (currently that's 3.5), and you should
> have no difficulty moving forward in versions; as someone who started
> writing Python 3 code back when 3.3 was the newest and latest thing, I
> can attest that it's been easy to migrate 3.2->3.3->3.4->3.5->3.6;
> there are very few things that get broken by the upgrade, and they're
> mostly things that would have been bad code in the older version
> anyway.
> 
> >> The basic python language and its libraries are completely cross-platform 
> >> (Linux, OS-X, Windows, iOS, and Android).  The same source code will run 
> >> on all of them.  However, because it is an Interpreted language, the step 
> >> to a bundled, self-contained image is platform dependent. There python 
> >> compliers (as opposed to interpreters) for some, but not all platforms, 
> >> and there is a very active JiT compiler project that would fall somewhere 
> >> in between.
> >>
> >
> > OK. This is clear to me now. It is like needing different Fortran compilers 
> > for different operating systems, but Fortran code does not need much 
> > modifications (except file names/paths, etc.).
> >
> 
> Something like that. There are a lot of little traps you can fall into
> (as you say, file names can be different, especially system ones) that
> stop your code from running correctly on all platforms, but porting a
> Python script from Linux to Windows or vice versa is a matter of
> testing it on the new platform and seeing what breaks, not completely
> rewriting it in a new language.
> 
> >> > Could someone kindly tell me advantages and disadvantages of Python?
> >>
> >> If you are completely satisfied with VB, there is no reason to change 
> >> (other than the enjoyable exercise of learning a new and more powerful 
> >> language).
> >>
> >
> > Will VB6 run on Windows 11? Or can I compile VB6 on Windows 11. We can't 
> > know. But there will be easy ways to run Python on any Windows version or 
> > Linux or whatever.
> >
> 
> There will indeed. That's the advantage of a fully open system - even
> if a nuclear meltdown kills all the Python core devs in one stroke (we
> really shouldn't have had PyCon Chernobyl), anyone in the world can
> pick up the source code and keep going with it. And Microsoft, despite
> having a strongly anti-freedom history, has come far more on board of
> recent years; as I understand it, Steve Dower has been spending
> company time improving Python (notably in the area of Windows
> installers and such). The future of open source software is pretty
> secure, and the future of openly-developed languages even more so,
> because CPython isn't the only way to run your Python code.
> 
> One Python advantage that you may or may not be aware of is its
> extensibility. To an extent that I haven't seen since working with
> REXX on OS/2, there is a thriving community building Python packages,
> many of which (about 75K!) are listed on PyPI [1]. Got this
> proprietary database that you need to get info from? Check PyPI -
> chances are someone's written a connector for it, so you can perform
> queries on it as if it had native support in the language. Once you
> install something using "pip" [2], you can import it into your script
> the exact same way that you would import something from the standard
> library - making PyPI kinda like the "extended 

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[Chris Angelico]

On Thu, Feb 18, 2016 at 7:17 PM,   wrote:
> Thanks to all of you who have responded. One point two of you ask me is why I 
> want to shift from Visual Basic.
>
> Most of my software is in VB6 (and VB3), and converting to VB.net is not very 
> pleasant. I have learnt enough VB.net to manage most of the things I will 
> need, but it always gives me a feeling that it is not meant for the kind of 
> things I am doing. And you never know when Microsoft will kick us out of 
> VB.net also. For the sake of keeping software compatible with new versions of 
> Windows, you need to keep changing things in the software, which takes too 
> much time. You might ask if it is really necessary to move from VB6 to VB.net 
> because Microsoft will still not be able to kill VB6 very soon, thanks to VBA 
> used in Excel. If my reasoning is wrong, please correct me. I am just an 
> engineer, not a good programmer.
>

Very fair point. And I fully support your move, here. Just make sure
you start on the latest Python (currently that's 3.5), and you should
have no difficulty moving forward in versions; as someone who started
writing Python 3 code back when 3.3 was the newest and latest thing, I
can attest that it's been easy to migrate 3.2->3.3->3.4->3.5->3.6;
there are very few things that get broken by the upgrade, and they're
mostly things that would have been bad code in the older version
anyway.

>> The basic python language and its libraries are completely cross-platform 
>> (Linux, OS-X, Windows, iOS, and Android).  The same source code will run on 
>> all of them.  However, because it is an Interpreted language, the step to a 
>> bundled, self-contained image is platform dependent. There python compliers 
>> (as opposed to interpreters) for some, but not all platforms, and there is a 
>> very active JiT compiler project that would fall somewhere in between.
>>
>
> OK. This is clear to me now. It is like needing different Fortran compilers 
> for different operating systems, but Fortran code does not need much 
> modifications (except file names/paths, etc.).
>

Something like that. There are a lot of little traps you can fall into
(as you say, file names can be different, especially system ones) that
stop your code from running correctly on all platforms, but porting a
Python script from Linux to Windows or vice versa is a matter of
testing it on the new platform and seeing what breaks, not completely
rewriting it in a new language.

>> > Could someone kindly tell me advantages and disadvantages of Python?
>>
>> If you are completely satisfied with VB, there is no reason to change (other 
>> than the enjoyable exercise of learning a new and more powerful language).
>>
>
> Will VB6 run on Windows 11? Or can I compile VB6 on Windows 11. We can't 
> know. But there will be easy ways to run Python on any Windows version or 
> Linux or whatever.
>

There will indeed. That's the advantage of a fully open system - even
if a nuclear meltdown kills all the Python core devs in one stroke (we
really shouldn't have had PyCon Chernobyl), anyone in the world can
pick up the source code and keep going with it. And Microsoft, despite
having a strongly anti-freedom history, has come far more on board of
recent years; as I understand it, Steve Dower has been spending
company time improving Python (notably in the area of Windows
installers and such). The future of open source software is pretty
secure, and the future of openly-developed languages even more so,
because CPython isn't the only way to run your Python code.

One Python advantage that you may or may not be aware of is its
extensibility. To an extent that I haven't seen since working with
REXX on OS/2, there is a thriving community building Python packages,
many of which (about 75K!) are listed on PyPI [1]. Got this
proprietary database that you need to get info from? Check PyPI -
chances are someone's written a connector for it, so you can perform
queries on it as if it had native support in the language. Once you
install something using "pip" [2], you can import it into your script
the exact same way that you would import something from the standard
library - making PyPI kinda like the "extended library" for the
language. The barrier to entry is low, though, so you do sometimes
have to wade through a bunch of stagnant or expired projects to find
the gems you want. But there's so much good stuff there that it's well
worth the effort.

ChrisA

[1] https://pypi.python.org/pypi
[2] No, not the chipmunk from Enchanted.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[Oscar Benjamin]

On 18 February 2016 at 08:17,   wrote:
> Is it easy to create vector graphics files of plots in Python?

Yes

> In VB6, I wrote my own code to generate EPS files. Then people who demand jpg 
> and gif files could be given those by converting the EPS with the desired 
> resolution.

That sounds a lot harder than doing it in Python using matplotlib. To
run the following you need Python, numpy and matplotlib:

-
from matplotlib import pyplot as plt

xdata = [0, 1, 2, 3, 4]
ydata = [0, 1, 0, 1, 0]

fig = plt.figure(figsize=(4, 3))
ax = fig.add_axes([0.15, 0.15, 0.70, 0.70])
ax.plot(xdata, ydata, color='black', linewidth=2)
ax.set_xlabel('$V_x$') # Latex math-mode in text
ax.set_ylabel('$V_y$')

plt.show() # Make the plot window appear on screen
-

The last line can be replaced with a call to fig.savefig if you want
the plot to go straight to a file. The format is inferred from the
filename so:

fig.savefig('plot.eps') # Do you really want eps?
fig.savefig('plot.pdf') # I'd use pdf
fig.savefig('plot.jpg') # etc.

--
Oscar
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[wrong . address . 1]

Thanks to all of you who have responded. One point two of you ask me is why I 
want to shift from Visual Basic. 

Most of my software is in VB6 (and VB3), and converting to VB.net is not very 
pleasant. I have learnt enough VB.net to manage most of the things I will need, 
but it always gives me a feeling that it is not meant for the kind of things I 
am doing. And you never know when Microsoft will kick us out of VB.net also. 
For the sake of keeping software compatible with new versions of Windows, you 
need to keep changing things in the software, which takes too much time. You 
might ask if it is really necessary to move from VB6 to VB.net because 
Microsoft will still not be able to kill VB6 very soon, thanks to VBA used in 
Excel. If my reasoning is wrong, please correct me. I am just an engineer, not 
a good programmer.

Is it easy to create vector graphics files of plots in Python? In VB6, I wrote 
my own code to generate EPS files. Then people who demand jpg and gif files 
could be given those by converting the EPS with the desired resolution.

More points in the text below.

William Ray Wing writes:
> > On Feb 17, 2016, at 2:49 PM, wrong.addres...@gmail.com wrote:
> > 
> > It seems Python is used more for web based applications. Is it equally fine 
> > for creating stand-alone *.exe's? Can the same code be compiled to run on 
> > Linux or Android or web-based?
> > 
> 
> I'm not sure where you got that idea.  Python has been and is being used for 
> an extremely broad range of applications.  At one extreme, the popular 
> YouTube site is based on Python (and yes, that is a web application), at the 
> other extreme much (most?) of the data analysis of the recent LIGO data 
> leading up to the discovery of gravitational waves was done in Python, and 
> numpy (a python numerical library); with the results displayed in matplotlib 
> (a python library for scientific-engineering graphics).
> 

This is good news, because I need several kinds of plots.

> The basic python language and its libraries are completely cross-platform 
> (Linux, OS-X, Windows, iOS, and Android).  The same source code will run on 
> all of them.  However, because it is an Interpreted language, the step to a 
> bundled, self-contained image is platform dependent. There python compliers 
> (as opposed to interpreters) for some, but not all platforms, and there is a 
> very active JiT compiler project that would fall somewhere in between. 
> 

OK. This is clear to me now. It is like needing different Fortran compilers for 
different operating systems, but Fortran code does not need much modifications 
(except file names/paths, etc.).

> > Is it possible to create GUI elements with a good IDE? Can they be defined 
> > like in Visual Basic with given sizes, fonts, visible/invisible, etc.?
> > 
> 
> There are several GUI libraries for Python.  You might check out TK (which 
> comes built-in), but there are also libraries like wxPython, Kivi (which is 
> completely cross platform), and PyQt.  Note that these are the GUI libraries 
> themselves, not IDE's which tend to be independent.  There are too many IDE's 
> to list here - check with Google.
> 
> > Is it easy to do matrix operations in Python? Or do I need to write 
> > subroutines like in Visual Basic?
> 
> Matrix (and similar operations) can be done in Python directly, but if you 
> need maximum performance you should use the optimized vector routines 
> available 

Speed is usually not an issue.

> in numpy, these are typically pre-compiled with C or FORTRAN and squeeze out 
> the maximum speed your hardware is capable of.  (There is work being done to 
> migrate them to GPUs, but is VERY hardware dependent at this point.) If you 
> need to do scientific/engineering analysis, you should also check out scipy, 
> which is built on top of it and is also vector optimized.
> 
> > 
> > Could someone kindly tell me advantages and disadvantages of Python?
> 
> If you are completely satisfied with VB, there is no reason to change (other 
> than the enjoyable exercise of learning a new and more powerful language).
> 

Will VB6 run on Windows 11? Or can I compile VB6 on Windows 11. We can't know. 
But there will be easy ways to run Python on any Windows version or Linux or 
whatever.

> On the other hand, Python has often been referred to as "executable pseudo 
> code" - in other words, the english-like steps you might sketch out to 
> outline the solution to a programming problem in another language is to all 
> intents and purposes Python itself.  This makes for very fast and productive 
> code generation with typically fewer errors than are made in other languages. 
> In addition, and as has been implied above, it is cross platform.  The same 
> python source code (with the appropriate libraries) will run on all the 
> platforms mentioned above. One of the biggest productive features of Python 
> is the fact that it is interpreted (in its most common instantiation).  Thus, 
> you can 

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[William Ray Wing]

> On Feb 17, 2016, at 2:49 PM, wrong.addres...@gmail.com wrote:
> 
> I am mostly getting positive feedback for Python.
> 

I would be surprised if you weren’t.

> It seems Python is used more for web based applications. Is it equally fine 
> for creating stand-alone *.exe's? Can the same code be compiled to run on 
> Linux or Android or web-based?
> 

I’m not sure where you got that idea.  Python has been and is being used for an 
extremely broad range of applications.  At one extreme, the popular YouTube 
site is based on Python (and yes, that is a web application), at the other 
extreme much (most?) of the data analysis of the recent LIGO data leading up to 
the discovery of gravitational waves was done in Python, and numpy (a python 
numerical library); with the results displayed in matplotlib (a python library 
for scientific-engineering graphics).

The basic python language and its libraries are completely cross-platform 
(Linux, OS-X, Windows, iOS, and Android).  The same source code will run on all 
of them.  However, because it is an Interpreted language, the step to a 
bundled, self-contained image is platform dependent. There python compliers (as 
opposed to interpreters) for some, but not all platforms, and there is a very 
active JiT compiler project that would fall somewhere in between. 

> Is it possible to create GUI elements with a good IDE? Can they be defined 
> like in Visual Basic with given sizes, fonts, visible/invisible, etc.?
> 

There are several GUI libraries for Python.  You might check out TK (which 
comes built-in), but there are also libraries like wxPython, Kivi (which is 
completely cross platform), and PyQt.  Note that these are the GUI libraries 
themselves, not IDE’s which tend to be independent.  There are too many IDE’s 
to list here - check with Google.

> Is it easy to do matrix operations in Python? Or do I need to write 
> subroutines like in Visual Basic?

Matrix (and similar operations) can be done in Python directly, but if you need 
maximum performance you should use the optimized vector routines available in 
numpy, these are typically pre-compiled with C or FORTRAN and squeeze out the 
maximum speed your hardware is capable of.  (There is work being done to 
migrate them to GPUs, but is VERY hardware dependent at this point.) If you 
need to do scientific/engineering analysis, you should also check out scipy, 
which is built on top of it and is also vector optimized.

> 
> Could someone kindly tell me advantages and disadvantages of Python?

If you are completely satisfied with VB, there is no reason to change (other 
than the enjoyable exercise of learning a new and more powerful language).

On the other hand, Python has often been referred to as “executable pseudo 
code” - in other words, the english-like steps you might sketch out to outline 
the solution to a programming problem in another language is to all intents and 
purposes Python itself.  This makes for very fast and productive code 
generation with typically fewer errors than are made in other languages. In 
addition, and as has been implied above, it is cross platform.  The same python 
source code (with the appropriate libraries) will run on all the platforms 
mentioned above. One of the biggest productive features of Python is the fact 
that it is interpreted (in its most common instantiation).  Thus, you can have 
two windows open side by side, with the source code in one and running code in 
the other.  Changes in the source code can instantly be reflected in the output.

> Or any better options? I have like 40-50 VB Forms and may be around 2 
> lines of code. It will be a task to learn a new language and 
> translate/re-write that code.
> 

Not necessarily better, but at least worth looking into would be the Swift 
language, which shares much of Python’s modern structure, is now also open 
source, and has been ported to most flavors of Linux.  A Window’s port is 
promised, but I don’t know how far along it is.  It *is* a compiled language, 
so you would then be back in the edit, compile, link, and run loop as you debug 
your code.

I’m sure you will get lots of other answers - Google each of the things I’ve 
mentioned and you will get a truck-load of info.  You might start with 
Wikipedia and read there about Python and Swift.

> Thanks for your responses. 
> -- 
> https://mail.python.org/mailman/listinfo/python-list

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[paul . hermeneutic]

On Wed, Feb 17, 2016 at 12:49 PM,   wrote:
> Could someone kindly tell me advantages and disadvantages of Python? Or any 
> better options? I have like 40-50 VB Forms and may be around 2 lines of 
> code. It will be a task to learn a new language and translate/re-write that 
> code.

Why are you looking to change from VB? Too slow? Cannot run on
anything but Windows? Buggy?

I, like most people here, would encourage you to learn Python 3.
However, there is something to be said for "if it ain't broke, don't
fix it."
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[Ray Cote]

On Wed, Feb 17, 2016 at 3:54 PM, Rob Gaddi <
rgaddi@highlandtechnology.invalid> wrote:

> > It seems Python is used more for web based applications. Is it equally
> fine for creating stand-alone *.exe's? Can the same code be compiled to run
> on Linux or Android or web-based?
>
> Standalone EXEs are hit and miss.  I've had best luck deploying just as
> Python scripts to machines with an expectation that the environment is
> already configured (i.e. Python already installed).
>
> You don't compile, you interpret.  So long as you've got the
> interpreter on the target platform you're set.  The EXE tools out there
> do so by bundling your plain-text source up with the interpreter
> environment.
>
> Packaging/distribution remains one of the real pain points in Python.
>

Python is used for much more then web based applications.
The latest versions of pyInstaller (http://www.pyinstaller.org) are
incredibly good at generating single-file binaries for both Windows and
Linux.
We’re using pyInstaller to distribute applications based on some fairly
complex frameworks—including wxPython (http://www.wxpython.org)
which is one option for building GUI applications.

—Ray




-- 
Raymond Cote, President
voice: +1.603.924.6079 email: rgac...@appropriatesolutions.com skype:
ray.cote
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[Rob Gaddi]

wrong.addres...@gmail.com wrote:

> I am mostly getting positive feedback for Python.

Welcome to the party.  Learn to write Python 3.  There is no reason
whatsoever for someone picking up Python to learn the deprecated
problems of Python 2.

> It seems Python is used more for web based applications. Is it equally fine 
> for creating stand-alone *.exe's? Can the same code be compiled to run on 
> Linux or Android or web-based?

Standalone EXEs are hit and miss.  I've had best luck deploying just as
Python scripts to machines with an expectation that the environment is
already configured (i.e. Python already installed).

You don't compile, you interpret.  So long as you've got the
interpreter on the target platform you're set.  The EXE tools out there
do so by bundling your plain-text source up with the interpreter
environment.

Packaging/distribution remains one of the real pain points in Python.

> Is it possible to create GUI elements with a good IDE? Can they be defined 
> like in Visual Basic with given sizes, fonts, visible/invisible, etc.?
>

Yep, and you've got your choice of GUI toolkits (which has ups and
downs).  Coming from VB you're probably used to graphical designers, in
which case I'd point you to Qt Designer and PySide or PyQt.

> Is it easy to do matrix operations in Python? Or do I need to write 
> subroutines like in Visual Basic?

Here's where Python's a godsend.  NumPy will give you vectors, matrices,
linear algebra, all manner of good stuff, all compiled to be blindingly
fast.

Depending on what you mean by engineering applications there's a
ton of good stuff in SciPy too; as an EE I make pretty extensive use
of SciPy's signal processing and optimization packages. Matplotlib is
the 3rd piece of the puzzle and behold! you have graphs, as simple or
complex as you'd like.

> Could someone kindly tell me advantages and disadvantages of Python? Or any 
> better options? I have like 40-50 VB Forms and may be around 2 lines of 
> code. It will be a task to learn a new language and translate/re-write that 
> code.
>

It will be, and I'm not sure I'd recommend doing it.  The last time I
wrote any VB was Windows 3.1, and the .NET framework wasn't even a gleam
in Paul Allen's ey.  So I can't speak too authoratively on what you're
leaving. But over the years I've probably tried to get work done in
two dozen languages. None of them turn out correct code more quickly
than Python; few even come close.

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[sohcahtoa82]

On Wednesday, February 17, 2016 at 11:49:44 AM UTC-8, wrong.a...@gmail.com 
wrote:
> I am mostly getting positive feedback for Python.

Good!

> 
> It seems Python is used more for web based applications. Is it equally fine 
> for creating stand-alone *.exe's? Can the same code be compiled to run on 
> Linux or Android or web-based?


Python is not traditionally compiled.  It is interpreted.  That said, there are 
utilities out there than can compile a Python script to a Windows executable.  
I personally have never used them, so I don't know about their limitations.

As for Android, I've heard of frameworks for making Android apps with Python, 
but I don't know of any off the top of my head.

> 
> Is it possible to create GUI elements with a good IDE? Can they be defined 
> like in Visual Basic with given sizes, fonts, visible/invisible, etc.?

I'm fairly certain there are GUI editors for Python.  I don't use any because I 
don't write anything with a GUI.

> 
> Is it easy to do matrix operations in Python? Or do I need to write 
> subroutines like in Visual Basic?

Check out the numpy and scipy packages.

> 
> Could someone kindly tell me advantages and disadvantages of Python? Or any 
> better options? I have like 40-50 VB Forms and may be around 2 lines of 
> code. It will be a task to learn a new language and translate/re-write that 
> code.

IMO, Python's greatest advantage is readability.  Python's syntax just plain 
makes sense to me.  It is just an easy language to work with.  It's funny, 
really.  I used to be a hardcore C/C++ fanatic.  When I first started learning 
Python, I hated it.  I thought it made things too easy and held your hand too 
much.  Now, I love it because it makes things so easy and holds your hand.  I 
spend less time worrying about memory allocation and pointer syntax and more 
time actually getting things done.

I think Python's biggest disadvantage is performance.  If you write 100% pure 
Python code, it can be a bit on the slower side.  However, if you're doing 
heavy number crunching using numpy/scipy, they're mostly written in C and are 
quite fast.

Basically, the way I see it, if speed of development is much more important 
than speed of execution, typically Python is a good choice.

> 
> Thanks for your responses.

I'm hoping someone else will be able to give a better response to Python on 
Android and the GUI editor.
-- 
https://mail.python.org/mailman/listinfo/python-list