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

#103185

On 19/02/16 11:23, 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.
> See http://nedbatchelder.com/text/python-parsers.html for a list of
> parsers that can do all sorts for you.  Or the stdlib re module
> https://docs.python.org/3/library/re.html.  Or a likely replacement for
> the re module https://pypi.python.org/pypi/regex.
>
Am I alone in thinking that this wrongaddress character is trolling?

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

-- 
Tony van der Hoff        | mailto:tony@vanderhoff.org
Buckinghamshire, England |

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

#103194

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.  But we can't do *all* the work for you ;-)

-tkc

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

#103213

On Friday, 19 February 2016 16:08:46 UTC+2, 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,
>           ))
> 

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

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

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

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

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

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

#103226

On 19/02/2016 18:14, wrong.address.1@gmail.com wrote:
> On Friday, 19 February 2016 16:08:46 UTC+2, Tim Chase  wrote:

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

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

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

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

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

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

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

-- 
Bartc

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

#103243

On 02/19/2016 10:14 AM, wrong.address.1@gmail.com wrote:
[snip]
>
> This is precisely reading one character at a time. If not exactly reading one character, it is effectively looking at each character to assemble the number. Not a good sign. I guess there might be libraries which will help read numbers better, but I would expect a good language to be able to handle this basic thing for engineers - to read numbers like Fortran and Basic do.
>
> Still, if I have misunderstood something, I will be glad to be corrected. I would generally know that the first three numbers will be floating point, the next will be something and then the next will be something else, etc. Does that help or does one still have to look at each character and determine how to place it in a number?
>
> Thanks for your patience. I don't want surprises later on, which is why I am asking very stupid questions.
>
It absolutely does NOT require reading a character at a time!  You are reading the data from a 
text file, which means everything is a string.  These strings (or sub-strings) can represent 
integers, floats, dates, phone numbers or whatever.  Your example data implies a free-form 
style, where it is then necessary to determine the data type for each of these (sub)strings 
individually.  Of course, if your data has a defined fixed format, this is simplified -- but 
they are still initially strings that have to be converted.  String processing in Python is very 
powerful and versatile.

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

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

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

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

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

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

Running this example gives this result:

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

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

      -=- Larry -=-

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

#103272

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

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

To give an example of the kind of things I have to read (and I have to read numbers from several files usually), here is some VB6 code:

    Open "N020S.TXT" For Input As #8

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

    etc..

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

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

How complicated could this get in Python? Reading the numbers is one thing, and then placing the values in text boxes of the GUI. Or can I write my own reading subroutines which can then be called like 
ReadVBstyle 8, ND, NIN, NT 
to make the code more readable?

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

#103283

On 02/20/2016 10:38 AM, wrong.address.1@gmail.com wrote:
[snip]
> How complicated could this get in Python? Reading the numbers is one thing, and then placing the values in text boxes of the GUI.

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

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

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

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

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

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

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

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

      -=- Larry -=-

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

#103287

On 21/02/2016 07:28, Larry Hudson wrote:
> On 02/20/2016 10:38 AM, wrong.address.1@gmail.com wrote:

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

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

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

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

   read f, a, b, c

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

   readline(f, a, b, c)

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

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

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

-- 
Bartc

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

#103289

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

How about:

a, b, c = readline(f)

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

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

ChrisA

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

#103295

BartC writes:

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

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

from io import StringIO

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

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

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

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

Number8 = StringIO(N020SdotTXT)

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

Hash = dict

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

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

/s

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

#103302

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

>> In other words, it seems this particular wheel does require
>> re-inventing!
>
> It's hardly Python's problem if an engineer is worried about some VB not
> being there in its current form in the future. The sample code upthread
> seemed gibberish to me

I don't know VB6 but:

  Open "N020S.TXT" For Input As #8

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

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

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

