Re: The Industry choice

2005-01-01 Thread Rob Emmons
> For managers of companies it's worse: the company makes
> VERY substantial investments into any technology it "marries",
> and that means big losses if it goes. Long-term stability
> of this technology in terms of "we're not going to be left out
> in cold alone with this technology to feed it" means a lot 
> to them. Even a poor technology with external backing 
> of big, stable vendor is better than the excellent technology 
> without ..

There is the stability issue you mention... but also probably the fear
issue.  If you choose a solution from a major company -- then it fails for
some reason or they drop the product -- it's their fault -- you've got an
automatic fall guy.  On the other hand, an open source solution or 
otherwise less accepted solution ... it will probably be consider 
your fault by the organization.  It's a rational decision to avoid 
personal risk when you don't get much reward for choosing something 
different.

Rob


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


Re: How do I make Windows Application with Python ?

2005-01-03 Thread Rob Emmons
> Well, I programmed a little in MS Visual Studio 2003, and there you have
> Console apllication and Windows application (among others). Windows one is
> with buttons and other gadgets. So, I want to make applications that
> doesn't open console to display result, I want to display it into the
> message box. Also, I want to use that application on the computers where
> Python isn't installed

First there is a good book:  Python Prgoramming on Win32,  by Hammond &
Robinson, O'Reilly is the publisher.  I believe one of these guys wrote
the python windows extension.

Second, on MS Windows you need two python installs, the basic python install,
and the python for windows extension (also sometimes call win32all or
something like that).  These two together give you a great basic set to
work with.  I've done MS Windows programming with these and they work great.

With the win32 extension module -- you can use ActiveX, you can use the
standard MS Windows calls, and it also defines a python intepretor mode
where it does not open the console window if you name the main program
module as .pyw (as opposed to .py).  It does other things too.  This is
all discribed in the book I recommended.  Note also, if you don't want to
see the console window -- even without use .pyw files, you can tell the
launcher to open the console window minimized -- not great but it does
work.

I believe also if you want to use MS Visual Studio -- Active State sells
python programming tools that plug into MS Visual Studio if you want to do
that.  I've not tried these so I don't know how they work or if they are
any good.

It's also possible to program on MS Windows so your app is protable to Linux
and other systems.  You can use Tkinter or wxWidgets (was called
wxWindows -- until maybe MS made them change it) to do that.  I've 
used Tkinter before for example, though I think wxWidgets is probalby 
more of the wave of the future.  Others may know.

If you want to run the program on other computers not having python, you
have two basic choices.  One -- what I do, I just made up a python setup
CD that installs python, python windows extensions, and the basic
libraries I usually use so that it's easy to setup a python environment on
other systems.  Then I install my code.

The other alternative is to use one of the tools that wraps up a python
program with the needed executables.  Some of these are py2exe, cx-freeze,
McMillan Installer, Fractel Mountains, StarKits, UPX, and InnoSetup. I've
not used any of these -- and so this list may not be correct/complete. 
Others may know what's best.

There are also some compilers too - pyrex, pysco starkiller, and pypy. 
Again, I've not used any of these and this is just from some cryptic notes
I've taken.  So ask others for input.  Probabably you want one of the 
installers rather than the compilers because python compilers are kind of 
new, but that's just a guess.

Hope that helps.
Rob
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: The Industry choice

2005-01-03 Thread Rob Emmons
> Theoretically. Because even though the source code is available
> and free (like in beer as well as in speech) the work of 
> programmers isn't cheap. 
> 
> This "free software" (not so much OSS) notion "but you can
> hire programmers to fix it" doesn't really happen in practice,
> at least not frequently: because this company/guy remains
> ALONE with this technology, the costs are unacceptable. 

This certainly is the thinking, but I is the wrong thinking in many cases.
If companies could some how take a larger view and realize that by working
together here and there -- they enable and open development model which in
the end saves them money.  AHHH but that's such a hard argument because it
takes vision, time, and trust.  

It takes a whole vision change to work in this environment -- believing in
an economy of plenty rather than an economy of scarcity.

> It depends on definition of "rational", on definition of your or
> company's goals and on the definitions of  the situations that 
> are the context. 

I work for a very large company -- there is an internal culture that
defines what "rational" is:  (a) Rational means outsourcing and doing less
inside the company, (b) pretty much single sourcing commerical software,
(c) releasing nothing outside the company unless there is a direct 
demonstratable significant business benifit related to our core products. 

I could argue these are not rational in the long run, but this is
the direction of the company as far as I know.  This will change -- and
someone will get a big promotion for doing it -- but it will take a lot of
time.  And of course someone already got a big promotion for outsourcing
and developing the single source stratagy -- bone headed as it is.

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


