I think that goes against the python dogma of "Explicit is better than implicit." In #1 and #2 there is no question about where 'x' comes from, while in #3 it could be a class variable or a global variable or from just about anywhere.

Agree. Even better, though:

    # 4
    def length():
    	return math.sqrt(.x**2 + .y**2 + .z**2)

Ambiguity and "pseudo-keyword" are both gone!

[EDITED code for better readability]

If you mind with self being too bloated, you can already change it to what you like. The `self` is merely idiomatic.

  def length(s):
    	return math.sqrt(s.x**2 + s.y**2 + s.z**2)

The beauty with self in Python is that self is not at all magic : it merely indicates that the object instance you're using will be passed as first argument of the class method.

Also you can get a custom font with typographic ligatures (e.g. for self, lambda, and so on) in order to make it more visually appealing. For instance (self > 圖) :

  def length(圖):
    	return math.sqrt(圖.x**2 + 圖.y**2 + 圖.z**2)

Huh, I experience python as quite the opposite of "Explicit is better than implicit":

- No static types

- A variable might belong to the scope of a method, object or class, depending on where it was first set and changed afterwards

- Implicit execution of code on import of a module (__init__.py, including parent packages)

- Any object is truthy or falsey, i.e. conditional statements don't require an explicit boolean

You can get the "Python dogma" with `import this`. "Explicit is better than implicit" is part of it, but so is "practicality beats purity" (and "There should be one-- and preferably only one --obvious way to do it, although that way may not be obvious at first unless you're Dutch").

I suppose "dogma" was the incorrect word in that case.

For JS, you can do

    function length() {
      const { x, y, z } = this
      return math.sqrt(x * x + y * y + z * z)
    }

I think it's pretty short, readable and explicit.

EDIT: formatting

And make every one-liner a two-liner?

In rust you can use pattern matching in arguments:

    struct Foo { x: f64, y: f64, z: f64 }
    fn length(Foo {x, y, z}: Foo) -> f64 {
        (x*x + y*y + z*z).sqrt()
    }

...Doesn't work with `self` because that would be implicit again, though. Anyway, I think that it is a minor inconvenience that isn't important for oneliners and extremely helpful when reading larger functions.

> Doesn't work with `self` because that would be implicit again, though.

AFAIK it doesn't work on self because the [&[mut ]]self parameter is more or less a keyword determining ownership interaction with the call subject.

The UFCS RFC would have made it sugar for `self: [&[mut ]]Self` (IIRC) but I believe that floundered.

It actually uses less characters, since you've eliminated all the repeated uses of 'this.'. As a general rule I'm in favor of a turning a one liner into a two liner if it improves readability, especially when it reduces actual typing.

I agree that it's mostly noise.

Python's self in the arglist is a C struct pointer sneaking in from the 80's, which is the time when Python has been designed. It could be excused but there should be a deprecation PEP by now. Make it a keyword and let us type it only when we need it.

That might seem nice for your limited example, but it breaks down when you realize that in example #3 there would be no easy way to differentiate between scopes.

  y = 100
  x = 15
  
  class MyClass(object):
    x = 50
    def __init__(self, x):
      self.x = x

    def length():
      return x * y

What does that mean? Does MyClass(10).length() raise an AttributeError because MyClass doesn't have an attribute named y? Does it automatically recognize there's a y in the outer scope and use that, or does it call __getattr__ first (i.e. method that gets called when a missing attribute is accessed)? Furthermore, how do I specify that I want to access the class attribute x, or that I want to access the nonlocal x?

In my opinion, there are far bigger problems with pythons scoping. Why is for/if/etc not it's own scope? You can define a temporary variable in there and mistakenly use it somewhere down the line. In a "for i in ..", the i should be cleared after the loop but it isn't. Why can't you create a new scope within a function? This allows you to bundle related stuff together and be sure the scope is cleared afterwards, so as to not mistakenly reuse variables. The thing that you're promoting as an advantage of explicit self is already broken by having a single scope for the whole function.

Blocks like this are an imensely useful way to keep scopes clean:

   int someMethod(){
   	...
   
   	{ // some small stuff that doesn't warrant a new method but you don't want it to bleed into the remaining part of the function, e.g.:
   		float x = readNextFloat();
   		float y = readNextFloat();
   		float z = readNextFloat();
   		float length = sqrt(x*x + y*y + z*z);
   		cout << length;
   	}
   	
   	// do some other things without worrying about potentially initialized variables
   	...
   }

Technically "self" could be anything you want it to be called, it's typically "self" by convention. I think it's fine, but that's just my opinion.

Yes, I usually call it "s" to reduce it's impact but I'm still not happy with it.

Don't call it "s", because then you break consistency basically with the whole Python ecosystem. That's not very nice for fellow programmers who already used to read and understand "self".

I look at #3 and ask "What are x, y, and z? How did they get into this scope?"