IIRC, the first programming exercise I ever did (in 1976 using Algol 60) 
involved reading 3 numbers from the teletype and working out if those 
could form sides of a triangle. It might have started off like this (I 
can't remember Algol 60):

   print "Type 3 numbers:"
   read a, b, c

In Basic, that last line might be:

   input a, b, c

instead (reading here as floats probably).

Now, nearly 40 years later, I don't actually know how to do that in 
Python! Sure, I can cobble something together, with all sorts of 
functions and string operations (and I would need to go and look them 
up). But it's not just /there/ already.

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

-- 
Bartc

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

#103319

BartC writes:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>>> def awkward():
        a = int(input('int> '))
        b = int(input('int> '))
        c = int(input('int> '))
        istriangle(a, b, c)
 
>>> awkward()
int> 3
int> 1
int> 4
>>> # oops

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

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

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

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

#103320

On 21/02/2016 21:52, Jussi Piitulainen wrote:
> BartC writes:
>
>> But this is not so much to do with VB6, but with a very fundamental
>> capability that seems missing in modern languages.
>
> All that's missing is a minor convenience that turns out to be mainly
> awkward. Not at all fundamental.

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

"Give me 3 numbers:"

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

"Yeah, they'd make a triangle."

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

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

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

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

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

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

 >Triangle

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

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

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

>> Now, nearly 40 years later, I don't actually know how to do that in
>> Python! Sure, I can cobble something together, with all sorts of
>> functions and string operations (and I would need to go and look them
>> up). But it's not just /there/ already.
>
> It seems you'd need to look them up in Algol 60 and Basic, too. Nothing
> wrong with that.

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

> It's *good* to be able to cobble together a simple one-liner that does
> what you want with fundamental, reusable components. Or a three-liner if
> you *want* something more complex.

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

  Or a page of code to fake something
> that is really AI-complete, if *that's* what you want. But mainly I mean
> that the present problem is just trivial, and what do you do with the
> Basic command if you have a slightly different input format - does it
> scale at all? If there is extra text on the line before the numbers? If
> the numbers are separated by commas, or semicolons?

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

>> If you gave this a Python exercise to a class of students, you'd end
>> up with 30 different solutions just for the first, easy part of the
>> exercise!

> Well, why would they write code that asks for interactive input at all?
> They can simply call their triangle-testing function in the Python
> interactive loop and specify the integers as arguments:
>
>>>> def istriangle(*threeintegers):
>          a,b,c = sorted(threeintegers)
>          return a*a + b*b == c*c

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

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

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

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

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

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

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

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

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

-- 
Bartc

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

#103327

BartC writes:

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

[...]

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

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

[...]

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

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

stuff = input()

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

It can be used piecemeal:

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

The same can be done in one statement:

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

Here's a simpler user interface:

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

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

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

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

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

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

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

[...]

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

#103337

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

>> Reading stuff from an interactive console or terminal, is such an
>> important part of the history of computing, still being used now, that
>> you'd think a language would provide simple, ready-to-use methods ways
>> to do it.
>
> I think it does. Do you at least agree that it provides a reasonably
> simple way to ask for a single line of text?
>
> stuff = input()
>
> Is that already too obscure or advanced for you? Because surely not?

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

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

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

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

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

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

  readln a,b,c

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

  read d,e

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

  readln @f,a,b,c

This does the same, from file handle f.

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

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

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

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

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

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

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

-- 
Bartc

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

#103322

On Sun, 21 Feb 2016 23:52:11 +0200, Jussi Piitulainen
<jussi.piitulainen@helsinki.fi> declaimed the following:


>and not at all difficult. You'll get far by line.split(), splitting at
>any amount of whitespace by default (note that the .strip() in the
>line.strip().split() that someone posted is redundant).
>
	Call it paranoid overkill... I tend to think of the .strip() as being
used to remove the trailing new-line, THEN splitting what is left on white
space.

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

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

#103332

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

> BartC writes:

>> IIRC, the first programming exercise I ever did (in 1976 using Algol
>> 60) involved reading 3 numbers from the teletype and working out if
>> those could form sides of a triangle.
> 
> That was a lousy user interface even then - an inflexible user
> interaction without even a possibility of handling errors interactively?
> Command line arguments would have been better (if available, that is).

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



-- 
Steven

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

#103335

Steven D'Aprano writes:

> On Mon, 22 Feb 2016 08:52 am, Jussi Piitulainen wrote:
>
>> BartC writes:
>
>>> IIRC, the first programming exercise I ever did (in 1976 using Algol
>>> 60) involved reading 3 numbers from the teletype and working out if
>>> those could form sides of a triangle.
>> 
>> That was a lousy user interface even then - an inflexible user
>> interaction without even a possibility of handling errors
>> interactively?  Command line arguments would have been better (if
>> available, that is).
>
> Jussi, I think you have an inflated expectation of what was available
> in 1976. Command line? What's that? Programs ran in batch mode, and
> 'interactive' meant that you could easily slip out one punched card,
> replace it with a different one, and run the program again.

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

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

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

#103342

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

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

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

#103347

On 22/02/2016 10:46, Steven D'Aprano wrote:
> On Mon, 22 Feb 2016 08:52 am, Jussi Piitulainen wrote:
>
>> BartC writes:
>
>>> IIRC, the first programming exercise I ever did (in 1976 using Algol
>>> 60) involved reading 3 numbers from the teletype and working out if
>>> those could form sides of a triangle.
>>
>> That was a lousy user interface even then - an inflexible user
>> interaction without even a possibility of handling errors interactively?
>> Command line arguments would have been better (if available, that is).
>
> Jussi, I think you have an inflated expectation of what was available in
> 1976. Command line? What's that? Programs ran in batch mode,
> and 'interactive' meant that you could easily slip out one punched card,
> replace it with a different one, and run the program again.

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

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

-- 
Bartc

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

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

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

csiph-web