Re: [Pythonmac-SIG] Newbies need IDEs (was Mac User Python Newbie)

[Brendan Simons]

Sorry, I actually meant I tried to bundle the PythonCard Editor, in its 
tools directory.  Your instructions are still helpful though, and I 
might give it another shot

 - Brendan
On 14-Feb-05, at 1:19 AM, Bob Ippolito wrote:
The problem with bundling PythonCard with py2app is that it makes no 
sense!  PythonCard is not an application, it's a framework.  It does 
have a whole bunch of little applications (the tools and samples -- or 
at least the "meta-sample") that deserve py2app-ing.

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

[Pythonmac-SIG] Re: MacPython 2.3.5 for 10.2 Release Candidate available

[Jim Sizelove]

Folks,
a MacPython 2.3.5 release for MacOSX 10.2 (also works on 10.3) is 
available for testing. Please download it from 
 and send feedback 
(preferably to the mailing list) telling me whether it works.

I'm quite convinced this is going to be the final installer, but 
before I publicly announce it I'd like a couple of positive replies. 
Also, the PackMan database for 10.2 isn't as complete as I'd like yet, 
that'll be done in the next few days.
--
Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

Everything works here.  I just upgraded from MacPython 2.3.3 to 
MacPython 2.3.5 on my iMac running OSX 10.2.  Thanks, Jack.

Jim Sizelove
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

[Pythonmac-SIG] Re: Mac Newbie IDE help...

[Andrew Meit]

On Feb 14, 2005, at 6:01 AM, Hartman wrote:
So an environment (in the vernacular, not the Unix sense) is what the 
beginner needs -- an IDE from within which everything you need to do 
can be done, and not dangerously much else. But if the IDE is complete 
enough for this beginner to work in, isn't it likely to be a 
reasonable place for someone to work who knows more, too?
-- YES. Thank you for stating it so well. 
Give me a lever which I can transform into a pencil ;-)

Andrew
-{Choose Life, Create hope, Nurture Love...}-
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Mac User Python Newbies

[has]

Charles Hartman wrote:
So an environment (in the vernacular, not the Unix sense) is what 
the beginner needs -- an IDE from within which everything you need 
to do can be done, and not dangerously much else. But if the IDE is 
complete enough for this beginner to work in, isn't it likely to be 
a reasonable place for someone to work who knows more, too?
I think Joel Spolsky hits on the broader problem when talking about 
bloat vs features 
:

"80% of the people use 20% of the features. Unfortunately, it's never 
the same 20%."

Thus we end up with big, extremely complex programs like MS Word, and 
the first thing new users have to do is to determine all the bits 
that they can simply ignore so they can concentrate on learning the 
bits they actually do need. Uber-geeks may enjoy the feeling of 
absolute control that comes from having more buttons and knobs at 
hand than they can count, but us ordinary schmoes just drown in that 
crap. MS builds software that way cos they like to get their users 
locked into a perpetual upgrade cycle from which they can make money, 
but what's OSS's excuse?

My preferred IDE architecture would be built on a completely 
component-oriented architecture. That way it can ship with the 
minimal components required to get started, and users can add, 
upgrade and remove components as and when they need them. For 
example, a new user needs everything visible so they can see what's 
available; an experience one may prefer everything driven by 
memorised keyboard combinations so they can devote screen estate to 
more important things like their code instead of floating palettes, 
on-screen help, etc.

Furthermore, those users aren't locked into a single fixed solution 
for, say, building GUIs: as long as wxPython, PythonCard, etc. 
provide compatible components they can plug in whichever one they 
want. And it allows individual features to develop at their own rate, 
so you're not stuck with the perpetually 'almost-there-but-not-quite' 
situation that somebody else mentioned.

Python's myriad web frameworks are in exactly the same situation, 
btw: they should be building smaller and simpler for greater 
flexibility and custom assembly, but instead seem only to build 
bigger and more complex with major lock-in and the result is systems 
that only their existing long-time users want to use because the cost 
of mastering one of these monsters has grown so high as to deter 
newcomers. Who then turn to simpler, less powerful systems, master 
those, and then complain about the lack of features until they too 
evolve into the same monolithic giants that they'd rejected in the 
first place.

I've never understood what the obsession with building every 
conceivable feature into the application core, least of all when it's 
coming from unix folks who really should know better. The central 
tenet of Unix design philosophy is to build small, interchangeable, 
single-purpose components that can be easily assembled into whatever 
form the user needs. So I see this as just sensible design, and the 
fact that it happens to scale well to fit lots of different user 
requirements is an added plus. And I despair when I see all these 
other unix-raised OSS folk rushing in the exact opposite direction, 
and am at a loss to understand what they're thinking.

HTH
has
--
"Oh, cut the bleeding heart crap, will ya? We've all got our 
switches, lights, and knobs to deal with, Striker. I mean, down here 
there are literally hundreds and thousands of blinking, beeping, and 
flashing lights, blinking and beeping and flashing - they're 
*flashing* and they're *beeping*. I can't stand it anymore! They're 
*blinking* and *beeping* and *flashing*! Why doesn't somebody pull 
the plug!"
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Mac User Python Newbies

[Louis Pecora]

Troy Rollins wrote:
Well, I've transitioned between tools like Director, REALbasic, and
Revolution, and extremely quickly moved into creating non-trivial
applications. With Python, it is far less condusive to "playing" and
therefore seems to hold me somewhere around the print "hello world"
stage.
Yes, I've look at the cited examples... perhaps they simply didn't
connect with me on the right level. Python stuff always seems to be
written from the perspective of "ok, you are starting from a lower
level language", but many of us are probably coming from the other
direction – a higher level language... Lingo, REALbasic, etc. It would
seem to me that the transition to Python should be easy, but perhaps I
just haven't yet encountered the right materials.
I just received 3 books on Python from Amazon. Every one of them
starts with the line "this book does not teach you to program in
Python, and assumes you already know how to do that." Perhaps it is
just my own dumb luck, but that is the angle most web materials take
as well in my experience. OR, it is print "hello world".
I'm pretty committed to learning this, but I'm somewhat surprised at
how much productivity I have to throw away in order to do it. Many
would say "well, that's free software for you." But, I'm not
interested in the "free" part. Free is not what is important to me.
Frankly, I'd rather pay for something productive. My time is worth WAY
more than whatever a decent tool would cost. The part that interests
me is open source, and "future-proofing." To me, "free" translates to
"loss of productivity." I'm not a hobbyist, and I'm not looking to
Python as something to use "outside of my day job." I make my living
with tools like this, and have a staff that does as well.
Please don't interpret any of my comments as saying anything bad about
list members, contributors, or Python. That isn't the intent at all. I
do realize that these things take time, that Python is free and
open-source, and that only I am responsible for my ability to use it,
and choice to do so.

Likewise my own previous comments were not intended to be criticisms of 
the members or the developers who put so much time and energy into the 
open source that is Python, but I can see how we might be rubbing some 
the wrong way.

I do look at your comments above and mine before as descriptions of what 
a newbie faces when coming aboard. That's just the way it looks from our 
vantage point. I've been using Python for several years, but I still 
feel like a newbie (and probably still am) as there is a myriad of 
packages that I have no clue about (although I see the names flash by 
online or my emails). I still feel that my code is fragile and hard to 
maintain. For example system upgrades to OS X killed off some plotting 
software I had learned to use. It appears that it is up to me to fix 
that. I've been looking around, but like Troy I am trying to use Python 
in my job, but I don't have time to become a guru nor the desire. So 
where does that leave me or, rather, us?

As someone else said in this thread, this is a good issue for the Python 
community to consider since it will affect who will be included in your 
world in the future and what that future will look like.

--
Cheers,
Lou Pecora
Code 6362
Naval Research Lab
Washington, DC 20375
P.S. I have not yet had time to try out Chris Barker's packaging of 
matplotlib. I hope to do that later this month, but BIG KUDOS to him for 
trying to make the code available to more people.

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Mac User Python Newbies

[Bob Ippolito]

On Feb 14, 2005, at 12:09 PM, has wrote:
Charles Hartman wrote:
So an environment (in the vernacular, not the Unix sense) is what the 
beginner needs -- an IDE from within which everything you need to do 
can be done, and not dangerously much else. But if the IDE is 
complete enough for this beginner to work in, isn't it likely to be a 
reasonable place for someone to work who knows more, too?
I think Joel Spolsky hits on the broader problem when talking about 
bloat vs features 
:

"80% of the people use 20% of the features. Unfortunately, it's never 
the same 20%."

Thus we end up with big, extremely complex programs like MS Word, and 
the first thing new users have to do is to determine all the bits that 
they can simply ignore so they can concentrate on learning the bits 
they actually do need. Uber-geeks may enjoy the feeling of absolute 
control that comes from having more buttons and knobs at hand than 
they can count, but us ordinary schmoes just drown in that crap. MS 
builds software that way cos they like to get their users locked into 
a perpetual upgrade cycle from which they can make money, but what's 
OSS's excuse?
Maybe because in many cases, the users are the developers and adding 
those 20%s together makes for some big ugly mess.

My preferred IDE architecture would be built on a completely 
component-oriented architecture. That way it can ship with the minimal 
components required to get started, and users can add, upgrade and 
remove components as and when they need them. For example, a new user 
needs everything visible so they can see what's available; an 
experience one may prefer everything driven by memorised keyboard 
combinations so they can devote screen estate to more important things 
like their code instead of floating palettes, on-screen help, etc.
I think Eclipse is intended to be like this -- though I can't say I 
have real experience using it.

Furthermore, those users aren't locked into a single fixed solution 
for, say, building GUIs: as long as wxPython, PythonCard, etc. provide 
compatible components they can plug in whichever one they want. And it 
allows individual features to develop at their own rate, so you're not 
stuck with the perpetually 'almost-there-but-not-quite' situation that 
somebody else mentioned.
Personally, I hope that developers See The Light and do interface 
building in a separate but integrated application like Xcode and 
Interface Builder.  If for no other reason than it's simply not 
possible to integrate a Tkinter GUI builder inside of a wxPython IDE or 
vice versa.  Without this separation, all of the features of the IDE 
*are* locked into a particular event loop.

