what does := means simply?
Ned Batchelder
ned at nedbatchelder.com
Fri May 18 07:45:38 EDT 2018
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.
More information about the Python-list
mailing list