Why a class when there will only be one instance?

[Kirk Strauser]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

$Prefixing @names with @symbols like $ and @ $is a great @idea - it $makes
the "@nouns" (@variables) $stand out from "@verbs" and $makes the @code
$flow like natural @language, $making $reading it easy and $writing it fun!

I ran that through Perl and got a mildly functional spreadsheet application.
A few more lines, and I think you could've added the flight simulator.
- --
Kirk Strauser
The Strauser Group
Open. Solutions. Simple.
http://www.strausergroup.com/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAtOya5sRg+Y0CpvERAm5OAJ9sjhZPhu2iVU3pdH+jiM2eb3udowCeNpJr
O9ca+ZS3J4lFI5gnQKTOOZI=
=NXmP
-----END PGP SIGNATURE-----

 

[Josh Gilbert]

Ryan> the line. It's a good OO strategy. I do understand your
Ryan> dislike of 'self'. It does seem like clutter. In my code, I
Ryan> shorten it to 's'. In ruby, class variables are prefixed
Ryan> with an '@', which makes them easier to discern in code, and
Ryan> it is easier than typing 'self'. I wish python had something

Prefixing names with symbols like $ and @ is a great idea - it makes
the "nouns" (variables) stand out from "verbs", and makes the code
flow like a natural language, making reading it easy and writing it
fun!

On a more serious note, you could consider creating a binding for @
that inserts "self.". @ is almost never used in Python, so it should
be pretty safe.

Ryan> like that. I also think that having to specify the class
Ryan> variable in every function definition is a bit silly. Ruby
Ryan> gets rid of that too.

You might want to create a preprocessor that adds "self" to all
in-class definitions that have @, and convert @hei to self.hei. Voila,
Ruby non-silliness.

The idea could be extended to provide a "Python shorthand", which
would expand to full-blown Python:

d hello x y: -> def hello(x,y):


c hello baseclass:
d init arg1 arg2: # expand to __init__
.x = arg1
.y = arg2
d sayhi:
p "hi!"
.x = 555



o = hello 12 13

p o.x + o.y # prints 25

o.sayhi

p o.x # prints 555


Actually, while this would make zero sense for language-as-such, it
might turn out to be a fun way to hammer out that first ultra-rapid
prototype. At the moment something comes up that needs the
explicitness of Python (say, after 45 minutes of hacking), the
shorthand can be expanded to Python (optimally with M-x
py-expand-shorthand).

I find that I write Python code quite fast already, but some phases of
the coding process (esp. the implementation of classes) could be
further accelerated by this shorthand, mostly due to alleviating the
need to use the shift-key. ":" should still be there to enable the use
of python-mode.el.

The implementation of the shorthand could be pretty ad-hoc, with
possibly ambigous grammar. The shorthand would never be shipped
unexpanded anyway.

Now that's a great idea! Not the sigils stuff, I switched from Perl to
Python for a reason, I was putting sigils in my English, C, and so on.

I love the shorthand tho:

c hello baseclass:
d init arg1 arg2: # expand to __init__
.x = arg1
.y = arg2
d sayhi:
p "hi!"
.x = 555

