what does := means simply?

[bartc]

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