Python's myriad web frameworks are in exactly the same situation, btw: 
they should be building smaller and simpler for greater flexibility 
and custom assembly, but instead seem only to build bigger and more 
complex with major lock-in and the result is systems that only their 
existing long-time users want to use because the cost of mastering one 
of these monsters has grown so high as to deter newcomers. Who then 
turn to simpler, less powerful systems, master those, and then 
complain about the lack of features until they too evolve into the 
same monolithic giants that they'd rejected in the first place.
I think WSGI (pep 333) is a good step to fixing this problem.  If you 
target WSGI, at least you can shoehorn your app into a giant framework 
when you need one.

I've never understood what the obsession with building every 
conceivable feature into the application core, least of all when it's 
coming from unix folks who really should know better. The central 
tenet of Unix design philosophy is to build small, interchangeable, 
single-purpose components that can be easily assembled into whatever 
form the user needs. So I see this as just sensible design, and the 
fact that it happens to scale well to fit lots of different user 
requirements is an added plus. And I despair when I see all these 
other unix-raised OSS folk rushing in the exact opposite direction, 
and am at a loss to understand what they're thinking.
I think this is largely caused by complexity of the alternative and the 
convenience of doing it in this way.

The problem with the Unix model is that processes only know how to 
exchange raw data (sockets, pipes, files).  In lots of cases you want 
to exchange a higher level representation of information, and there 
aren't a whole lot of easy ways to do that.  I'm pretty sure that these 
large frameworks suffer from the same problem.  It's much easier to 
exchange high level representations of data with yourself than it is to 
exchange them with someone else..  that, and it's much easier to design 
something ad-hoc if you don't concern yourself with keeping things 
modular.

The design of py2app definitely exhibits the "large core" issue as part 
of its development cycle.  In order to add a particular fea

Re: [Pythonmac-SIG] Mac User Python Newbies

[Louis Pecora]

Michael Hudson wrote:
Well, I think this is a subjective judgement -- a matter of
familiarity.  I "play" with Python all the time.  A good start is to
enhance your interactive experience somewhat.  Three options spring to
mind:
1) Get readline support working.  If you're still using Apple's
   Python, get bbum's readline.so from
   http://homepage.mac.com/bbum/BumFiles/FileSharing27.html
   (is this still the right link?), then add lines like
   try:
   import rlcompleter, readline
   readline.parse_and_bind("tab: complete")
   except ImportError:
   pass
   to a file called something link ~/.pythonrc and point the
   PYTHONSTARTUP environment variable to it (yikes, this is a bit
   involved...).  Then if you want to see what functions a module
   supports you can do:
   >>> import urllib2
   >>> urllib2.url
   urllib2.url2pathname  urllib2.urlopen   urllib2.urlparse
   and so on:
  >>> data = urllib2.urlopen('http://www.google.com').read()
   >>> data[:10]
   '
2) Install IPython (http://ipython.scipy.org/).  This is a massive
   extension of the above and requires you have readline working.
   I've not used it much, but people like it.  I imagine it has docs
   :)
3) Install (my) PyRepl package (http://codespeak.net/pyrpl/), which
   is a different implementation of the same kind of thing.
There are less terminal oriented interactive environments too -- I
think wxPython includes one and PyObjC has a 'PyInterpreter' example.
But to me they don't hold much advantage over the in-Terminal.app
solutions.
Well, I can just see Troy sitting at his computer reading the above and 
saying, "I rest my case."  :-)

You did somewhat admit that in (1) above and in the remainder of your 
message so you are honest about the state of affairs.  And I thank you 
for all the information.  Now, where to start?  Where to start?

--
Cheers,
Lou Pecora
Code 6362
Naval Research Lab
Washington, DC  20375
USA
Ph:  +202-767-6002
email:  [EMAIL PROTECTED]
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Mac User Python Newbies

[Chris Barker]

Brendan Simons wrote:
 TextWrangler, however,  has good Python support, including cmd-r
to run the present script.   They've even written a parser for 
traceback, so when I get a runtime error, TW drops me right where I made 
the mistake.  Handy.
But does it do Python indenting correctly? This is my only really 
obstacle with BBedit (a couple versions old). You can make it put in 
spaces instead of tabs, but once they're in they are treated only as 
spaces, rather than levels of indentation, so when you want to remove a 
level you have to hit delete four times. Not horrible, but annoying.

By they way, does anyone know what the heck is up with Pepper? It looked 
so promising, particularly for those of that want to use the same editor 
on all three major platforms.

-Chris


--
Christopher Barker, Ph.D.
Oceanographer

NOAA/OR&R/HAZMAT (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception
[EMAIL PROTECTED]
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Mac User Python Newbies

[Louis Pecora]

Bob Ippolito wrote:
Well, either the current state if Python tools is good enough or it 
isn't.  Perhaps the threat of a new user not sticking with Python is 
suitable motivation for some developers, but obviously not all of 
them, because then Python would do everything for everyone already :)

Python has been getting better tools and easier to pick up over the 
years.  How could this possibly put it in "danger of ceding the next 
generation"?  So what if the Director or Revolution equivalent doesn't 
spring from the ashes tomorrow?  When it does, it will be great, but 
there's years worth of programmer years that go into such a product.  
I'm not aware of such an effort, so it's probably not going to happen 
very soon.

Python does already ship with an IDE, IDLE, which is probably pretty 
new user friendly and it does have the one feature that most of the 
other IDEs don't have.  It runs sub-interpreters out of process by 
default, so running GUI applications works.

-bob 
You know a thought just hit me upon reading this and other emails about 
the Python environment.  I have a friend who has a Russian wife.  They 
went to buy a rug at Home Depot.  Lots of variety, thick pile, thin 
pile, patterns and weaves, colors, etc. etc. etc.   The whole situation 
which at first sounds wonderful was totally upsetting to  her.  "Too 
many choices!" she screamed and left the store.   Well, in Russia you 
had the choice of colors as long as it was grey or brown.   I'm not 
suggesting that the Python community should go to that extreme  :-) , 
but for newbies and even old-newbies like me, "Too many choices!"

--
Cheers,
Lou Pecora
Code 6362
Naval Research Lab
Washington, DC  20375
USA
Ph:  +202-767-6002
email:  [EMAIL PROTECTED]
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

[Pythonmac-SIG] Re: another point..porting...

[Andrew Meit]

On Feb 14, 2005, at 12:37 PM, [EMAIL PROTECTED] wrote:
Well, I can just see Troy sitting at his computer reading the above 
and saying, "I rest my case."  :-)
-- and for me too... :-(
Here is another bone to chew on: porting stuff to Python...I don't find 
anything to help make the transition of a Gui/data from let say 
Revolution/RB or anything else to Python...
Having to start from scratch does not appeal to a newbie ;-)

andrew
-{Choose Life, Create hope, Nurture Love...}-
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Mac User Python Newbies

[Louis Pecora]

Robert Kern wrote:
It's called "Enthon." There will be a new release (for Windows and 
Linux) with more stuff, like matplotlib, Soon(TM).

http://www.enthought.com/downloads/downloads.htm
There will be a Mac release A Little Later Than Soon(TM).
http://www.scipy.org/wikis/featurerequests/MacEnthon

Yeow!  Right on the money!  Just checked it out, it says:
Goal
To make a unifying distribution of Python packages useful to scientific 
developers on the Mac OS X platform in the way that the Enthought 
Edition of Python ("Enthon") does for Windows and (soon) Linux.

This is something I'd pay for.   I'll be following that development.  
Best of luck and may the Python force be with you.

--
Cheers,
Lou Pecora
Code 6362
Naval Research Lab
Washington, DC  20375
USA
Ph:  +202-767-6002
email:  [EMAIL PROTECTED]
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Re: another point..porting...

[Bob Ippolito]

On Feb 14, 2005, at 12:49 PM, Andrew Meit wrote:
On Feb 14, 2005, at 12:37 PM, [EMAIL PROTECTED] wrote:
Well, I can just see Troy sitting at his computer reading the above 
and saying, "I rest my case."  :-)
-- and for me too... :-(
Here is another bone to chew on: porting stuff to Python...I don't 
find anything to help make the transition of a Gui/data from let say 
Revolution/RB or anything else to Python...
Having to start from scratch does not appeal to a newbie ;-)
And having to reverse engineer proprietary formats doesn't normally 
appeal to an open source developer ;)

-bob
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Mac User Python Newbies

[Chris Barker]

Roger Binns wrote:
My wxPython code is hand coded.  I haven't found any of the design
tools to be much good for non-trivial projects.  For example try
doing something like the wxPython demo with one of them.  They
also don't work well if you have custom widgets, which is a lot of my UI.
This brings up a really good point about GUI GUI Builders: They tend to 
discourage the use of custom widgets, which is a really a bad thing. 
That's why I don't use them. Maybe someone will developer one that works 
really well with custom widgets some day... I'm guessing that would be a 
tool specifically developed for, and written in, python. That way you 
could easily add your custom widget to the "pallet" of available 
widgets, and it could be a first class citizen.

-Chris

--
Christopher Barker, Ph.D.
Oceanographer