That seems unambiguous to me and I could see a parser for that language that
would output equivalent Python. It just so happens that there was an
article on slashdot a few minutes ago recommending a similar principle
(http://www.third-bit.com/~gvwilson/xmlprog.html).

The rules of the game:
*This language must require less typing or be easier to use than Python.
*Each construct must map to an equivalent Python construct unambiguously.
*We always generate the Python equivalent ASAP and throw out the shorthand.
(You might want sigils, but I don't. Only Python is portable.)

There are two paths, have the IDE convert each line to Python when you hit
'\n' or as a batch. The first method would allow it in Python shells.

One final thought, it should be added to IPython. I'm not associated with
IPython in any way, but it already supports alternate Python syntax and
generates genuine Python.
In [6]: range 3
------> range(3)
Out[6]: [0, 1, 2]


This is a very good idea. I wonder how hard it will be.

Josh Gilbert

 

[Ville Vainio]

Andrew> Interesting idea. Let's try it with English, using @ for
Andrew> nouns and $ for verbs:

Lest the humor (of contorted inside variety, I admit) be missed, it
was a parody of Larry Wall's argument for why $ prefix does not in
fact suck.

 

[Peter Otten]

Ryan> the line. It's a good OO strategy. I do understand your
Ryan> dislike of 'self'. It does seem like clutter. In my code, I
Ryan> shorten it to 's'. In ruby, class variables are prefixed
Ryan> with an '@', which makes them easier to discern in code, and
Ryan> it is easier than typing 'self'. I wish python had something

Prefixing names with symbols like $ and @ is a great idea - it makes
the "nouns" (variables) stand out from "verbs", and makes the code
flow like a natural language, making reading it easy and writing it
fun!

As a preliminary measure you might want to apply the following patch:

*** this.py 2002-02-08 21:41:34.000000000 +0100
--- $this.py 2004-05-27 09:34:01.000000000 +0200
***************
*** 18,24 ****
Nygubhtu arire vf bsgra orggre guna *evtug* abj.
Vs gur vzcyrzragngvba vf uneq gb rkcynva, vg'f n onq vqrn.
Vs gur vzcyrzragngvba vf rnfl gb rkcynva, vg znl or n tbbq vqrn.
! Anzrfcnprf ner bar ubaxvat terng vqrn -- yrg'f qb zber bs gubfr!"""

d = {}
for c in (65, 97):
--- 18,24 ----
Nygubhtu arire vf bsgra orggre guna *evtug* abj.
Vs gur vzcyrzragngvba vf uneq gb rkcynva, vg'f n onq vqrn.
Vs gur vzcyrzragngvba vf rnfl gb rkcynva, vg znl or n tbbq vqrn.
! $Flzoby $cersvkrf @ner &bar !@ubaxvat &terng $vqrn -- /yrg'f @qb &!zber
&bs $gubfr!"""

d = {}
for c in (65, 97):

As you can see I didn't find the proposed distinction between nouns and
verbs always convenient. A little randomness immediately leads the eye to
the really unimportant stuff - just like the ugly new hat of a friend you
haven't seen for some time.
Yet another case where practicality beats purity

Peter

 

[Peter Maas]

You might want to create a preprocessor that adds "self" to all
in-class definitions that have @, and convert @hei to self.hei. Voila,
Ruby non-silliness.

This is an editor job. Good programming editors allow to expand
abbreviations, so there is no need to clutter the language
definition or write a preprocessor.

Mit freundlichen Gruessen,

Peter Maas

 

[Ville Vainio]

Josh> Now that's a great idea! Not the sigils stuff, I switched
Josh> from Perl to Python for a reason, I was putting sigils in my
Josh> English, C, and so on.

I agree - the $ @ stuff was a (bad) joke, as I said elsewhere.

Josh> There are two paths, have the IDE convert each line to
Josh> Python when you hit '\n' or as a batch. The first method
Josh> would allow it in Python shells.

Live conversion would probably bring less surprises.

Josh> This is a very good idea. I wonder how hard it will be.

At least it doesn't *seem* difficult. It might even be easy enough to
do with regexps!

Some syntax brainstorming again:

d f x,y,z=12: -> def f(x,y,z=12): (, is one keystroke just like space)

d f x,y: -> def f(self,x,y): (d with indent, add self)

p x; r x; -> print x; return x


a.b 1,2 ; a..b ; .a; -> a.b(1,2); a.b ; self.a;

Sounds like a potentially fun emacs project, and the style of
programming that could be appreci8ed by TXT MSG gener8n .

 

[Ville Vainio]

Peter> This is an editor job. Good programming editors allow to
Peter> expand abbreviations, so there is no need to clutter the
Peter> language definition or write a preprocessor.

Cluttering the language definition was the furthest thing from my
mind. The point of the preprocessor suggestion was that there is no
need to abandon Python if 'self' is all that troubles you. If one
doesn't bear to look at it, it can be made invisible. Running every
Python script you write through a preprocessor is not a worse solution
that switching to Ruby.

 

[Josh Gilbert]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Josh> Now that's a great idea! Nlanguageigils stuff, I switched
Josh> from Perl to Python for a reason, I was putting sigils in my
Josh> English, C, and so on.

I agree - the $ @ stuff was a (bad) joke, as I said elsewhere.

Josh> There are two paths, have the IDE convert each line to
Josh> Python when you hit '\n' or as a batch. The first method
Josh> would allow it in Python shells.

Live conversion would probably bring less surprises.

Josh> This is a very good idea. I wonder how hard it will be.

At least it doesn't *seem* difficult. It might even be easy enough to
do with regexps!

Some syntax brainstorming again:

d f x,y,z=12: -> def f(x,y,z=12): (, is one keystroke just like
space)

d f x,y: -> def f(self,x,y): (d with indent, add self)

p x; r x; -> print x; return x


a.b 1,2 ; a..b ; .a; -> a.b(1,2); a.b ; self.a;

Sounds like a potentially fun emacs project, and the style of
programming that could be appreci8ed by TXT MSG gener8n .

Oh my. It's utterly trivial with IPython. As in the framework is all there,
just plug in your rules. My implementation currently uses only regex's
which could lead to errors in string literals or comments. However, it
works.

A more interesting implementation would be to write a full-blown parser for
the shorthand language with a simple lookup table to translate it to real
Python. I might get around to it, but probably not. I can't think of a way
to save much more typing without being overly obscure.

Well that was fun. I guess the only thing left for me to say is the vague
handwaving of suggesting that the script could decode to another language,
any language as long as you can define a one to one correspondence of
terminals. So I could write Java that looked an awful lot like Python.
Probably a bad idea.

Josh

- --
http://www.uvm.edu/~jgilbert/public_key.gpg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAtkX13TWYZBkZ2IsRAiylAJ9oaFGHFoN0aRE8aGWxmyZIDt2c6ACbBBfB
FG/DVh1ApDQyBvKRQeTW61g=
=7Nwd
-----END PGP SIGNATURE-----

 

[=?iso-8859-1?Q?Fran=E7ois?= Pinard]

[[email protected]]

I see the value of a class when two or more instances will be created,
but Python programmers regularly use a class when there will only be
one instance. What is the benefit of this?

There are two advantages for me:

1) It helps at keeping related data and actions together within a named
concept. This further increases legibility and eases maintenance.

2) The global namespace stays much cleaner. (A side effect is that I
never need the `global' declaration in practice.)

It has a disadvantage of a whole lot of "self." being required
everywhere, making the code less readable.

While those `self.' are a bit of a clutter indeed, they help me to read
that this routine is calling this other one within the same conceptual
part of the whole program, and as such, they had documentation value.

Oh, also, all the methods of this class will have to have the instance
name prepended to them.

It would be `self.' within the class itself, and the instance name
within foreign classes. This habit stresses the relations between the
parts of the program and eases a better understanding of the whole.

 

[Christian Tismer]

François Pinard wrote:

....

It would be `self.' within the class itself, and the instance name
within foreign classes. This habit stresses the relations between the
parts of the program and eases a better understanding of the whole.

Just a little observation:
If you really want the class and the instance to be the same,
well, you can take a module.
In a sense, this *is* a class and the only instance.

ciao - chris
--
Christian Tismer :^) <mailto:[email protected]>
Mission Impossible 5oftware : Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/
14109 Berlin : PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34 home +49 30 802 86 56 mobile +49 173 24 18 776
PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04
whom do you want to sponsor today? http://www.stackless.com/

 

[=?iso-8859-1?Q?Fran=E7ois?= Pinard]

[Christian Tismer]

François Pinard wrote:

Just a little observation: If you really want the class and the
instance to be the same, well, you can take a module. In a sense,
this *is* a class and the only instance.

Indeed, and for programs which are more than small, this is a very
natural way to proceed. On the other hand, for programs which are not
so big, it is often quite practical to keep everything in a single file,
and there, short of having many modules, sole instances of a few classes
are still an attractive way for organising the code.

It might be worth noting, as a kind of counter-argument, that abusing of
classes may decrease legibility instead of increasing it. As usual in
such things, sense of measure, and good taste, are always welcome!

 

[Ville Vainio]

Josh> Oh my. It's utterly trivial with IPython. As in the
Josh> framework is all there,

But isn't IPython solely for interactive use?

 

[Josh Gilbert]

Josh> Oh my. It's utterly trivial with IPython. As in the
Josh> framework is all there,

But isn't IPython solely for interactive use?

Yes, you are correct. A decided limitation. You can automatically save
the Python statements from a session and paste them into a file, but you
cannot edit an existing file in an interactive mode. I'm afraid I have
to admit ignorace here, does Emacs offer more?

Josh.

 

[Ville Vainio]

Josh> Yes, you are correct. A decided limitation. You can
Josh> automatically save the Python statements from a session and
Josh> paste them into a file, but you cannot edit an existing file
Josh> in an interactive mode. I'm afraid I have to admit ignorace
Josh> here, does Emacs offer more?

Well, one idea would be to bind some kind of py-expand-current-line
command to the enter key, in addition to the normal newline
operation. Editing/creating the script would proceed as usual, with
the additional advantage of shorthand writing.

Normal emacs 'abbrev' processing won't do the trick, because
abbreviations are expansion of short string to long string, not
expansion of identifier with parameters to identifier with the same
parameters in other places/other representations.

 

[Cameron Laird]

Ville Vainio wrote: .
.
.
Yes, you are correct. A decided limitation. You can automatically save

.
.
.
Hold on; while I'm sure we can define "interactive" in a way
that includes all the things IPython does, I think that's
misleading. IPython supports a WIDE variety of uses. I don't
want someone to take the characterization above out of context
to reach a mistaken conclusion about IPython's limits.