what does := means simply?

[Ned Batchelder]

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.