Re: Python -- (just) a successful experiment?

Discussion in 'Python' started by Robert Kern, Aug 7, 2005.

  1. Robert Kern

    Robert Kern Guest

    Eric Pederson wrote:

    [snip yet another article repeating what's been said over and over again
    for years]

    > Is it wrong to appreciate Python as a language, but want to have the nice accoutrements we see in some competing languages?


    No it's not wrong to want these things. The problem is that we're not
    lacking in people posting this *same exact complaint* every month or so.
    We *are* lacking in people implementing these things.

    If you want to see these nice accoutrements, *stop posting here and get
    to work*! These threads never, ever bring anything new or interesting to
    the table, they don't build any consensus, and they certainly don't get
    any code written.

    --
    Robert Kern


    "In the fields of hell where the grass grows high
    Are the graves of dreams allowed to die."
    -- Richard Harter
     
    Robert Kern, Aug 7, 2005
    #1
    1. Advertising

  2. Robert Kern

    Paul Rubin Guest

    Robert Kern <> writes:
    > No it's not wrong to want these things. The problem is that we're not
    > lacking in people posting this *same exact complaint* every month or
    > so. We *are* lacking in people implementing these things.


    Eh? Nah, we keep getting lame excuses on why those things aren't
    needed and users should just supply tenacity and expect to suffer and
    they should stop being wimps, and having to locate, download, and
    figure out how to use a dozen packages from all over the internet
    really isn't more hassle than a one-click install with unified
    documentation for everything.

    > If you want to see these nice accoutrements, *stop posting here and
    > get to work*!


    Eh again--says who? You? Most of those functions for Python are
    already floating around the net. It's simply a matter in many cases
    of deciding to include them in the distro. The problem is an attitude
    that making things too easy for users is un-Pythonic. If you think
    it's just a matter of writing code, you're not on the side you think
    you're on.
     
    Paul Rubin, Aug 7, 2005
    #2
    1. Advertising

  3. Robert Kern

    Robert Kern Guest

    Paul Rubin wrote:
    > Robert Kern <> writes:
    >
    >>No it's not wrong to want these things. The problem is that we're not
    >>lacking in people posting this *same exact complaint* every month or
    >>so. We *are* lacking in people implementing these things.

    >
    > Eh? Nah, we keep getting lame excuses on why those things aren't
    > needed and users should just supply tenacity and expect to suffer and
    > they should stop being wimps, and having to locate, download, and
    > figure out how to use a dozen packages from all over the internet
    > really isn't more hassle than a one-click install with unified
    > documentation for everything.


    *I'm* not giving those excuses. I'm doing the work to assist in my area
    of interest.

    http://download.enthought.com/MacEnthon/ReadMe.html

    >>If you want to see these nice accoutrements, *stop posting here and
    >>get to work*!

    >
    > Eh again--says who? You?


    Yes, me. I've been doing the legwork.

    > Most of those functions for Python are
    > already floating around the net. It's simply a matter in many cases
    > of deciding to include them in the distro. The problem is an attitude
    > that making things too easy for users is un-Pythonic. If you think
    > it's just a matter of writing code, you're not on the side you think
    > you're on.


    I said nothing about writing code except as part of a list of several
    things that this thread won't accomplish. I certainly don't think that
    it *just* involves writing code.

    --
    Robert Kern


    "In the fields of hell where the grass grows high
    Are the graves of dreams allowed to die."
    -- Richard Harter
     
    Robert Kern, Aug 7, 2005
    #3
  4. Paul Rubin <http://> writes:

    > Eh? Nah, we keep getting lame excuses on why those things aren't
    > needed and users should just supply tenacity and expect to suffer and
    > they should stop being wimps, and having to locate, download, and
    > figure out how to use a dozen packages from all over the internet
    > really isn't more hassle than a one-click install with unified
    > documentation for everything.


    I don't see why the things you talk about would have to be part of the
    main Python distribution. Ruby on Rails seems to do pretty well without
    being included with the core language.

    There's already a pretty successful programming framework for Python
    (Zope), and I don't see why people wouldn't be able to put something
    like that together to compete on more equal terms with Ruby on Rails, or
    Delphi, &c.

    If you want the whole of the Python community to start developing stuff
    for one particular GUI toolkit, I think you'll have much more success by
    just making a really good GUI toolkit, than trying to force people to
    use it by standardising it. (Which I think is shown by the proliferation
    of GUI toolkits other than Tkinter.)

    In short, when you have your one-click-install Pythonic IDE
    extravaganza, I'm sure people will download it, whether or not they can
    do it on python.org.

    --
    Björn Lindström <>
    Student of computational linguistics, Uppsala University, Sweden
     
    =?utf-8?Q?Bj=C3=B6rn_Lindstr=C3=B6m?=, Aug 7, 2005
    #4
  5. Robert Kern

    Paul Rubin Guest

    (Björn Lindström) writes:
    > I don't see why the things you talk about would have to be part of the
    > main Python distribution. Ruby on Rails seems to do pretty well without
    > being included with the core language.


    I haven't used Ruby on Rails but from the description I saw, its distro
    includes everything needed, which I assume includes Ruby itself.

    > There's already a pretty successful programming framework for Python
    > (Zope), and I don't see why people wouldn't be able to put something
    > like that together to compete on more equal terms with Ruby on Rails, or
    > Delphi, &c.


    I have the impression that Zope is ungodly complex, and revolves around
    a weird and nonstandard database instead of having an SQL interface.

    > If you want the whole of the Python community to start developing stuff
    > for one particular GUI toolkit, I think you'll have much more success by
    > just making a really good GUI toolkit, than trying to force people to
    > use it by standardising it. (Which I think is shown by the proliferation
    > of GUI toolkits other than Tkinter.)


    Actually that proliferation is one of the culprits in Python being a
    pain to deal with. I'm personally not a GUI fetishist and Tkinter has
    been good enough for the client-side GUI's I've needed to write (I'm
    more web-oriented most of the time). But the reason for that
    proliferation is other people are dissatisfied with Tkinter. That
    by itself says the stdlib is lacking.

    > In short, when you have your one-click-install Pythonic IDE
    > extravaganza, I'm sure people will download it, whether or not they can
    > do it on python.org.


    There's already a Python IDE (Idle) included with the Python distro;
    its problem is that its limited in functionality and it's buggy.

    Anyway, I'm a Python user, not an evangelist. As a user I'm happy to
    have Python and am thankful to its authors, even though (like anything
    else) it's a long way from being perfect. But I do get annoyed by
    evangelists who make unsupportable claims that the product doesn't
    live up to.
     
    Paul Rubin, Aug 7, 2005
    #5
  6. Paul Rubin <http://> writes:

    > (Björn Lindström) writes:
    >> I don't see why the things you talk about would have to be part of the
    >> main Python distribution. Ruby on Rails seems to do pretty well without
    >> being included with the core language.

    >
    > I haven't used Ruby on Rails but from the description I saw, its distro
    > includes everything needed, which I assume includes Ruby itself.


    Hm... did you read my posting before you answered? That's exactly the
    kind of distro I suggested that you would make. Ruby on Rails is not
    Ruby itself, you know.

    >> There's already a pretty successful programming framework for Python
    >> (Zope), and I don't see why people wouldn't be able to put something
    >> like that together to compete on more equal terms with Ruby on Rails, or
    >> Delphi, &c.

    >
    > I have the impression that Zope is ungodly complex, and revolves around
    > a weird and nonstandard database instead of having an SQL interface.


    That's why you would put something together "to compete on more equal
    terms with Ruby on Rails".

    > Anyway, I'm a Python user, not an evangelist. As a user I'm happy to
    > have Python and am thankful to its authors, even though (like anything
    > else) it's a long way from being perfect. But I do get annoyed by
    > evangelists who make unsupportable claims that the product doesn't
    > live up to.


    I made no such claims. Again, did you actually read my posting?

    --
    Björn Lindström <>
    Student of computational linguistics, Uppsala University, Sweden
     
    =?utf-8?Q?Bj=C3=B6rn_Lindstr=C3=B6m?=, Aug 7, 2005
    #6
  7. Robert Kern

    Neil Hodgson Guest

    Paul Rubin:

    > I haven't used Ruby on Rails but from the description I saw, its distro
    > includes everything needed, which I assume includes Ruby itself.


    Whatever led you to assume that?

    * Install Ruby
    * Install RubyGems
    * Invoke gem to install rails

    http://download.rubyonrails.com/

    Neil
     
    Neil Hodgson, Aug 7, 2005
    #7
  8. Robert Kern

    Peter Decker Guest

    On 07 Aug 2005 02:42:43 -0700, Paul Rubin
    <"http://phr.cx"@nospam.invalid> wrote:
    > (Björn Lindström) writes:
    > > I don't see why the things you talk about would have to be part of the
    > > main Python distribution. Ruby on Rails seems to do pretty well without
    > > being included with the core language.

    >
    > I haven't used Ruby on Rails but from the description I saw, its distro
    > includes everything needed, which I assume includes Ruby itself.


    Here you go again: making pronouncements without actually knowing what
    you are talking about. Just a few days ago you were trashing products
    like Dabo, because they use things that aren't in the standard
    distribution, and now you're approving of something like Rails because
    it has a Windows package that installs everything you need, including
    Ruby. Yet Dabo has had exactly the same thing for quite some time now
    on Windows: a standard Windows installer that gives you Python,
    wxPython, MySQLdb, kinterbasdb, etc., but you spent countless messages
    trashing Dabo and anyone who would consider using something like it,
    because it "wasn't in the standard distribution".

    > I have the impression that Zope is ungodly complex, and revolves around
    > a weird and nonstandard database instead of having an SQL interface.


    Wow, and I have the impression that you form opinions before you
    actually experience something. Isn't there a word for such a person?
    Hmmm.....
    --

    # p.d.
     
    Peter Decker, Aug 7, 2005
    #8
  9. Robert Kern

    Paul Rubin Guest

    Peter Decker <> writes:
    > Hmmm.....


    Plonk.
     
    Paul Rubin, Aug 7, 2005
    #9
  10. Robert Kern

    Paul Rubin Guest

    (Björn Lindström) writes:
    > > I haven't used Ruby on Rails but from the description I saw, its distro
    > > includes everything needed, which I assume includes Ruby itself.

    >
    > Hm... did you read my posting before you answered? That's exactly the
    > kind of distro I suggested that you would make. Ruby on Rails is not
    > Ruby itself, you know.


    I'm going by another post earlier up. I'm not sure if it was from
    you. The distro in question was the Ruby on Rails distro. The person
    said he downloaded and installed it and it did everything in one
    click. That would imply that it included the Ruby language. Nothing
    stops the Ruby on Rails packagers from making the Ruby on Rails distro
    a superset of the Ruby distro, after all.

    > > I have the impression that Zope is ungodly complex, and revolves around
    > > a weird and nonstandard database instead of having an SQL interface.

    >
    > That's why you would put something together "to compete on more equal
    > terms with Ruby on Rails".


    Yes, it sounds like we agree that Zope isn't the answer. There's
    probably Python code around that does similar stuff to most of what
    RoR does, though it might be that RoR uses Ruby language features to
    do some things more conveniently than Python can.

    > > Anyway, I'm a Python user, not an evangelist. As a user I'm happy
    > > to have Python and am thankful to its authors, even though (like
    > > anything else) it's a long way from being perfect. But I do get
    > > annoyed by evangelists who make unsupportable claims that the
    > > product doesn't live up to.

    >
    > I made no such claims. Again, did you actually read my posting?


    Your claims are not the ones I have such trouble with.
     
    Paul Rubin, Aug 7, 2005
    #10
  11. Paul Rubin <http://> writes:

    > That would imply that it included the Ruby language. Nothing stops the
    > Ruby on Rails packagers from making the Ruby on Rails distro a
    > superset of the Ruby distro, after all.


    So you agree with me then? That _was_ exactly my point, after all. Not
    that you read it. After all, you might have been replying to some
    completely different posting - who could know?

    > Peter Decker <> writes:
    > >> Wow, and I have the impression that you form opinions before you
    > >> actually experience something. Isn't there a word for such a person?

    > > Hmmm.....

    >
    > Plonk.


    Yeah, thanks, that's the word.

    --
    Björn Lindström <>
    Student of computational linguistics, Uppsala University, Sweden
     
    =?utf-8?Q?Bj=C3=B6rn_Lindstr=C3=B6m?=, Aug 7, 2005
    #11
  12. Robert Kern

    Paul Rubin Guest

    (Björn Lindström) writes:
    > > That would imply that it included the Ruby language. Nothing stops the
    > > Ruby on Rails packagers from making the Ruby on Rails distro a
    > > superset of the Ruby distro, after all.

    >
    > So you agree with me then? That _was_ exactly my point, after all. Not
    > that you read it. After all, you might have been replying to some
    > completely different posting - who could know?


    I don't understand what you're getting at. Either the RoR
    distribution includes the Ruby language or else it doesn't. From that
    other post, I have the impression that it does, but I don't care
    enough about Ruby to want to go check into it.

    Or is your point that some third party could make a moby Python distro
    that includes more runtime stuff than the python.org distro includes?
    Yes, they could; that it's happened with Ruby and not with Python
    suggests that Ruby is doing a better job attracting people to do stuff
    like that. I don't think the Ruby language is as nice as Python, so
    the difference must be in the culture surrounding the language, rather
    than the language itself. Python culture often strikes me as
    seriously dysfunctional. See the "reinventing the wheel" thread of
    the previous week or so, which was full of gnashers arguing that a
    convenient unified distro isn't necessary since users should have
    enough tenacity to download and configure umpteen separate components
    themselves.
     
    Paul Rubin, Aug 7, 2005
    #12
  13. Robert Kern

    Robert Kern Guest

    Paul Rubin wrote:
    > (Björn Lindström) writes:
    >
    >>>That would imply that it included the Ruby language. Nothing stops the
    >>>Ruby on Rails packagers from making the Ruby on Rails distro a
    >>>superset of the Ruby distro, after all.

    >>
    >>So you agree with me then? That _was_ exactly my point, after all. Not
    >>that you read it. After all, you might have been replying to some
    >>completely different posting - who could know?

    >
    > I don't understand what you're getting at. Either the RoR
    > distribution includes the Ruby language or else it doesn't.


    No. A *particular* Ruby on Rails distribution includes the Ruby
    language. You can get Ruby on Rails by itself if you happen to already
    have Ruby installed. People who aren't just evaluating Ruby on Rails for
    the first time will probably be using the regular distribution.

    You'll notice, very distinctly, in big letters at the top of
    http://download.rubyonrails.com :

    "Rails is primarily distributed through RubyGems — the soon-to-be
    official packaging format for Ruby libs/apps"

    > From that
    > other post, I have the impression that it does, but I don't care
    > enough about Ruby to want to go check into it.
    >
    > Or is your point that some third party could make a moby Python distro
    > that includes more runtime stuff than the python.org distro includes?
    > Yes, they could; that it's happened with Ruby and not with Python


    http://www.enthought.com/python/
    http://download.enthought.com/MacEnthon/ReadMe.html

    I even pointed you to the last one, earlier.

    > suggests that Ruby is doing a better job attracting people to do stuff
    > like that. I don't think the Ruby language is as nice as Python, so
    > the difference must be in the culture surrounding the language, rather
    > than the language itself. Python culture often strikes me as
    > seriously dysfunctional. See the "reinventing the wheel" thread of
    > the previous week or so, which was full of gnashers arguing that a
    > convenient unified distro isn't necessary since users should have
    > enough tenacity to download and configure umpteen separate components
    > themselves.


    As a maintainers of a convenient unified distro, I have to say that it's
    a losing strategy. No matter how much you include, for every person that
    tells you, "Thank you, you've made my Python experience better," there
    are three who say, "Thanks, but could you also include Package X?" or
    "Thanks, but Package Y is much better at doing foo than Package Z? Could
    you include it next time?" or "When are you going to update Package W to
    the latest version?"

    You can't satisfy everyone or even a whole lot of people with a single
    massive installer. People want different things. I want VTK installed
    because I need 3D visualization; I couldn't care less about web
    applications. But lots of other people care very deeply about web
    applications and don't want to waste 100 MB of disk space on 3D
    visualization libraries.

    When "one-click installation" entails downloading 150 MB of compressed
    data for every update, the convenience begins to pall a bit.

    Fortunately, there's a better approach, and it's coming soon. The next
    iteration of MacEnthon, at least, is going to be based on Python eggs
    and easy_install.py. Python eggs are, more or less, Python's answer to
    Ruby's gems.

    http://peak.telecommunity.com/DevCenter/PythonEggs
    http://peak.telecommunity.com/DevCenter/EasyInstall

    --
    Robert Kern


    "In the fields of hell where the grass grows high
    Are the graves of dreams allowed to die."
    -- Richard Harter
     
    Robert Kern, Aug 7, 2005
    #13
  14. Robert Kern

    Paul Rubin Guest

    Robert Kern <> writes:
    > As a maintainers of a convenient unified distro, I have to say that
    > it's a losing strategy. No matter how much you include, for every
    > person that tells you, "Thank you, you've made my Python experience
    > better," there are three who say, "Thanks, but could you also include
    > Package X?" or "Thanks, but Package Y is much better at doing foo than
    > Package Z? Could you include it next time?" or "When are you going to
    > update Package W to the latest version?"


    It doesn't appear to be a losing strategy for Java, Fedora, GCC, or
    for that matter Ruby on Rails. Maybe it's more work, but those
    distros are able to attract enough community effort and/or corporate
    bucks to get the work done.

    > You can't satisfy everyone or even a whole lot of people with a single
    > massive installer. People want different things. I want VTK installed
    > because I need 3D visualization; I couldn't care less about web
    > applications. But lots of other people care very deeply about web
    > applications and don't want to waste 100 MB of disk space on 3D
    > visualization libraries.


    If I have a 400GB hard disk in my computer, why should I care whether
    it's 99.5% empty instead of 99 empty after I get done installing
    software?

    > When "one-click installation" entails downloading 150 MB of compressed
    > data for every update, the convenience begins to pall a bit.


    Fedora Core is around 4GB and I installed it from a DVD-ROM pretty
    easily.

    > Fortunately, there's a better approach, and it's coming soon. The next
    > iteration of MacEnthon, at least, is going to be based on Python eggs
    > and easy_install.py. Python eggs are, more or less, Python's answer to
    > Ruby's gems.
    >
    > http://peak.telecommunity.com/DevCenter/PythonEggs


    Cool. That doc page compares them to .jar files, but I don't see any
    provision for signatures on them like jars have. I hope that can be
    added sometime.
     
    Paul Rubin, Aug 7, 2005
    #14
  15. Robert Kern

    Robert Kern Guest

    Paul Rubin wrote:
    > Robert Kern <> writes:
    >
    >>As a maintainers of a convenient unified distro, I have to say that
    >>it's a losing strategy. No matter how much you include, for every
    >>person that tells you, "Thank you, you've made my Python experience
    >>better," there are three who say, "Thanks, but could you also include
    >>Package X?" or "Thanks, but Package Y is much better at doing foo than
    >>Package Z? Could you include it next time?" or "When are you going to
    >>update Package W to the latest version?"

    >
    > It doesn't appear to be a losing strategy for Java, Fedora, GCC, or
    > for that matter Ruby on Rails. Maybe it's more work, but those
    > distros are able to attract enough community effort and/or corporate
    > bucks to get the work done.


    Java I'll give you (but then, lots of people are paid to make it that
    way). Fedora is an OS, not a language. GCC does not come with a standard
    GUI or even many libraries, so I don't see why it's in this list. Ruby
    on Rails does *not* give you a sumo distribution like you are talking
    about and I have maintained. It does provide a single installer for Ruby
    on Rails (which is just a web framework) and its dependencies for a few
    platforms so that people new to Ruby can give Ruby on Rails a try
    without doing a big installation dance. When people start really
    developing Ruby on Rails apps, they're going to be using the RubyGems
    installers. The installer you're talking about is really just for
    evaluation.

    Ruby on Rails's main strategy for distribution, RubyGems, is *exactly*
    what I'm suggesting: packages.

    >>You can't satisfy everyone or even a whole lot of people with a single
    >>massive installer. People want different things. I want VTK installed
    >>because I need 3D visualization; I couldn't care less about web
    >>applications. But lots of other people care very deeply about web
    >>applications and don't want to waste 100 MB of disk space on 3D
    >>visualization libraries.

    >
    > If I have a 400GB hard disk in my computer, why should I care whether
    > it's 99.5% empty instead of 99 empty after I get done installing
    > software?


    <shrug> I have 60 GB on my laptop and lots of music and gigabyte-sized
    satellite images so disk space is relatively tight. You're making my
    point: everyone has different needs.

    >>When "one-click installation" entails downloading 150 MB of compressed
    >>data for every update, the convenience begins to pall a bit.

    >
    > Fedora Core is around 4GB and I installed it from a DVD-ROM pretty
    > easily.


    Fedora Core is an operating system, so it pretty much *needs* to be
    installed from some physical medium at some point in the process. It is
    also a very popular operating system, so pressing and mailing DVDs is
    relatively economical.

    Doing these large, "everything on one CD/DVD," deals is really the
    province of operating system distributions, and they do the job well.
    Package management is where we on the Python end ought to focus.

    >>Fortunately, there's a better approach, and it's coming soon. The next
    >>iteration of MacEnthon, at least, is going to be based on Python eggs
    >>and easy_install.py. Python eggs are, more or less, Python's answer to
    >>Ruby's gems.
    >>
    >>http://peak.telecommunity.com/DevCenter/PythonEggs

    >
    > Cool. That doc page compares them to .jar files, but I don't see any
    > provision for signatures on them like jars have. I hope that can be
    > added sometime.


    Which is exactly why I said at the beginning that people shouldn't
    bother with this thread and should instead just get to work.

    --
    Robert Kern


    "In the fields of hell where the grass grows high
    Are the graves of dreams allowed to die."
    -- Richard Harter
     
    Robert Kern, Aug 7, 2005
    #15
  16. Robert Kern

    Terry Reedy Guest

    "Paul Rubin" <"http://phr.cx"@NOSPAM.invalid> wrote in message
    news:...
    (Björn Lindström) writes:
    >Actually that proliferation is one of the culprits in Python being a
    >pain to deal with. I'm personally not a GUI fetishist and Tkinter has
    >been good enough for the client-side GUI's I've needed to write (I'm
    >more web-oriented most of the time). But the reason for that
    >proliferation is other people are dissatisfied with Tkinter.


    Do you have any data to support that? Seriously. Consider

    Hypothesis 1: someone learned Python and Tkinter, felt dissatisfied with
    Tkinter, went searching the universe for an alternative, found GTK, and
    wrote PyGTK, perhaps learning C in the process.

    Hypothesis 2: a C-programmer who is a satisfied user of GTK (on *nix,
    presumably) learns Python. "Neat, but I also want to keep using GTK."
    Which he can because it is relatively easy.

    Repeat H1 and H2 for every wrapping. You believe in H1. I suspect H2 is
    more often true, but admit I have no data.

    > That by itself says the stdlib is lacking.


    I have an alternate interpretation. There is a Python wrapping for as many
    C libraries as there are because Python is neat and wrapping is fairly easy
    and the rewards great.

    When I learned Python several years ago, being able to interactively drive
    and easily script foreign libraries was touted as one of its killer
    applications. Numerical Python, wrapping BLAS, LINPACK, and FTPPACK was a
    prime example. So in a sense, you are criticizing Python for being
    successful at what I believe was one of its design goals.

    But go ahead. Lots of choices can be a nuisance. Just check out the
    supermarkets. (But so is too few choices ;-)

    Terry J. Reedy
     
    Terry Reedy, Aug 8, 2005
    #16
  17. Hallöchen!

    "Terry Reedy" <> writes:

    > [...] Consider
    >
    > Hypothesis 1: someone learned Python and Tkinter, felt
    > dissatisfied with Tkinter, went searching the universe for an
    > alternative, found GTK, and wrote PyGTK, perhaps learning C in the
    > process.
    >
    > Hypothesis 2: a C-programmer who is a satisfied user of GTK (on
    > *nix, presumably) learns Python. "Neat, but I also want to keep
    > using GTK." Which he can because it is relatively easy.
    >
    > Repeat H1 and H2 for every wrapping. You believe in H1. I
    > suspect H2 is more often true, but admit I have no data.


    It is probably H2 (otherwise the reluctance to learn GTK so
    thoroughly would be too great) but with the important addition that
    the creator of PyGTK felt the general dissatisfaction with Tkinter.
    Getting users is a very very important motivation for a developer
    after all.

    >> That by itself says the stdlib is lacking.

    >
    > I have an alternate interpretation. There is a Python wrapping
    > for as many C libraries as there are because Python is neat and
    > wrapping is fairly easy and the rewards great.


    Yes, absolutely; but for the core functionality (which must contain
    a good GUI toolkit in my opinion) you should have more that just a
    "binding". Instead, it should be well-embedded into the standard
    library and the language.

    Tschö,
    Torsten.

    --
    Torsten Bronger, aquisgrana, europa vetus
     
    Torsten Bronger, Aug 8, 2005
    #17
  18. Robert Kern

    Paul Rubin Guest

    "Terry Reedy" <> writes:
    > Hypothesis 1: someone learned Python and Tkinter, felt dissatisfied with
    > Tkinter, went searching the universe for an alternative, found GTK, and
    > wrote PyGTK, perhaps learning C in the process.
    >
    > Hypothesis 2: a C-programmer who is a satisfied user of GTK (on *nix,
    > presumably) learns Python. "Neat, but I also want to keep using GTK."
    > Which he can because it is relatively easy.
    >
    > Repeat H1 and H2 for every wrapping. You believe in H1. I suspect H2 is
    > more often true, but admit I have no data.


    I dunno about PyGTK but one of the more common complaints about
    wxPython is that it's not Pythonic enough. And wxPython is probably
    the most popular Python GUI toolkit after Tkinter. So people don't
    want C wrappers. I think what they mostly want is a wide choice of
    good looking widgets. They don't like Tkinter because its widget set
    is limited and what widgets it does have, look like crap.

    > I have an alternate interpretation. There is a Python wrapping for
    > as many C libraries as there are because Python is neat and wrapping
    > is fairly easy and the rewards great.


    I think Python outgrew this "glue" orientation years ago and its main
    failings today are where it holds onto that orientation instead of trying
    to stand as a language in its own right. The Python docs should specify
    what Python code actually does, not simply that Python wraps the C library.

    > When I learned Python several years ago, being able to interactively drive
    > and easily script foreign libraries was touted as one of its killer
    > applications. Numerical Python, wrapping BLAS, LINPACK, and FTPPACK was a
    > prime example. So in a sense, you are criticizing Python for being
    > successful at what I believe was one of its design goals.


    Having a good FFI is certainly an important feature but Python
    programs should first and foremost be Python programs. Compare the
    situation with Java or Common Lisp for example. Both of those
    languages have better FFI's than Python in every serious
    implementation (consider why SWIG is popular--because Python's C API
    is so clumsy), and yet the specs for those languages are far more
    thorough than the Python docs.
     
    Paul Rubin, Aug 8, 2005
    #18
  19. Robert Kern

    EP Guest

    Robert Kern <> wrote:

    > Which is exactly why I said at the beginning that people shouldn't
    > bother with this thread and should instead just get to work.
    >



    Robert, you are probably right, but I think how we get to work is important as well.

    What I posted was a little intellectually thin, but it would be nice to stir the collective energy toward some common (and useful) objectives. I think that something more than a superior language specification is required for a language to get a firm foothold in the IT world (and that is something I would personally like for Python.)

    It seems there are people very capable and willing to develop the good applications/tools/frameworks on top of Python, but too many of those projects do not gain critical mass; rather we have dozens of competing applications and frameworks that never blossom to their full potential. I'd love to see a little consensus on what "goodies" should be developed atop the language; what standards, principles, and API/hooks those goodies should provide; and then a collaborative effort to get there. Projects with a broader buy-in have a greater chance of achieving their potential.

    It does seem that perhaps some ground was gained with the WSGI effort. I understand Django [http://www.djangoproject.com/], a RoR alternative based on the WSGI spec, already has some buzz though "the cat got out of the bag a bit early" and Django is "not officially launched just yet."

    It makes sense to ask one's fellow developers and Python users what a new open source development should look and act like if one wants to develop something great. Open source code denotes sharing, but we should add teamwork and community involvement in the code as connotations if we want our open source to reach its potential.


    What are the top 5 developments, aside from specification and implementation details of the language itself, which Python still needs for greater success in the day to day IT world?




    EriPy pyDerson





    P.S. In terms of a more concrete suggestion, I propose the Python community form an intervention team who are ready to fly in and intercede any time a developer, whose brilliance has been expended in their heroic coding effort, goes to name their new module, package, or application with a "py" other than to the right of the dot.
     
    EP, Aug 8, 2005
    #19
  20. Robert Kern

    Robert Kern Guest

    EP wrote:
    > Robert Kern <> wrote:
    >
    >>Which is exactly why I said at the beginning that people shouldn't
    >>bother with this thread and should instead just get to work.

    >
    > Robert, you are probably right, but I think how we get to work is important as well.
    >
    > What I posted was a little intellectually thin, but it would be nice to stir the collective energy toward some common (and useful) objectives.


    What I'm trying to say is that posting to c.l.py is absolutely
    ineffective in achieving that goal. Code attracts people that like to
    code. Tedious, repetitive c.l.py threads attract people that like to
    write tedious, repetitive c.l.py threads. In the open source world, you
    can't tell people what to do. It's often a waste of time even to try to
    get them to *agree* on what they should do particularly when the group
    ("Python programmers") is so large and the goals ("create a powerful web
    framework as good as the language") are so amorphous.

    Ruby on Rails isn't the phenomenon that it is today because a bunch of
    Ruby programmers got together on c.l.ruby and all decided to work on one
    web app framework and bless it as the One True Way to write Ruby web
    apps. Instead, they wrote good code that solved their problems, code
    that would solve other people's problems, too. They released it in such
    a way that got people talking about their code and people talking about
    people talking about their code (and me talking about people talking
    about ... yeah).

    I'm not sure that this phenomenon is particularly repeatable. It was the
    result of a large number of uncontrollable factors and relied very
    heavily on network effects. Plone has, for a long time, made all-in-one
    distributions of itself+Zope+Python+et al. for Windows and Mac just like
    the one you tried for Ruby on Rails. When Zope was first released as
    open source, it got the same kind of "people talking about people
    talking ..." that Ruby on Rails is now getting; Zope was widely
    purported to be *the* Killer App for Python that would draw users of
    other languages in droves. Django is getting the right kind of
    attention, and is simple enough to get started with a small project, but
    it's in the unfortunate position of having come out *after* Ruby on
    Rails. You can do everything right and still not get what you want.

    There's a better question that you should have asked instead: "What can
    I do to help make Python a more attractive language to program?" And I
    would suggest that far and away, Python will get the largest payoff for
    your effort if you hammer hammer hammer on
    setuptools/PythonEggs/EasyInstall. Distribution affects *everyone* from
    the hobbiest, to the Java guy who just wants to try out one of the funky
    "dynamic languages," to the enterprise programmer. And there are a large
    number of diverse, small projects that don't need a whole lot of
    coordination with anybody else; you can do them without needing to forge
    much consensus.

    You can make your own packages distributable via eggs. You can sumbit
    patches for your favorite 3rd party packages to work well as eggs. You
    can build and donate binary eggs for the platforms you care about. You
    can build a GUI interface for managing the installation of eggs via
    EasyInstall. You can work out a way for eggs to work well with
    dpkg/rpm/whatever package manager your system uses. You can add
    signatures for eggs. You can work out a way to easy associate
    documentation packages associated with the runtime eggs. The more you
    improve this technology, even incrementally, the more people will buy
    into it and thus improve it for you, too.

    Or we can keep posting here. Your choice.

    --
    Robert Kern


    "In the fields of hell where the grass grows high
    Are the graves of dreams allowed to die."
    -- Richard Harter
     
    Robert Kern, Aug 8, 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. walala
    Replies:
    4
    Views:
    2,133
    Ralf Hildebrandt
    Sep 8, 2003
  2. Graeme Matthew

    Python is a gem ,another successful day ....

    Graeme Matthew, Jul 6, 2003, in forum: Python
    Replies:
    6
    Views:
    307
    Skip Montanaro
    Jul 8, 2003
  3. A.M. Kuchling

    Python doc experiment

    A.M. Kuchling, Sep 9, 2004, in forum: Python
    Replies:
    0
    Views:
    276
    A.M. Kuchling
    Sep 9, 2004
  4. Paul Rubin
    Replies:
    13
    Views:
    428
    Cliff Wells
    Aug 9, 2005
  5. Ertugrul Söylemez

    Experiment: Church lists in Python

    Ertugrul Söylemez, Jan 16, 2009, in forum: Python
    Replies:
    0
    Views:
    275
    Ertugrul Söylemez
    Jan 16, 2009
Loading...

Share This Page