what does := means simply?

[bartc]

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