Prothon, metaclasses, Zope [Was: A 'Python like' language]

[Michele Simionato]

> Hello, my name is Skip and I am metaclass-unaware. I've been programming in

Python for about ten years and I have yet to write a metaclass. At first I
thought it was just that metaclasses were new to the language, but now as
more and more people use them and proclaim their widespread benefits, I have
come to realize that through years of abuse my brain has become addicted to
classic classes.

I began using Python since version 2.2.1 and without knowing anything
about OOP, so I had the advantage of a fresh start ;) Still, I will readily
admit that I was not immediately sold to metaclasses and actually I was
kind of skeptical about them. The "Putting metaclasses to work" book
made me change my mind. At this point I have becomed so accustomed to
metaclasses that I am disturbed when I cannot use them.

Just a real life example. I started studying Zope few days ago.
Writing my first class I got caught since I was overriding a predefined Zope
method. I made a dir() and discovered that the context object in Zope
has more than four hundreds (400!) attributes. In such a situation it
is likely to override a predefined name, especially now that I am a
beginner and I have a fair chance of reimplementing (badly) something
which is already available. So, I thought: "well, this a job for a metaclass"
and in five minutes I implemented a metaclass raising an error if I was
inadvertently overriding a predefined name (except names such as __init__
and similia, of course). Everything was nice and good until the moment
I tested the metaclass on a Zope class and got a segmentation fault.

Since I don't know anything about Zope internals I can only make a guess
of what happened and I would be happy if some Zope guru here could
confirm (possibly educated) guess.

In my understanding, Zope tweaked Python classes at C level code, introducing
the concept of Extension classes. Extension classes are instances of a C coded
metaclass which does a lot of magic (for instance there are methods which
are automatically generated each time I create an extensions class);
unfortunately, this metaclass does not follow the protocol of Python 2.2+
metaclasses. This is evidently an historical accident, since Zope Extension
Classes were invented before Python 2.2[*]; the net result is that I cannot
mix Python classes with custom metaclasses and Zope Extension classes.

