__autoinit__ (Was: Proposal: reducing self.x=x; self.y=y;self.z=z boilerplate code)

Discussion in 'Python' started by Ralf W. Grosse-Kunstleve, Jul 9, 2005.

  1. My initial proposal
    (http://cci.lbl.gov/~rwgk/python/adopt_init_args_2005_07_02.html) didn't
    exactly get a warm welcome...

    And Now for Something Completely Different:

    class autoinit(object):

    def __init__(self, *args, **keyword_args):
    self.__dict__.update(
    zip(self.__autoinit__.im_func.func_code.co_varnames[1:], args))
    self.__dict__.update(keyword_args)
    self.__autoinit__(*args, **keyword_args)

    class grouping(autoinit):

    def __autoinit__(self, x, y, z):
    print self.x, self.y, self.z

    group = grouping(1,2,z=3)
    group = grouping(z=1,x=2,y=3)
    try: grouping(1)
    except TypeError, e: print e
    try: grouping(1,2,3,a=0)
    except TypeError, e: print e


    Almost like my original favorite solution, only better, and it doesn't require
    a syntax change.

    Under a hypothetical new proposal __autoinit__ would become a standard feature
    of object.

    Any takers?

    Cheers,
    Ralf


    __________________________________________________
    Do You Yahoo!?
    Tired of spam? Yahoo! Mail has the best spam protection around
    http://mail.yahoo.com
     
    Ralf W. Grosse-Kunstleve, Jul 9, 2005
    #1
    1. Advertising

  2. Ralf W. Grosse-Kunstleve

    Kay Schluehr Guest

    Re: __autoinit__ (Was: Proposal: reducing self.x=x; self.y=y; self.z=z boilerplate code)

    Ralf W. Grosse-Kunstleve schrieb:
    > My initial proposal
    > (http://cci.lbl.gov/~rwgk/python/adopt_init_args_2005_07_02.html) didn't
    > exactly get a warm welcome...


    Well ... yes ;)

    Ralf, if you want to modify the class instantiation behaviour you
    should have a look on metaclasses. That's what they are for. It is not
    a particular good idea to integrate a new method into the object base
    class for each accidental idea and write a PEP for it.

    I provide you an example which is actually your use case. It doesn't
    change the class hierarchy : the metaclass semantics is not "is a" as
    for inheritance but "customizes" as one would expect also for
    decorators.

    class autoattr(type):
    '''
    The autoattr metaclass is used to extract auto_xxx parameters from
    the argument-tuple or the keyword arguments of an object
    constructor __init__
    and create object attributes mit name xxx and the value of auto_xxx
    passed
    into __init__
    '''
    def __init__(cls,name, bases, dct):
    super(autoattr,cls).__init__(name,bases,dct)
    old_init = cls.__init__
    defaults = cls.__init__.im_func.func_defaults
    varnames = cls.__init__.im_func.func_code.co_varnames[1:]

    def new_init(self,*args,**kwd):
    for var,default in zip(varnames[-len(defaults):],defaults):
    if var.startswith("auto_"):
    self.__dict__[var[5:]] = default
    for var,arg in zip(varnames,args):
    if var.startswith("auto_"):
    self.__dict__[var[5:]] = arg
    for (key,val) in kwd.items():
    if key.startswith("auto_"):
    self.__dict__[key[5:]] = val
    old_init(self,*args,**kwd)
    cls.__init__ = new_init

    class app:
    __metaclass__ = autoattr
    def __init__(self, auto_x, y, auto_z = 9):
    pass

    >>> a = app(2,5)
    >>> a.x

    2
    >>> a.z

    9
    >>> a.y

    -> AttributeError


    Kay
     
    Kay Schluehr, Jul 9, 2005
    #2
    1. Advertising

  3. Re: __autoinit__ (Was: Proposal: reducing self.x=x; self.y=y;self.z=zboilerplate code)

    Ralf W. Grosse-Kunstleve wrote:
    > My initial proposal
    > (http://cci.lbl.gov/~rwgk/python/adopt_init_args_2005_07_02.html) didn't
    > exactly get a warm welcome...
    >
    > And Now for Something Completely Different:
    >
    > class autoinit(object):
    >
    > def __init__(self, *args, **keyword_args):
    > self.__dict__.update(
    > zip(self.__autoinit__.im_func.func_code.co_varnames[1:], args))
    > self.__dict__.update(keyword_args)
    > self.__autoinit__(*args, **keyword_args)

    Should be:
    class autoinit(object):
    def __init__(self, *args, **keyword_args):
    for name, value in zip(self.__autoinit__.im_func.func_code.
    co_varnames[1:], args):
    setattr(self, name, value)
    for name, value in keyword_args.items():
    setattr(self, name, value)
    self.__autoinit__(*args, **keyword_args)

    Since using setattr will take care of any slots used in other classes.
    Not all data is stored in the __dict__.

    For example:

    class Example(autoinit):
    __slots__ = 'abc',
    def __autoinit__(self, a=1, abc=1):
    print a, abc

    a = Example(1,2)
    print a.__dict__
    print a.a
    print a.abc


    --Scott David Daniels
     
    Scott David Daniels, Jul 10, 2005
    #3
  4. Ralf W. Grosse-Kunstleve

    Kay Schluehr Guest

    Re: __autoinit__ (Was: Proposal: reducing self.x=x; self.y=y; self.z=z boilerplate code)

    > I stripped your code down to the essence. See attachment.
    > For the user your approach then becomes:
    >
    > class grouping:
    > __metaclass__ = autoattr
    > def __init__(self, x, y, z):
    > pass


    No. This is clearly NOT what I had in mind. I translated your original
    proposal which introduced a punctuation syntax '.x' for constructor
    parameters forcing the interpreter to create equally named object
    attributes into a naming convention that can be handled by a metaclass
    customizer. The grouping.__init__ above does exacly nothing according
    to my implementation. I would never accept dropping fine-tuning
    capabilities. The "auto_" prefix is all the declarative magic.

    > My __autoinit__ suggestion would result in (assuming object supports
    > this by default):
    >
    > class grouping(object):
    > def __autoinit__(self, x, y, z):
    > pass
    >
    > I think that's far more intuitive.


    Being intuitive is relative to someones intuition.

    Kay
     
    Kay Schluehr, Jul 10, 2005
    #4
  5. Ralf W. Grosse-Kunstleve

    Terry Reedy Guest

    "Ralf W. Grosse-Kunstleve" <> wrote in message
    news:...

    I have a suggestion I don't remember seeing for flagging which vars to
    autoinit without new syntax: use '_' instead of '.'. I have never seen
    local vars with a leading '_'. So, in combination with whatever other
    mechanism (metaclass, __init__ decorator?)

    def __init__(self, _x, y, _z) :

    would automatically do self.x = _x, self.z = _z, but not self.y = y.

    Terry J. Reedy
     
    Terry Reedy, Jul 10, 2005
    #5
  6. AST decoration vs byte-code-munging (Was: Re: __autoinit__ (Was: Proposal: reducing self.x=x; self.y=y; self.z=z boilerplate code))

    On Sun, 10 Jul 2005 16:26:24 -0400, "Terry Reedy" <> wrote:

    >
    >"Ralf W. Grosse-Kunstleve" <> wrote in message
    >news:...
    >
    >I have a suggestion I don't remember seeing for flagging which vars to
    >autoinit without new syntax: use '_' instead of '.'. I have never seen
    >local vars with a leading '_'. So, in combination with whatever other
    >mechanism (metaclass, __init__ decorator?)
    >
    > def __init__(self, _x, y, _z) :
    >
    >would automatically do self.x = _x, self.z = _z, but not self.y = y.
    >

    Of course, if it works for __init__, it should work for an arbitrary
    method or even function (if a decorator is used).

    I think I could write a byte-code-modifying decorator that would insert
    code at the beginning of a function to do the
    self.x = _x; self.z = _z # but not self.y = y
    in your example, and similarly for others.
    But I am not sure it's not a waste of time to do these byte-code things
    except to see how using such decorators feels in practice, or whether any
    byte-code munging after generation is a good idea.

    What would be the next step? To implement the same in C as a built in decorator?
    I'm wondering if the effort of munging byte code isn't misplaced, and would create
    a growing maintenance problem as more built-in decorators like that accumulated.

    So, if we want alternate code generated, perhaps we need a way of talking to the
    original code generation process? I'm thinking some kind of source-processing-time
    decorator (maybe marked with double-@, like
    @@auto_init_self_attributes
    def __init__(self, _x, y, _z) : print 'self.y=%r not set'%y

    The idea is for @@deco to be intercepted as part of the AST of the unit being compiled,
    and be converted at that time to call with the AST and its own location in the tree being
    passed to it so it can do mods to the AST (and cut itself out), and then let the resulting
    AST be compiled as normal. Multiple @@decorators would each get their chance to mod the AST
    before compilation. This still would have some version dependency, but it wouldn't be
    byte code hacking ;-) One of these days I'll think some more on @@. As an experiment, I think
    the tokenizer could translate @@deco to _AT_AT_deco and let the AST be formed with that
    apparent function call at that place in the code. Then the AST could be walked to find the _AT_AT_<deconame>
    calls and extract them and compile them and execute them (the _AT_AT_deco functions would
    obviously have to be defined already, so they might be looked up in some standard place
    like trying to do place = __import__(_AT_AT_MODULE_) wher _AT_AT_MODULE_ gets defined sort
    of like __METACLASS__.), passing the AST and the _AT_AT_deco call location therein, and the rest
    of the parameters.

    AST decoration would introduce macro-like capabilities, but restricted to transforming valid ASTs,
    so it isn't like source text rewriting macros.

    Sorry for the run-on stream of consciousness ;-/

    Regards,
    Bengt Richter
     
    Bengt Richter, Jul 10, 2005
    #6
  7. Ralf W. Grosse-Kunstleve

    Dan Sommers Guest

    Re: __autoinit__ (Was: Proposal: reducing self.x=x; self.y=y; self.z=z boilerplate code)

    On Sun, 10 Jul 2005 16:26:24 -0400,
    "Terry Reedy" <> wrote:

    > "Ralf W. Grosse-Kunstleve" <> wrote in message
    > news:...


    > I have a suggestion I don't remember seeing for flagging which vars to
    > autoinit without new syntax: use '_' instead of '.'. I have never seen
    > local vars with a leading '_'. So, in combination with whatever other
    > mechanism (metaclass, __init__ decorator?)


    > def __init__(self, _x, y, _z) :


    > would automatically do self.x = _x, self.z = _z, but not self.y = y.


    > Terry J. Reedy


    That's a pretty big change; now all formal parameters beginning with an
    underscore have a brand new meaning.

    How about this:

    def __init__(self, self.x, y, self.z):
    # self.x, self.z from first and third explicit parameters
    do_something_with_y()

    where "self" in "self.x" and "self.y" would have to match the first
    parameter (so that the pathological among us could write this:

    def __init__(this, this.x, y, this.z):
    do_something_with_y()

    instead).

    (Sorry if this posts multiple times; gnus and/or my news server were not
    happy when I was composing this reply.)

    Regards,
    Dan

    --
    Dan Sommers
    <http://www.tombstonezero.net/dan/>
     
    Dan Sommers, Jul 11, 2005
    #7
  8. Ralf W. Grosse-Kunstleve

    Paul Rubin Guest

    Re: __autoinit__ (Was: Proposal: reducing self.x=x; self.y=y; self.z=z boilerplate code)

    Dan Sommers <> writes:
    > def __init__(self, self.x, y, self.z):
    > # self.x, self.z from first and third explicit parameters
    > do_something_with_y()


    Hey, I like that.
     
    Paul Rubin, Jul 11, 2005
    #8
  9. Ralf W. Grosse-Kunstleve

    Terry Reedy Guest

    "Dan Sommers" <> wrote in message
    news:...
    > On Sun, 10 Jul 2005 16:26:24 -0400,
    > "Terry Reedy" <> wrote:
    >> I have a suggestion I don't remember seeing for flagging which vars to
    >> autoinit without new syntax: use '_' instead of '.'. I have never seen
    >> local vars with a leading '_'. So, in combination with whatever other
    >> mechanism (metaclass, __init__ decorator?)

    >
    >> def __init__(self, _x, y, _z) :

    >
    >> would automatically do self.x = _x, self.z = _z, but not self.y = y.

    >
    >> Terry J. Reedy

    >
    > That's a pretty big change; now all formal parameters beginning with an
    > underscore have a brand new meaning.


    As I said, 'in combination with whatever other mechanism', meaning one that
    one has to intentionally invoke. So there would be no code breaking: the
    suggestion is for a convention used with currently available mechanism
    (assuming that such is possible) that would give the fine-grained control
    not so easily possible with the current update_dict_with_locals idiom.

    It would be easier to write the decorator if it were passed the (quoted)
    names of the parameters to be 'attributed'. But then the user would have
    to write and keep in synchrony two lists, one a (quoted) subset of the
    other. So I thought it better to have the decorator writer and decorator
    function work a little harder to introspect and interpret one list with
    some items marked somehow in a currently legal but unusual manner.

    > How about this:
    >
    > def __init__(self, self.x, y, self.z):
    > # self.x, self.z from first and third explicit parameters


    This is new syntax that is not currently legal. My suggestion was for a
    solution that avoided that difficulty and that could, I believe, be
    implemented now, in less time that this thread has been going on, rather
    than maybe some years from now.

    Terry J. Reedy
     
    Terry Reedy, Jul 11, 2005
    #9
  10. Ralf W. Grosse-Kunstleve

    Dan Sommers Guest

    Re: __autoinit__ (Was: Proposal: reducing self.x=x; self.y=y; self.z=z boilerplate code)

    On Sun, 10 Jul 2005 20:11:38 -0400,
    "Terry Reedy" <> wrote:

    > "Dan Sommers" <> wrote in message
    > news:...


    >> That's a pretty big change; now all formal parameters beginning with
    >> an underscore have a brand new meaning.


    > As I said, 'in combination with whatever other mechanism', meaning one
    > that one has to intentionally invoke ...


    My mistake; I didn't read carefully enough.

    Regards,
    Dan

    --
    Dan Sommers
    <http://www.tombstonezero.net/dan/>
     
    Dan Sommers, Jul 11, 2005
    #10
  11. Re: __autoinit__ (Was: Proposal: reducing self.x=x; self.y=y; self.z=z boilerplate code)

    On 10 Jul 2005 16:07:40 -0700, Paul Rubin <http://> wrote:

    >Dan Sommers <> writes:
    >> def __init__(self, self.x, y, self.z):
    >> # self.x, self.z from first and third explicit parameters
    >> do_something_with_y()

    >
    >Hey, I like that.


    Me too. I liked the leading _, but on second thought it is a weird language change
    re names in a special context. Probably not so good.

    OTOH, I see in the above a generalizable principle of formal parameter expressions as
    automatic assignment targets at the beginning of function execution that could allow
    anything normally allowed locally on the left of an assignment. This is contrived,
    but illustrates:

    def setem(key, adict[key]): pass # note that assignment is left-right,
    # so key is available for adict[key]
    # and adict is global here
    adict = {}
    setem('k', 'value')
    adict -> {'k':'value'}

    Regards,
    Bengt Richter
     
    Bengt Richter, Jul 11, 2005
    #11
  12. Ralf W. Grosse-Kunstleve

    Kay Schluehr Guest

    Re: __autoinit__ (Was: Proposal: reducing self.x=x; self.y=y; self.z=z boilerplate code)

    Dan Sommers schrieb:

    > How about this:
    >
    > def __init__(self, self.x, y, self.z):
    > # self.x, self.z from first and third explicit parameters
    > do_something_with_y()


    Can you tell me in which way it is anyhow better than the original
    proposal

    def __init__(self, .x, y, .z):
    # self.x, self.z from first and third explicit parameters
    do_something_with_y()

    besides that it is more verbose?

    Kay
     
    Kay Schluehr, Jul 11, 2005
    #12
  13. Ralf W. Grosse-Kunstleve

    Terry Reedy Guest

    "Bengt Richter" <> wrote in message
    news:...
    > Me too. I liked the leading _, but on second thought it is a weird
    > language change
    > re names in a special context. Probably not so good.


    To repeat: while my '_' proposal could have been for a language change (in
    3.0), it was actually for a convention recognized by a metaclass or, more
    likely, decorator (and implementable now, I think). *Any* flag would serve
    the purpose, but I picked one that was a single char while being visually
    striking and, as far as I know, rarely used in current practice even though
    quite legal. A 'self_' prefix would do as well except for being more to
    type. The prefix could even be an argument to the decorator!

    Terry J. Reedy
     
    Terry Reedy, Jul 11, 2005
    #13
  14. Re: __autoinit__ (Was: Proposal: reducing self.x=x; self.y=y; self.z=zboilerplate code)

    Kay Schluehr wrote:
    > Dan Sommers schrieb:
    >
    >> How about this:
    >>
    >> def __init__(self, self.x, y, self.z):
    >> # self.x, self.z from first and third explicit parameters
    >> do_something_with_y()

    >
    > Can you tell me in which way it is anyhow better than the original
    > proposal
    >
    > def __init__(self, .x, y, .z):
    > # self.x, self.z from first and third explicit parameters
    > do_something_with_y()
    >
    > besides that it is more verbose?


    It is more explicit. Explicit is better than implicit.

    But as with many proposals, this raises consequential questions, for
    example, how "self.x" parameters are handled in other methods, or even
    functions, as __init__ is not special-cased by the parser.

    Reinhold
     
    Reinhold Birkenfeld, Jul 11, 2005
    #14
  15. Ralf W. Grosse-Kunstleve

    Kay Schluehr Guest

    Re: __autoinit__ (Was: Proposal: reducing self.x=x; self.y=y; self.z=z boilerplate code)

    Reinhold Birkenfeld schrieb:
    > Kay Schluehr wrote:
    > > Dan Sommers schrieb:
    > >
    > >> How about this:
    > >>
    > >> def __init__(self, self.x, y, self.z):
    > >> # self.x, self.z from first and third explicit parameters
    > >> do_something_with_y()

    > >
    > > Can you tell me in which way it is anyhow better than the original
    > > proposal
    > >
    > > def __init__(self, .x, y, .z):
    > > # self.x, self.z from first and third explicit parameters
    > > do_something_with_y()
    > >
    > > besides that it is more verbose?

    >
    > It is more explicit. Explicit is better than implicit.


    The punctuation syntax makes it explicit too. But maybe a point is a
    more tiny and less explicit symbol than an @ that makes a decorator
    explicit ;)

    > But as with many proposals, this raises consequential questions, for
    > example, how "self.x" parameters are handled in other methods, or even
    > functions, as __init__ is not special-cased by the parser.
    >
    > Reinhold


    Yes. My argument against the syntax is more that of a language lawyer:
    how a class uses the argument parameters of a constructor is an
    implementation detail of a class and should not be published in the
    constructor interface.

    One may assign special attributes to the classes ( e.g. tagging it with
    a metaclass ) or a qualifier. I had recently a look on Scala an
    object-functional language running on top of the JVM. Scala introduces
    the concept of a "case class" to represent object trees. All arguments
    passed into a case class constructor become automagically object
    attributes. This is for convenience and let the tree grow if the passed
    arguments are case class instances again. Here it is the class type
    that determines how it's construction is handled. I think this is a
    reasonable approach.

    Kay
     
    Kay Schluehr, Jul 11, 2005
    #15
  16. Ralf W. Grosse-Kunstleve

    Dan Sommers Guest

    Re: __autoinit__ (Was: Proposal: reducing self.x=x; self.y=y; self.z=z boilerplate code)

    On Mon, 11 Jul 2005 08:34:45 +0200,
    Reinhold Birkenfeld <> wrote:

    > Kay Schluehr wrote:
    >> Dan Sommers schrieb:
    >>
    >>> How about this:
    >>>
    >>> def __init__(self, self.x, y, self.z):
    >>> # self.x, self.z from first and third explicit parameters
    >>> do_something_with_y()

    >>
    >> Can you tell me in which way it is anyhow better than the original
    >> proposal
    >>
    >> def __init__(self, .x, y, .z):
    >> # self.x, self.z from first and third explicit parameters
    >> do_something_with_y()
    >>
    >> besides that it is more verbose?


    > It is more explicit. Explicit is better than implicit.


    > But as with many proposals, this raises consequential questions, for
    > example, how "self.x" parameters are handled in other methods, or even
    > functions, as __init__ is not special-cased by the parser.


    So why limit it to __init__? Bengt Richter's idea of generalizing it is
    a good one. Currently, when this method:

    def f(self, x, y, z):
    pass

    is called, Python binds self to a reference to the object, x to the
    first argument, y to the second argument, z to and the third. By
    extension, hypothetically, this method:

    def new_f(self, self.x, y, self.z):
    do_something_with_y()

    would be semantically identical to:

    def new_f(self, __anonymous_argument_1, y, __anonymous_argument_2):
    self.x = __anonymous_argument_1
    del __anonymous_argument_1 # look: a use case for del! <wink>
    self.z = __anonymous_argument_2
    del __anonymous_argument_2
    do_something_with_y()

    It's not too far from the tuple unpacking that happens now:

    def g(x, (a, b)):
    pass

    q = (3, 4)
    g(1, q) # inside g, x = 1, a = q[0] = 3, b = q[1] = 4

    and it's certainly not less explicit than properties.

    Without thinking it all the way through, I suppose these:

    def method_1(self, *self.l):
    pass
    def method_2(self, **self.d):
    pass

    could act as if they were these:

    def method_1(self, *args):
    self.l = args
    del args
    def method_2(self, **kw):
    self.d = kw
    del kw

    Regards,
    Dan

    --
    Dan Sommers
    <http://www.tombstonezero.net/dan/>
     
    Dan Sommers, Jul 11, 2005
    #16
  17. Re: __autoinit__ (Was: Proposal: reducing self.x=x; self.y=y; self.z=zboilerplate code)

    Dan Sommers wrote:

    > Without thinking it all the way through, I suppose these:
    >
    > def method_1(self, *self.l):
    > pass
    > def method_2(self, **self.d):
    > pass
    >
    > could act as if they were these:
    >
    > def method_1(self, *args):
    > self.l = args
    > del args
    > def method_2(self, **kw):
    > self.d = kw
    > del kw


    I still think it's too specialized. What would, hypothetically, this do?

    class Bar: pass

    class Foo:
    x = Bar()
    def method_1(self, x.y):
    pass

    It's hard to explain that you can autoassign self.y but not x.y.

    Reinhold
     
    Reinhold Birkenfeld, Jul 11, 2005
    #17
  18. Re: __autoinit__ (Was: Proposal: reducing self.x=x; self.y=y; self.z=z boilerplate code)

    On Mon, 11 Jul 2005 01:44:07 -0400, "Terry Reedy" <> wrote:

    >
    >"Bengt Richter" <> wrote in message
    >news:...
    >> Me too. I liked the leading _, but on second thought it is a weird
    >> language change
    >> re names in a special context. Probably not so good.

    >
    >To repeat: while my '_' proposal could have been for a language change (in
    >3.0), it was actually for a convention recognized by a metaclass or, more
    >likely, decorator (and implementable now, I think). *Any* flag would serve
    >the purpose, but I picked one that was a single char while being visually
    >striking and, as far as I know, rarely used in current practice even though
    >quite legal. A 'self_' prefix would do as well except for being more to
    >type. The prefix could even be an argument to the decorator!
    >

    Yes, sorry, I should have read more carefully. Yours is the high ground ;-)

    Regards,
    Bengt Richter
     
    Bengt Richter, Jul 11, 2005
    #18
  19. Re: __autoinit__ (Was: Proposal: reducing self.x=x; self.y=y; self.z=z boilerplate code)

    On Mon, 11 Jul 2005 15:37:35 +0200, Reinhold Birkenfeld <> wrote:

    >Dan Sommers wrote:
    >
    >> Without thinking it all the way through, I suppose these:
    >>
    >> def method_1(self, *self.l):
    >> pass
    >> def method_2(self, **self.d):
    >> pass
    >>
    >> could act as if they were these:
    >>
    >> def method_1(self, *args):
    >> self.l = args
    >> del args
    >> def method_2(self, **kw):
    >> self.d = kw
    >> del kw

    >
    >I still think it's too specialized. What would, hypothetically, this do?
    >
    >class Bar: pass
    >
    >class Foo:
    > x = Bar()
    > def method_1(self, x.y):
    > pass
    >
    >It's hard to explain that you can autoassign self.y but not x.y.
    >

    No, that limitation wouldn't exist, so you wouldn't have to explain it ;-)
    I.e., the above would act like

    class Foo:
    x = Bar()
    def method_1(self, _anonymous_arg_1):
    x.y = _anonymous_arg_1

    and would do whatever it would do now (probably look for a global x or a closure cell x, but
    it wouldn't find the class variable in a normal method call)

    Regards,
    Bengt Richter
     
    Bengt Richter, Jul 11, 2005
    #19
    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. dwok
    Replies:
    2
    Views:
    474
    Lucas Tam
    May 11, 2005
  2. Ralf W. Grosse-Kunstleve
    Replies:
    16
    Views:
    589
    Lonnie Princehouse
    Jul 11, 2005
  3. Ralf W. Grosse-Kunstleve
    Replies:
    2
    Views:
    407
    Dan Sommers
    Jul 12, 2005
  4. falcon
    Replies:
    0
    Views:
    380
    falcon
    Jul 31, 2005
  5. Nick Coghlan

    Reducing import try/except boilerplate

    Nick Coghlan, Dec 21, 2005, in forum: Python
    Replies:
    1
    Views:
    324
    Bengt Richter
    Dec 21, 2005
Loading...

Share This Page