Method Underscores?

[Lonnie Princehouse]

Re: Method Underscores?

It's extremely common for Python newbies to accidentally overwrite
the names of important things. I see stuff like this all the time:

list = [1,2,3]
str = "Hello world"

This sort of accidental trampling would be even more frequent without
the underscores.


And, to play devil's advocate, there are probably a dozen ways to
hack around the underscores, for those who don't like them:

class __silly__(type) :
def __new__(cls, name, bases, dct):
# incomplete list - just enough for a demo
magic_functions = ['init','len','s tr']
for f in [x for x in magic_functions if x in dct]:
dct['__%s__' % f] = dct[f]
return type.__new__(cl s, name, bases, dct)
__metaclass__ = __silly__

class Bar:
def init(self):
print "init Bar instance"
def str(self):
return "Bar str method"
def len(self):
return 23

f = Bar()[color=blue][color=green][color=darkred]
>>> "init Bar instance"[/color][/color][/color]
str(f)[color=blue][color=green][color=darkred]
>>> "Bar str method"[/color][/color][/color]
len(f)[color=blue][color=green][color=darkred]
>>> 23[/color][/color][/color]




"Chris S." <chrisks@NOSPAM .udel.edu> wrote in message news:<9dIdd.371 2$EL5.3057@trnd ny09>...[color=blue]
> Is there a purpose for using trailing and leading double underscores for
> built-in method names? My impression was that underscores are supposed
> to imply some sort of pseudo-privatization, but would using
> myclass.len() instead of myclass.__len__ () really cause Python
> considerable harm? As much as I adore Python, I have to admit, I find
> this to be one of the language's most "unPythonic " features and a key
> arguing point against Python. I've searched for a discussion on this
> topic in the groups archives, but found little. What are everyone's
> thoughts on this subject?[/color]

[Andrew Dalke]

Re: Method Underscores?

Nicolas Fleury wrote:[color=blue]
> And a syntax would be needed to get that function, that's why I like so
> much the Python approach. My only complain is that _somename_ would
> probably have been enough instead of __somename__. In C++, all
> _[A-Z_].* are reserved, reserve _.*_ would have been enough in Python IMHO.[/color]

Though I liked how the win32 code uses '_.*_' for its
special properties. It's 1/2 way between user- and
system- space so it was a very nice touch.

Andrew
dalke@dalkescie ntific.com

[Alex Martelli]

Re: Method Underscores? (and a 'solution')

Jeremy Bowers <jerf@jerf.or g> wrote:
[color=blue]
> But what mystical language exists that uses less punctuation than Python?[/color]

Applescript, maybe. 'tell foo of bar to tweak zippo' where python would
have bar.foo.tweak(z ippo), looks like. (I'm not enthusiastic about the
idea, just pointing it out!-).


Alex

[Jeremy Bowers]

Re: Method Underscores? (and a 'solution')

On Fri, 22 Oct 2004 00:25:28 +0200, Alex Martelli wrote:
[color=blue]
> Jeremy Bowers <jerf@jerf.or g> wrote:
>[color=green]
>> But what mystical language exists that uses less punctuation than Python?[/color]
>
> Applescript, maybe. 'tell foo of bar to tweak zippo' where python would
> have bar.foo.tweak(z ippo), looks like. (I'm not enthusiastic about the
> idea, just pointing it out!-).[/color]

Point. Maybe Cobol on the same theory? I don't know, I've never used
either.

I guess if you're so stuck on the double-underscore-is-too-much-
punctuation idea, you *deserve* to try to do all your programming in a
combo of COBOL and Applescript :-)

I'm thinking I'll stick with Python.

[John Roth]

Re: Method Underscores? (and a 'solution')


"Jeremy Bowers" <jerf@jerf.or g> wrote in message
news:pan.2004.1 0.21.15.09.51.1 56298@jerf.org. ..[color=blue]
>
> But what mystical language exists that uses less punctuation than Python?
> I've tried to come up with it, and even the obscure ones I can come up
> with use more.[/color]

Forth. Postscript.

John Roth

[John Roth]

Re: Method Underscores?


"Chris S." <chrisks@NOSPAM .udel.edu> wrote in message
news:9dIdd.3712 $EL5.3057@trndn y09...[color=blue]
> Is there a purpose for using trailing and leading double underscores for
> built-in method names? My impression was that underscores are supposed to
> imply some sort of pseudo-privatization, but would using myclass.len()
> instead of myclass.__len__ () really cause Python considerable harm? As
> much as I adore Python, I have to admit, I find this to be one of the
> language's most "unPythonic " features and a key arguing point against
> Python. I've searched for a discussion on this topic in the groups
> archives, but found little. What are everyone's thoughts on this subject?[/color]

