[Baypiggies] Frequently Argued Objections
Shannon -jj Behrens
jjinux at gmail.com
Mon Jun 23 11:48:58 CEST 2008
Let's make it really fun:
from thirdparty import *
def bar(): # Assuming we have implicit self.
Now, did foo come from:
* The parent class B?
* Something in thirdparty?
* Something in thirdparty that someone else shoved in there dynamically?
* Something in builtins that someone else shoved in there dynamically?
* Some global in the current module that's a few hundred lines down?
* Some global in the current module that someone else shoved in from
a third-party module? ;)
Using self cuts down on the possibilities which:
a) Saves the interpreter from doing a bunch of useless dict lookups.
b) Saves the reader from trying to figure out what's going on.
As a blanket statement, polymorphism can be confusing. When I see
"self", at least it's a good sign that I should start looking at
either the class's documentation or one of its ancestor's
On Sun, Jun 22, 2008 at 12:19 PM, Warren Stringer <warren at muse.com> wrote:
> Hey Andy,
> Point well taken about *clear* versus *concise*, though, ironically, when
> looking up both words, I found the Merriam-Webster definition of 'concise'
> (with one definition) to be more clear than that of 'clear' (with six
> definitions). My interpretation of your statement is that some redundancy is
> useful. Agreed; for example:
> The advantage to Ruby is that it makes it easy for me to create a domain
> specific language. The problem with Ruby is that it makes it easy for
> everyone else to make a domain specific language. So, I am more likely to
> send more time, while reading someone else's Ruby code, in figuring out
> their codec, as it were. With Python, the codec remains static. There is
> usually some symbol redundancy in a static codec. But, that means it will be
> easier for me to read your code and vice versa.
> As for "hand-waving magic happens that is either not extremely
> well-documented or extremely well-understood." Is that a problem with
> implicit self or a badly managed namespace? It is still possible to write
> obscure Python code. I would like to see a Python example, using explicit
> self, compared to a fake-Python version of the same example, using implicit
> self, that demonstrates how the former is clearer than the later. Hopefully,
> both examples will follow a few best practices in managing namespace; less
> convincing would be to use -say- a global function with the same name as a
> class method.
> On Jun 22, 2008, at 10:54 AM, Andrew Toulouse wrote:
> No true Scotsman. Even circuit diagrams aren't completely explicit, since
> they can be fabricated in any number of arrangements that affect signal
> integrity. That's not the point. I like 'explicit is good' because I
> absolutely *hate* it when hand-waving magic happens that is either not
> extremely well-documented or extremely well-understood.
> I've always hated when languages force me to use an implicit 'self' or
> 'this' because if I don't immediately realize I'm looking at a class method
> as opposed to a function I need to reread the whole function with the right
> scope in my head. In my opinion, Python doesn't exist directly to express
> complexity concisely, but rather to express complexity *clearly*. I don't
> think there's any universal purpose to high-level languages, either, beyond
> some vague common theme of abstracting out details for either conciseness or
> clarity or what have you.
> P.S. sorry for those of you who are getting my emails twice; i keep on
> forgetting to change which email I send this from.
> On Sun, Jun 22, 2008 at 10:25 AM, Warren Stringer <warren at muse.com> wrote:
>> *Is* there a reason to NOT use self? If not, then self is redundant. If
>> the reason to use self is to bypass name resolution order, then I would
>> suggest making the less common case explicit and the more common one
>> Since we're taIking about Objections, I find the statement "explicit is
>> good", without a justification, to be Objectionable. The only truly
>> explicit computer language is a circuit diagram. Even assembly language is
>> implicit; anything with op codes is a transformation of an explicit routing
>> of electrical charges to an implicit pattern that acts on an operand. Higher
>> level languages build upon lower level ones by transforming explicit
>> combinations into an implicit pattern.
>> IMO, languages evolve by compressing complexity. Just as Morse Code
>> compressed symbols tapped by hand over a wire, where the most common symbol
>> "E" required a single tap. Python reduces complexity by removing the
>> redundancy created by the often unnecessary enforcement of policy with typed
>> variables and by removing the redundancy of using begin/end symbols (for the
>> compiler) along with whitespace (for the human coders), when simply using
>> whitespace would suffice. As a result, Python is a more concise by making
>> coding policy implicit. However, Python is less concise when it enforces a
>> policy about making name resolution order explicit. From a statistical
>> viewpoint, this is akin to a Morse Code that assigning a single tap, not to
>> the letter 'E', where it belongs, but to the letter 'Z'.
>> While some people may see "self" as an issue of faith, others see it as a
>> statistical anomaly (in an otherwise compact language).
>> Baypiggies mailing list
>> Baypiggies at python.org
>> To change your subscription options or unsubscribe:
It's a walled garden, but the flowers sure are lovely!
More information about the Baypiggies