On Tue, 15 Aug 2017 02:54 pm, Rustom Mody wrote:
> On Monday, August 14, 2017 at 10:35:22 PM UTC+5:30, Terry Reedy wrote:
[...]
>> Suppose stdin contains "a\nb\nc\nd\ne\nf\ng\n".
>> What is the meaning of
>> [input(f"response{i}") for i in range(6)]?
>> In Python, the predictable result is
>> ['a', 'b', 'c', 'd', 'e', 'f']
>> It would not be with some of Rustom Mody's 'equivalents'.
Indeed. Terry has hit the nail on the head here. Python's documented semantics
is predictable and deterministic, and the documented semantics of
comprehensions are explicitly based on sequential for-loops.
To continue to insist, in contradiction to the documentation, that list comps
might legitimately operate in arbitrary order is simply irrational. If they
behaved as Rustom is insisting they might, it would be a bug in the
implementation.
>> Or let L = <list above>.
>> This implementation of list reversal: [L.pop() for i in range(len(L))]
>
> In languages, especially those with a clearly separated lang-spec from
> specific implementation-spec (eg C99), there is a sharp distinction made
> between - undefined behaviour
> - unspecified behaviour
> - erroneous behaviour
>
>
> Roughly:
> - Erroneous means compiler/runtime should flag an error
> - Undefined means implementation can format your hard disk and clear your bank
> account
In *some* languages, not all, undefined means the implementation can format your
hard disk. Those languages include C (and perhaps C++). I don't know of any
other languages which are so hostile to the developer (and their end users) as
to specify such abominable behaviour and claim it is a feature. (There may be
others, I just don't know them.)
In general, undefined and unspecified are synonymous.
>
https://stackoverflow.com/questions/18420753/unspecified-undefined-and-implementation-defined-behavior-wiki-for-c
> - Unspecified means not error but not spelled out
>
> My point of suggesting those alternative implementations is precisely
> to make your examples above fall squarely into unspecified category
Terry's examples don't demonstrate unspecified behaviour. The order of execution
is completely specified. See the links to the docs I have already posted.
> Note that this would square with the informal practice seen in places like
> this ML/NG where a noob asks a question using a comprehension such as the
> ones you've used and someone more experienced pipes up "Dont do that"
Don't do that *in production code.*
[print(x, y) for x in values for y in others]
is a good way of learning how to read list comprehensions.
You're making the classic logical error of affirming the consequent:
https://en.wikipedia.org/wiki/Affirming_the_consequent
we should avoid code with unspecified behaviour
we should avoid this code, therefore it must have unspecified behaviour
Just because code showing unspecified behaviour should be avoided, doesn't mean
that all code that should be avoided has unspecified behaviour.
There are plenty of reasons for avoiding certain misuses of comprehensions that
have nothing to do with unspecified behaviour.
--
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.
--
https://mail.python.org/mailman/listinfo/python-list
