Re: Are decorators really that different from metaclasses...

Discussion in 'Python' started by Paul Morrow, Aug 25, 2004.

  1. Paul Morrow

    Paul Morrow Guest

    Steven Bethard wrote:
    > Paul Morrow <pm_mon <at> yahoo.com> writes:
    >
    >>I believe that (virtually) all __xxx__ attributes have this metadata
    >>aspect (semantics) to them. When a programmer says
    >>
    >> def foo():
    >> __author__ = 'Wilma Flintstone'
    >> __version__ = '0.1'
    >>
    >>She does not intend for __author__ nor __version__ to be local variables
    >>of foo, used somehow by foo in the calculation of its return value. To
    >>her they are foo /metadata/ --- attributes of the foo object itself ---
    >>as they contain information that *describes* foo.

    >
    >
    > I assume you mean that this is what you'd like a programmer to intend? If I
    > wrote that, I would intend (and expect) __author__ to be a local variable.
    > I'm not saying that I couldn't be retrained. I'm just saying that right now,
    > I would not expect it to be otherwise.
    >


    What I mean is that this is what (I believe) veteran Python programmers
    always intend, because it's a Python convention (although I've never
    actually seen it described quite like this --- as metadata).

    Here's what PEP 8 (http://www.python.org/peps/pep-0008.html) has to say
    about __xxx__ attributes:

    __double_leading_and_trailing_underscore__: "magic" objects or
    attributes that live in user-controlled namespaces,
    e.g. __init__, __import__ or __file__. Sometimes these are
    defined by the user to trigger certain magic behavior
    (e.g. operator overloading); sometimes these are inserted by the
    infrastructure for its own use or for debugging purposes. Since
    the infrastructure (loosely defined as the Python interpreter
    and the standard library) may decide to grow its list of magic
    attributes in future versions, user code should generally
    refrain from using this convention for its own use. User code
    that aspires to become part of the infrastructure could combine
    this with a short prefix inside the underscores,
    e.g. __bobo_magic_attr__.


    Here's a link that gives some examples of them:
    http://cardboard.nu/blog/2003_09_18/module_level_magic_variables.html)

    Sure veterans know that if it looks like a local variable definition,
    then it is one. But my point is that (IMO) they don't normally rely on
    that aspect of __xxx__ variables. You'll almost never see a function
    that examines its own metadata in the computation of its result.


    >
    >>Likewise, when she defines __lt__, __getitem__, __init__, etc. as part
    >>of a class, they will not typically be called by methods of the class or
    >>users/consumers/clients of the class [*] the way that 'normal'
    >>attributes will. They contain meta info that describes a deeper level
    >>of class behavior.

    >
    >
    > This seems a little misleading to me. The only reason these methods are
    > special is because they override operators (something like "<", "[]", and "()"
    > respectively). You could provide a class with /exactly/ the same
    > functionality without ever implementing any of these methods. (Well, minus
    > __init__, but that was a special case in your discussion too.) The only thing
    > that implementing these methods does is allows your user to access these
    > methods through an operator shorthand. A simple example:
    >
    > class Identity:
    > def get(self, x):
    > return x
    > __getitem__ = get
    >
    > How is __getitem__ any more "metadata" then get is? They provide exactly the
    > same functionality. The __getitem__ declaration just allows you to access the
    > get method using "[...]".
    >


    Well, but that's a big difference. __getitem__ has a much deeper
    meaning than your 'get'. Defining it actually changes which syntax
    you're allowed to use on instances of your class. Now you can do things
    like...

    ident = Identity()
    print "%(alpha)s, %(beta)s, %(gamma)s" % ident


    > Are you trying to say that "metadata" is the same thing as "operator shortcut"?
    >


    Not exactly, but it would include defining those. One way to think
    about metadata is that it includes all information *about* an object,
    but no information *used by* the object.

    If we were to have a conversation about this conversation, then we would
    be having a "meta-conversation." /metadata/ is data that describes
    data. metadata for a function would be data that describes the
    function; data *about* the function as opposed to data *used by* the
    function. For example:

    def circumference(diameter):
    """ This is a docstring. It's metadata for this function. """
    __author__ = 'Paul Morrow' # more metadata
    pi = 3.14 # not metadata
    return pi * diameter



    Paul
     
    Paul Morrow, Aug 25, 2004
    #1
    1. Advertising

  2. Paul Morrow

    Jess Austin Guest

    Paul Morrow <> wrote in message news:<>...
    >
    > Not exactly, but it would include defining those. One way to think
    > about metadata is that it includes all information *about* an object,
    > but no information *used by* the object.
    >
    > If we were to have a conversation about this conversation, then we would
    > be having a "meta-conversation." /metadata/ is data that describes
    > data. metadata for a function would be data that describes the
    > function; data *about* the function as opposed to data *used by* the
    > function. For example:


    Here I think you're making an unwarranted assumption. There is
    currently nothing stopping an object from using information about
    itself to do its job. And this is sometimes a useful freedom. As an
    example, you might have subclasses whose only real purpose is to keep
    track of their class and metadata, and have all functionality provided
    by their superclass:

    class supe(object):
    """this docstring is rarely frobnosticated"""
    def do_something_based_on_metadata():
    frobnosticate(self.__doc__)

    class sub1(supe):
    """I am sub1"""

    class sub2(supe):
    """I am sub2"""

    Something like this could often be considered premature
    objectification, but I've used it successfully. Also, you'll notice
    that these are classes rather than simple functions - I admit I've
    never had a need to think about function metadata before.

    However, I know that many people have a specific view of metadata and
    don't really see how decorators fit in. To be frank, I think pep318
    shoehorned in metadata to pretend that there was a wider application
    area for decoration than there really is. The current quite minimal
    support for metadata is sufficient for 99% of metadata use cases. My
    example has worked in Python for some time. I know that decorators
    would allow different behaviors to be arbitrarily assigned to various
    pieces of metadata, but that doesn't seem like a big win for code
    maintainability. If anyone decided to support pep318 based solely on
    a love of metadata, he made a mistake.

    I'm intrigued by decorators anyway, and in no small part because it
    seems that they should be able to completely replace metaclasses,
    which are themselves totally unrelated to metadata. In fact, that's
    what at first prompted me to read a thread with the title, "Are
    decorators really that different from metaclasses..." Class
    decorators wouldn't be so different from metaclasses, but J2 or even
    @pie are much better syntaxes than the current metaclass syntax.

    In another post in this thread Anthony Baxter said they were
    different. I'll respond directly to that post.

    later,
    Jess
     
    Jess Austin, Aug 25, 2004
    #2
    1. Advertising

  3. Paul Morrow

    Paul Morrow Guest

    Jess Austin wrote:
    >
    > Here I think you're making an unwarranted assumption. There is
    > currently nothing stopping an object from using information about
    > itself to do its job. And this is sometimes a useful freedom. As an
    > example, you might have subclasses whose only real purpose is to keep
    > track of their class and metadata, and have all functionality provided
    > by their superclass:
    >
    > class supe(object):
    > """this docstring is rarely frobnosticated"""
    > def do_something_based_on_metadata():
    > frobnosticate(self.__doc__)
    >
    > class sub1(supe):
    > """I am sub1"""
    >
    > class sub2(supe):
    > """I am sub2"""
    >


    What you're trying to illustrate (I believe) is a superclass doing
    something based on the docstring of a subclass. Yes this certainly does
    happen. But the superclass and subclass are separate objects. I was
    talking about the situation where a function does something based on
    /its own/ metadata. That is what I'm saying virtually never happens,
    and therefore it's ok to make all assignments to __xxx__ attributes
    inside of a function def create /function attributes/ rather than /local
    variables/.


    Paul
     
    Paul Morrow, Aug 26, 2004
    #3
  4. Paul Morrow

    Paul Morrow Guest

    Paul Morrow wrote:

    > and therefore it's ok to make all assignments to __xxx__ attributes
    > inside of a function def create /function attributes/ rather than /local
    > variables/.


    In My Opinion.
     
    Paul Morrow, Aug 26, 2004
    #4
  5. On Wed, 25 Aug 2004 19:47:35 -0400, Paul Morrow <> wrote:
    > What you're trying to illustrate (I believe) is a superclass doing
    > something based on the docstring of a subclass. Yes this certainly does
    > happen. But the superclass and subclass are separate objects. I was
    > talking about the situation where a function does something based on
    > /its own/ metadata. That is what I'm saying virtually never happens,
    > and therefore it's ok to make all assignments to __xxx__ attributes
    > inside of a function def create /function attributes/ rather than /local
    > variables/.


    This is an extraordinarily complex idea - you're proposing that inside
    a function there is now access to a brand new namespace, that of the
    function object itself. I don't think you appreciate just _how_ much
    work this would requre, nor the complexity of trying to explain this
    to users. Remember, at the moment, you can't even get access to the
    function object itself from inside the function, without using a hack
    like sys._getframe() or raising an exception.

    Putting aside nested scopes for the moment, there are three namespaces
    that are used in Python - local, module level global, and builtins.
    You're proposing that there is a new namespace, that of the function
    object, and that it only be used by accessing any local variable that
    starts or ends with two underscores. At the moment, the scoping rules
    for Python are _extremely_ simple. Do you really want to add something
    like this, that looks like a hack, smells like a hack, and who's
    implementation would be a hack? I know I don't want to see something
    like this.
     
    Anthony Baxter, Aug 26, 2004
    #5
  6. Anthony Baxter wrote:
    > On Wed, 25 Aug 2004 19:47:35 -0400, Paul Morrow <> wrote:
    >
    >>What you're trying to illustrate (I believe) is a superclass doing
    >>something based on the docstring of a subclass. Yes this certainly does
    >>happen. But the superclass and subclass are separate objects. I was
    >>talking about the situation where a function does something based on
    >>/its own/ metadata. That is what I'm saying virtually never happens,
    >>and therefore it's ok to make all assignments to __xxx__ attributes
    >>inside of a function def create /function attributes/ rather than /local
    >>variables/.

    >
    >
    > This is an extraordinarily complex idea - you're proposing that inside
    > a function there is now access to a brand new namespace, that of the
    > function object itself. I don't think you appreciate just _how_ much
    > work this would requre, nor the complexity of trying to explain this
    > to users. Remember, at the moment, you can't even get access to the
    > function object itself from inside the function, without using a hack
    > like sys._getframe() or raising an exception.


    It's not the ideas complexity that fears,but the feeling we are trying
    to bring down to earth the supposed magic of some language solutions.
    There is nothing good in magic,specially when you have to build robust
    things on it.


    > Putting aside nested scopes for the moment, there are three namespaces
    > that are used in Python - local, module level global, and builtins.
    > You're proposing that there is a new namespace, that of the function
    > object, and that it only be used by accessing any local variable that
    > starts or ends with two underscores. At the moment, the scoping rules
    > for Python are _extremely_ simple. Do you really want to add something
    > like this, that looks like a hack, smells like a hack, and who's
    > implementation would be a hack? I know I don't want to see something
    > like this.


    If this blows away clouds on the language future and bring back the
    useful features in a wider theory where metaclasses and decorators are
    members of,this shouldn't be considered a hack.If it becomes a hack the
    problem is to be searched and solved above generalizing the scope system.
     
    Paolo Veronelli, Aug 26, 2004
    #6
  7. On Thu, 26 Aug 2004 10:28:14 +0200, Paolo Veronelli
    <> wrote:
    > It's not the ideas complexity that fears,but the feeling we are trying
    > to bring down to earth the supposed magic of some language solutions.
    > There is nothing good in magic,specially when you have to build robust
    > things on it.


    I have no idea what you're trying to say here. Are you saying that the
    approach of double-under variables inside a function having some new
    meaning, getting put into a new scope that did not previously exist,
    is somehow _less_ magical that the syntactic sugar of decorators? If
    so, how do you intend to handle the backwards compatibility issue,
    where code that works on Python2.4 will do something entirely
    different on Python2.3 (the double-under variables will be silently
    ignored). Do you intend that the double-under names would also be
    looked for in the same scopes? That is, what will this code do?

    def foo():
    __name__ = '%s_banana'%(__name__)

    > If this blows away clouds on the language future and bring back the
    > useful features in a wider theory where metaclasses and decorators are
    > members of,this shouldn't be considered a hack.If it becomes a hack the
    > problem is to be searched and solved above generalizing the scope system.


    Hand waving is all well and good, but this isn't a matter of
    "generalizing the scope system". This is a _radical_ change to the
    scoping rules of Python, and I think it's safe to say that there's
    *absolutely* *no* *way* something like this would be considered,
    without an excellent reason - and bolting some sort of strange
    decorator semantics doesn't cut it.

    Anthony
     
    Anthony Baxter, Aug 26, 2004
    #7
  8. Paul Morrow

    Paul Morrow Guest

    Anthony Baxter wrote:
    > On Wed, 25 Aug 2004 19:47:35 -0400, Paul Morrow <> wrote:
    >
    >>What you're trying to illustrate (I believe) is a superclass doing
    >>something based on the docstring of a subclass. Yes this certainly does
    >>happen. But the superclass and subclass are separate objects. I was
    >>talking about the situation where a function does something based on
    >>/its own/ metadata. That is what I'm saying virtually never happens,
    >>and therefore it's ok to make all assignments to __xxx__ attributes
    >>inside of a function def create /function attributes/ rather than /local
    >>variables/.

    >
    >
    > This is an extraordinarily complex idea - you're proposing that inside
    > a function there is now access to a brand new namespace, that of the
    > function object itself. I don't think you appreciate just _how_ much
    > work this would requre, nor the complexity of trying to explain this
    > to users. Remember, at the moment, you can't even get access to the
    > function object itself from inside the function, without using a hack
    > like sys._getframe() or raising an exception.
    >


    No I'm not suggesting that. The function would continue to have exactly
    the same namespace.

    This is not a big change; quite the contrary...

    The interpreter, when it is executing a def statement, after it binds
    __doc__ to the docstring, would execute any assignments to __xxx__
    attributes it finds immediately following the docstring (if present). So

    def circumference(diameter):
    """ This is a docstring. """
    __author__ = 'Paul Morrow'
    pi = 3.14
    return pi * diameter

    would be /exactly equivalent/ to

    def circumference(diameter):
    pi = 3.14
    return pi * diameter

    circumference.__doc__ = """ This is a docstring. """
    circumference.__author__ = 'Paul Morrow'


    See how simple? In fact, isn't this just as simple --- or even simpler
    -- than what would be require to implement J2 or A1?

    And remember, the assumption here is that these assignments (to __xxx__
    attributes) are a form of declarations /about the function/, just as
    docstrings are now. There's no need to support conditional declarations...

    def foo():
    """ I am a docstring. """
    __author__ = 'Morrow'

    # Just as there is no proper, 'definition time' way to
    # conditionally change a docstring, the code below
    # will generate an exception (at runtime).
    if 1:
    __version__ = '0.1'
    else:
    __version__ = '0.2'

    Think of what I'm proposing here as just a convenience syntax. We can
    already do the same thing after (outsidef of) the function def as the
    second circumference example above shows.

    Paul
     
    Paul Morrow, Aug 26, 2004
    #8
  9. Paul Morrow

    Paul Morrow Guest

    Anthony Baxter wrote:
    > On Thu, 26 Aug 2004 10:28:14 +0200, Paolo Veronelli
    > <> wrote:
    >
    > ignored). Do you intend that the double-under names would also be
    > looked for in the same scopes? That is, what will this code do?
    >
    > def foo():
    > __name__ = '%s_banana'%(__name__)
    >


    /exactly/ the same thing as

    def foo(): pass

    foo.__name__ = '%s_banana'%(foo.__name__)


    Paul
     
    Paul Morrow, Aug 26, 2004
    #9
  10. Paul Morrow

    Arthur Guest

    On Thu, 26 Aug 2004 17:31:16 +1000, Anthony Baxter
    <> wrote:

    >On Wed, 25 Aug 2004 19:47:35 -0400, Paul Morrow <> wrote:
    >> What you're trying to illustrate (I believe) is a superclass doing
    >> something based on the docstring of a subclass. Yes this certainly does
    >> happen. But the superclass and subclass are separate objects. I was
    >> talking about the situation where a function does something based on
    >> /its own/ metadata. That is what I'm saying virtually never happens,
    >> and therefore it's ok to make all assignments to __xxx__ attributes
    >> inside of a function def create /function attributes/ rather than /local
    >> variables/.

    >
    >This is an extraordinarily complex idea - you're proposing that inside
    >a function there is now access to a brand new namespace, that of the
    >function object itself. I don't think you appreciate just _how_ much
    >work this would requre, nor the complexity of trying to explain this
    >to users. Remember, at the moment, you can't even get access to the
    >function object itself from inside the function, without using a hack
    >like sys._getframe() or raising an exception.
    >
    >Putting aside nested scopes for the moment, there are three namespaces
    >that are used in Python - local, module level global, and builtins.
    >You're proposing that there is a new namespace, that of the function
    >object, and that it only be used by accessing any local variable that
    >starts or ends with two underscores. At the moment, the scoping rules
    >for Python are _extremely_ simple. Do you really want to add something
    >like this, that looks like a hack, smells like a hack, and who's
    >implementation would be a hack? I know I don't want to see something
    >like this.



    Though I am learning stuff by trying to keep up with this conversation
    - I should probably stay out of it, directly.

    But, as I publically demonstrated in my confusion about __name__

    ....to someone educated from within Python, mostly by chucking out
    code, rather than reading documentation - that __name__ accessed
    from within the function body is something totally different from
    __name__ accessed from outside of it, was not what I think the
    language taught me to expect. I might have intuited that to expect
    otherwise would be "magic", but thought, somehow, that the __xxx__
    implied the availability of that kind of magic.

    In other words, it would have surprised me less to have been right
    than to have benn wrong.

    Though I have learned not to be shocked about being wrong ;)

    And can understand the possiblity that others with other backgrounds
    might be surprised if I had been right.

    Does

    """
    Namespaces are one honking great idea -- let's do more of those!
    """

    come into play here at all?

    Art
     
    Arthur, Aug 26, 2004
    #10
  11. Paul Morrow

    Arthur Guest

    On Thu, 26 Aug 2004 21:05:46 +1000, Anthony Baxter
    <> wrote:
    >
    >def foo():
    > __name__ = '%s_banana'%(__name__)
    >



    I'm not sure what you are driving at here, but ...

    Aa a practical matter, wouldn't it be nice to be able to use string
    substitution on a docstring placed in its usual location under def
    foo().

    That I need to place my __doc__ under the function can't be considered
    a good thing, or intutive thing.

    Sort of like having to do transformations after and under the function
    ;)

    Art
     
    Arthur, Aug 26, 2004
    #11
  12. Paul Morrow

    Arthur Guest

    On Thu, 26 Aug 2004 13:00:41 GMT, Arthur <>
    wrote:

    >On Thu, 26 Aug 2004 21:05:46 +1000, Anthony Baxter
    ><> wrote:
    >>
    >>def foo():
    >> __name__ = '%s_banana'%(__name__)
    >>

    >
    >
    >I'm not sure what you are driving at here, but ...
    >
    >Aa a practical matter, wouldn't it be nice to be able to use string
    >substitution on a docstring placed in its usual location under def
    >foo().
    >
    >That I need to place my __doc__ under the function can't be considered
    >a good thing, or intutive thing.
    >
    >Sort of like having to do transformations after and under the function
    >;)
    >
    >Art


    But you can perhaps respond that with a2 the flexibility to put the
    doc string where you think it belongs, before and above the function
    (and I don't necessarily disagree, in that that it is always where I
    find myself putting #comments (though perhaps I am putting them there
    in particular to *distinguish* them from a docstring (where would I
    put comments if my docstring were above (perhaps below)))) -

    that you and I will be placing are docstrings differently can be seen
    both as a benefit *and as a cost*, of the a2 implmentation.

    Art
     
    Arthur, Aug 26, 2004
    #12
  13. Paul Morrow

    Paul Morrow Guest

    Arthur wrote:

    > On Thu, 26 Aug 2004 21:05:46 +1000, Anthony Baxter
    > <> wrote:
    >
    >>def foo():
    >> __name__ = '%s_banana'%(__name__)
    >>

    >
    >
    >
    > I'm not sure what you are driving at here, but ...
    >
    > Aa a practical matter, wouldn't it be nice to be able to use string
    > substitution on a docstring placed in its usual location under def
    > foo().
    >
    > That I need to place my __doc__ under the function can't be considered
    > a good thing, or intutive thing.
    >
    > Sort of like having to do transformations after and under the function
    > ;)
    >
    > Art


    Currently, you can change a doc string outside of a function, by
    modifying the function's __doc__ attribute

    >>> def foo():

    ... """ I am foo """
    ...
    >>> foo.__doc__

    ' I am foo '
    >>> foo.__doc__ = foo.__doc__ + 'indeed'
    >>> foo.__doc__

    ' I am foo indeed'
    >>>


    IMO, to change it inside of a function def should be (but isn't) as easy
    as...

    >>> def foo():

    ... """ I am foo """
    ... __doc__ = __doc__ + 'indeed'

    Paul
     
    Paul Morrow, Aug 26, 2004
    #13
  14. Paul Morrow

    Arthur Guest

    On Thu, 26 Aug 2004 09:31:55 -0400, Paul Morrow <>
    wrote:

    >
    >Currently, you can change a doc string outside of a function, by
    >modifying the function's __doc__ attribute
    >
    > >>> def foo():

    > ... """ I am foo """
    > ...
    > >>> foo.__doc__

    > ' I am foo '
    > >>> foo.__doc__ = foo.__doc__ + 'indeed'
    > >>> foo.__doc__

    > ' I am foo indeed'
    > >>>

    >
    >IMO, to change it inside of a function def should be (but isn't) as easy
    >as...
    >
    > >>> def foo():

    > ... """ I am foo """
    > ... __doc__ = __doc__ + 'indeed'
    >
    >Paul


    Yes. Not only do I follow, but I think we came to exactly the same
    place, from very different directions, and coming from what I sense is
    very different backgrounds.

    Its just that I don't think many others seem to find that as
    interesting as I happen to.

    Hopefully, for good enough reasons.

    Art

    >
    >
     
    Arthur, Aug 26, 2004
    #14
  15. On Thu, 26 Aug 2004 14:40:18 GMT, Arthur <> wrote:
    > >IMO, to change it inside of a function def should be (but isn't) as easy
    > >as...
    > >
    > > >>> def foo():

    > > ... """ I am foo """
    > > ... __doc__ = __doc__ + 'indeed'
    > >
    > >Paul

    >
    > Yes. Not only do I follow, but I think we came to exactly the same
    > place, from very different directions, and coming from what I sense is
    > very different backgrounds.
    >
    > Its just that I don't think many others seem to find that as
    > interesting as I happen to.


    Not so much that, as running out of ways to restate myself. The
    proposed syntax above still requires magic handling of double-under
    variables in a function, and a new namespace. I can't see how you can
    think that this is a _good_ thing.
     
    Anthony Baxter, Aug 26, 2004
    #15
  16. Paul Morrow

    Paul Morrow Guest

    Anthony Baxter wrote:
    > On Thu, 26 Aug 2004 14:40:18 GMT, Arthur <> wrote:
    >
    >>>IMO, to change it inside of a function def should be (but isn't) as easy
    >>>as...
    >>>
    >>> >>> def foo():
    >>> ... """ I am foo """
    >>> ... __doc__ = __doc__ + 'indeed'
    >>>
    >>>Paul

    >>
    >>Yes. Not only do I follow, but I think we came to exactly the same
    >>place, from very different directions, and coming from what I sense is
    >>very different backgrounds.
    >>
    >>Its just that I don't think many others seem to find that as
    >>interesting as I happen to.

    >
    >
    > Not so much that, as running out of ways to restate myself. The
    > proposed syntax above still requires magic handling of double-under
    > variables in a function, and a new namespace. I can't see how you can
    > think that this is a _good_ thing.


    The function does *not* get a new namespace! Let me stress this point a
    little further. We would simply be moving __xxx__ variables *out of*
    the function's local variable namespace to where they belong, the
    namespace of the function itself --- /the same namespace that __doc__
    lives in./

    As such, the function *body* would have no more access to __doc__ than
    it does now. Consider the following

    def foo():
    """ foo's docstring """
    __author__ = 'Paul Morrow'
    __version__ = '0.1'
    __features__ = memoized, synchronized
    # Above this line is the function's declaration section.
    # Below this line is where the function's body starts.
    var1 = 10
    print __doc__ # error! __doc__ is not in local namespace
    print var1 # ok.


    Paul
     
    Paul Morrow, Aug 26, 2004
    #16
  17. On Thu, 26 Aug 2004 11:09:28 -0400, Paul Morrow <> wrote:
    > The function does *not* get a new namespace! Let me stress this point a
    > little further. We would simply be moving __xxx__ variables *out of*
    > the function's local variable namespace to where they belong, the
    > namespace of the function itself --- /the same namespace that __doc__
    > lives in./


    There _is_ _no_ _such_ _namespace_. __doc__ is an attribute of the
    function object.

    You are proposing to add one. How else is __doc__ = __doc__ + 'extra' to work?

    Please, please look into how python's namespaces work a bit more. This
    isn't super-complex stuff, and the lovely thing about Python is that
    it's _really_ easy to use introspection to see how these things work.
     
    Anthony Baxter, Aug 26, 2004
    #17
  18. Paul Morrow

    Arthur Guest

    On Fri, 27 Aug 2004 00:53:51 +1000, Anthony Baxter
    <> wrote:

    >On Thu, 26 Aug 2004 14:40:18 GMT, Arthur <> wrote:
    >> >IMO, to change it inside of a function def should be (but isn't) as easy
    >> >as...
    >> >
    >> > >>> def foo():
    >> > ... """ I am foo """
    >> > ... __doc__ = __doc__ + 'indeed'
    >> >
    >> >Paul

    >>
    >> Yes. Not only do I follow, but I think we came to exactly the same
    >> place, from very different directions, and coming from what I sense is
    >> very different backgrounds.
    >>
    >> Its just that I don't think many others seem to find that as
    >> interesting as I happen to.

    >
    >Not so much that, as running out of ways to restate myself. The
    >proposed syntax above still requires magic handling of double-under
    >variables in a function, and a new namespace. I can't see how you can
    >think that this is a _good_ thing.


    Forgive me, that I am not necessarily able to grasp why it is
    necessarily a bad thing. or a badder thing than other things. But do
    not discount at all your advice that we are in pie-in-the-sky land.
    The weight of evidence - being the general lack of interest in this
    thread, being taken into account.

    But as I explained earlier, I was hoping some fortipation (or other
    mojo someone might provide) might make this come together some.

    Ain't to be if it ain't to be.

    Art
     
    Arthur, Aug 26, 2004
    #18
  19. Anthony Baxter wrote:
    > On Thu, 26 Aug 2004 10:28:14 +0200, Paolo Veronelli
    > <> wrote:
    >
    >>It's not the ideas complexity that fears,but the feeling we are trying
    >>to bring down to earth the supposed magic of some language solutions.
    >>There is nothing good in magic,specially when you have to build robust
    >>things on it.

    >
    >
    > I have no idea what you're trying to say here. Are you saying that the
    > approach of double-under variables inside a function having some new
    > meaning, getting put into a new scope that did not previously exist,
    > is somehow _less_ magical that the syntactic sugar of decorators?


    I would like to erase magic from code and have some kind of
    specification for the double-under variables.
    if __metaclass__ is not a keyword I suppose it's a reference
    but.....this is not enough:assigning it is a meta-coding action.
    So let's classify these actions and see what kind of meta-coding
    decorators are .
    This should be done before the creation of a new syntax,a good syntax
    for all meta-coding.


    > so, how do you intend to handle the backwards compatibility issue,
    > where code that works on Python2.4 will do something entirely
    > different on Python2.3 (the double-under variables will be silently
    > ignored).


    This is not a problem for me.If it's the case I don't really care of
    zoombies,I'm a researcher not a politician,
    I'm trying to develope a thought around a pragmatic good language,and
    possibly evolve my knowledge of it.
    Next generation will measure better our efforts.

    > Do you intend that the double-under names would also be
    > looked for in the same scopes? That is, what will this code do?
    >
    > def foo():
    > __name__ = '%s_banana'%(__name__)
    >

    Has it anything to do with our talking?Sharp features are sharp.If
    somebody want to obfuscate code he can do it,he is free of playing this
    game.

    >>If this blows away clouds on the language future and bring back the
    >>useful features in a wider theory where metaclasses and decorators are
    >>members of,this shouldn't be considered a hack.If it becomes a hack the
    >>problem is to be searched and solved above generalizing the scope system.

    >
    >
    > Hand waving is all well and good, but this isn't a matter of
    > "generalizing the scope system". This is a _radical_ change to the
    > scoping rules of Python, and I think it's safe to say that there's
    > *absolutely* *no* *way* something like this would be considered,
    > without an excellent reason - and bolting some sort of strange
    > decorator semantics doesn't cut it.


    We can use decorators issue to see how python successors will kill it
    in the long term or how the python will be
    after changing skin.
    In my enfant views knowledge is fractal and a the three scoping rules is
    hiding patterns which will be seen with the right lens.
    Possibly we can learn form other languages approches to the same
    problems but no way I matter to be considered from the higher spheres,I
    am a farmer taking some notes on how the plant is growing.

    Paolino
     
    Paolo Veronelli, Aug 26, 2004
    #19
  20. Paul Morrow

    Arthur Guest

    On Fri, 27 Aug 2004 00:53:51 +1000, Anthony Baxter
    <> wrote:

    >On Thu, 26 Aug 2004 14:40:18 GMT, Arthur <> wrote:
    >> >IMO, to change it inside of a function def should be (but isn't) as easy
    >> >as...
    >> >
    >> > >>> def foo():
    >> > ... """ I am foo """
    >> > ... __doc__ = __doc__ + 'indeed'
    >> >
    >> >Paul

    >>
    >> Yes. Not only do I follow, but I think we came to exactly the same
    >> place, from very different directions, and coming from what I sense is
    >> very different backgrounds.
    >>
    >> Its just that I don't think many others seem to find that as
    >> interesting as I happen to.

    >
    >Not so much that, as running out of ways to restate myself. The
    >proposed syntax above still requires magic handling of double-under
    >variables in a function, and a new namespace. I can't see how you can
    >think that this is a _good_ thing.


    Googling on "function namespace" is interesting.

    Subject to my interpretation of what I am accessing:

    Common Lisp has 'em, Scheme don't.

    Talked about a lot in the context of XML in ways I am not sure are
    relevant.

    Nested scopes is the beginning of their introduction into Python - as
    I am reading a cite from Dive Into Python. So of course what I have
    been driving at all along, is some extension to the the nested scope
    mechanism. Yes. I'm talking through my backside. Darts at the wall
    language design, I call it.

    Art
     
    Arthur, Aug 26, 2004
    #20
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Michael Sparks

    Using metaclasses to play with decorators.

    Michael Sparks, Jun 15, 2004, in forum: Python
    Replies:
    4
    Views:
    349
    Michele Simionato
    Jun 18, 2004
  2. Michael Sparks
    Replies:
    6
    Views:
    361
    David MacQuigg
    Jun 18, 2004
  3. Robert Brewer
    Replies:
    9
    Views:
    323
    David MacQuigg
    Jun 26, 2004
  4. Paul Morrow
    Replies:
    2
    Views:
    258
    Larry Bates
    Aug 24, 2004
  5. Anthony Baxter
    Replies:
    3
    Views:
    274
    Jess Austin
    Aug 26, 2004
Loading...

Share This Page