NOAA/OR&R/HAZMAT (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception
[EMAIL PROTECTED]
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Mac User Python Newbies

[Bob Ippolito]

On Feb 14, 2005, at 1:02 PM, Chris Barker wrote:
Roger Binns wrote:
My wxPython code is hand coded.  I haven't found any of the design
tools to be much good for non-trivial projects.  For example try
doing something like the wxPython demo with one of them.  They
also don't work well if you have custom widgets, which is a lot of my 
UI.
This brings up a really good point about GUI GUI Builders: They tend 
to discourage the use of custom widgets, which is a really a bad 
thing. That's why I don't use them. Maybe someone will developer one 
that works really well with custom widgets some day... I'm guessing 
that would be a tool specifically developed for, and written in, 
python. That way you could easily add your custom widget to the 
"pallet" of available widgets, and it could be a first class citizen.
Cocoa and Interface Builder get this right.  In IB, there's a "Custom 
Class" tab in the info window when you're inspecting an instance of 
something, and you can choose any subclass.  If you want to expose 
additional configuration features or a nice display for this widget, 
you can implement that in an Interface Builder palette.

Of course, this is only really useful for Mac OS X specific 
development, but I would definitely recommend that developers of tools 
for other frameworks look to Cocoa for inspiration.  It's extremely 
mature and flexible.

-bob
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Re: Mac newbie

[Wolfgang Keller]

> 3a Command R can wait for  the third tier because I have a trick:  I 
> run a script  "onchange.py python somefile.py" which runs somefile.py 
> whenever I save the file.  But a newbie wouldn't know how to create 
> this script.

Stakeout?

Best regards

Wolfgang Keller

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Re: Mac newbie

[Bob Ippolito]

On Feb 14, 2005, at 1:46 PM, Wolfgang Keller wrote:
3a Command R can wait for  the third tier because I have a trick:  I
run a script  "onchange.py python somefile.py" which runs somefile.py
whenever I save the file.  But a newbie wouldn't know how to create
this script.
Stakeout?
For reference:
http://michael-mccracken.net/blog/blosxom.pl/computers/mac/programming/ 
meetWatch.html

-bob
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Mac User Python Newbies

[Chris Barker]

Louis Pecora wrote:
> P.S. I have not yet had time to try out Chris Barker's packaging of
> matplotlib. I hope to do that later this month, but BIG KUDOS to him
> for trying to make the code available to more people.
Gee thanks! As it turns out, Robert Kern is working on MacEnthon, which 
will supersede anything I've done, and hopefully will be out soon.

In the meantime, you can get my package from Bob's web site:
http://undefined.org/python/packages.html
-Chris
--
Christopher Barker, Ph.D.
Oceanographer

NOAA/OR&R/HAZMAT (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception
[EMAIL PROTECTED]
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Re: Mac Python User Newbies

[Chris Barker]

thor wrote:
Well, that is a good point. I suppose everyone will have a differing
opinion on that, particularly in terms of goals. For me, I'd like to
see a single package, which includes a GUI designer, script editor
with colorizing, debugger, interactive console, some sort of module
browser for functions and syntax, resource viewer, something similar
to package manager... and a basic set of modules for x-plat
development work. Then, some tool which helps to output the whole
thing as a runtime package.
 
I wholly agree that this would be a utopian environment!
I actually don't think this would be utopia for me, which is think is 
quite relevant because it's people like me that develop these things. 
It's not that I wouldn't like things nicely integrated, it's that I want 
a choice of tools. In the above imagined environment, you've just 
selected the following:

Editor
GUI toolkit
console
packaging tool
Many of us like to mix and match these. the editor and GUI toolkit being 
the biggest ones. While a really nice Python friendly editor would be 
great, it wouldn't be great for me unless it was also a really nice 
editor for all the other text I need to edit. That's why I use Xemacs. I 
don't' even like it much, but I like that it has a powerful mode 
available for EVERYTHING I ever need to edit.

Same for GUI toolkit, Whatever toolkit this fabulous IDE uses, there are 
going to be a lot of us that want a different one. Also, I've never seen 
a GUI builder that was as productive for me as writing the code by hand 
(at least if I have something like wxPython's sizers to do layout for me)

I think that's why the editor+terminal+GUI-toolkit-of-choice has ended 
up being the de-facto environment for Python development

One more note: I've found that there is a big difference between
"Productivity Usability": how productive one is with a give tool over 
the long term
and
"Learn to Usability": how easy it is to learn, and get something done 
quickly.

The former is what really matters for a tool you use a lot. The later is 
what really matters when you trying to sell something new. While the two 
types of usability are not mutually exclusive, I think they are 
orthogonal. That is you can have any amount of either couples with any 
amount of the other. Obviously lots of both is the ideal. However, I've 
found that commercial products often have lots of Learn-to-Usability, 
because you need that to sell a product, while open source products tend 
to have a lot of Productivity-Usability, because the people developing 
them need that, and don't need to learn it.

One example I've seen a lot in the open source world is people writing 
to a mailing list, looking for a good tutorial. If it doesn't exist, 
many folks offer to write one as they learn, so that others will have it 
in the future. This is the true spirit of open source. However, most of 
them only get half-finished, because by the time the would-be author has 
learned enough to finish it, they don't' need it any more, and the 
motivation is gone.

> No way of
drawing
2D in python and use wxPython.
While you can't currently use PyGame, there are plenty of ways of 
drawing on a 2-d canvas. Also, I know there are some folks that have 
looked at integrating PyGame and wxPython. I don't know how far they 
got, but it's certainly possible.

Solutions:
- Do 2D stuff in OpenGL (quite awkward) as pyOpenGL works with wxPython
- Don't use wxPython but native libraries on each of the 3 platforms I 
want to write for.

For this reason I am now using Java and I draw on a Canvas
What kind of Canvas do you use with Java? I've seen people looking for a 
Java2d like Canvas for wxPython, is that what you're using? I've written 
the FloatCanvas class for wxPython, which provides much (but certainly 
not all) the functionality you might be looking for. At the moment, it 
is very vector graphics oriented, but adding bitmap graphics would be 
pretty trivial, depending on your needs.

A workable
environment for what I wanted to do without luck.
I'm curious what you mean by "environment" in this case. Environment: as 
in IDE, or Environment as it collection of libraries like GUI toolkit, 
fast bitmap graphics, etc?

-Chris
--
Christopher Barker, Ph.D.
Oceanographer

NOAA/OR&R/HAZMAT (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception
[EMAIL PROTECTED]
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Re: Mac newbie

[Chris Barker]

Bob Ippolito wrote:
4.  AnyGui seemed like a really good idea to me.

Lots of good ideas never get the attention and effort they deserve.
Except that AnyGui was never a good idea. A wrapper around a wrapper 
around a wrapper around a . just too much! As far as I can tell, 
there are two good ideas:

1) a toolkit written from scratch that draws it's own stuff on all 
platforms. To get performance, much of needs to be written in a lower 
level language: al la QT, GTK, Fox, etc

2) a toolkit that wraps the native widgets on all platforms, also needs 
to be written largely in a lower level language: al la wxWidgets.

What would be nicer than any of the existing alternatives is one written 
specifically for Python. The problem with that is that it has a smaller 
audience, so may never get done. PyGui has promise, but has a long way 
to go.

http://nz.cosc.canterbury.ac.nz/~greg/python_gui/
> For IDEs written in Python, in-process interpreters and
debuggers can cause the IDE to crash, halt, or behave strangely.  
Unfortunately this is common practice.
Very good point. This locks you into using the same GUI toolkit that the 
IDE uses, severely limiting the market.

-Chris
--
Christopher Barker, Ph.D.
Oceanographer

NOAA/OR&R/HAZMAT (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception
[EMAIL PROTECTED]
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Mac User Python Newbies

[has]

Bob Ippolito wrote:
 > MS builds software that way cos they like to get their users locked into
 > a perpetual upgrade cycle from which they can make money, but what's
 > OSS's excuse?
Maybe because in many cases, the users are the developers and adding
those 20%s together makes for some big ugly mess.
I'm not sure that qualifies as an excuse; more making their bed and 
lying in it. :)


 > Furthermore, those users aren't locked into a single fixed solution
 > for, say, building GUIs: as long as wxPython, PythonCard, etc. provide
 > compatible components they can plug in whichever one they want.
Personally, I hope that developers See The Light and do interface
building in a separate but integrated application like Xcode and
Interface Builder.
Exactly. Or separate, integrateable components that plug into a 
common base framework. That was the idea behind OpenDoc, for example: 
the user's work is more important than the tools, so make it the 
center of attention by using a document-oriented model instead of an 
application-oriented one. Either way though the technical goal is 
exactly the same: keep the coupling between components as loose as 
possible. That's the _key_ to getting the design right: decoupling 
each functional area from the others. The rest is just finding the 
slickest, most convenient presentation. Unfortunately, I think most 
folk are only thinking about the presentation when they 'design' 
their system, and so they miss this. They get the form looking almost 
right superficially, but they don't get the substance. And then they 
wonder why they can't get the form any better, and why it starts 
falling apart when they try to take it any further.


 > Python's myriad web frameworks are in exactly the same situation, btw
I think WSGI (pep 333) is a good step to fixing this problem.  If you
target WSGI, at least you can shoehorn your app into a giant framework
when you need one.
If I understand it correctly, WSGI decouples the app framework from 
the web server, which is a good thing in itself. It doesn't do 
anything to address the pathological kitchen sink-ism within the rest 
of the web-app framework, however. I think you'd need a chainsaw for 
that.


 > I've never understood what the obsession with building every
 > conceivable feature into the application core,
I think this is largely caused by complexity of the alternative and the
convenience of doing it in this way.
Developer convenience up to a point, yes. It requires less up-front 
planning and major direction changes: just jump in and write some 
code. Yet the same could be said for procedural vs OO construction, 
so why are developers seeing the advantages of modular design in the 
small but still missing it so often in the large?


The problem with the Unix model is that processes only know how to
exchange raw data (sockets, pipes, files).  In lots of cases you want
to exchange a higher level representation of information, and there
aren't a whole lot of easy ways to do that.
But there are ways. OpenDoc was built upon Apple events, for example. 
And assuming you only have Python talking to Python then you don't 
even need something that complex. It's not like there isn't prior art 
to study and take ideas from.


I'm pretty sure that these
large frameworks suffer from the same problem.  It's much easier to
exchange high level representations of data with yourself than it is to
exchange them with someone else..
It's interesting that even MS are now moving away from the DCOM 
approach and towards an Apple event/Apple Event Object Model 
approach. I think Apple were definitely onto something with these: 
it's all about where you make the split, and finding the right point 
makes the difference between moving Mohammed or moving the mountain.


that, and it's much easier to design
something ad-hoc if you don't concern yourself with keeping things
modular.
Of course. I often start out that way myself; it's hard to know what 
kind of high-level structure you're going to need if it's your first 
time exploring this particular problem. The trouble sets in when an 
initially ad-hoc design doesn't bother to improve its internal 
organisation as it grows; if you don't keep that burgeoning 
complexity under control then sooner or later the whole thing 
degenerates into a big ball of mud. It's a great very-short-term 
strategy, but an ultimately counter-productive stinker if you're 
planning to be in for the long haul and fail to replace it ASAP.

And it seems that very often programmers never do get around to that 
'rebuild and replace' stage, because as soon as they've reached 
working code it's considered 'done', and to then throw that code away 
and start all over again is anathema. Coming from a fine art 
background, I _know_ that if you've a day to draw a life picture, 
then the best way to spend that time is 'wasting' the first half on 
throwaway sketches and only sitting down to the final version in the 
final few remaining hours, not s

Re: [Pythonmac-SIG] Re: Mac newbie

[Bob Ippolito]

On Feb 14, 2005, at 2:05 PM, Chris Barker wrote:
Bob Ippolito wrote:
4.  AnyGui seemed like a really good idea to me.
Lots of good ideas never get the attention and effort they deserve.
Except that AnyGui was never a good idea. A wrapper around a wrapper 
around a wrapper around a . just too much! As far as I can tell, 
there are two good ideas:

1) a toolkit written from scratch that draws it's own stuff on all 
platforms. To get performance, much of needs to be written in a lower 
level language: al la QT, GTK, Fox, etc

2) a toolkit that wraps the native widgets on all platforms, also 
needs to be written largely in a lower level language: al la 
wxWidgets.