I have heard that this is a temporary wart and that Zope 3 will solve
this issue (I'd like to have a confirmation here). However, for the
moment, I had to come out with a non-metaclass solution.

So, I reverted my mind to the pre-metaclass functioning mode (which required
a certain effort) and I wrote a function that takes a class, looks at
its dictionary, and raises an error if the class overrides an attribute
which is already defined in the parent classes. The solution works,
but it is kind of ugly compared to the metaclass solution:

1. The metaclass can raise the error *before* the metaclass is created,
whereas the function works a posteriori, *after* the overriding is done;
if find it to be conceptually unsatisfactory, I don't want to create
a class just to throw it away. The alternative is to use a class factory,
but then I have just re-invented a metaclass with an ugly call syntax.

2. The metaclass can be inherited, so the check is automatic for all children;
on the contrary, I have to call the function by hand each time I define
a new class. This means writing twice the class name, which is error
prone if I later rename the class and I forget to update the function
call.

Whereas it is true that in most cases you can find a non-metaclass solution,
it is also true that in most case the metaclass solution is by far more
elegant than the alternative.

BTW, I wonder how Prothon would solve this problem, i.e. selectively
forbidding the overriding of names, with an easy of use/elegance
comparable to the Python metaclass solution.

Michele Simionato

[*] I would be curious to know if Guido decided to expose metaclasses in
Python since he noticed that they were already being used in real applications
such as Zope (in some hidden form), or if there was some other reason.

[Joe Mason]

In article <95**************************@posting.google.com >, Michele Simionato wrote:

1. The metaclass can raise the error *before* the metaclass is created,
whereas the function works a posteriori, *after* the overriding is done;
if find it to be conceptually unsatisfactory, I don't want to create
a class just to throw it away. The alternative is to use a class factory,
but then I have just re-invented a metaclass with an ugly call syntax.
In this case, you shouldn't worry about that, since presumably you're
just using it during development so it'll never be called anyway in the
release version.
2. The metaclass can be inherited, so the check is automatic for all children;
on the contrary, I have to call the function by hand each time I define
a new class. This means writing twice the class name, which is error
prone if I later rename the class and I forget to update the function
call.
You could just put the function call in your base class's __init__
method. (Or, in fact, put the code from that call directly there, if
you only care when you inherit from the one Zope class.)
BTW, I wonder how Prothon would solve this problem, i.e. selectively
forbidding the overriding of names, with an easy of use/elegance
comparable to the Python metaclass solution.
__init__ method, I believe. But I just realized something - how does
Prothon (or prototyped languages in general) handle multiple
inheritance or mixins?
[*] I would be curious to know if Guido decided to expose metaclasses in
Python since he noticed that they were already being used in real applications
such as Zope (in some hidden form), or if there was some other reason.

http://www.python.org/2.2/descrintro.html#metaclasses has some
references you might find interesting.

Joe

[Michele Simionato]

Joe Mason <jo*@notcharles.ca> wrote in message news:<sl****************@gate.notcharles.ca>...

You could just put the function call in your base class's __init__
method. (Or, in fact, put the code from that call directly there, if
you only care when you inherit from the one Zope class.)

Uh? The base class __init__ method is not called when I derive a new
class. I want to make the make the check at class level, *before*
instantiating.

Michele Simionato

[Joe Mason]

In article <95**************************@posting.google.com >, Michele Simionato wrote:

Joe Mason <jo*@notcharles.ca> wrote in message news:<sl****************@gate.notcharles.ca>...

You could just put the function call in your base class's __init__
method. (Or, in fact, put the code from that call directly there, if
you only care when you inherit from the one Zope class.)

Uh? The base class __init__ method is not called when I derive a new
class. I want to make the make the check at class level, *before*
instantiating.

It is if you call the inherited __init__ method, which you should be
doing because it probably does important stuff.

Why do you care whether it checks before instantiating the class, or
instantiates the class and then throws an error during __init__? It's
not going to make any speed or memory difference to the successful case,
which is all you care about for performance.

Joe

[Terry Reedy]

"Joe Mason" <jo*@notcharles.ca> wrote in message
news:sl****************@gate.notcharles.ca...

In article <95**************************@posting.google.com >, Michele Simionato wrote:

Joe Mason <jo*@notcharles.ca> wrote in message news:<sl****************@gate.notcharles.ca>...

You could just put the function call in your base class's __init__
method. (Or, in fact, put the code from that call directly there, if
you only care when you inherit from the one Zope class.)

Uh? The base class __init__ method is not called when I derive a new
class. I want to make the make the check at class level, *before*
instantiating.

It is if you call the inherited __init__ method, which you should be
doing because it probably does important stuff.

?? The derived class __init__ is not called until the first instance is
created, which might be way later or even never in any particular run of
the program. It does *not* check '*before* instantiating' as M.S. sensibly
wants.
Why do you care whether it checks before instantiating the class, or
instantiates the class and then throws an error during __init__? It's
not going to make any speed or memory difference to the successful case,
which is all you care about for performance.

The derived class is created just once. __init__ is called for every
instance, which could be a large number.

Terry J. Reedy

[Mark Hahn]

> how does Prothon (or prototyped languages in general) handle multiple
inheritance or mixins?

There is no difference. Prothon just has multiple protoypes with all the
normal problems (like the diamond problem) and the normal solutions.

Self defines having the same attribute in two different prototypes illegal.
That seemed extremely constraining to me so I went with the Python 2.2 mro
solution in Prothon.

"Joe Mason" <jo*@notcharles.ca> wrote in message
news:sl****************@gate.notcharles.ca...

In article <95**************************@posting.google.com >, Michele Simionato wrote:

1. The metaclass can raise the error *before* the metaclass is created,
whereas the function works a posteriori, *after* the overriding is done; if find it to be conceptually unsatisfactory, I don't want to create
a class just to throw it away. The alternative is to use a class factory, but then I have just re-invented a metaclass with an ugly call syntax.
In this case, you shouldn't worry about that, since presumably you're
just using it during development so it'll never be called anyway in the
release version.

2. The metaclass can be inherited, so the check is automatic for all

children; on the contrary, I have to call the function by hand each time I define a new class. This means writing twice the class name, which is error
prone if I later rename the class and I forget to update the function
call.

You could just put the function call in your base class's __init__
method. (Or, in fact, put the code from that call directly there, if
you only care when you inherit from the one Zope class.)

BTW, I wonder how Prothon would solve this problem, i.e. selectively
forbidding the overriding of names, with an easy of use/elegance
comparable to the Python metaclass solution.

__init__ method, I believe. But I just realized something - how does
Prothon (or prototyped languages in general) handle multiple
inheritance or mixins?

[*] I would be curious to know if Guido decided to expose metaclasses in
Python since he noticed that they were already being used in real applications such as Zope (in some hidden form), or if there was some other reason.

http://www.python.org/2.2/descrintro.html#metaclasses has some
references you might find interesting.

Joe

[Mark Hahn]

> BTW, I wonder how Prothon would solve this problem

Me too. I'll have to take a stab at it.

Mark Hahn (Prothon author daring to raise his head in the Python forum).

"Michele Simionato" <mi***************@poste.it> wrote in message
news:95**************************@posting.google.c om...

Hello, my name is Skip and I am metaclass-unaware. I've been programming in Python for about ten years and I have yet to write a metaclass. At first I thought it was just that metaclasses were new to the language, but now as more and more people use them and proclaim their widespread benefits, I have come to realize that through years of abuse my brain has become addicted to classic classes.
I began using Python since version 2.2.1 and without knowing anything
about OOP, so I had the advantage of a fresh start ;) Still, I will