Languages that make everything methods tend to have
two characteristics in common: a single base class, and
no facility for procedural programming.

Python does not have a single base class, and one of its
strong points is that it's a multi-paradigm language. You can
use it for procedural programming without having to put
everything in the object paradigm. People quite frequently
do this for scripts.

In single base class languages, the top object in the
hierarchy is a hod-podge of methods that have no
relationship other than the language designer's decision
that the function is fundamental enough that it needs to
be available to every object, whether it needs it or not.

It would be technically possible (and relatively easy for
anyone with a bit of experience with working on Python's
internals) to add, for example, .len() to the object class.
Would this break anything? Unlikely in most cases
(there is one edge case I know of where it would). Alex Martelli's
comment elsewhere in this thread assumes one would also
remove it from the builtins, which would of course break
everything in sight.

Removing it from the builtins is equivalent to eliminating
the multi-paradigm nature of Python: you could no longer
do effective procedural programming without the builtins!
This is simply not going to happen: it would be a completely
different language. Discussing it is futile.

Also, the new .len() method would only be available
to new style classes written in Python, and then only
if the author of some subclass had not decided to implement
their own len() method with different semantics. The
first of these two objections goes away in Python 3.0,
where old style classes are eliminated. The second,
however, is a difficulty that all "pure" OO languages
need to deal with, and there is no real good way of
handling it (meaning obvious, works all the time
everywhere, and upward compatible without breaking
anything.).

Having a parallel structure where a large number of
builtins are also implemented as methods on object
violates Python's basic philosophy in at least two
ways: there should only be one (obvious) way to do
something, and things should work the same way
everywhere.

All that said, I'd like to see some of the builtins
as methods on object, but since it's not going
to happen, it's not worth worrying about.

John Roth

[Cliff Wells]

Re: Method Underscores? (and a 'solution')

On Thu, 2004-10-21 at 19:35 -0500, John Roth wrote:[color=blue]
> "Jeremy Bowers" <jerf@jerf.or g> wrote in message
> news:pan.2004.1 0.21.15.09.51.1 56298@jerf.org. ..[color=green]
> >
> > But what mystical language exists that uses less punctuation than Python?
> > I've tried to come up with it, and even the obscure ones I can come up
> > with use more.[/color]
>
> Forth. Postscript.[/color]

He did say mystical.

--
Cliff Wells <clifford.wells @comcast.net>

[Jeremy Bowers]

Re: Method Underscores? (and a 'solution')

On Thu, 21 Oct 2004 19:35:06 -0500, John Roth wrote:
[color=blue]
>
> "Jeremy Bowers" <jerf@jerf.or g> wrote in message
> news:pan.2004.1 0.21.15.09.51.1 56298@jerf.org. ..[color=green]
>>
>> But what mystical language exists that uses less punctuation than Python?
>> I've tried to come up with it, and even the obscure ones I can come up
>> with use more.[/color]
>
> Forth. Postscript.[/color]

I guess I should have specified "general purpose". Yeah, of course you can
do anything in Forth, Postscript, or Applescript, but they aren't much
competition for Python.

(By which I mean they serve vastly differing uses; I've never used Forth
directly but I have done HP-48 programming and I liked it and I hear
there's a lot of similarities. Great calculator language. Of the ones
listed Forth is the closest to being a plausible app language, but it
would need more libraries.)

[Alex Martelli]

Re: Method Underscores? (and a 'solution')

Jeremy Bowers <jerf@jerf.or g> wrote:
[color=blue]
> On Fri, 22 Oct 2004 00:25:28 +0200, Alex Martelli wrote:
>[color=green]
> > Jeremy Bowers <jerf@jerf.or g> wrote:
> >[color=darkred]
> >> But what mystical language exists that uses less punctuation than Python?[/color]
> >
> > Applescript, maybe. 'tell foo of bar to tweak zippo' where python would
> > have bar.foo.tweak(z ippo), looks like. (I'm not enthusiastic about the
> > idea, just pointing it out!-).[/color]
>
> Point. Maybe Cobol on the same theory? I don't know, I've never used
> either.[/color]

Roughly, I guess. But a typical Applescript might be:

tell application "Microsoft Word"
open "MyWordFile "
set selection to paragraph 1
data size of selection as string
end tell

while a typical Cobol would start

IDENTIFICATION DIVISION.
PROGRAM-ID. My-Program.
AUTHOR. Some Body.

DATA DIVISION.
WORKING-STORAGE SECTION.
01 Num1 PIC 9 VALUE ZEROS.

etc, etc; more full-stops, typically.

[color=blue]
> I guess if you're so stuck on the double-underscore-is-too-much-
> punctuation idea, you *deserve* to try to do all your programming in a
> combo of COBOL and Applescript :-)
>
> I'm thinking I'll stick with Python.[/color]

