Re: Do other Python GUI toolkits require this?

[James Stroud]

Bruno Desthuilliers wrote:
> Kevin Walzer a écrit :
> (snip)
> 
>> Thanks to all for an illuminating thread on the mathematical 
>> implications of "learning curve" and other aspects. This thread has 
>> wandered pretty far from my original question (above) 
> 
> 
> Noticed this too ?-)

I would have noticed, but my learning curve is rather steep.

(Did I use that right? ;)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Do other Python GUI toolkits require this?

[David Boddie]

On Monday 23 April 2007 15:55, Kevin Walzer wrote:

> I had originally thought that learning PyObjC might preclude me from
> having to learn Objective-C, but that seems not to be the case. I have
> previously found the same to be true with PyQt and wxPython--not knowing
> the toolkits as they are implemented in C++ is a serious handicap.

I'm not so sure about that. Certainly, it's useful to be able to read C++
example code, but none of the examples you see should require more than
a basic proficiency in C++.

I started using PyQt before I had more than basic C++ skills, and I don't
think it slowed me down too much.

> I've even found this to be the case with Tkinter: understanding the Tcl
> implementation of Tk (which I do, because I am also a Tcl developer) is
> a huge advantage.
> 
> Am I wrong to conclude that, if you want to do GUI programming in
> Python, then some level of proficiency with another language is not just
> recommended, but almost required? This is the case at least in my
> experience. When I first started learning Python a couple of years ago,
> I spun my wheels with it for months, because I couldn't figure out where
> to get started with GUI programming.

Of the common toolkits and frameworks, I started using Tkinter because
that's what came with Python, but I can't say that I'm comfortable with
it. Once I started using PyQt, I started to forget Tkinter, and now I
don't have a reason to go back to using it.

> Finally I set Python aside and took 
> up Tcl/Tk for awhile--its simplicity in building GUI's is more
> beginner-friendly. (No "there's more than one way to do it"--there's
> only one way to do it, and that's Tk.)
> 
> Now, coming back to Python with the Tk model of GUI development burned
> in my brain, I appreciate the breadth of functions that Python
> supports--but I still find myself "dropping down into Tcl" (!) to
> assemble elements of my GUI's--either to write a Python wrapper, or
> figure out how to implement something in pure Python.

While this is one of the strengths of Tcl/Tk/Tkinter, I think this is a
relatively rare thing to do with other toolkits and frameworks. For example,
there are people writing wrappers around Qt-based classes, but the only
people writing wrappers for Qt or KDE classes are the bindings authors
themselves.

> I understand the argument for Python having lots of bindings to
> different GUI toolkits. If you are already proficient with a GUI toolkit
> in a compiled language (Gtk, wxWidgets, Cocoa, Qt) then presumably
> switching to Python will speed up your development--learning Python is
> easy if you already know C++, for instance, and usually the Python
> bindings are just a "thin wrapper" over the compiled bits.

Yes and no. The bindings may be thin, but there are often other advantages
that make the bindings subtly different/better to use than the underlying
toolkit/framework. :-)

>From memory, PyGTK is more natural to use the GTK+ on its own because Python
provides the object-oriented features that you don't get in C, though there
are C++ bindings to GTK+ as well.

Another example would be the way PyQt handles Qt's signals and slots. In C++
you need to declare these with specific signatures at compile time, but
that would be a bit restrictive in Python. The result is that PyQt lets you
define and connect arbitrary signals, slots and normal Python methods at
run-time. (Actually, you don't even need to define signals.)

So, even the thin wrappers contain some value other than simply enabling you
to use Python. :-)

> But if you come to Python from the other direction--you're a relative
> beginner and you want to learn GUI programming without the complexities of
> compiled languages--then it's a lot harder to get started, ironically.
> Even Tkinter is a challenge for someone who doesn't know Tcl. The basics
> are easy enough--buttons, menus, labels, images--but doing anything
> sophisticated, such as trees, column views, drag-and-drop, and so on,
> requires extensions that may or may not be implemented in Python.

I think that's a specific Tkinter problem in many ways. However, the
expectations of many new users have also increased since I wrote my first
GUI program in Python, and that also influences the way people respond to
the different solutions on offer.

David
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Do other Python GUI toolkits require this?

[Diez B. Roggisch]

> I had originally thought that learning PyObjC might preclude me from
> having to learn Objective-C, but that seems not to be the case. I have
> previously found the same to be true with PyQt and wxPython--not knowing
> the toolkits as they are implemented in C++ is a serious handicap. I've
> even found this to be the case with Tkinter: understanding the Tcl
> implementation of Tk (which I do, because I am also a Tcl developer) is
> a huge advantage.
> 
> Am I wrong to conclude that, if you want to do GUI programming in
> Python, then some level of proficiency with another language is not just
> recommended, but almost required? This is the case at least in my
> experience. When I first started learning Python a couple of years ago,
> I spun my wheels with it for months, because I couldn't figure out where
> to get started with GUI programming. Finally I set Python aside and took
> up Tcl/Tk for awhile--its simplicity in building GUI's is more
> beginner-friendly. (No "there's more than one way to do it"--there's
> only one way to do it, and that's Tk.)
> 
> Now, coming back to Python with the Tk model of GUI development burned
> in my brain, I appreciate the breadth of functions that Python
> supports--but I still find myself "dropping down into Tcl" (!) to
> assemble elements of my GUI's--either to write a Python wrapper, or
> figure out how to implement something in pure Python.
> 
> I understand the argument for Python having lots of bindings to
> different GUI toolkits. If you are already proficient with a GUI toolkit
> in a compiled language (Gtk, wxWidgets, Cocoa, Qt) then presumably
> switching to Python will speed up your development--learning Python is
> easy if you already know C++, for instance, and usually the Python
> bindings are just a "thin wrapper" over the compiled bits. But if you
> come to Python from the other direction--you're a relative beginner and
> you want to learn GUI programming without the complexities of compiled
> languages--then it's a lot harder to get started, ironically. Even
> Tkinter is a challenge for someone who doesn't know Tcl. The basics are
> easy enough--buttons, menus, labels, images--but doing anything
> sophisticated, such as trees, column views, drag-and-drop, and so on,
> requires extensions that may or may not be implemented in Python.

I personally can't conclude with your conclusions :)

Some background: I've started with Tcl/Tk as a scripting language precisely
because of Tk - I liked the easy GUI creation, the layout management, and
it was available for Unix/Linux, my OS of choice.

So when I discovered Python about 7 or 8 years ago, I certainly had the
right mindset for Tk. So, I was able to create GUIs in Tkinter, yet it
never felt very comfortable - it just has too much Tclisms in there for my
taste. 

So for GUI-development, I moved on to Qt - and simply loved it. I do have
some C++-skillz, although these are somewhat rusty. And all I needed them
for was reading the excellent reference Qt-documentation. Just the
class-docs, not examples!

The last step then was PyObjC. I bought a mac roughly two years ago, and
immediately got interested in GUI-development there. I've never done a
single bit of ObjectiveC before, and even though I now have some few
classes done (mainly for interfacing with parts of OS X or other libraries
that weren't exposed to python, e.g. CIImage and CGImage processing), I
wouldn't say that I'm an ObjectiveC-programmer. 

The hardships for me with PyObjc stemmed from the unawareness and
unfamiliarity with the specifics of GUI-development under the mac in
general. E.g. the concepts of NIBs, NIB-classes, bundles and the like.

Now admittedly I'm not a totally fair comparison to you for judging the
matters at hand - I had a fair amount of exposure to different languages
before and while learning python. But especially for PyObjC I can say that
I became productive pretty fast without having to actually do serious or
even not so serious ObjectiveC-development. 

I'd rather say that using a gui-toolkit usually requires to adapt to
whatever concepts that toolkit has implemented. And certainly there are
some of these that are influenced by the language the toolkit has been
developed for. But for example ObjectiveC and Python both allow for dynamic
dispatch - thus lots of the design decisions would have been the same. And
as ObjecC and Cocoa heavily rely on NSArray and NSDictionary, which the
bridge has good marshalling code for, using python's lists & dicts is
natural and easy.

In Qt OTOH they implemented their dynamic dispatch themselves - but using
slots and signals is easy as cake as well. To me at least :)

Diez
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Do other Python GUI toolkits require this?

[Kevin Walzer]

Michael Bentley wrote:
> OK.  In order to kill the-thread-that-would-not-die(tm), I think I know 
> what I must do.  I'll print a correction:
> 
> On Apr 19, 2007, at 2:22 AM, Michael Bentley wrote:
>> ... I switched to PyObjC.  The
>> learning curve is rather steep IMO, but worth it.  One thing I think
>> I should mention though is that if you move to PyObjC -- do some
>> projects in Objective C first.  Otherwise your brain will implode.
> 
> Should be changed to:
> 
> .. I switched to PyObjC.  The
> learning-effort curve is rather steep IMO, but worth it.  One thing I think
> I should mention though is that if you move to PyObjC -- do some
> projects in Objective C first.  Otherwise your brain will implode.
> 
> Hope this helps,
> Michael ;-)
> 

I had originally thought that learning PyObjC might preclude me from 
having to learn Objective-C, but that seems not to be the case. I have 
previously found the same to be true with PyQt and wxPython--not knowing 
the toolkits as they are implemented in C++ is a serious handicap. I've 
even found this to be the case with Tkinter: understanding the Tcl 
implementation of Tk (which I do, because I am also a Tcl developer) is 
a huge advantage.

Am I wrong to conclude that, if you want to do GUI programming in 
Python, then some level of proficiency with another language is not just 
recommended, but almost required? This is the case at least in my 
experience. When I first started learning Python a couple of years ago, 
I spun my wheels with it for months, because I couldn't figure out where 
to get started with GUI programming. Finally I set Python aside and took 
up Tcl/Tk for awhile--its simplicity in building GUI's is more 
beginner-friendly. (No "there's more than one way to do it"--there's 
only one way to do it, and that's Tk.)

Now, coming back to Python with the Tk model of GUI development burned 
in my brain, I appreciate the breadth of functions that Python 
supports--but I still find myself "dropping down into Tcl" (!) to 
assemble elements of my GUI's--either to write a Python wrapper, or 
figure out how to implement something in pure Python.

I understand the argument for Python having lots of bindings to 
different GUI toolkits. If you are already proficient with a GUI toolkit 
in a compiled language (Gtk, wxWidgets, Cocoa, Qt) then presumably 
switching to Python will speed up your development--learning Python is 
easy if you already know C++, for instance, and usually the Python 
bindings are just a "thin wrapper" over the compiled bits. But if you 
come to Python from the other direction--you're a relative beginner and 
you want to learn GUI programming without the complexities of compiled 
languages--then it's a lot harder to get started, ironically. Even 
Tkinter is a challenge for someone who doesn't know Tcl. The basics are 
easy enough--buttons, menus, labels, images--but doing anything 
sophisticated, such as trees, column views, drag-and-drop, and so on, 
requires extensions that may or may not be implemented in Python.

-- 
Kevin Walzer
Code by Kevin
http://www.codebykevin.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Do other Python GUI toolkits require this?

[Michael Bentley]

OK.  In order to kill the-thread-that-would-not-die(tm), I think I  
know what I must do.  I'll print a correction:

On Apr 19, 2007, at 2:22 AM, Michael Bentley wrote:
> ... I switched to PyObjC.  The
> learning curve is rather steep IMO, but worth it.  One thing I think
> I should mention though is that if you move to PyObjC -- do some
> projects in Objective C first.  Otherwise your brain will implode.

Should be changed to:

.. I switched to PyObjC.  The
learning-effort curve is rather steep IMO, but worth it.  One thing I  
think
I should mention though is that if you move to PyObjC -- do some
projects in Objective C first.  Otherwise your brain will implode.

Hope this helps,
Michael ;-)