readily admit that I was not immediately sold to metaclasses and actually I was
kind of skeptical about them. The "Putting metaclasses to work" book
made me change my mind. At this point I have becomed so accustomed to
metaclasses that I am disturbed when I cannot use them.

Just a real life example. I started studying Zope few days ago.
Writing my first class I got caught since I was overriding a predefined Zope method. I made a dir() and discovered that the context object in Zope
has more than four hundreds (400!) attributes. In such a situation it
is likely to override a predefined name, especially now that I am a
beginner and I have a fair chance of reimplementing (badly) something
which is already available. So, I thought: "well, this a job for a metaclass" and in five minutes I implemented a metaclass raising an error if I was
inadvertently overriding a predefined name (except names such as __init__
and similia, of course). Everything was nice and good until the moment
I tested the metaclass on a Zope class and got a segmentation fault.

Since I don't know anything about Zope internals I can only make a guess
of what happened and I would be happy if some Zope guru here could
confirm (possibly educated) guess.

In my understanding, Zope tweaked Python classes at C level code, introducing the concept of Extension classes. Extension classes are instances of a C coded metaclass which does a lot of magic (for instance there are methods which
are automatically generated each time I create an extensions class);
unfortunately, this metaclass does not follow the protocol of Python 2.2+
metaclasses. This is evidently an historical accident, since Zope Extension Classes were invented before Python 2.2[*]; the net result is that I cannot mix Python classes with custom metaclasses and Zope Extension classes.

