Double underscores -- ugly?

[benhoyt]

Hi guys,

I've been using Python for some time now, and am very impressed with
its lack of red tape and its clean syntax -- both probably due to the
BDFL's ability to know when to say "no".

Most of the things that "got me" initially have been addressed in
recent versions of Python, or are being addressed in Python 3000. But
it looks like the double underscores are staying as is. This is
probably a good thing unless there are better alternatives, but ...

Is it just me that thinks "__init__" is rather ugly? Not to mention
"if __name__ == '__main__': ..."?

I realise that double underscores make the language conceptually
cleaner in many ways (because fancy syntax and operator overloading
are just handled by methods), but they don't *look* nice.

A solution could be as simple as syntactic sugar that converted to
double underscores behind the scenes. A couple of ideas that come to
my mind (though these have their problems too):

def ~init(self): # shows it's special, but too like a C++ destructor
def +init(self): # a bit too additive :-)
defop add(self, other): # or this, equivalent to "def __add__"
def operator add(self, other): # new keyword, and a bit wordy

Has anyone thought about alternatives? Is there a previous discussion
on this I can look up?

Cheers,
Ben.

[Berwyn]

Re: Double underscores -- ugly?

Is it just me that thinks "__init__" is rather ugly? Not to mention

"if __name__ == '__main__': ..."?

That ugliness has long been my biggest bugbear with python, too. The
__name__ == '__main__' thing is something I always have to look up,
every time I use it, too ... awkward.

I'd settle for:

hidden def init(self): # which could be extended to work
for everything "hidden x=3"
...

And for __name__ == '__main__' how about:

if sys.main():
...

[Ben Finney]

The __name__ == '__main__' hack (was: Double underscores -- ugly?)

benhoyt <benhoyt@gmail. comwrites:

Not to mention "if __name__ == '__main__': ..."?

Unlike the double-underscore attribute names for signalling "special
meaning", that particular hack is IMO unnecessarily ugly.

I don't, however, think it's likely to go away any time soon. If
that's the ugliest convention people can find in Python (as opposed to
the limitless *non*-conventional ugliness that programmers are capable
of in any language), then Python is doing pretty well.

--
\ “An idea isn't responsible for the people who believe in it.” |
`\ —Donald Robert Perry Marquis |
_o__) |
Ben Finney

[Asun Friere]

Re: Double underscores -- ugly?


benhoyt wrote:

Is it just me that thinks "__init__" is rather ugly?

I used to hate looking at and having the type out all those
underscores (surely two leading or one on either side would do?), but
I've gotten so used to it by now the eyes don't see and the fingers
work by themselves.

Not to mention
"if __name__ == '__main__': ..."?

Which ugliness is only trumped by the use of 'main' as a function name
thus:

if __name__ == '__main__' : main()

[Raymond Hettinger]

Re: Double underscores -- ugly?

[benhoyt]

Is it just me that thinks "__init__" is rather ugly?

I also find it unattractive and unpleasant to type.

In Py3.0, I would support a single underscore convention, _init_ or
somesuch.

I'm not sure what the aesthetic reasons are, but somehow the change
from double underscores to single underscores makes the result a lot
less offensive to my eyes.

Raymond

[Marco Mariani]

Re: Double underscores -- ugly?

Ben Finney wrote:

>I realise that double underscores make the language conceptually
>cleaner in many ways (because fancy syntax and operator overloading
>are just handled by methods), but they don't *look* nice.

>
That's a good thing, in that it draws attention to the names.

Well, double underscore is awful when you have to read code with the
wrong typeface, possibly printed.

[Jason]

Re: Double underscores -- ugly?

On Feb 18, 3:28 pm, benhoyt <benh...@gmail. comwrote:

Hi guys,
>
I've been using Python for some time now, and am very impressed with
its lack of red tape and its clean syntax -- both probably due to the
BDFL's ability to know when to say "no".
>
Most of the things that "got me" initially have been addressed in
recent versions of Python, or are being addressed in Python 3000. But
it looks like the double underscores are staying as is. This is
probably a good thing unless there are better alternatives, but ...
>
Is it just me that thinks "__init__" is rather ugly? Not to mention
"if __name__ == '__main__': ..."?
>
I realise that double underscores make the language conceptually
cleaner in many ways (because fancy syntax and operator overloading
are just handled by methods), but they don't *look* nice.
>
A solution could be as simple as syntactic sugar that converted to
double underscores behind the scenes. A couple of ideas that come to
my mind (though these have their problems too):
>
def ~init(self): # shows it's special, but too like a C++ destructor
def +init(self): # a bit too additive :-)
defop add(self, other): # or this, equivalent to "def __add__"
def operator add(self, other): # new keyword, and a bit wordy
>
Has anyone thought about alternatives? Is there a previous discussion
on this I can look up?
>
Cheers,
Ben.

Hmm. I must be the only person who doesn't think the double
underscores are ugly. To me, they seem to provide plenty of attention
to the special methods, but still appear clean due to their almost
white-space-like nature. Given the use of underscores to indicate
italics in plain-text, the special methods seem (to me) to have extra
emphasis.

I don't print my code often, so that's a caveat, and I came from a C/C+
+ background.

I agree with Ben, that your suggestions don't particularly stand out.
They might stand out if the editor you used supported syntax
highlighting. Personally, I find the examples with the plus and tilde
(+, ~) to be more noisy and ugly than the underscores.

Think of the underscores as a serene white-space day, with a simple
black road that takes you to the special name. Or, you can wonder
what I'm smoking when I code.... *grin*

--Jason

[Wildemar Wildenburger]

Re: Double underscores -- ugly?

Jason wrote:

Hmm. I must be the only person who doesn't think the double
underscores are ugly.

Nope. I like them too. :)

Frankly, I think it's just a matter of adaption. I too found it rather
"ugly" in the beginning, but with anything, I've gotten used to it. (And
I wholeheartedly support your "looks like underlined / is unintrusive
like whitespace" argument.)

/W

[Ben Finney]

Re: Double underscores -- ugly?

Marco Mariani <marco@sferacar ta.comwrites:

Ben Finney wrote:
>

I realise that double underscores make the language conceptually
cleaner in many ways (because fancy syntax and operator overloading
are just handled by methods), but they don't *look* nice.

That's a good thing, in that it draws attention to the names.

>
Well, double underscore is awful when you have to read code with the
wrong typeface, possibly printed.

The wrong typeface can make anything awful to read. This is unrelated
to double-underscores.

The solution, therefore, is also unrelated to double-underscores:
choose an appropriate typeface.

--
\ “Courage is not the absence of fear, but the decision that |
`\ something else is more important than fear.” —Ambrose |
_o__) Redmoon |
Ben Finney

