[Gorf]

Originally Posted by meynaf

Your replies were just choosing some lib that remotely looks as if it could do the work...
So i had to be a little more specific.
If we decide to really start the code contest, the rules should be as clear as possible, but why should they be fully specified now as it's likely that nothing will be done ?

your questions or tasks tend to be non fitting for a scripting language.
It makes little to no sense to use Python directly for such things, or only to write appropriate bindings or modules as part of a system integration.

This thread is "python on amiga", not "python at work".

That is true. My argument is still valid here, since code-reuse and manageability by others are platform independent virtues.

No, because it is the thread's topic.

Python coding has to do with Amiga coding, since you can code in Python on a Amiga...

I wrote "iff image", which was assumed to mean ilbm.

I'd really like to see actual code doing that.

But the situation isn't different with asm (on which it's very easy for me to load and show an iff file due to my existing loading routine), maybe 'xcept on one point : Amiga asm isn't a moving target. It will hardly ever change.
So maybe writing a routine for some task may take longer (NOT for that one, though).
But it will also last longer. A routine for life, instead of a routine that will have compatibility problems when next major version of the language comes out.
What happened to python 2.x programs already when 3.x came out ?

I made the point myself earlier and was admitting that keeping up with the development of such languages is problematic.
Since Python introduces some incompatibilities as it moved from 2.x to 3.x this is an even bigger problem, so some programs need to be adjusted or need a 2.x interpreter to run. It took some years, but 3.x is now widely accepted und the vast majority of applications use it.
That is the reason, why a newer version for the Amiga would be nice.

Your 68k assembler will also not work on a newer machines, or you have to provide an emulator to do so.

So now i must be doing YOUR work ? Remember, it's YOU who said this lib would do the job !
For me it's a lot easier to use some asm replay routine...

To which a Python module could point.
Handling such low-level stuff is surely not the stronghold of a scripting language, and you would resort to C or assembler to provide libraries or modules doing this.

It's indeed closer. And now, by having seen it, it looks simpler to actually do that in asm.

but that asm code will not run on anything else, the Python code will.

I'm not aiming at something specific.

ok...

The target wasn't supposed to be clearly defined to start with...
It was just raw idea, and then instead of simply choosing one you throw library names.

because that is exactly what you would do in a scripting language like Python: use modules and libraries, that provide the functionality you need.

And again, it wasn't supposed to be fully defined either. I just had to be more specific to prevent you from just throwing in some existing function.

why?

Anyway, this was just what my actual asm routine provides...

fine. again something you can reuse in a higher level scripting language through a module or library.

It was about saying that while both tools are inappropriate for the task, one is less inappropriate than the other.

was it?

And now criticizing is forbidden so i should just stop ?

you agreeing with Bruce that Cython is "shit piled on shit" does not qualify as constructive criticism.

Since when being better than the worse means being good ?

you stated that 99% of all languages may be "shit".
You also admitted to have failed, to come up with something better by yourself.
No shame here: it would have been great, if you had and maybe I would love to use it, if you did...

But since we can not apply moral criteria to programming languages, it is not possible to judge them to be absolutely good or bad in that sense. "Good" is here a relative statement and applies to languages that are better than others.

Every language has its warts.
But replacing arexx by python or lua isn't very clever for the simple reason they don't have built-in port to send commands to other programs.

Why replacing?
No one suggested that.

Accommodating and juxtaposing would be the way to go.

The OS4 way of adjusting Python to make use of Arexx-ports is a reasonable way - MorphOS did the same for Lua

"Lupa" gives you a bridge between Lua and Python.

Arexx also does not have big runtime.
Anyway, the point was - once again - it is here all about python on amiga, not python on windows or at work.

And (some) Amiga users would benefit from a newer version ...