Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #103064 > unrolled thread

Considering migrating to Python from Visual Basic 6 for engineering applications

Started bywrong.address.1@gmail.com
First post2016-02-17 11:49 -0800
Last post2016-02-20 10:47 -0800
Articles 20 on this page of 94 — 31 participants

Back to article view | Back to comp.lang.python


Contents

  Considering migrating to Python from Visual Basic 6 for engineering applications wrong.address.1@gmail.com - 2016-02-17 11:49 -0800
    Re: Considering migrating to Python from Visual Basic 6 for engineering applications sohcahtoa82@gmail.com - 2016-02-17 12:25 -0800
    Re: Considering migrating to Python from Visual Basic 6 for engineering applications Rob Gaddi <rgaddi@highlandtechnology.invalid> - 2016-02-17 20:54 +0000
      Re: Considering migrating to Python from Visual Basic 6 for engineering applications Ray Cote <rgacote@appropriatesolutions.com> - 2016-02-17 16:13 -0500
    Re: Considering migrating to Python from Visual Basic 6 for engineering applications paul.hermeneutic@gmail.com - 2016-02-17 14:18 -0700
    Re: Considering migrating to Python from Visual Basic 6 for engineering applications William Ray Wing <wrw@mac.com> - 2016-02-17 16:27 -0500
      Re: Considering migrating to Python from Visual Basic 6 for engineering applications wrong.address.1@gmail.com - 2016-02-18 00:17 -0800
        Re: Considering migrating to Python from Visual Basic 6 for engineering applications Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2016-02-18 10:09 +0000
        Re: Considering migrating to Python from Visual Basic 6 for engineering applications Chris Angelico <rosuav@gmail.com> - 2016-02-18 21:16 +1100
          Re: Considering migrating to Python from Visual Basic 6 for engineering applications wrong.address.1@gmail.com - 2016-02-18 03:11 -0800
            Re: Considering migrating to Python from Visual Basic 6 for engineering applications Chris Angelico <rosuav@gmail.com> - 2016-02-18 22:32 +1100
              Re: Considering migrating to Python from Visual Basic 6 for engineering applications wrong.address.1@gmail.com - 2016-02-18 07:49 -0800
                Re: Considering migrating to Python from Visual Basic 6 for engineering applications Chris Angelico <rosuav@gmail.com> - 2016-02-19 03:06 +1100
                  Re: Considering migrating to Python from Visual Basic 6 for engineering applications wrong.address.1@gmail.com - 2016-02-18 09:49 -0800
                    Re: Considering migrating to Python from Visual Basic 6 for engineering applications Dietmar Schwertberger <maillist@schwertberger.de> - 2016-02-18 21:37 +0100
                RE: Considering migrating to Python from Visual Basic 6 for engineering applications Dan Strohl <D.Strohl@F5.com> - 2016-02-18 16:24 +0000
                  Re: Considering migrating to Python from Visual Basic 6 for engineering applications wrong.address.1@gmail.com - 2016-02-18 09:58 -0800
                    Re: Considering migrating to Python from Visual Basic 6 for engineering applications Tim Chase <python.list@tim.thechases.com> - 2016-02-18 13:18 -0600
              Re: Considering migrating to Python from Visual Basic 6 for engineering applications Steven D'Aprano <steve@pearwood.info> - 2016-02-19 11:30 +1100
                Re: Considering migrating to Python from Visual Basic 6 for engineering applications Chris Angelico <rosuav@gmail.com> - 2016-02-19 11:57 +1100
                Ohnoes significant whitespace (was: Considering migrating to Python from Visual Basic 6 for engineering applications) Ben Finney <ben+python@benfinney.id.au> - 2016-02-19 12:03 +1100
                  Re: Ohnoes significant whitespace Marko Rauhamaa <marko@pacujo.net> - 2016-02-19 08:36 +0200
                  Re: Ohnoes significant whitespace (was: Considering migrating to Python from Visual Basic 6 for engineering applications) Grant Edwards <invalid@invalid.invalid> - 2016-02-19 14:57 +0000
                Re: Considering migrating to Python from Visual Basic 6 for engineering applications BartC <bc@freeuk.com> - 2016-02-19 02:14 +0000
                  Re: Considering migrating to Python from Visual Basic 6 for engineering applications Steven D'Aprano <steve@pearwood.info> - 2016-02-19 21:18 +1100
            Re: Considering migrating to Python from Visual Basic 6 for engineering applications Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2016-02-18 15:20 +0000
              Re: Considering migrating to Python from Visual Basic 6 for engineering applications wrong.address.1@gmail.com - 2016-02-18 07:33 -0800
                Re: Considering migrating to Python from Visual Basic 6 for engineering applications Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2016-02-18 15:47 +0000
                Re: Considering migrating to Python from Visual Basic 6 for engineering applications William Ray Wing <wrw@mac.com> - 2016-02-18 10:59 -0500
                  Re: Considering migrating to Python from Visual Basic 6 for engineering applications wrong.address.1@gmail.com - 2016-02-18 09:38 -0800
                RE: Considering migrating to Python from Visual Basic 6 for engineering applications Dan Strohl <D.Strohl@F5.com> - 2016-02-18 16:00 +0000
                  Re: Considering migrating to Python from Visual Basic 6 for engineering applications wrong.address.1@gmail.com - 2016-02-18 09:44 -0800
                Re: Considering migrating to Python from Visual Basic 6 for engineering applications Tim Chase <python.list@tim.thechases.com> - 2016-02-18 13:28 -0600
                  Re: Considering migrating to Python from Visual Basic 6 for engineering applications wrong.address.1@gmail.com - 2016-02-19 02:47 -0800
                    Re: Considering migrating to Python from Visual Basic 6 for engineering applications Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-02-19 11:23 +0000
                      Re: Considering migrating to Python from Visual Basic 6 for engineering applications wrong.address.1@gmail.com - 2016-02-19 03:53 -0800
                        Re: Considering migrating to Python from Visual Basic 6 for engineering applications Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-02-19 08:13 -0500
                        Re: Considering migrating to Python from Visual Basic 6 for engineering applications Steven D'Aprano <steve@pearwood.info> - 2016-02-20 18:54 +1100
                          Re: Considering migrating to Python from Visual Basic 6 for engineering applications wrong.address.1@gmail.com - 2016-02-20 10:45 -0800
                            Re: Considering migrating to Python from Visual Basic 6 for engineering applications Christian Gollwitzer <auriocus@gmx.de> - 2016-02-20 20:21 +0100
                    Re: Considering migrating to Python from Visual Basic 6 for engineering applications Tony van der Hoff <tony@vanderhoff.org> - 2016-02-19 11:34 +0000
                    Re: Considering migrating to Python from Visual Basic 6 for engineering applications Tim Chase <python.list@tim.thechases.com> - 2016-02-19 07:40 -0600
                      Re: Considering migrating to Python from Visual Basic 6 for engineering applications wrong.address.1@gmail.com - 2016-02-19 10:14 -0800
                        Re: Considering migrating to Python from Visual Basic 6 for engineering applications BartC <bc@freeuk.com> - 2016-02-19 23:06 +0000
                        Re: Considering migrating to Python from Visual Basic 6 for engineering applications Larry Hudson <orgnut@yahoo.com> - 2016-02-19 23:49 -0800
                          Re: Considering migrating to Python from Visual Basic 6 for engineering applications wrong.address.1@gmail.com - 2016-02-20 10:38 -0800
                            Re: Considering migrating to Python from Visual Basic 6 for engineering applications Larry Hudson <orgnut@yahoo.com> - 2016-02-20 23:28 -0800
                              Re: Considering migrating to Python from Visual Basic 6 for engineering applications BartC <bc@freeuk.com> - 2016-02-21 13:16 +0000
                                Re: Considering migrating to Python from Visual Basic 6 for engineering applications Chris Angelico <rosuav@gmail.com> - 2016-02-22 00:54 +1100
                                Re: Considering migrating to Python from Visual Basic 6 for engineering applications Jussi Piitulainen <jussi.piitulainen@helsinki.fi> - 2016-02-21 17:08 +0200
                                  Re: Considering migrating to Python from Visual Basic 6 for engineering applications BartC <bc@freeuk.com> - 2016-02-21 16:16 +0000
                                    Re: Considering migrating to Python from Visual Basic 6 for engineering applications Jussi Piitulainen <jussi.piitulainen@helsinki.fi> - 2016-02-21 23:52 +0200
                                      Re: Considering migrating to Python from Visual Basic 6 for engineering applications BartC <bc@freeuk.com> - 2016-02-21 23:05 +0000
                                        Re: Considering migrating to Python from Visual Basic 6 for engineering applications Jussi Piitulainen <jussi.piitulainen@helsinki.fi> - 2016-02-22 10:50 +0200
                                          Re: Considering migrating to Python from Visual Basic 6 for engineering applications BartC <bc@freeuk.com> - 2016-02-22 12:24 +0000
                                      Re: Considering migrating to Python from Visual Basic 6 for engineering applications Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-02-21 21:19 -0500
                                      Re: Considering migrating to Python from Visual Basic 6 for engineering applications Steven D'Aprano <steve@pearwood.info> - 2016-02-22 21:46 +1100
                                        Re: Considering migrating to Python from Visual Basic 6 for engineering applications Jussi Piitulainen <jussi.piitulainen@helsinki.fi> - 2016-02-22 13:39 +0200
                                        Re: Considering migrating to Python from Visual Basic 6 for engineering applications Random832 <random832@fastmail.com> - 2016-02-22 09:49 -0500
                                        Re: Considering migrating to Python from Visual Basic 6 for engineering applications BartC <bc@freeuk.com> - 2016-02-22 16:21 +0000
                                          Re: Considering migrating to Python from Visual Basic 6 for   engineering applications Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-02-23 10:45 +1300
                                Re: Considering migrating to Python from Visual Basic 6 for engineering applications Christian Gollwitzer <auriocus@gmx.de> - 2016-02-21 16:21 +0100
                                Re: Considering migrating to Python from Visual Basic 6 for engineering applications Tim Chase <python.list@tim.thechases.com> - 2016-02-21 12:19 -0600
                                Re: Considering migrating to Python from Visual Basic 6 for engineering applications Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-02-21 21:40 -0500
                                Re: Considering migrating to Python from Visual Basic 6 for engineering applications Steven D'Aprano <steve@pearwood.info> - 2016-02-22 22:16 +1100
                                  Re: Considering migrating to Python from Visual Basic 6 for engineering applications BartC <bc@freeuk.com> - 2016-02-22 12:51 +0000
                                    Re: Considering migrating to Python from Visual Basic 6 for engineering applications Chris Angelico <rosuav@gmail.com> - 2016-02-23 00:09 +1100
                            Re: Considering migrating to Python from Visual Basic 6 for engineering applications Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-02-21 13:39 -0500
                    Re: Considering migrating to Python from Visual Basic 6 for engineering applications Peter Otten <__peter__@web.de> - 2016-02-19 15:58 +0100
                    Re: Considering migrating to Python from Visual Basic 6 for engineering applications Matt Wheeler <m@funkyhat.org> - 2016-02-19 17:05 +0000
                    Re: Considering migrating to Python from Visual Basic 6 for engineering applications Roel Schroeven <roel@roelschroeven.net> - 2016-02-20 23:28 +0100
            Re: Considering migrating to Python from Visual Basic 6 for engineering applications Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-02-19 01:07 +0000
    Re: Considering migrating to Python from Visual Basic 6 for engineering applications wxjmfauth@gmail.com - 2016-02-18 01:49 -0800
    Re: Considering migrating to Python from Visual Basic 6 for engineering applications William Ray Wing <wrw@mac.com> - 2016-02-18 09:07 -0500
      Re: Considering migrating to Python from Visual Basic 6 for engineering applications wrong.address.1@gmail.com - 2016-02-18 07:35 -0800
        Re: Considering migrating to Python from Visual Basic 6 for engineering applications Steven D'Aprano <steve@pearwood.info> - 2016-02-19 12:06 +1100
          Re: Considering migrating to Python from Visual Basic 6 for engineering applications wrong.address.1@gmail.com - 2016-02-19 03:11 -0800
            Re: Considering migrating to Python from Visual Basic 6 for engineering applications Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-02-19 08:27 -0500
              Re: Considering migrating to Python from Visual Basic 6 for engineering applications Steven D'Aprano <steve@pearwood.info> - 2016-02-20 12:13 +1100
                Re: Considering migrating to Python from Visual Basic 6 for engineering applications William Ray Wing <wrw@mac.com> - 2016-02-19 22:28 -0500
    Re: Considering migrating to Python from Visual Basic 6 for engineering applications BartC <bc@freeuk.com> - 2016-02-19 15:34 +0000
      Re: Considering migrating to Python from Visual Basic 6 for engineering applications Chris Angelico <rosuav@gmail.com> - 2016-02-20 02:43 +1100
        Re: Considering migrating to Python from Visual Basic 6 for engineering applications Grant Edwards <invalid@invalid.invalid> - 2016-02-19 16:04 +0000
      Re: Considering migrating to Python from Visual Basic 6 for engineering applications Grant Edwards <invalid@invalid.invalid> - 2016-02-19 15:59 +0000
        Re: Considering migrating to Python from Visual Basic 6 for engineering applications BartC <bc@freeuk.com> - 2016-02-19 16:32 +0000
          Re: Considering migrating to Python from Visual Basic 6 for engineering applications Chris Angelico <rosuav@gmail.com> - 2016-02-20 03:49 +1100
          Re: Considering migrating to Python from Visual Basic 6 for engineering applications Grant Edwards <invalid@invalid.invalid> - 2016-02-19 18:03 +0000
    Re: Considering migrating to Python from Visual Basic 6 for engineering applications Denis Akhiyarov <denis.akhiyarov@gmail.com> - 2016-02-19 20:58 -0800
      Re: Considering migrating to Python from Visual Basic 6 for engineering applications wrong.address.1@gmail.com - 2016-02-20 10:50 -0800
        Re: Considering migrating to Python from Visual Basic 6 for engineering applications Denis Akhiyarov <denis.akhiyarov@gmail.com> - 2016-02-22 00:02 -0800
      Re: Considering migrating to Python from Visual Basic 6 for engineering applications Mike S <mscir@yahoo.com> - 2016-02-20 19:52 -0800
    Re: Considering migrating to Python from Visual Basic 6 for engineering applications wxjmfauth@gmail.com - 2016-02-20 01:46 -0800
    Re: Considering migrating to Python from Visual Basic 6 for engineering applications nholtz <nholtz@cee.carleton.ca> - 2016-02-20 08:22 -0800
      Re: Considering migrating to Python from Visual Basic 6 for engineering applications wrong.address.1@gmail.com - 2016-02-20 10:47 -0800

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →


#103160 — Ohnoes significant whitespace (was: Considering migrating to Python from Visual Basic 6 for engineering applications)

FromBen Finney <ben+python@benfinney.id.au>
Date2016-02-19 12:03 +1100
SubjectOhnoes significant whitespace (was: Considering migrating to Python from Visual Basic 6 for engineering applications)
Message-ID<mailman.29.1455843906.2289.python-list@python.org>
In reply to#103157
Chris Angelico <rosuav@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

[toc] | [prev] | [next] | [standalone]


#103173 — Re: Ohnoes significant whitespace

FromMarko Rauhamaa <marko@pacujo.net>
Date2016-02-19 08:36 +0200
SubjectRe: Ohnoes significant whitespace
Message-ID<87bn7dqk9m.fsf@elektro.pacujo.net>
In reply to#103160
Ben Finney <ben+python@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

[toc] | [prev] | [next] | [standalone]


#103196 — Re: Ohnoes significant whitespace (was: Considering migrating to Python from Visual Basic 6 for engineering applications)

FromGrant Edwards <invalid@invalid.invalid>
Date2016-02-19 14:57 +0000
SubjectRe: Ohnoes significant whitespace (was: Considering migrating to Python from Visual Basic 6 for engineering applications)
Message-ID<na7ahc$n6g$1@reader1.panix.com>
In reply to#103160
On 2016-02-19, Ben Finney <ben+python@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            