Re: The Industry choice

2005-01-04 Thread Rob Emmons
> But the vision of what? Do we have clear, detailed, unambigous vision
> _of the process_ or just big ideological axes to grind? I'm afraid
> we're close to the latter situation - even though Python is remarkably
> different in this area than the "free software": clean, pragmatic,
> effective, free to include in closed-source. If Python were GPLed,
> I wouldn't use it: attempting to force people to share doesn't work.

That is an interesting thing about open source.  I'm very surprised and
encouraged by the wide slice of philosophical views that it embrases.

Me personally, I believe in free software, but always talk about open
source.  My answer regarding forcing people to share -- I like the GPL 
-- and I am perfectly happy to have anyone who does not like the GPL 
not to use any GPLed software.  I don't feel compelled to share.

> Well, I'd say that lack of interchangeability in software is a big
> obstacle on this road: not that there's little source code, but
> that it's relatively hard (read: expensive) to combine the pieces.

Linux/BSD/Unix in some ways have been the most consistent platforms 
over time.  It is ironic that POSIX like systems are perhaps the only
systems that have a pretty set of standards back to the early 1970's. 
It's a great story of what can be done by sharing.

> 'The problem is that for all of the rhetoric about software becoming a
> "commodity", most software is still very much not a commodity: one
> software product is rarely completely interchangeable with another.'

The thing about Open Source -- I don't think I've heard of any other way
for software to become commodity.  I'd love to hear about other options.

> This could be made into a very strong argument for OSS: see the
> OSS developers as your "outsourced team" that works for almost
> nothing, i.e. "if we want to win them or get them to help, maybe
> we should contribute our bugfixes and enhancements to them".

I've wondered about this.  I think the big issue is that it's not
outsourcing where it works -- but the potential for software customization
an in-sourcing things.  That's why it seems to me that Open Source is
portentially the opposite of oursourcing -- though I guess the
customization can be outsourced... hmm...

> As much as people tend to hate outsourcing, it frequently _does_
> increase the efficiency of the industries.  

I actually don't have a problem with outsourcing if it makes sense.  The
big issue I have with this sort of thing is that often the numbers look
good only because hidden costs are transfered to other parts of the
organization. Often the outsourcing company even participates in this sort
of thing -- gives upper management the servicies they have always had,
gives the rest of the company poor service.  I've seen this in the company
I work for.

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


Re: The Industry choice

2005-01-05 Thread Rob Emmons
> I'd go further.  It's not possible to force anyone to share, but the
> GPL aims to remove software from a system that instead aims to force
> people NOT to share. 

Well said.  

I do think the point is -- no one liscence fits all.  The GPL
is a great tool for those that write software for the purpose of sharing
with those that want to mutually share. Personally it has the feel of
justice to me -- but that's just me.

But of course it does not fit all needs and the politics and 
personalities of all developers and teams of developers. For example, RMS
developed the LGPL for other cases where it makes sense, and I think 
I read somewhere that RMS encouraged the release of BSD (is that right?) 
-- because that too is a help to free software in the end.

As for Python -- I think the best liscence depends on the goals of the
developers.  If you want python to be infrastructure, especially, for
applciation scripting -- it's kind of nice that it's BSD like or perhaps
LGPL, on the other hand if you want it to be free software focused -- 
then GPL would be better.  So there are many alternatives depending 
on goals.  You see this played out throughout the Open Source community.

In any case -- regardless of liscence -- I think Python is the greatest
and I have great respect for all those that have made it possible.

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


Re: How do I make Windows Application with Python ?

2005-01-06 Thread Rob Emmons
On Wed, 05 Jan 2005 04:49:05 -0800, Fuzzyman wrote:

> Couple of corrections - neither pypy nor starkiller are compilers.
> Starkiller isn't available yet and *may* be helpful in building
> compilers. Pyrex is an alternative language - a python/C hybrid that
> can be compiled.
> 
> If you want to release an application then innosetup, starkit, and upx
> might help - but they're not python related. You will need something
> like py2exe, cx_freeze, or mcmillan installer. (Which are specific to
> python - py2exe seems to be the more mature tool).
> 
> Alternatively you could consider 'Movable Python' - a frozen
> distribution of python that doesn't need isntalling. See
> http://sourceforge.net/projects/movpy

Great summary.  I was hoping someone would fill in the blanks.  I've been
interested in this area for some time -- but have not had time to look
into it more than keep a list of interesting projects I wanted to research
in the future.  I'll add your comments to my list.

Again, thanks.

Rob

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