I have heard that this is a temporary wart and that Zope 3 will solve
this issue (I'd like to have a confirmation here). However, for the
moment, I had to come out with a non-metaclass solution.

So, I reverted my mind to the pre-metaclass functioning mode (which required a certain effort) and I wrote a function that takes a class, looks at
its dictionary, and raises an error if the class overrides an attribute
which is already defined in the parent classes. The solution works,
but it is kind of ugly compared to the metaclass solution:

1. The metaclass can raise the error *before* the metaclass is created,
whereas the function works a posteriori, *after* the overriding is done; if find it to be conceptually unsatisfactory, I don't want to create
a class just to throw it away. The alternative is to use a class factory, but then I have just re-invented a metaclass with an ugly call syntax.

2. The metaclass can be inherited, so the check is automatic for all children; on the contrary, I have to call the function by hand each time I define
a new class. This means writing twice the class name, which is error
prone if I later rename the class and I forget to update the function
call.

Whereas it is true that in most cases you can find a non-metaclass solution, it is also true that in most case the metaclass solution is by far more
elegant than the alternative.

BTW, I wonder how Prothon would solve this problem, i.e. selectively
forbidding the overriding of names, with an easy of use/elegance
comparable to the Python metaclass solution.

Michele Simionato
[*] I would be curious to know if Guido decided to expose metaclasses in
Python since he noticed that they were already being used in real applications such as Zope (in some hidden form), or if there was some other reason.

[Joe Mason]

In article <ma*************************************@python.or g>, Terry Reedy wrote:

?? The derived class __init__ is not called until the first instance is
created, which might be way later or even never in any particular run of
the program. It does *not* check '*before* instantiating' as M.S. sensibly
wants.

You're right, I was misreading the whole time.

Joe

[Greg Ewing (using news.cis.dfn.de)]

Joe Mason wrote:

In article <95**************************@posting.google.com >, Michele Simionato wrote:

Uh? The base class __init__ method is not called when I derive a new
class. I want to make the make the check at class level, *before*
instantiating.

It is if you call the inherited __init__ method, which you should be
doing because it probably does important stuff.

But presumably he wants the check done only once, when a subclass
is defined, *not* every time said subclass is instantiated. In
Prothon it appears that both of these end up invoking the same
__init__ method, so there's no way of telling them apart.

--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand
http://www.cosc.canterbury.ac.nz/~greg

[Mark Hahn]

> But presumably he wants the check done only once, when a subclass is
defined, *not* every time said subclass is instantiated.

You can have a different __init__ for an object and it's prototpe.So the
Prothon equivalent of a subclass can easily have different __init__
behaviour than it's child (what you call instance). You need to unthink
classes when designing in Prothon. If you try to move a problem from Python
to Prothon and think in the same classes/subclasses metaphors you won't get
very far.

Mark Hahn (Prothon Author)

"Greg Ewing (using news.cis.dfn.de)" <ie*******@sneakemail.com> wrote in
message news:c4*************@ID-169208.news.uni-berlin.de...

Joe Mason wrote:

In article <95**************************@posting.google.com >, Michele Simionato wrote:

Uh? The base class __init__ method is not called when I derive a new
class. I want to make the make the check at class level, *before*
instantiating.

It is if you call the inherited __init__ method, which you should be
doing because it probably does important stuff.

But presumably he wants the check done only once, when a subclass
is defined, *not* every time said subclass is instantiated. In
Prothon it appears that both of these end up invoking the same
__init__ method, so there's no way of telling them apart.

--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand
http://www.cosc.canterbury.ac.nz/~greg

[Roberto Lupi]

In article <95**************************@posting.google.com >,

So, I reverted my mind to the pre-metaclass functioning mode (which required
a certain effort) and I wrote a function that takes a class, looks at
its dictionary, and raises an error if the class overrides an attribute
which is already defined in the parent classes. The solution works,
but it is kind of ugly compared to the metaclass solution:

1. The metaclass can raise the error *before* the metaclass is created,
whereas the function works a posteriori, *after* the overriding is done;
if find it to be conceptually unsatisfactory, I don't want to create
a class just to throw it away. The alternative is to use a class factory,
but then I have just re-invented a metaclass with an ugly call syntax.
I would add the check to a test case for the class.

class XYZTestCase(ZopeTestCase):
tested_class = XYZ

def testOverriddenMethods(self):
check_if_we_are_overriding_names_in(self.tested_cl ass)
2. The metaclass can be inherited, so the check is automatic for all children;
on the contrary, I have to call the function by hand each time I define
a new class. This means writing twice the class name, which is error
prone if I later rename the class and I forget to update the function
call.

Test cases can be inherited.

class XYZ2TestCase(XYZTestCase):
tested_class = XYZ2

--
Roberto Lupi

[Greg Ewing (using news.cis.dfn.de)]

Mark Hahn wrote:

But presumably he wants the check done only once, when a subclass is
defined, *not* every time said subclass is instantiated.

You can have a different __init__ for an object and it's prototpe.So the
Prothon equivalent of a subclass can easily have different __init__
behaviour than it's child (what you call instance).

Can you post some code illustrating how you would do this
in Prothon? I still can't see how, at the point where you
do

X = Base()

anything can tell whether you're intending to use X as
an instance of Base or whether you're going to go on to
say

with X:
def ...

and use X as a prototype which inherits behaviour from
Base. In both cases, Base.__init__ is going to get invoked
before you have a chance to define any other __init__ that
might override it.

--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand
http://www.cosc.canterbury.ac.nz/~greg

[Mark Hahn]

Greg: Just a quick note to let you know that I do intend to reply to this
but haven't had the time.

Greg Ewing (using news.cis.dfn.de) wrote:

Mark Hahn wrote:

But presumably he wants the check done only once, when a subclass is
defined, *not* every time said subclass is instantiated.

You can have a different __init__ for an object and it's prototpe.So
the Prothon equivalent of a subclass can easily have different
__init__ behaviour than it's child (what you call instance).

Can you post some code illustrating how you would do this
in Prothon? I still can't see how, at the point where you
do

X = Base()

anything can tell whether you're intending to use X as
an instance of Base or whether you're going to go on to
say

with X:
def ...

and use X as a prototype which inherits behaviour from
Base. In both cases, Base.__init__ is going to get invoked
before you have a chance to define any other __init__ that
might override it.

[Aahz]

In article <eAF9c.48978$cx5.17895@fed1read04>,
Mark Hahn <ma**@prothon.org> wrote:

Self defines having the same attribute in two different prototypes
illegal. That seemed extremely constraining to me so I went with the
Python 2.2 mro solution in Prothon.

Bad idea. But I won't tell you why until you stop top-posting and
over-quoting.
--
Aahz (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/

"usenet imitates usenet" --Darkhawk

[Mark Hahn]

Does anyone get anything done around here with all the bitching? I've been
communicating via email for 30 years and never have I seen such complaining
about something so silly. If you have anything to contribute to Prothon
I'll be over in the Prothon lists. We are too busy creating to have
conversations like this over there.

You may not be able to tell it, but I'm a nice guy who would really like
feedback from intelligent knowledgable people like yourself. I just can't
take this anymore.

Aahz wrote:

In article <eAF9c.48978$cx5.17895@fed1read04>,
Mark Hahn <ma**@prothon.org> wrote:

Self defines having the same attribute in two different prototypes
illegal. That seemed extremely constraining to me so I went with the
Python 2.2 mro solution in Prothon.

Bad idea. But I won't tell you why until you stop top-posting and
over-quoting.

[Mark Hahn]

"Greg Ewing (using news.cis.dfn.de)" <ie*******@sneakemail.com> wrote in
message news:c4*************@ID-169208.news.uni-berlin.de...

Mark Hahn wrote:

But presumably he wants the check done only once, when a subclass is
defined, *not* every time said subclass is instantiated.
You can have a different __init__ for an object and it's prototpe.So the
Prothon equivalent of a subclass can easily have different __init__
behaviour than it's child (what you call instance).

Can you post some code illustrating how you would do this
in Prothon? I still can't see how, at the point where you
do

X = Base()

anything can tell whether you're intending to use X as
an instance of Base or whether you're going to go on to
say

with X:
def ...

and use X as a prototype which inherits behaviour from
Base. In both cases, Base.__init__ is going to get invoked
before you have a chance to define any other __init__ that
might override it.

You don't have to use the obj = proto() technique to create an object. The
following code is identical to saying subproto = topproto() except no
__init__() will be called:

subproto = Object()
subproto.set_proto(topproto) # switch prototype on the fly

Does this give you the missing piece you need or is there something else
missing in Prothon? If you explain the overall goal better I'll write the
complete code for you.

--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand
http://www.cosc.canterbury.ac.nz/~greg

[Michele Simionato]

"Mark Hahn" <ma**@prothon.org> wrote in message news:<S7Lac.87628$cx5.10253@fed1read04>...

Original top posting maintained on purpose:

Does anyone get anything done around here with all the bitching? I've been
communicating via email for 30 years and never have I seen such complaining
about something so silly. If you have anything to contribute to Prothon
I'll be over in the Prothon lists. We are too busy creating to have
conversations like this over there.

You may not be able to tell it, but I'm a nice guy who would really like
feedback from intelligent knowledgable people like yourself. I just can't
take this anymore.

Aahz wrote:

In article <eAF9c.48978$cx5.17895@fed1read04>,
Mark Hahn <ma**@prothon.org> wrote:

Self defines having the same attribute in two different prototypes
illegal. That seemed extremely constraining to me so I went with the
Python 2.2 mro solution in Prothon.

Bad idea. But I won't tell you why until you stop top-posting and
over-quoting.

Aahz is probably referring to the fact that Python 2.3 has changed the
MRO since the 2.2 one was a bad idea. See
http://www.python.org/2.3/mro.html
for more. A part for this, Aahz is right in pointing out that you
cannot get
the attention of a lot of intelligent knowledgable people on c.l.py
because
of your postings habits. Actually this is the reason why I have
downloaded Prothon yet. It is kinda of a pity, since maybe the idea is
worth, but it is difficult to give credit to people liking tabs and
top posting. Those are not
stupid things IMNSHO.

Michele Simionato

[Aahz]

In article <95**************************@posting.google.com >,
Michele Simionato <mi***************@poste.it> wrote:

[...]

Michele, I just got a mailbox full error when I tried sending you
e-mail. Please fix.
--
Aahz (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/

"usenet imitates usenet" --Darkhawk

[Mark Hahn]

> it is difficult to give credit to people liking tabs and

top posting.
Even though I admit to the heinous crime being a "tab-lover", we have
changed Prothon to accept either tabs or spaces in indents, just not both in
the same file.

As far as top-posting, I am trying to improve, it's just hard to change my
reply style after using it for 30 years without getting any complaints
before. I feel like I'm in a twilight-zone episode.

"Michele Simionato" <mi***************@poste.it> wrote in message
news:95**************************@posting.google.c om... "Mark Hahn" <ma**@prothon.org> wrote in message news:<S7Lac.87628$cx5.10253@fed1read04>...
Original top posting maintained on purpose:

Does anyone get anything done around here with all the bitching? I've been communicating via email for 30 years and never have I seen such complaining about something so silly. If you have anything to contribute to Prothon
I'll be over in the Prothon lists. We are too busy creating to have
conversations like this over there.

You may not be able to tell it, but I'm a nice guy who would really like
feedback from intelligent knowledgable people like yourself. I just can't take this anymore.

Aahz wrote:

In article <eAF9c.48978$cx5.17895@fed1read04>,
Mark Hahn <ma**@prothon.org> wrote:
>
> Self defines having the same attribute in two different prototypes
> illegal. That seemed extremely constraining to me so I went with the
> Python 2.2 mro solution in Prothon.

Bad idea. But I won't tell you why until you stop top-posting and
over-quoting.

Aahz is probably referring to the fact that Python 2.3 has changed the
MRO since the 2.2 one was a bad idea. See
http://www.python.org/2.3/mro.html
for more. A part for this, Aahz is right in pointing out that you
cannot get
the attention of a lot of intelligent knowledgable people on c.l.py
because
of your postings habits. Actually this is the reason why I have
downloaded Prothon yet. It is kinda of a pity, since maybe the idea is
worth, but it is difficult to give credit to people liking tabs and
top posting. Those are not
stupid things IMNSHO.

Michele Simionato

[JanC]

"Mark Hahn" <ma**@prothon.org> schreef:

As far as top-posting, I am trying to improve, it's just hard to
change my reply style after using it for 30 years without getting any
complaints before. I feel like I'm in a twilight-zone episode.

You're still not using OE-QuoteFix... ;-)

--
JanC

"Be strict when sending and tolerant when receiving."
RFC 1958 - Architectural Principles of the Internet - section 3.9

[Michele Simionato]

aa**@pythoncraft.com (Aahz) wrote in message news:<c4**********@panix1.panix.com>...

In article <95**************************@posting.google.com >,
Michele Simionato <mi***************@poste.it> wrote:

[...]

Michele, I just got a mailbox full error when I tried sending you
e-mail. Please fix.

It should work now. My address mi***************@poste.it is mostly
a span recipient I don't check often. Rea addresses I check every day are
mi**************@libero.it and mi***************@partecs.com
M.S.

[Aahz]

In article <95**************************@posting.google.com >,
Michele Simionato <mi***************@poste.it> wrote:

aa**@pythoncraft.com (Aahz) wrote in message news:<c4**********@panix1.panix.com>...

Michele, I just got a mailbox full error when I tried sending you
e-mail. Please fix.

It should work now. My address mi***************@poste.it is mostly
a span recipient I don't check often. Rea addresses I check every day are
mi**************@libero.it and mi***************@partecs.com

Then please make those addresses readily available by sticking them in
your .sig or something. Having a non-replyable address is about as rude
as top-posting. ;-)
--
Aahz (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/

"usenet imitates usenet" --Darkhawk

[Greg Ewing]

Mark Hahn wrote:

You don't have to use the obj = proto() technique to create an object. The following code is identical to saying subproto = topproto() except no
__init__() will be called:

subproto = Object()
subproto.set_proto(topproto) # switch prototype on the fly

Does this give you the missing piece you need

Yes, it does, I think. Creating the prototype this way
is very similar to what the Python class statement does.

Greg

[Max M]

Mark Hahn wrote:

it is difficult to give credit to people liking tabs and

As far as top-posting, I am trying to improve, it's just hard to change my
reply style after using it for 30 years without getting any complaints
before. I feel like I'm in a twilight-zone episode.

Actually I am too. There is some interresting dynamics going on here.

Appart from that Brandon guy, I have never experienced such a reaction
before in this group. I hope it is just a fluke.
regards Max M

[Aahz]

In article <40*********************@dread12.news.tele.dk>,
Max M <ma**@mxm.dk> wrote:

Mark Hahn wrote:

As far as top-posting, I am trying to improve, it's just hard to change my
reply style after using it for 30 years without getting any complaints
before. I feel like I'm in a twilight-zone episode.

Actually I am too. There is some interresting dynamics going on here.

Appart from that Brandon guy, I have never experienced such a reaction
before in this group. I hope it is just a fluke.

Mark's the first person I recall seeing who was trying to participate in
a serious discussion and also using top-posting. Also, there are a fair
number of netiquette snobs here, and when Mark actively rejected the
arguments against top-posting, people got annoyed. It was similar to
the reaction you might expect from the following exchange:

A: <spam>
B: Please don't post spam, it's not appropriate
A: Why not? Spam has a number of beneficial qualities....

I'm always surprised when I find someone who's been active on the Net for
more than a few years who isn't even aware of how much a hot-button
top-posting is in some communities.
--
Aahz (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/

"usenet imitates usenet" --Darkhawk

[Michele Simionato]

aa**@pythoncraft.com (Aahz) wrote in message news:<c4**********@panix2.panix.com>...

In article <95**************************@posting.google.com >,
Michele Simionato <mi***************@poste.it> wrote:

My address mi***************@poste.it is mostly
a span recipient I don't check often. Rea addresses I check every day are
mi**************@libero.it and mi***************@partecs.com

Then please make those addresses readily available by sticking them in
your .sig or something. Having a non-replyable address is about as rude
as top-posting. ;-)

BTW, I tried to send you a message and got this:

- These recipients of your message have been processed by the mail
server:
aa**@pythoncraft.com; Failed; 5.1.1 (bad destination mailbox address)

Remote MTA iris2.directnic.com: SMTP diagnostic: 550 5.7.1 Mail from
smtp1.libero.it (193.70.192.51) refused (blackholed by
bl.spamcop.net); Blocked - see
http://www.spamcop.net/bl.shtml?193.70.192.51

So it looks like spam is taking control of our lifes and making both
of us to appear rude :-/
Michele Simionato

[Aahz]

In article <95*************************@posting.google.com> ,
Michele Simionato <mi***************@poste.it> wrote:

aa**@pythoncraft.com (Aahz) wrote in message news:<c4**********@panix2.panix.com>...

In article <95**************************@posting.google.com >,
Michele Simionato <mi***************@poste.it> wrote:

My address mi***************@poste.it is mostly
a span recipient I don't check often. Rea addresses I check every day are
mi**************@libero.it and mi***************@partecs.com

Then please make those addresses readily available by sticking them in
your .sig or something. Having a non-replyable address is about as rude
as top-posting. ;-)

BTW, I tried to send you a message and got this:

- These recipients of your message have been processed by the mail
server:
aa**@pythoncraft.com; Failed; 5.1.1 (bad destination mailbox address)

Remote MTA iris2.directnic.com: SMTP diagnostic: 550 5.7.1 Mail from
smtp1.libero.it (193.70.192.51) refused (blackholed by
bl.spamcop.net); Blocked - see
http://www.spamcop.net/bl.shtml?193.70.192.51

So it looks like spam is taking control of our lifes and making both
of us to appear rude :-/

Ick. That's odd -- I thought my DNS provider didn't do that kind of
thing, but I'm guessing they've been under such overload that they had
to. <sigh> Please forward that message with full headers to
aa****@panix.com -- my local spam filters shouldn't trap it.
--
Aahz (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/

"usenet imitates usenet" --Darkhawk

[Dave Benjamin]

In article <c4**********@panix3.panix.com>, Aahz wrote:

Ick. That's odd -- I thought my DNS provider didn't do that kind of
thing, but I'm guessing they've been under such overload that they had
to. <sigh> Please forward that message with full headers to
a****y@p***x.com -- my local spam filters shouldn't trap it.

Just a few words of advice - never post your email address on Usenet unless:

a) you don't mind getting flooded with spam, or
b) you obfuscate it in some way

Especially given the context of this conversation, it made me wince when I
saw you post a secondary email address in plaintext to get around spam
problems with your primary one...

Peace,
Dave

--
..:[ dave benjamin: ramen/[sp00] -:- spoomusic.com -:- ramenfest.com ]:.
: please talk to your son or daughter about parametric polymorphism. :