What would be nicer than any of the existing alternatives is one 
written specifically for Python. The problem with that is that it has 
a smaller audience, so may never get done. PyGui has promise, but has 
a long way to go.

http://nz.cosc.canterbury.ac.nz/~greg/python_gui/
While I agree with the assertion that a large part needs to be written 
in a lower level language, I don't agree that wrapping a wrapper is 
going to be a performance problem.  All the tight loops are already in 
the lower level and anything on top of that is going to be 
insignificant unless it's done horribly wrong.  Especially when using 
native widgets.

Ideally I'd propose a design like this:
1. Low level C/ObjC/C++ implementation (probably the native platform's 
toolkit, but could be wxWidgets, Qt, etc.)
2. Thin Python FFI layer (i.e. ctypes or PyObjC -- ultimate 
flexibility, minimal non-Python code)
2.5. Mid-level Python layer if necessary for a sane implementation of 
the high-level (might be overkill for PyObjC given how similar 
Objective-C and Python are)
3. High level Python layer (exposes a nice interface for Python 
developers)

The benefit of an approach such as ctypes or PyObjC is that there's 
essentially nothing you can't do from Python.  The price you pay is 
that the interpreter can crash if you do the wrong thing (this happens 
in platform code, anyway), and due to the nature of FFI such things can 
be confusing to track down from the platform debugger if you don't know 
what you're looking for.  Appropriate safeguards would be installed in 
the high level layer, rather than in C/C++ code.

Wrappers generated with tools such as SWIG, sip, bgen, and Boost Python 
could also fit in for layer 2 -- but I think that a runtime solution is 
going to be better in the long run.

> For IDEs written in Python, in-process interpreters and
debuggers can cause the IDE to crash, halt, or behave strangely.  
Unfortunately this is common practice.
Very good point. This locks you into using the same GUI toolkit that 
the IDE uses, severely limiting the market.
Not only does it lock you into a GUI toolkit, but the crashes, halting, 
and strange behavior is definitely a very big problem.  On Mac OS X 
especially, where each process can have exactly one or zero menus.

-bob
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Re: Mac Python User Newbies

[Kevin Ollivier]

Hi Chris,
I promised myself I'd stay out of this discussion, but I think you hit 
on a good point and wanted to expand on it.

On Feb 14, 2005, at 11:02 AM, Chris Barker wrote:
[snip]
Same for GUI toolkit, Whatever toolkit this fabulous IDE uses, there 
are going to be a lot of us that want a different one. Also, I've 
never seen a GUI builder that was as productive for me as writing the 
code by hand (at least if I have something like wxPython's sizers to 
do layout for me)

I think that's why the editor+terminal+GUI-toolkit-of-choice has ended 
up being the de-facto environment for Python development
Ah, but in the world of Interface Builder, or VB, or RealBasic, people 
mostly use what's given to them. How would you explain those trends 
then? I think your choice was made predicated on the available tools, 
not because there isn't any one tool that would/could meet your needs. 
(It just doesn't exist yet. ;-)

The point being that in Python, AFAICT, 
editor+terminal+GUI-toolkit-of-choice is the only environment available 
for most, thus it is the de-facto standard. But you make a very good 
point below which ties into this...

One more note: I've found that there is a big difference between
"Productivity Usability": how productive one is with a give tool over 
the long term
and
"Learn to Usability": how easy it is to learn, and get something done 
quickly.

The former is what really matters for a tool you use a lot. The later 
is what really matters when you trying to sell something new. While 
the two types of usability are not mutually exclusive, I think they 
are orthogonal. That is you can have any amount of either couples with 
any amount of the other. Obviously lots of both is the ideal. However, 
I've found that commercial products often have lots of 
Learn-to-Usability, because you need that to sell a product, while 
open source products tend to have a lot of Productivity-Usability, 
because the people developing them need that, and don't need to learn 
it.
Bingo! :-) This is a very good point which many people overlook, and 
which leads to many, many confused usability discussions, because one 
group is arguing the need for Learn-To Usability and the other is 
arguing the need for Productivity Usability. (As is mostly the case in 
this thread, too.) But I would argue both are needed, because you do 
want to actually "sell" Python to people. (At least I do!) I think of 
it like riding a bike. When you *start* riding a bike, "Learn to 
Usability" is key, so you have training wheels. The wheels basically 
just show you that, hey, this isn't impossible. Now, eventually you get 
good at riding a bike and training wheels are a hinderance, so you take 
them off, because "Productivity-Usability" becomes key to you.

Now, I don't think it's a perfect analogy because I think software can 
be easy to use without being crippling, as training wheels are. I think 
software can tackle Learn-To-Usability through a combination of 
intelligent defaults (i.e. you have choices, but it makes the most 
likely choice for you at first by default) and excellent ease-of-use, 
including usable interfaces, documentation and training resources. It 
will never be for everyone (maximizing efficiency usually means 
choosing a tool for exactly that) but I think there can be one tool 
that meets the needs of most people.

One example I've seen a lot in the open source world is people writing 
to a mailing list, looking for a good tutorial. If it doesn't exist, 
many folks offer to write one as they learn, so that others will have 
it in the future. This is the true spirit of open source. However, 
most of them only get half-finished, because by the time the would-be 
author has learned enough to finish it, they don't' need it any more, 
and the motivation is gone.
Right, because there's no real reward to speak of, aside from maybe a 
thank you. So the question is: how do you encourage people to actively 
participate in the community, especially in the sense of a major 
project like an IDE?

And here, despite the many, many messages in this thread, is where IMHO 
this discussion gets stuck - because we don't have the answer to that. 
Is the PSF going to offer some incentive for a polished, 
well-documented, cross-platform, "Learn-To Usable" RAD tool that 
incorporates GUI design? If so, I think someone will step up and make 
this happen. (Heck, I'd be happy to work on such a tool, in fact, I've 
already got some ideas for it.) If not, we're just adding more choice 
to the equation (which isn't good for Learn-To) and we're just going 
back and forth about which is more important, Learn-To-Usability or 
Productivity-Usability, which is one of those Coke or Pepsi 
discussions. ;-)

In any case, to me the key issue is that there are tools out there for 
the advanced developers, but the people who need the tools most but 
don't have them are the Learn-To folks.

Thanks,
Kevin
___
Pythonmac-

Re: [Pythonmac-SIG] Mac User Python Newbies

[Bob Ippolito]

On Feb 14, 2005, at 2:29 PM, has wrote:
Bob Ippolito wrote:
 > MS builds software that way cos they like to get their users 
locked into
 > a perpetual upgrade cycle from which they can make money, but 
what's
 > OSS's excuse?

Maybe because in many cases, the users are the developers and adding
those 20%s together makes for some big ugly mess.
I'm not sure that qualifies as an excuse; more making their bed and 
lying in it. :)
Well the people writing these things obviously write it such that it 
suits them, so perhaps they find this bed to be comfortable?

 > Furthermore, those users aren't locked into a single fixed solution
 > for, say, building GUIs: as long as wxPython, PythonCard, etc. 
provide
 > compatible components they can plug in whichever one they want.

Personally, I hope that developers See The Light and do interface
building in a separate but integrated application like Xcode and
Interface Builder.
Exactly. Or separate, integrateable components that plug into a common 
base framework. That was the idea behind OpenDoc, for example: the 
user's work is more important than the tools, so make it the center of 
attention by using a document-oriented model instead of an 
application-oriented one. Either way though the technical goal is 
exactly the same: keep the coupling between components as loose as 
possible. That's the _key_ to getting the design right: decoupling 
each functional area from the others. The rest is just finding the 
slickest, most convenient presentation. Unfortunately, I think most 
folk are only thinking about the presentation when they 'design' their 
system, and so they miss this. They get the form looking almost right 
superficially, but they don't get the substance. And then they wonder 
why they can't get the form any better, and why it starts falling 
apart when they try to take it any further.
Well, separate processes is necessary.. a component based model can't 
work, because certain components just can't live in the same process 
with one another.

 > I've never understood what the obsession with building every
 > conceivable feature into the application core,
