3 ms·

>> Most programming languages pass function parameters by value. If the function alters the value, the results are not passed back to the calling code. But as I

>> Most programming languages pass function parameters by value. If the function alters the value, the results are not passed back to the calling code. But as I've already explained, Python goes out of its way to be different. Python defaults to doing functions with pass-by-object-reference parameters. Python passes method arguments by value, pushing them on the stack like every other language I've used. Because everything is an object in python the passed _scalar_ values are references (addresses), the objects the references refer to are on the heap. I sometimes think literally everyone should have to use C for six months, most of this stuff would stop being debated endlessly.

brudgers 8y ago
Everything in Python may be an object in some technical sense. Semantically, everything isn't. The utility of "everything is an object" is as a promise that lets programmers write: 3.fizzbuzz # returns "fizz" 5.fizzbuzz # returns "buzz" 7.fizzbuzz # returns 7 15.fizzbuzz # returns "fizzbuzz" as is the case with Ruby or Smalltalk. I think that the author's complaints center around Python behaving like C sometimes and Smalltalk other times. In particular, some operations happen according to the semantics of types and others happen according to the semantics of objects. At the lowest levels of Python, object oriented programming isn't available to do things like adding methods to Integer.
- bakery2k 8y ago
  You can't add methods to integers in Python, but they're still objects in the sense that you can call methods on them: >>> i = 123 >>> i.bit_length() 7
  - brudgers 8y ago
    Some methods but not others. Specifically, I can call built-in methods, but not methods I define. For example: >>> def f(self): ... return self ... >>> (3).f Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: 'int' object has no attribute 'f'
    - bakery2k 8y ago
      Your `f` is not a method, but a top-level function whose first parameter happens to be named `self`. You can't call `f` as a method of any object, because in Python (unlike Ruby) the top-level namespace is unrelated to the namespaces of any classes.
      - brudgers 8y ago
        I don't disagree. I just think it's much worse than that. There is no scope in Python where I can define 'f' to allow '(3).f'. I cannot restrict a function to the domain of Integers using encapsulation. I am forced to put it in some other arbitrary namespace.
- civility 8y ago
  Are you after monkey patching, where you can add new methods outside of the class definition? That's not really a standard feature of all object orient languages - Java doesn't do that, for instance. Python integers are definitely objects: (3).real # returns 3 (3).imag # returns 0 Python's lexer/parser made different choices than Ruby's, so the parens are needed here.
  - brudgers 8y ago
    In no particular order + Java doesn't promise "everything is an object." It has Base Types. + Python doesn't make a semantic promise that "everything is an object." Code for (3).fizzbuzz => "fizz" probably needs written in C because built-in types are closed and object literals use the built-in types. "3" cannot be forced to use a subclass of Integer. At the bottom, '3' is defined in terms of Types (i.e. "Built-in Types") not as an Object. + Ruby's semantic promise that "everything is an object" means: class Fixnum def fizzbuzz() if self % 15 == 0 "fizzbuzz" end if self % 3 == 0 "fizz" end if self % 5 == 0 "buzz" end return self end end And "3" behaves just like any other object. The "everything is an object" promise means that behavior as an object is a cross-cutting concern (or an aspect).
    - civility 8y ago
      I'm not sure if you think you're correcting me, but it sounds like you think you've got it all figured out. Java calls them "primitive types", btw.
      - brudgers 8y ago
        I was clarifying the difference between "everything is an object" as technically true and "everything is an object" as a commitment to semantic consistency. Probably because I'm still figuring out these ideas.
    - ubernostrum 8y ago
      probably needs written in C because built-in types are closed "Everything is an object" does not necessarily imply "all objects are always infinitely monkeypatchable at all times". It also doesn't necessarily imply "you can change how the parser interprets literals". You're also going to be really mad when you learn about __init_subclass__ and the fact that Python lets you write a class that can't be subclassed!

brudgers 8y ago

Everything in Python may be an object in some technical sense. Semantically, everything isn't. The utility of "everything is an object" is as a promise that lets programmers write: 3.fizzbuzz # returns "fizz" 5.fizzbuzz # returns "buzz" 7.fizzbuzz # returns 7 15.fizzbuzz # returns "fizzbuzz" as is the case with Ruby or Smalltalk. I think that the author's complaints center around Python behaving like C sometimes and Smalltalk other times. In particular, some operations happen according to the semantics of types and others happen according to the semantics of objects. At the lowest levels of Python, object oriented programming isn't available to do things like adding methods to Integer.

bakery2k 8y ago
You can't add methods to integers in Python, but they're still objects in the sense that you can call methods on them: >>> i = 123 >>> i.bit_length() 7
- brudgers 8y ago
  Some methods but not others. Specifically, I can call built-in methods, but not methods I define. For example: >>> def f(self): ... return self ... >>> (3).f Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: 'int' object has no attribute 'f'
  - bakery2k 8y ago
    Your `f` is not a method, but a top-level function whose first parameter happens to be named `self`. You can't call `f` as a method of any object, because in Python (unlike Ruby) the top-level namespace is unrelated to the namespaces of any classes.
    - brudgers 8y ago
      I don't disagree. I just think it's much worse than that. There is no scope in Python where I can define 'f' to allow '(3).f'. I cannot restrict a function to the domain of Integers using encapsulation. I am forced to put it in some other arbitrary namespace.
civility 8y ago
Are you after monkey patching, where you can add new methods outside of the class definition? That's not really a standard feature of all object orient languages - Java doesn't do that, for instance. Python integers are definitely objects: (3).real # returns 3 (3).imag # returns 0 Python's lexer/parser made different choices than Ruby's, so the parens are needed here.
- brudgers 8y ago
  In no particular order + Java doesn't promise "everything is an object." It has Base Types. + Python doesn't make a semantic promise that "everything is an object." Code for (3).fizzbuzz => "fizz" probably needs written in C because built-in types are closed and object literals use the built-in types. "3" cannot be forced to use a subclass of Integer. At the bottom, '3' is defined in terms of Types (i.e. "Built-in Types") not as an Object. + Ruby's semantic promise that "everything is an object" means: class Fixnum def fizzbuzz() if self % 15 == 0 "fizzbuzz" end if self % 3 == 0 "fizz" end if self % 5 == 0 "buzz" end return self end end And "3" behaves just like any other object. The "everything is an object" promise means that behavior as an object is a cross-cutting concern (or an aspect).
  - civility 8y ago
    I'm not sure if you think you're correcting me, but it sounds like you think you've got it all figured out. Java calls them "primitive types", btw.
    - brudgers 8y ago
      I was clarifying the difference between "everything is an object" as technically true and "everything is an object" as a commitment to semantic consistency. Probably because I'm still figuring out these ideas.
  - ubernostrum 8y ago
    probably needs written in C because built-in types are closed "Everything is an object" does not necessarily imply "all objects are always infinitely monkeypatchable at all times". It also doesn't necessarily imply "you can change how the parser interprets literals". You're also going to be really mad when you learn about __init_subclass__ and the fact that Python lets you write a class that can't be subclassed!