By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
444,137 Members | 2,242 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 444,137 IT Pros & Developers. It's quick & easy.

Why a class when there will only be one instance?

P: n/a
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? It has a disadvantage of a whole lot of
"self."
being required everywhere, making the code less readable. Also, since a
strength of Python is rapid application development, it slows one down
to have to put in all those self.'s. The code seems much cleaner to me
without classes that have only one instance. Oh, also, all the methods
of this class will have to have the instance name prepended to them.

I would appreciate it if someone could explain the advantages of doing
this, or at least the sociological reasons why it occurs.

Mitchell Timin

--
"Many are stubborn in pursuit of the path they have chosen, few in
pursuit of the goal." - Friedrich Nietzsche

http://annevolve.sourceforge.net is what I'm into nowadays.
Humans may write to me at this address: zenguy at shaw dot ca
Jul 18 '05 #1
Share this Question
Share on Google+
34 Replies


P: n/a
On Ter 25 Mai 2004 21:43, Se******@SeeBelow.Nut wrote:
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? It has a disadvantage of a whole lot of
"self."
being required everywhere, making the code less readable. Also, since a
strength of Python is rapid application development, it slows one down
to have to put in all those self.'s. The code seems much cleaner to me
without classes that have only one instance. Oh, also, all the methods
of this class will have to have the instance name prepended to them.

I would appreciate it if someone could explain the advantages of doing
this, or at least the sociological reasons why it occurs.


How can you guarantee that such a code will never ever be used again,
anywhere?

It's easier to allow for code reuse from the beginning, IMHO.

--
Godoy. <go***@ieee.org>
Jul 18 '05 #2

P: n/a
On 2004-05-26, Se******@SeeBelow.Nut <Se******@SeeBelow.Nut> wrote:
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?


What happens when down the line someone wants to use that code in
something that requires multiple instances?

--
Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
PGP Key: 8B6E99C5 | main connection to the switchboard of souls.
-------------------------------+---------------------------------------------
Jul 18 '05 #3

P: n/a
On Wed, 26 May 2004 00:43:49 +0000, SeeBelow wrote:
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? It has a disadvantage of a whole lot of
"self."
being required everywhere, making the code less readable. Also, since a
strength of Python is rapid application development, it slows one down
to have to put in all those self.'s. The code seems much cleaner to me
without classes that have only one instance. Oh, also, all the methods
of this class will have to have the instance name prepended to them.

I would appreciate it if someone could explain the advantages of doing
this, or at least the sociological reasons why it occurs.

Mitchell Timin


defining a class may be useful if you plan on making more instances down
the line. It's a good OO strategy. I do understand your dislike of 'self'.
It does seem like clutter. In my code, I shorten it to 's'. In ruby, class
variables are prefixed with an '@', which makes them easier to discern in
code, and it is easier than typing 'self'. I wish python had something
like that. I also think that having to specify the class variable in every
function definition is a bit silly. Ruby gets rid of that too.

--SegPhault

Jul 18 '05 #4

P: n/a
In article <40***************@shaw.ca>, Se******@SeeBelow.Nut wrote:
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? It has a disadvantage of a whole lot of
"self."
being required everywhere, making the code less readable. Also, since a
strength of Python is rapid application development, it slows one down
to have to put in all those self.'s. The code seems much cleaner to me
without classes that have only one instance. Oh, also, all the methods
of this class will have to have the instance name prepended to them.

I would appreciate it if someone could explain the advantages of doing
this, or at least the sociological reasons why it occurs.

Mitchell Timin


Typing "self" is a mechanical process which adds very little to the
development cost. Deciding which things to make classes and which not
to requires significant mental effort and does add cost. It's just
easier to make everything a class.

More than that, most times I've decided to not bother making something a
class because it was too simple, I've eventually added enough
functionality to it to change my mind and have to re-do things. That's
real cost. Much simplier and cheaper to just make it a class from the
get-go.
Jul 18 '05 #5

P: n/a
Ryan Paul <se*******@sbcglobal.net> wrote:
defining a class may be useful if you plan on making more instances down
the line. It's a good OO strategy. I do understand your dislike of 'self'.
It does seem like clutter. In my code, I shorten it to 's'.


Please don't do that. While it's true that the first parameter of a
class method can be named anything, the use of "self" is so
overwhelmingly ubiquitous it might as well be a standard. Using
anything else is just going to make your code more difficult for anybody
else to read and understand.

Typing is cheap. Thinking is expensive. And, yes Aahz, you can quote
me on that :-)
Jul 18 '05 #6

P: n/a
Roy Smith wrote:

In article <40***************@shaw.ca>, Se******@SeeBelow.Nut wrote:
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? It has a disadvantage of a whole lot of
"self."
being required everywhere, making the code less readable. Also, since a
strength of Python is rapid application development, it slows one down
to have to put in all those self.'s. The code seems much cleaner to me
without classes that have only one instance. Oh, also, all the methods
of this class will have to have the instance name prepended to them.

I would appreciate it if someone could explain the advantages of doing
this, or at least the sociological reasons why it occurs.

Mitchell Timin
Typing "self" is a mechanical process which adds very little to the
development cost. Deciding which things to make classes and which not
to requires significant mental effort and does add cost. It's just
easier to make everything a class.


Even easier is not to make anything a class unless there will be two or
more instances of it. I still don't get what advantage making a class
buys for you.

More than that, most times I've decided to not bother making something a
class because it was too simple, I've eventually added enough
functionality to it to change my mind and have to re-do things. That's
real cost. Much simplier and cheaper to just make it a class from the
get-go.


Why does greater functionality make a class desireable, if there won't
be multiple instances created?

Other people have mentioned "code reuse". Again I don't see how a class
helps to make code reusable. I find methods in a class more difficult
to reuse than simple function definitions. (unless there are multiple
instances.)

Mitchell Timin

--
"Many are stubborn in pursuit of the path they have chosen, few in
pursuit of the goal." - Friedrich Nietzsche

http://annevolve.sourceforge.net is what I'm into nowadays.
Humans may write to me at this address: zenguy at shaw dot ca
Jul 18 '05 #7

P: n/a
In article <40***************@shaw.ca>, Se******@SeeBelow.Nut wrote:
More than that, most times I've decided to not bother making something a
class because it was too simple, I've eventually added enough
functionality to it to change my mind and have to re-do things. That's
real cost. Much simplier and cheaper to just make it a class from the
get-go.


Why does greater functionality make a class desireable, if there won't
be multiple instances created?


