[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.python

Double underscores -- ugly?

benhoyt

2/18/2008 10:29:00 PM

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.
35 Answers

Ben Finney

2/18/2008 11:39:00 PM

0

benhoyt <benhoyt@gmail.com> writes:

> 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. The
convention is by design: these names will be treated specially, so
they should stand out visually to the reader.

> 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

None of these, IMO, meet the "needs to stand out" requirement met by
double-underscore names.

They also introduce special cases for the language parser (and thus
for the reader to understand how the language will be parsed), whereas
double-underscore names work without any special syntax handling.

--
\ â??Holy contributing to the delinquency of minors, Batman!â? |
`\ â??Robin |
_o__) |
Ben Finney

Berwyn

2/19/2008 12:15:00 AM

0

> 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

2/19/2008 12:33:00 AM

0

benhoyt <benhoyt@gmail.com> writes:

> 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

2/19/2008 1:37:00 AM

0


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()

Terry Reedy

2/19/2008 2:23:00 AM

0


"benhoyt" <benhoyt@gmail.com> wrote in message
news:a52fa343-1b7a-4e99-8841-6b64a046ca1a@i7g2000prf.googlegroups.com...
| 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?

No, the reservered special names are supposed to be ugly ;-) -- or at least
to stand out. However, since special methods are almost always called
indirectly by syntax and not directly, only the class writer or reader, but
not users, generally see them.

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

Someone (perhaps me) once suggested on pydev using 'main' instead, but a
couple of people piped back that they regularly name their main module (as
opposed to the startup script) 'main'. So much for that idea. 'main__'
might not look as bad, but anything other that '__main__' introduces an
inconsistency with the reserved name rule. Changing '__name__' has the
same pair of problems (conflict with user names and consistency). So I
decided to live with the current incantation.

Terry Jan Reedy



|



Raymond Hettinger

2/19/2008 3:17:00 AM

0

[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

benhoyt

2/19/2008 5:39:00 AM

0


> [Terry Jan Reedy]
> No, the reservered special names are supposed to be ugly ;-) -- or at least
> to stand out. However, since special methods are almost always called
> indirectly by syntax and not directly, only the class writer or reader, but
> not users, generally see them.

Fair enough, but my problem is that class writers are users too. :-)

-Ben

Duncan Booth

2/19/2008 9:01:00 AM

0

Berwyn <berhoyt@gmail.com> wrote:

>> 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():
> ...

Or even:

@hidden
def init(self): ...

@main
def mymainfunc():
...


The first of those probably wants some metaclass support to make it work
cleanly, but here's a sample implementation for the second one:

import sys, atexit
def main(f):
"""Decorator for main function"""
def runner():
sys.exit(f())
if f.func_globals['__name__']=='__main__':
atexit.register(runner)
return f

print "define mymainfunc"
@main
def mymainfunc(args=sys.argv):
print "Got args", args
return 3
print "end of script"

If you have multiple functions marked as main that will run them in
reverse order, so it might be better to put them on a list and use a
single runner to clear the list. Also, I have no idea what happens to
the exit code if you use this decorator more than once.

BTW, should anyone be wondering, you can still use atexit inside a
function called from atexit and any registered functions are then called
when the first one returns.

Marco Mariani

2/19/2008 2:17:00 PM

0

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

2/19/2008 2:37:00 PM

0

On Feb 18, 3:28 pm, benhoyt <benh...@gmail.com> wrote:
> 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