-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Do other Python GUI toolkits require this?

[Antoon Pardon]

On 2007-04-20, Dennis Lee Bieber <[EMAIL PROTECTED]> wrote:
> On 20 Apr 2007 12:25:40 GMT, Antoon Pardon <[EMAIL PROTECTED]>
> declaimed the following in comp.lang.python:
>
>> 
>> But if a wrong idea is circulating and nobody ever tries to correct it,
>> people will continue with the wrong idea. All I did was make a simple
>> remark, that as I suggested anyone could ignore, but that would allow
>> those willing to learn, to further investigate.
>>
>   But is it a "wrong idea" if 999 people interpret the phrase one way,
> and just 1 insists upon an interpretation that, while correct in a small
> technical area, results in misunderstanding when speaking with the other
> 999?
>
>   The lay person sees "productivity" as movement on the x-axis (I'm
> "here" [start of job], I need to get "there" [end of job]).

I dare you. Give some people some data: Like the productivity of each
month in a year and ask them to put those numbers on a graph. I bet most
will put the months on the x-axis and the productivity on the y-axis.

-- 
Antoon Pardon
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Do other Python GUI toolkits require this?

[Antoon Pardon]

On 2007-04-22, René Fleschenberg <[EMAIL PROTECTED]> wrote:
> Antoon Pardon schrieb:
>>> Who says the axes are labeled "familiarity" and "learning period"?   I
>>> just assume they are labeled (y-axis) "Effort" and (x-axis) "Knowledge"
>>> (or "skill" or ).  
>> 
>> You can assume all you want, but no serious person processing numbers
>> would choose axes like that.
>
> The vast majority of world population is not into "processing numbers",
> so why should they care?

They don't have to care at all. But if they don't care about how curves
are usually organized, maybe they are better of not using curves to
bring a message across, since it risks to bring the wrong message to
those who are familiar with curves.

-- 
Antoon Pardon
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Do other Python GUI toolkits require this?

[Antoon Pardon]

On 2007-04-21, Diez B. Roggisch <[EMAIL PROTECTED]> wrote:
> Antoon Pardon schrieb:
>> On 2007-04-20, Diez B. Roggisch <[EMAIL PROTECTED]> wrote:
 So if you have the choice between a steep or a shalow income curve
 you will prefer the shalow curve because a steep curve makes you
 think about verticale clifs and such?

 The analogy with a walk is just silly because curves are not like walks.
 Nobody will say something like: I won't invest in that company because
 it has a steep profit curve or the reverse: I'll invest in this company
 because it has an easy looking downhill going profit curve.
>>> Your whole argumentation bases on the fact that the result of the 
>>> learning process, and the success of it, has something to do with the 
>>> reached height - or y-axis-value - of your climb.
>>>
>>> Which is nonsense. The goal is to go from A - ignorance - to B - 
>>> knowledge - which both lie on the X-Axis.
>> 
>> Well if you want to do it that way, nobody can stop you, but people
>> in the habit of processing numbers usually put the time on the X-axis
>> like in time spend learning or exercising and put the other value
>> on the Y-axis. 
>
>
> You seem to live in a very limited world, where bezier-curves (note the 
> name...)
> are parametrized over t, but rendered on the x/y-axis happily going 
> forth and back and whatnot.

I'm not talking about bezier-curves or any parametric curve, because
it doesn't make sense to talk about steep and shalow curves then, since
there is no implication of hard/slow easy/fast associated then
with steep or shalow, you might as well use polar coordinates.

> If using knowledge as the x-axis and effort on the y-axis, the figure of 
> speech makes perfect sense.

That is an after the fact interpretation. There certain
rules/conventions in picking your variables when you want to draw a
curve. The association of steep and shalow of a curve with some real
world implication depends on those rules/conventions.

If you don't follow those rules/conventions don't think you can get
a message across by saying steep, because any data can be put on
a steep curve if you are allowed to pick how to draw your axes.

So your statement doesn't mean much more than: After I have played
with the paper, turned it over, rotated it a bit, the curve looks
steep.

>> That is because people prefer a curve going up and down while moving
>> to the right instead of going left and right while moving up.
>
> Which is obviously something people don't want to do in this context, 
> because "going down" doesn't make too much sense here, doesn't it? Or do 
> you want to cram the process of unlearning in the little figure of 
> speech as well?

Then those people shouldn't refer to curves. If people want to refer
to curves in order to bring a message accross then the message should
make sense to those familiar with curves. I can understand that some
people find that doing so, makes their message feel wrong. Not a
problem, use an other metaphor. Don't twist the metaphor to get
a message that feels all right to you but brings nonsense to those
who are familiar with the metaphor.

> But even a perfectly sense-making explanation can be found, I doubt that 
> you will ever acknowledge that you did make a mistake on this one - as 
> you always (or better never) do...

As far as I can see I don't differ from most people in this respect
on this news group.

-- 
Antoon Pardon
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Do other Python GUI toolkits require this?

[Antoon Pardon]

On 2007-04-20, Paul Boddie <[EMAIL PROTECTED]> wrote:
> On 20 Apr, 16:34, Antoon Pardon <[EMAIL PROTECTED]> wrote:
>> On 2007-04-20, Paul Boddie <[EMAIL PROTECTED]> wrote:
>>
>> > You could have knowledge or accomplishment
>> > on the X axis and effort or work on the Y axis.
>>
>> What else is effort than the time you spent on it?
>
> What's the difference between watching a television programme called
> "Useless Celebrity Factoids" for half an hour and spending the same
> amount of time studying for an exam involving useful information where
> you might also need to show some level of understanding of the subject
> matter?

Do you want to discus principals or the practical problem in setting
up a study?

> If that's not comparing similar measures of information, what's the
> difference between studying for an exam in a subject whose
> prerequisites are familiar to you and studying for one in an
> unfamiliar field, both for the same amount of time?

Same question. If you are looking at the principals there is no
problem, those already familiar now, already have spent time/effort
at the subject. So you should calculate that time too.

In practice those setting up a study, try to pick a activity
noone is very familiar with.

-- 
Antoon Pardon
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Do other Python GUI toolkits require this?

[René Fleschenberg]

Antoon Pardon schrieb:
>> Who says the axes are labeled "familiarity" and "learning period"?   I
>> just assume they are labeled (y-axis) "Effort" and (x-axis) "Knowledge"
>> (or "skill" or ).  
> 
> You can assume all you want, but no serious person processing numbers
> would choose axes like that.

The vast majority of world population is not into "processing numbers",
so why should they care?

-- 
René
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Do other Python GUI toolkits require this?

[Bruno Desthuilliers]

Kevin Walzer a écrit :
>  From the introduction to PyObjC, the Python-Objective-C bridge on Mac 
> OS X:
> 
> "As described in Objective-C for PyObjC users the creation of 
> Objective-C objects is a two-stage process. To initialize objects, first 
> call a class method to allocate the memory (typically alloc), and then 
> call an initializer (typically starts with init). Some classes have 
> class methods which perform this behind the scenes, especially classes 
> that create cached, immutable, or singleton instances."
> 
> An example:
> 
> myObject = NSObject.alloc().init()
> 
> I know Tkinter doesn't require any manual memory allocation of this 
> sort. Does wxPython, PyQt, PyGtk require anything like this when 
> creating objects?
> 

PyObjC is not a GUI toolkit, it's a bridge between Python and 
Objective-C (a smalltalk-inspired OO superset of ansi C).

And FWIW, under the hood, Python also uses this 2-stages 
instanciation/initialisation scheme (methods __new__ and __init__), even 
if it doesn't requires you to call them both explicitly.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Do other Python GUI toolkits require this?

[Bruno Desthuilliers]

Kevin Walzer a écrit :
(snip)
> Thanks to all for an illuminating thread on the mathematical 
> implications of "learning curve" and other aspects. This thread has 
> wandered pretty far from my original question (above) 

Noticed this too ?-)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Do other Python GUI toolkits require this?

[Kevin Walzer]

Kevin Walzer wrote:
>  From the introduction to PyObjC, the Python-Objective-C bridge on Mac 
> OS X:
> 
> "As described in Objective-C for PyObjC users the creation of 
> Objective-C objects is a two-stage process. To initialize objects, first 
> call a class method to allocate the memory (typically alloc), and then 
> call an initializer (typically starts with init). Some classes have 
> class methods which perform this behind the scenes, especially classes 
> that create cached, immutable, or singleton instances."
> 
> An example:
> 
> myObject = NSObject.alloc().init()
> 
> I know Tkinter doesn't require any manual memory allocation of this 
> sort. Does wxPython, PyQt, PyGtk require anything like this when 
> creating objects?
> 


Thanks to all for an illuminating thread on the mathematical 
implications of "learning curve" and other aspects. This thread has 
wandered pretty far from my original question (above) but I got at least 
one useful answer, so I am grateful.

-- 
Kevin Walzer
Code by Kevin
http://www.codebykevin.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Do other Python GUI toolkits require this?

[Diez B. Roggisch]

Antoon Pardon schrieb:
> On 2007-04-20, Diez B. Roggisch <[EMAIL PROTECTED]> wrote:
>>> So if you have the choice between a steep or a shalow income curve
>>> you will prefer the shalow curve because a steep curve makes you
>>> think about verticale clifs and such?
>>>
>>> The analogy with a walk is just silly because curves are not like walks.
>>> Nobody will say something like: I won't invest in that company because
>>> it has a steep profit curve or the reverse: I'll invest in this company
>>> because it has an easy looking downhill going profit curve.
>> Your whole argumentation bases on the fact that the result of the 
>> learning process, and the success of it, has something to do with the 
>> reached height - or y-axis-value - of your climb.
>>
>> Which is nonsense. The goal is to go from A - ignorance - to B - 
>> knowledge - which both lie on the X-Axis.
> 
> Well if you want to do it that way, nobody can stop you, but people
> in the habit of processing numbers usually put the time on the X-axis
> like in time spend learning or exercising and put the other value
> on the Y-axis. 