[benhoyt]

Re: Double underscores -- ugly?

My editor actually renders [underscores] as miniature chess pieces.
The bartender said she runs a pre-execution step, that searches and
replaces a double-colon with the underscores.

Heh, that makes me think. Great use for character encodings! Just like
Tim Hatch's "pybraces", we could use any character combo we liked and
just implement a character encoding for it. See:

http://timhatch.com/projects/pybraces/

Just kidding.

Seriously, though, I give in. There's no perfect solution, and it's
probably just a matter of getting over it. Though I wouldn't mind
Raymond Hettinger's suggestion of using single underscores as in
_init_. Only half as ugly. :-)

Then again, what's stopping us just using a single leading underscore?
Nobody calls their own private methods _init or _add ... and that's
only 1/4 the ugliness, which is getting pretty good.

-Ben

[Ben Finney]

Re: Double underscores -- ugly?

benhoyt <benhoyt@gmail. comwrites:

Then again, what's stopping us just using a single leading underscore?
Nobody calls their own private methods _init or _add

You must be looking at different code from the rest of us. A single
leading underscore on the name *is* the convention for "this attribute
is not part of the external interface", which is about as "private" as
Python normally gets.

--
\ “God forbid that any book should be banned. The practice is |
`\ as indefensible as infanticide.” —Dame Rebecca West |
_o__) |
Ben Finney

[Erik Max Francis]

Re: Double underscores -- ugly?

castironpi@gmai l.com wrote:

My editor actually renders them as miniature chess pieces. The
bartender said she runs a pre-execution step, that searches and
replaces a double-colon with the underscores.

I'm sorry, did you hit your head before dashing off your recent posts or
something?

--
Erik Max Francis && max@alcyone.com && http://www.alcyone.com/max/
San Jose, CA, USA && 37 18 N 121 57 W && AIM, Y!M erikmaxfrancis
One cannot always be a hero, but one can always be a man.
-- Goethe

[Ivan Illarionov]

Re: Double underscores -- ugly?

I would like to see something like %init or &init to be converted to
__init__ behind the scenes. And $something to be converted to
self.something. But, unfortunately, most Python people would consider
this ugly just because Perl uses too much syntactic sugar and anything
Perl-like is considered ugly in Python community. So, unless Perl die,
I believe that Python will remain sugar-free.

[benhoyt]

Re: Double underscores -- ugly?

Then again, what's stopping us just using a single leading underscore?
Nobody calls their own private methods _init or _add

>
You must be looking at different code from the rest of us. A single
leading underscore on the name *is* the convention for "this attribute
is not part of the external interface", which is about as "private" as
Python normally gets.

Yeah, I understand that. I meant -- and I could be wrong -- that I
haven't seen people creating a method called "init" with a single
leading underscore. It's too similar to "__init__", so they would use
some other name.

In other words, defining _init to mean what __init__ now means
probably wouldn't cause name conflicts.

-Ben

[Ben Finney]

Re: Double underscores -- ugly?

Please preserve attribution lines on the quoted material, so we can
see who wrote what at each level.

benhoyt <benhoyt@gmail. comwrites:

Then again, what's stopping us just using a single leading
underscore? Nobody calls their own private methods _init or _add

You must be looking at different code from the rest of us. A
single leading underscore on the name *is* the convention for
"this attribute is not part of the external interface", which is
about as "private" as Python normally gets.

>
Yeah, I understand that. I meant -- and I could be wrong -- that I
haven't seen people creating a method called "init" with a single
leading underscore. It's too similar to "__init__", so they would
use some other name.
>
In other words, defining _init to mean what __init__ now means
probably wouldn't cause name conflicts.

But it would conflict with the existing conventions. '_init' as a name
indicates that it's *not* treated specially, because it's not named
with double-underscores. Since it *is* treated specially by Python, it
would be confusing not to follow the convention for naming such
attributes.

--
\ "I know you believe you understood what you think I said, but I |
`\ am not sure you realize that what you heard is not what I |
_o__) meant." -- Robert J. McCloskey |
Ben Finney