Re: sqlite for mac?

2007-05-01 Thread kirkjobsluder
On May 1, 1:12 pm, 7stud <[EMAIL PROTECTED]> wrote:
> I'm using python 2.4.4 because the download said there were more mac
> modules available for 2.4.4. than 2.5, and I can't seem to locate a
> place to download sqlite for mac.

I it comes on OS X Tiger, and possibly earlier versions as well (it's
used as an index for Mail.app)..  You just need to download and
install the pysqlite libraries.

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


Re: Future Python Gui?

2007-04-18 Thread kirkjobsluder
On Apr 18, 11:24 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> > I'd say that the best bet is to learn swig and similar
> > bridging, expanding, and embedding mechanisms.
> > Python GUI programming is likely to involve either
> > python hooking into frameworks like Cocoa, Qt, or
> > wxWidgets, python embedded in frameworks
> > like Java or .NET, or flavors of python used
> > as domain-specific languages in applications such as
> > emacs, vim, and OpenOffice.org.
>
> If this were just a tool for me, it wouldn't matter.  My concern is
> distribution.  If anybody who wants to run my software then they also
> have to go through all the trouble to install these extensions, none
> of which seem to have decent instructions.  I'm an old-time hack and I
> have trouble getting them to work.  A simple user won't have a chance!

Deployment has improved a lot in recent years, PyObjC is a simple
double-click on a package.  Most windows libraries work the same way.
On the FOSS Unix world, you would add to a package system which will
install dependencies automatically.  When I used a FOSS Unix, I really
only got burned when I decided to live on the bleeding edge. And as
someone else pointed out, package tools should take much of the work
out of delivery.

Meanwhile, things could work the other way around. If Apple extends
their support to PyObjC for example, python developers would know that
every new OS X system would be able to run their PyObjC.

> If Python doesn't declare an official Gui system, then it'll be
> fragmented, inconsistent, and unsupportable.

I don't see that as the case because many other languages don't have
an "official" GUI system including C, C++, Ruby, lisp, Basic and
perl.  All of these have their active areas of deployment.  For that
matter, Java has three "official" GUI systems with most development on
the server side.

And didn't comp.long.python have this same argument in regards to
MySQL support which was dropped from php? In addition to license
issues, the php core library just wasn't used, and lagged behind the
MySQL library.

My personal opinion is that GUI development is such a moving target
that toolkits are a poor choice for inclusion into the core standard
libraries.  There does not appear to be a standards process involved,
and toolkits are expanding or changing parts of their API every few
years.  Anything that could be added, is going to be obsolete by the
time it is incorporated into the standard. My feeling is that python
is better served by encouraging GUI developers to include python-
friendly bindings.

> I wouldn't mind using just Tkinter, despite it's primative look,
> except that it doesn't support more advanced widgets like "notebook".

I wouldn't mind seeing tkgrid and tkhtml added to the standard
library.  But Tk is probably "good enough" for most simple
interfaces.

>
> -- Brian


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


Re: Future Python Gui?

2007-04-18 Thread kirkjobsluder
On Apr 18, 2:07 am, Richard Jones <[EMAIL PROTECTED]>
wrote:
> kirkjobsluder wrote:
> > I'd say that the best bet is to learn swig and similar
> > bridging, expanding, and embedding mechanisms.
>
> For GUI programming this would seem overkill. Pick a GUI toolkit and it's
> almost guaranteed to be wrapped for use in Python already.

Perhaps a bit.  I'm not saying that everyone should wrap their own
code,
but many of the currently existing wrappers are quite thin, and
understanding
how to use and debug wrapped GUI code might put one in a better
position
over knowing a particular toolkit.


>
> Richard


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


Re: Future Python Gui?

2007-04-17 Thread kirkjobsluder
On Apr 17, 9:28 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> I've been trying to find out what the future of Python is with regard
> to Tk.  It seems there are several interfaces that make use of new
> functionality, including "Tile" and "Ttk".
>
> If I want to write a program that will run under the standard Python
> distribution of the future, what extension module should I work with
> today?

I've been doing a lot of reading this month.

At the moment, none of the toolkits available strike me as being in a
position to become the next tkinter, and it seems like core python
development is moving away from extensions that might be
better produced by other parties.  Everyone and their cousin
have different ideas about how a GUI should be built including
how it hooks into other services.  Cross-platform, it seems like
wxPython has a considerable edge over jython+SWT or Swing.
But platform-specific frameworks are also pretty important.

I'd say that the best bet is to learn swig and similar
bridging, expanding, and embedding mechanisms.
Python GUI programming is likely to involve either
python hooking into frameworks like Cocoa, Qt, or
wxWidgets, python embedded in frameworks
like Java or .NET, or flavors of python used
as domain-specific languages in applications such as
emacs, vim, and OpenOffice.org.



> Thanks!
>
> -- Brian


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