Me, too. But I understand how the "antiperl" (lrep?-) nearly
punctuation free style of Applescript may be tempting -- if Applescript
were cross-platform, it might perhaps make an even better beginners'
language than Python (and I think that of few languages). It doesn't
scale up as well as Python, though, it appears to me.


Alex

[Ville Vainio]

Re: Method Underscores?

>>>>> "Lonnie" == Lonnie Princehouse <finite.automat on@gmail.com> writes:

Lonnie> It's extremely common for Python newbies to accidentally
Lonnie> overwrite the names of important things. I see stuff like
Lonnie> this all the time:

Lonnie> list = [1,2,3]
Lonnie> str = "Hello world"

This is not really a mistake. If you don't use "list" builtin in the
same function, it's ok to override it. Not so on module level, of
course.

--
Ville Vainio http://tinyurl.com/2prnb

[Steve Holden]

Re: Method Underscores? (and a 'solution')

Alex Martelli wrote:
[color=blue]
> Jeremy Bowers <jerf@jerf.or g> wrote:
>[/color]
[...][color=blue]
> Roughly, I guess. But a typical Applescript might be:
>
> tell application "Microsoft Word"
> open "MyWordFile "
> set selection to paragraph 1
> data size of selection as string
> end tell
>[/color]
[...][color=blue]
>
>[color=green]
>>I guess if you're so stuck on the double-underscore-is-too-much-
>>punctuation idea, you *deserve* to try to do all your programming in a
>>combo of COBOL and Applescript :-)
>>[/color][/color]
What a dreadful; fate to wish on anybody!
[color=blue][color=green]
>>I'm thinking I'll stick with Python.[/color]
>
>
> Me, too. But I understand how the "antiperl" (lrep?-) nearly
> punctuation free style of Applescript may be tempting -- if Applescript
> were cross-platform, it might perhaps make an even better beginners'
> language than Python (and I think that of few languages). It doesn't
> scale up as well as Python, though, it appears to me.
>
>[/color]
Yeah, it does have that Logo-like quality about it, doesn't it? For
beginners, of course, it's typically more interesting to be able to
write scripts to get their computers to do things they'd otherwise have
to do themselves, so AppleScript-for-Windows might be a good Python project!

regards
Steve
--

http://www.holdenweb.com

http://pydish.holdenweb.com

Holden Web LLC +1 800 494 3119

[Alex Martelli]

Re: Method Underscores? (and a 'solution')

Steve Holden <steve@holdenwe b.com> wrote:
...[color=blue][color=green]
> > tell application "Microsoft Word"
> > open "MyWordFile "
> > set selection to paragraph 1
> > data size of selection as string
> > end tell[/color][/color]
...[color=blue][color=green]
> > were cross-platform, it might perhaps make an even better beginners'
> > language than Python (and I think that of few languages). It doesn't
> > scale up as well as Python, though, it appears to me.
> >[/color]
> Yeah, it does have that Logo-like quality about it, doesn't it? For
> beginners, of course, it's typically more interesting to be able to
> write scripts to get their computers to do things they'd otherwise have
> to do themselves, so AppleScript-for-Windows might be a good Python project![/color]

Yes, but mapping the simple "apple events" on which applescript is based
(and which are widespread in applications as well as the OS on the Mac,
e.g. MS Office apps implement them) to COM's richer and more complex
ways (and COM/Automation enjoys a similar prominence on Windows and its
applications) sounds like quite a task, requiring deep understanding of
both platforms. Maybe I'm being pessimistic...


Alex

[has]

Re: Method Underscores? (and a 'solution')

aleaxit@yahoo.c om (Alex Martelli) wrote in message news:<1gm17go.1 r662ynelfha7N%a leaxit@yahoo.co m>...[color=blue]
> Jeremy Bowers <jerf@jerf.or g> wrote:
>[color=green]
> > But what mystical language exists that uses less punctuation than Python?[/color]
>
> Applescript, maybe. 'tell foo of bar to tweak zippo' where python would
> have bar.foo.tweak(z ippo), looks like. (I'm not enthusiastic about the
> idea, just pointing it out!-).[/color]

Trust me, it's not a place you want to go. ;p

[has]

Re: Method Underscores? (and a 'solution')

aleaxit@yahoo.c om (Alex Martelli) wrote in message news:<1gm2fs0.1 wc9vf61okndnvN% aleaxit@yahoo.c om>...[color=blue][color=green]
> > Yeah, it does have that Logo-like quality about it, doesn't it? For
> > beginners, of course, it's typically more interesting to be able to
> > write scripts to get their computers to do things they'd otherwise have
> > to do themselves, so AppleScript-for-Windows might be a good Python project![/color][/color]

Even better idea: just use Logo! :)