[toc] | [prev] | [next] | [standalone]


#103165

FromBartC <bc@freeuk.com>
Date2016-02-19 02:14 +0000
Message-ID<na5tlh$fuf$1@dont-email.me>
In reply to#103157
On 19/02/2016 00:30, Steven D'Aprano wrote:
> On Thu, 18 Feb 2016 10:32 pm, Chris Angelico wrote:
>
>> The biggest disadvantage of Python is that, in a number of ways, it
>> surprises people. Significant whitespace bugs a lot of experienced
>> programmers
>
> This is why we cannot have nice things.
>
> "But what if we pass the source code through a system that strips out
> leading whitespace?"
>
> "Then don't do that. What if you pass the source code through a system that
> strips out braces?"

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

-- 
Bartc

[toc] | [prev] | [next] | [standalone]


#103178

FromSteven D'Aprano <steve@pearwood.info>
Date2016-02-19 21:18 +1100
Message-ID<56c6ebf4$0$1583$c3e8da3$5496439d@news.astraweb.com>
In reply to#103165
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

[toc] | [prev] | [next] | [standalone]


#103120

FromOscar Benjamin <oscar.j.benjamin@gmail.com>
Date2016-02-18 15:20 +0000
Message-ID<mailman.5.1455808876.2289.python-list@python.org>
In reply to#103107
On 18 February 2016 at 11:32, Chris Angelico <rosuav@gmail.com> wrote:
> On Thu, Feb 18, 2016 at 10:11 PM,  <wrong.address.1@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

