Typed Python?

  • Thread starter Thomas Reichelt
  • Start date
?

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

[Ville Vainio]
[François Pinard]
Suddenly backtracking out of a complex involvement for restarting
in a new direction, for the above project at least, requires a lot
of state resumption, and doing this cleanly in Python implies a
rather strict and burdening discipline about where and how the state
information is kept.
Would such a problem be solvable if you could pickle a "running"
generator?

Not really. Generators could be used in chains (of generators), each
element of the chain usually being some local variable in another
element, and pickling one is meaningless if you cannot pickle them
all. Moreover, the serialisation implied by pickling would usually be
extraneous and unwanted overhead to the whole process of saving and
restoring generator state.
So, is there some deep philosophical (as opposed to implementation
detail) flaw in the picklable generator idea?

I'm not a deep philosopher, so I cannot say! :)
 
?

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

[Christopher T King]
[François Pinard]
Suddenly backtracking out of a complex involvement for restarting
in a new direction, for the above project at least, requires a lot
of state resumption, and doing this cleanly in Python implies a
rather strict and burdening discipline about where and how the state
information is kept. While tractable, this is not as comfortable as
I would have liked it...
It may be possible to do what you want to do using only generators.
continuation=dostuff()
try:
value=continuation.next()
except StopIteration:
<store continuation away for future use>
else:
<function completed, carry on>

If the generator gets exhausted, what would be the purpose of saving it?

I would presume chained generators might ease control of the flow, at
least to a certain extent, but would not help so much for complex state
resumption, especially when state is shared between parts of the program.
Dunno if this helps or not....

Thinking always help! Thanks for sharing your thoughts.
 
C

Christopher T King

[Christopher T King]
It may be possible to do what you want to do using only generators.
continuation=dostuff()
try:
value=continuation.next()
except StopIteration:
<store continuation away for future use>
else:
<function completed, carry on>

If the generator gets exhausted, what would be the purpose of saving it?

Oops, I got that backwards. It should read:

continuation=dostuff()
try:
value=continuation.next()
except StopIteration:
<function completed, carry on>
else:
said:
I would presume chained generators might ease control of the flow, at
least to a certain extent, but would not help so much for complex state
resumption, especially when state is shared between parts of the program.

And hence the need for continuations ;) Perhaps if there was a way to
resume code that was interrupted by an exception?
 
M

Michele Simionato

Siegfried Gonzi said:
I am not an expert in CLOS programming. But what are the disadvantages of not having a meta-object protocol? What
is hard to realize then?

This is the kind of questions which would require a book for
even a partial answer :-( In the Lisp world there is "The Art of
the Metaobject Protocol", in the C++ world there is "Putting Metaclasses
to Work", in the Java world there are various books on AOP (anyway
the MOP is not the same as AOP: the MOP is a general framework which
you can use to implemente Aspect Oriented Programming. Metaclasses and
metaobject protocol are essentially the same thing).

