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

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

Re: Do you consider Python a 4GL? Why (not)?

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Do you consider Python a 4GL? Why (not)? Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-06-05 19:40 -0400
    Re: Do you consider Python a 4GL? Why (not)? Laurent Pointal <laurent.pointal@free.fr> - 2013-06-11 21:48 +0200
      Re: Do you consider Python a 4GL? Why (not)? Dave Angel <davea@davea.name> - 2013-06-11 22:02 -0400
      Re: Do you consider Python a 4GL? Why (not)? Chris Angelico <rosuav@gmail.com> - 2013-06-12 12:10 +1000

#47160 — Re: Do you consider Python a 4GL? Why (not)?

On Tue, 4 Jun 2013 18:17:33 -0700, Dan Stromberg <drsalists@gmail.com>
declaimed the following in gmane.comp.python.general:


> Perhaps "Scripting language" is the best general category we have that
> Python fits into.  But I hope not.

	Heh... Having encountered ARexx (the Amiga version of REXX), Python
is NOT a scripting language... The ARexx implementation (along with the
Amiga's interprocess communication system) allowed for scripting any
application that opened an "ARexx Port"... Other than, maybe, the
original IBM REXX, I've not seen any other REXX implementation that
would permit embedding application specific commands into a script.

	Python's subprocess (and related) are all based on explicit startup
and communication over stdin/stdout... Nothing like:

address TextEditor	/* a fictitious application port */
'DN 5'	/* move down five lines *?:
'MARK'		/* start a selection	*/
'RW 5'	/* move right five words */
'COPY'	/* copy selection to operation result */
string = result
address PageSetter	/* fictitious here, but a real program */
'PASTE' string	/* insert selected string into page document /*

	Yes, maybe the above could be done as two sessions of subprocess --
presuming both programs had a command line interface. But what if the
script was going to switch between the two of them throughout one
session.

	The C compiler suites used this ability to read the error log from a
compile, and move to the line/column in the source file associated with
each error. (Before "integrated" development environments)

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

[toc] | [next] | [standalone]

#47696

Dennis Lee Bieber wrote:

> On Tue, 4 Jun 2013 18:17:33 -0700, Dan Stromberg <drsalists@gmail.com>
> declaimed the following in gmane.comp.python.general:
> 
> 
>> Perhaps "Scripting language" is the best general category we have that
>> Python fits into.  But I hope not.
> 
> Heh... Having encountered ARexx (the Amiga version of REXX), Python
> is NOT a scripting language... The ARexx implementation (along with the
> Amiga's interprocess communication system) allowed for scripting any
> application that opened an "ARexx Port"... Other than, maybe, the
> original IBM REXX, I've not seen any other REXX implementation that
> would permit embedding application specific commands into a script.
> 
> Python's subprocess (and related) are all based on explicit startup
> and communication over stdin/stdout... Nothing like:
> 
> address TextEditor	/* a fictitious application port */
> 'DN 5'	/* move down five lines *?:
> 'MARK'		/* start a selection	*/
> 'RW 5'	/* move right five words */
> 'COPY'	/* copy selection to operation result */
> string = result
> address PageSetter	/* fictitious here, but a real program */
> 'PASTE' string	/* insert selected string into page document /*
> 
> Yes, maybe the above could be done as two sessions of subprocess --
> presuming both programs had a command line interface. But what if the
> script was going to switch between the two of them throughout one
> session.

For me this is not a DSL, but an external API of an application, like you 
have with COM under Windows, DBUS under Linux. Unix streams are just an 
ancestor way of communication, you could have local-RPC also, or CORBA.

So, as this is just inter-process communication procotol, if you have the 
Amigaes interprocess communication system tool written for Python, you could 
easily write things using a Python syntax:

te = TextEditor()
te.dn(5)
te.mark()
te.rw(5)
te.copy()
string = te.result()
ps = PageSetter()
ps.paste(string)

Python is a scripting language, and a nice one to use as glue between 
different components, eventually of different technologies.

(note: if you have more than one process to control via streams, you can 
open more than one pipe)

And... here http://www.solie.ca/articles/pythonmod/pythonmod.html
you could find modules for using Python with Amiga APIs and combining it 
with ARexx.

> The C compiler suites used this ability to read the error log from a
> compile, and move to the line/column in the source file associated with
> each error. (Before "integrated" development environments)

This is a + for compiled environments that you effectively cannot have with 
Python, non-syntaxic errors found at runtime.

A+
Laurent.

-- 
Laurent POINTAL - laurent.pointal@laposte.net

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

#47728

On 06/11/2013 03:48 PM, Laurent Pointal wrote:
> Dennis Lee Bieber wrote:
>
>> On Tue, 4 Jun 2013 18:17:33 -0700, Dan Stromberg <drsalists@gmail.com>
>> declaimed the following in gmane.comp.python.general:
>>
>>      <SNIP>
>
>> The C compiler suites used this ability to read the error log from a
>> compile, and move to the line/column in the source file associated with
>> each error. (Before "integrated" development environments)
>
> This is a + for compiled environments that you effectively cannot have with
> Python, non-syntaxic errors found at runtime.
>

Sure.  I think they're usually called exceptions.  And lo and behold, 
they come with filenames and line numbers.



-- 
DaveA

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

#47731

On Wed, Jun 12, 2013 at 12:02 PM, Dave Angel <davea@davea.name> wrote:
> On 06/11/2013 03:48 PM, Laurent Pointal wrote:
>>
>> Dennis Lee Bieber wrote:
>>
>>> On Tue, 4 Jun 2013 18:17:33 -0700, Dan Stromberg <drsalists@gmail.com>
>>> declaimed the following in gmane.comp.python.general:
>>>
>>>      <SNIP>
>>
>>
>>> The C compiler suites used this ability to read the error log from a
>>> compile, and move to the line/column in the source file associated with
>>> each error. (Before "integrated" development environments)
>>
>>
>> This is a + for compiled environments that you effectively cannot have
>> with
>> Python, non-syntaxic errors found at runtime.
>>
>
> Sure.  I think they're usually called exceptions.  And lo and behold, they
> come with filenames and line numbers.

Nearly every language has parse-time and run-time errors. Some skew it
further one way than the other, but (a) there will always be run-time
errors (interrupted, out of memory, etc), and (b) it'd be a stupid
language[1] that didn't even *try* to parse a file before running it.
The only difference is that C has a much heavier compile-time phase
than Python does, so the latter has to throw TypeError for 1+[]
instead of failing the compilation.

ChrisA

[1] I opened with "Nearly" because MS-DOS batch does seem to be this stupid.

[toc] | [prev] | [standalone]

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

csiph-web