On 8/26/2015 10:43 PM, Steven D'Aprano wrote:
On Tue, Aug 25, 2015 at 07:48:39PM +0200, Sven R. Kunze wrote:

I think the main issue here is the gab between intuition and what the
compiler actually does. The following line:

class MyClass: # first appearance of MyClass

basically creates MyClass in the mind of the developer reading this
piece of code. Thus, he expects to be able to use it after this line.
Intuition according to whom? Some people expect that. Others do not.

People hold all sorts of miscomprehensions and misunderstandings about
the languages they use, and Python is no different.

However, Python first assigns the class to the name MyClass at the end
of the class definition. Thus, it is usable only after that.

People get around this (especially since one doesn't need it thus
often), but it still feels... different.
To me, it feels intuitive and natural. Of course you can't use the class
until after you have finished creating it. To me, alternatives like
Javascript's function hoisting feel weird. This looks like time travel:

// print is provided by the Rhino JS interpreter
var x = f();
// multiple pages later
function f() {return "Hello World!";};

How can you call a function that doesn't exist yet? There are even
stranger examples, but for the sake of brevity let's just say that what
seems "intuitive" to one person may be "weird" to another.

With one or two minor exceptions, the Python interactive interpreter
behaves identically to the non-interactive interpreter. If you have
valid Python code, you can run it interactively. The same can't be said
for Javascript. You can't run the above example interactively without
*actual* time travel, if you try, it fails:

[steve at ando ~]$ rhino
Rhino 1.7 release 0.7.r2.3.el5_6 2011 05 04
js> var x = f();
js: "<stdin>", line 2: uncaught JavaScript runtime exception:
ReferenceError: "f" is not defined.
at <stdin>:2

A nice, clean, easy to understand execution model is easy to reason
about. Predictability is much more important than convenience: I much
prefer code which does what I expect over code that saves me a few
characters, or lines, of typing, but surprises me by acting in a way I
didn't expect. The fewer special cases I have to learn, the more
predictable the language and the less often I am surprised.

Python treats functions and classes as ordinary values bound to ordinary
names in the ordinary way: the binding doesn't occur until the statement
is executed. I like it that way.

So do I. The same is true of import statements -- the binding of the
name to the module does not happen until the module is built. It
happens that the import machinery has a cache where is sticks an
initially empty module in case of circular imports. But that is
normally invisible to the code with the import statement.

Terry Jan Reedy

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 24 of 28 | next ›
Discussion Overview
grouppython-ideas @
postedAug 24, '15 at 4:19a
activeAug 28, '15 at 7:21p



site design / logo © 2017 Grokbase