I think this is largely caused by complexity of the alternative and 
the
convenience of doing it in this way.
Developer convenience up to a point, yes. It requires less up-front 
planning and major direction changes: just jump in and write some 
code. Yet the same could be said for procedural vs OO construction, so 
why are developers seeing the advantages of modular design in the 
small but still missing it so often in the large?
I think in a lot of cases this may be somewhat incorrect.  A lot of 
times you have a really modular framework, but it's not easy to rip 
apart into its constituent components and install just what you want 
(Twisted 1.x is an example of this).  So what?  Although Twisted 2.x is 
moving away from this model, it's to accommodate a more flexible 
release schedule, not to split it up for the sake of splitting it up.  
In some cases, such as your own appscript/aem/etc., this kind of 
external componentization is more of a hassle than anything else.  
You're releasing them on basically the same schedule, but you make the 
user worry about dealing with them separately.  I decided to go the 
other way with py2app.  It has four distinct components, but it makes 
little sense to distribute them separately, so I don't.  
altgraph/modulegraph will eventually be available separately for the 
sake of other platforms, but macholib, py2app, and bdist_mpkg will 
forever be distributed in a single unit (unless of course some of it 
ends up in the standard library -- which hopefully at least 
altgraph/modulegraph will someday).

The problem with the Unix model is that processes only know how to
exchange raw data (sockets, pipes, files).  In lots of cases you want
to exchange a higher level representation of information, and there
aren't a whole lot of easy ways to do that.
But there are ways. OpenDoc was built upon Apple events, for example. 
And assuming you only have Python talking to Python then you don't 
even need something that complex. It's not like there isn't prior art 
to study and take ideas from.
I've never seen it done in Python really easily.  It's like programming 
with threads, people think it's easy, but then a piano falls on their 
head a couple hundred lines of code later cause they didn't truly 
understand what they were getting into.  There is certainly no standard 
library support for such a feature, other than marshal and pickle, but 
those are only formats for data exchange, they do nothing to help you 
exchange the data.

I'm pretty sure that these
large frameworks suffer from the same problem.  It's much easier to
exchange high level representations of data with yourself than it is 
to
exchange them with someone else..
It's interesting that even MS are now moving away from the DCOM 
approach and towards an Apple event/Apple Event Object Model approach. 
I think Apple were de

Re: [Pythonmac-SIG] Re: Mac newbie

[Chris Barker]

Bob Ippolito wrote:
On Feb 14, 2005, at 2:05 PM, Chris Barker wrote:
Except that AnyGui was never a good idea. A wrapper around a wrapper 
around a wrapper around a . just too much!

While I agree with the assertion that a large part needs to be written 
in a lower level language, I don't agree that wrapping a wrapper is 
going to be a performance problem.
It's not so much performance as complexity and the 
lowest-common-denominator problem. I"m pretty sure AnyGui is dead now 
anyway, and I've written a couple longer rants about this, but consider 
this:

AnyGuiTK is a Python wrapper around a Python wrapper around another 
scripting language, around and extension written in C, which is wrapped 
about the X11 API, which is emulated on other platforms.

AnyGuiWx is a Python wrapper around a SWIG wrapper around a C++ toolkit 
that is a wrapper around a native GUI toolkit.

When there's a bug, you've got a lot of layers that may be responsible!
It comes down to why? AnyGui has a flawed reason for being. NO one 
should care what toolkit is underlying their app at the bottom. What 
they should care about is;

The API
The Look and Feel
The Features
The Platform support
AnyGUI had some potential to improve the API of the underlying toolkits 
but that's it. It makes much more sense to just write a better API 
wrapper around a toolkit that meets your other needs.

Ideally I'd propose a design like this:
1. Low level C/ObjC/C++ implementation (probably the native platform's 
toolkit, but could be wxWidgets, Qt, etc.)
wouldn't it have to be it it were X-platform?
2. Thin Python FFI layer (i.e. ctypes or PyObjC -- ultimate flexibility, 
minimal non-Python code)
What's FFI ?
2.5. Mid-level Python layer if necessary for a sane implementation of 
the high-level (might be overkill for PyObjC given how similar 
Objective-C and Python are)
Good point. The better the API you're wrapping, the less need for this.
3. High level Python layer (exposes a nice interface for Python developers)
This sounds a lot like PythonCard, actually.
1) wxWidgets
2) SWIG--wxPython
2.5) Some of the stuff wxPython adds: better dynamic binding syntax, 
OGL, FloatCanvas, other high level widgets.
3) That's what PythonCard itself is.

Wrappers generated with tools such as SWIG, sip, bgen, and Boost Python 
could also fit in for layer 2 -- but I think that a runtime solution is 
going to be better in the long run.
hmm. Is it possible to have a run-time solution for the more static 
languages like C++?

-Chris
--
Christopher Barker, Ph.D.
Oceanographer

NOAA/OR&R/HAZMAT (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception
[EMAIL PROTECTED]
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Mac User Python Newbies

[Wolfgang Keller]

> I tried SPE, PythonCard, PyOxice, PyPE, eclipse and 
> wing (under x11). 

Supposed to run on MacOS X:
Eric3, Boa Constructor, DrPython (?), Leo (not exactly a conventional IDE)

Maybe someday as well:
BlackAdder

It doesn't seem to me that there are no IDEs available for Python on MacOS
X (or any other common system), but rather the opposite is true imho: There
are so many different ones that in fact the development ressources get
scattered instead of concentrated and in the end none gets the effort that
would be required to make it "rock-solid" and "newbie-proof".

And (from my outsider perspective as a "constant newbie") this seems to be
somehow symptomatic for the Python "community" altogether: Usually for each
"problem" to solve, there are several implementations competing with each
other. Other examples besides IDEs: DB modules, web frameworks, ORMs...

If for each given problem one implementation was chosen as "the official
one" and efforts would be concentrated on "hardening" this one and merging
in good features/concepts from the others as far as possible, newbies would
maybe get less confused and could maybe also get more productive more
quickly due to "better quality" of the "batteries included" in python...

Best regards

Wolfgang Keller

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Mac User Python Newbies

[Chris Barker]

Wolfgang Keller wrote:
If for each given problem one implementation was chosen as "the official
one" 
To some extent, while Guido could endorse something (which is more or 
less the case with IDLE), there is no way to name something the 
"official one", and even if there were, there's nothing to stop folks 
from going out on their own anyway. Thus is the nature of open-source. 
How many Linux distros are there?

Remember that most of this stuff is written by folks who are "scratching 
an itch". The scratching itself is as much the point as getting rid of 
the itch, and many people find it much more satisfying to do something 
in just their own way than adapting to other's ideas and style.

Very little becomes standard by declaration: If someone makes something 
really good, it could evolve into a standard.

By the way, I've often thought of forming a company that would produce 
just what we've been talking about here, but with a bit of a twist:

A set of Python environments for doing specialized development. Some 
ideas are:

--A database app environment, as easy to use as FileMaker, but with a 
real language at it's core.

--A scientific programming environment, everything that MATLAB gives 
you, but again, with a real language at the core.

--Maybe a web framework.
--And you'd probably need to do a general purpose IDE as well.
Anyone have any venture capital?
I know that there are open-source versions of all of these: SciPy, Dabo, 
Pythoncard, Zope, etc., but they don't have the polish that you'd need 
to attract the type of newbies that are at the core of this thread.

-Chris

--
Christopher Barker, Ph.D.
Oceanographer

NOAA/OR&R/HAZMAT (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception
[EMAIL PROTECTED]
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Re: Mac newbie

[Bob Ippolito]

On Feb 14, 2005, at 3:06 PM, Chris Barker wrote:
Bob Ippolito wrote:
On Feb 14, 2005, at 2:05 PM, Chris Barker wrote:
Except that AnyGui was never a good idea. A wrapper around a wrapper 
around a wrapper around a . just too much!

While I agree with the assertion that a large part needs to be 
written in a lower level language, I don't agree that wrapping a 
wrapper is going to be a performance problem.
It's not so much performance as complexity and the 
lowest-common-denominator problem. I"m pretty sure AnyGui is dead now 
anyway, and I've written a couple longer rants about this, but 
consider this:

AnyGuiTK is a Python wrapper around a Python wrapper around another 
scripting language, around and extension written in C, which is 
wrapped about the X11 API, which is emulated on other platforms.

AnyGuiWx is a Python wrapper around a SWIG wrapper around a C++ 
toolkit that is a wrapper around a native GUI toolkit.

When there's a bug, you've got a lot of layers that may be responsible!
That happens anyway :)  Only the AnyGui developers need to care about 
this.  A typical user of wxPython isn't going to be able to track a bug 
down to Carbon any better than a hypothetical AnyGui user is going to 
be able to.

It comes down to why? AnyGui has a flawed reason for being. NO one 
should care what toolkit is underlying their app at the bottom. What 
they should care about is;

The API
The Look and Feel
The Features
The Platform support
AnyGUI had some potential to improve the API of the underlying 
toolkits but that's it. It makes much more sense to just write a 
better API wrapper around a toolkit that meets your other needs.
And the API is the only one of those things that the underlying toolkit 
DOESN'T ultimately control!  Though it of course can have a big 
influence w.r.t. thread safety and what should be asynchronous.

The only fundamental difference between AnyGui and wxPython is that 
wxPython has a lot of C++ code (re: wxWidgets) where AnyGui would have 
a lot of Python code and relatively little platform code.

Ideally I'd propose a design like this:
1. Low level C/ObjC/C++ implementation (probably the native 
platform's toolkit, but could be wxWidgets, Qt, etc.)
wouldn't it have to be it it were X-platform?
Well the difference is that a "native platform" could be either the 
actual platform toolkit, or something on top of said toolkit.  For 
example, there's the Win32 API, and then anything on top of that (MFC, 
wxWidgets, etc.).

2. Thin Python FFI layer (i.e. ctypes or PyObjC -- ultimate 
flexibility, minimal non-Python code)
What's FFI ?
Foreign Function Interface
2.5. Mid-level Python layer if necessary for a sane implementation of 
the high-level (might be overkill for PyObjC given how similar 
Objective-C and Python are)
Good point. The better the API you're wrapping, the less need for this.
3. High level Python layer (exposes a nice interface for Python 
developers)
This sounds a lot like PythonCard, actually.
1) wxWidgets
2) SWIG--wxPython
2.5) Some of the stuff wxPython adds: better dynamic binding syntax, 
OGL, FloatCanvas, other high level widgets.
3) That's what PythonCard itself is.
Yeah, I think PythonCard has the right approach for the layers that 
they control (2.5-3).  wxPython/wxWidgets is something that I'd have 
approached differently, though at the time the projects were started 
the methods they used were most certainly the best or near-best ways to 
do it.