For me, it's more about encapsulation than code re-use. If I've got a
bunch of functions which operate on a collection of data, to me that
says "object", which in Python (and most OOPL's) implies "class".

Bundling it up into a class lets me think about it as a unit. Each
class is a convenient thought unit for design and testing, and also for
understanding somebody else's code.

I don't think there's a need to be dogmatic about it. It's just what I
find is a natural way to break a program down into smaller pieces you
can get your brain around one piece at a time.
Jul 18 '05 #8

P: n/a
Roy Smith wrote:

In article <40***************@shaw.ca>, Se******@SeeBelow.Nut wrote:
More than that, most times I've decided to not bother making something a
class because it was too simple, I've eventually added enough
functionality to it to change my mind and have to re-do things. That's
real cost. Much simplier and cheaper to just make it a class from the
get-go.
Why does greater functionality make a class desireable, if there won't
be multiple instances created?


For me, it's more about encapsulation than code re-use. If I've got a
bunch of functions which operate on a collection of data, to me that
says "object", which in Python (and most OOPL's) implies "class".


OK, that makes some sense - to associate certain data and code items and
separate them from other code and data. Wouldn't that purpose be served
even better by putting them into a different file, and not bother with a
class?
Bundling it up into a class lets me think about it as a unit. Each
class is a convenient thought unit for design and testing, and also for
understanding somebody else's code.

I don't think there's a need to be dogmatic about it. It's just what I
find is a natural way to break a program down into smaller pieces you
can get your brain around one piece at a time.

--
"Many are stubborn in pursuit of the path they have chosen, few in
pursuit of the goal." - Friedrich Nietzsche

http://annevolve.sourceforge.net is what I'm into nowadays.
Humans may write to me at this address: zenguy at shaw dot ca
Jul 18 '05 #9

P: n/a
<Se******@SeeBelow.Nut> wrote in message news:40***************@shaw.ca...
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? It has a disadvantage of a whole lot of
"self."
being required everywhere, making the code less readable. Also, since a
strength of Python is rapid application development, it slows one down
to have to put in all those self.'s. The code seems much cleaner to me
without classes that have only one instance. Oh, also, all the methods
of this class will have to have the instance name prepended to them.
I'm only aware of one domain (interactive fiction) where it is really
common to have single instance classes. That's served by a number
of special purpose languages (Inform, TADS and Hugo spring to
mind). Your example (of single use classes in a UI context) seems
to be a bit contrived. I've usually found that I could get quite a bit
of code reuse out of UI classes simply by thinking the problems
through.

Granted, single use classes aren't uncommon, but instances of
other classes are much more common in most programs. In
Python, there are a number of ways of getting singletons without
very much extra effort.
I would appreciate it if someone could explain the advantages of doing
this, or at least the sociological reasons why it occurs.
Both have their uses. The class / instance dicotomy comes from
the earliest days of object oriented programming, and experiments
with classless languages (see the Prothon stuff currently going on,
also the IO language) have never been very compelling. A lot of
people (which include me) think that it's much to easy to get sloppy
with that paradigm.

The other thing to understand is that in most OO languages a
class is a declaration: it does not appear in the actual object
program other than as a framework for the instances that are
created. Python is one of the few languages where classes are
first class objects.

John Roth

Mitchell Timin

Jul 18 '05 #10

P: n/a
Se******@SeeBelow.Nut wrote:
Even easier is not to make anything a class unless there will be two or
more instances of it. I still don't get what advantage making a class
buys for you.
To use classes even in single instance cases has some advantages:

- There is a unique way of organizing your code.

- There is an easy transition to the multiple instance case.

- It makes writing meta code (e.g. for documentation, transformation
...) easier.

- Code organisation should resemble the real world problem to be modeled
(for the sake of clarity): if emphasis is on an entity (e.g. a document)
use an object, if emphasis is on activity (e.g. computing the cosine)
use a function.

These advantages outweigh by far lexical arguments (self. takes soooo long
to type) or temporary arguments (instance count is currently = 1).

Of course this is largely a matter of taste but I am a 'burnt child'
because I had to deal with the one-instance argument in multi-developer
projects and found the defender's code quite messy. :)
Other people have mentioned "code reuse". Again I don't see how a class
helps to make code reusable.
Inheritance.
I find methods in a class more difficult to reuse than simple function
definitions. (unless there are multiple instances.)


Why? Methods are functions with an instance argument:

class person:
def tellName(self):
print self.name
p = person()
p.name = 'Peter'
intro_c = person.tellName
intro_c(p) Peter intro_i = p.tellName
intro_i()

Peter

Mit freundlichen Gruessen,

Peter Maas

--
-------------------------------------------------------------------
Peter Maas, M+R Infosysteme, D-52070 Aachen, Hubert-Wienen-Str. 24
Tel +49-241-93878-0 Fax +49-241-93878-20 eMail pe********@mplusr.de
-------------------------------------------------------------------
Jul 18 '05 #11

P: n/a
On Tue, 25 May 2004 21:20:02 -0400, Roy Smith wrote:
Ryan Paul <se*******@sbcglobal.net> wrote:
defining a class may be useful if you plan on making more instances down
the line. It's a good OO strategy. I do understand your dislike of 'self'.
It does seem like clutter. In my code, I shorten it to 's'.


Please don't do that. While it's true that the first parameter of a
class method can be named anything, the use of "self" is so
overwhelmingly ubiquitous it might as well be a standard. Using
anything else is just going to make your code more difficult for anybody
else to read and understand.

Typing is cheap. Thinking is expensive. And, yes Aahz, you can quote
me on that :-)


I dont conform to a bad standard just because it's a standard. If I did, I
would be using java instead of a dynamic language like python. If other
people dont like it, thats too bad- they dont have to use my code.

Jul 18 '05 #12

P: n/a
On 2004-05-26, Se******@SeeBelow.Nut <Se******@SeeBelow.Nut> wrote:
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?
1) Because people are notoriously bad and predicting the
future. Their guesses at what "will be" are often wrong.

If you use a class, then you can add a second instance
later when you figure out what the customer really wanted.

2) I find it often helps me think through the problem and
arrive at a more structured, easily maintained solution
compared to a bunch of random functions.
It has a disadvantage of a whole lot of "self." being required
everywhere, making the code less readable.
In some cases (particulary mathematical computations), the
self's can reduce readability. A few local variables can fix
that.
Also, since a strength of Python is rapid application
development, it slows one down to have to put in all those
self.'s.
I've never seen any project where the speed of development was
limited by typing speed.
The code seems much cleaner to me without classes that have
only one instance.


Until the requirements change (or are actually discovered), and
you need more than one instance.

--
Grant Edwards grante Yow! If I felt any more
at SOPHISTICATED I would DIE
visi.com of EMBARRASSMENT!
Jul 18 '05 #13

P: n/a
Se******@SeeBelow.Nut wrote:
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.


This is a lot like putting code in functions. "Its only called in one place, why put it in a function, why not just leave it where it is?" I had a conversation with a dBase
programmer many years ago on just these lines and what it came down to was this.

for x = 1 to length(orderitems)
calculate_tax(orderitems[x], .175)
next

(forgive the pseudo code) is easier to read and the intent of the code is much clearer, and also we had 24 * 80 screens and so you could see much more of the 'flow' of the program
than if the code was in lined. Objects just take all that one step further.