You seem to live in a very limited world, where bezier-curves (note the 
name...)
are parametrized over t, but rendered on the x/y-axis happily going 
forth and back and whatnot.

If using knowledge as the x-axis and effort on the y-axis, the figure of 
speech makes perfect sense.


> That is because people prefer a curve going up and down while moving
> to the right instead of going left and right while moving up.

Which is obviously something people don't want to do in this context, 
because "going down" doesn't make too much sense here, doesn't it? Or do 
you want to cram the process of unlearning in the little figure of 
speech as well?


But even a perfectly sense-making explanation can be found, I doubt that 
you will ever acknowledge that you did make a mistake on this one - as 
you always (or better never) do...
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Do other Python GUI toolkits require this? (OT)

[Roel Schroeven]

Hendrik van Rooyen schreef:
>  "Roel Schroeven" <[EMAIL PROTECTED]> wrote:
> 
>> Hendrik van Rooyen schreef:
>>>  "Steve Holden" <[EMAIL PROTECTED]> wrote:
>>>
>>>  
 Perhaps in Belgium they prefer climbing mountains over walking up and 
 down gentle hills?
>>> Mountains ?   Hills ?   In Belgium ??
>>>
>>> Its not called the battlefield of Europe for nothing...
>> I'm not sure if this adds anything of interest (well actually I'm pretty 
>> sure it doesn't), but our king Albert I was a fanatic mountain climber, 
>> until he died from a fall in 1934.
>>
> 
> Thanks - I was not aware of that.
> Adds a whole new dimension to the phrase:
> 
> "The Fall of a King"
> 
> What was he climbing when he fell, btw?

A rock in Marche-les-Dames, see the picture at 
http://nl.wikipedia.org/wiki/Afbeelding:Roy-m%C3%A5tche.jpg

That's in the Walloon region; Flanders is of course much more flat than 
that.

-- 
If I have been able to see further, it was only because I stood
on the shoulders of giants.  -- Isaac Newton

Roel Schroeven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Do other Python GUI toolkits require this? (OT)

[Hendrik van Rooyen]

 "Roel Schroeven" <[EMAIL PROTECTED]> wrote:

> Hendrik van Rooyen schreef:
> >  "Steve Holden" <[EMAIL PROTECTED]> wrote:
> > 
> >  
> >> Perhaps in Belgium they prefer climbing mountains over walking up and 
> >> down gentle hills?
> > 
> > Mountains ?   Hills ?   In Belgium ??
> > 
> > Its not called the battlefield of Europe for nothing...
> 
> I'm not sure if this adds anything of interest (well actually I'm pretty 
> sure it doesn't), but our king Albert I was a fanatic mountain climber, 
> until he died from a fall in 1934.
> 

Thanks - I was not aware of that.
Adds a whole new dimension to the phrase:

"The Fall of a King"

What was he climbing when he fell, btw?

- Hendrik

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Do other Python GUI toolkits require this? (OT)

[Roel Schroeven]

hg schreef:
> Roel Schroeven wrote:
> 
>> Hendrik van Rooyen schreef:
>>>  "Steve Holden" <[EMAIL PROTECTED]> wrote:
>>>
>>>  
 Perhaps in Belgium they prefer climbing mountains over walking up and
 down gentle hills?
>>> Mountains ?   Hills ?   In Belgium ??
>>>
>>> Its not called the battlefield of Europe for nothing...
>> I'm not sure if this adds anything of interest (well actually I'm pretty
>> sure it doesn't), but our king Albert I was a fanatic mountain climber,
>> until he died from a fall in 1934.
>>
> You never know ... was it a 'steep curve' ?

To stay in the general style of this thread, that largely depends on how 
you interpret that expression :-) I would say yes, but judge for 
yourself; this is the rock he was climbing when he fell: 
http://nl.wikipedia.org/wiki/Afbeelding:Roy-m%C3%A5tche.jpg

It's completely true that Belgium is a pretty flat country, but there 
are some regions featuring a somewhat more pronounced differences in height.

-- 
If I have been able to see further, it was only because I stood
on the shoulders of giants.  -- Isaac Newton

Roel Schroeven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Do other Python GUI toolkits require this? (OT)

[hg]

Roel Schroeven wrote:

> Hendrik van Rooyen schreef:
>>  "Steve Holden" <[EMAIL PROTECTED]> wrote:
>> 
>>  
>>> Perhaps in Belgium they prefer climbing mountains over walking up and
>>> down gentle hills?
>> 
>> Mountains ?   Hills ?   In Belgium ??
>> 
>> Its not called the battlefield of Europe for nothing...
> 
> I'm not sure if this adds anything of interest (well actually I'm pretty
> sure it doesn't), but our king Albert I was a fanatic mountain climber,
> until he died from a fall in 1934.
> 
> --
> If I have been able to see further, it was only because I stood
> on the shoulders of giants.  -- Isaac Newton
> 
> Roel Schroeven

You never know ... was it a 'steep curve' ?

hg

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Do other Python GUI toolkits require this?

[Jorge Godoy]

Dennis Lee Bieber <[EMAIL PROTECTED]> writes:

>   But is it a "wrong idea" if 999 people interpret the phrase one way,
> and just 1 insists upon an interpretation that, while correct in a small
> technical area, results in misunderstanding when speaking with the other
> 999?

You remind me of my grandpa: if all soldiers but one are marching with
the "wrong" foot ahead, who's wrong?

-- 
Jorge Godoy  <[EMAIL PROTECTED]>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Do other Python GUI toolkits require this?

[Gabriel Genellina]

En Thu, 19 Apr 2007 17:33:19 -0300, [EMAIL PROTECTED]  
<[EMAIL PROTECTED]> escribió:

> On Apr 19, 6:54 am, Antoon Pardon <[EMAIL PROTECTED]> wrote:

>> I don't know how you come to the conclusion that it is a mathematical
>> absurdity but consider this: If you find that common usage propagates
>> something that is incorrect, should we just shrug it off or should we
>> attemp a correction?
>
> a) In English, "learning curve" is not restricted to a mathematical
> plot--Webster's also defines it as "the course of progress made in
> learning something".  In that context, adding the adjective steep
> ("extremely or excessively high...STEEP implies such sharpness of
> pitch that ascent or descent is very difficult") makes sense.
>
> Trying to apply a mathematical definition to an English-language
> phrase is prone to incorrect outcomes.

I don't know if it's used in English, but my uncle says "open the light"  
and "close the light". From an electrician point of view, that's wrong: to  
turn the light on you have to close the circuit, and the light is off when  
the circuit is open.
A biologyst won't aggree on the common usage of "crocodrile tears". Such  
expressions should not be understood technically (I think they're known as  
idioms).
As English is not my native language, I sometimes got puzzled by some  
idioms. How much Python can be put in a nutshell? Almost nothing, so for  
me, the famous book starts diminished from the title.
Or, I would not consider "sleepping tight" a good thing, I prefer big and  
comfortable beds...

This is getting close to win the "longest off topic thread" award.

-- 
Gabriel Genellina
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Do other Python GUI toolkits require this?

[Paul Boddie]

On 20 Apr, 16:34, Antoon Pardon <[EMAIL PROTECTED]> wrote:
> On 2007-04-20, Paul Boddie <[EMAIL PROTECTED]> wrote:
>
> > You could have knowledge or accomplishment
> > on the X axis and effort or work on the Y axis.
>
> What else is effort than the time you spent on it?

What's the difference between watching a television programme called
"Useless Celebrity Factoids" for half an hour and spending the same
amount of time studying for an exam involving useful information where
you might also need to show some level of understanding of the subject
matter?

If that's not comparing similar measures of information, what's the
difference between studying for an exam in a subject whose
prerequisites are familiar to you and studying for one in an
unfamiliar field, both for the same amount of time?

Paul

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Do other Python GUI toolkits require this?

[Max Erickson]

Antoon Pardon <[EMAIL PROTECTED]> wrote:

> On 2007-04-20, Max Erickson <[EMAIL PROTECTED]> wrote:
>>
>> If we are being pedantic about describing a curve that shows the
>> progress of a person in learning a topic, there is no arguing
>> with you, a steep curve describes fast uptake and is a good
>> thing. 
>>
>> If we are being pedantic about what a learning curve describes,
>> it seems possible that it describes the rate of knowledge uptake
>> required to master a given topic, and that such a learning curve
>> could exclude people that were unable to take in knowledge at
>> that rate(for whatever reason) from mastering that topic, making
>> it reasonable to describe such a topic as both 'hard' and
>> 'having a steep learning curve'.
> 
> I must confess I don't follow you here. A rate is a single
> number. Now some second variable can be a function of this rate
> or vice versa but I can't make out what this second variable is
> supposed to be from your explanation.
> 

I'm stopping after this because it is offtopic noise, but take a
graph of position vs time for an object; the slope of that graph
happens to be related to the velocity of the object, so you can
'see' the velocity of the object even though the graph is of
position and time. The slope of the graph can be said to describe a
rate. 

(and a graph that showed the movement of the world around that
object would be quite different, and similar lines on those
different graphs would thus elecit rather different descriptions,
which is the point, pretending that all graphs of learning curves
only describe what you assume they describe and then being pedantic
about what information can be inferred from the graphs isn't going
to get you anywhere, hence this thread) 

My english is full of colloquialisms and idioms and I am not
interested in learning "Antoon Pardon's Dictionary of Exact Usage",
so I fear that further explanation will be fruitless. 


max

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Do other Python GUI toolkits require this?

[Antoon Pardon]

On 2007-04-20, Paul Boddie <[EMAIL PROTECTED]> wrote:
> On 20 Apr, 15:22, Antoon Pardon <[EMAIL PROTECTED]> wrote:
>> On 2007-04-20, Diez B. Roggisch <[EMAIL PROTECTED]> wrote:
>>
>> > Which is nonsense. The goal is to go from A - ignorance - to B -
>> > knowledge - which both lie on the X-Axis.
>>
>> Well if you want to do it that way, nobody can stop you, but people
>> in the habit of processing numbers usually put the time on the X-axis
>> like in time spend learning or exercising and put the other value
>> on the Y-axis.
>
> But time wasn't mentioned.

Wel what is the second variable then? 

> You could have knowledge or accomplishment
> on the X axis and effort or work on the Y axis.

What else is effort than the time you spent on it?

And yes you could do that, but in general it is not done because such an
organisation would make your curve no longer a function. Situations could
occur where more effort will result in less knowledge; where new material
seem to conflict with older material resulting in confusion.  With an
arrangement of axes like you proposed that would result in an inverted
c like curve. 

So you no longer have the familiar up and down movement but a movement
going left and right. 

-- 
Antoon Pardon
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Do other Python GUI toolkits require this?

[Antoon Pardon]

On 2007-04-20, Max Erickson <[EMAIL PROTECTED]> wrote:
>
> If we are being pedantic about describing a curve that shows the 
> progress of a person in learning a topic, there is no arguing with 
> you, a steep curve describes fast uptake and is a good thing.
>
> If we are being pedantic about what a learning curve describes, it 
> seems possible that it describes the rate of knowledge uptake 
> required to master a given topic, and that such a learning curve 
> could exclude people that were unable to take in knowledge at that 
> rate(for whatever reason) from mastering that topic, making it 
> reasonable to describe such a topic as both 'hard' and 'having a 
> steep learning curve'.

I must confess I don't follow you here. A rate is a single number.
Now some second variable can be a function of this rate or vice
versa but I can't make out what this second variable is supposed
to be from your explanation.

-- 
Antoon Pardon
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Do other Python GUI toolkits require this?

[Max Erickson]

Antoon Pardon <[EMAIL PROTECTED]> wrote:
>>> Just asserting how something can make a difference withouth
>>> arguing how in the particular case it actucally makes a
>>> difference is just a divertion tactic without real merrit.
>>> 
>> In the face of a notion that all steep curves determining
>> "progress made in something" must be good I stand with my mouth
>> agape. I am aware that common usage does not concur with
>> academic rigor, but in this particular instance I'm with the
>> common herd. 
> 
> Well that notion is entirely yours. My notion was only that
> progres in productivity, earnings and learning was good and thus
> that curves that are to be prefered tend to be the same shape for
> those three subjects. 
> 

If we are being pedantic about describing a curve that shows the 
progress of a person in learning a topic, there is no arguing with 
you, a steep curve describes fast uptake and is a good thing.

If we are being pedantic about what a learning curve describes, it 
seems possible that it describes the rate of knowledge uptake 
required to master a given topic, and that such a learning curve 
could exclude people that were unable to take in knowledge at that 
rate(for whatever reason) from mastering that topic, making it 
reasonable to describe such a topic as both 'hard' and 'having a 
steep learning curve'.


max

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Do other Python GUI toolkits require this?

[Paul Boddie]

On 20 Apr, 15:22, Antoon Pardon <[EMAIL PROTECTED]> wrote:
> On 2007-04-20, Diez B. Roggisch <[EMAIL PROTECTED]> wrote:
>
> > Which is nonsense. The goal is to go from A - ignorance - to B -
> > knowledge - which both lie on the X-Axis.
>
> Well if you want to do it that way, nobody can stop you, but people
> in the habit of processing numbers usually put the time on the X-axis
> like in time spend learning or exercising and put the other value
> on the Y-axis.

But time wasn't mentioned. You could have knowledge or accomplishment
on the X axis and effort or work on the Y axis. Subjects with more
material to learn could be said to have a "long learning curve"; an
example of such usage can be found here:

http://www.linuxplanet.com/linuxplanet/reviews/3207/5/

But if the nature of the material is not particularly challenging, you
could say that a "shallow learning curve" is involved: you don't need
to think very hard about the material. Conversely, a "steep learning
curve" in the popular sense suggests more effort being expended for a
given measure of material.

Paul

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Do other Python GUI toolkits require this?

[Tommy Grav]

On Apr 20, 2007, at 9:22 AM, Antoon Pardon wrote:

> Well if you want to do it that way, nobody can stop you, but people
> in the habit of processing numbers usually put the time on the X-axis
> like in time spend learning or exercising and put the other value
> on the Y-axis.
>
> That is because people prefer a curve going up and down while moving
> to the right instead of going left and right while moving up.

That depends all on what you are plotting. If you are after the  
amount of
work it was to go from uneducated to educated then a shallow slope is
preferable (with amount of work on the y axis, and degree of educated
on the x axis). Wether a shallow or steep slope is preferable is all  
dependent
on what one is actually measuring.

Cheers
   Tommy
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Do other Python GUI toolkits require this? (OT)

[Roel Schroeven]

Hendrik van Rooyen schreef:
>  "Steve Holden" <[EMAIL PROTECTED]> wrote:
> 
>  
>> Perhaps in Belgium they prefer climbing mountains over walking up and 
>> down gentle hills?
> 
> Mountains ?   Hills ?   In Belgium ??
> 
> Its not called the battlefield of Europe for nothing...

I'm not sure if this adds anything of interest (well actually I'm pretty 
sure it doesn't), but our king Albert I was a fanatic mountain climber, 
until he died from a fall in 1934.

-- 
If I have been able to see further, it was only because I stood
on the shoulders of giants.  -- Isaac Newton

Roel Schroeven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Do other Python GUI toolkits require this?

[Antoon Pardon]

On 2007-04-20, Diez B. Roggisch <[EMAIL PROTECTED]> wrote:
>> So if you have the choice between a steep or a shalow income curve
>> you will prefer the shalow curve because a steep curve makes you
>> think about verticale clifs and such?
>> 
>> The analogy with a walk is just silly because curves are not like walks.
>> Nobody will say something like: I won't invest in that company because
>> it has a steep profit curve or the reverse: I'll invest in this company
>> because it has an easy looking downhill going profit curve.
>
> Your whole argumentation bases on the fact that the result of the 
> learning process, and the success of it, has something to do with the 
> reached height - or y-axis-value - of your climb.
>
> Which is nonsense. The goal is to go from A - ignorance - to B - 
> knowledge - which both lie on the X-Axis.

Well if you want to do it that way, nobody can stop you, but people
in the habit of processing numbers usually put the time on the X-axis
like in time spend learning or exercising and put the other value
on the Y-axis. 

That is because people prefer a curve going up and down while moving
to the right instead of going left and right while moving up.

-- 
Antoon Pardon

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Do other Python GUI toolkits require this?

[Antoon Pardon]

On 2007-04-20, Paul Boddie <[EMAIL PROTECTED]> wrote:
> On 20 Apr, 09:21, Antoon Pardon <[EMAIL PROTECTED]> wrote:
>>
>> Indeed I have no wish to bow before common usage.
>
> Then nobody will understand you properly if you start referring to a
> "steep learning curve" when in their terminology you actually mean a
> "shallow learning curve". Certainly, this discussion has alerted me to
> a level of ambiguity with the term that would dissuade me from using
> it, but then it's a hand-waving kind of term, anyway, which would be
> better replaced with a proper description of whatever effect is
> supposed to be observable.

Well that I made some people aware was all I intended. Personaly
I don't use the term either unless I have an actual curve to
show which I can use to explain how to interpret it.

-- 
Antoon Pardon
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Do other Python GUI toolkits require this?

[Diez B. Roggisch]

Antoon Pardon schrieb:
> On 2007-04-19, Steve Holden <[EMAIL PROTECTED]> wrote:
>> Antoon Pardon wrote:
>>> On 2007-04-19, Steve Holden <[EMAIL PROTECTED]> wrote:
 Michael Bentley wrote:
> On Apr 19, 2007, at 4:11 AM, Antoon Pardon wrote:
>
>> On 2007-04-19, Michael Bentley <[EMAIL PROTECTED]> wrote:
 [...]  The
>>> learning curve is rather steep IMO, but worth it.
>> Just a throw in remark, that  you may ignore if you wish, but a steep
>> learning curve means that the subject is easily familiarized and that
>> the learning period is short.
>>
>> You seem to use it as if it is the opposite.
> Mathematical absurdities aside, it's the common usage -- but perhaps  
> you knew that.
>
>
 Perhaps in Belgium they prefer climbing mountains over walking up and 
 down gentle hills? Or possibly they will simply pick any nit that is 
 carelessly left within range?
>>> If it is just a nit, why don't you ignore my remark as I suggested?
>>>
>> Because I suffer from the quixotic urge to help stamp out obsessive 
>> compulsive behavior on c.l.py? This is self-defeating, of course, since 
>> it makes me appear obsessive compulsive in my own right ...
>>
>>> Now suppose I give you a graph that shows you how different people
>>> are making progress. Would you prefer the rather flat curves instead
>>> of the steep curves because the latter gives you the idea of someone
>>> having to conquer huge obstacles or would you choose the steep curve
>>> because they show you someone is getting results fast?
>>>
>> Suppose I should you a hill you have to climb? Would you rather don 
>> mountain boots and crampons to climb 3,000 feet up a vertical cliff or 
>> would you rather amble up, say, Ben Lomond with the other tourists?
> 
> So if you have the choice between a steep or a shalow income curve
> you will prefer the shalow curve because a steep curve makes you
> think about verticale clifs and such?
> 
> The analogy with a walk is just silly because curves are not like walks.
> Nobody will say something like: I won't invest in that company because
> it has a steep profit curve or the reverse: I'll invest in this company
> because it has an easy looking downhill going profit curve.

Your whole argumentation bases on the fact that the result of the 
learning process, and the success of it, has something to do with the 
reached height - or y-axis-value - of your climb.

Which is nonsense. The goal is to go from A - ignorance - to B - 
knowledge - which both lie on the X-Axis.

And you really argue that having to go 2 miles OVER THE GROUND on a 
shallow slope is worse than walking 2 miles OVER GROUND with the mount 
everest between you and your goal?

Diez
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Do other Python GUI toolkits require this?

[Antoon Pardon]

On 2007-04-20, Steve Holden <[EMAIL PROTECTED]> wrote:
> Antoon Pardon wrote:
>> On 2007-04-20, Steve Holden <[EMAIL PROTECTED]> wrote:
>>> Antoon Pardon wrote:
 On 2007-04-19, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> On Apr 19, 6:54 am, Antoon Pardon <[EMAIL PROTECTED]> wrote:
>> I don't know how you come to the conclusion that it is a mathematical
>> absurdity but consider this: If you find that common usage propagates
>> something that is incorrect, should we just shrug it off or should we
>> attemp a correction?
> a) In English, "learning curve" is not restricted to a mathematical
> plot--Webster's also defines it as "the course of progress made in
> learning something".  In that context, adding the adjective steep
> ("extremely or excessively high...STEEP implies such sharpness of
> pitch that ascent or descent is very difficult") makes sense.
 How much sense does it really make? Suppose we would talk about
 an income curve. Would you not prefer a steep curve over a shalow
 one? What about a productivity curve? It is all about the progress
 made in something.

 So how much sense does it make that a steep curve in earnings and
 productivity is good but a steep curve in learning is bad?

>>> Just as much sense as that a motor car is great for driving around in 
>>> but bad for being run over by. Context is everything. Do *all* steep 
>>> curves have to be good or all bad? What the hell happened to common sense?
>> 
>> You are just grabbing for straws. Sure context is everything. But you
>> don't make a case that the context makes a difference here. Are you
>> suggesting progres in productivity is good but progres in learning is bad?
>> 
> No, I'm suggesting that in the company of thousands of people, most of 
> whom agree that a "steep learning curve" means, in the face of all 
> logic, that something is difficult to learn, you stop banging your head 
> against the wall and trying to "prove" them "wrong" (presumably because 
> it's important to you to be "right").

Thousands of people can be wrong. Now I don't particularly want
to prove them wrong. But if instead of ignoring the remark as
I suggested, they start trying to prove they are right, I will
point out where their thinking is wrong.

> As has been said already at least twice in this thread, language is 
> about communication. Human beings aren't always entirely rational no 
> matter how much we may individually strive for correctness, and 
> sometimes our only options are to either go with the flow or stand 
> valiantly, pissing into the wind.

But if a wrong idea is circulating and nobody ever tries to correct it,
people will continue with the wrong idea. All I did was make a simple
remark, that as I suggested anyone could ignore, but that would allow
those willing to learn, to further investigate.

But what a terrible thing that seems to be.

>> Just asserting how something can make a difference withouth arguing
>> how in the particular case it actucally makes a difference is just
>> a divertion tactic without real merrit.
>> 
> In the face of a notion that all steep curves determining "progress made 
> in something" must be good I stand with my mouth agape. I am aware that 
> common usage does not concur with academic rigor, but in this particular 
> instance I'm with the common herd.

Well that notion is entirely yours. My notion was only that progres in
productivity, earnings and learning was good and thus that curves that
are to be prefered tend to be the same shape for those three subjects.

-- 
Antoon Pardon
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Do other Python GUI toolkits require this? (OT)

[Hendrik van Rooyen]

 "Steve Holden" <[EMAIL PROTECTED]> wrote:

 
> Perhaps in Belgium they prefer climbing mountains over walking up and 
> down gentle hills?

Mountains ?   Hills ?   In Belgium ??

Its not called the battlefield of Europe for nothing...

- Hendrik

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Do other Python GUI toolkits require this?

[Steve Holden]

Antoon Pardon wrote:
> On 2007-04-20, Steve Holden <[EMAIL PROTECTED]> wrote:
>> Antoon Pardon wrote:
>>> On 2007-04-19, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
 On Apr 19, 6:54 am, Antoon Pardon <[EMAIL PROTECTED]> wrote:
> I don't know how you come to the conclusion that it is a mathematical
> absurdity but consider this: If you find that common usage propagates
> something that is incorrect, should we just shrug it off or should we
> attemp a correction?
 a) In English, "learning curve" is not restricted to a mathematical
 plot--Webster's also defines it as "the course of progress made in
 learning something".  In that context, adding the adjective steep
 ("extremely or excessively high...STEEP implies such sharpness of
 pitch that ascent or descent is very difficult") makes sense.
>>> How much sense does it really make? Suppose we would talk about
>>> an income curve. Would you not prefer a steep curve over a shalow
>>> one? What about a productivity curve? It is all about the progress
>>> made in something.
>>>
>>> So how much sense does it make that a steep curve in earnings and
>>> productivity is good but a steep curve in learning is bad?
>>>
>> Just as much sense as that a motor car is great for driving around in 
>> but bad for being run over by. Context is everything. Do *all* steep 
>> curves have to be good or all bad? What the hell happened to common sense?
> 
> You are just grabbing for straws. Sure context is everything. But you
> don't make a case that the context makes a difference here. Are you
> suggesting progres in productivity is good but progres in learning is bad?
> 
No, I'm suggesting that in the company of thousands of people, most of 
whom agree that a "steep learning curve" means, in the face of all 
logic, that something is difficult to learn, you stop banging your head 
against the wall and trying to "prove" them "wrong" (presumably because 
it's important to you to be "right").

As has been said already at least twice in this thread, language is 
about communication. Human beings aren't always entirely rational no 
matter how much we may individually strive for correctness, and 
sometimes our only options are to either go with the flow or stand 
valiantly, pissing into the wind.

> Just asserting how something can make a difference withouth arguing
> how in the particular case it actucally makes a difference is just
> a divertion tactic without real merrit.
> 
In the face of a notion that all steep curves determining "progress made 
in something" must be good I stand with my mouth agape. I am aware that 
common usage does not concur with academic rigor, but in this particular 
instance I'm with the common herd.

regards
  Steve
-- 
Steve Holden   +44 150 684 7255  +1 800 494 3119
Holden Web LLC/Ltd  http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden
Recent Ramblings   http://holdenweb.blogspot.com

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Do other Python GUI toolkits require this?

[Paul Boddie]

On 20 Apr, 09:21, Antoon Pardon <[EMAIL PROTECTED]> wrote:
>
> Indeed I have no wish to bow before common usage.

Then nobody will understand you properly if you start referring to a
"steep learning curve" when in their terminology you actually mean a
"shallow learning curve". Certainly, this discussion has alerted me to
a level of ambiguity with the term that would dissuade me from using
it, but then it's a hand-waving kind of term, anyway, which would be
better replaced with a proper description of whatever effect is
supposed to be observable.

It seems to me that the original term isn't directly applicable to
most situations where it is applied in general usage. For example,
someone talking about the learning curve involved in riding a bicycle
is taking a term originally used to describe effects observed when
people carry out the same task repeatedly and applying it to an
activity which involves a number of different cooperating tasks or
processes.

> I prefer to think about things and dare to speak out when they don't seem to 
> make sense.
>
> Just repeating common usage propagates a lot of nonsense.

Languages and their constituent parts change over time. Here's a
relevant article on the topic:

http://groups.google.com/group/alt.usage.english/msg/face58f687589a6c

Paul

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Do other Python GUI toolkits require this?

[Christophe]

Nigel Rowe a écrit :
> On Thu, 19 Apr 2007 19:11, Antoon Pardon wrote in comp.lang.python:
>> On 2007-04-19, Michael Bentley <[EMAIL PROTECTED]> wrote:
> 
> 
> 
>>> The learning curve is rather steep IMO, but worth it.
>> Just a throw in remark, that  you may ignore if you wish, but a steep
>> learning curve means that the subject is easily familiarized and that
>> the learning period is short.
>>
>> You seem to use it as if it is the opposite.
>>
> 
> Who says the axes are labeled "familiarity" and "learning period"?   I
> just assume they are labeled (y-axis) "Effort" and (x-axis) "Knowledge"
> (or "skill" or ).  
> 
> Which means that something with a 'steep learning curve' requires a lot
> of effort to achieve a small amount of knowledge (or skill or ...).

Funny, I would have placed on the x axis the time, and on the y axis 
"Knowledge". And Effort = lambda*time where lambda is the amount of 
effort per minute you are able to produce. Thus I always found it weird 
to call a steep learning curve something hard to learn.

Disclaimer: I have never made any study in that field, never read any 
reports or anything like that. It just feels much more natural for me to 
place the time on the x axis.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Do other Python GUI toolkits require this?

[Antoon Pardon]

On 2007-04-20, Steve Holden <[EMAIL PROTECTED]> wrote:
> Antoon Pardon wrote:
>> On 2007-04-19, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>>> On Apr 19, 6:54 am, Antoon Pardon <[EMAIL PROTECTED]> wrote:
 I don't know how you come to the conclusion that it is a mathematical
 absurdity but consider this: If you find that common usage propagates
 something that is incorrect, should we just shrug it off or should we
 attemp a correction?
>>> a) In English, "learning curve" is not restricted to a mathematical
>>> plot--Webster's also defines it as "the course of progress made in
>>> learning something".  In that context, adding the adjective steep
>>> ("extremely or excessively high...STEEP implies such sharpness of
>>> pitch that ascent or descent is very difficult") makes sense.
>> 
>> How much sense does it really make? Suppose we would talk about
>> an income curve. Would you not prefer a steep curve over a shalow
>> one? What about a productivity curve? It is all about the progress
>> made in something.
>> 
>> So how much sense does it make that a steep curve in earnings and
>> productivity is good but a steep curve in learning is bad?
>> 
> Just as much sense as that a motor car is great for driving around in 
> but bad for being run over by. Context is everything. Do *all* steep 
> curves have to be good or all bad? What the hell happened to common sense?

You are just grabbing for straws. Sure context is everything. But you
don't make a case that the context makes a difference here. Are you
suggesting progres in productivity is good but progres in learning is bad?

Just asserting how something can make a difference withouth arguing
how in the particular case it actucally makes a difference is just
a divertion tactic without real merrit.

-- 
Antoon Pardon
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Do other Python GUI toolkits require this?

[Antoon Pardon]

On 2007-04-20, Roel Schroeven <[EMAIL PROTECTED]> wrote:
> Antoon Pardon schreef:
>> On 2007-04-19, Wayne Brehaut <[EMAIL PROTECTED]> wrote:
>>> So the remark that " a steep learning curve means that the subject is
>>> easily familiarized and that the learning period is short" is
>>> completely incorrect on two points (i.e., all points that are
>>> relevant): first, steep always implies much to learn in a relatively
>>> short time (what else could the slope of a curve possibly mean
>>> "mathematicallY" or logically?);
>> 
>> No it doesn't imply that at all. A learning curve doesn't show some
>> goal of a person who was given just so much time to familiarize himself
>> with some material. A learning curve shows the progres that is made
>> in familiarizing one self while studying. A steep curve means a
>> lot of actual learning in a short time.
>
> >> A learning curve is conventionally the graph of a function of
> >> "quantity to be learned" vs. time,
>
> > No it doesn't. A learning curve is the graph that somehow quantifies
> > what is actually learned vs time.
>
> Do you have any reference to back that up?

http://en.wikipedia.org/wiki/Experience_curve_effects

Where you will also learn that learning curves by what values
are generally plotted go downwards.

-- 
Antoon Pardon
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Do other Python GUI toolkits require this?

[Steve Holden]

Antoon Pardon wrote:
> On 2007-04-19, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>> On Apr 19, 6:54 am, Antoon Pardon <[EMAIL PROTECTED]> wrote:
>>> I don't know how you come to the conclusion that it is a mathematical
>>> absurdity but consider this: If you find that common usage propagates
>>> something that is incorrect, should we just shrug it off or should we
>>> attemp a correction?
>> a) In English, "learning curve" is not restricted to a mathematical
>> plot--Webster's also defines it as "the course of progress made in
>> learning something".  In that context, adding the adjective steep
>> ("extremely or excessively high...STEEP implies such sharpness of
>> pitch that ascent or descent is very difficult") makes sense.
> 
> How much sense does it really make? Suppose we would talk about
> an income curve. Would you not prefer a steep curve over a shalow
> one? What about a productivity curve? It is all about the progress
> made in something.
> 
> So how much sense does it make that a steep curve in earnings and
> productivity is good but a steep curve in learning is bad?
> 
Just as much sense as that a motor car is great for driving around in 
but bad for being run over by. Context is everything. Do *all* steep 
curves have to be good or all bad? What the hell happened to common sense?

>> Trying to apply a mathematical definition to an English-language
>> phrase is prone to incorrect outcomes.
>>
>> b) The purpose of language is to communicate.  In English, if a phrase
>> now means something in common usage, then that is (one of) its current
>> definition(s)--this is possibly different from some other languages
>> where there is an attempt to have an "officially sanctioned" set of
>> definitions and spellings that may differ from common usage.  If you
>> find that everyone else means something when they say a phrase, you'd
>> best learn what they mean if you want to be speaking the same language
>> (and hence be able to communicate with them).
> 
> But the problem is that even if this would be only a way to communicate
> in englishi, a lot of people get the wrong idea about real curves from
> this idiom, as this thread shows. So even if you only want to communicate
> one specific idea that comes accross as intended, you also propagate
> a lot of nonsense with it.
> 
Well, I have to bow to your expertise when it comes to propagating nonsense.

regards
  Steve
-- 
Steve Holden   +44 150 684 7255  +1 800 494 3119
Holden Web LLC/Ltd  http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden
Recent Ramblings   http://holdenweb.blogspot.com

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Do other Python GUI toolkits require this?

[Jan Danielsson]

Antoon Pardon wrote:
>> a) In English, "learning curve" is not restricted to a mathematical
>> plot--Webster's also defines it as "the course of progress made in
>> learning something".  In that context, adding the adjective steep
>> ("extremely or excessively high...STEEP implies such sharpness of
>> pitch that ascent or descent is very difficult") makes sense.
> 
> How much sense does it really make? Suppose we would talk about
> an income curve. Would you not prefer a steep curve over a shalow
> one? What about a productivity curve? It is all about the progress
> made in something.

   I don't think I have seen "steep learning curve" used in that sense
prior to reading your post. I have seen it being used as "what a steep
cliff to climb!" (i.e. would would have been much easier with a
"flatter" one). OTOH, I just went to an (Am.) English school my first
school year, and language is not one of my fields of interest. So I'll
just shut up and go away.


-- 
Kind regards,
Jan Danielsson
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Do other Python GUI toolkits require this?

[Roel Schroeven]

Antoon Pardon schreef:
> On 2007-04-19, Wayne Brehaut <[EMAIL PROTECTED]> wrote:
>> So the remark that " a steep learning curve means that the subject is
>> easily familiarized and that the learning period is short" is
>> completely incorrect on two points (i.e., all points that are
>> relevant): first, steep always implies much to learn in a relatively
>> short time (what else could the slope of a curve possibly mean
>> "mathematicallY" or logically?);
> 
> No it doesn't imply that at all. A learning curve doesn't show some
> goal of a person who was given just so much time to familiarize himself
> with some material. A learning curve shows the progres that is made
> in familiarizing one self while studying. A steep curve means a
> lot of actual learning in a short time.

 >> A learning curve is conventionally the graph of a function of
 >> "quantity to be learned" vs. time,

 > No it doesn't. A learning curve is the graph that somehow quantifies
 > what is actually learned vs time.

Do you have any reference to back that up?

As I understand it, a learning curve plots the learning effort vs. the 
progress made. A steep learning curve means you need to learn a lot in 
order to make a little progress.

-- 
If I have been able to see further, it was only because I stood
on the shoulders of giants.  -- Isaac Newton

Roel Schroeven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Do other Python GUI toolkits require this?

[Antoon Pardon]

On 2007-04-20, Nigel Rowe <[EMAIL PROTECTED]> wrote:
> On Thu, 19 Apr 2007 19:11, Antoon Pardon wrote in comp.lang.python:
>> On 2007-04-19, Michael Bentley <[EMAIL PROTECTED]> wrote:
>
>
>
>>> The learning curve is rather steep IMO, but worth it.
>> 
>> Just a throw in remark, that  you may ignore if you wish, but a steep
>> learning curve means that the subject is easily familiarized and that
>> the learning period is short.
>> 
>> You seem to use it as if it is the opposite.
>> 
>
> Who says the axes are labeled "familiarity" and "learning period"?   I
> just assume they are labeled (y-axis) "Effort" and (x-axis) "Knowledge"
> (or "skill" or ).  

You can assume all you want, but no serious person processing numbers
would choose axes like that.

-- 
Antoon Pardon
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Do other Python GUI toolkits require this?

[Antoon Pardon]

On 2007-04-19, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> On Apr 19, 6:54 am, Antoon Pardon <[EMAIL PROTECTED]> wrote:
>> I don't know how you come to the conclusion that it is a mathematical
>> absurdity but consider this: If you find that common usage propagates
>> something that is incorrect, should we just shrug it off or should we
>> attemp a correction?
>
> a) In English, "learning curve" is not restricted to a mathematical
> plot--Webster's also defines it as "the course of progress made in
> learning something".  In that context, adding the adjective steep
> ("extremely or excessively high...STEEP implies such sharpness of
> pitch that ascent or descent is very difficult") makes sense.

How much sense does it really make? Suppose we would talk about
an income curve. Would you not prefer a steep curve over a shalow
one? What about a productivity curve? It is all about the progress
made in something.

So how much sense does it make that a steep curve in earnings and
productivity is good but a steep curve in learning is bad?

> Trying to apply a mathematical definition to an English-language
> phrase is prone to incorrect outcomes.
>
> b) The purpose of language is to communicate.  In English, if a phrase
> now means something in common usage, then that is (one of) its current
> definition(s)--this is possibly different from some other languages
> where there is an attempt to have an "officially sanctioned" set of
> definitions and spellings that may differ from common usage.  If you
> find that everyone else means something when they say a phrase, you'd
> best learn what they mean if you want to be speaking the same language
> (and hence be able to communicate with them).