Wrappers generated with tools such as SWIG, sip, bgen, and Boost 
Python could also fit in for layer 2 -- but I think that a runtime 
solution is going to be better in the long run.
hmm. Is it possible to have a run-time solution for the more static 
languages like C++?
If you can do it for C you can do it for C++.  The problem is that C 
has very few calling convention standards where C++ is much less 
standardized (though this is settling a bit).  At worst, you would have 
a "cpptypes" that could only do magic for code generated by a 
particular compiler (e.g. gcc 3.3).  The largest difference between 
Objective-C and C is that Objective-C compiles lots of RTTI (runtime 
type information) and makes it available to the objects themselves.  C 
doesn't do this at all, all you have is the symbols in the symbol 
table, you don't even know if they're functions or globals.  C++ is a 
hybrid, where a lot of this type information is actually in the symbol 
table, but not so easily available at runtime.  The approach that you 
take with ctypes for C is to convert a lot of information from the 
headers into Python syntax, C++ you would take *some* information from 
the headers and translate into Python syntax (I haven't studied C++ 
compilation enough to be able to say what the scope of "some" is), and 
in Objective-C you need extremely little information from the headers 
(just constants, global variables, and functions -- basically cruft 
from the subset of Objective-C that is C -- which is fortunately not 
that popular in 

Re: [Pythonmac-SIG] Mac User Python Newbies

[Bob Ippolito]

On Feb 14, 2005, at 3:08 PM, Wolfgang Keller wrote:
I tried SPE, PythonCard, PyOxice, PyPE, eclipse and
wing (under x11).
Supposed to run on MacOS X:
Eric3, Boa Constructor, DrPython (?), Leo (not exactly a conventional 
IDE)
Speaking of DrPython, I have an example of having it packaged in the 
py2app svn trunk.. but as it uses wxScintilla, it isn't really very fun 
to play with.

Maybe someday as well:
BlackAdder
It doesn't seem to me that there are no IDEs available for Python on 
MacOS
X (or any other common system), but rather the opposite is true imho: 
There
are so many different ones that in fact the development ressources get
scattered instead of concentrated and in the end none gets the effort 
that
would be required to make it "rock-solid" and "newbie-proof".

And (from my outsider perspective as a "constant newbie") this seems 
to be
somehow symptomatic for the Python "community" altogether: Usually for 
each
"problem" to solve, there are several implementations competing with 
each
other. Other examples besides IDEs: DB modules, web frameworks, ORMs...

If for each given problem one implementation was chosen as "the 
official
one" and efforts would be concentrated on "hardening" this one and 
merging
in good features/concepts from the others as far as possible, newbies 
would
maybe get less confused and could maybe also get more productive more
quickly due to "better quality" of the "batteries included" in 
python...
This generally happens eventually, it just takes time for one approach 
to be obviously better and good enough to become the official one.  Or 
at least some standard way of doing things (DB-API, WSGI, importer 
protocol, etc.)

-bob
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

[Pythonmac-SIG] Re: Pythonmac-SIG Digest, Vol 22, Issue 46

[Andrew Meit]

On Feb 14, 2005, at 3:04 PM, [EMAIL PROTECTED] wrote:
And it seems that very often programmers never do get around to that 
'rebuild and replace' stage, because as soon as they've reached 
working code it's considered 'done', and to then throw that code away 
and start all over again is anathema. Coming from a fine art 
background, I _know_ that if you've a day to draw a life picture, then 
the best way to spend that time is 'wasting' the first half on 
throwaway sketches and only sitting down to the final version in the 
final few remaining hours, not spend all day hammering away at this 
one single drawing from 9 till 5.
-- YES, I once, when much younger, did Type (known for my Gutenberg 
font work) and graphic design; and so "write and burn" method was 
carried over to my coding as second nature. However, I found out in 
programming world rarely was that method valued or wanted: "gotta ship, 
now". 
	Which brings up another point: testing. Does python support robust 
testing tools or methods?? I code towards quality and so an IDE needs 
to support that goal. :-)

Andrew
-{Choose Life, Create hope, Nurture Love...}-
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Mac User Python Newbies

[Bob Ippolito]

On Feb 14, 2005, at 3:27 PM, Chris Barker wrote:
Wolfgang Keller wrote:
If for each given problem one implementation was chosen as "the 
official
one"
To some extent, while Guido could endorse something (which is more or 
less the case with IDLE), there is no way to name something the 
"official one", and even if there were, there's nothing to stop folks 
from going out on their own anyway. Thus is the nature of open-source. 
How many Linux distros are there?

Remember that most of this stuff is written by folks who are 
"scratching an itch". The scratching itself is as much the point as 
getting rid of the itch, and many people find it much more satisfying 
to do something in just their own way than adapting to other's ideas 
and style.

Very little becomes standard by declaration: If someone makes 
something really good, it could evolve into a standard.

By the way, I've often thought of forming a company that would produce 
just what we've been talking about here, but with a bit of a twist:

A set of Python environments for doing specialized development. Some 
ideas are:

--A database app environment, as easy to use as FileMaker, but with a 
real language at it's core.

--A scientific programming environment, everything that MATLAB gives 
you, but again, with a real language at the core.

--Maybe a web framework.
--And you'd probably need to do a general purpose IDE as well.
Anyone have any venture capital?
I know that there are open-source versions of all of these: SciPy, 
Dabo, Pythoncard, Zope, etc., but they don't have the polish that 
you'd need to attract the type of newbies that are at the core of this 
thread.
I'm definitely interested in these things (more some than others), but 
I'm currently professionally committed to some other stuff.  The real 
problem I'd have with this sort of business venture is doing it in a 
way that's compatible with open source, but still making enough money 
to keep doing it without spending too much time doing consulting.

I'd definitely want to give these things away as liberally licensed 
open source, which might mean that it has to be done in the context of 
a non-profit foundation (like Chandler via OSAF).  However, it might be 
possible to get away on a smaller scale by simply having a set of 
robust open source tools as the "lite" version, and a "pro" version 
with a couple nice extra features that isn't free (like the difference 
between OmniGraffle and OmniGraffle Pro).  I've never seen the donation 
model work at the smaller scale.

-bob
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Mac User Python Newbies

[Wolfgang Keller]

> To some extent, while Guido could endorse something (which is more or 
> less the case with IDLE), there is no way to name something the 
> "official one", and even if there were, there's nothing to stop folks 
> from going out on their own anyway.

Sure, but...

> Thus is the nature of open-source. 
> How many Linux distros are there?

...how many FreeBSD distributions are there?

And what is the consequence for the users, developers, administrators of
systems running on FreeBSD compared to Linux? *duck* >:->

Best regards

Wolfgang Keller

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Mac User Python Newbies

[Troy Rollins]

> 
> I know that there are open-source versions of all of these: SciPy, Dabo,
> Pythoncard, Zope, etc., but they don't have the polish that you'd need
> to attract the type of newbies that are at the core of this thread.
> 
True enough. There have been no shortage of excellent thoughts and
suggestions, but I think that what the new user really want, more than
"free", is something which provides a "raodmap to being productive." I
am not an inexperienced developer. I develop non-trivial applications
with high-level languages... one example
... I've actually written that same
application, or large portions of it in several different programming
languages, and have multiple custom versions of it running in some
extremely high-end systems of its kind. I wouldn't have a clue how to
write that application in Python. The bits and pieces of logic I can
imagine without difficulty... bits an pieces of scripts, no problem...
but the whole project? It is just too big, with too many lines of code
for me to manage with a text editor and the terminal.

Many of the (very generous) free tools that have been written by
community members are fabulous examples of the possible... but are not
really a working environment which can be trusted for large projects.
And perhaps, (as I think Bob mentioned) therein lies the problem. If
all those options didn't exist, people like me would spend the first
several months trying to find something which works like the (payware)
tools we are accustomed to.

What I *want* in an environment like Flash, Director, REALbasic, etc.
which is python-based.  I've seen a lot of great tools so far, but
none of them match the capabilities of these tools in terms of
refinement, as well as being supportive of users of all levels.
Director, as an example, is pretty friendly to newbies, but it is also
used by gurus on a level of any Python guru. There is nothing to say
that an IDE must be restrictive, either. For instance, I love the
Director IDE, but I often use SubEthaEdit to edit my Lingo scripts...
Director does not demand that it be my only script editor.

So far, Eclipse, and things like Xored TruStudio are very robust and 
look like they are heading in the right direction, for those of us who
don't need to be spoonfed, but also like a productive tool to help
keep our thoughts together while we build our products.

I plan to research some of the latest great suggestions, and I
appreciate all the comments. I do hope that these long threads are
useful to others as well, and hopefully that the community gains
insight into extending itself out to other potential "markets" beyond
the "pioneer crowd" it currently enjoys.

Cheers.
-- 
Troy Rollins
RPSystems, Ltd.
www.rpsystems.net
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Mac User Python Newbies

[Wolfgang Keller]

> Speaking of DrPython, I have an example of having it packaged in the 
> py2app svn trunk.. but as it uses wxScintilla, it isn't really very fun 
> to play with.

Dumb question: What's wrong with wxScintilla? Doesn't SPE use it as well?
What's Boa using?

Best regards,

