3 ms·

Differentiating properties and methods from internal methods is as simple as using another char, like dots and colons. So box.length would not be the same as bo

Differentiating properties and methods from internal methods is as simple as using another char, like dots and colons. So box.length would not be the same as box:length, that way you could assign all names you want without fear of collision. Poor choices in language design will always haunt you til the end of times. That being said, python is my favorite language right now and the only complain I have is about underscores which I try to avoid. Now, GO being a new language, I can't really understand why it does not implement methods for primitive types like "hello".ToUpper(), instead we have to import "strings" and call strings.ToUpper("hello"). Easier for the compiler but harder for the programmer has never been my mantra.

lucian1900 15y ago
I'm not sure about different namespaces for special methods. Python's object system is so self-referential and so transparent that it'd be surprising. Go devs are of the opinion that what behaves like a function should be a function, with no exception. It's also the reason they don't do operator overloading, which I think is just dumb.
dalke 15y ago
Would you mean this to be a namespace which only the Python implementation could access? For example, if the protocol "it:next" is added (which is equivalent to next(it)) then is there any way to support that syntax in an older version? With next() as a builtin it's easy; try: next except NameError, and in case of exception, implement the function yourself. But if I can't implement it myself then there's no good migration path. With your particular choice of ":", then what would "d={a:length()}" be? Currently it's a 1-element set. What would "words[middle:length()]" do?
- Kilimanjaro 15y ago
  "is there any way to support that syntax in an older version" Nop, that is exactly what I meant with decisions haunting you forever. You better start a new language than radically change the current implementation. With regard to my particular choice of ':' there are three solutions: 1. pick any of the 100k unicode chars for internal methods but imperative is to differentiate them to freely use attributes and methods as pleased. 2. force the compiler and the coder to disambiguate the possible same use as internal method: first assign then use n=a:length(), d={n} 3. design the language to use .. as slicer and {a=b} as dictionary assignment. Again, we are talking about design decisions for a new language, not to change the core of an existing language which is not an easy task. That is exactly why language design is not an exact science an very few make it to stardom.
  - dalke 15y ago
    My point is that it isn't "as simple as using another char." #1 doesn't work if you want things visible on most keyboards in the world. #2 is counter to a design principle (which Python uses) that humans are less good at resolving ambiguity than people (see "template <template <int>>" in C++ pre 2011), and #3 as a specific case means problems getting methods of floats, as in "1..hex()". Of course Python has that already with "1 .bit_length()" being different than "1.bit_length()". I agree that seemingly minor decisions can have a big impact in the future of a language. What I disagree with is that this choice of a special syntax for built-in methods is "simple", and I believe that doing it yields a language not meant for stardom.
njharman 15y ago
how is ':' less onerous than underscores i.e. '.__'? Sounds like you just have irrational hatred of underscore (or possibly love of colon?) btw having two or more access operators '.', ':' and distinguishing between "internal/language" and "user" methods is a poor language design choice over having a standard but unenforced __ means "special" and "internal/language" and "user" all being coequal in semantics, syntax, rights and responsibilities.
- Kilimanjaro 15y ago
  "how is ':' less onerous than underscores i.e. '.__'?" There is no difference at all, just one char vs five if we count ending double-underscores too, and more visual noise. They both accomplish the same. Being both the same, what difference do you think there is between, in one hand .init() and .__init__(), and on the other hand .init() and :init() Just syntactic sugar, I rather pick my colon ;-)

lucian1900 15y ago

I'm not sure about different namespaces for special methods. Python's object system is so self-referential and so transparent that it'd be surprising. Go devs are of the opinion that what behaves like a function should be a function, with no exception. It's also the reason they don't do operator overloading, which I think is just dumb.

dalke 15y ago

Would you mean this to be a namespace which only the Python implementation could access? For example, if the protocol "it:next" is added (which is equivalent to next(it)) then is there any way to support that syntax in an older version? With next() as a builtin it's easy; try: next except NameError, and in case of exception, implement the function yourself. But if I can't implement it myself then there's no good migration path. With your particular choice of ":", then what would "d={a:length()}" be? Currently it's a 1-element set. What would "words[middle:length()]" do?

Kilimanjaro 15y ago
"is there any way to support that syntax in an older version" Nop, that is exactly what I meant with decisions haunting you forever. You better start a new language than radically change the current implementation. With regard to my particular choice of ':' there are three solutions: 1. pick any of the 100k unicode chars for internal methods but imperative is to differentiate them to freely use attributes and methods as pleased. 2. force the compiler and the coder to disambiguate the possible same use as internal method: first assign then use n=a:length(), d={n} 3. design the language to use .. as slicer and {a=b} as dictionary assignment. Again, we are talking about design decisions for a new language, not to change the core of an existing language which is not an easy task. That is exactly why language design is not an exact science an very few make it to stardom.
- dalke 15y ago
  My point is that it isn't "as simple as using another char." #1 doesn't work if you want things visible on most keyboards in the world. #2 is counter to a design principle (which Python uses) that humans are less good at resolving ambiguity than people (see "template <template <int>>" in C++ pre 2011), and #3 as a specific case means problems getting methods of floats, as in "1..hex()". Of course Python has that already with "1 .bit_length()" being different than "1.bit_length()". I agree that seemingly minor decisions can have a big impact in the future of a language. What I disagree with is that this choice of a special syntax for built-in methods is "simple", and I believe that doing it yields a language not meant for stardom.

njharman 15y ago

how is ':' less onerous than underscores i.e. '.__'? Sounds like you just have irrational hatred of underscore (or possibly love of colon?) btw having two or more access operators '.', ':' and distinguishing between "internal/language" and "user" methods is a poor language design choice over having a standard but unenforced __ means "special" and "internal/language" and "user" all being coequal in semantics, syntax, rights and responsibilities.

Kilimanjaro 15y ago
"how is ':' less onerous than underscores i.e. '.__'?" There is no difference at all, just one char vs five if we count ending double-underscores too, and more visual noise. They both accomplish the same. Being both the same, what difference do you think there is between, in one hand .init() and .__init__(), and on the other hand .init() and :init() Just syntactic sugar, I rather pick my colon ;-)