order.calculate_tax( .175 )

Why read fifty lines of code to work out that tax is being calculated for each item in the order when you can read one line? How you achieve this is not all that important, functions
or classes only that the flow of the program can be comprehended quickly. Objects don't just make writing code easier but it makes *READING* code easier too, a very important plus
(ever had to maintain APL?)

Almost everything that I write becomes an object even the programs themselves.
Jul 18 '05 #14

P: n/a
Ryan Paul wrote:
On Tue, 25 May 2004 21:20:02 -0400, Roy Smith wrote:

Ryan Paul <se*******@sbcglobal.net> wrote:
defining a class may be useful if you plan on making more instances down
the line. It's a good OO strategy. I do understand your dislike of 'self'.
It does seem like clutter. In my code, I shorten it to 's'.


Please don't do that. While it's true that the first parameter of a
class method can be named anything, the use of "self" is so
overwhelmingly ubiquitous it might as well be a standard. Using
anything else is just going to make your code more difficult for anybody
else to read and understand.

Typing is cheap. Thinking is expensive. And, yes Aahz, you can quote
me on that :-)

I dont conform to a bad standard just because it's a standard. If I did, I
would be using java instead of a dynamic language like python. If other
people dont like it, thats too bad- they dont have to use my code.

It's your code but might I suggest that you then be consistent in your
naming convention to aid re-use?
- Pad.

Jul 18 '05 #15

P: n/a
>>>>> "Ryan" == Ryan Paul <se*******@sbcglobal.net> writes:

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.

--
Ville Vainio http://tinyurl.com/2prnb
Jul 18 '05 #16

P: n/a
Se******@SeeBelow.Nut wrote:
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? It has a disadvantage of a whole lot of
"self."
being required everywhere, making the code less readable. Also, since
a strength of Python is rapid application development, it slows one
down
to have to put in all those self.'s. The code seems much cleaner to
me
without classes that have only one instance. Oh, also, all the
methods of this class will have to have the instance name prepended to
them.

I would appreciate it if someone could explain the advantages of doing
this, or at least the sociological reasons why it occurs.

Mitchell Timin

As a novice Python programmer, I also thought about this question
recently and came up with one other rationale that no one else has
mentioned yet. (If this rationale is wrong, I would value
elucidation.) An instance also retains state whereas a function does
not (because the instance continues to exist). For example, if you
create the function

def assigner():
x = 2

the variable x exists only when test runs. A second function printer()

def printer():
print x

will not print the value assigned to x in assigner. (You get a
traceback because global variable x is not defined.) If you want x to
continue to exist after assigner runs, you must declare it global.
Thus, with

def assigner():
global x
x = 2

printer() will print the value assigned to x in assigner. When assigner
is a method, you can cause x to continue to exist by prepending self.
All variables with self prepended have global scope within the
instance. Thus,

class tester:
def assigner(self):
x = 1
def printer(self):
print x # global variable x not defined
t = tester()
t.assigner()
t.printer()

will not work (for the same reason it does not work with the functions
above), whereas

class tester:
def assigner(self):
self.x = 1
def printer(self):
print self.x # self.x is global within scope of instance
t = tester()
t.assigner()
t.printer()

prints 1.

It works to have a bunch of global variables in a module rather than a
single-instance class, but you may have to be more careful about name
clashes as the code expands. Using a single-instance class provides
another level of control over scope. Thus, you could have more than
one single-instance class in a module each defining its own namespace
whereas the code that lives in the other classes would otherwise have
to go in separate modules to provide the same degree of namespace
isolation. Also, with global declarations, it's hard to tell when you
read the code whether a variable has been declared global, whereas the
"self." prefix essentially announces that the corresponding variable
has been declared to have global scope within the instance.
--
Jeffrey Barish
Jul 18 '05 #17

P: n/a
In article <ro***********************@reader2.panix.com>,
Roy Smith <ro*@panix.com> wrote:

Typing is cheap. Thinking is expensive. And, yes Aahz, you can quote
me on that :-)