Wolfgang Keller

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Re: Pythonmac-SIG Digest, Vol 22, Issue 46

[Bob Ippolito]

On Feb 14, 2005, at 4:11 PM, Andrew Meit wrote:
On Feb 14, 2005, at 3:04 PM, [EMAIL PROTECTED] wrote:
And it seems that very often programmers never do get around to that 
'rebuild and replace' stage, because as soon as they've reached 
working code it's considered 'done', and to then throw that code away 
and start all over again is anathema. Coming from a fine art 
background, I _know_ that if you've a day to draw a life picture, 
then the best way to spend that time is 'wasting' the first half on 
throwaway sketches and only sitting down to the final version in the 
final few remaining hours, not spend all day hammering away at this 
one single drawing from 9 till 5.
-- YES, I once, when much younger, did Type (known for my Gutenberg 
font work) and graphic design; and so "write and burn" method was 
carried over to my coding as second nature. However, I found out in 
programming world rarely was that method valued or wanted: "gotta 
ship, now". 	Which brings up another point: testing. Does python 
support robust testing tools or methods?? I code towards quality and 
so an IDE needs to support that goal. :-)
There is plenty of Python software out there to facilitate testing: 
pychecker, the standard library unittest, py.test, ComfyChair, etc.  
I'm really not sure of any IDE that also has test runners, but that 
really isn't such a big deal.  It's Just Another Script.

-bob
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Mac User Python Newbies

[Bob Ippolito]

On Feb 14, 2005, at 4:32 PM, Wolfgang Keller wrote:
Speaking of DrPython, I have an example of having it packaged in the
py2app svn trunk.. but as it uses wxScintilla, it isn't really very 
fun
to play with.
Dumb question: What's wrong with wxScintilla? Doesn't SPE use it as 
well?
What's Boa using?
It's currently really slow on Mac OS X, as mentioned before.  I don't 
like environments where I can type faster than the redraw.  No idea 
about Boa.

-bob
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Mac User Python Newbies

[Chris Barker]

Bob Ippolito wrote:
Dumb question: What's wrong with wxScintilla? Doesn't SPE use it as well?
What's Boa using?
It's currently really slow on Mac OS X, as mentioned before.  I don't 
like environments where I can type faster than the redraw.  No idea 
about Boa.
Boa uses wxScintilla (AKA wxSTC) also. It is also only currently working 
 with wxPython2.4.2, so not a good option on the Mac for that reason 
anyway.

I do think the performance of wxSTC has been improved in more recent 
versions of wx, but I'm not the one to tell you for sure. I'm still not 
sure anyone has figured out how to use ATSUI in a truly efficient way yet.

-Chris

--
Christopher Barker, Ph.D.
Oceanographer

NOAA/OR&R/HAZMAT (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception
[EMAIL PROTECTED]
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Mac User Python Newbies

[Chris Barker]

Troy Rollins wrote:
I think that what the new user really want, more than
"free", is something which provides a "raodmap to being productive."
I've lost track, have you tried any of the proprietary tools? (Wing, 
etc.). I know I haven't.

but the whole project? It is just too big, with too many lines of code
for me to manage with a text editor and the terminal.
I'm confused here. People have been managing big coding projects with an 
editor and a command line for ages. More to the point, many folks still 
do it, even when they have the option of a nifty GUI IDE. In fact, one 
thing I realized when working with Windows and the old MacOS, was that 
one reason that you needed an IDE so badly on those systems, and not so 
much on Unix, was that in a way, Unix IS an IDE. I still find grep 
easier to use than any "find in files" feature in an editor or IDE, for 
example.

 If
all those options didn't exist, people like me would spend the first
several months trying to find something which works like the (payware)
tools we are accustomed to.
Did you mean "would NOT spend the "?
Off to get some real work done.
-Chris
--
Christopher Barker, Ph.D.
Oceanographer

