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

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • Michele Simionato

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

    > Hello, my name is Skip and I am metaclass-unaware. I've been programming in[color=blue]
    > 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.[/color]

    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

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

    In article <95aa1afa.04032 72243.78d60724@ posting.google. com>, Michele Simionato wrote:[color=blue]
    > 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.[/color]

    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.
    [color=blue]
    > 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.[/color]

    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.)
    [color=blue]
    > 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.[/color]

    __init__ method, I believe. But I just realized something - how does
    Prothon (or prototyped languages in general) handle multiple
    inheritance or mixins?
    [color=blue]
    >[*] 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.[/color]

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

    Joe

    Comment

    • Michele Simionato

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

      Joe Mason <joe@notcharles .ca> wrote in message news:<slrnc6crt i.dit.joe@gate. notcharles.ca>. ..[color=blue]
      >
      > 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.)[/color]

      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

      Comment

      • Joe Mason

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

        In article <95aa1afa.04032 80258.41dc5cd9@ posting.google. com>, Michele Simionato wrote:[color=blue]
        > Joe Mason <joe@notcharles .ca> wrote in message news:<slrnc6crt i.dit.joe@gate. notcharles.ca>. ..[color=green]
        >>
        >> 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.)[/color]
        >
        > 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.[/color]

        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

        Comment

        • Terry Reedy

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


          "Joe Mason" <joe@notcharles .ca> wrote in message
          news:slrnc6ddi6 .e5c.joe@gate.n otcharles.ca...[color=blue]
          > In article <95aa1afa.04032 80258.41dc5cd9@ posting.google. com>, Michele[/color]
          Simionato wrote:[color=blue][color=green]
          > > Joe Mason <joe@notcharles .ca> wrote in message[/color][/color]
          news:<slrnc6crt i.dit.joe@gate. notcharles.ca>. ..[color=blue][color=green][color=darkred]
          > >>
          > >> 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.)[/color]
          > >
          > > 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.[/color]
          >
          > It is if you call the inherited __init__ method, which you should be
          > doing because it probably does important stuff.[/color]

          ?? 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.
          [color=blue]
          > 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.[/color]

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

          Terry J. Reedy




          Comment

          • Mark Hahn

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

            > 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" <joe@notcharles .ca> wrote in message
            news:slrnc6crti .dit.joe@gate.n otcharles.ca...[color=blue]
            > In article <95aa1afa.04032 72243.78d60724@ posting.google. com>, Michele[/color]
            Simionato wrote:[color=blue][color=green]
            > > 1. The metaclass can raise the error *before* the metaclass is created,
            > > whereas the function works a posteriori, *after* the overriding is[/color][/color]
            done;[color=blue][color=green]
            > > 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[/color][/color]
            factory,[color=blue][color=green]
            > > but then I have just re-invented a metaclass with an ugly call[/color][/color]
            syntax.[color=blue]
            >
            > 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.
            >[color=green]
            > > 2. The metaclass can be inherited, so the check is automatic for all[/color][/color]
            children;[color=blue][color=green]
            > > on the contrary, I have to call the function by hand each time I[/color][/color]
            define[color=blue][color=green]
            > > 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.[/color]
            >
            > 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.)
            >[color=green]
            > > 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.[/color]
            >
            > __init__ method, I believe. But I just realized something - how does
            > Prothon (or prototyped languages in general) handle multiple
            > inheritance or mixins?
            >[color=green]
            > >[*] 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[/color][/color]
            applications[color=blue][color=green]
            > > such as Zope (in some hidden form), or if there was some other reason.[/color]
            >
            > http://www.python.org/2.2/descrintro.html#metaclasses has some
            > references you might find interesting.
            >
            > Joe[/color]


            Comment

            • Mark Hahn

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

              > 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" <michele.simion ato@poste.it> wrote in message
              news:95aa1afa.0 403272243.78d60 724@posting.goo gle.com...[color=blue][color=green]
              > > Hello, my name is Skip and I am metaclass-unaware. I've been[/color][/color]
              programming in[color=blue][color=green]
              > > Python for about ten years and I have yet to write a metaclass. At[/color][/color]
              first I[color=blue][color=green]
              > > thought it was just that metaclasses were new to the language, but now[/color][/color]
              as[color=blue][color=green]
              > > more and more people use them and proclaim their widespread benefits, I[/color][/color]
              have[color=blue][color=green]
              > > come to realize that through years of abuse my brain has become addicted[/color][/color]
              to[color=blue][color=green]
              > > classic classes.[/color]
              >
              > 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[/color]
              readily[color=blue]
              > 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[/color]
              Zope[color=blue]
              > 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[/color]
              metaclass"[color=blue]
              > 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,[/color]
              introducing[color=blue]
              > the concept of Extension classes. Extension classes are instances of a C[/color]
              coded[color=blue]
              > 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[/color]
              Extension[color=blue]
              > Classes were invented before Python 2.2[*]; the net result is that I[/color]
              cannot[color=blue]
              > 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[/color]
              required[color=blue]
              > 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[/color]
              done;[color=blue]
              > 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[/color]
              factory,[color=blue]
              > 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[/color]
              children;[color=blue]
              > 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[/color]
              solution,[color=blue]
              > 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[/color]
              applications[color=blue]
              > such as Zope (in some hidden form), or if there was some other reason.[/color]


              Comment

              • Joe Mason

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

                In article <mailman.13.108 0496451.20120.p ython-list@python.org >, Terry Reedy wrote:[color=blue]
                > ?? 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.[/color]

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

                Joe

                Comment

                • Greg Ewing (using news.cis.dfn.de)

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

                  Joe Mason wrote:[color=blue]
                  > In article <95aa1afa.04032 80258.41dc5cd9@ posting.google. com>, Michele Simionato wrote:
                  >[color=green]
                  >>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 .[/color]
                  >
                  > It is if you call the inherited __init__ method, which you should be
                  > doing because it probably does important stuff.[/color]

                  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


                  Comment

                  • Mark Hahn

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

                    > 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 )" <ieyf4fu02@snea kemail.com> wrote in
                    message news:c4aia1$2d4 4ll$1@ID-169208.news.uni-berlin.de...[color=blue]
                    > Joe Mason wrote:[color=green]
                    > > In article <95aa1afa.04032 80258.41dc5cd9@ posting.google. com>, Michele[/color][/color]
                    Simionato wrote:[color=blue][color=green]
                    > >[color=darkred]
                    > >>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 .[/color]
                    > >
                    > > It is if you call the inherited __init__ method, which you should be
                    > > doing because it probably does important stuff.[/color]
                    >
                    > 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
                    >[/color]


                    Comment

                    • Roberto Lupi

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

                      In article <95aa1afa.04032 72243.78d60724@ posting.google. com>,[color=blue]
                      > 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.[/color]

                      I would add the check to a test case for the class.

                      class XYZTestCase(Zop eTestCase):
                      tested_class = XYZ

                      def testOverriddenM ethods(self):
                      check_if_we_are _overriding_nam es_in(self.test ed_class)
                      [color=blue]
                      > 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.[/color]

                      Test cases can be inherited.

                      class XYZ2TestCase(XY ZTestCase):
                      tested_class = XYZ2

                      --
                      Roberto Lupi

                      Comment

                      • Greg Ewing (using news.cis.dfn.de)

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

                        Mark Hahn wrote:[color=blue][color=green]
                        > > But presumably he wants the check done only once, when a subclass is
                        > > defined, *not* every time said subclass is instantiated.[/color]
                        >
                        > 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).[/color]

                        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


                        Comment

                        • Mark Hahn

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

                          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:[color=blue]
                          > Mark Hahn wrote:[color=green][color=darkred]
                          >>> But presumably he wants the check done only once, when a subclass is
                          >>> defined, *not* every time said subclass is instantiated.[/color]
                          >>
                          >> 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).[/color]
                          >
                          > 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.[/color]


                          Comment

                          • Aahz

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

                            In article <eAF9c.48978$cx 5.17895@fed1rea d04>,
                            Mark Hahn <mark@prothon.o rg> wrote:[color=blue]
                            >
                            >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.[/color]

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

                            "usenet imitates usenet" --Darkhawk

                            Comment

                            • Mark Hahn

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

                              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:[color=blue]
                              > In article <eAF9c.48978$cx 5.17895@fed1rea d04>,
                              > Mark Hahn <mark@prothon.o rg> wrote:[color=green]
                              >>
                              >> 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.[/color]
                              >
                              > Bad idea. But I won't tell you why until you stop top-posting and
                              > over-quoting.[/color]


                              Comment

                              Working...