Re: Python becoming less Lisp-like

Discussion in 'Python' started by Fernando, Mar 14, 2005.

  1. Fernando

    Fernando Guest

    On Sun, 13 Mar 2005 18:23:05 GMT, Peter Seibel <>
    wrote:

    >Looks like the BDFL is planning to take lambda, reduce, filter, and
    >map out of Python in the next big rev of Python (so called Python
    >3000):
    >
    > <http://www.artima.com/weblogs/viewpost.jsp?thread=98196>


    Basically, it says that it will get rid of the explicit map, filter
    and reduce and substitute them by some syntactic sugar that uses them
    implicitly. That's ok, and not a big deal.

    It will also get rid of lambda, and it's not a great loss, since
    python's version is so limited that it's almost useless. Besides,
    given the syntactic sugar used to replace map, reduce and filter,
    there's no real need for lambda in the most usual cases.

    The real problem with Python is that it has been very successful as a
    scripting language in the static-typing/C/C++ world. Those
    programmers, instead of adapting their evil ways to Python, and
    realizing the advantages of a dynamic language, are influencing
    Python's design and forcing it into the static-typing mold. Python is
    going the C++ way: piling feature upon feature, adding bells and
    whistles while ignoring or damaging its core design.

    The new 'perlified' syntax for decorators, the new static type bonds
    and the weird decision to kill lambda instead of fixing it are good
    examples that show that Python is going the wrong way. What used to be
    a cool language will soon be an interpreted C/C++ without any
    redeeming value. A real pity...
     
    Fernando, Mar 14, 2005
    #1
    1. Advertising

  2. Hallöchen!

    Fernando <> writes:

    > [...]
    >
    > [...] Python is going the C++ way: piling feature upon feature,
    > adding bells and whistles while ignoring or damaging its core
    > design.


    I'm new to Python, but I while I skimmed through the "What's new?"
    of recent versions, I saw the same unfortunate development.

    Moreover, I dislike the fact that new features are implemented
    partly in the interpreter and partly in Python itself. It reminds
    me of TeX/LaTeX, where the enormous flexibility of TeX is used to
    let it change itself in order to become a LaTeX compiler. However,
    the underlying constructs are utterly ugly, as are some of Python's
    features (e.g. __getattr__ and such, and decorators, in order to get
    nice class properties).

    > The new 'perlified' syntax for decorators,


    Python lost its innocence here: The first really special character,
    disturbing the former syntax style. Not important, but irritating.

    > the new static type bonds


    What is meant by that?

    > [...] What used to be a cool language will soon be an interpreted
    > C/C++ without any redeeming value. A real pity...


    I don't think so, there will be always an enormous difference. But
    Python seems a little bit chaotic.

    I looked for a new language for my hobby programming. I used to use
    Turbo Pascal for 10 years and then C++ for 6 years. A couple of
    weeks ago, I narrowed my decision to C#, Ruby, and Python. At the
    moment, I want to go with Python, but you can definitely see that
    it's the oldest one: Many parts of its syntax are awkward and look
    like patchwork.

    Tschö,
    Torsten.

    --
    Torsten Bronger, aquisgrana, europa vetus
     
    Torsten Bronger, Mar 14, 2005
    #2
    1. Advertising

  3. Hallöchen!

    Fernando <> writes:

    > [...]
    >
    > [...] Python is going the C++ way: piling feature upon feature,
    > adding bells and whistles while ignoring or damaging its core
    > design.


    I'm new to Python, but I while I skimmed through the "What's new?"
    of recent versions, I saw the same unfortunate development.

    Moreover, I dislike the fact that new features are implemented
    partly in the interpreter and partly in Python itself. It reminds
    me of TeX/LaTeX, where the enormous flexibility of TeX is used to
    let it change itself in order to become a LaTeX compiler. However,
    the underlying constructs are utterly ugly, as are some of Python's
    features (e.g. __getattr__ and such, and descriptors, in order to
    get nice class properties).

    > The new 'perlified' syntax for decorators,


    Python lost its innocence here: The first really special character,
    disturbing the former syntax style. Not important, but irritating.

    > the new static type bonds


    What is meant by that?

    > [...] What used to be a cool language will soon be an interpreted
    > C/C++ without any redeeming value. A real pity...


    I don't think so, there will be always an enormous difference. But
    Python seems a little bit chaotic.

    I looked for a new language for my hobby programming. I used to use
    Turbo Pascal for 10 years and then C++ for 6 years. A couple of
    weeks ago, I narrowed my decision to C#, Ruby, and Python. At the
    moment, I want to go with Python, but you can definitely see that
    it's the oldest one: Many parts of its syntax are awkward and look
    like patchwork.

    Tschö,
    Torsten.

    --
    Torsten Bronger, aquisgrana, europa vetus
     
    Torsten Bronger, Mar 14, 2005
    #3
  4. Torsten Bronger wrote:
    > the underlying constructs are utterly ugly, as are some of Python's
    > features (e.g. __getattr__ and such, and decorators, in order to get
    > nice class properties).


    What do you find ugly about __getattr__?

    > I looked for a new language for my hobby programming.

    [snip]
    > I want to go with Python, but you can definitely see that
    > it's the oldest one: Many parts of its syntax are awkward and look
    > like patchwork.


    Interesting. I've never thought that. What parts strike you as
    "patchwork"?

    STeVe
     
    Steven Bethard, Mar 14, 2005
    #4
  5. Fernando

    Fernando Guest

    On Tue, 15 Mar 2005 00:01:09 +0100, Torsten Bronger
    <-aachen.de> wrote:


    >> The new 'perlified' syntax for decorators,

    >
    >Python lost its innocence here: The first really special character,
    >disturbing the former syntax style. Not important, but irritating.
    >
    >> the new static type bonds

    >
    >What is meant by that?


    http://www.artima.com/weblogs/viewpost.jsp?thread=85551
     
    Fernando, Mar 14, 2005
    #5

  6. > I looked for a new language for my hobby programming. I used to use
    > Turbo Pascal for 10 years and then C++ for 6 years. A couple of
    > weeks ago, I narrowed my decision to C#, Ruby, and Python. At the
    > moment, I want to go with Python, but you can definitely see that
    > it's the oldest one: Many parts of its syntax are awkward and look
    > like patchwork.


    You mean you think Ruby syntax is less awkward then Python ? Maybe you
    should add Perl to your list of languages to learn especially after your
    complaints about the decorator syntax.


    Huy
     
    news.sydney.pipenetworks.com, Mar 14, 2005
    #6
  7. Torsten Bronger wrote:
    > Hallöchen!


    Tach!

    > Moreover, I dislike the fact that new features are implemented
    > partly in the interpreter and partly in Python itself. It reminds
    > me of TeX/LaTeX, where the enormous flexibility of TeX is used to
    > let it change itself in order to become a LaTeX compiler. However,
    > the underlying constructs are utterly ugly, as are some of Python's
    > features (e.g. __getattr__ and such, and descriptors, in order to
    > get nice class properties).


    Well, I think TeX is just an awful, weird language with (AFAIK) dynamic
    scoping. Thinking of Lisp macros, I'd say that implementing features on
    top of a small language core is GREAT!
     
    Ulrich Hobelmann, Mar 15, 2005
    #7
  8. news.sydney.pipenetworks.com a écrit :
    >
    >> I looked for a new language for my hobby programming. I used to use
    >> Turbo Pascal for 10 years and then C++ for 6 years. A couple of
    >> weeks ago, I narrowed my decision to C#, Ruby, and Python. At the
    >> moment, I want to go with Python, but you can definitely see that
    >> it's the oldest one: Many parts of its syntax are awkward and look
    >> like patchwork.

    >
    >
    > You mean you think Ruby syntax is less awkward then Python ?


    It is actually. Ruby's syntax is mostly consistent and coherent, and
    there is much less special cases than in Python.

    Now it's also much more difficult to grasp Ruby for programmers coming
    from procedural languages, but that's another story.

    > Maybe you
    > should add Perl to your list of languages to learn especially after your
    > complaints about the decorator syntax.


    I guess you stopped your exploration of Ruby at the first sign of
    'special chars' syntax.

    I don't like Perl, I still prefer to use Python (over Ruby) for a number
    of good and less good reasons, but I somewhat share Fernando's (and some
    other's people here) concerns about the future of MyFavoriteLanguage.

    Bruno
     
    Bruno Desthuilliers, Mar 15, 2005
    #8
  9. Bruno Desthuilliers <> wrote:

    > It is actually. Ruby's syntax is mostly consistent and coherent, and
    > there is much less special cases than in Python.


    I'd be glad to know which special cases are you referring to.
    Please note that you wrote "much less" which means there are probably so
    many that you weren't able to count them.

    --
    Valentino Volonghi aka Dialtone
    Now Running MacOSX 10.3.8
    Blog: http://vvolonghi.blogspot.com
    http://weever.berlios.de
     
    Valentino Volonghi aka Dialtone, Mar 15, 2005
    #9
  10. Hallöchen!

    Steven Bethard <> writes:

    > Torsten Bronger wrote:
    >
    >> the underlying constructs are utterly ugly, as are some of
    >> Python's features (e.g. __getattr__ and such, and decorators, in
    >> order to get nice class properties).

    >
    > What do you find ugly about __getattr__?


    [First, I wanted to say "descriptors" instead of "decorators" (I
    superseded my post).]

    The goal is to trigger function calls when attributes are accessed.
    This is called properties in C# (and maybe in Ruby, too). Python
    now also has this concept. What I find ugly is that it is not a
    syntax element. It looks artificially added to the language. In
    C#, the "set" and "get" methods form with its attribute a syntactic
    unity. Everything is together, and no "property" function is
    necessary.

    >> I looked for a new language for my hobby programming.

    >
    > [snip]
    >
    >> I want to go with Python, but you can definitely see that it's
    >> the oldest one: Many parts of its syntax are awkward and look
    >> like patchwork.

    >
    > Interesting. I've never thought that. What parts strike you as
    > "patchwork"?


    Well, with a little bit of experience in the field of programming
    languages, you can see which elements had been added later (ie years
    after Python's creation). Properties surely would have looked
    *very* different 15 years ago.

    There would be keywords for static and class methods, no distinction
    between Unicode and non-Unicode, and probably no multiple
    inheritance (which seem to have caused a lot of trouble recently),
    and no __new__.

    At first, I was very pleased by Python's syntax (and still I am).
    Then, after two weeks, I learned about descriptors and metaclasses
    and such and understood nothing (for the first time in syntax I felt
    totally lost).

    The reason why I stay with Python is (apart from the indenting
    syntax, huge community, and equally huge library) my feeling that
    the Python developers what to unify the language, even by dropping
    features. The current snapshot is a transitional Python and thus
    with some double features. The numerical types and two kinds of
    classes are examples. I'm very surprised about this, because Python
    is a production language, but I'm happy, too.

    Tschö,
    Torsten.

    --
    Torsten Bronger, aquisgrana, europa vetus
     
    Torsten Bronger, Mar 15, 2005
    #10
  11. Fernando

    Kay Schluehr Guest

    Lisp-likeness

    Maybe You can answer my question what this simple LISP function does ?

    (defun addn (n)
    #'(lambda (x)
    (+ x n)))

    This is correct LISP-syntax if You bear in mind LISPs powerwull macro
    language...

    I think Guido and python-dev are very carefull in adding new power to
    Python. They have to balance the needs for powerfull language features
    on the one hand, simplicity on the other hand. That this relation
    drifts towards more power and more complexity since Python 2.2. is a
    correct observation, but You probably may have notized that the number
    of large projects using Python as their primal language is growing. The
    boundary between that what was formerly called "systems programming"
    and "scripting" is blurred ( if Your mindset reduces
    "systems-programming" on the availability of pointers You certainly
    don't have any problems with the common public prejudices ).

    > The real problem with Python is that it has been very successful as a
    > scripting language in the static-typing/C/C++ world. Those
    > programmers, instead of adapting their evil ways to Python, and
    > realizing the advantages of a dynamic language, are influencing
    > Python's design and forcing it into the static-typing mold. Python is
    > going the C++ way: piling feature upon feature, adding bells and
    > whistles while ignoring or damaging its core design.


    Maybe You should explain what You regard as Pythons "core design", what
    belongs to the core and what to the periphery? Otherwise Your statement
    seems to be plain emotional.

    > The new 'perlified' syntax for decorators, the new static type bonds
    > and the weird decision to kill lambda instead of fixing it are good
    > examples that show that Python is going the wrong way.


    My hypothesis about lambda: lambda will be trashed because it is an
    alien in the language. It is impure. Trashing it is an expression of
    Pythons rassism. There is no way of "doing it right" without exceeding
    it's power and making it less controlable. When Guido once stated that
    the generator way of doing things is Pythons future it was also a
    renouncement of lambda. Compared with this ideological orientation the
    introduction of the @-syntax is a minor sacrilege on syntax esthetics -
    though this special character may hurd the souls of the believers more
    that everything else introduced into the language.

    Kay
     
    Kay Schluehr, Mar 15, 2005
    #11
  12. Torsten Bronger <-aachen.de> wrote:
    > The current snapshot is a transitional Python and thus
    > with some double features. The numerical types and two kinds of
    > classes are examples. I'm very surprised about this, because Python
    > is a production language, but I'm happy, too.


    As long as python 2.x -> 3.x/3000 isn't like perl 5.x -> perl 6.x I'll
    be perfectly happy too.

    "Less is more" is a much better philosophy for a language and having
    the courage to take things out differentiates python from the crowd.

    Of course we users will complain about removals, but we'll knuckle
    down and take our medicine eventually ;-)

    --
    Nick Craig-Wood <> -- http://www.craig-wood.com/nick
     
    Nick Craig-Wood, Mar 15, 2005
    #12
  13. Fernando

    Carl Banks Guest

    Torsten Bronger wrote:
    > Steven Bethard <> writes:
    > > Interesting. I've never thought that. What parts strike you as
    > > "patchwork"?

    >
    > Well, with a little bit of experience in the field of programming
    > languages, you can see which elements had been added later (ie years
    > after Python's creation). Properties surely would have looked
    > *very* different 15 years ago.
    >
    > There would be keywords for static and class methods,


    I don't think there would be. For one thing, I doubt the Python
    leadership thinks static and class methods are important enough to
    warrant keywords. For another thing, it violates Python's idea of how
    much special belongs in class definitions (i.e., none at all).

    In Python, classes aren't some magical land where the usual rules don't
    hold (as they are in many other languages). That's why "self." is used
    on class variables, for instance. A class is nothing more than a scope
    that uses a smittering of magic to turn it into a type.

    > no distinction
    > between Unicode and non-Unicode,


    True.

    > and probably no multiple
    > inheritance


    I highly doubt it. A couple years ago, when Python made the transition
    to new-style classes, there was an opportunity to toss out multiple
    inheritance. Not only did the Python developers not toss it or
    deprecate it, they put in a lot of work and effort to improve it. We
    now have a spiffy stable MRO algorithm to handle resolution of
    attributes.

    Besides, in the tradition of dynamic languages, MI is pretty par for
    the course, unlike for static languages where it is seen as kind of
    exotic.

    >(which seem to have caused a lot of trouble recently),


    Not sure what you're talking about here. Was the problem with
    XMLRPCServer related to MI?

    > and no __new__.


    Perhaps. More likely, there would have been __new__ but no __init__.
    At the C level, new and init do seem to serve distinct purposes, but I
    don't know how important it would be in a new design.

    > At first, I was very pleased by Python's syntax (and still I am).
    > Then, after two weeks, I learned about descriptors and metaclasses
    > and such and understood nothing (for the first time in syntax I felt
    > totally lost).


    Metaclasses weren't something that Python just threw in because it was
    cool. Rather, they were mostly a side effect of how Python constructs
    classes. When Python transistioned to new-style classes, the gods
    decided to expose the metaclass functionality, because it could prove
    useful in a lot of cases.

    I believe, however, that there was an intentional lack of effort to
    make them less obscure than they already are. They didn't want average
    people to be hacking metaclasses left and right.

    > The reason why I stay with Python is (apart from the indenting
    > syntax, huge community, and equally huge library) my feeling that
    > the Python developers what to unify the language, even by dropping
    > features.


    Yes, fortunately that happens. It's good, too.

    > The current snapshot is a transitional Python and thus
    > with some double features. The numerical types and two kinds of
    > classes are examples. I'm very surprised about this, because Python
    > is a production language, but I'm happy, too.


    Yeah, well that's the price you gotta pay when remedying old mistakes
    or restrictions.


    --
    CARL BANKS
     
    Carl Banks, Mar 15, 2005
    #13
  14. Fernando

    Tim Daneliuk Guest

    In-Reply-To: <-wood.com>
    X-Enigmail-Version: 0.90.0.0
    X-Enigmail-Supports: pgp-inline, pgp-mime
    Content-Type: text/plain; charset=us-ascii; format=flowed
    Content-Transfer-Encoding: 7bit

    Nick Craig-Wood wrote:

    > Torsten Bronger <-aachen.de> wrote:
    >
    >> The current snapshot is a transitional Python and thus
    >> with some double features. The numerical types and two kinds of
    >> classes are examples. I'm very surprised about this, because Python
    >> is a production language, but I'm happy, too.

    >
    >
    > As long as python 2.x -> 3.x/3000 isn't like perl 5.x -> perl 6.x I'll
    > be perfectly happy too.
    >
    > "Less is more" is a much better philosophy for a language and having
    > the courage to take things out differentiates python from the crowd.
    >
    > Of course we users will complain about removals, but we'll knuckle
    > down and take our medicine eventually ;-)
    >


    Except that in this case, removal will also complicate code in some
    cases. Consider this fragment of Tkinter logic:

    UI.CmdBtn.menu.add_command(label="MyLabel",
    command=lambda cmd=cmdkey: CommandMenuSelection(cmd))

    Would it not be the case that, without lambda, we will need to pollute
    the name space with a bunch of specialized little functions for each
    and every construct like this?

    --
    ----------------------------------------------------------------------------
    Tim Daneliuk
    PGP Key: http://www.tundraware.com/PGP/
     
    Tim Daneliuk, Mar 15, 2005
    #14
  15. Fernando

    Serge Orlov Guest

    Torsten Bronger wrote:
    > > Interesting. I've never thought that. What parts strike you as
    > > "patchwork"?

    >
    > Well, with a little bit of experience in the field of programming
    > languages, you can see which elements had been added later (ie years
    > after Python's creation). Properties surely would have looked
    > *very* different 15 years ago.
    >
    > There would be keywords for static and class methods, no distinction
    > between Unicode and non-Unicode


    You couldn't do that 15 years ago because there were no Unicode that
    time.

    Serge.
     
    Serge Orlov, Mar 15, 2005
    #15
  16. Hallöchen!

    "Serge Orlov" <> writes:

    > Torsten Bronger wrote:
    >
    >>> Interesting. I've never thought that. What parts strike you as
    >>> "patchwork"?

    >>
    >> Well, with a little bit of experience in the field of programming
    >> languages, you can see which elements had been added later (ie
    >> years after Python's creation). Properties surely would have
    >> looked *very* different 15 years ago.
    >>
    >> There would be keywords for static and class methods, no
    >> distinction between Unicode and non-Unicode

    >
    > You couldn't do that 15 years ago because there were no Unicode
    > that time.


    I've never said that Guido was just too stupid at that time. I only
    said "but you can definitely see that it's the oldest one". In
    other words, a Ruby six years older than the real one would have the
    same problem. And who knows how C# looks like in 10 years.

    But I want to program now, and this is the current situation in my
    opinion.

    Tschö,
    Torsten.

    --
    Torsten Bronger, aquisgrana, europa vetus
     
    Torsten Bronger, Mar 15, 2005
    #16
  17. Fernando

    Peter Maas Guest

    Carl Banks schrieb:
    > In Python, classes aren't some magical land where the usual rules don't
    > hold (as they are in many other languages). That's why "self." is used
    > on class variables, for instance. A class is nothing more than a scope
    > that uses a smittering of magic to turn it into a type.


    scope -> dictionary

    --
    -------------------------------------------------------------------
    Peter Maas, M+R Infosysteme, D-52070 Aachen, Tel +49-241-93878-0
    E-mail 'cGV0ZXIubWFhc0BtcGx1c3IuZGU=\n'.decode('base64')
    -------------------------------------------------------------------
     
    Peter Maas, Mar 15, 2005
    #17
  18. Tim Daneliuk wrote:
    > In-Reply-To: <-wood.com>
    > X-Enigmail-Version: 0.90.0.0
    > X-Enigmail-Supports: pgp-inline, pgp-mime
    > Content-Type: text/plain; charset=us-ascii; format=flowed
    > Content-Transfer-Encoding: 7bit
    >
    > Nick Craig-Wood wrote:
    >
    >
    >>Torsten Bronger <-aachen.de> wrote:
    >>
    >>
    >>>The current snapshot is a transitional Python and thus
    >>>with some double features. The numerical types and two kinds of
    >>>classes are examples. I'm very surprised about this, because Python
    >>>is a production language, but I'm happy, too.

    >>
    >>
    >>As long as python 2.x -> 3.x/3000 isn't like perl 5.x -> perl 6.x I'll
    >>be perfectly happy too.
    >>
    >>"Less is more" is a much better philosophy for a language and having
    >>the courage to take things out differentiates python from the crowd.
    >>
    >>Of course we users will complain about removals, but we'll knuckle
    >>down and take our medicine eventually ;-)
    >>

    >
    >
    > Except that in this case, removal will also complicate code in some
    > cases. Consider this fragment of Tkinter logic:
    >
    > UI.CmdBtn.menu.add_command(label="MyLabel",
    > command=lambda cmd=cmdkey: CommandMenuSelection(cmd))
    >


    In this case you perhaps should try using a class like so:-

    UI.CmdBtn.menu.add_command(label="MyLabel",
    command=CommandMenuSelectionCallback(cmdkey))

    Where CommandMenuSelectionCallback is a class like so:


    class CommandMenuSelectionCallback:
    def __init__(self, key):
    self.key = key

    def __call__(self):
    print self.key

    > Would it not be the case that, without lambda, we will need to pollute
    > the name space with a bunch of specialized little functions for each
    > and every construct like this?
    >
     
    Martin Franklin, Mar 15, 2005
    #18
  19. Fernando

    Paul Boddie Guest

    Torsten Bronger <-aachen.de> wrote in message news:<-aachen.de>...
    >
    > At first, I was very pleased by Python's syntax (and still I am).
    > Then, after two weeks, I learned about descriptors and metaclasses
    > and such and understood nothing (for the first time in syntax I felt
    > totally lost).


    Well, I've been using Python for almost ten years, and I've managed to
    deliberately ignore descriptors and metaclasses quite successfully. I
    get the impression that descriptors in particular are a detail of the
    low-level implementation that get a disproportionate level of coverage
    because of the "hack value" they can provide (albeit with seemingly
    inappropriate application to certain problem areas).

    Still, having new- and old-style classes, a separate old-style
    exception class hierarchy, and various other "transitional" features
    doesn't seem very "Pythonic", does it? ;-)

    Paul
     
    Paul Boddie, Mar 15, 2005
    #19
  20. Hallöchen!

    (Paul Boddie) writes:

    > Torsten Bronger <-aachen.de> wrote:
    >
    >> At first, I was very pleased by Python's syntax (and still I am).
    >> Then, after two weeks, I learned about descriptors and
    >> metaclasses and such and understood nothing (for the first time
    >> in syntax I felt totally lost).

    >
    > Well, I've been using Python for almost ten years, and I've
    > managed to deliberately ignore descriptors and metaclasses quite
    > successfully. I get the impression that descriptors in particular
    > are a detail of the low-level implementation that get a
    > disproportionate level of coverage because of the "hack value"
    > they can provide (albeit with seemingly inappropriate application
    > to certain problem areas).


    I have exactly the same impression, but for me it's the reason why I
    feel uncomfortable with them. For example, I fear that a skilled
    package writer could create a module with surprising behaviour by
    using the magic of these constructs. I don't know Python well
    enough to get more specific, but flexibility almost always make
    confusing situations for non-hackers possible.

    I know that such magic is inavoidable with dynamic languages, but
    descriptors will be used almost exclusively for properties, and
    therefore I think it would have been better to hard-wire properties
    in the interpreter rather than pollute the language with this sort
    of proto-properties (aka descriptors).

    TeX is extremely dynamic. It can modify its own scanner in order to
    become an XML parser or AFM (Adobe font metrics) reader. This is
    highly confusing for all but those five or six people on this planet
    who speak TeX fluently. Since I saw raw TeX, I dislike
    "proto-syntaxes" (or meta-syntaxes if you wish).

    Tschö,
    Torsten.

    --
    Torsten Bronger, aquisgrana, europa vetus
     
    Torsten Bronger, Mar 15, 2005
    #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. ekzept
    Replies:
    0
    Views:
    377
    ekzept
    Aug 10, 2007
  2. mk
    Replies:
    1
    Views:
    538
    Diez B. Roggisch
    Feb 5, 2009
  3. Terry Reedy

    Re: Is c.l.py becoming less friendly?

    Terry Reedy, Feb 5, 2009, in forum: Python
    Replies:
    3
    Views:
    213
    Mark Dickinson
    Feb 6, 2009
  4. nanothermite911fbibustards
    Replies:
    0
    Views:
    381
    nanothermite911fbibustards
    Jun 16, 2010
  5. nanothermite911fbibustards
    Replies:
    0
    Views:
    324
    nanothermite911fbibustards
    Jun 16, 2010
Loading...

Share This Page