[toc] | [prev] | [next] | [standalone]


#103121

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

This form of packing is not desirable. I can't ask 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)?

[toc] | [prev] | [next] | [standalone]


#103126

FromOscar Benjamin <oscar.j.benjamin@gmail.com>
Date2016-02-18 15:47 +0000
Message-ID<mailman.9.1455810487.2289.python-list@python.org>
In reply to#103121
On 18 February 2016 at 15:33,  <wrong.address.1@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

[toc] | [prev] | [next] | [standalone]


#103130

FromWilliam Ray Wing <wrw@mac.com>
Date2016-02-18 10:59 -0500
Message-ID<mailman.12.1455811186.2289.python-list@python.org>
In reply to#103121
> On Feb 18, 2016, at 10:33 AM, wrong.address.1@gmail.com wrote:
> 
> torstai 18. helmikuuta 2016 17.21.32 UTC+2 Oscar Benjamin kirjoitti:
>> On 18 February 2016 at 11:32, Chris Angelico <rosuav@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

[toc] | [prev] | [next] | [standalone]


#103138

Fromwrong.address.1@gmail.com
Date2016-02-18 09:38 -0800
Message-ID<f71cf3ee-ea23-423e-901a-dfaef6f02271@googlegroups.com>
In reply to#103130
On Thursday, 18 February 2016 17:59:59 UTC+2, William Ray Wing  wrote:
> > On Feb 18, 2016, at 10:33 AM, wrong.address.1@gmail.com wrote:
> > 
> > torstai 18. helmikuuta 2016 17.21.32 UTC+2 Oscar Benjamin kirjoitti:
> >> On 18 February 2016 at 11:32, Chris Angelico <rosuav@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