But the problem is that even if this would be only a way to communicate
in englishi, a lot of people get the wrong idea about real curves from
this idiom, as this thread shows. So even if you only want to communicate
one specific idea that comes accross as intended, you also propagate
a lot of nonsense with it.

-- 
Antoon Pardon
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Do other Python GUI toolkits require this?

[Antoon Pardon]

On 2007-04-19, Wayne Brehaut <[EMAIL PROTECTED]> wrote:
> On 19 Apr 2007 10:54:20 GMT, Antoon Pardon <[EMAIL PROTECTED]>
> wrote:
>
>>On 2007-04-19, Michael Bentley <[EMAIL PROTECTED]> wrote:
>>>
>>> On Apr 19, 2007, at 4:11 AM, Antoon Pardon wrote:
>>>
 On 2007-04-19, Michael Bentley <[EMAIL PROTECTED]> wrote:
>
> PyObjC is pretty slick (and since Ronald hasn't made any commits in a
> while I'm nearly certain it'll show up in the next official
> distribution of the devtools). About the time you gave up on PyQt on
> the Mac and switched over to Tkinter, I switched to PyObjC.  The
> learning curve is rather steep IMO, but worth it.

 Just a throw in remark, that  you may ignore if you wish, but a steep
 learning curve means that the subject is easily familiarized and that
 the learning period is short.

 You seem to use it as if it is the opposite.
