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

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 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

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

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

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

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

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

-- 
Greg

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

#103297

Am 21.02.16 um 14:16 schrieb BartC:
> Even accepting that syntax limitations might require this to be written as:
>
>    readline(f, a, b, c)
>
> I can't see a straightforward way of making this possible while still
> keeping a, b and c simple integer, float or string types (because
> Python's reference parameters don't work quite the right way).
>
> (There is also the question of 'readline' knowing what types of values
> to read. This information would not be needed in Fortran or Basic but
> somehow needs to be supplied here, if a particular set of types is to
> imposed on the input.)

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

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

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

Yes, but the above seems quite trivial:

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

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

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

Apfelkiste:Tests chris$

	Christian

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

#103313

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

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

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

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

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

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

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

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

-tkc

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

#103323

On Sun, 21 Feb 2016 12:19:06 -0600, Tim Chase
<python.list@tim.thechases.com> declaimed the following:

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

	In K&K BASIC, the neophyte level (remember, variable names were limited
to [A-Z][null|0-9]) is that 'A' is a single-precision float, 'A$' is a
character string, and eventually there were additional punctuation codes
for double-precision and integer types.

	Visual BASIC took the DEF statement (originally only used to declare
array bound) and extended it to declare data types for the subsequent
variable names.

	FORTRAN traditionally used I-N ("IndiaN") to indicate an integer, all
other variable names were single precision float -- unless explicitly
declared as some other type (and there were no character string type back
then -- it was an array of bytes).

	However, in BOTH BASIC, FORTRAN, C/C++, Pascal, Ada, etc., the type of
the data being read is known by the compiler based upon the (implicit or
explicit) type declaration of the receiving variable. Python, REXX, other
"scripting" languages, do not use predefined types for variable names -- a
given name can receive an object of any type. This means I/O has to specify
the type needed to parse the string representation. Note that a real REXX
implementation determines the difference between numeric and string at time
of usage (most REXX implementations do have internal float/integer forms,
but it is perfectly valid for the implementation to keep things in string
form and do a behind-the-scenes parse when arithmetic is done, then convert
the result back to string).

-=-=-=-=-
/* junk */
A = "1"
B = 2
say A + B
say A || B
-=-=-=-=-
C:\Users\Wulfraed\Documents>rexx junk.rx
3
12

C:\Users\Wulfraed\Documents>

	The first "say" treats them as integers, and returns the sum. The
second say is using string concatenation. Yet in the code, A is a string
and B is an integer.

	And you don't want to see REXX's equivalent of multi-field console
input... {Hint: it starts with PARSE PULL -- PULL being the equivalent of
Python's input()/raw_input() [P3 vs P2]}
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

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

#103334

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

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

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

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

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


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

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



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

Python doesn't have reference parameters.

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


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

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

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

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

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

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


-- 
Steven

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

#103339

On 22/02/2016 11:16, Steven D'Aprano wrote:
> On Mon, 22 Feb 2016 12:16 am, BartC wrote:
>
> [...]
>>> No need for anyone to re-invent the
>>> wheel!  ;-)
>>
>> I keep seeing this in the thread. Python has all this capability, yet it
>> still requires a lot of fiddly code to be added to get anywhere near as
>> simple as this:
>>
>>     read f, a, b, c
>
> I can't say I really know what that means. My guess is that reads three
> things (a, b and c) from a file f, but what those things are (strings,
> binary blobs, floats, ints, something else?) is a mystery.

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

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

> One of the major problems with output parameters is that it isn't obvious
> what is an output parameter and what isn't. When it comes to read, perhaps
> you can guess, but when it comes to arbitrary functions, who can tell what
> is output and what is input?
>
> fromaginate m, x, y, z, a, b
>
>
> Whereas a functional design makes it obvious: output is on the left of the
> assignment symbol, input is on the right.
>
> x, y, z = fromaginate m, a, b

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

>>     readline(f, a, b, c)
>>
>> I can't see a straightforward way of making this possible while still
>> keeping a, b and c simple integer, float or string types (because
>> Python's reference parameters don't work quite the right way).
>
> Python doesn't have reference parameters.
>
> Please feel free to discuss further if you disagree, or want additional
> explanation.

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

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

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

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

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

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

-- 
Bartc

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

#103340

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

What you could do is something like this:

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

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

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

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


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

ChrisA

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

#103314

On Sat, 20 Feb 2016 10:38:40 -0800 (PST), wrong.address.1@gmail.com
declaimed the following:

>
>To give an example of the kind of things I have to read (and I have to read numbers from several files usually), here is some VB6 code:
>
>    Open "N020S.TXT" For Input As #8
>
>    Input #8, ND, NIN, NT ' all integers
>    Text9.Text = ND
>    Text1 = CStr(NIN)
>    Text4 = NT
>
	Are characters rationed on this job? Names that mean something?

	I note that you read a text file -- letting the runtime convert "words"
