On 5/18/18 7:09 AM, 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'?
If the source to such libraries is not available then it is necessary
to emulate that functionality. You are writing from scratch, not
porting, according to specifications. And those specifications may be
inexplicably tied to the inner workings of the language.
That is a little bit harder, yes? Especially as Python is a scripting
language and might rely more than most on this quite extensive
built-in functionality, even on fairly short programs.
(When I once thought about implementing an interpreter for Python
byte-code, I found all this out very quickly. Such an interpreter
could work perfectly but it would not get past 'import sys'.)
To successful port anything but the most trivial code, you actually have
to understand *both* languages -- including the syntax, semantics,
built-
in language features, AND libraries.
Don't forget configuration and build systems. The code you want to
port may not even exist, but is synthesised as part of the build
process, and be specific to a particular build.
I'm talking about the seemingly rare case these days where you DO have
the source code!
That's one problem. Others might involve how to deal with something
like
__globals__ which doesn't have an equivalent in the target language.
And
we haven't started on features that are specific to Python.
How about features which are specific to C
I'm quite familiar with C which has its own set of problems. But
taking one aspect, if a C program relies on its standard library, then
it is very often possible to directly call that standard library from
another language, so you don't need to reimplement it, nor port it.
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, especially written 'Pythonically', which seems to be code for
'this only makes sense in Python', so that you can't understand it
even if you have no intention of porting it.
If you want to *really* see code that is hard to port, you should try
porting an Inform 7 program to another language. Any other language.
You seem to be saying that because it is rarely completely impossible
to port software, that we disregard any difficulties and consider all
such porting as equally trivial.
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.
Same with choosing between 'full-on' C++ and, say, Pascal.
Both C++ and Python can be used to write software in a simple style
(as I would use); typically they are not used that way. Given the rich
set of esoteric features of both, programmers do like to pull out all
the stops.
Your logic here seems to be to use the least-common denominator among
some guessed-at set of languages, so that if you ever have to
re-implement a program, you can transliterate it into another language.
I would much rather choose a tool and use it well (that is, to its
fullest power) than to hobble myself on the off-chance I have to switch
languages in the future.
I guess I don't understand the type of work you've been doing: I have
only very very rarely had to reimplement the same program in another
language. I can't imagine choosing tooling or style based on that concern.
We have had this discussion at work: do we use Python in a "simple" way
so that new developers coming from Java (or C, etc) can understand it?
Or do we assume that people working in a large Python codebase
understand Python? I choose the latter.
--Ned.
--
https://mail.python.org/mailman/listinfo/python-list