>>>
>>> Mathematical absurdities aside, it's the common usage -- but perhaps  
>>> you knew that.
>>
>>I don't know how you come to the conclusion that it is a mathematical
>>absurdity but consider this: If you find that common usage propagates
>>something that is incorrect, should we just shrug it off or should we
>>attemp a correction? There is always a chance that one day you find
>>yourself exposed to a learning curve while going through a document.
>>If you just depend on common usage you will probably draw the wrong
>>conclusion.
>
> The only way one could assume the "common usage" to be a mathematical
> absurdity would be not to think about it or not to have much
> mathematical insight or "maturity".  Is a vertical cliff not steep no
> matter how high it is?  And is a gentle grade (say <= 10%) not
> un-steep no matter how long it is?  Is the slope of a curve dependent
> on its length?
>
> So the remark that " a steep learning curve means that the subject is
> easily familiarized and that the learning period is short" is
> completely incorrect on two points (i.e., all points that are
> relevant): first, steep always implies much to learn in a relatively
> short time (what else could the slope of a curve possibly mean
> "mathematicallY" or logically?);

No it doesn't imply that at all. A learning curve doesn't show some
goal of a person who was given just so much time to familiarize himself
with some material. A learning curve shows the progres that is made
in familiarizing one self while studying. A steep curve means a
lot of actual learning in a short time.

> second, steepness is independent of
> length, so "steep" has no implication in general about how long the
> learning curve will be--on the contrary, in fact, it's quite possible
> that a learning curve will never have any great challenges (steep
> portions) but be only a very long gradual process--as the learning of
> many natural languages is.

That doesn't contradict that if one language has a steeper curve to
learn than a second. Familiarisation with the first language will
be faster and easier than with the second.

> A learning curve is conventionally the graph of a function of
> "quantity to be learned" vs. time,

No it doesn't. A learning curve is the graph that somehow quantifies
what is actually learned vs time.

-- 
Antoon Pardon
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Do other Python GUI toolkits require this?

[Antoon Pardon]

On 2007-04-19, Steve Holden <[EMAIL PROTECTED]> wrote:
> Antoon Pardon wrote:
>> On 2007-04-19, Steve Holden <[EMAIL PROTECTED]> wrote:
>>> Michael Bentley wrote:
 On Apr 19, 2007, at 4:11 AM, Antoon Pardon wrote:

> On 2007-04-19, Michael Bentley <[EMAIL PROTECTED]> wrote:
>>> [...]  The
>> learning curve is rather steep IMO, but worth it.
> Just a throw in remark, that  you may ignore if you wish, but a steep
> learning curve means that the subject is easily familiarized and that
> the learning period is short.
>
> You seem to use it as if it is the opposite.
 Mathematical absurdities aside, it's the common usage -- but perhaps  
 you knew that.


>>> Perhaps in Belgium they prefer climbing mountains over walking up and 
>>> down gentle hills? Or possibly they will simply pick any nit that is 
>>> carelessly left within range?
>> 
>> If it is just a nit, why don't you ignore my remark as I suggested?
>> 
> Because I suffer from the quixotic urge to help stamp out obsessive 
> compulsive behavior on c.l.py? This is self-defeating, of course, since 
> it makes me appear obsessive compulsive in my own right ...
>
>> Now suppose I give you a graph that shows you how different people
>> are making progress. Would you prefer the rather flat curves instead
>> of the steep curves because the latter gives you the idea of someone
>> having to conquer huge obstacles or would you choose the steep curve
>> because they show you someone is getting results fast?
>> 
> Suppose I should you a hill you have to climb? Would you rather don 
> mountain boots and crampons to climb 3,000 feet up a vertical cliff or 
> would you rather amble up, say, Ben Lomond with the other tourists?