Re: The best way to do web apps with Python?

2005-01-08 Thread Rob Emmons
> 
> 
> 
> 
> 
> 
> 
> What is 

Just FYI -- the post you posted was in HTML -- you might want to avoid
this in the future.  99% of all posts to news groups are in text, not
html.  Html is hard for everyone to read with normal news readers and not
usually of any extra value.  It's also more of a security risk to read it --
because there is more potential for exploitation.

Anyway, just thought I'd mention it if you didn't know.

Take care,
Rob
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Newbie: module structure and import question

2005-01-13 Thread Rob Emmons
> hi all,
> i have question on how to design a module structure.
> for example, i have 3 files.
> [somewhere]/main.py
> [somewhere]/myLib/Base/BaseA.py
> [somewhere]/myLib/ClassA.py
> 
> .
> It's fine when i run main.py.
> however when i run ClassA.py individually, it would fail in import
> statment since the import path is incorrect.
> I would like to know is something wrong in my design, or something i
> missed.

I think your issue is your module search path.  Take a look at the doc for
sys.path in the library reference.  These are the directories that python
searchies for modules.  Usually the "." directory is included in this
which makes python search the current working directory.  Your example
fails because your working directories are probably different when you ran
the two modules.  In any case always consider how you've setup sys.path
and your libraries and modules.

> Also, in practical usage, is that one class in one py file?

I'm not exactly clear what your asking -- but I think yor asking if you'd
normally only put one class in one py file.  My answer is no -- generally
you'd put many functions and classes in each py file.  Modules are high
level and should be used to create libraries essentailly -- this means
many fucntions and classes per module.

Rob


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


Re: Newbie: module structure and import question

2005-01-16 Thread Rob Emmons
> yes i know it's related to search path, but i don't know how to set it in a
> practical way (beside hard coding).
> my concern is, if i want to create a custom module/library, i don't know
> what py file will import it and where the working directory should be.

Regarding where the current working directory is -- on Linux your right,
you probably don't know where it is going to be.  On Windows -- you can
pretty much demand that users set up the launcher so that your python
program is opened in a specific location -- typically the root directory
of the installed package.  So in the windows situation -- if all your
components are in that package directory you can access everything via
relative roots.  Linux is not so easy -- I'll get to that.

On the other hand, if your installing a general directory library module
that your going to use from a variety of other programs, then you need to
have the installer setup things so other applications can find it.  The
standard way to do this is to use the distutils package that is part of the
python distribution to install these modules in a standard location which
should already be in the search path.  If you don't want to do that you
have to do something special:  on windows create a registry entry that
can be accessed and looked up probably, or setup the default python path
for your system (or user) to include the extra directories, or like GNOME
does on Linux -- create a script in the executable search path
that your program or installer can run -- and have it return the path you 
need. 

So on the application side, you'd find out the location of the library as
described above and set sys.path.  You can either do this at launch time
in your main program -- or you can have the installer hard code it at the
top of the main program.

This is not really any different then for example using shared libraries. 
You either need to install all of your modules in the search path to start
with or you need to modify the search path by some method.

There is one more thought -- if you want to find out where the python
module is in the file system -- there are sometimes ways to do this --
I've never done this but I have some notes somewhere about this.  This
might also be helpful in finding directories for example.  If your
interested in this -- maybe someone else here can remember?
 
> But if i put a set of classes in a py file as a module,  will it increase
> the dependency of each class?
> back to my example, of course, i can put BaseA and ClassA together in one py
> file. what should i do when i need to add one more class later, "ClassB",
> which also extend BaseA. Put it into the same file or in a new file? if put
> in in the same file, i think it should difficult to maintain versioning.

Versioning -- hmm.  Well I think it depends.  If ClassB is intended to be
a general capability that you want to add to to moduleA (the module with
BaseA and ClassA), then add it to moduleA but make the module upwardly
compatible.  If you want to track versions, then just keep old version
snapshots if you need to or use something like CVS to do it for you.  I'm
pretty basic so I keep old copies but try to make my general libraries
upwardly compatible if possible.

Of course on the other hand, if the new class classB has a special function
then I'd either create a new module, or I'd just include it into my main
program module, or some other application module.  To merge the functions
just import what you need into that module.  I for example often use "from
mymodule import *" which imports everything rather than the limited
imports you used -- nothing wrong with either, just a matter of taste. I
also often use "import" and write the full module name when I reference
things too. 

The point is -- I personally think one should look at modules as being
collections of functions, classes, and other constructs that form
librararies rather than putting each class and function in a separate
module.

Thanks,
Rob
-- 
http://mail.python.org/mailman/listinfo/python-list