I feel the standard answer you get in this case (the MOP is for the ones
who knows why it is useful, if you don't, forget about it) to be a little
frustrating but it is rather difficult to come up with a better answer.

So, what I will do, is to give you an example of the last case where I
used Python metaclasses in a real life application. You will deduce for
yourself if you are missing something useful or not.

My use case was hacking PloneTestCase, the Plone testing framework to
avoid startup times. What I did was to implement a command line
interpreter to execute my tests, reload modules, and similar things.

Python has a beatiful facility for writing command line interpreters,
the "cmd" module in the standard library. You just derive the
cmd.Cmd class and write your commands as methods starting with "do_":

do_this(self, arg), do_that(self, arg)

I had only few commands, it was useful for me to have one-letter aliases:
this means to generate an alias for each method starting with "do_".
You can do that with a function applied to the class, without the MOP.
However, if I subclass later my custom command class, I would like to maintain
the automatic alias feature (this feature has only meaning if I have
less than 26+26 commands of course, otherwise there will be conflicts
so it is not a scalable solution, but this was a quick & dirty hack,
not a masterpiece of software). In order to preserve the feature under
inheritance, you need a metaclass. Here is the solution:

# cmd_with_aliases.py
import cmd

class make_oneletter_aliases_for_commands(type):
"""Typically used in Cmd classes."""
def __init__(cls, name, bases, dic):
for name,func in dic.iteritems():
if name.startswith("do_"):
firstletter = name[3]
setattr(cls, "do_" + firstletter, func)

class Cmd(cmd.Cmd, object): # make it a new-style class
__metaclass__ = make_oneletter_aliases_for_commands
def preloop(self):
"""Done once at the beginning."""
cmd.Cmd.preloop(self)
self.do_greetings("World!")

def do_greetings(self, arg):
"""Display a greeting message."""
print "Hello, %s!" % arg

def do_help(self, arg):
"""Print this help message."""
super(Cmd, self).do_help(arg)

def do_quit(self,arg):
"""Exit the command-loop."""
return 'quit' # anything != None will do

Cmd().cmdloop()


Here is the usage:

~/md/python/Various $ python cmd_with_aliases.py
Hello, World!!
(Cmd) help

Documented commands (type help <topic>):
========================================
g greetings h help q quit

(Cmd) h

Documented commands (type help <topic>):
========================================
g greetings h help q quit

(Cmd) greetings Michele
Hello, Michele!
(Cmd) q
~/md/python/Various $

As you see g,h and q are aliases for greeting, help and quit.
"help greetings" or "help g" or "h greetings" or "h g" all work:

(Cmd) h g
Display a greeting message.
(Cmd) h greetings
Display a greeting message.
(Cmd) help greetings
Display a greeting message.

For me the metaclass solution was the simplest and easier solution
for this job.

I have written a couple of papers on metaclasses in Python that you may
find easily (look at the Python Wiki for instance) and more justifications
for the MOP are given. I mostly use it for hacks concerning testing and
debugging. If I was a framework builder I would have a better use for
it. If I was writing numerical code I would probably not miss it
(I mean, Fortran is not even OO but works pretty well for numerical
tasks). MOP is good if you are writing code for others to use
(for instance if you are writing a command line interpreter as in
this example). As another example, I used metaclasses and descriptors to
hack Python object model in a prototype based one, as a proof of
concept. You can do any kind of fearful hacks (google this newsgroup
for metaclasses). There is really a *lot* you can do. But in 99.9%
of my real life programming I have no use for the MOP.

So, it is up to you to decide if is something worthy or not to learn.


Michele Simionato
 
S

Siegfried Gonzi

So, it is up to you to decide if is something worthy or not to learn.

I posted ("Bigloo and the lack of a MOP") some questions on comp.lang.scheme because I do not grasp why one would
implement an object system without a perceived valuable meta object protocol.

I mean what are the motivations behind such adventures. I found a thread on google where they say that not having a
meta object protocol is simply a matter of style and preference and one can realize all such things with MERON too.

Fensterbrett
 
B

beliavsky

(I mean, Fortran is not even OO but works pretty well for numerical
tasks).

As of the 2003 standard, Fortran supports OOP, including inheritance.
The NAG Fortran compiler is not a full F2003 compiler, but it has the
OOP features -- see http://www.nag.co.uk/nagware/NP/NP50_announcement.asp
..

Fortran 95 supports object-based programming -- there is no
inheritance, but you can define data types with public and private
members, and these data types can be used as procedure arguments.

But I agree with your main point -- you can write good numerical
software in Fortran without OO.
 
J

Jacek Generowicz

Siegfried Gonzi said:
I am not an expert in CLOS programming. But what are the
disadvantages of not having a meta-object protocol?

What you're asking is "What is the point of a meta-object protocol?".

The point of a meta-object protocol is to make your object system
programmable; to be able to tune your object system to the needs of
your application.
What is hard to realize then?

.... tuning the behaviour of your object system, adapting your object
system to the requirements of your program.
 
M

Michele Simionato

As of the 2003 standard, Fortran supports OOP, including inheritance.
The NAG Fortran compiler is not a full F2003 compiler, but it has the
OOP features -- see http://www.nag.co.uk/nagware/NP/NP50_announcement.asp
.

Fortran 95 supports object-based programming -- there is no
inheritance, but you can define data types with public and private
members, and these data types can be used as procedure arguments.

But I agree with your main point -- you can write good numerical
software in Fortran without OO.

Thank you for your clarification and for the link. I was aware of Fortran 2003
(thanks to another post of yours some time ago ;) but as you guessed my
main point was that you can do a lot of good work without needing an
object system. Personally, I am not OO bigot and I have no problem in
using non-OO languages. Actually, I have a lot of Python code which is
not OO, because I feel OO constraining or too verbose for many tasks,
whereas invaluable for other tasks (in particular, programming in a
corporate environment).

Coming back to the original poster, I don't think that Bigloo object
system is crippled because it lacks a MOP: but in that period of time
I wanted to learn CLOS and not Meroon, so I did not consider Bigloo
further. That's all.

A MOP gives you more power but also makes your code more magical
and more difficult to debug, so take in account this fact in when
deciding if using a MOP or not.


Michele Simionato
 
J

Jacek Generowicz

[Siegfried Gonzi on Tue, 13 Jul 2004 at 10:31:22]
what are the disadvantages of not having a meta-object protocol?
What is hard to realize then?

[Siegfried Gonzi on Wed, 14 Jul 2004 at 15:48:15]
I do not grasp why one would implement an object system without a
perceived valuable meta object protocol.

You appear to have gone from not seeinig the point of a MOP, to not
seeing why one would implement an object system without one, in under
29 hours, 16 minutes and 53 seconds. Must be some sort of world
record. (Mechele's answer must have made a huge impression on you.)

You like going from extreme to extreme, don't you :)

[Siegfried Gonzi]
I posted ("Bigloo and the lack of a MOP") some questions on
comp.lang.scheme because I do not grasp why one would implement an
object system without a perceived valuable meta object protocol.

Why pick on Scheme?... you should post the same questions on
newsgroups talking about C++, Java ... the vast majority of languages
supporting OO languages on earth, in fact ... of which Scheme is not
really one, as all OO support in Scheme is via implementation specific
language extensions.

All in all, a pretty poor choice of newsgroup ... well, at least you
didn't post it on rec.sport.korfball :) (Or alt.cleaning-utensils.mop)
I mean what are the motivations behind such adventures.

Yes, I do wonder (your usenet adventures, that is).
 
S

Siegfried Gonzi

Jacek said:
You appear to have gone from not seeinig the point of a MOP, to not
seeing why one would implement an object system without one, in under
29 hours, 16 minutes and 53 seconds. Must be some sort of world
record. (Mechele's answer must have made a huge impression on you.)

You know the sentence is not meant as you read it. Why do you insist that
I personally "perceive" a MOP valuable?
Why pick on Scheme?...

Why not?
you should post the same questions on
newsgroups talking about C++, Java ...

You got me. I think my posts are not that much entertaining than yours.
 
S

Siegfried Gonzi

Michele said:
Coming back to the original poster, I don't think that Bigloo object
system is crippled because it lacks a MOP: but in that period of time
I wanted to learn CLOS and not Meroon, so I did not consider Bigloo
further. That's all.

Hi:

Pascal C. made some interesting remarks to my post on comp.lang.scheme.

I do not object the usefullness of a MOP. I was more after the connection between MOP and Bigloo. And the appropiate usegroup
for this quest might be comp.lang.scheme.
 
J

Jacek Generowicz

Siegfried Gonzi said:
You know the sentence is not meant as you read it.

I admit that I sometimes deliberately interpret things in a way which
they were not originally intended. However, I am not doing it in this
case.
Why do you insist that I personally "perceive" a MOP valuable?

I do not insist; I implied it just once.

I implied it, because that is what I inferred from your choice of
words. My interpretation could well be wrong.

Because Scheme is irrelevant to the question you seem to be asking
.... but I appear not to be able to interpret your words correctly, so
Scheme may well be central to the issue for all I know.

Because "picking" on languages and posting provocative articles in the
languages' newsgroups wastes a lot of people's time. I guess you do it
inadvertently, but you do seem to do it rather a lot (all based on
recollections of posts I associate with you across various NGs over
some period of time; I may be misremembering: if so, I
apologize. Also, it is likely that your most memorable threads are the
ones that stick in my memory ... so I'm likely to have a lop-sided
recollection of your posts).

[Googling ...]

Your opening shot in the c.l.scheme thread you started is:

Someone explained to me on comp.lang.python that Bigloo its object
system is crippled due to its lack of a meta object protocol.

You really know how to put the reader in the right mood for reading
the rest of your post. Fortunately enough, you distance yourself
sufficiently from the negative implications of your opening shot,
later on in the article.

But this is turning into an ad-hominem subthread (and I set us off on
that course, so I apologize) ... so let's not continue in that
direction.

I should have said: "Your question isn't really relevant to Scheme"
and left it at that.
 
S

Siegfried Gonzi

Jacek said:
I should have said: "Your question isn't really relevant to Scheme"
and left it at that.

a) Yes it is not essentially related to Scheme. You are right, but:

b) However, it is related to Bigloo and MEROON. Do you know any Java
programmers who knows MEROON.

My interest actually was: Bigloo and its connection to this MOP stuff. And
to my knowledge Bigloo is Scheme.

I am not expecting that they will explain me MOP on comp.lang.scheme. But I
hoped to get some hints why Bigloo or MEROON is as it actually is.

Peace.
 
J

Jacek Generowicz

Siegfried Gonzi said:
a) Yes it is not essentially related to Scheme. You are right, but:

b) However, it is related to Bigloo and MEROON. Do you know any Java
programmers who knows MEROON.

No, but that's because I try to avoid knowing Java programmers :)
My interest actually was: Bigloo and its connection to this MOP stuff. And
to my knowledge Bigloo is Scheme.

Bigloo is Bigloo. OK, Bigloo contains most of Scheme within it ... but
its additions are NOT scheme, and it's object system is an addition.

OTOH, given that Scheme has no object system, and yet, most
implementations do have one, it is probably of general interest on
c.l.s.

But this thread has made me aware of Meroon, and that

- it is ported to many Schemes (including Bigloo, so Bigloo's object
system not having a MOP becomes a non-issue)

- it has CLOS-like generic functions

- it has a MOP

.... which (if the blurb is to be believed) makes Scheme altogether
more interesting for me ... and I might just consider it in future
projects ...

.... so I thank you for making me aware of Meroon.
 
M

Michele Simionato

Jacek Generowicz said:
OTOH, given that Scheme has no object system, and yet, most
implementations do have one, it is probably of general interest on
c.l.s.

It would be more correct to say that Scheme has no *standard* object
system, so most implementations provide *more* than just one object
system.

For instance MzScheme has his own (non-remarkable IMHO) object system
(actually two versions of it) and Swindle (which is essentially CLOS);
Chicken has both TinyClos and Meroon, idem for Guile. I don't know about
the other hundreds Scheme implementations, but from here