So if you have the choice between a steep or a shalow income curve
you will prefer the shalow curve because a steep curve makes you
think about verticale clifs and such?

The analogy with a walk is just silly because curves are not like walks.
Nobody will say something like: I won't invest in that company because
it has a steep profit curve or the reverse: I'll invest in this company
because it has an easy looking downhill going profit curve.

> Clearly you have no wish to bow before common usage. be careful this 
> doesn't put you in a universe with only one inhabitant. We all have to 
> get along.

Indeed I have no wish to bow before common usage. I prefer to think
about things and dare to speak out when they don't seem to make sense.

Just repeating common usage propagates a lot of nonsense.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Do other Python GUI toolkits require this?

[Nigel Rowe]

On Thu, 19 Apr 2007 19:11, Antoon Pardon wrote in comp.lang.python:
> On 2007-04-19, Michael Bentley <[EMAIL PROTECTED]> wrote:



>> The learning curve is rather steep IMO, but worth it.
> 
> Just a throw in remark, that  you may ignore if you wish, but a steep
> learning curve means that the subject is easily familiarized and that
> the learning period is short.
> 
> You seem to use it as if it is the opposite.
> 

Who says the axes are labeled "familiarity" and "learning period"?   I
just assume they are labeled (y-axis) "Effort" and (x-axis) "Knowledge"
(or "skill" or ).  

Which means that something with a 'steep learning curve' requires a lot
of effort to achieve a small amount of knowledge (or skill or ...).

-- 
Nigel Rowe
A pox upon the spammers that make me write my address like..
rho (snail) swiftdsl (stop) com (stop) au
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Do other Python GUI toolkits require this?

[[EMAIL PROTECTED]]

On Apr 19, 6:54 am, Antoon Pardon <[EMAIL PROTECTED]> wrote:
> I don't know how you come to the conclusion that it is a mathematical
> absurdity but consider this: If you find that common usage propagates
> something that is incorrect, should we just shrug it off or should we
> attemp a correction?

a) In English, "learning curve" is not restricted to a mathematical
plot--Webster's also defines it as "the course of progress made in
learning something".  In that context, adding the adjective steep
("extremely or excessively high...STEEP implies such sharpness of
pitch that ascent or descent is very difficult") makes sense.

Trying to apply a mathematical definition to an English-language
phrase is prone to incorrect outcomes.

b) The purpose of language is to communicate.  In English, if a phrase
now means something in common usage, then that is (one of) its current
definition(s)--this is possibly different from some other languages
where there is an attempt to have an "officially sanctioned" set of
definitions and spellings that may differ from common usage.  If you
find that everyone else means something when they say a phrase, you'd
best learn what they mean if you want to be speaking the same language
(and hence be able to communicate with them).

-- 
http://mail.python.org/mailman/listinfo/python-list

RE: Do other Python GUI toolkits require this?

[Sampson, David]

 I don't know how this whole things started, 

But it is funny on both sides. And hilarious from the outside. It sounds
like university Banter really. And who can avoid getting their 2 cents
in. Honestly

And people say computers are all about science. You guys prove that we
are all as much tech geeks and semantic geeks.

>From my own experiential education background, and currently trying to
learn python I would say my exposure to python as a scripting language
is a logical extension to my knowledge of DOS and BASH scripting so in
that respect I am on a shallow learning curve. That is little effort
(say 5 on the X axis) over a given time (say 10 y). 

Now, my goal is to take what I had learn about VB6 over the last number
of months to modify a chunk of in-house software My learning curve was
steeper. That is I had the same amount of time (10 y) but I had to put
in some more effort, so a moderate curve using 10 X as my peak, or point
where I plateau.

However where I as a newbie am having a hard time is programming a GUI
and full application using python (hence why I saw the topic), and
understanding OOP. Therefore right now I feel as though I am on a steep
learning curve. So maybe 20 or 30 on the X and I still have the same
amount of time.

To further support this I took the first result of google (of course the
worlds most authoritative resource on randomness) and went to this BLOG
(worlds best phenomena of random and unsubstantiated opinions).
http://createwhatmattersmost.blogspot.com/2006/10/learning-curve-explain
ed.html

And found this

I guess I'm approaching the "knee" of the learning curve, that magical
transition point on the learning at which you begin to generate results
far out of proportion to time and energy expended.

This tells me my understanding is the common accepted one of X= Effort,
Y= time or productivity  ... But really productivity is a function of
time.


C'mon now folks, if this is university banter the least I should see is
some referencing.

Thanks for demonstrating my own lack of will power and propensity to
engage in both of your OCB.

Now I must get back to my steep learning curve or else I will be back on
the street.

Cheers


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf
Of Steve Holden
Sent: April 19, 2007 08:25
To: python-list@python.org
Subject: Re: Do other Python GUI toolkits require this?

Antoon Pardon wrote:
> On 2007-04-19, Steve Holden <[EMAIL PROTECTED]> wrote:
>> Michael Bentley wrote:
>>> On Apr 19, 2007, at 4:11 AM, Antoon Pardon wrote:
>>>
>>>> On 2007-04-19, Michael Bentley <[EMAIL PROTECTED]> wrote:
>> [...]  The
>>>>> learning curve is rather steep IMO, but worth it.
>>>> Just a throw in remark, that  you may ignore if you wish, but a 
>>>> steep learning curve means that the subject is easily familiarized 
>>>> and that the learning period is short.
>>>>
>>>> You seem to use it as if it is the opposite.
>>> Mathematical absurdities aside, it's the common usage -- but perhaps

>>> you knew that.
>>>
>>>
>> Perhaps in Belgium they prefer climbing mountains over walking up and

>> down gentle hills? Or possibly they will simply pick any nit that is 
>> carelessly left within range?
> 
> If it is just a nit, why don't you ignore my remark as I suggested?
> 
Because I suffer from the quixotic urge to help stamp out obsessive
compulsive behavior on c.l.py? This is self-defeating, of course, since
it makes me appear obsessive compulsive in my own right ...

> Now suppose I give you a graph that shows you how different people are

> making progress. Would you prefer the rather flat curves instead of 
> the steep curves because the latter gives you the idea of someone 
> having to conquer huge obstacles or would you choose the steep curve 
> because they show you someone is getting results fast?
> 
Suppose I should you a hill you have to climb? Would you rather don
mountain boots and crampons to climb 3,000 feet up a vertical cliff or
would you rather amble up, say, Ben Lomond with the other tourists?

Clearly you have no wish to bow before common usage. be careful this
doesn't put you in a universe with only one inhabitant. We all have to
get along.

obsessive-compulsive-ly y'rs  - steve
-- 
Steve Holden   +44 150 684 7255  +1 800 494 3119
Holden Web LLC/Ltd  http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden
Recent Ramblings   http://holdenweb.blogspot.com

--
http://mail.python.org/mailman/listinfo/python-list
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Do other Python GUI toolkits require this?

[Steve Holden]

Antoon Pardon wrote:
> On 2007-04-19, Steve Holden <[EMAIL PROTECTED]> wrote:
>> Michael Bentley wrote:
>>> On Apr 19, 2007, at 4:11 AM, Antoon Pardon wrote:
>>>
 On 2007-04-19, Michael Bentley <[EMAIL PROTECTED]> wrote:
>> [...]  The
> learning curve is rather steep IMO, but worth it.
 Just a throw in remark, that  you may ignore if you wish, but a steep
 learning curve means that the subject is easily familiarized and that
 the learning period is short.

 You seem to use it as if it is the opposite.
>>> Mathematical absurdities aside, it's the common usage -- but perhaps  
>>> you knew that.
>>>
>>>
>> Perhaps in Belgium they prefer climbing mountains over walking up and 
>> down gentle hills? Or possibly they will simply pick any nit that is 
>> carelessly left within range?
> 
> If it is just a nit, why don't you ignore my remark as I suggested?
> 
Because I suffer from the quixotic urge to help stamp out obsessive 
compulsive behavior on c.l.py? This is self-defeating, of course, since 
it makes me appear obsessive compulsive in my own right ...

> Now suppose I give you a graph that shows you how different people
> are making progress. Would you prefer the rather flat curves instead
> of the steep curves because the latter gives you the idea of someone
> having to conquer huge obstacles or would you choose the steep curve
> because they show you someone is getting results fast?
> 
Suppose I should you a hill you have to climb? Would you rather don 
mountain boots and crampons to climb 3,000 feet up a vertical cliff or 
would you rather amble up, say, Ben Lomond with the other tourists?

Clearly you have no wish to bow before common usage. be careful this 
doesn't put you in a universe with only one inhabitant. We all have to 
get along.

obsessive-compulsive-ly y'rs  - steve
-- 
Steve Holden   +44 150 684 7255  +1 800 494 3119
Holden Web LLC/Ltd  http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden
Recent Ramblings   http://holdenweb.blogspot.com

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Do other Python GUI toolkits require this?

[Antoon Pardon]

On 2007-04-19, Steve Holden <[EMAIL PROTECTED]> wrote:
> Michael Bentley wrote:
>> On Apr 19, 2007, at 4:11 AM, Antoon Pardon wrote:
>> 
>>> On 2007-04-19, Michael Bentley <[EMAIL PROTECTED]> wrote:
> [...]  The
 learning curve is rather steep IMO, but worth it.
>>> Just a throw in remark, that  you may ignore if you wish, but a steep
>>> learning curve means that the subject is easily familiarized and that
>>> the learning period is short.
>>>
>>> You seem to use it as if it is the opposite.
>> 
>> Mathematical absurdities aside, it's the common usage -- but perhaps  
>> you knew that.
>> 
>> 
> Perhaps in Belgium they prefer climbing mountains over walking up and 
> down gentle hills? Or possibly they will simply pick any nit that is 
> carelessly left within range?

If it is just a nit, why don't you ignore my remark as I suggested?

Now suppose I give you a graph that shows you how different people
are making progress. Would you prefer the rather flat curves instead
of the steep curves because the latter gives you the idea of someone
having to conquer huge obstacles or would you choose the steep curve
because they show you someone is getting results fast?

-- 
Antoon Pardon
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Do other Python GUI toolkits require this?

[Steve Holden]

