Considering migrating to Python from Visual Basic 6 for engineering applications

[wrong.a...@gmail.com]

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 20000 lines of code. It will be a task to learn a new language and translate/re-write that code.

Thanks for your responses.

[sohca...@gmail.com]

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

[Rob Gaddi]

wrong.a...@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 20000 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.

[Ray Cote]

On Wed, Feb 17, 2016 at 3:54 PM, Rob Gaddi <
rga...@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: rga...@AppropriateSolutions.com skype:
ray.cote

[paul.her...@gmail.com]

On Wed, Feb 17, 2016 at 12:49 PM, <wrong.a...@gmail.com> 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 20000 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."

[William Ray Wing]

> On Feb 17, 2016, at 2:49 PM, wrong.a...@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 20000 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

[wrong.a...@gmail.com]

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.a...@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 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 20000 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.

Thanks again to all of you who have responded.

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

[wxjm...@gmail.com]

The single solid and reliable GUI toolkits are
Jython or IronPython.

A serious - exotic - solution, like "PyUNO" in LibreOffice,
is all but satisfying.

jmf

[Oscar Benjamin]

On 18 February 2016 at 08:17, <wrong.a...@gmail.com> 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

[Chris Angelico]

On Thu, Feb 18, 2016 at 7:17 PM, <wrong.a...@gmail.com> 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.

[wrong.a...@gmail.com]

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?

[Chris Angelico]

On Thu, Feb 18, 2016 at 10:11 PM, <wrong.a...@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.

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

[William Ray Wing]

> On Feb 17, 2016, at 2:49 PM, wrong.a...@gmail.com wrote:
>

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

[Oscar Benjamin]

On 18 February 2016 at 11:32, Chris Angelico <ros...@gmail.com> wrote:
> On Thu, Feb 18, 2016 at 10:11 PM, <wrong.a...@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

[wrong.a...@gmail.com]

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

[wrong.a...@gmail.com]

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.

[Oscar Benjamin]

On 18 February 2016 at 15:33, <wrong.a...@gmail.com> 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

[wrong.a...@gmail.com]

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.

[William Ray Wing]

> On Feb 18, 2016, at 10:33 AM, wrong.a...@gmail.com wrote:
>
> 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:
>>