into integers (presume they've been declared as such somewhere), and then
immediately convert one of them back into text. Granted, it IS used as an
integer later but one gets the impression above that all three "integers"
just get converted back to text.
    
>    Text12 = ""
>    For i = 1 To NIN
>        Input #8, DINCOL(i) ' single precision floating point vector
>        Text12 = Text12.Text & DINCOL(i) & " "
>        If Dvarname(1) <> "" Then varname(i) = Dvarname(NLCOL(i)) ' strings
>    Next i
>
	Ignoring that "Dvarname" is undefined, it looks like you are reading --
one at a time (ie; by "words") values that are being converted to floating
point format, only to immediately have the runtime convert them back to
text format so you can string concatenate them with a blank separator.

	You also seem to be relying upon BASIC's tendency to ignore end-of-line
marks (after reading the three integers, the next read ignores the line
feed and reads the first float) AND its tendency to leave partial lines in
the stream for the next read request.

-=-=-=-=-
f8 = open("N020S.TXT", "r")

(ND, NIN, NT) = [int(x) for x in f8.readline().strip().split()]
#only works if there are three valid integers on the line

#skipping the three assignments as i suspect you are referencing
#GUI form objects and that depends then on the framework in use

DINCOL = [float(x) for x in f8.readline().strip().split()]
if len(DINCOL) != NIN:
	#expected NIN values, but got a different number of values

Text12 = " ".join(str(x) for x in DINCOL)

#assumption: all NIN-count floats are on one line; if they can spread
#across multiple lines, the I/O will need to get fancier
#upto, yes, reading large buffers, stripping new-lines, and doing
#your own "word" parsing -- though .split() does take a
#parameter on how many splits to make, so 
#	rest = " ".join(f8.read().split("\n"))
#		read entire file, split on lines, rejoin with space
#	while rest:
#		fld, rest = rest.split(None, 1)
#		do something with fld	
-=-=-=-=-

	For "ignore new lines" type I/O, you could maybe make a generator
function to handle the word fetching... Something like (I've not written a
generator before)...

def words(fname):
	fin = open(fname, "r")
	contents = " ".join(fin.read().split("\n"))
	fin.close
	while contents:
		aword, contents = contents.split(None, 1)
		yield aword

reader = words("N020S.TXT")
ND = int(reader.next())
NIN = int(reader.next())
NT = int(reader.next())

DINCOL = []
for _ in xrange(NIN):
	DINCOL.append(float(reader.next()))
text12 = " ".join(str(x) for x in DINCOL)


	If the input files are really huge, you would have to modify the
generator to read in chunks, and when one chunk is nearly consumed,  read
the next chunk and concatenate it... Could use lines for the chunks

def words(fname):
	fin = open(fname, "r")
	for line in fin:
		contents = line.strip()
		while contents:	#warning: will skip over blank lines
			aword, contents = contents.split(None, 1)
			yield aword
	fin.close()

	Of course, since the file read is all done inside the generator, if you
suddenly need a multiple word string, you will have problems, since no
indicator of end-of-line is seen outside this generator.

	Expanding up to the next level, you could create a class, with methods
to handle explicit data types, cognizance of the EOL, allowing blank lines
if, say, the input request is for a string, etc.

-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

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

#103197

Tim Chase wrote:

> On 2016-02-19 02: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? --
> 
> It's easy to read.  What you do with that mess of data is the complex
> part.  They come in as byte-strings, but you'd have to convert them
> to the corresponding formats:
> 
>   from shlex import shlex
>   USE_LEX = True # False
>   with open('data.txt') as f:
>     for i, line in enumerate(f, 1):
>       if USE_LEX:
>         bits = shlex(line)
>       else:
>         bits = line.split()
>       for j, bit in enumerate(bits, 1):
>         if bit.isdigit():
>           result = int(bit)
>           t = "an int"
>         elif '"' in bit:
>           result = bit
>           t = "a string"
>         else:
>           result = float(bit)
>           t = "a float"
>         print("On line %i I think that item %i %r is %s: %r" % (
>           i,
>           j,
>           bit,
>           t,
>           result,
>           ))
> 
> The USE_LEX controls whether the example code uses string-splitting
> on white-space, or uses the built-in "shlex" module to parse for
> quoted strings that might contain a space.  The naive way of
> string-splitting will be faster, but choke on string-data containing
> spaces.
> 
> You'd have to make up your own heuristics for determining what type
> each data "bit" is, parsing it out (with int(), float() or whatever),
> but the above gives you some rough ideas with at least one known
> bug/edge-case.  

Or just tell the parser what to expect:

$ cat read_data_shlex2.py
import shlex

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


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


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


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

If this thread goes long enough eventually we will ;)

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

#103206

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

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

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

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

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

-- 
Matt Wheeler
http://funkyh.at

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

#103279

wrong.address.1@gmail.com schreef op 2016-02-19 11:47:
> Thanks. The data I will often have to read from text files could read like
> 
> 2 12.657823 0.1823467E-04 114 0
> 3 4 5 9 11
> "Lower"
> 278.15
> 
> Is it straightforward to read this, or does one have to read one character at a time and then figure out what the numbers are?

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

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

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

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

Output:

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

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

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

Roel Schroeven

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

#103162

On 18/02/2016 11:32, Chris Angelico 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.
>

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

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

Mark Lawrence

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

#103099

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

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

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

jmf

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

#103114

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

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

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

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

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

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

Good luck and have fun,
Bill


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

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

#103122

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

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

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

#103161

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

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

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

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

(1) Yes it can.

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


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

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

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

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

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


Instead, a good question is:

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


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

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

Copy and paste this code into the Python interpreter:



# ===== cut =====

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

# ===== cut =====



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


# ===== cut =====

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

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

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

# ===== cut =====



Does this help?



-- 
Steven

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

#103183

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

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

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

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

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

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

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

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

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

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

> 
> 
> -- 
> Steven

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

#103193

On Fri, 19 Feb 2016 03:11:04 -0800 (PST), wrong.address.1@gmail.com
declaimed the following:

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

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

	Most of your questions have the same answer if applied to any
Turing-complete language... (LISP, APL, Fortran, BASIC, REXX, Ada, COBOL,
PERL, etc.)

			Yes -- it does that!

HOW it does "that" may differ from one language to another but the
capability will be there in some form.

-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

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

#103230

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


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

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



-- 
Steven

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

#103234

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

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

Bill

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

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

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

csiph-web