Michael Bentley wrote:
> On Apr 19, 2007, at 4:11 AM, Antoon Pardon wrote:
> 
>> On 2007-04-19, Michael Bentley <[EMAIL PROTECTED]> wrote:
[...]  The
>>> learning curve is rather steep IMO, but worth it.
>> Just a throw in remark, that  you may ignore if you wish, but a steep
>> learning curve means that the subject is easily familiarized and that
>> the learning period is short.
>>
>> You seem to use it as if it is the opposite.
> 
> Mathematical absurdities aside, it's the common usage -- but perhaps  
> you knew that.
> 
> 
Perhaps in Belgium they prefer climbing mountains over walking up and 
down gentle hills? Or possibly they will simply pick any nit that is 
carelessly left within range?

   http://home.earthlink.net/~macrakis/Snail_Stew_Recipe.html

Don't forget the salt, Antoon!

regards
  Steve
-- 
Steve Holden   +44 150 684 7255  +1 800 494 3119
Holden Web LLC/Ltd  http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden
Recent Ramblings   http://holdenweb.blogspot.com

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Do other Python GUI toolkits require this?

[Michael Bentley]

*plonk*
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Do other Python GUI toolkits require this?

[Antoon Pardon]

On 2007-04-19, Michael Bentley <[EMAIL PROTECTED]> wrote:
>
> On Apr 19, 2007, at 4:11 AM, Antoon Pardon wrote:
>
>> On 2007-04-19, Michael Bentley <[EMAIL PROTECTED]> wrote:
>>>
>>> PyObjC is pretty slick (and since Ronald hasn't made any commits in a
>>> while I'm nearly certain it'll show up in the next official
>>> distribution of the devtools). About the time you gave up on PyQt on
>>> the Mac and switched over to Tkinter, I switched to PyObjC.  The
>>> learning curve is rather steep IMO, but worth it.
>>
>> Just a throw in remark, that  you may ignore if you wish, but a steep
>> learning curve means that the subject is easily familiarized and that
>> the learning period is short.
>>
>> You seem to use it as if it is the opposite.
>
> Mathematical absurdities aside, it's the common usage -- but perhaps  
> you knew that.

I don't know how you come to the conclusion that it is a mathematical
absurdity but consider this: If you find that common usage propagates
something that is incorrect, should we just shrug it off or should we
attemp a correction? There is always a chance that one day you find
yourself exposed to a learning curve while going through a document.
If you just depend on common usage you will probably draw the wrong
conclusion.

-- 
Antoon Pardon
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Do other Python GUI toolkits require this?

[Michael Maibaum]

On 18/04/07, Kevin Walzer <[EMAIL PROTECTED]> wrote:


James Stroud wrote:

> This appears more or less unique to Objective C. It looks that with
> PyObjC, you have to interact with the Objective C runtime to manage
> memory. This is not required, thankfully, with any other GUI tookits
> I've seen.
>
> I think the main difference is that PyObjC is not a GUI toolkit per se,
> but is simply a means to make the Objective C runtime (and hence Cocoa)
> available via a python layer.
>
> James

That's kind of what I thought. Memory management? In Python? *shudder*



I'm wondering if this might go away with the arrival of garbage collection
in ObjectiveC?

Michael
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Do other Python GUI toolkits require this?

[Michael Bentley]

On Apr 19, 2007, at 4:11 AM, Antoon Pardon wrote:

> On 2007-04-19, Michael Bentley <[EMAIL PROTECTED]> wrote:
>>
>> On Apr 18, 2007, at 5:11 PM, Kevin Walzer wrote:
>>
>>> James Stroud wrote:
>>>
 This appears more or less unique to Objective C. It looks that with
 PyObjC, you have to interact with the Objective C runtime to manage
 memory. This is not required, thankfully, with any other GUI  
 tookits
 I've seen.

 I think the main difference is that PyObjC is not a GUI toolkit
 per se,
 but is simply a means to make the Objective C runtime (and hence
 Cocoa)
 available via a python layer.

 James
>>>
>>> That's kind of what I thought. Memory management? In Python?  
>>> *shudder*
>>>
>>> I'm a Mac-only developer, and I keep telling myself I should  
>>> drink the
>>> Mac-only Kool-aid of PyObjC. But Tk is burned into my brain, and
>>> anything else looks and feels weird to me. Tk is so flexible that  
>>> it's
>>> fairly easy to tweak it to look Mac-like, and it's simpler to do  
>>> that
>>> than learn a new tookit.
>>
>> PyObjC is pretty slick (and since Ronald hasn't made any commits in a
>> while I'm nearly certain it'll show up in the next official
>> distribution of the devtools). About the time you gave up on PyQt on
>> the Mac and switched over to Tkinter, I switched to PyObjC.  The
>> learning curve is rather steep IMO, but worth it.
>
> Just a throw in remark, that  you may ignore if you wish, but a steep
> learning curve means that the subject is easily familiarized and that
> the learning period is short.
>
> You seem to use it as if it is the opposite.

Mathematical absurdities aside, it's the common usage -- but perhaps  
you knew that.


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Do other Python GUI toolkits require this?

[Antoon Pardon]

On 2007-04-19, Michael Bentley <[EMAIL PROTECTED]> wrote:
>
> On Apr 18, 2007, at 5:11 PM, Kevin Walzer wrote:
>
>> James Stroud wrote:
>>
>>> This appears more or less unique to Objective C. It looks that with
>>> PyObjC, you have to interact with the Objective C runtime to manage
>>> memory. This is not required, thankfully, with any other GUI tookits
>>> I've seen.
>>>
>>> I think the main difference is that PyObjC is not a GUI toolkit  
>>> per se,
>>> but is simply a means to make the Objective C runtime (and hence  
>>> Cocoa)
>>> available via a python layer.
>>>
>>> James
>>
>> That's kind of what I thought. Memory management? In Python? *shudder*
>>
>> I'm a Mac-only developer, and I keep telling myself I should drink the
>> Mac-only Kool-aid of PyObjC. But Tk is burned into my brain, and
>> anything else looks and feels weird to me. Tk is so flexible that it's
>> fairly easy to tweak it to look Mac-like, and it's simpler to do that
>> than learn a new tookit.
>
> PyObjC is pretty slick (and since Ronald hasn't made any commits in a  
> while I'm nearly certain it'll show up in the next official  
> distribution of the devtools). About the time you gave up on PyQt on  
> the Mac and switched over to Tkinter, I switched to PyObjC.  The  
> learning curve is rather steep IMO, but worth it. 

Just a throw in remark, that  you may ignore if you wish, but a steep
learning curve means that the subject is easily familiarized and that
the learning period is short.

You seem to use it as if it is the opposite.

-- 
Antoon Pardon
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Do other Python GUI toolkits require this?

[Michael Bentley]

On Apr 18, 2007, at 5:11 PM, Kevin Walzer wrote:

> James Stroud wrote:
>
>> This appears more or less unique to Objective C. It looks that with
>> PyObjC, you have to interact with the Objective C runtime to manage
>> memory. This is not required, thankfully, with any other GUI tookits
>> I've seen.
>>
>> I think the main difference is that PyObjC is not a GUI toolkit  
>> per se,
>> but is simply a means to make the Objective C runtime (and hence  
>> Cocoa)
>> available via a python layer.
>>
>> James
>
> That's kind of what I thought. Memory management? In Python? *shudder*
>
> I'm a Mac-only developer, and I keep telling myself I should drink the
> Mac-only Kool-aid of PyObjC. But Tk is burned into my brain, and
> anything else looks and feels weird to me. Tk is so flexible that it's
> fairly easy to tweak it to look Mac-like, and it's simpler to do that
> than learn a new tookit.

PyObjC is pretty slick (and since Ronald hasn't made any commits in a  
while I'm nearly certain it'll show up in the next official  
distribution of the devtools). About the time you gave up on PyQt on  
the Mac and switched over to Tkinter, I switched to PyObjC.  The  
learning curve is rather steep IMO, but worth it.  One thing I think  
I should mention though is that if you move to PyObjC -- do some  
projects in Objective C first.  Otherwise your brain will implode.

hth,
Michael

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Do other Python GUI toolkits require this?

[Kevin Walzer]

James Stroud wrote:

> This appears more or less unique to Objective C. It looks that with 
> PyObjC, you have to interact with the Objective C runtime to manage 
> memory. This is not required, thankfully, with any other GUI tookits 
> I've seen.
> 
> I think the main difference is that PyObjC is not a GUI toolkit per se, 
> but is simply a means to make the Objective C runtime (and hence Cocoa) 
> available via a python layer.
> 
> James

That's kind of what I thought. Memory management? In Python? *shudder*

I'm a Mac-only developer, and I keep telling myself I should drink the 
Mac-only Kool-aid of PyObjC. But Tk is burned into my brain, and 
anything else looks and feels weird to me. Tk is so flexible that it's 
fairly easy to tweak it to look Mac-like, and it's simpler to do that 
than learn a new tookit.

-- 
Kevin Walzer
Code by Kevin
http://www.codebykevin.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Do other Python GUI toolkits require this?

[James Stroud]

Kevin Walzer wrote:
>  From the introduction to PyObjC, the Python-Objective-C bridge on Mac 
> OS X:
> 
> "As described in Objective-C for PyObjC users the creation of 
> Objective-C objects is a two-stage process. To initialize objects, first 
> call a class method to allocate the memory (typically alloc), and then 
> call an initializer (typically starts with init). Some classes have 
> class methods which perform this behind the scenes, especially classes 
> that create cached, immutable, or singleton instances."
> 
> An example:
> 
> myObject = NSObject.alloc().init()
> 
> I know Tkinter doesn't require any manual memory allocation of this 
> sort. Does wxPython, PyQt, PyGtk require anything like this when 
> creating objects?
> 

This appears more or less unique to Objective C. It looks that with 
PyObjC, you have to interact with the Objective C runtime to manage 
memory. This is not required, thankfully, with any other GUI tookits 
I've seen.

I think the main difference is that PyObjC is not a GUI toolkit per se, 
but is simply a means to make the Objective C runtime (and hence Cocoa) 
available via a python layer.

James
-- 
http://mail.python.org/mailman/listinfo/python-list

Do other Python GUI toolkits require this?

[Kevin Walzer]

 From the introduction to PyObjC, the Python-Objective-C bridge on Mac OS X:

"As described in Objective-C for PyObjC users the creation of 
Objective-C objects is a two-stage process. To initialize objects, first 
call a class method to allocate the memory (typically alloc), and then 
call an initializer (typically starts with init). Some classes have 
class methods which perform this behind the scenes, especially classes 
that create cached, immutable, or singleton instances."

An example:

myObject = NSObject.alloc().init()

I know Tkinter doesn't require any manual memory allocation of this 
sort. Does wxPython, PyQt, PyGtk require anything like this when 
creating objects?

-- 
Kevin Walzer
Code by Kevin
http://www.codebykevin.com
-- 
http://mail.python.org/mailman/listinfo/python-list