RE: Decorator syntax (was Re: PEP 318 - PyFIT comments)

Discussion in 'Python' started by Delaney, Timothy C (Timothy), Aug 5, 2004.

  1. Christopher T King wrote:

    > On 4 Aug 2004, Nick Vargish wrote:
    >
    >> I just don't know where else to voice my opinion on this matter, but
    >> I absolutely hate the new decorator syntax.

    >
    > I wish PEPs had a method through which votes could be cast, for or
    > against the PEP (or parts of it), not unlike Bugzilla bugs. At least


    The last vote was an unmitigated disaster. And there appears to be no
    more agreement on the correct syntax for decorators. The difference is
    that decorator syntax will have significant benefits for a certain class
    of project.

    > democratic input. Either way, I really wish he would hold off on
    > decorators until there's a consensus on them, rather than forcing
    > them in amidst all the disagreements surrounding them.


    There are significant projects that will greatly benefit from decorator
    syntax - for example, PyObjC.

    Personally, I don't overly like the new syntax - I much preferred def
    func (args) [decorators] - and I would have preferred not to "waste" @
    for them, but I can definitely live with the decision. Some usable
    decorator syntax is IMO more important than none.

    Besides, @ could possibly be reused for function attributes, meaning
    it's less "wasted" - there's also an obvious correlation in that both
    decorators and function attributes operate on the function object:

    @classmethod
    def func (args):
    @attr = 1
    pass

    Tim Delaney
     
    Delaney, Timothy C (Timothy), Aug 5, 2004
    #1
    1. Advertising

  2. In article <>,
    "Delaney, Timothy C (Timothy)" <> wrote:

    > Besides, @ could possibly be reused for function attributes, meaning
    > it's less "wasted" - there's also an obvious correlation in that both
    > decorators and function attributes operate on the function object:
    >
    > @classmethod
    > def func (args):
    > @attr = 1
    > pass
    >
    > Tim Delaney


    Hey, an actual reason for the restricted syntax in the current decorator
    implementation: it makes it less likely that @decorators will conflict
    with potential other @syntaxes such as this @attribute one.

    --
    David Eppstein
    Computer Science Dept., Univ. of California, Irvine
    http://www.ics.uci.edu/~eppstein/
     
    David Eppstein, Aug 5, 2004
    #2
    1. Advertising

  3. On 2004-08-04, Delaney, Timothy C (Timothy) <> wrote:
    > Christopher T King wrote:
    >
    >> On 4 Aug 2004, Nick Vargish wrote:
    >>
    >>> I just don't know where else to voice my opinion on this matter, but
    >>> I absolutely hate the new decorator syntax.

    >
    > @classmethod
    > def func (args):
    > @attr = 1
    > pass


    I'm just a dumb user of Python - I don't even program for a living, so
    there is no reason any of you should listen to me, but this @-syntax
    thing makes Python look like Perl. The reason I learned Python was that
    Perl looks like line noise to me, and I wanted a scripting language I
    could read. Please don't wreck a beautiful, readable language with this
    shortcut. Choose a word for it, not a symbol, please.

    Mike
     
    Michael Ressler, Aug 5, 2004
    #3
  4. Delaney, Timothy C (Timothy)

    Bruce Eckel Guest

    Re[2]: Decorator syntax (was Re: PEP 318 - PyFIT comments)

    I'll weigh in a little on this one.

    This is very similar to attributes/metadata in Java J2SE 5 and in C#.
    The thing is, metadata is a little bit weird; it's intentionally
    outside of the domain of the 'normal' programming language, because it
    expresses things that you can't or shouldn't within the normal
    programming language. So you _do_ need an escape mechanism. And it
    also takes a little bit of getting used to; it's orthogonal to what
    you normally think of as a language feature. But the potential for
    metadata features, at least in Java, is very powerful.

    I suspect that the influence comes from Java, where they are also
    using '@' (I don't recall what C# uses but it's very possibly also
    '@'), and this was, I believe, one of the last things put into J2SE
    1.5, so (guessing again) I suspect that's why it showed up so late in
    Python -- the last thing I saw presented was attributes inside square
    braces, and the only question was where they should go.

    You can certainly argue that I'm more comfortable with it because I'm
    already familiar with and used to the '@' syntax and actually think it
    may be an improvement over [] because it may be more flexible -- at
    least it is in Java.

    I understand that many are uncomfortable with this feature and idea
    and syntax, but I think we'll find it has compelling value, and the
    fact that it is in both Java and C# (actually, it was invented for C#
    by Anders, I believe, and Java is catching up), and that it fills a
    need in Java that people were inventing comment syntax for, makes it
    worth considering.

    Bruce Eckel
     
    Bruce Eckel, Aug 5, 2004
    #4
  5. Delaney, Timothy C (Timothy)

    John Roth Guest

    Re: Re[2]: Decorator syntax (was Re: PEP 318 - PyFIT comments)

    "Bruce Eckel" <> wrote in message
    news:...
    > I'll weigh in a little on this one.
    >
    > This is very similar to attributes/metadata in Java J2SE 5 and in C#.
    > The thing is, metadata is a little bit weird; it's intentionally
    > outside of the domain of the 'normal' programming language, because it
    > expresses things that you can't or shouldn't within the normal
    > programming language. So you _do_ need an escape mechanism. And it
    > also takes a little bit of getting used to; it's orthogonal to what
    > you normally think of as a language feature. But the potential for
    > metadata features, at least in Java, is very powerful.


    I'd be a lot happier if it was, in fact, a general metadata
    facility. Unfortunately, it only seems to work on functions
    (methods), and for what I'm working on I need metadata
    for properties and fields as well, that is, any identifier that you can
    bind an object to.

    That's not to say I can't use it for something. It looks like
    it might be very useful if I ever get around to writing an
    interactive fiction system in Python. It solves one significant
    problem in such a system - how to put a method into an
    instance cleanly.

    John Roth
    >
    > Bruce Eckel
    >
    >
     
    John Roth, Aug 5, 2004
    #5
  6. Bruce Eckel wrote:

    > This is very similar to attributes/metadata in Java J2SE 5 and in C#.
    > The thing is, metadata is a little bit weird; it's intentionally
    > outside of the domain of the 'normal' programming language, because it
    > expresses things that you can't or shouldn't within the normal
    > programming language. So you _do_ need an escape mechanism.


    But the escape mechanism does not have to take the shape of
    funny, loaded symbols.

    Are these really necessary? Aren't they a just premature
    solution (shortcuts) to a problem that may not even exist?
    I am most irritated by the requirement of spreading out a function
    definition over two lines.

    > also takes a little bit of getting used to; it's orthogonal to what
    > you normally think of as a language feature. But the potential for
    > metadata features, at least in Java, is very powerful.


    I always felt that Java was too rigid and that any kind
    of loosening feels like a breath of fresh air. That is much less the
    case in Python. If anything people sometimes want a little
    more "discipline". This is what this PEP was initially about.
    Too bad that instead of quickly settling at something really
    simple like:

    def static foo():
    ...

    the urge to solve all future problems in the most generic manner
    possible lead to increasingly hairy syntaxes and made
    the decision process so prolonged, fruitless and boring
    that GvR just got fed up with everybody.

    Istvan.
     
    Istvan Albert, Aug 5, 2004
    #6
  7. Re: Re[2]: Decorator syntax (was Re: PEP 318 - PyFIT comments)

    "John Roth" <> writes:

    > "Bruce Eckel" <> wrote in message
    > news:...
    > > I'll weigh in a little on this one.
    > >
    > > This is very similar to attributes/metadata in Java J2SE 5 and in C#.
    > > The thing is, metadata is a little bit weird; it's intentionally
    > > outside of the domain of the 'normal' programming language, because it
    > > expresses things that you can't or shouldn't within the normal
    > > programming language.


    Except, of course, this is Python so there isn't any such thing as
    metadata, really. Objects all the way down.

    > > So you _do_ need an escape mechanism. And it also takes a little
    > > bit of getting used to; it's orthogonal to what you normally think
    > > of as a language feature. But the potential for metadata features,
    > > at least in Java, is very powerful.

    >
    > I'd be a lot happier if it was, in fact, a general metadata
    > facility. Unfortunately, it only seems to work on functions
    > (methods), and for what I'm working on I need metadata for
    > properties and fields as well, that is, any identifier that you can
    > bind an object to.


    Well, that would be because that's impossible :) Where would you
    attach the data in:

    class C(object):
    @funky
    i = 0

    ?

    You can't attach it to 'i' -- that's just a string. '0' is just an
    integer. The class doesn't exist at the time the body is executed.

    What you can do (today) of course is stuff like:

    class C(object):
    i = MagicProperty(int, default=0)

    or something -- which obviously leaves ample space for metadata in the
    argument list -- but that can be painful, I grant.

    What kind of metadata do you want?

    (I have to admit I read your first post on this thread a bit like
    "this hammer doesn't do a very good job of screwing in screws" :)

    Cheers,
    mwh

    --
    It is time-consuming to produce high-quality software. However,
    that should not alone be a reason to give up the high standards
    of Python development. -- Martin von Loewis, python-dev
     
    Michael Hudson, Aug 5, 2004
    #7
  8. Delaney, Timothy C (Timothy)

    John Roth Guest

    Re: Re[2]: Decorator syntax (was Re: PEP 318 - PyFIT comments)

    "Michael Hudson" <> wrote in message
    news:...
    > "John Roth" <> writes:
    >
    > > "Bruce Eckel" <> wrote in message
    > > news:...
    > > > I'll weigh in a little on this one.
    > > >
    > > > This is very similar to attributes/metadata in Java J2SE 5 and in C#.
    > > > The thing is, metadata is a little bit weird; it's intentionally
    > > > outside of the domain of the 'normal' programming language, because it
    > > > expresses things that you can't or shouldn't within the normal
    > > > programming language.

    >
    > Except, of course, this is Python so there isn't any such thing as
    > metadata, really. Objects all the way down.
    >
    > > > So you _do_ need an escape mechanism. And it also takes a little
    > > > bit of getting used to; it's orthogonal to what you normally think
    > > > of as a language feature. But the potential for metadata features,
    > > > at least in Java, is very powerful.

    > >
    > > I'd be a lot happier if it was, in fact, a general metadata
    > > facility. Unfortunately, it only seems to work on functions
    > > (methods), and for what I'm working on I need metadata for
    > > properties and fields as well, that is, any identifier that you can
    > > bind an object to.

    >
    > Well, that would be because that's impossible :)


    I wish you'd have told me that before I did it. As I said in
    a prior post, I had to put a general metadata facility into
    PyFIT, and it's working quite nicely, thank you.

    What I did was put a dictionary with a known name (_typeDict)
    into the class, and stick the metadata in there. It's nowhere near
    as convenient as being able to directly associate it with the
    needed bindings, but it does serve my needs in that particular
    package.

    > Where would you
    > attach the data in:
    >
    > class C(object):
    > @funky
    > i = 0
    >
    > ?
    >
    > You can't attach it to 'i' -- that's just a string. '0' is just an
    > integer. The class doesn't exist at the time the body is executed.


    Two of which are exactly the points I mentioned. The third
    is piffle. If the implementer wanted to do it, there is no reason
    why it couldn't be done.

    >
    > What you can do (today) of course is stuff like:
    >
    > class C(object):
    > i = MagicProperty(int, default=0)
    >
    > or something -- which obviously leaves ample space for metadata in the
    > argument list -- but that can be painful, I grant.
    >
    > What kind of metadata do you want?


    Type and other declaration information for any identifiers
    that will be referenced in the FIT tests. Other information
    includes things like precision for floating point numbers,
    strings that are accepted as "true" or "false" for booleans,
    the subtype for lists and tuples, references to custom
    type adapters and other stuff.

    > (I have to admit I read your first post on this thread a bit like
    > "this hammer doesn't do a very good job of screwing in screws" :)


    Well, that's basically what it said, after all. I was trying to find
    something I could use the facility for. I can always dream up
    ways someone else could use it, but I've found out after long
    and painful experiance that if I'm not the developer in question,
    at best it's a futile exercise.

    That was basically my comment about ctypes. AMK's
    blog entry referenced the ctype's documentation page,
    which didn't tell me anything about what Thomas Heller
    would do with it in the context of that package, and I'm
    not enough of an expert on ctypes to see it myself.

    John Roth
    >
    > Cheers,
    > mwh
    >
    > --
    > It is time-consuming to produce high-quality software. However,
    > that should not alone be a reason to give up the high standards
    > of Python development. -- Martin von Loewis, python-dev
     
    John Roth, Aug 5, 2004
    #8
  9. Re: Re[2]: Decorator syntax (was Re: PEP 318 - PyFIT comments)

    On Thu, 5 Aug 2004 09:06:01 -0400,
    John Roth <> wrote:
    > That was basically my comment about ctypes. AMK's
    > blog entry referenced the ctype's documentation page,


    Heller's post (at
    http://mail.python.org/pipermail/python-dev/2004-June/045139.html) wasn't
    very informative, either; I assume ctypes needs to do 'func =
    something_or_other(func)' as PyObjC does currently.

    --amk
     
    A.M. Kuchling, Aug 5, 2004
    #9
  10. "Delaney, Timothy C (Timothy)" <> wrote in message news:<>...
    > Personally, I don't overly like the new syntax - I much preferred def
    > func (args) [decorators] - and I would have preferred not to "waste" @
    > for them, but I can definitely live with the decision. Some usable
    > decorator syntax is IMO more important than none.


    This also my opinion, more or less. It is just the "@" which is ugly.
    Why not to overload (once more) the colon and write:

    :classmethod
    def func (cls, *args, **kw):
    pass

    ? Only half serious ...


    Michele Simionato
     
    Michele Simionato, Aug 5, 2004
    #10
  11. Delaney, Timothy C (Timothy)

    John Roth Guest

    Re: Re[2]: Decorator syntax (was Re: PEP 318 - PyFIT comments)

    "A.M. Kuchling" <> wrote in message
    news:...
    > On Thu, 5 Aug 2004 09:06:01 -0400,
    > John Roth <> wrote:
    > > That was basically my comment about ctypes. AMK's
    > > blog entry referenced the ctype's documentation page,

    >
    > Heller's post (at
    > http://mail.python.org/pipermail/python-dev/2004-June/045139.html) wasn't
    > very informative, either; I assume ctypes needs to do 'func =
    > something_or_other(func)' as PyObjC does currently.


    I see; that's not very informative.

    What ctypes does is create a specialized object to
    represent a particular c function, variable, array or
    struct; then you use those objects as part of the
    interface when you call the c function you're going
    after.

    Possibly he's got something in mind to streamline
    the construction of the supporting objects for
    a given C API call.

    It does, however, seem like something that would
    be appropriate for function decorators.

    John Roth
    >
    > --amk
     
    John Roth, Aug 5, 2004
    #11
  12. Istvan Albert <> wrote in message news:<>...
    > I always felt that Java was too rigid and that any kind
    > of loosening feels like a breath of fresh air.


    Yeah, I felt the same way. I really like that Python hasn't been
    deathly afraid of backwards incompatibility, at least when it was
    minor and introducing the backwards incompatibility made the language
    cleaner and more powerful.

    The whole @ syntax reminds me of Java's : syntax for their enhanced
    for-loop. From http://java.sun.com/developer/technicalArticles/releases/j2se15langfeat:
    "Many developers are asking why they didn't add the foreach and in so
    that we can write:
    foreach (element in collection)
    The fact of the matter is that adding new keywords to a language such
    as Java is quite costly. In addition, it wouldn't be compatible with
    existing source code that uses the in keyword, for example, as in
    System.in. So the whole idea is just to keep things
    upwardly-compatible."

    These are, of course, the standard reasons against introducing new
    keywords, and the same reasons that Python tries not to introduce them
    unnecessarily. Still, I think, for example, the 'yield' generator
    syntax (which was introduced relatively recently) is much clearer than
    doing something strange with punctuation would have been. I guess I
    just don't see why decorators merit strange punctuation when
    generators didn't...

    (Notice that if Java's 'foreach' discussion came up in Python --
    assuming Python didn't already have the 'for' construction -- the
    'foreach' keyword would probably have been added without hesitation
    because it would be quickly deemed a very minor backwards
    incompatibility.)

    Steve
     
    Steven Bethard, Aug 5, 2004
    #12
  13. (Steven Bethard) writes:

    > These are, of course, the standard reasons against introducing new
    > keywords, and the same reasons that Python tries not to introduce them
    > unnecessarily. Still, I think, for example, the 'yield' generator
    > syntax (which was introduced relatively recently) is much clearer than
    > doing something strange with punctuation would have been. I guess I
    > just don't see why decorators merit strange punctuation when
    > generators didn't...


    Also, in the case of Java, keywords actually have been introduced
    (strictfp, assert), in the latter case leading to a rewrite of the
    "standard" unit test library JUnit which changed a framework method
    name (assert() -> assertTrue()).

    However, a "foreach" would just pollute (in a sense) as long as it's
    very close to for, and it demantically makes sense to "reuse" it
    instead (like they do for "class", which both is used in a class
    declaration and to access a class object statically). Both strictfp
    and assert did new things that didn't match what any other language
    feature did.
     
    Tor Iver Wilhelmsen, Aug 5, 2004
    #13
  14. Delaney, Timothy C (Timothy)

    Yu Wang Guest

    I'm not an active guy in the groups.But I do agree with Mike.
    If there is a vote. I'll vote for this reply.
    Please consider a more elegant way.

    Michael Ressler <> wrote in message news:<>...
    > On 2004-08-04, Delaney, Timothy C (Timothy) <> wrote:
    > > Christopher T King wrote:
    > >
    > >> On 4 Aug 2004, Nick Vargish wrote:
    > >>
    > >>> I just don't know where else to voice my opinion on this matter, but
    > >>> I absolutely hate the new decorator syntax.

    > >
    > > @classmethod
    > > def func (args):
    > > @attr = 1
    > > pass

    >
    > I'm just a dumb user of Python - I don't even program for a living, so
    > there is no reason any of you should listen to me, but this @-syntax
    > thing makes Python look like Perl. The reason I learned Python was that
    > Perl looks like line noise to me, and I wanted a scripting language I
    > could read. Please don't wreck a beautiful, readable language with this
    > shortcut. Choose a word for it, not a symbol, please.
    >
    > Mike
     
    Yu Wang, Aug 6, 2004
    #14
  15. Re: Re[2]: Decorator syntax (was Re: PEP 318 - PyFIT comments)

    This reply was a touch more hostile that I was expecting; if I've hit
    some nerve, sorry, if not, err, can you relax a bit?

    "John Roth" <> writes:

    > "Michael Hudson" <> wrote in message
    > news:...
    >
    > > Well, that would be because that's impossible :)

    >
    > I wish you'd have told me that before I did it. As I said in
    > a prior post, I had to put a general metadata facility into
    > PyFIT, and it's working quite nicely, thank you.


    OK, poor choice of words.

    [snippity]

    > > What kind of metadata do you want?

    >
    > Type and other declaration information for any identifiers
    > that will be referenced in the FIT tests. Other information
    > includes things like precision for floating point numbers,
    > strings that are accepted as "true" or "false" for booleans,
    > the subtype for lists and tuples, references to custom
    > type adapters and other stuff.


    So, you would like to write

    class Thiny(object):
    @attribute(type=float, precision=3)
    a = 1.23

    ?

    I really don't see how you could make that work. attribute() could
    return something that was called with the dictionary being inserted
    into, the string 'a' and the value 1.23, but... ick. I don't think I
    like that idea. What would you find helpful?

    Cheers,
    mwh

    --
    ... but I'd rather not reinvent the wheel if I don't have to. On
    the other hand, if the currently instantiated version of the wheel
    consists of a square rock covered with moss, I might as well just
    start fresh. -- Roy Smith, comp.lang.python
     
    Michael Hudson, Aug 6, 2004
    #15
  16. Delaney, Timothy C (Timothy)

    John Roth Guest

    Re: Re[2]: Decorator syntax (was Re: PEP 318 - PyFIT comments)

    "Michael Hudson" <> wrote in message
    news:...
    > This reply was a touch more hostile that I was expecting; if I've hit
    > some nerve, sorry, if not, err, can you relax a bit?
    >
    > "John Roth" <> writes:
    >
    > > "Michael Hudson" <> wrote in message
    > > news:...
    > >
    > > > Well, that would be because that's impossible :)

    > >
    > > I wish you'd have told me that before I did it. As I said in
    > > a prior post, I had to put a general metadata facility into
    > > PyFIT, and it's working quite nicely, thank you.

    >
    > OK, poor choice of words.
    >
    > [snippity]
    >
    > > > What kind of metadata do you want?

    > >
    > > Type and other declaration information for any identifiers
    > > that will be referenced in the FIT tests. Other information
    > > includes things like precision for floating point numbers,
    > > strings that are accepted as "true" or "false" for booleans,
    > > the subtype for lists and tuples, references to custom
    > > type adapters and other stuff.

    >
    > So, you would like to write
    >
    > class Thiny(object):
    > @attribute(type=float, precision=3)
    > a = 1.23
    >
    > ?
    >
    > I really don't see how you could make that work. attribute() could
    > return something that was called with the dictionary being inserted
    > into, the string 'a' and the value 1.23, but... ick. I don't think I
    > like that idea. What would you find helpful?


    Well, what I need here is very simple. If the FIT test contains
    a column labeled "a", then I need to find the type. If it's a float,
    I need to find the default precision for the compare. (Actually,
    float is a poor choice here - I fixed the need to have a precision
    by using the precision information in the text version of the float,
    but that's a different conversation.)

    What I'm doing right now is this:

    class fubar:
    _typeDict = {}
    _typeDict['a'] = "float"
    _typeDict['a.precision'] = 3

    Note that I'm not defining 'a' on the class level. Whether or not
    I need a default value is a purely tactical decision that's orthogonal
    to the need for metadata in this application.

    A somewhat better (if whimsical) example of the need for
    structured metadata is:

    _typeDict['b'] = "boolean"
    _typeDict['b.false'] = "fubar"

    This makes the boolean type adapter accept the string 'fubar'
    as 'false'. (It doesn't make it print it that way, though.)

    Or a much more pedestrian example:

    _typeDict['d'] = "date"
    _typeDict['d.parse'] = "some %format string"
    _typeDict['d.print'] = 'some other %format string'

    The operands being, of course, something you can feed to the
    appropriate functions in the time or datetime modules.

    Notice that in all three cases I want to associate several pieces of
    metadata with an identifier in the class. I don't want to associate
    it with a particular object (although there are other applications that
    would want to do that, especially for functions).

    Also note that one of the two pieces of metadata is probably generally
    useful (the type). The other is highly specific to my application.

    John Roth


    >
    > Cheers,
    > mwh
    >
    > --
    > ... but I'd rather not reinvent the wheel if I don't have to. On
    > the other hand, if the currently instantiated version of the wheel
    > consists of a square rock covered with moss, I might as well just
    > start fresh. -- Roy Smith, comp.lang.python
     
    John Roth, Aug 6, 2004
    #16
  17. Hi,

    after thinking all day I hope I've found the option I like more:

    #decorator
    def func (cls, *args, **kw):
    pass

    .... and it's compatible with old versions of python :)

    seriously, I prefer next options, they are more readable:

    1)
    def func (cls, *args, **kw):
    .deco
    pass

    2)
    def func (cls, *args, **kw):
    __deco__
    pass

    i.e., not before or inside function definition.



    Best regards,
    Iñigo

    El jue, 05-08-2004 a las 07:32 -0700, Michele Simionato escribió:
    > "Delaney, Timothy C (Timothy)" <> wrote in message news:<>...
    > > Personally, I don't overly like the new syntax - I much preferred def
    > > func (args) [decorators] - and I would have preferred not to "waste" @
    > > for them, but I can definitely live with the decision. Some usable
    > > decorator syntax is IMO more important than none.


    > This also my opinion, more or less. It is just the "@" which is ugly.
    > Why not to overload (once more) the colon and write:
    >
    > :classmethod
    > def func (cls, *args, **kw):
    > pass
    >
    > ? Only half serious ...
    >
    > Michele Simionato



    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.2.5 (GNU/Linux)

    iD8DBQBBE9X8yEiL8H0Z6/ERAsPSAJ9s5+yd7qT1Pl4ADC3dGrmFaBVqxwCfccvy
    Xq3FBabs7RXFh/pNWVD2jPw=
    =LnXL
    -----END PGP SIGNATURE-----
     
    =?ISO-8859-1?Q?I=F1igo?= Serna, Aug 6, 2004
    #17
    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. John Roth

    PEP 318 - PyFIT comments

    John Roth, Aug 4, 2004, in forum: Python
    Replies:
    7
    Views:
    391
    Nick Vargish
    Aug 6, 2004
  2. Edward K. Ream

    Confused about pep 318

    Edward K. Ream, Aug 4, 2004, in forum: Python
    Replies:
    45
    Views:
    1,002
    Shalabh Chaturvedi
    Aug 6, 2004
  3. Hallvard B Furuseth

    pep-318 questions

    Hallvard B Furuseth, Aug 8, 2004, in forum: Python
    Replies:
    3
    Views:
    340
    Hallvard B Furuseth
    Aug 28, 2004
  4. Tim Hochberg
    Replies:
    0
    Views:
    281
    Tim Hochberg
    Aug 10, 2004
  5. Arien Malec

    PEP 318 decorators are not Decorators

    Arien Malec, Aug 13, 2004, in forum: Python
    Replies:
    11
    Views:
    588
    Arien Malec
    Aug 16, 2004
Loading...

Share This Page