what does := means simply?
bartc
bc at freeuk.com
Fri May 18 07:09:02 EDT 2018
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.
--
bartc
More information about the Python-list
mailing list