[toc] | [prev] | [next] | [standalone]


#103131

FromDan Strohl <D.Strohl@F5.com>
Date2016-02-18 16:00 +0000
Message-ID<mailman.13.1455811262.2289.python-list@python.org>
In reply to#103121
Disadvantages of python... (compared to VB)

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

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

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

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

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

My approach is generally:

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

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

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





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

[toc] | [prev] | [next] | [standalone]


#103140

Fromwrong.address.1@gmail.com
Date2016-02-18 09:44 -0800
Message-ID<14835961-1ee1-44c6-a0a2-dd88d3f9298f@googlegroups.com>
In reply to#103131
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

[toc] | [prev] | [next] | [standalone]


#103146

FromTim Chase <python.list@tim.thechases.com>
Date2016-02-18 13:28 -0600
Message-ID<mailman.20.1455823868.2289.python-list@python.org>
In reply to#103121
On 2016-02-18 07:33, wrong.address.1@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


[toc] | [prev] | [next] | [standalone]


#103181

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

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

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

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

[toc] | [prev] | [next] | [standalone]


#103184

FromMark Lawrence <breamoreboy@yahoo.co.uk>
Date2016-02-19 11:23 +0000
Message-ID<mailman.40.1455881073.2289.python-list@python.org>
In reply to#103181
On 19/02/2016 10:47, wrong.address.1@gmail.com wrote:
>
> 2 12.657823 0.1823467E-04 114 0
> 3 4 5 9 11
> "Lower"
> 278.15
>
> Is it straightforward to read this, or does one have to read one character at a time and then figure out what the numbers are?
>

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

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

Mark Lawrence

[toc] | [prev] | [next] | [standalone]


#103189

Fromwrong.address.1@gmail.com
Date2016-02-19 03:53 -0800
Message-ID<729e6513-4d1d-4b9b-be8b-4b7664abac2e@googlegroups.com>
In reply to#103184
On Friday, 19 February 2016 13:24:46 UTC+2, Mark Lawrence  wrote:
> On 19/02/2016 10:47, wrong.address.1@gmail.com wrote:
> >
> > 2 12.657823 0.1823467E-04 114 0
> > 3 4 5 9 11
> > "Lower"
> > 278.15
> >
> > Is it straightforward to read this, or does one have to read one character at a time and then figure out what the numbers are?
> >
> 
> One character at a time in a high level language like Python, please. 

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

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

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

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

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

