Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > ger.ct > #614381 > unrolled thread
| Started by | "F. W." <me@home.invalid> |
|---|---|
| First post | 2024-01-23 12:27 +0100 |
| Last post | 2024-01-31 13:34 +0100 |
| Articles | 20 on this page of 108 — 23 participants |
Back to article view | Back to ger.ct
Zwei Textdateien zeilenweise abgleichen "F. W." <me@home.invalid> - 2024-01-23 12:27 +0100
Re: Zwei Textdateien zeilenweise abgleichen Ulf Kutzner <Ulf.Kutzner@web.de> - 2024-01-23 03:45 -0800
Re: Zwei Textdateien zeilenweise abgleichen "F. W." <me@home.invalid> - 2024-01-23 14:55 +0100
Re: Zwei Textdateien zeilenweise abgleichen Hartmut Ott <hartmut@arcor.de> - 2024-01-23 13:14 +0100
Re: Zwei Textdateien zeilenweise abgleichen Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-01-23 13:31 +0100
Re: Zwei Textdateien zeilenweise abgleichen "Wendelin Uez" <wuez@online.de> - 2024-01-23 13:50 +0100
Re: Zwei Textdateien zeilenweise abgleichen "F. W." <me@home.invalid> - 2024-01-23 14:56 +0100
Re: Zwei Textdateien zeilenweise abgleichen Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2024-01-25 11:16 +0100
Re: Zwei Textdateien zeilenweise abgleichen Shinji Ikari <shinji@gmx.net> - 2024-01-23 14:17 +0100
Re: Zwei Textdateien zeilenweise abgleichen "F. W." <me@home.invalid> - 2024-01-23 14:57 +0100
Re: Zwei Textdateien zeilenweise abgleichen Walter Brill <WalterBrill@t-online.de> - 2024-01-23 16:44 +0100
Re: Zwei Textdateien zeilenweise abgleichen Gunter Kühne <kuehne-g@freenet.de> - 2024-01-23 18:07 +0100
Re: Zwei Textdateien zeilenweise abgleichen "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2024-01-23 16:01 +0000
Re: Zwei Textdateien zeilenweise abgleichen Axel Reichert <mail@axel-reichert.de> - 2024-01-23 18:41 +0100
Re: Zwei Textdateien zeilenweise abgleichen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-01-24 18:14 +0100
Re: Zwei Textdateien zeilenweise abgleichen Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-01-24 19:09 +0100
Re: Zwei Textdateien zeilenweise abgleichen Axel Reichert <mail@axel-reichert.de> - 2024-01-24 21:00 +0100
Re: Zwei Textdateien zeilenweise abgleichen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-01-25 02:54 +0100
Re: Zwei Textdateien zeilenweise abgleichen Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-01-25 18:52 +0100
Re: Zwei Textdateien zeilenweise abgleichen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-01-25 03:16 +0100
Re: Zwei Textdateien zeilenweise abgleichen Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-01-25 18:51 +0100
Re: Zwei Textdateien zeilenweise abgleichen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-01-25 19:35 +0100
Re: Zwei Textdateien zeilenweise abgleichen; Ergänzung Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-01-25 20:10 +0100
Re: Zwei Textdateien zeilenweise abgleichen Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2024-01-25 22:42 +0000
Re: Zwei Textdateien zeilenweise abgleichen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-01-26 10:59 +0100
Re: Zwei Textdateien zeilenweise abgleichen Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2024-01-26 22:20 +0000
Re: Zwei Textdateien zeilenweise abgleichen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-01-27 14:36 +0100
Re: Zwei Textdateien zeilenweise abgleichen Michael Bode <m.g.bode@web.de> - 2024-01-27 14:46 +0100
Re: Zwei Textdateien zeilenweise abgleichen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-01-27 18:08 +0100
Re: Zwei Textdateien zeilenweise abgleichen Michael Bode <m.g.bode@web.de> - 2024-01-27 18:34 +0100
Re: Zwei Textdateien zeilenweise abgleichen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-01-28 09:46 +0100
Re: Zwei Textdateien zeilenweise abgleichen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-01-28 11:15 +0100
Re: Zwei Textdateien zeilenweise abgleichen Michael Bode <m.g.bode@web.de> - 2024-01-28 12:11 +0100
Re: Zwei Textdateien zeilenweise abgleichen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-01-28 12:43 +0100
Re: Zwei Textdateien zeilenweise abgleichen Georg Gruber <g.gruber_hauwech@gmx.net> - 2024-01-28 13:46 +0100
Re: Zwei Textdateien zeilenweise abgleichen Michael Bode <m.g.bode@web.de> - 2024-01-28 13:52 +0100
Re: Zwei Textdateien zeilenweise abgleichen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-01-28 21:26 +0100
Re: Zwei Textdateien zeilenweise abgleichen Ulf Kutzner <Ulf.Kutzner@web.de> - 2024-01-29 03:18 -0800
Re: Zwei Textdateien zeilenweise abgleichen "Dr. Joachim Neudert" <neudert@5sl.org> - 2024-03-01 12:30 +0100
Re: Zwei Textdateien zeilenweise abgleichen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-01-27 18:52 +0100
Re: Zwei Textdateien zeilenweise abgleichen Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2024-01-27 18:01 +0000
Re: Zwei Textdateien zeilenweise abgleichen Michael Bode <m.g.bode@web.de> - 2024-01-27 21:20 +0100
Re: Zwei Textdateien zeilenweise abgleichen Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2024-01-27 21:57 +0000
Re: Zwei Textdateien zeilenweise abgleichen Goetz Schultz <ng.expire1225@goetz.co.uk> - 2024-01-27 20:17 +0000
Re: Zwei Textdateien zeilenweise abgleichen Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-01-25 18:59 +0100
Re: Zwei Textdateien zeilenweise abgleichen Michael Bode <m.g.bode@web.de> - 2024-01-25 19:08 +0100
Re: Zwei Textdateien zeilenweise abgleichen Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-01-25 20:10 +0100
Re: Zwei Textdateien zeilenweise abgleichen Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2024-01-25 19:45 +0000
Re: Zwei Textdateien zeilenweise abgleichen "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2024-01-26 09:07 +0000
Re: Zwei Textdateien zeilenweise abgleichen Andreas Karrer <ak-4a@gmx.ch> - 2024-01-26 10:02 +0000
Re: Zwei Textdateien zeilenweise abgleichen "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2024-01-26 10:41 +0000
Re: Zwei Textdateien zeilenweise abgleichen Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-01-27 18:39 +0100
Re: Zwei Textdateien zeilenweise abgleichen Andreas Karrer <ak-4a@gmx.ch> - 2024-01-26 00:02 +0000
Re: Zwei Textdateien zeilenweise abgleichen Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-01-26 06:57 +0100
Re: Zwei Textdateien zeilenweise abgleichen Andreas Karrer <ak-4a@gmx.ch> - 2024-01-26 09:55 +0000
Re: Zwei Textdateien zeilenweise abgleichen Michael Zink <michael@swamp.franken.de> - 2024-01-27 10:03 +0100
Re: Zwei Textdateien zeilenweise abgleichen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-01-27 13:10 +0100
Re: Zwei Textdateien zeilenweise abgleichen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-01-27 14:45 +0100
Re: Zwei Textdateien zeilenweise abgleichen "Dr. Joachim Neudert" <neudert@5sl.org> - 2024-01-27 18:18 +0100
Re: Zwei Textdateien zeilenweise abgleichen Michael Bode <m.g.bode@web.de> - 2024-01-27 18:47 +0100
Re: Zwei Textdateien zeilenweise abgleichen Georg Gruber <g.gruber_hauwech@gmx.net> - 2024-01-27 19:39 +0100
Re: Zwei Textdateien zeilenweise abgleichen Michael Bode <m.g.bode@web.de> - 2024-01-27 21:24 +0100
Re: Zwei Textdateien zeilenweise abgleichen Georg Gruber <g.gruber_hauwech@gmx.net> - 2024-01-28 00:03 +0100
Re: Zwei Textdateien zeilenweise abgleichen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-01-28 09:00 +0100
Re: Zwei Textdateien zeilenweise abgleichen Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-01-27 18:36 +0100
Re: Zwei Textdateien zeilenweise abgleichen Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-01-27 19:42 +0100
Re: Zwei Textdateien zeilenweise abgleichen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-01-28 09:43 +0100
Re: Zwei Textdateien zeilenweise abgleichen Georg Gruber <g.gruber_hauwech@gmx.net> - 2024-01-28 11:12 +0100
Re: Zwei Textdateien zeilenweise abgleichen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-01-28 11:38 +0100
Re: Zwei Textdateien zeilenweise abgleichen Georg Gruber <g.gruber_hauwech@gmx.net> - 2024-01-28 11:56 +0100
Re: Zwei Textdateien zeilenweise abgleichen Michael Bode <m.g.bode@web.de> - 2024-01-28 12:09 +0100
Re: Zwei Textdateien zeilenweise abgleichen Georg Gruber <g.gruber_hauwech@gmx.net> - 2024-01-28 12:31 +0100
Re: Zwei Textdateien zeilenweise abgleichen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-01-28 12:38 +0100
Re: Zwei Textdateien zeilenweise abgleichen Georg Gruber <g.gruber_hauwech@gmx.net> - 2024-01-28 13:33 +0100
Re: Zwei Textdateien zeilenweise abgleichen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-01-28 21:06 +0100
Re: Zwei Textdateien zeilenweise abgleichen Georg Gruber <g.gruber_hauwech@gmx.net> - 2024-01-28 23:38 +0100
Re: Zwei Textdateien zeilenweise abgleichen Georg Gruber <g.gruber_hauwech@gmx.net> - 2024-01-31 13:37 +0100
Re: Zwei Textdateien zeilenweise abgleichen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-01-31 13:54 +0100
Re: Zwei Textdateien zeilenweise abgleichen Georg Gruber <g.gruber_hauwech@gmx.net> - 2024-01-31 15:11 +0100
Re: Zwei Textdateien zeilenweise abgleichen Matthias Eißing <meissing@gmx.de> - 2024-01-31 15:19 +0100
Re: Zwei Textdateien zeilenweise abgleichen Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-01-28 16:00 +0100
[Python3] print() (was: Zwei Textdateien zeilenweise abgleichen) Marcel Logen <333200007110-0201@ybtra.de> - 2024-01-28 16:20 +0100
Re: Zwei Textdateien zeilenweise abgleichen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-01-28 21:16 +0100
Re: Zwei Textdateien zeilenweise abgleichen Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-01-30 07:24 +0100
Re: Zwei Textdateien zeilenweise abgleichen Michael Bode <m.g.bode@web.de> - 2024-02-02 17:40 +0100
Re: Zwei Textdateien zeilenweise abgleichen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-02-02 20:00 +0100
Re: Zwei Textdateien zeilenweise abgleichen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-02-03 12:15 +0100
Re: Zwei Textdateien zeilenweise abgleichen; Ergänzung Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-02-03 12:45 +0100
Re: Zwei Textdateien zeilenweise abgleichen; Ergänzung Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-02-03 16:27 +0100
Re: Zwei Textdateien zeilenweise abgleichen "F. W." <me@home.invalid> - 2024-01-25 09:54 +0100
Re: Zwei Textdateien zeilenweise abgleichen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-01-25 11:54 +0100
Re: Zwei Textdateien zeilenweise abgleichen "F. W." <me@home.invalid> - 2024-01-25 12:13 +0100
Re: Zwei Textdateien zeilenweise abgleichen Ruediger Lahl <ruediger.lahl@gmx.de> - 2024-01-25 13:56 +0100
Re: Zwei Textdateien zeilenweise abgleichen "F. W." <me@home.invalid> - 2024-01-25 15:24 +0100
Re: Zwei Textdateien zeilenweise abgleichen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-01-25 14:42 +0100
Re: Zwei Textdateien zeilenweise abgleichen "F. W." <me@home.invalid> - 2024-01-25 15:31 +0100
Re: Zwei Textdateien zeilenweise abgleichen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-01-25 17:38 +0100
Re: Zwei Textdateien zeilenweise abgleichen Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2024-01-25 18:52 +0100
Re: Zwei Textdateien zeilenweise abgleichen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-01-25 19:10 +0100
Re: Zwei Textdateien zeilenweise abgleichen Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2024-01-25 19:28 +0100
Re: Zwei Textdateien zeilenweise abgleichen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-01-25 19:56 +0100
Re: Zwei Textdateien zeilenweise abgleichen "F. W." <me@home.invalid> - 2024-01-30 10:11 +0100
Re: Zwei Textdateien zeilenweise abgleichen Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2024-01-30 10:56 +0100
Re: Zwei Textdateien zeilenweise abgleichen "F. W." <me@home.invalid> - 2024-01-26 07:43 +0100
Re: Zwei Textdateien zeilenweise abgleichen Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-01-27 18:45 +0100
Re: Zwei Textdateien zeilenweise abgleichen "F. W." <me@home.invalid> - 2024-01-30 07:29 +0100
Re: Zwei Textdateien zeilenweise abgleichen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-01-31 13:09 +0100
Re: Zwei Textdateien zeilenweise abgleichen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-01-31 13:34 +0100
Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
| From | Gerrit Heitsch <gerrit@laosinh.s.bawue.de> |
|---|---|
| Date | 2024-01-28 16:00 +0100 |
| Message-ID | <up5pcn$13j$2@news.bawue.net> |
| In reply to | #614586 |
On 1/28/24 09:43, Hermann Riemann wrote:
> Am 27.01.24 um 19:42 schrieb Gerrit Heitsch:
>
>> Man kann also einen String wie ein Tuple behandeln?
>
> Behandeln, teilweise.
>
> string, list und tuple
> werden teilweise wie arrays behandelt
> Also mit Syntax wie Element a[index]
> bzw.: Bereich: a[start_index:end_index]
> wobei start_index beim weglassen Anfang,
> end_index beim weglassen Ende bedeutet.
> Und bei -Zeichen von hinten gezählt wird.
>
> string ist ein array von utf-Zeichen, der nicht verändert werden kann.
> list und tuple sind arrays deren Elemente beliebig sind,
> also auch ihrerseits wieder list ..
> Tupels dürfen nicht verändert werden, list schon.
> Bei list dürfen beliebige Bereiche gelöscht und eingefügt werden.
>
> t='a','b' # tuple wird erzeugt
> s=''.join(t) # nach string konvertiert
> print(s,tuple(s)) # 2. Parameter: nach tuple zurück konvertiert
>
> ab ('a', 'b') # Ergebnis von print
>
> Ähnlich ist noch dictionary,
> was einem array ähnelt, deren Indices beliebige Konstanten sind.
> Und wenn man da auf den array Inhalt verzichtet,
> und nur die Indices betrachtet, landet man beim Datentyp set
> für Mengenlehre.
>
> Und bei all diesen Typen kann man
> mit for element in was:
> eine Schleife über einzelne Elemente ausführen.
> ..
>
>>> |>>> print( type( a[ 0 ][ 0 ]))
>>> |<class 'str'>
>>> |
>>> |>>> print( a[ 1 ])
>>> |beta
>>> |
>>> |>>> print( type( a[ 1 ]))
>>> |<class 'str'>
>>> |
>>> |>>> print( a[ 2 ])
>>> |('gamma', 'delta')
>>> |
>>> |>>> print( type( a[ 2 ]))
>>> |<class 'tuple'>
>>> |
>>> |>>> print( a[ 2 ][ 0 ])
>>> |gamma
>>> |
>>> |>>> print( a[ 2 ][ 1 ])
>>> |delta
>>> |
>>> |>>> print( a )
>>> |('alpha', 'beta', ('gamma', 'delta'))
>>
>> Sehr konfus. Problematisch ist, daß das 'print(a)' nicht den Inhalt
>> von 'a' ausgibt sondern den Inhalt mit einer Formatierung vermischt
>> während andere print() Statements das nicht tun sondern nur den Inhalt
>> ausgeben.
>
> print in Python gibt die Struktur mit aus.
Beim Typ str aber nicht. Oder wie erkennt man bei
print( a[ 1 ])
den Unterschied zwischen
a = ('alpha', 'beta', ('gamma', 'delta'))
und
a = ('alpha', 'beta ', ('gamma', 'delta'))
korrekt betrachtet müsste die Ausgabe
'beta '
sein, also mit Quotes.
Gerrit
[toc] | [prev] | [next] | [standalone]
| From | Marcel Logen <333200007110-0201@ybtra.de> |
|---|---|
| Date | 2024-01-28 16:20 +0100 |
| Subject | [Python3] print() (was: Zwei Textdateien zeilenweise abgleichen) |
| Message-ID | <AABltnCqhtcAAPFu.A3.flnews@t20.ybtra.de> |
| In reply to | #614615 |
Gerrit Heitsch in ger.ct:
[...]
>a = ('alpha', 'beta ', ('gamma', 'delta'))
>
>korrekt betrachtet müsste die Ausgabe
>
>'beta '
>
>sein, also mit Quotes.
| t20$ python3
| Python 3.10.13 (main, Jan 6 2024, 06:37:28) [Clang 16.0.6 ] on openbsd7
| Type "help", "copyright", "credits" or "license" for more information.
| >>> a='alpha', 'beta ',('gamma','delta')
| >>> a
| ('alpha', 'beta ', ('gamma', 'delta'))
| >>> print(a)
| ('alpha', 'beta ', ('gamma', 'delta'))
| >>> a[1]
| 'beta '
| >>> print(a[1])
| beta
^ da steht ein SPACE
| >>> print('"'+a[1]+'"')
| "beta "
| >>> quit()
| t20$
Marcel 12rdb (1142187)
--
╭──────╮ ╭──────────╮
╰────╮ │ ╭──╮ ╰───╮ ╭──╯
╭──────╮ ╭───╮ ╭─╯ ╰─╮ │ │ ╭─╮ ╭──╮ ╭─╯ │ ╭─╮ ╭─╮ ╭
─╯38f857╰──╯ ╰─╯ ╰─╯ ╰───╯ ╰────────────╯ ╰─╯ ╰─╯ ╰───╯ ╰──╯
[toc] | [prev] | [next] | [standalone]
| From | Hermann Riemann <nospam.ng@hermann-riemann.de> |
|---|---|
| Date | 2024-01-28 21:16 +0100 |
| Message-ID | <l1nr1lFko40U1@mid.individual.net> |
| In reply to | #614615 |
Am 28.01.24 um 16:00 schrieb Gerrit Heitsch:
>> print in Python gibt die Struktur mit aus.
Da hätte ich "mit Ausnahme von string" dazuschreiben müssen
> Beim Typ str aber nicht. Oder wie erkennt man bei
Das Ergebnis von str ist ein string
> print( a[ 1 ])
>
> den Unterschied zwischen
>
> a = ('alpha', 'beta', ('gamma', 'delta'))
>
> und
>
> a = ('alpha', 'beta ', ('gamma', 'delta'))
>
> korrekt betrachtet müsste die Ausgabe
>
> 'beta '
>
> sein, also mit Quotes.
print(len(a[1]))
'beta' und 'beta ' sind strings, die von print
ohne quotes ausgegeben werden.
Aus shell Komandoebene führt
a='beta'
a
zu
'beta'
[toc] | [prev] | [next] | [standalone]
| From | Gerrit Heitsch <gerrit@laosinh.s.bawue.de> |
|---|---|
| Date | 2024-01-30 07:24 +0100 |
| Message-ID | <upa3ts$ihk$2@news.bawue.net> |
| In reply to | #614615 |
On 1/28/24 16:23, Stefan Ram wrote:
> Gerrit Heitsch <gerrit@laosinh.s.bawue.de> writes:
>> Beim Typ str aber nicht. Oder wie erkennt man bei
>> print( a[ 1 ])
>> den Unterschied zwischen
>> a = ('alpha', 'beta', ('gamma', 'delta'))
>> und
>> a = ('alpha', 'beta ', ('gamma', 'delta'))
>> korrekt betrachtet müsste die Ausgabe
>> 'beta'
>> sein, also mit Quotes.
>
> Das ist in der Python-Kommandozeile sogar noch einfacher als
> das angegebene Beispiel: Um das zu erreichen, muß man nämlich
> /weniger/ schreiben als sonst: Man muß "print" /weglassen/!
Auf der Kommandozeile vielleicht, aber nicht im Script selber, oder?
Gerrit
[toc] | [prev] | [next] | [standalone]
| From | Michael Bode <m.g.bode@web.de> |
|---|---|
| Date | 2024-02-02 17:40 +0100 |
| Message-ID | <l24k7uF9a0U1@mid.individual.net> |
| In reply to | #614428 |
ram@zedat.fu-berlin.de (Stefan Ram) writes: > ram@zedat.fu-berlin.de (Stefan Ram) writes: >>|Die Schreibweise "Perl" bezeichnet die Sprache, "perl" > > Mein neuestes selbstgeschriebenes Python-Programm kann > Archiv-Dateien durchsuchen. Damit kann ich herausfinden, wer > aus meinem ger.ct-Archiv "PERL" ganz in Großbuchstaben schrieb. Du hast zgrep geschrieben?
[toc] | [prev] | [next] | [standalone]
| From | Hermann Riemann <nospam.ng@hermann-riemann.de> |
|---|---|
| Date | 2024-02-02 20:00 +0100 |
| Message-ID | <l24segF1uicU1@mid.individual.net> |
| In reply to | #614428 |
Am 02.02.24 um 11:32 schrieb Stefan Ram: > ram@zedat.fu-berlin.de (Stefan Ram) writes: >> |Die Schreibweise "Perl" bezeichnet die Sprache, "perl" > > Mein neuestes selbstgeschriebenes Python-Programm kann > Archiv-Dateien durchsuchen. Damit kann ich herausfinden, wer > aus meinem ger.ct-Archiv "PERL" ganz in Großbuchstaben schrieb. > > Das sollte mit Usenet-Archiven im Web schwierig sein, weil diese > normalerweise keine Suche nach Großschreibung unterstützen und > auch keine so übersichtliche Ausgabe im Textformat erzeugen. > Meine nächsten Python Programme prg1 prg2 sollen untereinander kommunizieren, so dass sie im Kommando prg1 -ftp directory_name | ftp provider1 | prg2 bzw. prg1 -sftp directory_name | sftp provider2 | prg2 rsync -a --delete nachbilden. Das macht bei unterschiedlichen directories kleine Probleme, da ls -lR in sftp nicht funktioniert hat.
[toc] | [prev] | [next] | [standalone]
| From | Hermann Riemann <nospam.ng@hermann-riemann.de> |
|---|---|
| Date | 2024-02-03 12:15 +0100 |
| Message-ID | <l26li7Fbo2tU1@mid.individual.net> |
| In reply to | #614922 |
Am 02.02.24 um 20:10 schrieb Stefan Ram:
> Hermann Riemann <nospam.ng@hermann-riemann.de> writes:
>> Meine nächsten Python Programme prg1 prg2 sollen untereinander
>> kommunizieren, so dass sie im Kommando
>> prg1 -ftp directory_name | ftp provider1 | prg2
>> bzw.
>> prg1 -sftp directory_name | sftp provider2 | prg2
>> rsync -a --delete nachbilden.
>
> Mit etwas Ähnlichem beschäftige ich mich auch gerade.
>
> Ich habe ein Programm "synchdir" geschrieben, das aber etwas
> anderes tut als "rsync": Es vergleicht im wesentlichen den
> Inhalt zweier Verzeichnisse Bit für Bit, um Kopierfehler zu
> entdecken. Falls es einen Fehler entdeckt, versucht es dann
> ihn zu reparieren, indem es die Datei solange neu kopiert,
> bis keine Abweichung mehr gefunden wird.
Das erinnert mich an Vergleiche zwischen Original Verzeichnis
und Verzeichnis der Datensicherung oder zwischen 2
Datensicherungsverzeichnissen..
Wobei noch softlinks ( keine Inhalte ) zu berücksichtigen sind.
Inhalte von Dateien habe ich mit wahrscheinlich
if open(dateiname1).read()==open(dateiname2).read(): verglichen.
Bei Kopieren ziehe ich os.system(f"cp -p {dateiname1} {dateiname2}"))
vor.
> Das Programm läuft zwar schon, aber man muß noch den Quellcode
> editieren, um die Verzeichnispfade einzugeben - ich möchte
> jetzt noch eine GUI dafür bauen. Zum Glück ist das ja auch
> bereits mit dem Standard von Python möglich, dank tkinter!
Früher habe ich cgi als GUI verwendet,
da html editieren und lesen und schreiben über Python
einfach ist. Leider wurde ab Python 11 cgi bin gestrichen,
und die Verbindung über json habe ich noch nicht in Griff.
Mein Basteleien mit QT5 sind nicht im gewünschten Zustand
und mein Traum SDL2ttf hat bisher nicht funktioniert.
Im Zweifelsfall editiere in meine Kommandos bzw Daten
bzw Abkürzungen ( auch für Kommandooberfläche)
"einmalig" in /tmp/x.txt oder "dauerhaft" in
/eigene_Dateien/garbage/irgendwas.txt
Und passe die Dateinamen am Anfang der .py Datei an.
> Wegen anderer, paralleler Projekte wird sich die Entwicklung
> der GUI aber vermutlich noch länger hinziehen.
Das ?ftp oben dient zur Übertragung auf meine externe homepages
--
<http://www.hermann-riemann.de>
[toc] | [prev] | [next] | [standalone]
| From | Hermann Riemann <nospam.ng@hermann-riemann.de> |
|---|---|
| Date | 2024-02-03 12:45 +0100 |
| Subject | Re: Zwei Textdateien zeilenweise abgleichen; Ergänzung |
| Message-ID | <l26na4Fc2gkU1@mid.individual.net> |
| In reply to | #614954 |
Am 03.02.24 um 12:15 schrieb Hermann Riemann: > if open(dateiname1).read()==open(dateiname2).read(): verglichen. Es muss open(dateiname,"rb") heissen, das b steht für binary sonst gibt es Fehler oder dauert viel länger.
[toc] | [prev] | [next] | [standalone]
| From | Hermann Riemann <nospam.ng@hermann-riemann.de> |
|---|---|
| Date | 2024-02-03 16:27 +0100 |
| Subject | Re: Zwei Textdateien zeilenweise abgleichen; Ergänzung |
| Message-ID | <l274adFec8cU1@mid.individual.net> |
| In reply to | #614964 |
Am 03.02.24 um 13:01 schrieb Stefan Ram:
> Hermann Riemann <nospam.ng@hermann-riemann.de> writes:
>> Am 03.02.24 um 12:15 schrieb Hermann Riemann:
>>> if open(dateiname1).read()==open(dateiname2).read(): verglichen.
>> Es muss open(dateiname,"rb") heissen, das b steht für binary
>> sonst gibt es Fehler oder dauert viel länger.
>
> Aber würde das auch gehen, wenn die Datei nicht in den Speicher paßt?
Falls es vom Warten her nicht eilig ist: swapspace mit USB-Platte
Ansonsten der Vergleich in Blöcke zerlegen.
Vor einem Inhaltsvergleich würde ich mir erst mit
os.stat(path) über st_size einen Längenvergleich machen
Eventuell auch über st_mode Leserechte nachschauen
> Mein Verfahren sieht derzeit - etwas gekürzt - so aus:
>
> try:
> with open( source, 'rb' )as source_file:
> with open( target, 'rb' )as target_file:
> try:
> sdata = source_file.read( size )
> except ...
> while sdata:
> try:
> tdata = target_file.read( size )
> except ...
> if sdata != tdata:
> source_file.close()
> target_file.close()
> return not_equal( source, target )
> try:
> sdata = source_file.read( size )
> except ...
> except PermissionError as e:
> print( "Permission denied. Skipping this." )
>
print ohne Verzeichnisname und Dateiname würden
Aktionen wie bei allen Verzeichnissen und Dateien
Lese und Schreibrecht setzten erschweren.
Wenn das size bei read() weggelassen wird,
wird die ganze Datei eingelesen.
Dateien können vermutlich nicht direkt in den swap Speicher
eingelesen werden.
Hermann
sich noch an rekursive setzten derartiger Bits
nach Kopieren von CDs erinnernd.
--
<http://www.hermann-riemann.de>
[toc] | [prev] | [next] | [standalone]
| From | "F. W." <me@home.invalid> |
|---|---|
| Date | 2024-01-25 09:54 +0100 |
| Message-ID | <uot7ke$t4pm$3@solani.org> |
| In reply to | #614423 |
Am 24.01.2024 um 18:14 schrieb Hermann Riemann: > Vielleicht nach Python3 wechseln? Ich mache Pascal seit etwa 1981 und kenne mich da ein wenig aus. Alle drei Jahre kam eine neue Programmiersprache, die jetzt, ja jetzt wirklich, besser war als Pascal. Mir sind die modernen Sprachen zu kryptisch. Ich mag selbsterklärenden Code und da bin ich bei Pascal gut aufgehoben. Und ja: ich mache auch manchmal Basic und COBOL auch. Was man kommentieren muss, ist für mich ungeeignet. Ich mache auch mal C, aber sehr ungern. Aber schon C++ stellt Programmabläufe sehr schwer lesbar dar. Da finde ich Assembler ja lesbarer. Ich möchte mich um das Werkstück kümmern und nicht um das Werkzeug. So sehe ich das. Auch wenn ich jetzt eine sinnlose Sprachargumentation lostreten sollte. > Nach meiner Erfahrung ist Pascal bezüglich Textverarbeitung im > Vergleich zu Python ( und C* und..) sehr umständlich. copy, concat, leftstr, rightstr, asc, chr, pos ... mehr brauche ich nicht. Die alten Recken arbeiten hier noch jeden Tag. > Für Spezialwünsche sind fertige Programme schwer oder nicht zu > finden, so dass da selber in Python programmieren schneller geht. Da ich erst mal Python wirklich lernen müsste, ist das keine Option. Kostet zu viel Zeit. Ein Teil der hohen Kosten meiner Software-Firma wurde auch dadurch vermieden, dass die Programme nicht alle vier Jahre neu programmiert werden mussten, weil der letzte Schrei gerade in war. Nenn mich ruhig altertümlich. FW
[toc] | [prev] | [next] | [standalone]
| From | Hermann Riemann <nospam.ng@hermann-riemann.de> |
|---|---|
| Date | 2024-01-25 11:54 +0100 |
| Message-ID | <l1esujFcvrU1@mid.individual.net> |
| In reply to | #614446 |
Am 25.01.24 um 09:54 schrieb F. W.:
> Am 24.01.2024 um 18:14 schrieb Hermann Riemann:
>
>> Vielleicht nach Python3 wechseln?
>
> Ich mache Pascal seit etwa 1981 und kenne mich da ein wenig aus. Alle
> drei Jahre kam eine neue Programmiersprache, die jetzt, ja jetzt
> wirklich, besser war als Pascal.
Ich habe viele Programmiersprachen verwendet.
Für Textbearbeitung hatte ich Hauptprogrammiersprachen.
Ausbildung und Beruf Fortran.
( Im Beruf war eingeschränkte Auswahlerlaubnis. ).
Privat bis etwa 2010 C, danach Python
> Mir sind die modernen Sprachen zu kryptisch. Ich mag selbsterklärenden
> Code und da bin ich bei Pascal gut aufgehoben.
Python ist wenig kryptisch. Deutlich weniger als Basic
Es macht im Vergleich zu Sprachen mit compiler
erheblich weniger Verwaltungsaufwand.
Kein Unterschied char string; integer und string nur beliebige Länge..
Ab Python3 ist char bzw string utf und nicht byte.
Variablentyp wird durch Zuweisung gesetzt.
> Und ja: ich mache auch manchmal Basic und COBOL auch.
Basic habe ich selten gemacht.
COBOL beruflich vermutlich weniger als 5 Programme.
> Was man kommentieren muss, ist für mich ungeeignet.
Was in Pascal nicht kommentiert wird,
wird es in Python vermutlich auch nicht.
> Ich mache auch mal C, aber sehr ungern. Aber schon C++ stellt
> Programmabläufe sehr schwer lesbar dar. > Da finde ich Assembler ja lesbarer.
In Spezialfällen verwende ich auch noch C
C++ hat es bei mir nicht bis zu einer Anwendung geschafft.
Dafür waren meine Projekte zu klein.
Assembler war Atari ST, meine computer mit 8 bit CPU
habe ich fast nur hex in Maschinencode programmiert.
> Ich möchte mich um das Werkstück kümmern und nicht um das Werkzeug. So
> sehe ich das. Auch wenn ich jetzt eine sinnlose Sprachargumentation
> lostreten sollte.
Das Werkzeug soll wenig Arbeit machen.
Die Zeitersparnis von Python ist erheblich.
Kryptische Sprachen wie bash sind gut für Einzeiler
oder nach Benutzung Wegwerf Programme
>> Nach meiner Erfahrung ist Pascal bezüglich Textverarbeitung im
>> Vergleich zu Python ( und C* und..) sehr umständlich.
> copy, concat, leftstr, rightstr, asc, chr, pos ... mehr brauche ich
> nicht. Die alten Recken arbeiten hier noch jeden Tag.
copy ist in Python Zuweisung
concat wird mit + erledigt
a="bla"
b=a
c=a+b
Dann liefert
print(c,2*a,c[2],a[:2],a[-2:])
print(c.find("la"),c.rfind("la"))
blabla blabla a bl la
1 4
Das dürfte in Pascal mehr Arbeit machen.
Anmerkung: Das erste Element hat in Python wie bei C den Index 0
>> Für Spezialwünsche sind fertige Programme schwer oder nicht zu finden,
>> so dass da selber in Python programmieren schneller geht.
> Da ich erst mal Python wirklich lernen müsste, ist das keine Option.
Was ist mit "wirklich" gemeint?
Perfekt oder nur für einfachen Gebrauch?
> Kostet zu viel Zeit.
Für den einfachen Gebrauch ist Python schnell erlernbar.
In Linux Python aufrufen und obige Zuweisungen und print Zeilen eingeben..
Viele Feinheiten kommen nach und nach.
> Ein Teil der hohen Kosten meiner Software-Firma wurde auch dadurch
> vermieden, dass die Programme nicht alle vier Jahre neu programmiert
> werden mussten, weil der letzte Schrei gerade in war.
Mein code von 1978 ist vermutlich immer noch käuflich und im Einsatz.
Der in C von vor 1992 mit Sicherheit.
Bei Pascal und Basic besteht die Gefahr, dass sie irgendwann
auf neu aktuelle Maschinen nicht mehr verwendet werden können.
C und Python dürften da sicherer sein.
> Nenn mich ruhig altertümlich.
Kennst Du noch Rechenschieber, Logarithmentafel, ALGOL60, Lochkarten..?
Hermann
dessen neue Lötstation noch nicht in Betrieb war.
--
<http://www.hermann-riemann.de>
[toc] | [prev] | [next] | [standalone]
| From | "F. W." <me@home.invalid> |
|---|---|
| Date | 2024-01-25 12:13 +0100 |
| Message-ID | <uotfp6$t4pn$1@solani.org> |
| In reply to | #614449 |
Am 25.01.2024 um 11:54 schrieb Hermann Riemann: >> Mir sind die modernen Sprachen zu kryptisch. Ich mag >> selbsterklärenden Code und da bin ich bei Pascal gut aufgehoben. > Python ist wenig kryptisch. Deutlich weniger als Basic. Ist wahr? Ich fand BASIC immer selbsterklärend. Damit meine ich das zeilenorientierte, interpretierte BASIC. 10 PRINT "Wie heißen Sie?" 20 INPUT Name$ 30 IF Name$<>"Admin" THEN GOTO 50 40 PRINT "Hallo, Boss!" 50 PRINT "Hallo, ";Name$ 60 GOSUB ... Das sollte jeder verstehen. Jedenfalls haben viel mehr Schüler im BASIC-Unterricht alles verstanden als bei anderen Sprachen. > Es macht im Vergleich zu Sprachen mit compiler erheblich weniger > Verwaltungsaufwand. Dafür schreibst Du immer alternativlos Open-Source. Für bezahlte Geschäftsanwendungen nicht zu empfehlen. >> Was man kommentieren muss, ist für mich ungeeignet. > Was in Pascal nicht kommentiert wird, wird es in Python vermutlich > auch nicht. Möglich. Aber Pascal und viel mehr COBOL sollten eben von sich aus klar verständlich sein. Wirth soll anfangs mit Jürg Gutknecht sogar darüber diskutiert haben, ob man überhaupt einen (* Kommentar *) zulässt. > > Was ist mit "wirklich" gemeint? Perfekt oder nur für einfachen > Gebrauch? > Ich habe ein bisschen mit Thonny geschrieben und meine Raspis laufen auch mit Python. Aber mehr wollte ich nie. > Für den einfachen Gebrauch ist Python schnell erlernbar. In Linux > Python aufrufen und obige Zuweisungen und print Zeilen eingeben.. > Viele Feinheiten kommen nach und nach. Ja, deshalb ackern bei mir die Raspis mit Python. Aber auf den Laptops läuft nur Pascal (bzw. FreePascal bzw. Lazarus). > Bei Pascal und Basic besteht die Gefahr, dass sie irgendwann auf neu > aktuelle Maschinen nicht mehr verwendet werden können. C und Python > dürften da sicherer sein. Ist Python denn zu sich selbst kompatibel? Python 1, 2 und 3? Also bei PHP hatte ich schon Probleme. Lazarus ist zu ObjectPascal, Pascal-S und Turbo kompatibel. Meine Programme seit 1990 kamen fast sofort durch den Compiler. Das schätzte ich immer sehr. Vor allem, da ich 1990 tatsächlich noch einen Apple ][ mit UCSD-Pascal hatte. Selbst dieser merkwürdige Dialekt machte wenig Arbeit auf den PCs. >> Nenn mich ruhig altertümlich. > Kennst Du noch Rechenschieber, Logarithmentafel, ALGOL60, > Lochkarten..? Rechenschieber musste ich im Informatikunterricht lernen. Logarithmentafel kenne ich nur theoretisch und brauchte es nie. ALGOL60 als Vorgänger zu Pascal war Thema im Studium. Lochkarten haben wir im Informatikunterricht gebastelt. Aber meine Flamme entzündete sich erst mit Pascal. Im Sommer 1984 bin ich nicht verreist, sondern habe alle meine 20 BASIC-Programme in Pascal übersetzt. Meine Eltern wollten schon den Arzt rufen. :-D FW
[toc] | [prev] | [next] | [standalone]
| From | Ruediger Lahl <ruediger.lahl@gmx.de> |
|---|---|
| Date | 2024-01-25 13:56 +0100 |
| Message-ID | <uotpb8.8ic.1@privat.lahls.de> |
| In reply to | #614452 |
*F. W.* schrieb: > Ist wahr? Ich fand BASIC immer selbsterklärend. Damit meine ich das > zeilenorientierte, interpretierte BASIC. > > 10 PRINT "Wie heißen Sie?" > 20 INPUT Name$ > 30 IF Name$<>"Admin" THEN GOTO 50 > 40 PRINT "Hallo, Boss!" > 50 PRINT "Hallo, ";Name$ > 60 GOSUB ... Wenn der Name "Admin" ist, kommt das hier: Hallo, Boss! Hallo, Admin -- bis denne
[toc] | [prev] | [next] | [standalone]
| From | "F. W." <me@home.invalid> |
|---|---|
| Date | 2024-01-25 15:24 +0100 |
| Message-ID | <uotqu2$tjq9$6@solani.org> |
| In reply to | #614456 |
Am 25.01.2024 um 13:56 schrieb Ruediger Lahl: > *F. W.* schrieb: > >> Ist wahr? Ich fand BASIC immer selbsterklärend. Damit meine ich das >> zeilenorientierte, interpretierte BASIC. >> >> 10 PRINT "Wie heißen Sie?" >> 20 INPUT Name$ >> 30 IF Name$<>"Admin" THEN GOTO 50 >> 40 PRINT "Hallo, Boss!" >> 50 PRINT "Hallo, ";Name$ >> 60 GOSUB ... > > Wenn der Name "Admin" ist, kommt das hier: > Hallo, Boss! > Hallo, Admin Bestanden! FW
[toc] | [prev] | [next] | [standalone]
| From | Hermann Riemann <nospam.ng@hermann-riemann.de> |
|---|---|
| Date | 2024-01-25 14:42 +0100 |
| Message-ID | <l1f6qiF2gv3U1@mid.individual.net> |
| In reply to | #614452 |
Am 25.01.24 um 12:13 schrieb F. W.:
> Am 25.01.2024 um 11:54 schrieb Hermann Riemann:
>
>>> Mir sind die modernen Sprachen zu kryptisch. Ich mag
>>> selbsterklärenden Code und da bin ich bei Pascal gut aufgehoben.
>
>> Python ist wenig kryptisch. Deutlich weniger als Basic.
>
> Ist wahr? Ich fand BASIC immer selbsterklärend. Damit meine ich das
> zeilenorientierte, interpretierte BASIC.
>
> 10 PRINT "Wie heißen Sie?"
> 20 INPUT Name$
> 30 IF Name$<>"Admin" THEN GOTO 50
> 40 PRINT "Hallo, Boss!"
> 50 PRINT "Hallo, ";Name$
> 60 GOSUB ...
>
> Das sollte jeder verstehen. Jedenfalls haben viel mehr Schüler im
> BASIC-Unterricht alles verstanden als bei anderen Sprachen.
Obiges in Python
print("Wie heißen Sie?")
name=input()
if name=="Admin":
print("Hallo Boss")
print("Hallo",name)
...
Einrückung statt Nummern für Zeilen.
>> Es macht im Vergleich zu Sprachen mit compiler erheblich weniger
>> Verwaltungsaufwand.
> Dafür schreibst Du immer alternativlos Open-Source.
Ich programmiere zu Hause nur für eigenen Gebrauch.
Beruflich habe ich im Team an gemeinsamen Projekten gearbeitet,
die auch lizensiert wurden und immer noch verwendet werden.
> Für bezahlte Geschäftsanwendungen nicht zu empfehlen.
Das hängt von Projektgröße und Laufzeit ab.
Python macht dank fehlender .h Dateien Schnittstellenprobleme.
Und die Geschwindigkeit, in der Python Programme ablaufen,
ist, wie bei jedem interpreter, geringer.
>>> Was man kommentieren muss, ist für mich ungeeignet.
>
>> Was in Pascal nicht kommentiert wird, wird es in Python vermutlich
>> auch nicht.
>
> Möglich. Aber Pascal und viel mehr COBOL sollten eben von sich aus klar
> verständlich sein. Wirth soll anfangs mit Jürg Gutknecht sogar darüber
> diskutiert haben, ob man überhaupt einen (* Kommentar *) zulässt.
Die Verständlichkeit hängt primär von Programmierstil und Namenswahl ab.
Sind beide gleich, bringt Python noch einen Vorteil durch
weniger Text und Zeichen, die zur Verwaltung gehören.
>> Was ist mit "wirklich" gemeint? Perfekt oder nur für einfachen Gebrauch?
> Ich habe ein bisschen mit Thonny geschrieben und meine Raspis laufen
> auch mit Python. Aber mehr wollte ich nie.
In welcher Sprache sind auf raspi eigene Programme empfehlenswert?
Wenn Text wichtig ist, würde ich Python nehmen,
für die IO Leiste eher C bevorzugen.
>> Für den einfachen Gebrauch ist Python schnell erlernbar. In Linux
>> Python aufrufen und obige Zuweisungen und print Zeilen eingeben..
>> Viele Feinheiten kommen nach und nach.
> Ja, deshalb ackern bei mir die Raspis mit Python. Aber auf den Laptops
> läuft nur Pascal (bzw. FreePascal bzw. Lazarus).
Auf meinem PC code Zeilen:
schätzungsweise ca 90% Python, ca 9% C ca 1% JavaScript und bash
Raspi vielleicht 98% Python 2% JavaScript
>> Bei Pascal und Basic besteht die Gefahr, dass sie irgendwann auf neu
>> aktuelle Maschinen nicht mehr verwendet werden können. C und Python
>> dürften da sicherer sein.
>
> Ist Python denn zu sich selbst kompatibel? Python 1, 2 und 3? Also bei
> PHP hatte ich schon Probleme.
Python1 habe ich nicht verwendet.
Bei Python3 gab es bezüglich Python2 spürbare Änderungen.
Bei Python3 gibt es auch Inkompatibiliäten.
So wurde die alte cgi Schnittstelle ab Python 3.11 gestrichen.
Aufgrund der Verbreitung von Python erwarte ich wenig
Inkompatibilitäten. So wie bei C.
> Lazarus ist zu ObjectPascal, Pascal-S und Turbo kompatibel.
ANSI C war auch lange kompatibel.
> Meine Programme seit 1990 kamen fast sofort durch den Compiler.
Meine alten (ANSI) C Programme werden heutzutage mit viel warnings
kommentiert. Und es gibt Probleme mit ISO statt utf Zeichen in strings.
> Das schätzte ich immer sehr.
Wo geht das PUNCH in Fortran ( in COBOL?) denn hin?
> Vor allem, da ich 1990 tatsächlich noch einen Apple ][
> mit UCSD-Pascal hatte.
1990 hatte ish Atari ST, möglicherweise noch Pascal ST.
> Selbst dieser merkwürdige Dialekt machte wenig
> Arbeit auf den PCs.
Beim Atari ST bin von Pascal ST irgendwann auf Borland ANSI C
umgestiegen. das war eine Befreiung von etlichen Probleme.
Pascal ST kannte nur strings von fester Länge.
Da habe ich mit variant Strings mit Längen von 1 bis 255 gebastelt..
>>> Nenn mich ruhig altertümlich.
>> Kennst Du noch Rechenschieber, Logarithmentafel, ALGOL60, Lochkarten..?
>
> Rechenschieber musste ich im Informatikunterricht lernen.
> Logarithmentafel kenne ich nur theoretisch und brauchte es nie.
Ich auf dem Gymnasium beide in Mathematik.
Taschenrechner (HP35) hatte ich erst in späterer Ausbildung.
( Und da auch mal Zugriff auf APL )
> ALGOL60 als Vorgänger zu Pascal war Thema im Studium.
Das war meine erste Programmiersprache
> Lochkarten haben wir im Informatikunterricht gebastelt.
Das war meiner Ausbildung vor dem Beruf,
von wenigen Ausnahme abgesehen,
meine einzige computer (CDC3300) Eingabe
> Aber meine Flamme entzündete sich erst mit Pascal.
Die war bei mir mit Lisp 1.5
Das symbolische Rechnen hat mir gefallen.
Allerdings finde ich die Syntax von Lisp heutzutage grauenhaft
und erwäge, wesentliche Funktionalität mit Python nachzubauen.
( Programme automatisch basteln .. )
> Im Sommer 1984 bin ich nicht verreist,
> sondern habe alle meine 20 BASIC-Programme in Pascal übersetzt.
> Meine Eltern wollten schon den Arzt rufen. :-D
1984 hatte ich Einplatinen computer mit Z80, 6502, 8085 CPU.
und programmierte in Maschinencode.
Und Umzug von gemietete in eigene Wohnung.
Entfernung zu Eltern ca 500 km.
Die hätten vermutlich lieber,
dass ich mich mit Freundin statt computer beschäftigen würde.
Hermann
der heute auf seinem PC mit Debian 10 vergeblich nach parted
und gparted gesucht hat, ( Ersatz im internet gefunden )
um diesen PC mit Debian 12 neu zu installieren.
--
<http://www.hermann-riemann.de>
[toc] | [prev] | [next] | [standalone]
| From | "F. W." <me@home.invalid> |
|---|---|
| Date | 2024-01-25 15:31 +0100 |
| Message-ID | <uotrbm$tjqa$1@solani.org> |
| In reply to | #614457 |
Am 25.01.2024 um 14:42 schrieb Hermann Riemann: > > Einrückung statt Nummern für Zeilen. > Fand ich schon bei COBOL grauslig. >>> Es macht im Vergleich zu Sprachen mit compiler erheblich weniger >>> Verwaltungsaufwand. >> Dafür schreibst Du immer alternativlos Open-Source. > Ich programmiere zu Hause nur für eigenen Gebrauch. Beruflich habe > ich im Team an gemeinsamen Projekten gearbeitet, die auch lizensiert > wurden und immer noch verwendet werden. Und Ihr liefert den Quellcode an den Kunden aus? Unsere fühlten sich zur Änderung berufen und stellten uns den Schaden in Rechnung. Da haben wir das gelassen. Ja, es gab auch Compiler für Zeilen-BASIC. Aber wir sind schnell auf Turbo-Pascal umgestiegen. >> Möglich. Aber Pascal und viel mehr COBOL sollten eben von sich aus >> klar verständlich sein. Wirth soll anfangs mit Jürg Gutknecht sogar >> darüber diskutiert haben, ob man überhaupt einen (* Kommentar *) >> zulässt. > Die Verständlichkeit hängt primär von Programmierstil und Namenswahl > ab. Sind beide gleich, bringt Python noch einen Vorteil durch weniger > Text und Zeichen, die zur Verwaltung gehören. Python hat da dankenswerterweise einiges von Modula-2/Oberon übernommen. Aber lesbar... >> Ich habe ein bisschen mit Thonny geschrieben und meine Raspis >> laufen auch mit Python. Aber mehr wollte ich nie. > In welcher Sprache sind auf raspi eigene Programme empfehlenswert? > Wenn Text wichtig ist, würde ich Python nehmen, für die IO Leiste > eher C bevorzugen. Ja, Python ist viel besser unterstützt als andere Programme. Gerade mit Thonny kann man gleich loslegen. Da ich aber beruflich nicht mehr programmiere, bin ich auf MMBASIC umgestiegen. Für meine Bedürfnisse reicht das. > Wo geht das PUNCH in Fortran ( in COBOL?) denn hin? Verwende ich nicht. FW
[toc] | [prev] | [next] | [standalone]
| From | Hermann Riemann <nospam.ng@hermann-riemann.de> |
|---|---|
| Date | 2024-01-25 17:38 +0100 |
| Message-ID | <l1fh3sF4llpU1@mid.individual.net> |
| In reply to | #614459 |
Am 25.01.24 um 15:31 schrieb F. W.:
> Am 25.01.2024 um 14:42 schrieb Hermann Riemann:
>
>>
>> Einrückung statt Nummern für Zeilen.
> Fand ich schon bei COBOL grauslig.
Ich finde, die Einrückung erhöht Lesbarkeit
mehr als begin end { }
>>>> Es macht im Vergleich zu Sprachen mit compiler erheblich weniger
>>>> Verwaltungsaufwand.
>
>>> Dafür schreibst Du immer alternativlos Open-Source.
>
>> Ich programmiere zu Hause nur für eigenen Gebrauch. Beruflich habe ich
>> im Team an gemeinsamen Projekten gearbeitet, die auch lizensiert
>> wurden und immer noch verwendet werden.
>
> Und Ihr liefert den Quellcode an den Kunden aus?
Wurde nicht gemacht.
>> Wo geht das PUNCH in Fortran ( in COBOL?) denn hin?
>
> Verwende ich nicht.
Ich habe es mal verwendet um die Informationsdichte
von Lochkarten zu erhöhen. Der computer hat aber
die Annahme derartiger Lochkarten piepend verweigert.
[toc] | [prev] | [next] | [standalone]
| From | Diedrich Ehlerding <diedrich.ehlerding@t-online.de> |
|---|---|
| Date | 2024-01-25 18:52 +0100 |
| Message-ID | <1oja8kx18f.ln2@diedrich.ddnssec.de> |
| In reply to | #614461 |
Hermann Riemann meinte:
> Ich finde, die Einrückung erhöht Lesbarkeit
> mehr als begin end { }
Niemand hindert dich, in C oder Pascal einzurücken. Außerdem gibt es
prettyprinter, die das ggf nachträglich erledigen.
--
gpg-Key (DSA 1024) D36AD663E6DB91A4
fingerprint = 2983 4D54 E00B 8483 B5B8 C7D1 D36A D663 E6DB 91A4
HTML-Mail wird ungeleſen entſorgt.
[toc] | [prev] | [next] | [standalone]
| From | Hermann Riemann <nospam.ng@hermann-riemann.de> |
|---|---|
| Date | 2024-01-25 19:10 +0100 |
| Message-ID | <l1fmg0F5o3uU1@mid.individual.net> |
| In reply to | #614467 |
Am 25.01.24 um 18:52 schrieb Diedrich Ehlerding:
> Hermann Riemann meinte:
>
>> Ich finde, die Einrückung erhöht Lesbarkeit
>> mehr als begin end { }
>
> Niemand hindert dich, in C oder Pascal einzurücken.
Mache ich in C ja auch. ( Pascal verwende ich nicht mehr)
Nur sieht }}} etwas häslich aus.
> Außerdem gibt es prettyprinter, die das ggf nachträglich erledigen.
pretty ist Geschmackssache.
Insbesondere wenn sie Tabellen artige Spaltenanordnungen
in einer Zeile verschieben
Hermann
der das TAB-Zeichen nur noch bei Make Dateien verwendet.
--
<http://www.hermann-riemann.de>
[toc] | [prev] | [next] | [standalone]
| From | Diedrich Ehlerding <diedrich.ehlerding@t-online.de> |
|---|---|
| Date | 2024-01-25 19:28 +0100 |
| Message-ID | <erla8kxpjj.ln2@diedrich.ddnssec.de> |
| In reply to | #614471 |
Hermann Riemann meinte:
>> Niemand hindert dich, in C oder Pascal einzurücken.
>
> Mache ich in C ja auch. ( Pascal verwende ich nicht mehr)
> Nur sieht }}} etwas häslich aus.
So schreibt man das ja auch nicht, sondern schreibt die { in eine neue
Zeile, rückt dann den Teil in der Klamme ein, und schreibt dann die }
wieder in einer neuen Zeile unter die passende {. Und sieht im vim mit
entsprechendem Syntaxmodul sofort, ob man da was falsch hat.
>> Außerdem gibt es prettyprinter, die das ggf nachträglich erledigen.
>
> pretty ist Geschmackssache.
Das, was da rauskommt, ist um Größenordnungen prettier als
unsystematisch eingerückter Quellcode.
Vor ca 45+ Jahren habe ich mal quick+dirty-Prettyprinter für Pascal zbd
Algol60 als Suchprogramme für deinen und meinen damaligen
Lieblingseditor $EDOR geschrieben; das war gar nicht so schwer, und was
da rauskam, war recht gut. OK, die waren nicht wasserdicht, hatten zB
Probleme, wenn Schlüsselworte in Kommentaren vorkamen, aber es sollte
halt auch nur quick+dirty sein (im Prinzip wollte ich damals die Syntax
dieser EDOR-Suchprogramme lernen, keinen produktiv nutzbaren
prettyprinter schreiben, aber mindestens ein Kollege hat das tatsächlich
mal benutzt). ).
--
gpg-Key (DSA 1024) D36AD663E6DB91A4
fingerprint = 2983 4D54 E00B 8483 B5B8 C7D1 D36A D663 E6DB 91A4
HTML-Mail wird ungeleſen entſorgt.
[toc] | [prev] | [next] | [standalone]
Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
Back to top | Article view | ger.ct
csiph-web