Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #103064 > unrolled thread
| Started by | wrong.address.1@gmail.com |
|---|---|
| First post | 2016-02-17 11:49 -0800 |
| Last post | 2016-02-20 10:47 -0800 |
| Articles | 20 on this page of 94 — 31 participants |
Back to article view | Back to comp.lang.python
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 →
| From | Ben Finney <ben+python@benfinney.id.au> |
|---|---|
| Date | 2016-02-19 12:03 +1100 |
| Subject | Ohnoes 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]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2016-02-19 08:36 +0200 |
| Subject | Re: 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]
| From | Grant Edwards <invalid@invalid.invalid> |
|---|---|
| Date | 2016-02-19 14:57 +0000 |
| Subject | Re: 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]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-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]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-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]
| From | Oscar Benjamin <oscar.j.benjamin@gmail.com> |
|---|---|
| Date | 2016-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]
| From | wrong.address.1@gmail.com |
|---|---|
| Date | 2016-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]
| From | Oscar Benjamin <oscar.j.benjamin@gmail.com> |
|---|---|
| Date | 2016-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]
| From | William Ray Wing <wrw@mac.com> |
|---|---|
| Date | 2016-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]
| From | wrong.address.1@gmail.com |
|---|---|
| Date | 2016-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]
| From | Dan Strohl <D.Strohl@F5.com> |
|---|---|
| Date | 2016-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]
| From | wrong.address.1@gmail.com |
|---|---|
| Date | 2016-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]
| From | Tim Chase <python.list@tim.thechases.com> |
|---|---|
| Date | 2016-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]
| From | wrong.address.1@gmail.com |
|---|---|
| Date | 2016-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]
| From | Mark Lawrence <breamoreboy@yahoo.co.uk> |
|---|---|
| Date | 2016-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]
| From | wrong.address.1@gmail.com |
|---|---|
| Date | 2016-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]
| From | Dennis Lee Bieber <wlfraed@ix.netcom.com> |
|---|---|
| Date | 2016-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]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-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]
| From | wrong.address.1@gmail.com |
|---|---|
| Date | 2016-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]
| From | Christian Gollwitzer <auriocus@gmx.de> |
|---|---|
| Date | 2016-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