Heh. It's in my database now.
--
Aahz (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/

"He's Quebecois. He puts mayonnaise on *everything*." --*******@virulent.org
Jul 18 '05 #18

P: n/a
Peter Hickman wrote:

Se******@SeeBelow.Nut wrote:
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.


This is a lot like putting code in functions. "Its only called in one place, why put it in a function, why not just leave it where it is?" I had a conversation with a dBase
programmer many years ago on just these lines and what it came down to was this.

for x = 1 to length(orderitems)
calculate_tax(orderitems[x], .175)
next

(forgive the pseudo code) is easier to read and the intent of the code is much clearer, and also we had 24 * 80 screens and so you could see much more of the 'flow' of the program
than if the code was in lined. Objects just take all that one step further.

order.calculate_tax( .175 )

Why read fifty lines of code to work out that tax is being calculated for each item in the order when you can read one line? How you achieve this is not all that important, functions
or classes only that the flow of the program can be comprehended quickly.


I see the value of replacing many lines of code by a function
definition, for readability, even if that only happens once. In fact I
regularly do this. But does using a class acheive this better than a
function? It seems to me that a function is simpler and clearer.

m

--
"Many are stubborn in pursuit of the path they have chosen, few in
pursuit of the goal." - Friedrich Nietzsche

http://annevolve.sourceforge.net is what I'm into nowadays.
Humans may write to me at this address: zenguy at shaw dot ca
Jul 18 '05 #19

P: n/a
"Ville Vainio" <vi***@spammers.com> wrote in message
news:du****************@amadeus.cc.tut.fi...
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!


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

$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!

See how much easier the modified text is to read? :-)
Jul 18 '05 #20

P: n/a
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

At 2004-05-26T18:00:29Z, "Andrew Koenig" <ar*@acm.org> writes:
$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+jiM 2eb3udowCeNpJr
O9ca+ZS3J4lFI5gnQKTOOZI=
=NXmP
-----END PGP SIGNATURE-----
Jul 18 '05 #21

P: n/a
Ville Vainio wrote:
>> "Ryan" == Ryan Paul <se*******@sbcglobal.net> writes:


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
Jul 18 '05 #22

P: n/a
>>>>> "Andrew" == Andrew Koenig <ar*@acm.org> writes:

Andrew> "Ville Vainio" <vi***@spammers.com> wrote in message
Andrew> news:du****************@amadeus.cc.tut.fi...
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!


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.

--
Ville Vainio http://tinyurl.com/2prnb
Jul 18 '05 #23

P: n/a
Ville Vainio wrote:
>> "Ryan" == Ryan Paul <se*******@sbcglobal.net> writes:


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

Jul 18 '05 #24

P: n/a
Ville Vainio wrote:
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

--
-------------------------------------------------------------------
Peter Maas, M+R Infosysteme, D-52070 Aachen, Hubert-Wienen-Str. 24
Tel +49-241-93878-0 Fax +49-241-93878-20 eMail pe********@mplusr.de
-------------------------------------------------------------------
Jul 18 '05 #25

P: n/a
>>>>> "Josh" == Josh Gilbert <jg***********************@uvm.edu> writes:
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 http://tinyurl.com/2prnb
Jul 18 '05 #26

P: n/a
>>>>> "Peter" == Peter Maas <pe********@mplusr.de> writes:

Peter> Ville Vainio wrote:
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.


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.

--
Ville Vainio http://tinyurl.com/2prnb
Jul 18 '05 #27

P: n/a
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ville Vainio wrote:
>> "Josh" == Josh Gilbert <jg***********************@uvm.edu> writes:

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)

iD8DBQFAtkX13TWYZBkZ2IsRAiylAJ9oaFGHFoN0aRE8aGWxmy ZIDt2c6ACbBBfB
FG/DVh1ApDQyBvKRQeTW61g=
=7Nwd
-----END PGP SIGNATURE-----
Jul 18 '05 #28

P: n/a
[Se******@SeeBelow.Nut]
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.

--
François Pinard http://www.iro.umontreal.ca/~pinard

Jul 18 '05 #29

P: n/a
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:ti****@stackless.com>
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/
Jul 18 '05 #30

P: n/a
[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.


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! :-)

--
François Pinard http://www.iro.umontreal.ca/~pinard

Jul 18 '05 #31

P: n/a
>>>>> "Josh" == Josh Gilbert <jg***********************@uvm.edu> writes:

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?

--
Ville Vainio http://tinyurl.com/2prnb
Jul 18 '05 #32

P: n/a
Ville Vainio wrote:
>>"Josh" == Josh Gilbert <jg***********************@uvm.edu> writes:

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.
Jul 18 '05 #33

P: n/a
>>>>> "Josh" == Josh Gilbert <jg*************@uvm.edu> writes:
But isn't IPython solely for interactive use?


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.

--
Ville Vainio http://tinyurl.com/2prnb
Jul 18 '05 #34

P: n/a
In article <c9************@swen.emba.uvm.edu>,
Josh Gilbert <jg*************@uvm.edu> wrote:
Ville Vainio wrote:

Jul 18 '05 #35

This discussion thread is closed

Replies have been disabled for this discussion.