[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

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

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

[Chris Angelico]

On Fri, Feb 19, 2016 at 2:49 AM, <wrong.a...@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

[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: pytho...@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.a...@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

[wrong.a...@gmail.com]

On Thursday, 18 February 2016 17:59:59 UTC+2, William Ray Wing wrote:
> > On Feb 18, 2016, at 10:33 AM, wrong.a...@gmail.com wrote:
> >
> > 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:
> >>
>
> [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

[wrong.a...@gmail.com]

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

[wrong.a...@gmail.com]

On Thursday, 18 February 2016 18:06:29 UTC+2, Chris Angelico wrote:
> On Fri, Feb 19, 2016 at 2:49 AM, <wrong.a...@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.
>

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.

[wrong.a...@gmail.com]

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.

[Tim Chase]

On 2016-02-18 09:58, wrong.a...@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

[Tim Chase]

On 2016-02-18 07:33, wrong.a...@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

[Dietmar Schwertberger]

On 18.02.2016 18:49, wrong.a...@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

[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

[Chris Angelico]

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

[Ben Finney]

Chris Angelico <ros...@gmail.com> writes:

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

To be fair, there is good reason for the programming (and broader IT)
community to have a heuristic of “significant whitespace is probably
bad”.

The few languages that did this badly (Makefile syntax, some Unix shell
syntax) leave a legacy of countless headaches and you can't fix the
language retroactively without breaking backward compatibility.

So I am sympathetic to Python newcomers recoiling in horror from
significant whitespace, *before* they try it. And because of that, we
are burdened with forever needing to deal with that reaction and
soothing it.

Those people who claim to have tried Python and *still* complain about
“significant whitespace”, I have no sympathy for. Python clearly does it
right, and it's a huge boon to readability and reducing simple errors.

--
\ “He was the mildest-mannered man / That ever scuttled ship or |
`\ cut a throat.” —“Lord” George Gordon Noel Byron, _Don Juan_ |
_o__) |
Ben Finney

[Steven D'Aprano]

On Fri, 19 Feb 2016 02:35 am, wrong.a...@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

[Mark Lawrence]

On 18/02/2016 11:32, Chris Angelico wrote:
> On Thu, Feb 18, 2016 at 10:11 PM, <wrong.a...@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.
>

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

[BartC]

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

--
Bartc

[Marko Rauhamaa]

Ben Finney <ben+p...@benfinney.id.au>:

> So I am sympathetic to Python newcomers recoiling in horror from
> significant whitespace, *before* they try it. And because of that, we
> are burdened with forever needing to deal with that reaction and
> soothing it.

I remember being *very* doubtful how the whitespace would work in
practice. I was won over by a colleague who had sloppy indentation
habbits in C++ but produced tidy, readable code in Python.

> Those people who claim to have tried Python and *still* complain about
> “significant whitespace”,

I am bitten by it occasionally. The editor doesn't know from the context
how a line or block should be (re)indented. In Emacs, TAB, BS and C-M-\,
which keep source code properly indented in other programming languages,
have been known to lead to accidental bugs in Python code. (The proper
way in Emacs is to use C-> and C-< to manipulate blocks of Python code.)

> I have no sympathy for. Python clearly does it right, and it's a huge
> boon to readability and reducing simple errors.

I don't mind Python's syntax. It's the implicit semicolons of JavaScript
and Go that I dislike.


Marko

[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

[wrong.a...@gmail.com]

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?

[wrong.a...@gmail.com]

On Friday, 19 February 2016 03:06:58 UTC+2, Steven D'Aprano wrote:
> On Fri, 19 Feb 2016 02:35 am, wrong.a...@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.

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

[Mark Lawrence]

On 19/02/2016 10:47, wrong.a...@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.

[Tony van der Hoff]

On 19/02/16 11:23, Mark Lawrence wrote:
> On 19/02/2016 10:47, wrong.a...@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:to...@vanderhoff.org
Buckinghamshire, England |

[wrong.a...@gmail.com]

On Friday, 19 February 2016 13:24:46 UTC+2, Mark Lawrence wrote:
> On 19/02/2016 10:47, wrong.a...@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.

[Tim Chase]

On 2016-02-19 02:47, wrong.a...@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

[Grant Edwards]

On 2016-02-19, Ben Finney <ben+p...@benfinney.id.au> wrote:

> So I am sympathetic to Python newcomers recoiling in horror from
> significant whitespace, *before* they try it. And because of that, we
> are burdened with forever needing to deal with that reaction and
> soothing it.

The first time I wrote Python (it was the only language I could find
that was free and for which I found understandable examples on how to
suck e-mail messages out of Outlook using DCOM -- which was the
problem to be solved), I had an initial aversion to the "significant
whitespace" concept. That immediately vanished once I started working
on my first Python code. That was Python 1.5.2 back in 1999. Shortly
after that, I went to the trouble to add raw socket support to the
Python standard library "socket" module so that I could use Python for
some other tasks. :)

> Those people who claim to have tried Python and *still* complain
> about “significant whitespace”, I have no sympathy for.

I, on the other hand, do feel sorry for them because their brains are
evidently broken in some basic manner that can't help but cause them
suffering.

> Python clearly does it right, and it's a huge boon to readability
> and reducing simple errors.

Indeed.

--
Grant Edwards grant.b.edwards Yow! Used staples are good
at with SOY SAUCE!
gmail.com

[Peter Otten]

Tim Chase wrote:

> On 2016-02-19 02:47, wrong.a...@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

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("iiiii", 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 <module>
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 ;)

[BartC]

On 17/02/2016 19:49, wrong.a...@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

[Chris Angelico]

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

[Grant Edwards]

On 2016-02-19, BartC <b...@freeuk.com> wrote:
> On 17/02/2016 19:49, wrong.a...@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.edwards Yow! I would like to
at urinate in an OVULAR,
gmail.com porcelain pool --

[Grant Edwards]

On 2016-02-19, Chris Angelico <ros...@gmail.com> 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.edwards Yow! I like your SNOOPY
at POSTER!!
gmail.com

[BartC]

On 19/02/2016 15:59, Grant Edwards wrote:
> On 2016-02-19, BartC <b...@freeuk.com> wrote:
>> On 17/02/2016 19:49, wrong.a...@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

[Chris Angelico]

On Sat, Feb 20, 2016 at 3:32 AM, BartC <b...@freeuk.com> 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

[Matt Wheeler]

On 19 February 2016 at 14:58, Peter Otten <__pet...@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

[Grant Edwards]

On 2016-02-19, BartC <b...@freeuk.com> 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.edwards Yow! I'd like some JUNK
at FOOD ... and then I want to
gmail.com be ALONE --

[wrong.a...@gmail.com]

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.

[BartC]

On 19/02/2016 18:14, wrong.a...@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

[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

[William Ray Wing]

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

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

Bill

[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 20000 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

[Larry Hudson]

On 02/19/2016 10:14 AM, wrong.a...@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.

<code>
# 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
</code>

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

[Steven D'Aprano]

On Fri, 19 Feb 2016 10:53 pm, wrong.a...@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

[wxjm...@gmail.com]

Le mercredi 17 février 2016 20:49:44 UTC+1, wrong.a...@gmail.com a écrit :
> 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 20000 lines of code. It will be a task to learn a new language and translate/re-write that code.
>
> Thanks for your responses.

- Choose a language which is Unicode.org compliant.
- Choose a language which does not crash as soon as
non ascii characters are used (even within BMP).
- Choose a language which support a working GUI toolkit.

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

[wrong.a...@gmail.com]

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 to read numbers from several files usually), here is some VB6 code:

Open "N020S.TXT" For Input As #8

Input #8, ND, NIN, NT ' all integers
Text9.Text = ND
Text1 = CStr(NIN)
Text4 = NT

Text12 = ""
For i = 1 To NIN
Input #8, DINCOL(i) ' single precision floating point vector
Text12 = Text12.Text & DINCOL(i) & " "
If Dvarname(1) <> "" Then varname(i) = Dvarname(NLCOL(i)) ' strings
Next i

etc..

The data file (written by another VB6 code) contains in the first few lines:

10 6 1
8.65 0.2192347 3.33E-4 44 0.0051 6
9
1
2 1
3

How complicated could this get in Python? Reading the numbers is one thing, and then placing the values in text boxes of the GUI. 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?

[wrong.a...@gmail.com]

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

[wrong.a...@gmail.com]

Thanks. This gives me some more confidence that it will be a good choice for my work as well.

[wrong.a...@gmail.com]

This will definitely be useful to me in the early phase.

[Christian Gollwitzer]

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

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

[Roel Schroeven]

wrong.a...@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

[Mike S]

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!

[Larry Hudson]

On 02/20/2016 10:38 AM, wrong.a...@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 -=-

[BartC]

On 21/02/2016 07:28, Larry Hudson wrote:
> On 02/20/2016 10:38 AM, wrong.a...@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

[Chris Angelico]

On Mon, Feb 22, 2016 at 12:16 AM, BartC <b...@freeuk.com> wrote:
> On 21/02/2016 07:28, Larry Hudson wrote:
>>
>> On 02/20/2016 10:38 AM, wrong.a...@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

[Jussi Piitulainen]

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 = ''' 10 6 1

8.65 0.2192347 3.33E-4 44 0.0051 6
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

[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

10 6 1
8.65 0.2192347 3.33E-4 44 0.0051 6

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

[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

[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

[Jussi Piitulainen]

BartC writes:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>>> def awkward():
a = int(input('int> '))
b = int(input('int> '))
c = int(input('int> '))
istriangle(a, b, c)

>>> awkward()
int> 3
int> 1
int> 4
>>> # oops

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

>>> awkward()
int> 5
int> 4
int> 3
True
>>>

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

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

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

Not at all. Once you've got the hang of reading a line of interactive
input, then the same program can be given redirected input from a file.
And the OP's example was reading from a file anyway.

(Some formats will need more sophisticating parsing; that's advanced
stuff though. Advanced enough in fact that you wouldn't attempt parsing
them; just use a library.)

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.

Would it have hurt to have done so? Then it would be easier also to port
existing programs.

--
Bartc

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

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

[...]

[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

[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

[Jussi Piitulainen]

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.

[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

[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

[Chris Angelico]

On Mon, Feb 22, 2016 at 11:51 PM, BartC <b...@freeuk.com> 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

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

[BartC]

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

[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