Seriously, the AppleScript language is no great shakes. The only
things going for it are that AppleScript code is easy for
non-programmers to read, and that it's got very good Apple Event
Manager and Open Scripting Architecture support built in. Then again,
AppleScript code is a right pain to write, and the only reason it
remains the popular choice for Mac application scripting is because
most every other scripting language has failed to provide AEM and OSA
support worth a damn. :(

[color=blue]
> Yes, but mapping the simple "apple events" on which applescript is based
> (and which are widespread in applications as well as the OS on the Mac,
> e.g. MS Office apps implement them) to COM's richer and more complex
> ways (and COM/Automation enjoys a similar prominence on Windows and its
> applications) sounds like quite a task, requiring deep understanding of
> both platforms. Maybe I'm being pessimistic...[/color]

Any fule could implement a clone of the AS _language_; there's
actually very little to it. Heck, you could probably write a parser
that compiles an AppleScript-like syntax into Python source code
fairly easily. It's the OSA component and IPC stuff that would take
time. The former you could probably do fairly easily using COM, but
for IPC support you'll find Windows' DCOM/WSH to be a VERY different
beast to Apple events, which is basically synchronous/asynchronous RPC
plus basic relational queries. This means that almost all the hard
work to support a _full_ AppleScript clone would be on the
application, not the language, side. Which means not only providing
application developers with suitable frameworks but also persuading
them to use them - no small task to say the least.

An application's Apple event interface is basically a whole additional
View-Controller layer - a peer to its GUI/CLI/web/etc. interface(s) -
built atop the Apple Event Manager/Cocoa Scripting framework, just as
its GUI interface is built with the Application Kit framework. And,
just as there's a whole bunch of rules and guidelines on how GUI
interfaces should look and behave, there's an equivalent for scripting
interface developers. e.g. See Apple's Scripting Interface Guidelines,
a partner to its GUI-oriented HIG,
at<http://developer.apple .com/technotes/tn2002/tn2106.html>.

It's deceptively powerful stuff, though a lot of applications don't
support it nearly as well as they could - or should (many of Apple's
own apps are guilty here). Mac Office apps aren't really a good
example - their Apple event interfaces are really just a thin wrapper
around their VB APIs and quite atypical. Take a look at something like
Adobe InDesign (one of their engineers is Jon Pugh, one of the
original Apple team behind OSA, etc.) - it has very comprehensive and
well designed AE interface, as well as JavaScript and VB APIs.


You probably could implement a Windows clone of the Apple Event
Manager using DCOM or whatever as your inter-process message transport
mechanism, but it looks as if Longhorn will have something fairly
similar to Apple events and the Apple Event Object Model with its
Indigo and OPath technologies, so probably not worth doing now. (Makes
you wonder what might've been had OpenDoc taken off though - it was
built on Apple events and, IIRC, intended to be cross-platform, and
years ahead of its time.)

Mind you, I've already implemented Python libraries for constructing
object specifier-based queries
<http://freespace.virgi n.net/hamish.sanderso n/appscript.html> and am
working on supporting the Apple Event Object Model in Python, so you
probably could port these to other systems just by replacing the
platform-specific Carbon.AE extensions used for the inter-process
messaging part with XML-RPC, dBus or whatever else is to hand.


Happy to discuss this stuff further if anyone's interested and wants
to take it to a separate thread.

has

[has]

Re: Method Underscores? (and a 'solution')

aleaxit@yahoo.c om (Alex Martelli) wrote in message news:<1gm1um6.z gqbbe8x559fN%al eaxit@yahoo.com >...[color=blue]
> Jeremy Bowers <jerf@jerf.or g> wrote:[color=green]
> > I'm thinking I'll stick with Python.[/color]
>
> Me, too. But I understand how the "antiperl" (lrep?-) nearly
> punctuation free style of Applescript may be tempting -- if Applescript
> were cross-platform, it might perhaps make an even better beginners'
> language than Python (and I think that of few languages).[/color]

Ahhhhh, don't say that!

While AppleScript code can be wonderfully readable even to folk with
absolutely no knowledge of the language, it's often an absolute swine
to write - stripping out all the punctuation and allowing applications
and osaxen (extensions) to add their own arbitrary keywords leaves the
language semantics appallingly ambiguous and confused.

The right approach, imo, would be to design a very conventional
scripting language, perhaps using a S-expression based [non-]syntax
that's easy to manipulate programmaticall y, and leave all the fancy
syntax, visual effects, beginner-friendly dumbing down, etc. to the
editing tools, which are much better placed to know what's really what
than any dumb text-based source code can ever be. Still a major
undertaking, but a better chance of pulling it off than.

[color=blue]
> It doesn't scale up as well as Python, though, it appears to me.[/color]

Heh, more like AppleScript doesn't scale *at all*. :p

has