http://www.call-with-current-continuation.org/eggs/meroon.html

I gather the following info:
"""
MeroonV3 is an object system written in Scheme that works
under Bigloo, Elk, Gambit, Guile, MacScheme, MIT-Scheme,
OScheme, PC Scheme, PCS/geneva, Scheme->C, SCM and vscm
interpreters. It also runs faster when compiled with
Bigloo, Gambit and Scheme->C, see below.

<snip>
"""
But this thread has made me aware of Meroon, and that

- it is ported to many Schemes (including Bigloo, so Bigloo's object
system not having a MOP becomes a non-issue)

- it has CLOS-like generic functions

- it has a MOP

... which (if the blurb is to be believed) makes Scheme altogether
more interesting for me ... and I might just consider it in future
projects ...

... so I thank you for making me aware of Meroon.

Yes, I got curious and I would like to look at it too, if I had the time!


Michele Simionato
 
J

Jacek Generowicz

Yes, I got curious and I would like to look at it too, if I had the time!

Indeed ... I desperately need to find the time to go down to the time
shop and some time for doing all these things :)
 
C

chain_lube

Jacek Generowicz said:
... which (if the blurb is to be believed) makes Scheme altogether
more interesting for me ... and I might just consider it in future
projects ...

The following link to comp.lang.scheme/slashdot has nothing to do with
Python whatsoever. But I think it will finalize the discussions and
the thread about pattern matching and the object system and its
usefullness in real life projects:

http://groups.google.com/groups?dq=...rev=/groups?q=comp.lang.scheme&ie=UTF-8&hl=en

Fensterbrett
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,755
Messages
2,569,536
Members
45,009
Latest member
GidgetGamb

Latest Threads

Top