Thanks.

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

[toc] | [prev] | [next] | [standalone]


#103192

FromDennis Lee Bieber <wlfraed@ix.netcom.com>
Date2016-02-19 08:13 -0500
Message-ID<mailman.46.1455887608.2289.python-list@python.org>
In reply to#103189
On Fri, 19 Feb 2016 03:53:03 -0800 (PST), wrong.address.1@gmail.com
declaimed the following:

>
>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.
>
	I've not done .NET, but surely they haven't removed the ability to read
a full line and then perform string operations on the result to find
fields.

	But in general, for ad-hoc input, scanning of some sort will be
required to locate/parse the values. It becomes much simpler if the input
has a specified structure (fixed columns being traditional).


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

	There was FORTRAN -- which didn't even have a character string data
type; one used fixed size arrays of individual characters and had to
perform lots of loops to locate and copy "words". Heck, even in the
mid-80s, one of the most used utility functions in the department I was in
was to take a line of user input and split it into a 2-dimensional array
(10 entries of 32 characters max) on white space, just so the rest of the
program could parse the user command input.

	Provide a specification for your input data, and I'm sure almost anyone
here could come up with something to read it.

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

	A block of four lines, white-space delimited:
		Integer, 2 floats, 2 integers
		5 integers
		string with " delimiter
		float

def readBlock(fin):
    #NO ERROR CHECKING INCLUDED
    ln = fin.readline().strip()
    flds = ln.split()
    l1 = [int(flds[0]), float(flds[1]),
          float(flds[2]), int(flds[3]),
          int(flds[4])]
    ln = fin.readline().strip()
    l2 = [int(fld) for fld in ln.split()]
    ln = fin.readline().strip()
    l3 = ln.strip('"')
    ln = fin.readline().strip()
    l4 = float(ln)
    return (l1, l2, l3, l4)

	The "l1 =" line could fail for: less than 5 fields on the input line;
invalid character for int/float data within a field; excess fields will be
ignored. The "l2 =" line could fail for: invalid character for int data; it
will accept any number of integer fields. The "l4 =" could fail for invalid
characters for a float.

	What it returns is a tuple containing a list of 5 (mixed) numerics, a
list of 5 integers, one string, and a float.


>> https://docs.python.org/3/library/re.html.  Or a likely replacement for 
>> the re module https://pypi.python.org/pypi/regex.
>> 
>
>Thanks.
>
>> -- 
>> My fellow Pythonistas, ask not what our language can do for you, ask
>> what you can do for our language.
>> 
>> Mark Lawrence
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]


#103245

FromSteven D'Aprano <steve@pearwood.info>
Date2016-02-20 18:54 +1100
Message-ID<56c81b9f$0$1585$c3e8da3$5496439d@news.astraweb.com>
In reply to#103189
On Fri, 19 Feb 2016 10:53 pm, wrong.address.1@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

[toc] | [prev] | [next] | [standalone]


#103273

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

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

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

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

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

> 
> 
> 
> 
> 
> -- 
> Steven

[toc] | [prev] | [next] | [standalone]


#103276

FromChristian Gollwitzer <auriocus@gmx.de>
Date2016-02-20 20:21 +0100
Message-ID<naae5n$3g9$1@dont-email.me>
In reply to#103273
Am 20.02.16 um 19:45 schrieb wrong.address.1@gmail.com:
> On Saturday, 20 February 2016 09:54:15 UTC+2, Steven D'Aprano  wrote:
>> To answer your question "Do I need something fancy...?", no, of course not,
>> reading a line of numbers from a text file is easy.
>>
>> with open("numbers.txt", "r") as f:
>>      for line in f:
>>          numbers = [int(s) for s in split(line)]
>>
>
> This looks good enough. This does not seem complicated (although I still understand almost nothing of what is written). I was simply not expressing myself in a way you people would understand.
>
>>
>> will read and convert integer-valued numbers separated by whitespace like:
>>
>>      123 654 9374 1 -45 3625
>>
>>
>> one line at a time. You can then collate them for later use, or process them
>> as you go. If they're floating point numbers, change the call to int() to a
>> call to float().
>>
>
> And I guess if the first three numbers are integers and the fourth is a float, then also there must be some equally straightforward way.

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

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

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

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

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

After installing that, you can do:

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

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

	Christian

[toc] | [prev] | [next] | [standalone]


Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

Back to top | Article view | comp.lang.python


csiph-web