NOAA/OR&R/HAZMAT (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception
[EMAIL PROTECTED]
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Mac User Python Newbies

[Charles Hartman]

I don't know if this answers the question, but I've been using wxSTCs 
in my apps (there's no other way to display or edit text over 32k), and 
they seem to work just fine. One app uses an STC to load, for example, 
a 4.5 meg text file and do some searches on it. It's all very quick and 
painless. The only annoyance is the almost-but-not-quite-the-same 
commands for STCs versus wx's TextCtrls.

Charles Hartman
On Feb 14, 2005, at 5:08 PM, Chris Barker wrote:
Boa uses wxScintilla (AKA wxSTC) also. It is also only currently 
working  with wxPython2.4.2, so not a good option on the Mac for that 
reason anyway.

I do think the performance of wxSTC has been improved in more recent 
versions of wx, but I'm not the one to tell you for sure. I'm still 
not sure anyone has figured out how to use ATSUI in a truly efficient 
way yet.
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Re: Pythonmac-SIG Digest, Vol 22, Issue 46

[Just van Rossum]

Andrew Meit wrote:

> -- YES, I once, when much younger, did Type (known for my Gutenberg 
> font work) and graphic design; 

I must be getting old, too: I thought I knew everyone who did type AND
Python... Welcome to the club.

Just
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Mac User Python Newbies

[has]

Bob Ippolito wrote:
Maybe because in many cases, the users are the developers and adding
those 20%s together makes for some big ugly mess.
I'm not sure that qualifies as an excuse; more making their bed and 
lying in it. :)
Well the people writing these things obviously write it such that it 
suits them, so perhaps they find this bed to be comfortable?
People are generally lazy. They'll do less work now even if it means 
more work later. (Perl's definition of 'lazy', while charming, is 
seriously optimistic.)


Personally, I hope that developers See The Light and do interface
building in a separate but integrated application like Xcode and
Interface Builder.
Exactly. Or separate, integrateable components that plug into a 
common base framework.
Well, separate processes is necessary.. a component based model 
can't work, because certain components just can't live in the same 
process with one another.
Why not? And even where multiple processes are needed, why shouldn't 
we still hide the distinction from the user? (e.g. Erlang is 
virtually nothing _but_ processes.) Application-centric metaphors are 
nothing special. Hierarchical file/folder metaphors are nothing 
special. They're not inviolable holy of holies.


 > I've never understood what the obsession with building every
 > conceivable feature into the application core,
I think this is largely caused by complexity of the alternative and the
convenience of doing it in this way.
Developer convenience up to a point, yes. It requires less up-front 
planning and major direction changes: just jump in and write some 
code. Yet the same could be said for procedural vs OO construction, 
so why are developers seeing the advantages of modular design in 
the small but still missing it so often in the large?
I think in a lot of cases this may be somewhat incorrect.  A lot of 
times you have a really modular framework, but it's not easy to rip 
apart into its constituent components and install just what you want 
(Twisted 1.x is an example of this).
There's no excuse for coupling, say, persistence mechanisms and 
templating mechanisms into the framework. Argue the point again when 
they've at least managed to split those off.


So what?  Although Twisted 2.x is moving away from this model, it's 
to accommodate a more flexible release schedule, not to split it up 
for the sake of splitting it up.
IOW, there are benefits to modular, componentized architecture. I'm 
certainly not arguing doing it simply for its own sake.


In some cases, such as your own appscript/aem/etc., this kind of 
external componentization is more of a hassle than anything else.
Bad example. Appscript/aem's heavily componentized architecture is 
not the problem. The problem with appscript is that 1. Python's own 
module management mechanism is mediocre, and 2. I haven't bothered 
compensating for this weakness by providing an easy 'all-in-one' 
installer.


But there are ways. OpenDoc was built upon Apple events, for example.
I've never seen it done in Python really easily.
Which is not to say it can't be done. It just means than in order for 
it to be done, some poor sap will have to have to step up and do all 
the hard work themselves. Which means lots of exploration and 
experimentation and lots of throwing out and starting over until the 
answers start emerging.


It's interesting that even MS are now moving away from the DCOM 
approach and towards an Apple event/Apple Event Object Model 
approach. I think Apple were definitely onto something with these: 
it's all about where you make the split, and finding the right 
point makes the difference between moving Mohammed or moving the 
mountain.
And we all know how well Apple has been implementing Apple Events in 
its more recent applications.  It's simply Not That Easy to do so, 
so it's simply not done well or not done at all.
Apple can't even come up with a half decent explanation of what Apple 
events are. Wanna take bets on the total amount of resources they 
bother to invest in them internally? Is it any surprise they so often 
don't get supported properly? It's hardly like this is the first time 
Apple have come up with a great technology and consistently fumbled 
its deployment. Only Xerox seems able to consistently make an even 
bigger arse of things. I think you're much to quick in throwing up 
your hands; there's a big difference between a bolloxed execution and 
a bolloxed concept, and failure of one doesn't automatically imply 
failure of the other.


that, and it's much easier to design something ad-hoc if you don't 
concern yourself with keeping things modular.
Of course. I often start out that way myself; it's hard to know 
what kind of high-level structure you're going to need if it's your 
first time exploring this particular problem. The trouble sets in 
when an initially ad-hoc design doesn't bother to improve its 
internal organisation as it grows;
Well yeah, you do have to clean up your mess every so often.
Or constantly, 

[Pythonmac-SIG] New wiki entry

[Robert White]

I just added a new wiki entry, "Describe Apple's Framework implementation of Python and how that affects me adding new Python implementations".  Please review it.  If it does not answer your questions about Apple's Framework installation, please send those questions to this list or me personally and I will try to adjust the entry to answer the question.

Thanks,

Bob White___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

[Pythonmac-SIG] Re: Macu User Python Newbiew

[Brendan Simons]

" cmd [ " moves a block of selected text one tab level back (4 spaces 
if you've set "auto-expand tabs").  and " cmd ] " moves a block of text 
one level forward.  Is this what you're looking for?  TextWrangler is 
no IDE, but as a code editor it's very good.

-Brendan
On 14-Feb-05, at 2:03 PM, [EMAIL PROTECTED] wrote:
But does it do Python indenting correctly? This is my only really 
obstacle with BBedit (a couple versions old). You can make it put in 
spaces instead of tabs, but once they're in they are treated only as 
spaces, rather than levels of indentation, so when you want to remove 
a level you have to hit delete four times. Not horrible, but annoying.

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Mac User Python Newbies

[Chris Barker]

Bob Ippolito wrote:
I'm definitely interested in these things (more some than others), but 
I'm currently professionally committed to some other stuff.  The real 
problem I'd have with this sort of business venture is doing it in a way 
that's compatible with open source, but still making enough money to 
keep doing it without spending too much time doing consulting.
Well, aside form the fact hat I'm no businessman, that's one of my show 
stoppers too. I'm not sure how to balance open source and trying to make 
a profit.

I'd definitely want to give these things away as liberally licensed open 
source,
I would too, but I'm not sure there's a business plan there. Another 
idea was to open source what has always worked well as open source: the 
core libraries, like whatever GUI toolkit was used, be it improvements 
to an existing one, or something done just for this. The nifty, 
easy-for-newbies IDEs are kind of more of a natural for proprietary 
projects, as has been discussed here.

which might mean that it has to be done in the context of a 
non-profit foundation (like Chandler via OSAF).
That would be nice, but I have even less of an idea how to get money for 
hat than I do getting venture capital to start a business. However, 
perhaps this is just what one poster proposed: the PSF could fund a good 
cross-platform IDE.

However, it might be 
possible to get away on a smaller scale by simply having a set of robust 
open source tools as the "lite" version, and a "pro" version with a 
couple nice extra features that isn't free (like the difference between 
OmniGraffle and OmniGraffle Pro).
Another good idea, but we'd still need the start-up money!
-Chris
--
Christopher Barker, Ph.D.
Oceanographer

NOAA/OR&R/HAZMAT (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception
[EMAIL PROTECTED]
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Mac User Python Newbies

[Bob Ippolito]

On Feb 14, 2005, at 18:29, has wrote:
Bob Ippolito wrote:
Personally, I hope that developers See The Light and do interface
building in a separate but integrated application like Xcode and
Interface Builder.
Exactly. Or separate, integrateable components that plug into a 
common base framework.
Well, separate processes is necessary.. a component based model can't 
work, because certain components just can't live in the same process 
with one another.
Why not? And even where multiple processes are needed, why shouldn't 
we still hide the distinction from the user? (e.g. Erlang is virtually 
nothing _but_ processes.) Application-centric metaphors are nothing 
special. Hierarchical file/folder metaphors are nothing special. 
They're not inviolable holy of holies.
It's simply, without a doubt, no way around it, not technically 
possible to hide the separation from the user if you want to support 
components written using different GUI frameworks -- and that is an 
explicit requirement.  On Mac OS X, each process may have zero or one 
GUI event loops, and each event loop may have zero or one Mac OS X menu 
bars.  You simply can not design it any other way without being 
shackled to a particular GUI framework.

Why the heck should a text editor share a menu and accelerator keys 
with an interface builder anyway?

 > I've never understood what the obsession with building every
 > conceivable feature into the application core,
I think this is largely caused by complexity of the alternative and 
the
convenience of doing it in this way.
Developer convenience up to a point, yes. It requires less up-front 
planning and major direction changes: just jump in and write some 
code. Yet the same could be said for procedural vs OO construction, 
so why are developers seeing the advantages of modular design in the 
small but still missing it so often in the large?
I think in a lot of cases this may be somewhat incorrect.  A lot of 
times you have a really modular framework, but it's not easy to rip 
apart into its constituent components and install just what you want 
(Twisted 1.x is an example of this).
There's no excuse for coupling, say, persistence mechanisms and 
templating mechanisms into the framework. Argue the point again when 
they've at least managed to split those off.
So what if having Twisted installed gets you both persistence and 
templating functionality?  They are not tightly coupled to anything 
else in Twisted that don't absolutely require them to function, and you 
don't have to use them.

So what?  Although Twisted 2.x is moving away from this model, it's 
to accommodate a more flexible release schedule, not to split it up 
for the sake of splitting it up.
IOW, there are benefits to modular, componentized architecture. I'm 
certainly not arguing doing it simply for its own sake.
The *architecture* has been componentized since the start (or at least 
for the past few years, pre-1.0).  The release packages were not.

In some cases, such as your own appscript/aem/etc., this kind of 
external componentization is more of a hassle than anything else.
Bad example. Appscript/aem's heavily componentized architecture is not 
the problem. The problem with appscript is that 1. Python's own module 
management mechanism is mediocre, and 2. I haven't bothered 
compensating for this weakness by providing an easy 'all-in-one' 
installer.
I don't think you understood my point.
Twisted 1.x is fully modular and componentized, but is distributed as a 
single unit
Twisted 2.x is fully modular and componentized, and will be distributed 
as multiple units (or one "sumo" installer that has them all)

There's no technical advantage whatsoever to Twisted 2's organization, 
but it makes sense given the need to have distinct release cycles -- 
which is simply a matter of scale.

appscript takes this to the extreme by separating several related 
things into different packages when they follow in lock-step anyway.  
Distutils is perfectly suitable for installing several packages at the 
same time in the same setup(...) invocation, there is *no good reason* 
for the appscript suite to be distributed in several units.  It's just 
a hassle for everyone, probably including yourself, because you have to 
upload and manage several different packages.

And it seems that very often programmers never do get around to that 
'rebuild and replace' stage, because as soon as they've reached 
working code it's considered 'done',
Lots of people think that throwing away an application and starting 
over is a real mistake.  Joel Spolsky has an article on this that 
everyone likes to quote.
Throwing away an _application_ is a sign that you've massively 
fubared, and anyone who does that _should_ indeed be bloody ashamed of 
themselves. Whereas generating and chucking away lots of fast working 
sketches is an indication that you're already planning and 
anticipating well ahead, because you're throwing out at a time when 
the cost of doing so is still ex

Re: [Pythonmac-SIG] Mac User Python Newbies

[Charles Hartman]

I don't want to beat this dead horse any farther into the ground, but: 
I'm working on a small but not toy app, one or two thousand lines in 
eight modules. To build and debug a module with "if __name__ == 
'__main__'", I can use TextWrangler's Run, or Run-with-debug if I want 
to get down into pdb. This works even if the module imports other 
program modules, as long as they're pretty well finished and debugged. 
But to put together more than that -- to trace bugs and design flaws 
having to do with the interaction among modules -- I need to turn to 
the WingIDE (the only one whose debugger I've been able to get 
working), which will let me step through and into my code, moving 
seamlessly from module to module.

I'm not suggesting I couldn't do all this with an editor and Terminal; 
I'm saying this is the easy way for me, at my stage -- beginner but not 
complete beginner -- and that without the IDE I'd get lost in the 
larger integrative steps. And those are the parts where a 
sort-of-beginner is most likely to need help for (I'm guessing) quite a 
while.

Charles Hartman
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Mac User Python Newbies

[Bob Ippolito]

On Feb 14, 2005, at 19:47, Chris Barker wrote:

Bob Ippolito wrote:
I'm definitely interested in these things (more some than others), 
but I'm currently professionally committed to some other stuff.  The 
real problem I'd have with this sort of business venture is doing it 
in a way that's compatible with open source, but still making enough 
money to keep doing it without spending too much time doing 
consulting.
Well, aside form the fact hat I'm no businessman, that's one of my 
show stoppers too. I'm not sure how to balance open source and trying 
to make a profit.

I'd definitely want to give these things away as liberally licensed 
open source,
I would too, but I'm not sure there's a business plan there. Another 
idea was to open source what has always worked well as open source: 
the core libraries, like whatever GUI toolkit was used, be it 
improvements to an existing one, or something done just for this. The 
nifty, easy-for-newbies IDEs are kind of more of a natural for 
proprietary projects, as has been discussed here.
I'm not sure I'd really want to do it if it wasn't almost entirely open 
source.  If I'm going to be developing closed stuff, I might as well 
target a larger market than current and future Python developers :)

which might mean that it has to be done in the context of a 
non-profit foundation (like Chandler via OSAF).
That would be nice, but I have even less of an idea how to get money 
for hat than I do getting venture capital to start a business. 
However, perhaps this is just what one poster proposed: the PSF could 
fund a good cross-platform IDE.
It'd probably be easier to try and get grant(s) than to try and start a 
new non-profit organization expressly for the purpose -- but I wouldn't 
really know.

However, it might be possible to get away on a smaller scale by 
simply having a set of robust open source tools as the "lite" 
version, and a "pro" version with a couple nice extra features that 
isn't free (like the difference between OmniGraffle and OmniGraffle 
Pro).
Another good idea, but we'd still need the start-up money!
The way some small software developers have gone is to segue a 
consulting business (which takes almost no startup capital) into a 
product business..

-bob
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Mac User Python Newbies

[Bill Janssen]

> If I'm going to be developing closed stuff, I might as well 
> target a larger market than current and future Python developers :)

Well, that's good.  My projects are typically a mix of Python, Java,
and Jython, often with a bit of C, C++, HTML, CSS and Javascript, all
mixed together.  An IDE that won't let me mix them up (WingIDE,
Eclipse) does me no good.  Emacs to the rescue!

Bill
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Mac User Python Newbies

[Bob Ippolito]

On Feb 14, 2005, at 9:21 PM, Bill Janssen wrote:
If I'm going to be developing closed stuff, I might as well
target a larger market than current and future Python developers :)
Well, that's good.  My projects are typically a mix of Python, Java,
and Jython, often with a bit of C, C++, HTML, CSS and Javascript, all
mixed together.  An IDE that won't let me mix them up (WingIDE,
Eclipse) does me no good.  Emacs to the rescue!
Well, what I meant, is that I'm not sure I'd want to be in the 
development tools business at all if I was going to be writing closed 
software.

I'm sorry you have to deal with HTML/CSS/Javascript mixed projects :)
-bob
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig