what does := means simply?

[Steven D'Aprano]

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 you know that.

If I see:

    result = math.sin(x)

and I want to port it, what should I do?

1. Dive into the source code of math.so or math.dll, and from there dig 
deeper into the platform maths libraries and the intricacies of the sin 
function;

2. Read the docs, discover that math.sin returns the trigonometric sine 
function, and use my target languages own sine implementation? (If and 
only if there is a difference in behaviour between sine implementations 
should I *consider* diving into the platform sine.)


I don't believe you actually choose 1 when you are porting.

So why should sys.version be treated differently from math.sin(), for 
example? What matters is the *interface*, not the implementation, and we 
best get the interface from the docs, not from diving into the source.

Diving into the source is the last resort.


> 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.

I disagree.

Come on Bart, be serious here. You surely don't mean to say that porting 
the Python script

    print("Hello World!")

to Ruby:

    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.


>> 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.

But that's always the case.


[...]
>> 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.

No.


> 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.

If a Python program does a task T using some implementation P which Lua 
cannot easily use, and a Lua program does exactly the same task T but 
using a different implementation L, then the way to port the Python 
program to Lua is to adapt the algorithm so that it uses L.

Any successful port is going to require changes to the implementation, 
because the two languages are going to have differences in semantics. The 
Ruby print is not absolutely identical to the Python print, so there may 
be times you need to work around those differences. Lua's tables are not 
identical to either Python lists or dicts (but a little like both).

And port is going to require you to adapt the code. Sometimes a little, 
sometimes a lot.

But you know that.



-- 
Steve