On 18/05/2018 13:29, Steven D'Aprano wrote:
On Fri, 18 May 2018 12:09:02 +0100, bartc wrote:
On 18/05/2018 02:45, Steven D'Aprano wrote:
On Fri, 18 May 2018 02:17:39 +0100, bartc wrote:
Normally you'd use the source code as a start point. In the case of
Python, that means Python source code. But you will quickly run into
problems because you will often see 'import lib' and be unable to find
lib.py anywhere.
Seriously? There's a finite number of file extensions to look for:
.py .pyc .pyo .pyw .dll .so
pretty much is the lot, except on some obscure platforms which few
people use.
Which one corresponds to 'import sys'?
The functions in sys are built-in to the CPython interpreter. For other
interpreters, they could correspond to some file, or not, as the
implementer desires.
So just like built-in functions, your first stop when porting is to READ
THE DOCUMENTATION and learn what the semantics of the functions you care
about, not the source code.
But there is a huge amount of such functionality.
There are other ways of doing it which can make more use of the actual
language (ie. Python) and make use of generally available libraries (eg.
msvcrt.dll/libc.so.6), with fewer mysterious goings-on in the middle.
If I see:
result = math.sin(x)
and I want to port it, what should I do?
print("Hello World!")
is "writing from scratch, not porting" unless the Ruby print uses
precisely the same implementation as the Python print. All that matters
is that for *this* specific use, the two print commands behave the same.
And you've chosen two of the most common language features for your
examples, which would probably be available on a 1970s BASIC (I know SQR
was, can't remember about SIN).
Those are not the kinds of problem I mean.
Since every language has features that some other languages don't have,
is it your position that it is impossible to port code from any
language to any other?
I'm saying some languages make it more difficult, and Python is one of
them
Only if you are trying to port *down* the Blub hierarchy, to a less
powerful language.
You might be trying to go from one level of Blub to the same level of
Blub, but the two Blubs are completely incompatible.
I'm just saying that in my experience, given the choice of porting the
same program from other Python or, say, Lua, I would choose Lua.
If they are *the same program* then surely they will be identical (modulo
syntax and naming of builtins) and there should be no difference in
difficulty in porting.
If they are *semantically the same* (they do the same thing) but have
different implementations, then you've just blown a hole in your own
argument.
Have a look at some of the implementations here (to test some Mandelbrot
benchmark):
https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/mandelbrot.html
The three Python examples all use 'import sys' and 'import
multiprocessing', none of which I can find any trace of as any sort of
files let alone .py. One of them also uses 'import array', which I can't
find either.
Now look at the Lua and Lua#2 examples. They don't appear to use
anything that hairy, and could be good candidates for porting. As would
be Free Pascal #3 (the other Pascals use threads).
(Although when I tried to port the Lua just now, I ran into trouble
because I didn't know Lua well enough (it's also poorly written IMO, and
I ran out of time). That's fair enough; you need to be familiar with the
language you're porting from.
But I could be very familiar with Python and still wouldn't be able to
directly translate code which depended heavily on library functions.
Knowing the specification of those is not going to help if I don't
already have something that does exactly the same job.)
Looking also at the amount of code, the Pythons don't appear to be that
much shorter or simpler than many of the others.
--
bartc
--
https://mail.python.org/mailman/listinfo/python-list
