Re: Python evolution: Unease

[michele . simionato]

Paul Rubin:
> I'm now running the Python
> that was included in Fedora Core 3 GNU/Linux, a complete OS distro on
> a DVD-ROM, containing about 3 gigabytes not including sources. And
> when a user installs 3 gigabytes of software from a DVD, they can
> reasonably expect that they've installed a complete system and
> shouldn't need to download anything additional to use all the
features
> of the programs on the DVD. Now the Fedora maintainers aren't Python
> gurus--people ask for Python so they did the obvious thing:
downloaded
> it, ran its installer, put the output into their distro, and said
"ok,
> Fedora has Python". That's all they should need to do to incorporate
> Python into Fedora. So it's up to the Python maintainers, not the
> Fedora maintainers or the user, to make sure that the Python distro
> has everything that users need, without further downloading.

Dunno about Fedora, I stopped using Red Hat just because they were
*not* using
the standard Python distribution, and the version they shipped was
cripped  in various
ways. There is nothing the Python developers can do if the OS vendors
choose to ship
modified Python distributions, with missing modules or splitted in n
separated packages
to download separately.

   Michele Simionato

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

% operation

[Daewon YOON]

Python 1.5.2 (#1, Jul  5 2001, 03:02:19)  [GCC 2.96 2731 (Red Hat 
Linux 7.1 2 on linux-i386
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> x=9
>>> y=4
>>> x%y
1
>>> for z in range(44):
... z%9
  File "", line 2
z%9
^
SyntaxError: invalid syntax


What's wrong with the above operation and how can I get the correct
modulo result with Python?
--
ZOO-<
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python evolution: Unease

[Ville Vainio]

> "Paul" == Paul Rubin  writes:

Paul> inclusion in some bigger distro.  E.g., I'm now running the
Paul> Python Python into Fedora.  So it's up to the Python
Paul> maintainers, not the Fedora maintainers or the user, to make
Paul> sure that the Python distro has everything that users need,
Paul> without further downloading.

To me, this seems to be the job for the Fedora maintainers, not Python
maintainers. If something essential is not in the distro the distro
maintainers have screwed up.

Paul> And that was just about Tkinter, for which good docs exist
Paul> but just don't happen to be in the distro.  How about

I think most people these days do a google search when they are
learning how to use a feature to get the whole story. It's often also
faster than finding the information in the bundled documentation -
even if the first google hit often happens to refer to the page with
the very documentation thu user would have looked up.

Paul> The book is very good, but having to go buy a proprietary
Paul> book is the opposite of what self-contained free software
Paul> documentation is supposed to mean.

I'm not sure the free software documentation is going to evolve to be
more self-contained; the exact opposite is more likely.

-- 
Ville Vainio   http://tinyurl.com/2prnb
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: % operation

[Christopher Koppler]

On Wed, 05 Jan 2005 15:36:30 +0900, Daewon YOON wrote:

> 
> Python 1.5.2 (#1, Jul  5 2001, 03:02:19)  [GCC 2.96 2731 (Red Hat 
> Linux 7.1 2 on linux-i386
> Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>  >>> x=9
>  >>> y=4
>  >>> x%y
> 1
>  >>> for z in range(44):
> ... z%9
>File "", line 2
>  z%9
>  ^
> SyntaxError: invalid syntax
> 
> 
> What's wrong with the above operation and how can I get the correct
> modulo result with Python?

There's nothing wrong with the operation, but it looks like you forgot to
indent your loop body (which the interactive shell doesn't automagically
do for you):

>>> for z in range(44):
... z%9
... 

[result snipped]

-- 
Christopher

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

Re: python intergration bus ?

[Jaco Smuts]

Tonino wrote:
Hi,
Just an interested question - I friend is testing a few JAVA
intergration bus's that will be used to intergrate his companies
services - I was wondering if there was a python intergration bus ?
other than maybe Pyro ?

Thanks
Tonino
 

Hello Tonino
There is a Python module (http://www.python.org/other/spread/) for 
Spread  (http://www.spread.org/ ) that is worth looking at.

There is also some work on a rpc module using spread. 
http://pyhacks.suddenthinks.com/spreadrpc/, never worked with this one 
though.

There is a great module for IBM's websphere mq, pymqi ( 
http://pymqi.sourceforge.net/) by L Smithson. This obviously depends on 
using the Commercial websphere MQ product though.

If web services are an option you can also have a look at
Clarence (http://clarens.sourceforge.net)
and / or
http://pywebsvcs.sourceforge.net/
I've previously stumbled accross some others at sourceforge, but this 
should get you started.

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

Re: Embedding a restricted python interpreter

[Paul Rubin]

Maurice LING <[EMAIL PROTECTED]> writes:
> I won't really count on that. In my opinions, which may be wrong,
> Python is not constructed to work in a sandbox like Java. Java does it
> by subjecting all classes that it loads through a security
> manager. What you seems to want is a Python to have Java applet-typed
> of restrictions.

Java has also been subject to years and years of attacks against the
sandbox, followed by patches, followed by more attacks and more
patches, so at this point it's not so easy to get past the security
any more.  But in the beginning it was full of bugs, and it may still
have bugs.  Python's rexec never attracted the attention of serious
attackers.

If you really have to do restricted execution, your best bet is to put
the sandbox in a separate process chrooted to where it can't mess with
the file system, and have it communicate with your application through
a socket.  I think there may be a way now to trap any system calls
that it attempts, too.  Of course none of that stops resource
exhaustion attacks, etc.

I don't have direct knowledge but it seems to me that there's
potential for the situation to improve under PyPy, whose interpreter
will have an extra layer where various bad operations can be trapped,
if my impression is correct.  So the long term prospects for secure
rexec may be better than the immediate ones.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Embedding a restricted python interpreter

[Craig Ringer]

On Wed, 2005-01-05 at 13:43, Maurice LING wrote:
> Rolf Magnus wrote:
> > Hi,
> > 
> > I would like to embed a python interpreter within a program, but since that
> > program would be able to automatically download scripts from the internet,
> > I'd like to run those in a restricted environment, which basically means
> > that I want to allow only a specific set of modules to be used by the
> > scripts, so that it wouldn't be possible for them to remove files from the
> > hard drive, kill processes or do other nasty stuff.
> > Is there any way to do that with the standard python interpreter?
> > 
> 
> I won't really count on that. In my opinions, which may be wrong, Python 
> is not constructed to work in a sandbox like Java.

That is my understanding. In fact, I'd say with Python it's nearly
impossible given how dynamic everything is and the number of tricks that
can be used to obfuscate what you're doing. Think of the fun that can be
had with str.encode / str.decode and getattr/hasattr .

I looked into this, and my conclusion ended up being "Well, I'm using
Python because I want it's power and flexibilty. If I want a secure
scripting environment, I should use something like Lua or Qt Script for
Applications instead."

AFAIK that's why the rexec() builtin is disabled - it's just not
practical to make a restricted Python execution environment.

> You can try to use 'exec' to run your scripts in a constructed 
> environment. For example,
> 
> global = {}
> local = {}
> 
> ... your stuffs 
> 
> statement = [] # to hold the script to run
> 
> for line in statement:
>   exec statement in global, local
> 
> global and local are the global and local namespaces respectively. 
> Although it had been explained to me before but I can't recall the 
> details of how it works. In gist, you may be able to craft a global and 
> local environment for your script to run in.


> I do not know if it is possible to disable or override 'import'..

You can do a fair bit to it by wrapping/replacing __builtin__.__import__
. Preventing people from getting around what you've done, though... not
sure.

--
Craig Ringer

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

Re: Frameworks for "Non-Content Oriented Web Apps"

[mirnazim]

---
Well, I think a we can say that a framework for "Non Content Oriented
Web Apps" is something that can help in
(*) creating N tier data aware web applications
(*) creating data-aware controls (forms etc.).
(*) managing different data sources
transparently(ZODB,MySQL,PostGreSQL, etc).
(*) de-coupling UI, Business Logic and Data Sources from each other.
(*) provide transaction management facilities(am I asking too much).
---

I think there is something more to the above points than just a
construction of web interfaces like forms etc. I never said that it
should be something really big(like Zope). I have looked at Quixote and
is really cool. But I think we need something more than just a forms
processing libary.

Alext Martelli:
>Once you're on a multilayer track, whether the presentation
>is on the web or on some other UI should just be an
>issue for the very last layer(closest to the user).

I agree in an multi-tier application UI is the last layer issue, but
the point here is that there should be some thing that can make
connection of web controls to various data sources easy. Of course this
is just UI issue of many others that are not UI issues.

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

Re: Embedding a restricted python interpreter

[Maurice LING]

Rolf Magnus wrote:
Hi,
I would like to embed a python interpreter within a program, but since that
program would be able to automatically download scripts from the internet,
I'd like to run those in a restricted environment, which basically means
that I want to allow only a specific set of modules to be used by the
scripts, so that it wouldn't be possible for them to remove files from the
hard drive, kill processes or do other nasty stuff.
Is there any way to do that with the standard python interpreter?
I won't really count on that. In my opinions, which may be wrong, Python 
is not constructed to work in a sandbox like Java. Java does it by 
subjecting all classes that it loads through a security manager. What 
you seems to want is a Python to have Java applet-typed of restrictions.

You can try to use 'exec' to run your scripts in a constructed 
environment. For example,

global = {}
local = {}
... your stuffs 
statement = [] # to hold the script to run
for line in statement:
exec statement in global, local
global and local are the global and local namespaces respectively. 
Although it had been explained to me before but I can't recall the 
details of how it works. In gist, you may be able to craft a global and 
local environment for your script to run in.

I do not know if it is possible to disable or override 'import'..
maurice
--
http://mail.python.org/mailman/listinfo/python-list

Re: coding conventions, PEP vs. practice

[Terry Reedy]

"Robert Kern" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> Note the first sentence of the PEP: "This document gives coding 
> conventions for the Python code comprising the standard library for the 
> main Python distribution."

Even that should say "from now on".  Some library code was written before 
PEP8.  And Guido has so far discouraged purely stylistic patches to 
functioning code (because of the risk on introducing bugs where none 
exist).

TJR





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

Re: Python evolution: Unease

[Paul Rubin]

"alex23" <[EMAIL PROTECTED]> writes:
> It's called "having an opinion". "Good" documentation does its job, if
> noone else thought it was poorly documented then to them it wasn't.

Obviously other people thought Tkinter is poorly documented in the
Python distro, since the Python library manual says so itself and
invites people to look at external references instead.

> > Software advocacy, which Python has an awful lot of, [...]
> 
> Unjustifiable claims, which your postings have an awful lot of...

I've justified every claim I've made.

> You've done nothing but kvetch about how others aren't providing you
> with what you need. Let's face it, people like you are never going
> to take the initiative and actually contribute something when you're
> already quite comfortable sponging off the efforts of others and
> hiding behind claims of advocacy whenever anyone questions your own
> motivations.

I'm not one of the Python developers, I'm just a user, I have my own
projects that I spend my time on.  I like the idea of using Python in
some of those projects.  Python advocacy revolves around encouraging
people to use Python in their projects, without having to be Python
developers themselves.  Python advocates say "Python does what you
need, so use it".  That's supposed make Python sound attractive.  If
the real truth is "Python does something sort of related to what you
need, so if besides your own project that you need to finish, you are
willing to stop in the middle and take on some additional projects of
improving Python, it can end up being useful for your task", that's a
lot less attractive.

I'm happy to use Python, as it is, for various kinds of noncritical
and throwaway tasks.  For critical projects I'm looking for tools that
work (e.g. Linux, Apache, GCC), not "it's open source, go fix it".
But just one or two days ago, various people on this group were urging
me to do a critical project in Python instead of Java.  I like Python
enough to get into these romantic quarrels with it (which is what
you're seeing now) and feel pretty cold toward Java.  But while Java's
libraries are poorly designed, their implementations tend to be quite
complete, while Python's are well-designed but often incompletely
implemented.  And so with Java, I feel much less likely to look in the
manual and note the existence of some feature and plan to use it, only
to find out after it's too late, that the feature's implementation is
missing some crucial functionality that would be a lot of work to add.
(Then there's issues with the languages themselves, that are separate).

> In short: grow up and just write the damn documentation.

In short, I should grow up and quietly ignore a lot of Python advocacy
as being groundless and just use Python for limited purposes.  But
what I want instead is for Python itself to grow up, and do things
properly instead of half-assedly.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python evolution: Unease

[Paul Rubin]

Peter Hansen <[EMAIL PROTECTED]> writes:
> The key distinction is that "well-documented" is clearly
> a judgment call, a personal opinion,

No it's not.  If a program has significant modules with complicated
public API's and no documentation, it's poorly documented in an
absolute sense.  A well-documented program includes docs for all
the public API's.

> So those who claim Python is well-documented are the ones who
> should improve the documentation, but those claiming that
> the documentation is poor should feel no responsibility to
> make the improvements?

Yes, precisely so.  Like if someone says "I've written this fantastic
math package, it's fast and accurate and solves every problem
perfectly, let's start a newsgroup about how to convince our PHB's to
use it and why it's so much better than every other math package
that's ever been written", and I try the package and it says that
2+2=5 and I report that bug, I've made a constructive comment and have
no further responsibility.  I've also shown that the program doesn't
live up to its claims and people wanting to do real work with it
should watch out.  If the developers want to keep making the grand
claims, they should fix the bug.  If they want to say "this package is
technically cool but gets some answers wrong, maybe you don't want to
do anything serious with it but it's fun to play with", that's
different.  But there's a constant current in clpy of "Python is great
for everything, our PHB's should all embrace it, it supports protocols
X, Y, and Z and is great for that kind of application" when those
protocols turn out to be only half-implemented, or "it's
well-documented" when the manual turns out to be only half-complete.
And the responses I see sound almost like "2+2=5 is an accurate
answer, and if you think it's not close enough, it's open source, so
fix it".

If you want to see a really well-done (at least in parts, and also
poorly documented but not making claims to the contrary) Python
program, take a look at Twisted Matrix.  It reimplements any number of
features that are already in Python.  An early version of the docs
explained the reason.  It said something like "it may look like we're
re-inventing the wheel, but we have no choice, since the existing
wheel is square and made of glue".

> Does this make any sense to you?  To me, *this* is the nonsense.

I don't see any nonsense.  People who make claims about a program are
the ones responsible for the truth of the claims.  Saying anyone else
is responsible is bizarre.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: what is lambda used for in real code?

[Adam DePrince]

On Sat, 2005-01-01 at 11:42, Steve Holden wrote:
> Adam DePrince wrote:
> [...]
> > 
> > In sort, we must preserve the ability to create an anonymous function
> > simply because we can do so for every other object type, and functions
> > are not special enough to permit this special case.
> > 
> And you'd create an anonymous type how, exactly?
> 

Okay, you got me.   Let me rephrase:

... functions, types, classes and moduless are not special enough ... 

I had things like, um, strings, lists, integers, etc in mind.

- adam

> regards
>   Steve
> -- 
> Steve Holden   http://www.holdenweb.com/
> Python Web Programming  http://pydish.holdenweb.com/
> Holden Web LLC  +1 703 861 4237  +1 800 494 3119
Adam DePrince 


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

Re: what is lambda used for in real code?

[Adam DePrince]

On Fri, 2004-12-31 at 22:09, Terry Reedy wrote:
> "Adam DePrince" <[EMAIL PROTECTED]> wrote in message 
> news:[EMAIL PROTECTED]
> > In sort, we must preserve the ability to create an anonymous function
> > simply because we can do so for every other object type, and functions
> > are not special enough to permit this special case.
> 
> Please show me how to create an anonymous type, module, or class, 

You can create anonymous instances of classes and types.  The actual
type, module or class .. well, that is another special case that isn't
special enough ... but that is somewhat beyond the scope of this
thread.  I've seen a number of responses similar to this; I feel that
the lack of anonymous classes, types and modules are flaws with the
language that should be fixed, not used to justify introducing another
flaw.  

It is my humble opinion that a good language design is completely
orthogonal.  The curse of anonymity in the language can be "cured" at a
management/specification level by requiring the use of the name space. 
The alternative, the removal of anonymous functions, adds a "special
case" and dumbs down the language.  Personally, I'd like to see Python
evolve in the direction of ML instead of Visual Basic.

There are actually times when I've wanted anonymous classes.  Very
often, I've written code that accepts as a parameter, a class.  Of
course, the code instantiates this class with the expectation that it
provides a particular interface.  And sometimes, it would have been nice
to, in a single invocation of such a function, change a single method of
the class before passing it.  In a sense, I've written code for which a
class or type equivalent to a lambda would actually have been really
nice.

> especially with an expression.  Number, sequences, and dicts have easily 
> printable values.  Functions, like classes and module do not*, so 

So do lambdas, classes, types, etc.  And I've encountered a good many
lists and dicts that don't qualify as "easily printable."   Quite
frankly, it seems a bit capricious to *require* the use of the name
space on the basis of the similarity between the repr of the object and
line noise.

And here is a counter example ... this def fits nicely on one line:

Python 2.4 (#1, Dec 27 2004, 15:19:19)
[GCC 3.4.1] on linux2
>>> def a( b ): return b+1
...
>>> a( 2 )
3
>>>



> definition names act as a standin and as a pointer to the source code that 
> produced the object.  If functions are not special relative to classes and 
> modules, which is the grouping they belong with, then we should get rid of 
> lambda ;-)
> 
> *Now that memory is 'cheap', someone recently proposed that code objects 
> (and hence functions) get .source attribute.  Maybe, someday...

The .source attribute could be free from a memory consumption
perspective if the source -> byte code conversion is reversible. 

> 
> Terry J. Reedy
Adam DePrince 


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

Re: what is lambda used for in real code?

[Adam DePrince]

On Fri, 2004-12-31 at 17:36, Steven Bethard wrote:
> Adam DePrince wrote:
> > Lets not forget the "real reason" for lambda ... the elegance of
> > orthogonality.   Why treat functions differently than any other object? 
> > 
> > We can operate on every other class without having to involve the
> > namespace, why should functions be any different?
> 
> Yup.  I think in most of the examples that I didn't know how to rewrite, 
> this was basically the issue.  On the other hand, I do think that 
> lambdas get overused, as indicated by the number of examples I *was* 
> able to rewrite.[1]
> 
> Still, I have to admit that in some cases (especially those involving 
> reduce), I wish the coder had named the function -- it would have given 
> me a little bit more documentation as to what the code was trying to do.

This is a long standing philosophical issue that really shouldn't impose
itself on the language.  Do you document, and risk that the
documentation doesn't match the code, or do you use the code itself as
documentation.  

Leaving, or even expanding upon, anonymous functions permits the
programmer to choose their stance in the above debate; you can still
write

# If I had to give this function a name, it would be ... 

before or after the lambda to elect the former option.  The removal of
anonymous functions, however, forces the former option.   Even if option
latter is misguided, one of the guiding principles of Python is that we
are all consenting adults free to do dumb things.

- Adam

Adam DePrince 


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

Tkinter, iconbitmap and Windows XP

[John Fouhy]

Hi all,

I have been attempting to change the title bar icon of my Tkinter
applications in Windows XP.  Chasing round in google, I discovered:
 - This is a common difficulty.
 - There aren't any good answers.

Eventually, I stumbled across a link to this:
http://www.tcl.tk/man/tcl8.4/TkCmd/wm.htm#M18

Here is the significant information:
 "On the Windows operating system, an additional flag is supported: wm
iconbitmap window ?-default? ?image?. If the -default flag is given,
the icon is applied to all toplevel windows (existing and future) to
which no other specific icon has yet been applied. In addition to
bitmap image types, a full path specification to any file which
contains a valid Windows icon is also accepted (usually .ico or .icr
files), or any file for which the shell has assigned an icon. Tcl will
first test if the file contains an icon, then if it has an assigned
icon, and finally, if that fails, test for a bitmap."

The Tkinter source (Python 2.3.4) includes this:

def wm_iconbitmap(self, bitmap=None):
"""Set bitmap for the iconified widget to BITMAP. Return
the bitmap if None is given."""
return self.tk.call('wm', 'iconbitmap', self._w, bitmap)

I modified this, to look like:

def wm_iconbitmap(self, bitmap=None, default=None):
"""Set bitmap for the iconified widget to BITMAP. Return
the bitmap if None is given."""
if default:
return self.tk.call('wm', 'iconbitmap', self._w,
'-default', default)
else:
return self.tk.call('wm', 'iconbitmap', self._w, bitmap)

The following code now does exactly what you would like it to:

#
from Tkinter import *

tk = Tk()
tk.iconbitmap(default='foo.ico')
Label(tk, text='This window now has a custom icon.').pack()

t = Toplevel(tk)
Label(t, text='This one has the same custom icon.').pack()

tk.mainloop()
#

I hope this is helpful to people...

(now to see if I can figure out how to submit a patch in Sourceforge)

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

Re: Python evolution: Unease

[alex23]

Paul Rubin wrote:
> The Python advocates who claim that Python is well-documented and
take
> exception to when someone say it isn't.  Their idea of "it's
> well-documented" seems to be "if there's parts that you think are
> poorly documented, feel free to document it".  What kind of nonsense
> is that?

It's called "having an opinion". "Good" documentation does its job, if
noone else thought it was poorly documented then to them it wasn't.

The only person who knows how the current documentation is
unsatisfactory to you is *you*.

The mistake being made here by the OS community is the assumption,
based on their own personal experiences, that others will take the
absence of something as a challenge to fill it themselves, serving the
dual role of obtaining what they need for their own purposes AND
providing it for the purposes of others. It's a mistaken assumption
because for most people it's easier to gripe that someone else, oh
let's say "advocates", should be doing it for you.

> "Python code runs just as fast as C code.  If you think it's
> slower, feel free to speed it up".

The objective, qualifiable speed of Python has *what* exactly to do
with the subjective, interprative assessment of the Python
documentation?

> "Python's standard library includes a database module.  If it isn't
there,
> feel free to add one".

Which part of the open source movement do you just not get?

> "Programming in Python cures cancer.  If your cancer doesn't clear up
> when you code in Python, feel free to submit a patch".

Wow, you quickly ran out of points of blind Pythonic advocation, didn't
you?

> Software advocacy, which Python has an awful lot of, [...]

Unjustifiable claims, which your postings have an awful lot of...see
how easy it is to characterise someones position in the negative? See
how pointless it is for useful dialogue?

You've done nothing but kvetch about how others aren't providing you
with what you need. Let's face it, people like you are never going to
take the initiative  and actually contribute something when you're
already quite comfortable sponging off the efforts of others and hiding
behind claims of advocacy whenever anyone questions your own
motivations.
In short: grow up and just write the damn documentation.

- alex23 -

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

Re: The Industry choice

[Paul Rubin]

"Rob Emmons" <[EMAIL PROTECTED]> writes:
> 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.

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.  As the MPAA knows, people do want to share, and
forcing them not to do so is impossible without turning the world into
a police state.  Maybe if Python were GPL, then Bulba wouldn't use it,
but since it's not GPL, some people find themselves much less willing
to contribute to it than if it were GPL.  (I myself contribute bug
reports and maybe small patches, but resist larger projects since
there are GPL'd things that I can do instead).  So catering to the
wishes of Bulba and Microsoft may actually be impeding Python
development.  Yes, there are some people selfless enough to do long
and difficult unpaid software tasks so that Bulba and Bill G can get
richer by stopping people from sharing it, but others of us only want
to do unpaid programming if we can make sure that the results stay
available for sharing.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python evolution: Unease

[Peter Hansen]

Paul Rubin wrote:
Jeremy Bowers <[EMAIL PROTECTED]> writes:
So, nobody should have to write the docs because they should already be
there, but "somebody" should have to write the docs?
You need to think more clearly about the pronouns you are slinging around.
Who is this "they" that should write the docs?
The Python advocates who claim that Python is well-documented and take
exception to when someone say it isn't.  Their idea of "it's
well-documented" seems to be "if there's parts that you think are
poorly documented, feel free to document it".  What kind of nonsense
is that?  "Python code runs just as fast as C code.  If you think it's
slower, feel free to speed it up".  "Python's standard library
includes a database module.  If it isn't there, feel free to add one".
"Programming in Python cures cancer.  If your cancer doesn't clear up
when you code in Python, feel free to submit a patch".
I think you're throwing out strawman arguments here.
The key distinction is that "well-documented" is clearly
a judgment call, a personal opinion, while the others
are all measurable absolutes.  (The "as fast as C" one borders
on being an opinion, since most people actually say things that
mean something more like "as fast as I need it to, so C has no
advantage".)
Saying, in effect, as they are, "Python's docs are well enough
documented for my purposes and, I believe, for those of many
other people" certainly isn't nonsense, and saying "and if you
don't agree you should consider improving them yourself
instead of asking me or others who feel as I do" is certainly
not nonsense.
And no, I don't feel a responsibility to do the missing work, since
I'm not the one making those advocacy claims.
So those who claim Python is well-documented are the ones who
should improve the documentation, but those claiming that
the documentation is poor should feel no responsibility to
make the improvements?
Does this make any sense to you?  To me, *this* is the nonsense.
-Peter
--
http://mail.python.org/mailman/listinfo/python-list

Re: The Industry choice

[Ian J Cottee]

Peter Hansen wrote:
I know that I've started many one-man projects over the years,
and only slowly (I'm a little thick, you see) came to realize
that while it's incredibly easy to start something, seeing it
through to the end is rather more difficult.
At this point, perhaps largely as a result of a new world-view
inspired by the agile movement, I rarely start anything...
and when I do, it's driven by a strong, recurring need, and I
only do just enough to meet that need, in the simplest way
I can find.  (Often, that ends up not involving a computer.)
So here we are, in our wisdom. Never starting anything grandiose for 
fear of failure :). Personally I'm trying to get back some of that old 
stupidity but I'm very thick :)

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

Re: The Industry choice

[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: Dr. Dobb's Python-URL! - weekly Python news and links (Dec 30)

[Carl Banks]

Skip Montanaro wrote:
> I started to answer, then got confused when I read the docstrings for
> unicode.encode and unicode.decode:
[snip]


It certainly is confusing.  When I first started Unicoding, I pretty
much stuck to Aahz's rule of thumb, without understanding this details,
and still do that. But now I do undertstand it.

Although encodings are bijective (i.e., equivalent one-to-one
mappings), they are not apolar.  One side of the encoding is
arbitrarily labeled the encoded form; the other is arbitrarily labeled
the decoded form.  (This is not a relativistic system, here.)  The
encode method maps from the decoded to the encoded set.  The decode
method does the inverse.

That's it.  The only real technical difference between encode and
decode is the direction they map in.

By convention, the decoded form is a Python unicode string, and the
encoded form is the byte string.

I believe it's technically possible (but very rude) to write an
"inverse encoding", where the "encoded" form is a unicode string, and
the decoded form is UTF-8 byte string.

Also, note that there are some encodings unrelated to Unicode.  For
example, try this:

. >>> "abcd".encode("base64")
This is an encoding between two byte strings.


-- 
CARL BANKS

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

Re: Python evolution: Unease

[Paul Rubin]

Jeremy Bowers <[EMAIL PROTECTED]> writes:
> So, nobody should have to write the docs because they should already be
> there, but "somebody" should have to write the docs?
> 
> You need to think more clearly about the pronouns you are slinging around.
> Who is this "they" that should write the docs?

The Python advocates who claim that Python is well-documented and take
exception to when someone say it isn't.  Their idea of "it's
well-documented" seems to be "if there's parts that you think are
poorly documented, feel free to document it".  What kind of nonsense
is that?  "Python code runs just as fast as C code.  If you think it's
slower, feel free to speed it up".  "Python's standard library
includes a database module.  If it isn't there, feel free to add one".
"Programming in Python cures cancer.  If your cancer doesn't clear up
when you code in Python, feel free to submit a patch".

Software advocacy, which Python has an awful lot of, involves
extolling the virtues of a program as it exists in the present.  Not
as it could potentially exist if someone hypothetically added a bunch
of work that hasn't yet been done.  Python is good software, but its
advocates are making claims that Python itself doesnt live up to.

And no, I don't feel a responsibility to do the missing work, since
I'm not the one making those advocacy claims.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python evolution: Unease

[Jeremy Bowers]

On Tue, 04 Jan 2005 17:12:04 -0800, Paul Rubin wrote:
> Irrelevant, the issue isn't what docs can be written if someone wants to
> do it, it's what docs are actually already there

> I just see various other free software projects as
> trying to live up to higher standards and I think Python should aspire to
> the same thing.

So, nobody should have to write the docs because they should already be
there, but "somebody" should have to write the docs?

You need to think more clearly about the pronouns you are slinging around.
Who is this "they" that should write the docs? (Yes, I know you didn't use
that exact word but the concept is clearly there.) And what right do you
have to demand this action from "they"? Are you willing to pay me to do it?



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

Re: python intergration bus ?

[Peter Hansen]

Tonino wrote:
Just an interested question - I friend is testing a few JAVA
intergration bus's that will be used to intergrate his companies
services - I was wondering if there was a python intergration bus ?
other than maybe Pyro ?
I'm not sure what that term means, and I don't believe
it is a widely recognized term in the field of programming.
I can guess, or Google for it, but I suspect most of
what I find wouldn't be what you meant...
Perhaps you could define what "integration bus" means to
you so we could understand what your question really is?
(And please do it without just referencing some Java
product which none of us will know about.)
Thanks,
-Peter
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python evolution: Unease

[Skip Montanaro]

Paul> Skip Montanaro <[EMAIL PROTECTED]> writes:
>> Start writing (or reorganizing).  Folks, this is open source.  I'm
>> sure by the traffic on the list most people here know how to write.

Paul> Irrelevant, the issue isn't what docs can be written if someone
Paul> wants to do it, it's what docs are actually already there.  

How do you think we got the docs we already have?  Somebody wrote them.  If
there aren't enough docs or if they have mistakes, then somebody has to
correct them.  I'm just suggesting that more people put their money where
they mouths are so-to-speak.

>> This being the Internet and all, it's not clear that referencing
>> external documentation is somehow worse than incorporating it
>> directly into the distribution.

Paul> The same thing could be said for software.  So why not eliminate
Paul> the Python library and let everyone download each module
Paul> separately?  Because it's bogus is why.
Paul> It really does matter whether something is included or just
Paul> referenced.

Okay, then start doing the work necessary to incorporate that stuff into the
core.  Get Fredrik to say "okay" to including his Tkinter docs, then do what
it takes to incorporate it.  The fact that Fredrik can check those docs in
himself but hasn't after several years suggests that he prefers the status
quo for one or more reasons.

I'm not saying references are perfect.  I'm saying that given the time
constraints of the existing developer crowd and the relative priority of
various open tasks that folding in external documentation hasn't risen to
the top of the queue yet.  The best way to make that happen is for it to be
your highest priority and then for you to make it happen.  That's a
longer-winded way to say what I meant with "this is open source".

Paul> And that was just about Tkinter, for which good docs exist but
Paul> just don't happen to be in the distro.  How about something like
Paul> SocketServer, for which no reasonable docs exist at all?  

I'm at a loss.  Is there something about this quote taken directly from the
section of the library reference manual entitled "Undocumented Modules" that
is unclear?

Here's a quick listing of modules that are currently undocumented, but
that should be documented.  Feel free to contribute documentation for
them!  (Send via email to [EMAIL PROTECTED])

The list there is itself incomplete.

There is a reference manual section for SocketServer, btw:

http://www.python.org/doc/current/lib/module-SocketServer.html

If that needs examples or corrections or is incomplete, feel free to submit
a patch to either SourceForge or by email to [EMAIL PROTECTED]

Paul> I'm not trying to bash Python, which is excellent in many ways, or
Paul> I wouldn't be using it.  I just see various other free software
Paul> projects as trying to live up to higher standards and I think
Paul> Python should aspire to the same thing.

I'm sorry, I don't know quite how to respond to that.  Sure, I imagine there
are other communities that do it better.  I've seen PHP mentioned here
recently, and have direct experience with CPAN (and actually like it pretty
well).

Look, I don't have much free time, and what free time I do have I mostly
spend moonlighting on other software (much to my wife's chagrin).  I imagine
most of the other people who contribute to the Python distribution are
similarly time-afflicted.  Here are a couple ideas:

1.  Do you have more money than time?  Donate a few bucks to the PSF:

http://www.python.org/psf/

Someone will probably do #2.

2.  Do you have more time than money?  Write a proposal to the PSF to
implement/improve/polish off some aspect of the distribution:

http://www.python.org/psf/

3.  Got some free time and don't care about a few extra bucks?  Check
out how to contribute to Python:

http://www.python.org/dev/

>> As for stuff that exists in PEPs and release notes, they should
>> already all have the necessary copyright (either they were placed in
>> the public domain or they are already part of the Python
>> distribution) to allow you do just check out a CVS tree, make the
>> necessary edits and either check the files back in or submit a patch
>> to SourceForge.

Paul> And about that full featured Python web browser and native-code
Paul> Python compiler, all you have to do is go write it.  Come on.

Where did I say to go write a browser or a native-code Python compiler?  If
that's your bag you can try resurrecting something Grail-like (browser) or
contribute time top PyPy or Psyco.  When I said "write", I literally meant
write, as in English text.

Paul> Having to piece together info from a dozen obscure and
Paul> inconsistent PEP's and stuff in the CVS tree and source comments
Paul> is not what most people think of as "documentation".
Paul> Documen

Re: modpython, apache and windows

[Bob Van Zant]

Fortunately most of the Python-for-the-web implementations do not follow
closely to the PHP paradigm of web-based programming. There are some,
like PSP, that more closely model what PHP does.

It is not uncommon to have something like index.py which does hardly
anything except fire up a framework that takes care of parsing the rest
of the URI and passing control over to the proper script. Using some
relatively cryptic features of Apache you can hide the fact that
everything goes through index.py (mod_rewrite).

You might be interested in the Aquarium web framework
(http://aquarium.sf.net). It provides a very flexible, mature framework
for developing web applications including a session manager, a form
validation library and a form generation "widget" among many other
things. The documentation on the official aquarium site is fairly
cryptic but I have written a few more intro documents at
http://bob.norcalttora.com including an example excerpt of an httpd.conf
file that will configure mod_python to work with Aquarium including the
previously mentioned apache rewrite rules.

I have never tried to get this working in windows but if you get it
working I'd be very interested in seeing what changes you had to make.
I'm willing to help you along the way.

Not really sure how else to help you at this point. The index.py that
you had working was probably on the right track.

-Bob


On Wed, 2005-01-05 at 01:12 +, Sam wrote:
> Hi All,
> 
> I am interested in learning python since I am hearing more and more 
> about python for use in web development
> 
> I am starting out on python, with knowledge of PHP some perl
> 
> my current hurdle is setting up either apache 1 or 2 with python 2.3.3 I 
> have installed modpython fine
> 
> which informed me that I need to make some configuration changes to 
> httpd.conf
> 
> I have not had it working yet, searches on the web give conflicting 
> suggestions and so far has confused me
> 
> some forums mention spyce and serving .spy files
> 
> so far I  one explanation worked in that a .py file was parsed but I had 
> to set the name of the actual file within apache.conf
> this seems strange
> 
> thanks in advance >> SS
> 
> 
> -- 
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.298 / Virus Database: 265.6.7 - Release Date: 30/12/2004
> 

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

Re: coding conventions, PEP vs. practice

[Skip Montanaro]

Roman> These frameworks are using "mixedCase" but PEP8 suggests
Roman> "lower_case_with_underscores" except "in contexts where that's
Roman> already the prevailing style" which is not the case here IMHO.

Roman> So, are there any specific reasons for breaking the rules here? 

Since they aren't really rules, people and organizations can and do use
their own personal preferences when naming things.

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

Re: coding conventions, PEP vs. practice

[Robert Kern]

Roman Roelofsen wrote:
Dear python-list,
while looking for some coding conventions for python programs, i found the 
PEP8 at http://www.python.org/peps/pep-0008.html. It defines the rules very 
well and leaves no space for interpretations. I guess thats a good thing :-) 
But when i started playing a bit with python and frameworks like Zope, 
Webworks, etc., i noticed, that a lot frameworks are using a different 
convention for methodnames. 
Note the first sentence of the PEP: "This document gives coding 
conventions for the Python code comprising the standard library for the 
main Python distribution."

It is not intended to be a style guide for all Python code although many 
groups do adopt all or part of it for their own style guides.

--
Robert Kern
[EMAIL PROTECTED]
"In the fields of hell where the grass grows high
 Are the graves of dreams allowed to die."
  -- Richard Harter
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python evolution: Unease

[Paul Rubin]

Skip Montanaro <[EMAIL PROTECTED]> writes:
> Start writing (or reorganizing).  Folks, this is open source.  I'm
> sure by the traffic on the list most people here know how to write.

Irrelevant, the issue isn't what docs can be written if someone
wants to do it, it's what docs are actually already there.  I mean
every shortcoming anyone could raise about Python or anything else
could have the same answer, "it's open source, go fix it".  The
question is what does the existing stuff do.

> In the case of Tkinter, you should probably get the okay of the
> authors of various external docs before incorporating them into the
> Python docs, 

If such permission is available then the external docs should just
be dropped into the distro.  

> but note that several Tkinter-related documents are referenced
> directly from the Tkinter module docs:

Irrelevant, the Python docs mean the ones that are included, not the
ones that are merely referenced.

> This being the Internet and all, it's not clear that referencing external
> documentation is somehow worse than incorporating it directly into the
> distribution.

The same thing could be said for software.  So why not eliminate the
Python library and let everyone download each module separately?
Because it's bogus is why.  It really does matter whether something is
included or just referenced.  That's what "batteries included" is
supposed to be about--you get ONE package and it's supposed to have
everything you need without having to go forage for additional
components.  It matters because most users shouldn't need to care
about the Python distro at all, since they got Python through its
inclusion in some bigger distro.  E.g., I'm now running the Python
that was included in Fedora Core 3 GNU/Linux, a complete OS distro on
a DVD-ROM, containing about 3 gigabytes not including sources.  And
when a user installs 3 gigabytes of software from a DVD, they can
reasonably expect that they've installed a complete system and
shouldn't need to download anything additional to use all the features
of the programs on the DVD.  Now the Fedora maintainers aren't Python
gurus--people ask for Python so they did the obvious thing: downloaded
it, ran its installer, put the output into their distro, and said "ok,
Fedora has Python".  That's all they should need to do to incorporate
Python into Fedora.  So it's up to the Python maintainers, not the
Fedora maintainers or the user, to make sure that the Python distro
has everything that users need, without further downloading.

And that was just about Tkinter, for which good docs exist but just
don't happen to be in the distro.  How about something like
SocketServer, for which no reasonable docs exist at all?  There's no
way to figure out how to use it without reading the source.  Or the
socket library, whose docs say to go buy a book by W. Richard Stevens.
The book is very good, but having to go buy a proprietary book is the
opposite of what self-contained free software documentation is
supposed to mean.

I'm not trying to bash Python, which is excellent in many ways, or I
wouldn't be using it.  I just see various other free software projects
as trying to live up to higher standards and I think Python should
aspire to the same thing.

> As for stuff that exists in PEPs and release notes, they should
> already all have the necessary copyright (either they were placed in
> the public domain or they are already part of the Python
> distribution) to allow you do just check out a CVS tree, make the
> necessary edits and either check the files back in or submit a patch
> to SourceForge.

And about that full featured Python web browser and native-code Python
compiler, all you have to do is go write it.  Come on.

Having to piece together info from a dozen obscure and inconsistent
PEP's and stuff in the CVS tree and source comments is not what most
people think of as "documentation".  Documentation means I can look in
the manual and the info is right there, properly referenced in the
table of contents and in the proper section for that type of language
feature, unified with the rest of the docs.

> In the documentation arena, I think more thought should probably be
> given to producing online docs that can be directly annotated, thus
> further reducing the barrier to more complete documentation (and
> more updates).  Take a look at latex2html, propose or implement
> changes, or just rewrite the damn thing in Python.  I think
> latex2html is probably a recurring nightmare for Fred Drake.

I've personally been happy with Texinfo for other kinds of docs and
would consider it easier to deal with than latex2html.  It might even
be feasible to edit it in a wiki, so anyone could improve it easily.
Another idea is web-based doc comments like PHP and MySQL have, so the
doc editors can incorporate the info from the comments in subsequent
doc releases.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python evolution: Unease

[Skip Montanaro]

Terry> Numarray has a record array type.  If there is not one publicly
Terry> available, perhaps you could write a CSV file to record-array
Terry> slurper and contribute it to the Recipes site or maybe even the
Terry> CSV module.

-1 on putting such a beast into the CSV module, especially if, as it seems,
it would rely on something outside the core.

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

Re: coding conventions, PEP vs. practice

[Roy Smith]

Roman Roelofsen <[EMAIL PROTECTED]> wrote:
> These frameworks are using "mixedCase" but PEP8 suggests 
> "lower_case_with_underscores" except "in contexts where that's already the 
> prevailing style" which is not the case here IMHO.
> 
> So, are there any specific reasons for breaking the rules here? I think 
> consistent conventions are very important. Being a Java developer in the last 
> couple of years, i learned how practical it can be to have only one naming 
> style. 

My personal preference is camelCase over words_with_underscores, but 
fundamentally, this is a bit of a religious issue.  Pick a style, and go 
with it.

If you're working on existing code, go with the prevailing style.  If 
you're working in a group, pick a common style and go with the group 
decision.  Of all the software engineering issues to worry about, this 
is pretty low on the list.
-- 
http://mail.python.org/mailman/listinfo/python-list

modpython, apache and windows

[Sam]

Hi All,
I am interested in learning python since I am hearing more and more 
about python for use in web development

I am starting out on python, with knowledge of PHP some perl
my current hurdle is setting up either apache 1 or 2 with python 2.3.3 I 
have installed modpython fine

which informed me that I need to make some configuration changes to 
httpd.conf

I have not had it working yet, searches on the web give conflicting 
suggestions and so far has confused me

some forums mention spyce and serving .spy files
so far I  one explanation worked in that a .py file was parsed but I had 
to set the name of the actual file within apache.conf
this seems strange

thanks in advance >> SS
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.298 / Virus Database: 265.6.7 - Release Date: 30/12/2004
--
http://mail.python.org/mailman/listinfo/python-list

Re: Optional Static Typing: Part II

[Carl Banks]

John Roth wrote:
> http://www.artima.com/weblogs/viewpost.jsp?thread=86641

Nitpicking: I don't think he's necessarily in good company w.r.t. types
vs classes.  Take Ada, for example.   In Ada, a class is a set of types
(in particular, the type and all its subtypes), which is kind of the
opposite way Guido claims to see it.  Not the Ada is relevant, and not
that there is ever any agreement on terminology in computer science,
but still.

Based on their English language meanings, I would tend to agree with
Ada's terminology.  But, based on how the terminology developed for
computer languages (especially under the influence of C++), it seems
that most people would regard class as more of an implementation.

Another question: can anyone think of something an interface statement
could syntactically that an interface metaclass couldn't?  I couldn't
think of anything, based on the description, and it's not like th BDFL
to throw out keywords for things that current syntax can handle.  It
leads me to suspect that maybe he has something up his sleeve.  Hmm.
-- 
CARL BANKS

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

Re: Embedding a restricted python interpreter

[Paul Rubin]

Rolf Magnus <[EMAIL PROTECTED]> writes:
> I would like to embed a python interpreter within a program, but since that
> program would be able to automatically download scripts from the internet,
> I'd like to run those in a restricted environment, which basically means
> that I want to allow only a specific set of modules to be used by the
> scripts, so that it wouldn't be possible for them to remove files from the
> hard drive, kill processes or do other nasty stuff.
> Is there any way to do that with the standard python interpreter?

Don't count on it.
-- 
http://mail.python.org/mailman/listinfo/python-list

coding conventions, PEP vs. practice

[Roman Roelofsen]

Dear python-list,

while looking for some coding conventions for python programs, i found the 
PEP8 at http://www.python.org/peps/pep-0008.html. It defines the rules very 
well and leaves no space for interpretations. I guess thats a good thing :-) 
But when i started playing a bit with python and frameworks like Zope, 
Webworks, etc., i noticed, that a lot frameworks are using a different 
convention for methodnames. 

These frameworks are using "mixedCase" but PEP8 suggests 
"lower_case_with_underscores" except "in contexts where that's already the 
prevailing style" which is not the case here IMHO.

So, are there any specific reasons for breaking the rules here? I think 
consistent conventions are very important. Being a Java developer in the last 
couple of years, i learned how practical it can be to have only one naming 
style. 

Best regards,

Roman

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

Re: Reaching the real world

[Gary Richardson]

"Fuzzyman" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> I have a friend who would like to move and program lights and other
> electric/electro-mechanical devices by computer. I would like to help -
> and needless to say Python would be an ideal language for the
> 'programmers interface'.
>
> What I'd like is an electronic interface that connects to several
> relays and a python extension module to switch on and off the relays.
> I've had a quick google and can't see anything too similar to what I
> want. pyro (python robotics) seems to require expensive (relatively)
> robotic equipment.
>
> Does anyone know anything *similar* to what I have in mind, or have
> alternative suggestions ?
> Regards,
>
> Fuzzy
> http://www.voidspace.org.uk/python/index.shtml
>

Take a look at:
http://www.geocities.com/hagtronics/pic_das/index.html

Very easy to interface to Python.


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

Re: Restore a unified diff

[Tim Peters]

[Nick Allen]
> After using ndiff from difflib, the function restore
> would return the sequence that generated the delta.

It can actually reproduce either sequence from which the delta was
generated.  But this is really trivial:  ndiff was intended to produce
diff output for humans to read, and includes the full text of both
input sequences in "the diff" it generates.

> Unfortunately, restore does not do the same for unified_diff.  I do
> not see any similar function that is intended for unified_diff.  Does
> anyone know how to "restore" from a unified diff generated delta?

That's in general impossible, since unified diffs generally omit most
lines that compared equal to begin with.  Unified and context diffs
are, in part, compression gimmicks, showing only what changed plus a
bit of context.  ndiff shows everything, so can restore everything
too.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Reaching the real world

[Alejandro Weinstein]

On 4 Jan 2005 at 6:55, Fuzzyman wrote:
 
> What I'd like is an electronic interface that connects to several
> relays and a python extension module to switch on and off the relays.
> I've had a quick google and can't see anything too similar to what I
> want. pyro (python robotics) seems to require expensive (relatively)
> robotic equipment.

Look at pyParallel (http://pyserial.sourceforge.net/pyparallel.html) 
to control the parallel port. From the parallel port you can control 
external devices. Please note that you will need to add a transistor 
to control a relay.

There is also pySerial, (http://pyserial.sourceforge.net/) to control 
the serial port. If you know how to use a microcontroller (AVR, PIC, 
8031, etc) you can communicate with it through the sereial port, and 
let the micro control the "real world".

Regards,
Alejandro.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Lambda as declarative idiom

[Jeff Shannon]

Robert Brewer wrote:
Michael Spencer wrote:
I believe that this "possibility to postpone" divides into 
two related but separate concepts: controlling the moment
of evaluation, and assembling the arguments required at
that moment.  They are both species of 'eval', but 
managing arguments is more specialized, because it includes 
possibly renaming parameters, assigning default values,
processing positional and keyword arguments, and, perhaps
in the future dealing with argument types.
Yes, but the "moment of evaluation" is more complex than just
"postponing". In a declarative construct, you probably also want global
variables to be bound early, so that the expression does not depend upon
*any* free variables. Ditto for closures. A more realistic example:
term = input("Enter the amount to add")
e = expr(x): x + term
...MUCH code passes, maybe even a new process or thread...
d = a + e(3)

I see this as simply a combination of both of the aforementioned 
concepts -- argument control plus moment-of-evaluation control.

Jeff Shannon
Technician/Programmer
Credit International
--
http://mail.python.org/mailman/listinfo/python-list

RE: Bug in handling of single underscore identifiers?

[Robert Brewer]

Tom Blackwell wrote:
> Today I installed the 'mechanoid' package from sourceforge, but the
> self-test failed. On looking into it, I noticed odd behaviour in the
> handling of single underscore module names.  Importing into the
> current namespace with 'from' seems to work, but accessing members of
> the imported module only works if the imported name is qualified by
> the  containing module name.
> 
> For example:
> >>> from mechanoid import _mechanoid_Common
> >>> from _mechanoid_Common import Common
> Traceback (most recent call last):
>   File "", line 1, in ?
> ImportError: No module named _mechanoid_Common
> >>> from mechanoid._mechanoid_Common import Common
> **succeeds**
> >>> _mechanoid_Common
>  'mechanoid\_mechanoid_Common.pyc'>
> 
> Is this a bug or a feature? The language reference section 2.3.2
> 'Reserved classes of identifiers' indicates that identifiers starting
> with a single underscore are not imported by "from module import *".
> However I can't find any indication that "from module import _name"
> should work this way.

I don't think this has anything to do with the underscore. The import
statement doesn't reference module globals; instead, it uses its own
mechanism to find the module you specify:

>>> from os import path
>>> path.sys

>>> from path import sys
Traceback (most recent call last):
  File "", line 1, in ?
ImportError: No module named path

In your example ("from _mechanoid_Common import Common"), import can't
find any module named "_mechanoid_Common" in site-packages, PYTHONPATH,
or other known sources.


Robert Brewer
MIS
Amor Ministries
[EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list

Embedding a restricted python interpreter

[Rolf Magnus]

Hi,

I would like to embed a python interpreter within a program, but since that
program would be able to automatically download scripts from the internet,
I'd like to run those in a restricted environment, which basically means
that I want to allow only a specific set of modules to be used by the
scripts, so that it wouldn't be possible for them to remove files from the
hard drive, kill processes or do other nasty stuff.
Is there any way to do that with the standard python interpreter?

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

Compiling C99 extensions

[dayzman]

Hi,

I'm running Windows and Python 2.4 (binary). I've been trying to
compile this module with extensions that incorporate some C99
extensions (e.g. designated initialisers). I haven't had much luck with
MSVC++ Toolkit 2003, because it doesn't support C99. Is there any other
way I can get the module installed and the extension compiled without
the need to compile Python? I heard that Intel C++ has the same ABI as
VS7.1, can I use it to comple the extension separately? If so, could
someone briefly explain how, because I keep getting the error
"python24.lib cannot be open" or similar error.
Any help will be much appreciated.

Cheers,
Michael

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

Bug in handling of single underscore identifiers?

[Tom Blackwell]

Today I installed the 'mechanoid' package from sourceforge, but the
self-test failed. On looking into it, I noticed odd behaviour in the
handling of single underscore module names.  Importing into the
current namespace with 'from' seems to work, but accessing members of
the imported module only works if the imported name is qualified by
the  containing module name.

For example:
>>> from mechanoid import _mechanoid_Common
>>> from _mechanoid_Common import Common
Traceback (most recent call last):
  File "", line 1, in ?
ImportError: No module named _mechanoid_Common
>>> from mechanoid._mechanoid_Common import Common
**succeeds**
>>> _mechanoid_Common


Is this a bug or a feature? The language reference section 2.3.2
'Reserved classes of identifiers' indicates that identifiers starting
with a single underscore are not imported by "from module import *".
However I can't find any indication that "from module import _name"
should work this way.

Thanks

Tom


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

Restore a unified diff

[Nick Allen]

After using ndiff from difflib, the function restore
would return the sequence that generated the delta.  Unfortunately,
restore does not do the same for unified_diff.  I do not see any similar
function that is intended for unified_diff.  Does anyone know how to 
"restore" from a unified diff generated delta?

Thanks for all your help in advance.

Best Regards,
Nick


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

Re: args (was Re: Lambda as declarative idiom (was RE: what is lambda used for in real code?))

[Roman Suzi]

On Tue, 4 Jan 2005, Michael Spencer wrote:

>Roman Suzi wrote:
>
>> Maybe this is too outlandish, but I see lambdas as a "quote" mechanism,
>> which presents a possibility to postpone (precisely control, delegate)
>> evaluation. That is, an ovehead for lambda must be much lower but at the
>> same time visible to the programmer:
>>
>>  d = a + (lambda x, y: x+ y)(3, 4)
>[...]
>
>I believe that this "possibility to postpone" divides into two related but
>separate concepts: controlling the moment of evaluation, and assembling the
>arguments required at that moment.

Yes. I have the same understanding.

>They are both species of 'eval', but
>managing arguments is more specialized, because it includes possibly renaming
>parameters, assigning default values, processing positional and keyword
>arguments, and, perhaps in the future dealing with argument types.

Very precise!

>Meanwhile, GvR wrote (about defining Interfaces in the context of Optional
>Static Type Checking)

As for GvR's writing, I think he is exploring the ground. What he wrote
is too complex for Python and he guesses it is.

There i another thread in c.l.p where I propose generic programming
approach for Python's "type checking": IMHO, a much simpler and more natural
for Python than programming by contract, just interfaces and such.

And the syntactic way to express concepts is going thru
declarations. That is why lambdas are to be on steroids for this task.

More than that, compile vs. evaluation/parameter dispetching must not muddy
the waters for programmer. It must always be clear (syntactically too)
for him what is going on in the expression at hand. (But I do not know
how this could be elegantly done sytactically)

Is declaration-chewing engine built into Python an overkill?
There are at least 2 specialized ones in it: parser and re.compile +
many for different formats, like xml.dom.


Sincerely yours, Roman Suzi
-- 
[EMAIL PROTECTED] =\= My AI powered by GNU/Linux RedHat 7.3
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python evolution: Unease

[Robert Kern]

Terry Reedy wrote:
"Bulba!" <[EMAIL PROTECTED]> wrote in message
E.g. right now I would kill for a standard, built-in matrix
type

The array types of Numerical Python (NumPy) and now Numarray are, defacto, 
Python's standard 1 to n dimensional array types.  Once installed, they are 
as builtin as anything else.  Several other packages build on top of them.
And one of the goals of numarray (which is a complete rewrite of 
Numeric) *is* entry into the standard library.

--
Robert Kern
[EMAIL PROTECTED]
"In the fields of hell where the grass grows high
 Are the graves of dreams allowed to die."
  -- Richard Harter
--
http://mail.python.org/mailman/listinfo/python-list

Re: cxOracle for python 2.4

[sigzero]

Volker Helm wrote:
> Hi there,
>
> does anybody knows where I can get the DB interface cx_Oracle for
Python
> 2.4 with win32.
>
> On http://www.computronix.com/utilities.shtml exists only the version

> for Python 2.3. I would try to compile it myself, if I had a compiler

> and would know how to use it ;-)
>
> Thanks in advance,
> 
> Volker

http://starship.python.net/crew/atuining/cx_Oracle/

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

Re: Speed ain't bad

[Anders J. Munch]

"John Machin" <[EMAIL PROTECTED]> wrote:
> 1. Robustness: Both versions will "crash" (in the sense of an unhandled
> 2. Efficiency: I don't see the disk I/O inefficiency in calling

3. Don't itemise perceived flaws in other people's postings. It may
give off a hostile impression.

> 1. Robustness: Both versions will "crash" (in the sense of an unhandled
> exception) in the situation where zfdir exists but is not a directory.
> The revised version just crashes later than the OP's version :-(
> Trapping EnvironmentError seems not very useful -- the result will not
> distinguish (on Windows 2000 at least) between the 'existing dir' and
> 'existing non-directory' cases.

Good point; my version has room for improvement. But at least it fixes
the race condition between isdir and makedirs.

What I like about EnvironmentError is that it it's easier to use than
figuring out which one of IOError or OSError applies (and whether that
can be relied on, cross-platform).

> 2. Efficiency: I don't see the disk I/O inefficiency in calling
> os.path.isdir() before os.makedirs() -- if the relevant part of the
> filesystem wasn't already in memory, the isdir() call would make it
> so, and makedirs() would get a free ride, yes/no?

Perhaps. Looking stuff up in operating system tables and buffers takes
time too. And then there's network latency; how much local caching do
you get for an NFS mount or SMB share?

If you really want to know, measure.

- Anders


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

Re: What can I do with Python ??

[Lee Harr]

On 2005-01-03, Steve Holden <[EMAIL PROTECTED]> wrote:
> John J. Lee wrote:
>
>> Lee Harr <[EMAIL PROTECTED]> writes:
>> [...]
>> 
>>>I think it looks pretty good. The only problem I see is section 5
>>>where it says:
>>>
>>>5. Did we miss your concern?
>>>
>>> Please add a comment to this page.
>>>
>>>
>>>but the page is immutable.
>> 
>> 
>> 
>> Hopefully one of the site maintainers will read this and demonstrate
>> that it's actually readonly rather than immutable, then make it
>> appendable ;-)
>> 
>> 
>
> To be even more pedantic, I believe it's possible to gain editing 
> privileges on the Wiki by authenticating yourself to the engine at
>
>  http://www.python.org/moin/UserPreferences
>
> The point is to be able to track changes and thereby discourage 
> defacement, which was starting to happen of a depressingly regular basis.
>


I do not understand. Are you saying that someone who wants
to "add a comment to this page" can do so?

When I clicked on the "edit" link, it said:
"You are not allowed to edit this page."

Maybe it should say ...
"You are not allowed to edit this page. Try logging in first."
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Pythonic search of list of dictionaries

[John Machin]

Bulba! wrote:
[big snip]

Forget the csv-induced dicts for the moment, they're just an artifact
of your first solution attempt. Whether english = csv_row[1], or
english = csv_row_dict["english"], doesn't matter yet. Let's take a few
steps back, and look at what you are trying to do through a telescope
instead of a microscope.

Core basic root problem: you have a table with 3 columns, id, english,
polish. Nothing is said about id so let's assume nothing. Evidently
contents of "english" is the "key" for this exercise, but it's not
necessarily unique. You have two instances of the table, and you want
to "diff" them using "english" as the key.

You want to collect together all rows that have the same value of
"english", and then process them somehow. You need to define an object
containing a list of all "left" rows and a list of all "right" rows.

Processing the contents of the object: do whatever you have to with
obj.left_list and obj.right_list depending on the lengths; you have 3
cases of length to consider (0, 1, many). 3 x 3 = 9 but if you get both
zero you have a bug (which you should of course assert does not exist),
so that leaves 8 cases to think about.

Now, how do we get the rows together:

(a) The sort method

Step 1: sort each dataset on (english, id, polish) or (english, polish,
id) -- your choice; sorting on the whole record instead just english
makes the ordering predictable and repeatable.

Step 2: read the two sorted datasets ("left" and "right") in parallel:

when left key < right key: do_stuff(); read another left record
when left key > right key: converse
when left ley == right key: do_stuff(); read another record for both
where do_stuff() includes appending to left_list and right_list as
appropriate and at the right moment, process a completed object.
This is a little tricky, and handling end of file needs a little care.
However this algorithm can be implemented with minimal memory ("core"),
no disk drive at all :-O and a minimum of 3 (preferably 4+)
serially-readable rewindable re-writable storage devices e.g magnetic
tape drives. Once upon a time, it was *the* way of maintaining a
database (left = old database, right = transactions, output file -> new
database).

(b) Fast forwarding 30+ years, let's look at the dictionary method,
assuming you have enough memory to hold all your data at once:

Step 1: read the "left" table; for each row, if english not in mydict,
then do mydict[english] = MyObject(). In any case, do
mydict[english].left_list.append(row)
Step 2: same for the "right" table.
Step 3: for english, obj in mydict.iteritems(): process(english, obj)

As your datasets are stored in MS Excel spreadsheets, N < 64K so
whether your solution is O(N) or O(N*log(N)) doesn't matter too much.
You are however correct to avoid O(N**2) solutions.

Hoping this sketch of the view through the telescope (and the
rear-vision mirror!) is helpful,
John

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

Re: Optional Static Typing: Part II

[Michael Hobbs]

John Roth <[EMAIL PROTECTED]> wrote:
> Now, the base objective seems to be to incorporate PyChecker
> functionality into the root. This in turn requires type inference,
> which in turn strongly suggests type annotations to help the
> inferencer out over rough spots.
> 
> I like this approach a lot.

If he makes the type inferencer "proud", that might help alleviate
the fears around here that it will become standard practice to put
type annotations on everything. That is, if you explicitly annotate
a function in the same way that the inferencer would have inferenced
it, the PyChecker thingie would emit a message saying:

"I'm no dummy! I could have told you that foo() takes an 'int' and
returns a 'bool'. What do you think I am, stupid? Duuu-uhhh!"

:)

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

Re: Lambda as declarative idiom

[Robert Brewer]

Michael Spencer wrote:
> Roman Suzi wrote:
> 
> > Maybe this is too outlandish, but I see lambdas as a 
> "quote" mechanism,
> > which presents a possibility to postpone (precisely 
> control, delegate)
> > evaluation. That is, an ovehead for lambda must be much 
> lower but at the
> > same time visible to the programmer:
> > 
> >  d = a + (lambda x, y: x+ y)(3, 4)
> [...]
> 
> I believe that this "possibility to postpone" divides into 
> two related but separate concepts: controlling the moment
> of evaluation, and assembling the arguments required at
> that moment.  They are both species of 'eval', but 
> managing arguments is more specialized, because it includes 
> possibly renaming parameters, assigning default values,
> processing positional and keyword arguments, and, perhaps
> in the future dealing with argument types.

Yes, but the "moment of evaluation" is more complex than just
"postponing". In a declarative construct, you probably also want global
variables to be bound early, so that the expression does not depend upon
*any* free variables. Ditto for closures. A more realistic example:

term = input("Enter the amount to add")
e = expr(x): x + term

...MUCH code passes, maybe even a new process or thread...

d = a + e(3)


Robert Brewer
MIS
Amor Ministries
[EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list

Re: why does UserDict.DictMixin use keys instead of __iter__?

[Steven Bethard]

John Machin wrote:
OK, I'll rephrase: what is your interest in DictMixin?
My interest: I'm into mappings that provide an approximate match
capability, and have a few different data structures that I'd like to
implement as C types in a unified manner. The plot includes a base type
that, similarly to DictMixin, provides all the non-basic methods.
I was recently trying to prototype a simple mapping type that implements 
the suggestion "Improved default value logic for Dictionaries" from
http://www.python.org/moin/Python3_2e0Suggestions
You can't just inherit from dict and override dict.__getitem__ because 
dict.__getitem__ isn't always called:

py> class D(dict):
... def __init__(*args, **kwds):
... self = args[0]
... self.function, self.args, self.kwds = None, None, None
... super(D, self).__init__(*args[1:], **kwds)
... def setdefault(self, function, *args, **kwds):
... self.function, self.args, self.kwds = function, args, kwds
... def __getitem__(self, key):
... if key not in self:
... super(D, self).__setitem__(
... key, self.function(*self.args, **self.kwds))
... return super(D, self).__getitem__(key)
...
py> d = D()
py> d.setdefault(list)
py> d['c'].append(2)
py> d
{'c': [2]}
py> print d.get('d') # should print []
None
This, of course, is exactly the kind of thing that DictMixin is designed 
for. =)

Of course, it's no trouble for me to implement keys().  I was just 
wondering why that design decision was made when it seems like __iter__ 
is more integral to the mapping protocol.  And if you want efficient 
iteration over your mapping type, you're going to have to define 
__iter__ too...

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

Re: Python evolution: Unease

[Roman Suzi]

On Tue, 4 Jan 2005, Dave Brueck wrote:

>Roman Suzi wrote:
>>>The term "generic programming" is too... er... generic. :)

>> Nope. It is not generic. It has it's definition made by the co-author
>> of STL - A.Stepanov. And the Boost C++ library (many of us know it as
>> Boost Python) standardise on the approach, AFAIK.
>
>Ok, "too broad" then; Python already supports at least some aspects of generic
>programming (at least, in the sense that I think you mean it), so it'd be good
>to spell out what specific features you're referring to.
>
>> Python could have honest support of concepts. Everything else will be
>> available with them.
>
>"Concepts" is a pretty generic term too! ;-) Do you mean concepts as defined
>here: http://www.boost.org/more/generic_programming.html
>?

Yes.

>> And BTW, are we really disputing?
>

>No, not at all - I'm just trying to better understand what you mean. Words
>like "generic" and "concepts" don't yet have a widely recognized, strict
>definition in the context of programming. If somebody has assigned some
>specific definition to them, that's great, it's just not universal yet so
>references and additional explanations are helpful.

I apologize for not providing URLs to the exact definitions in the first
place! I really think there is ONE understanding of GP vs. multitudes of
understandings of OOP.


Sincerely yours, Roman Suzi
-- 
[EMAIL PROTECTED] =\= My AI powered by GNU/Linux RedHat 7.3
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python evolution: Unease

[Roman Suzi]

On Tue, 4 Jan 2005, Ian Bicking wrote:

>Umm... this isn't helpful.  "Generic" and "concept" are not terms that
>belong to Boost or STL or whatever.  They are just words.  Coining the
>term doesn't mean anyone else knows what it means, nor that anyone
>*should* know what they mean -- personally I get very suspicious of
>ideas that are based on redefined words, that tends to be a way of
>hiding complexity or fuzziness.
>
>But anyway, if you use these terms, you really must provide references,
>otherwise no one will know what you mean.  "Python could have honest
>support of concepts" is simply an incomplete sentence.  "Python could
>have honest support of Concepts (url)" would be more reasonable.

Sorry. I use definitions from there sources:

 1. http://www.cs.rpi.edu/~musser/gp/

 2. "A Formalization of Concepts for Generic Programming"
(google could find PDF of that). If I am correct, this one:
http://www.osl.iu.edu/publications/pubs/2004/willcock04:_formal_concep_gener_progr.pdf

(it is safe to skip till example on Fig.1 to grasp the idea behind
a concept. Relations between concepts are also very logical and
remind of inheritance, association and aggregation)

 3. "The Boost Graph Library" by Jeremy Siek, et al with A.Stepanov's
foreword is a good way to see GP != STL.

 Probably Boost docs contain some knowledge on the topic, at least
Boost Graph Library's ones (which I read).


>"Python could have honest support of Concepts (url)"

- of course, right now those sources are C++-specific. But I could see that
Python has even greater potential to have concepts ahead of C++ and with
greater usefulness at the same time.


Sincerely yours, Roman Suzi
-- 
[EMAIL PROTECTED] =\= My AI powered by GNU/Linux RedHat 7.3
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python evolution: Unease

[Dave Brueck]

Roman Suzi wrote:
The term "generic programming" is too... er... generic. :)

Nope. It is not generic. It has it's definition made by the co-author
of STL - A.Stepanov. And the Boost C++ library (many of us know it as
Boost Python) standardise on the approach, AFAIK.
Ok, "too broad" then; Python already supports at least some aspects of generic 
programming (at least, in the sense that I think you mean it), so it'd be good 
to spell out what specific features you're referring to.

Python could have honest support of concepts. Everything else will be
available with them.
"Concepts" is a pretty generic term too! ;-) Do you mean concepts as defined 
here: http://www.boost.org/more/generic_programming.html
?

And BTW, are we really disputing? 
No, not at all - I'm just trying to better understand what you mean. Words like 
"generic" and "concepts" don't yet have a widely recognized, strict definition 
in the context of programming. If somebody has assigned some specific definition 
to them, that's great, it's just not universal yet so references and additional 
explanations are helpful.

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

args (was Re: Lambda as declarative idiom (was RE: what is lambda used for in real code?))

[Michael Spencer]

Roman Suzi wrote:
Maybe this is too outlandish, but I see lambdas as a "quote" mechanism,
which presents a possibility to postpone (precisely control, delegate)
evaluation. That is, an ovehead for lambda must be much lower but at the
same time visible to the programmer:
 d = a + (lambda x, y: x+ y)(3, 4)
[...]
I believe that this "possibility to postpone" divides into two related but 
separate concepts: controlling the moment of evaluation, and assembling the 
arguments required at that moment.  They are both species of 'eval', but 
managing arguments is more specialized, because it includes possibly renaming 
parameters, assigning default values, processing positional and keyword 
arguments, and, perhaps in the future dealing with argument types.

Meanwhile, GvR wrote (about defining Interfaces in the context of Optional 
Static Type Checking)
Method declarations can be inspected to find out their signature. I propose a
__signature__ attribute (also for methods defined in classes!) which might be an
object whose attributes make the signature easily inspectable. This might take 
the form of a list of argument declaration objects giving the name, type and default
(if any) for each argument, and a separate argument for the return type. For 
signatures that include *args and/or **kwds, the type of the additional arguments 
should also be given (so you can write for example a varargs method whose arguments
are all strings).
GvR's method.__signature__ object might be related to the args object I proposed 
 as part of the syntax for anonymous functions without 'lambda'. i.e.,

args(a,*b,**kw) --> an object that specifies but does not evaluate its 
parameters until it is supplied to a callable, possibly with calling parameters

This object would contain the default values, and could contain type 
annotations, explicit, or inferred, as well as more complex assertions used in 
several contexts.

* Current function syntax:
def func(a,*b,**c) : pass
creates func with func.__signature__ = args(a,*b,**c)
and when func is called, the args are evaluated using a mechanism in
args.__call__
so, roughly, eval(func.__signature__) --> func.locals
 * Anonymous functions
	Syntax alternatives at http://www.python.org/moin/AlternateLambdaSyntax
	e.g., (f(a) + o(b) - o(c) for args(a, b, c))
	
	args would evaluated with the calling parameters and made available in 			the 
local scope defined by ()
	
 * A stricter alternative to keyword arguments:
 	argspec = args(arg1, arg2, arg3)
	def func(**argspec): pass
	
	is equivalent to def func(arg1, arg2, arg3): pass


args["arg1"]

(i.e., only args defined in argspec are accepted)
 * Useful infrastructure for user-supplied type-based dispatch/lightweight 
multimethods:
	
	argspec = args([(a:int, b:int),(a:str,b:str)])
	
	then a framework can provide a custom args.__call__ method that does
	conformance-checking, adaptation or whatever


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

Re: Python evolution: Unease

[holger krekel]

Hi Roman, 

On Wed, Jan 05, 2005 at 00:44 +0300, Roman Suzi wrote:
> Python could have honest support of concepts. Everything else will be
> available with them.
> 
> That is the whole point that Python supports GP. It is only one step
> to do concepts right (and GvR it seems want type-checking into Python 3.0
> anyway), so support for concepts/concept checking is very logical,
> isn't it?

As an innocent by-dropper into this thread: 

a) do you know Armin Rigo's "semantic model" page dealing 
   with concepts? 

   http://arigo.tunes.org/semantic_models.html

b) do you have some concise definition of what you mean 
   by "concept"? 

Myself, i appreciate the combination of testing and python's 
flexibility so much that i don't long for type declarations, 
at least not to the degree that would warrant syntax additions. 

Now for interfaces, for me this references more a documentation issue
than a syntax one: I'd like to have a full-featured runtime browser 
that allows to quickly navigate cross-referenced life python objects. 
Back and forth in execution time, preferably.  This probably requires 
the interpreter to help, track and record more information (which is one 
of the possibilities with PyPy).  It doesn't neccessarily require any new 
syntax though.  

And I don't really see the point of adding interface
hierarchies to already large frameworks.  To me this adds to -
what i call - "naming complexity", i.e. the number of names a
programmer needs to remember to deal with a library or
framework.  For me, it's not really the syntax that is the
problem with interfaces in Zope3 or twisted, but the sheer
amount of names (each indicating certain concepts and
behaviours) i am confronted with.  

Not sure why i am saying all this here 
but have fun, 

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

Looking for CORBA (omniORB) examples

[RajaSrinivasan]

can we script CORBA objects/events with python. my search for simple
examples has not yielded any results. any help appreciated.

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

Re: Python evolution: Unease

[Roman Suzi]

On Tue, 4 Jan 2005, Dave Brueck wrote:

>> What about generic programming coming into fashion anytime soon?

>Roman, I think I've read every single thread in the past year or three
>wherein you've brought up generic programming, and I think you'd do well to
>choose a new term for the idea you're trying to convey.

Or, yes, and I forgot to mention that generic programming is much clearer idea
than OO programming, as it is not so vague. At least for me:
I still don't fully comprehend OOP (after N years of "studying" it!) and
understanding of GP came after just one book on the topic.


Sincerely yours, Roman Suzi
-- 
[EMAIL PROTECTED] =\= My AI powered by GNU/Linux RedHat 7.3
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python evolution: Unease

[Ian Bicking]

Roman Suzi wrote:
The term "generic programming" is too... er... generic. :)

Nope. It is not generic. It has it's definition made by the co-author
of STL - A.Stepanov. And the Boost C++ library (many of us know it as
Boost Python) standardise on the approach, AFAIK.

As you know, Python
already includes a _lot_ of support for generic programming (a function that
iterates over a sequence can easily process a list, or a string, or a tuple as
input; a function that takes a file-like object can often work just as will with
a true file object or a cStringIO object; etc.). So when you bring up "generic
programming", it's too easy to dismiss the comment because (1) it's too vague
and (2) Python already does a lot of it.
So, what is your term for the type of generic programming that Python doesn't
yet support? Interfaces? Protocols? Adapters? Metatype hierarchies?

Python could have honest support of concepts. Everything else will be
available with them.
Umm... this isn't helpful.  "Generic" and "concept" are not terms that 
belong to Boost or STL or whatever.  They are just words.  Coining the 
term doesn't mean anyone else knows what it means, nor that anyone 
*should* know what they mean -- personally I get very suspicious of 
ideas that are based on redefined words, that tends to be a way of 
hiding complexity or fuzziness.

But anyway, if you use these terms, you really must provide references, 
otherwise no one will know what you mean.  "Python could have honest 
support of concepts" is simply an incomplete sentence.  "Python could 
have honest support of Concepts (url)" would be more reasonable.

--
Ian Bicking  /  [EMAIL PROTECTED]  /  http://blog.ianbicking.org
--
http://mail.python.org/mailman/listinfo/python-list

Re: Bad Interpreter

[RajaSrinivasan]

sounds like it. vi sock.py shows '$' at the end of each line.

however when i went to a unix machine and recreated the file, the
problem went away.

thanks for all the help

regards

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

Re: Python evolution: Unease

[Terry Reedy]

"Bulba!" <[EMAIL PROTECTED]> wrote in message
> E.g. right now I would kill for a standard, built-in matrix
> type

The array types of Numerical Python (NumPy) and now Numarray are, defacto, 
Python's standard 1 to n dimensional array types.  Once installed, they are 
as builtin as anything else.  Several other packages build on top of them.

> that would be as flexible as lists and dictionaries are
> in Python, so that I could slurp the whole CSV file or some
> other table in one instruction into a matrix that could
> accomodate data types likes strings and floats (just like
> dictionaries do - just,  say, declare, "column 1 of matrix
> contains strings, and please convert the values in column 2
> into floats"), and then easily do some fancy matrix
> transformations.

Numarray has a record array type.  If there is not one publicly available, 
perhaps you could write a CSV file to record-array slurper and contribute 
it to the Recipes site or maybe even the CSV module.

Terry J. Reedy



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

Re: Python evolution: Unease

[Roman Suzi]

On Tue, 4 Jan 2005, Dave Brueck wrote:

>Roman Suzi wrote:
It may be optional in the sense that the language will
accept missing declarations but as soon as the feature
is available it will become "mandatory" to use it
(peer pressure, workplace practices).
>>
>>
>> What about generic programming coming into fashion anytime soon?
>
>Roman, I think I've read every single thread in the past year or three wherein
>you've brought up generic programming, and I think you'd do well to choose a 
>new
>term for the idea you're trying to convey.

IIRC, I did it only once: at fall 2004.

>The term "generic programming" is too... er... generic. :)

Nope. It is not generic. It has it's definition made by the co-author
of STL - A.Stepanov. And the Boost C++ library (many of us know it as
Boost Python) standardise on the approach, AFAIK.

>As you know, Python
>already includes a _lot_ of support for generic programming (a function that
>iterates over a sequence can easily process a list, or a string, or a tuple as
>input; a function that takes a file-like object can often work just as will 
>with
>a true file object or a cStringIO object; etc.). So when you bring up "generic
>programming", it's too easy to dismiss the comment because (1) it's too vague
>and (2) Python already does a lot of it.
>
>So, what is your term for the type of generic programming that Python doesn't
>yet support? Interfaces? Protocols? Adapters? Metatype hierarchies?

Python could have honest support of concepts. Everything else will be
available with them.

That is the whole point that Python supports GP. It is only one step
to do concepts right (and GvR it seems want type-checking into Python 3.0
anyway), so support for concepts/concept checking is very logical,
isn't it?

Right now concepts in Python are things which experienced Python programmers
know from practise. Sometimes, they feel them unconsciously.
Concepts could be veryfied and this, for example, could prevent errors
like DB-API-complient module doesn't have some small, but necessary
to comply, attributes.

Standard concepts could be part of standard concept "metalibrary", along with
verification mechanisms (this could be done even on C++, why not in a candy
like Python?). So every programmer could verify that his/her class, created to
satisfy concept XYZ is (formally) such. Your example - cStringIO - does
it really satisfy concept of STRING? It does. Partially. Those "partially"
here and there could lead to madness.

Unit testing will be simplified too, because structural tests will be
built into concept-checking mechanism.

And BTW, are we really disputing? What do you propose instead? Old-fashioned
Pascal-like type definitions? Java-like interface/implementaion ...? IMHO it
could be a big mistake to play catch-up.


Sincerely yours, Roman Suzi
-- 
[EMAIL PROTECTED] =\= My AI powered by GNU/Linux RedHat 7.3
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Hlelp clean up clumpsy code

[Pierre Quentel]

You can also do it in a more pythonic way but without generators :
# a = [[1,5,2], 8, 4]
# l = []
# for item in a:
#if isinstance(item, (int, long)):
#l.append(item)
#else:
#l+=item
# print dict([(item,i+1) for (i,item) in enumerate(l)])
It works in the same conditions as your original code (no nested lists)
A few other things :
- you don't have to type a comma for one-item lists : x = [x] works - 
you probably confused with tuples where you must do x=(x,)
- instead of
# for w in [y for y in x]:
just do
# for w in x:
-  for "i = i+1" there is a shortcut : i+=1 (see "l+=item" above)

Regards,
Pierre
--
http://mail.python.org/mailman/listinfo/python-list

Re: Optional Static Typing: Part II

[Roman Suzi]

On Tue, 4 Jan 2005, John Roth wrote:

>Guido has posted a second blog entry on the optional static typing
>initiative.
>I like this a lot better than the first.

Declarative approach is even more human-oriented than algorithmic one.
If Python is to support declarations, let it support declarative programming
paradigm with full-blown inference engine .

So, why not add some logic approach to type declarations? I hope
that "type" is understood in a generic programming way: it will be a
big win for Python to provide grounds for GP 'concept' concept ;)
Why not? Python program right now are nearer to GP than C++'s.
'Concept' is not mere "interface", but interface + semantic behaviour.
And to describe that behaviour logic is needed (right now it could be done
with asserts).

I propose to skip 'interface' support with Python and go stright to
GP concepts :>

This way Python will be ahead with innovation and type/interface/concept
declarations will not be seen as atavisms but a step forward from OOP.

I hope GvR waited so long not implementing interfaces to implement something
better, concepts for example ;-) Right now concepts are expressed informally
in the docstrings.


Sincerely yours, Roman Suzi
-- 
[EMAIL PROTECTED] =\= My AI powered by GNU/Linux RedHat 7.3
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: why does UserDict.DictMixin use keys instead of __iter__?

[Raymond Hettinger]

[Steven Bethard]
> Sorry, my intent was not to say that I didn't know from the docs that
> UserDict.DictMixin required keys().  Clearly it's documented.  My
> question was *why* does it use keys()?  Why use keys() when keys() can
> be derived from __iter__, and __iter__ IMHO looks to be a more basic
> part of the mapping protocol.

Viewed from the present, __iter__() may seem more basic.  However, it is a
recent innovation.  The keys() method, on the other hand, goes back to the
beginning.  There were no shortage of mapping-like classes defining keys() but
not __iter__().

Still, if __iter__() is provided, UserDict.DictMixin will take advantage of it.
The same is also true for __contains__(), and iteritems().


Raymond Hettinger


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

Re: Working with flat files [LDIF].

[generate]

Scott A. McIntyre wrote:
>
> I looked around but didn't see any LDIF tools for perl or python...
>
> Any assistance or advice is appreciated!!
>
> Scott


Hello Scott,

Did you ever get this issue resolved?  I have a similar need to merge
two LDIF files.  I did find a program called mmldif, but I believe it
is proprietary to Sun.

Cheers,
Charles

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

Re: Pythonic search of list of dictionaries

[Marc 'BlackJack' Rintsch]

In <[EMAIL PROTECTED]>, Bulba! wrote:

> I put those dictionaries into the list:
> 
>oldl=[x for x in orig]  # where orig=csv.DictReader(ofile ...

If you don't "do" anything with each `x` you can write this as:

oldl = list(orig)

Ciao,
Marc 'BlackJack' Rintsch
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Working with flat files [LDIF].

[generate]

Scott A. McIntyre wrote:
>
> I looked around but didn't see any LDIF tools for perl or python...
>
> Any assistance or advice is appreciated!!
>
> Scott


Hello Scott,

Did you ever get this issue resolved?  I have a similar need to merge
two LDIF files.  I did find a program called mmldif, but I believe it
is proprietary to Sun.

Cheers,
Charles

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

Re: why does UserDict.DictMixin use keys instead of __iter__?

[John Machin]

Steven Bethard wrote:
> John Machin wrote:
> > Steven Bethard wrote:
> >
> >>So I was looking at the Language Reference's discussion about
> >>emulating container types[1], and nowhere in it does it mention
that
> >> .keys() is part of the container protocol.
> >
> > I don't see any reference to a "container protocol".
>
> Sorry, I extrapolated "container protocol" from this statement:
>
> "Containers usually are sequences (such as lists or tuples) or
mappings
> (like dictionaries), but can represent other containers as well. The
> first set of methods is used either to emulate a sequence or to
emulate
> a mapping"
>
> and the fact that there is a "sequence protocol" and a "mapping
protocol".
>
> But all I was really reading from this statement was that the "first
set
> of methods" (__len__, __getitem__, __setitem__, __delitem__ and
> __iter__) were more integral than the second set of methods (keys(),
> values(), ...).
>
>
> > What I do see is
> > (1) """It is also recommended that mappings provide the methods
keys(),
> > ..."""
>
> You skipped the remaining 13 methods in this list:
>
> "It is also recommended that mappings provide the methods keys(),
> values(), items(), has_key(), get(), clear(), setdefault(),
iterkeys(),
> itervalues(), iteritems(), pop(), popitem(), copy(), and update()
> behaving similar to those for Python's standard dictionary objects."
>
> This is the "second set of methods" I mentioned above.  I don't
> understand why the creators of UserDict.DictMixin decided that
keys(),
> from the second list, is more important than __iter__, from the first
list.
>
>
> >>Because of this, I would assume that to
> >>use UserDict.DictMixin correctly, a class would only need to define
> >>__getitem__, __setitem__, __delitem__ and __iter__.
> >
> >
> > So I can't see why would you assume that, given that the docs say
in
> > effect "you supply get/set/del + keys as the building blocks, the
> > DictMixin class will provide the remainder". This message is
reinforced
> > in the docs for UserDict itself.
>
> Sorry, my intent was not to say that I didn't know from the docs that

> UserDict.DictMixin required keys().  Clearly it's documented.

Sorry, the combination of (a) "assume X where not(X) is documented" and
(b) posting of tracebacks that demonstrated behaviour that is both
expected and documented lead to my making an unwarranted assumption :-)

> My
> question was *why* does it use keys()?  Why use keys() when keys()
can
> be derived from __iter__, and __iter__ IMHO looks to be a more basic
> part of the mapping protocol.

Now that I understand your question: Hmmm, good question. __iter__
arrived (2.2) before DictMixin (2.3), so primacy is not the reason.
Ease of implementation by the user of DictMixin: probably not, "yield
akey" vs "alist.append(akey)" -- not much in it in Python, different
story in C, but a C extension wouldn't be using DictMixin anyway.
>
> > In any case, isn't UserDict past history? Why are you mucking about
> > with it?
>
> UserDict is past history, but DictMixin isn't.

OK, I'll rephrase: what is your interest in DictMixin?

My interest: I'm into mappings that provide an approximate match
capability, and have a few different data structures that I'd like to
implement as C types in a unified manner. The plot includes a base type
that, similarly to DictMixin, provides all the non-basic methods.

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

Re: Python evolution: Unease

[Dave Brueck]

Roman Suzi wrote:
On Tue, 4 Jan 2005, Dave Brueck wrote:

It may be optional in the sense that the language will
accept missing declarations but as soon as the feature
is available it will become "mandatory" to use it
(peer pressure, workplace practices).

What about generic programming coming into fashion anytime soon?
Roman, I think I've read every single thread in the past year or three wherein 
you've brought up generic programming, and I think you'd do well to choose a new 
term for the idea you're trying to convey.

The term "generic programming" is too... er... generic. :) As you know, Python 
already includes a _lot_ of support for generic programming (a function that 
iterates over a sequence can easily process a list, or a string, or a tuple as 
input; a function that takes a file-like object can often work just as will with 
a true file object or a cStringIO object; etc.). So when you bring up "generic 
programming", it's too easy to dismiss the comment because (1) it's too vague 
and (2) Python already does a lot of it.

So, what is your term for the type of generic programming that Python doesn't 
yet support? Interfaces? Protocols? Adapters? Metatype hierarchies?

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

Re: Python evolution: Unease

[Doug Holton]

Istvan Albert wrote:
Doug Holton wrote:
application is so important that I expect Python 3000 will have
optional type declarations integrated into the argument list."

I think that *optional* part of the "optional type declaration"
is a myth.
It may be optional in the sense that the language will
accept missing declarations but as soon as the feature
is available it will become "mandatory" to use it
(peer pressure, workplace practices).
I didn't write that, Guido did.  I agree with you, and others who have 
made the same point you made.  I would have to think Guido is already 
aware of this issue (keep python simple).  I'm not sure what his 
motivations are for wanting to add static typing to python, not that I'm 
against it.

It doesn't matter a whole lot either way since Python 3000 is still 
years away and you can already do static typing now with Pyrex or boo, 
as well as many other things that people have requested for python from 
little things like ++i to bigger features like multi-line anonymous 
methods/closures.
--
http://mail.python.org/mailman/listinfo/python-list

Optional Static Typing: Part II

[John Roth]

Guido has posted a second blog entry on the optional static typing 
initiative.
I like this a lot better than the first.

http://www.artima.com/weblogs/viewpost.jsp?thread=86641
Now, the base objective seems to be to incorporate PyChecker
functionality into the root. This in turn requires type inference,
which in turn strongly suggests type annotations to help the
inferencer out over rough spots.
I like this approach a lot.
There's also an explicit recognition that there are a lot of
use cases for being able to access type information at
run time.
I also like this. I'm kind of neutral to the idea of using it
for actual type checking: I don't think that it catches that
many errors if the developer is doing a decent job of
testing. However, since it's going to be supplemental to
type inference, it will be a lot less intrusive.
There's a new approach to interfaces that looks
intriguing. One nice part is the ability to include
Design By Contract type preconditions with the
interface. It will be even better if they can be checked
at compile time, or by the PyChecker functionality.
I have to say this turned my attitude around on the
subject: I'm quite in favor of the direction Guido
seems to be going.
John Roth
--
http://mail.python.org/mailman/listinfo/python-list

Re: [Hack] Import binary extensions from zipfiles, windows only

[Thomas Heller]

"PJDM" <[EMAIL PROTECTED]> writes:

> I'm trying to make ZopeX3 start faster by zipping up the "zope"
> directory. (Because this will be stored on a CD, having less data to
> read will make it quicker to start.)
>
> The standard python zipimporter won't work with the ZopeX3 .pyd files,
> so zipextimporter came along at just the right time. However, it
> doesn't seem to work for me (Python 2.3.4 (#53, May 25 2004, 21:17:02)
> [MSC v.1200 32 bit (Intel)] on win32, Windows XP SP2).
>
> Sample script:
> 
> import zipextimporter
> zipextimporter.install()
>
> import sys
> print 'Hooks:\n', sys.path_hooks
>
> sys.path.append(r'C:\tmp\zope.zip')
> print 'Path:\n', sys.path
>
> # Try an innocuous import first to make sure we have the path correct.
> import zope.server
> print 'Server file:\n', zope.server.__file__
>
> # Now try a .pyd import.
> import zope.thread._zope_thread
> print 'Thread file:\n', zope.thread._zope_thread.__file__
> 
>
> Output:
> 
> Hooks:
> [,  'zipimport.zipimporter'>]
> Path:
> ['C:\\tmp', 'C:\\WINDOWS\\system32\\python23.zip', 'C:\\tmp',
> 'C:\\opt\\Python23\\DLLs', 'C:\\opt\\Python23\\lib',
> 'C:\\opt\\Python23\\lib\\plat-win', 'C:\\opt\\Python23\\lib\\lib-tk',
> 'C:\\opt\\Python23', 'C:\\opt\\Python23\\lib\\site-packages',
> 'C:\\tmp\\zope.zip']
> Server file:
> C:\tmp\zope.zip\zope\server\__init__.py
> Traceback (most recent call last):
> File "zei.py", line 15, in ?
> import zope.thread._zope_thread
> ImportError: No module named _zope_thread
> 
>
> The zope.zip file contains zope.thread:
> 
> $ unzip -l zope.zip |grep zope/thread
> 0  11-08-04 11:00   zope/thread/
> 0  07-03-04 04:34   zope/thread/DEPENDENCIES.cfg
> 65  07-28-04 22:52   zope/thread/SETUP.cfg
> 994  07-03-04 04:34   zope/thread/tests.py
> 748  11-08-04 11:00   zope/thread/tests.pyc
> 748  11-08-04 11:00   zope/thread/tests.pyo
> 20480  11-07-04 00:54   zope/thread/_zope_thread.pyd
> 7838  08-17-04 17:20   zope/thread/__init__.py
> 7808  11-08-04 11:00   zope/thread/__init__.pyc
> 7808  11-08-04 11:00   zope/thread/__init__.pyo
> 

zipextimporter, as published, doesn't handle extensions in packages.
The patch I attached at the end, may fix this - I tested it with PIL.

It may work with zope, or may not - depends on how the extensions are
structured.  If there are extensions/pyds that link to other
extensions/pyds, then it will most certainly not work.

If it doesn't work, you could still try the py2exe approach:
py2exe bundles the .py modules in a zip file, and also inserts loaders
for extensions into the zip file.  The loaders load the .pyd extensions
from the file system.

Thomas


Index: zipextimporter.py
===
RCS file: /cvsroot/py2exe/py2exe/hacks/memimp/zipextimporter.py,v
retrieving revision 1.2
diff -c -r1.2 zipextimporter.py
*** zipextimporter.py   16 Dec 2004 09:29:42 -  1.2
--- zipextimporter.py   4 Jan 2005 20:08:08 -
***
*** 50,55 
--- 50,56 
  if result:
  return result
  
+ fullname = fullname.replace(".", "\\")
  for s in self._suffixes:
  if (fullname + s) in self._files:
  return self
***
*** 60,72 
  return zipimport.zipimporter.load_module(self, fullname)
  except zipimport.ZipImportError:
  pass
  for s in self._suffixes:
  path = fullname + s
  if path in self._files:
  # XXX should check sys.modules first ? See PEP302 on reload
  # XXX maybe in C code...
  code = self.get_data(path)
! mod = _memimporter.import_module(code, "init" + fullname)
  mod.__file__ = "%s\\%s" % (self.archive, path)
  mod.__loader__ = self
  if _memimporter.get_verbose_flag():
--- 61,75 
  return zipimport.zipimporter.load_module(self, fullname)
  except zipimport.ZipImportError:
  pass
+ initname = fullname.split(".")[-1]
+ fullname = fullname.replace(".", "\\")
  for s in self._suffixes:
  path = fullname + s
  if path in self._files:
  # XXX should check sys.modules first ? See PEP302 on reload
  # XXX maybe in C code...
  code = self.get_data(path)
! mod = _memimporter.import_module(code, "init" + initname)
  mod.__file__ = "%s\\%s" % (self.archive, path)
  mod.__loader__ = self
  if _memimporter.get_verbose_flag():

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

cxOracle for python 2.4

[Volker Helm]

Hi there,
does anybody knows where I can get the DB interface cx_Oracle for Python 
2.4 with win32.

On http://www.computronix.com/utilities.shtml exists only the version 
for Python 2.3. I would try to compile it myself, if I had a compiler 
and would know how to use it ;-)

Thanks in advance,
Volker
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python evolution: Unease

[Roman Suzi]

On Tue, 4 Jan 2005, Dave Brueck wrote:

>> It may be optional in the sense that the language will
>> accept missing declarations but as soon as the feature
>> is available it will become "mandatory" to use it
>> (peer pressure, workplace practices).

What about generic programming coming into fashion anytime soon?

>That's my fear - type declarations could become one of the most abused language
>features because they'd get used too often.
>
>-Dave
>

Sincerely yours, Roman Suzi
-- 
[EMAIL PROTECTED] =\= My AI powered by GNU/Linux RedHat 7.3
-- 
http://mail.python.org/mailman/listinfo/python-list

python and activex

[yaniv_vi]

Hi ,
Has anybody used jython and visual j++ togheter to do python and
activeX integration ?

is there a simpler way (except win32all , which i feel is non trivial ,
at least not as dragging components )

Thanks ,yaniv

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

Re: The Industry choice

[Scott David Daniels]

Bulba! wrote:
 The Americans show the French engineers a working prototype.
The French engineers scratch their heads and ask warily:
"OK, it works in practice; but will it work in theory?"
I once worked with a computer built by two graduate students who formed
a company.  The scuttlebutt was that they were very different people.
Of one it was said, "his designs are beautiful and provably correct,
but they have the nasty habit of not working when you wire them up."
The other's story was more like, "its amazing, you can prove his
designs cannot possibly work, but every time he builds them, they
seem to work in defiance of every engineering principle."  Both of
them had some version of the social skills of your average technical
genius, that is to say, less than the world normally requires.
When it became known these two were working together, the generally
accepted view was that this company would either produce a
spectacularly fast machine, or at least one of them would be dead.
--Scott David Daniels
[EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list

HTML table input data grid

[Gregor Horvath]

Hi,
I googled for a possibilty to create a html table where the user can 
input data.
I just found this site:

http://www.codeproject.com/aspnet/I3HTree2.asp
That is what I am looking for.
Is there an existing solution for python?
--
Greg
--
http://mail.python.org/mailman/listinfo/python-list

Re: Help clean up clumsy code

[Jeff Shannon]

Scott David Daniels wrote:
Nick Coghlan wrote:
A custom generator will do nicely:
Py> def flatten(seq):
...   for x in seq:
... if hasattr(x, "__iter__"):
...   for y in flatten(x):
... yield y
... else:
...   yield x

Avoiding LBYL gives you:
def flatten(seq):
for x in seq:
try:
for y in flatten(x):
yield y
except TypeError:
yield x
If I'm not mistaken, this will result in infinite recursion on 
strings.  'for x in aString' will iterate over the characters in the 
string, even if the string is only a single character, so "for y in 
flatten('a'):" will not give a type error.  You'd need to add 
special-case tests to watch for this condition (and try not to be too 
special-case and allow unicode objects to pass).

Nick's version works on strings (and unicode objects) because they 
lack an __iter__() method, even though they follow the (older) 
sequence protocol.

Jeff Shannon
Technician/Programmer
Credit International
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python design strategy (was Python evolution: Unease)

[Scott David Daniels]

[EMAIL PROTECTED] wrote:
Viile writes -
Type declarations are a feature that might benefit IronPython and
Jython more than they would CPython.
How much is this part of Guido's decisionmaking process? 
One major reason to allow optional static typing is to aid specializing
compilers.  A language called "Self" had a type system even more
dynamic than Python's, and it was capable of getting to quite
reasonable speeds doing dynamic analysis and specialization.  In
fact, PyPy is quite likely to get great optimization from the
declarations as well as IronPython and JPython.
If for some reason you know the arguments to a function are all
integers, you can create a translation of that function that
only operates on integers, and you can often discover that
operations not only on the arguments, but on partial results,
can all be kept as integers.  These operations can be translated
into very simple operations that avoid method lookup, and can
therefore run much faster.  If, conceptually, some set of
functions and methods always are called with specific types,
those functions and methods can have very high-speed (relatively)
implementations for fairly little cost in compiler complexity.
Such specifications could be spread through the standard library
(if only in the most obvious of places), and provide a _very_
_substantial_ speed improvement for less investment than almost
any of the other techniques around.
Remember, at the core, all current CPUs operate on one or two
data types: integers and floating point.  Wherever they must
distinguish types they must use conditional branches, the slowest
operation on the fastest CPUs being produced today and in the
relatively visible future.  Even when the type specification
is advice about the most common type path, rather than a strict
guarantee of the type, code can be generated that does the test
before choosing which path to choose, and have fast code on the
type-specific path.
--Scott David Daniels
[EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python evolution: Unease

[Bulba!]

On Tue, 4 Jan 2005 15:18:48 -0200, Carlos Ribeiro
<[EMAIL PROTECTED]> wrote:

>> Let's take one by one: 

>I'll take only a few ;-)

>> - IDE: Better than what? Than IDLE? Than Eclipse? Than SPE? Than Pythonwin? 
>
>I would like to seee Eric3, with some polish & opensourced on Win
>(which means solving the Qt licensing problem).

I second that. I still haven't used Eric3 much, which means I didn't
exploit it in full yet, but I like it a lot. And yes, Qt licensing is
a big problem for me, because for non-technical reasons I have
to work on Windows: when my eval Qt license runs out of time, 
no more eric3 for folks like me.



--

Real world is perfectly indifferent to lies that 
are the foundation of leftist "thinking".
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Reaching the real world

[Thomas Bartkus]

"Fuzzyman" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> I have a friend who would like to move and program lights and other
> electric/electro-mechanical devices by computer. I would like to help -
> and needless to say Python would be an ideal language for the
> 'programmers interface'.
>
> What I'd like is an electronic interface that connects to several
> relays and a python extension module to switch on and off the relays.
> I've had a quick google and can't see anything too similar to what I
> want. pyro (python robotics) seems to require expensive (relatively)
> robotic equipment.

Loosely, what you are looking for is Data Acquisition (DAQ) , Digital I/O,
and control that you can do from your pc. Those are the keywords you want to
google.

Look at www.ni.com and poke around. They will have some introductory
material.
Look at www.circuitcellar.com .  It may look a bit overwhelming at first but
look at the ads for pc equipment.  These should also lead you to some
tutorials.

You are looking for simple digital output. You can use an existing serial or
parallel port with a bit of external hardware from radio shack to control
relays on the cheap.
OR
You can purchase a Digital I/O adaptor that will plug into your computer bus
and give you outputs to control your  relays.  You will also get
instructions and some software to interface (talk!) to the adaptor.
Typically you will read and write to the I/O ports on your computer to flip
the switches.
   OR perhaps the easiest and most effective
These would be smart devices that talk to your Python (or whatever!)
software via the serial port. You would throw simple string commands (eg
"ChannelB ON") at the serial port and the microprocessor based controller
will turn on the appropriate relay.

Your challenge from Python will be to control the computers I/O ports or to
communicate with one of the serial ports.  I'm sure someone else will point
to libraries that will help you with this.

Much *much* more but you have to start somewhere :-)
Thomas Bartkus


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

Re: Reaching the real world

[John Machin]

Fuzzyman wrote:
> I have a friend who would like to move and program lights and other
> electric/electro-mechanical devices by computer. I would like to help
-
> and needless to say Python would be an ideal language for the
> 'programmers interface'.

Try Googling for "Python X10"

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

Re: Unicode universe (was Re: Dr. Dobb's Python-URL! - weekly Python news and links (Dec 30))

[Walter Dörwald]

Skip Montanaro wrote:
aahz> Here's the stark simple recipe: when you use Unicode, you *MUST*
aahz> switch to a Unicode-centric view of the universe.  Therefore you
aahz> encode *FROM* Unicode and you decode *TO* Unicode.  Period.  It's
aahz> similar to the way floating point contaminates ints.
That's what I do in my code.  Why do Unicode objects have a decode method
then?
Because MAL implemented it! >;->
It first encodes in the default encoding and then decodes the result
with the specified encoding, so if u is a unicode object
   u.decode("utf-16")
is an abbreviation of
   u.encode().decode("utf-16")
In the same way str has an encode method, so
   s.encode("utf-16")
is an abbreviation of
   s.decode().encode("utf-16")
Bye,
   Walter Dörwald
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python evolution: Unease

[Bulba!]

On Tue, 4 Jan 2005 11:15:54 +0100, [EMAIL PROTECTED] (Alex Martelli)
wrote:

>Also, you keep talking about "the core python team" on the basis, it
>would appear, of reading one document by Guido.  Have you bothered doing
>a MINIMUM of homework, such as, looking at
>http://www.amk.ca/diary/archives/cat_python.html
>and specifically AMK's entry for September 30?  

This complaint about "syntax cruft" is really weird, as while
browsing through the old and new docs I got the impression that
Python hasn't really changed so much as just added new, and
mostly well-chosen features. What's not to like in sets for
instance?!

However, I do have to concede that Python as environment
still has a way to go - not the language features are missing, but 
better _standard_ IDE and debugger. E.g. Pythonwin debugger 
sometimes simply dies on me, I have no idea why. 

This is not to criticize the great work that you 
guys are doing and the results of which we get FOR
FREE (something in principle I don't believe), but merely 
to indicate that Python has grown and so did the 
expectations. People tend to get spoilt: they expect to 
find in a free product the gazillion of VS-like features. :-) 
As we say here, "appetite tends to grow as you eat". 

E.g. right now I would kill for a standard, built-in matrix 
type that would be as flexible as lists and dictionaries are
in Python, so that I could slurp the whole CSV file or some
other table in one instruction into a matrix that could 
accomodate data types likes strings and floats (just like
dictionaries do - just,  say, declare, "column 1 of matrix 
contains strings, and please convert the values in column 2 
into floats"), and then easily do some fancy matrix 
transformations. 

Clean and expressive syntax plus flexibility of lists and 
dictionaries are the main reasons I got into Python. 

Where else could I do smth as neat as writing a 
CSV header with:

DictWriterInstance.writerow(dict(zip(titles,titles)))

Note I didn't have to do any operations myself:
all that was necessary for me as a programmer was to 
figure out how to connect the Lego pieces together.

We need more of this sort of expressive power in a 
standard library and built-in types. This is the subconscious
power of attraction in Python I think. :-) I'm not a language
designer. I don't know how to get there. I just would love 
to see more of that around. 

To summarize, it's not the language that is would be
nice to develop further. Those are:

- more of the rich, flexible data types

- more extensive standard debugger

- possibly standard IDE with more features
that are typically found in commercial products



No, really, guys, great thanks for all that work.


--

Real world is perfectly indifferent to lies that 
are the foundation of leftist "thinking".
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python evolution: Unease

[Dave Brueck]

Istvan Albert wrote:
Doug Holton wrote:
application is so important that I expect Python 3000 will have
optional type declarations integrated into the argument list."

I think that *optional* part of the "optional type declaration"
is a myth.
It may be optional in the sense that the language will
accept missing declarations but as soon as the feature
is available it will become "mandatory" to use it
(peer pressure, workplace practices).
That's my fear - type declarations could become one of the most abused language 
features because they'd get used too often.

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

Re: Pythonic search of list of dictionaries

[Scott David Daniels]

Skip Montanaro wrote:
...lotsa great stuff ...
You might want to sort your lists by the 'English' key.  I don't know how to
use the new key arg to list.sort(), but you can still do it the
old-fashioned way:
oldl.sort(lambda a,b: cmp(a['English'], b['English']))
newl.sort(lambda a,b: cmp(a['English'], b['English']))
To complete the thought, for 2.4 and after the new-fashioned way is:
import operator
oldl.sort(key=operator.itemgetter('English'))
newl.sort(key=operator.itemgetter('English'))
Once sorted, you can then march through the lists in parallel, which should
give you an O(n) algorithm.  
But overall you will have O(n log n) because of the sorts.
--Scott David Daniels
[EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list

Re: Dr. Dobb's Python-URL! - weekly Python news and links (Dec 30)

[Thomas Heller]

Max M <[EMAIL PROTECTED]> writes:

> Thomas Heller wrote:
>
>> It seems also the error messages aren't too helpful:
>>
>"ä".encode("latin-1")
>> Traceback (most recent call last):
>>   File "", line 1, in ?
>> UnicodeDecodeError: 'ascii' codec can't decode byte 0x84 in position 0: 
>> ordinal not in range(128)
>> Hm, why does the 'encode' call complain about decoding?
>
> Because it tries to print it out to your console and fail. While
> writing to the console it tries to convert to ascii.

Wrong, same error without trying to print something:

>>> x = "ä".encode("latin-1")
Traceback (most recent call last):
  File "", line 1, in ?
UnicodeDecodeError: 'ascii' codec can't decode byte 0x84 in position 0: ordinal 
not in range(128)
>>>

>
> Beside, you should write:
>
> u"ä".encode("latin-1") to get a latin-1 encoded string.

I know, but the question was: why does a unicode string has a encode
method, and why does it complain about decoding (which has already been
answered in the meantime).

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

Re: lies about OOP

[Mike Brenner]

> ... C++ *appears* to increase the cost of fixing defects ...

Some additional points:

Some languages allow direct pointer manipulation 
which favors certain classes of bugs.
This is independent of whether the language is OO,
and these are probably the most costly defects
to find (hanging pointers, buffer overflows,
array index busting, memory leakages, etc.).

Some languages have strong type checking, which
reduces some classes of bugs.
This is independent of whether the language is OO.

Some people like to think they are OO
if they wrap every incoming piece of data
in get/put methods in classes. This reduces
some categories of errors at the cost of
flexibility. When the input format changes,
the code needs serious modification everywhere.
This is also independent of whether the
language is OO, and is a matter of style.

While python classes permit you to wrap everything,
python classes are so "thin" a wrapper that
it is as if they almost aren't wrapped.

A trend for style would be to use OO for 
the methods on stable objects (a continually
decreasing breed over time) and use
data-driven methods to permit handling
data of very flexible input formats.
This trend will permit more use of 
techniques like XSLT, where data
structures define the transformations
instead of classical code, and 
techniques like semantical analysis
using ontologies, taxonomies, 
thesaurii, dictionaries, and 
mappings of semantics into real-world contexts.

In other words, data-driven software
is not top-down (problem-oriented).
It is also not bottom-up (object-oriented).
It is simply data-oriented, and 
totally driven by the input data.

This trend will result in the number of 
lines of code going down, the cost of
software going down, and the consciousness
of data relationships going up.

We will then see Python-D, the python Data
language. 

While Python said: "indentation
of code is everything", Python-D will say:
all the relational arrows in your
dataflow diagram (which IS your code)
must be pointing upwards.

While Python said: "simplify, 
reduce coupling, increase cohesion
of the software, and do tricks with lambda", 
Python-D will say: "simplify, 
reduce coupling, and increase cohesion
of the data, and do tricks with metadata."

Mike Brenner


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

RE: Python evolution: Unease

[Batista, Facundo]

Title: RE: Python evolution: Unease





[Skip Montanaro]


#- This being the Internet and all, it's not clear that 
#- referencing external
#- documentation is somehow worse than incorporating it 
#- directly into the
#- distribution.


The problem is Internet access.


For example, once I put together a "Python CD" as a present for my father. Inside it put Linux & Windows installers (Python itself and wxWindows (this name then)).

And of course, the whole documentation package, in PDF. Of course, I didn't parse the whole docs to see what other documents I could include.

And to my father is kinda complicated (and expensive!) access internet and read the docs there.


I mean, it's perfectly possible, but would be better IMO to have the docs concentrated.



.    Facundo


Bitácora De Vuelo: http://www.taniquetil.com.ar/plog
PyAr - Python Argentina: http://pyar.decode.com.ar/



  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

ADVERTENCIA.


La información contenida en este mensaje y cualquier archivo anexo al mismo, son para uso exclusivo del destinatario y pueden contener información confidencial o propietaria, cuya divulgación es sancionada por la ley.

Si Ud. No es uno de los destinatarios consignados o la persona responsable de hacer llegar este mensaje a los destinatarios consignados, no está autorizado a divulgar, copiar, distribuir o retener información (o parte de ella) contenida en este mensaje. Por favor notifíquenos respondiendo al remitente, borre el mensaje original y borre las copias (impresas o grabadas en cualquier medio magnético) que pueda haber realizado del mismo.

Todas las opiniones contenidas en este mail son propias del autor del mensaje y no necesariamente coinciden con las de Telefónica Comunicaciones Personales S.A. o alguna empresa asociada.

Los mensajes electrónicos pueden ser alterados, motivo por el cual Telefónica Comunicaciones Personales S.A. no aceptará ninguna obligación cualquiera sea el resultante de este mensaje.

Muchas Gracias.



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

Re: Dr. Dobb's Python-URL! - weekly Python news and links (Dec 30)

[Max M]

Thomas Heller wrote:
It seems also the error messages aren't too helpful:
"ä".encode("latin-1")
Traceback (most recent call last):
  File "", line 1, in ?
UnicodeDecodeError: 'ascii' codec can't decode byte 0x84 in position 0: ordinal 
not in range(128)
Hm, why does the 'encode' call complain about decoding?
Because it tries to print it out to your console and fail. While writing 
to the console it tries to convert to ascii.

Beside, you should write:
u"ä".encode("latin-1") to get a latin-1 encoded string.
--
hilsen/regards Max M, Denmark
http://www.mxm.dk/
IT's Mad Science
--
http://mail.python.org/mailman/listinfo/python-list

RE: Pexpect getting a defuct process

[Jorge Luiz Godoy Filho]

Baillargeon, Sonny, TerÃa 04 Janeiro 2005 16:16, wrote:

> Nothing...I know that's the default answer but considering I control the
> environment, I can assure you that nothing changed.

I have no reason to doubt you.  :-)

Checking pexpect's documentation, and re-reading your code I see that you
have not called "close()".  As the documentation says:

(http://pexpect.sourceforge.net/doc/pexpect.html)
"""
close(self, wait=1)
(...)
Only set wait to false if you know the child will
continue to run after closing the controlling TTY.
Otherwise you will end up with defunct (zombie) processes.
"""


Be seeing you,
-- 
Godoy. <[EMAIL PROTECTED]>

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

Re: Cookbook 2nd ed Credits (was Re: The Industry choice)

[Brian van den Broek]

Alex Martelli said unto the world upon 2005-01-04 11:15:
<[EMAIL PROTECTED]> wrote:

But then I have THREE published recipes!!
Does that mean that I get three free copies of the cookbook ? ;-)

...ti piacerebbe eh...?-)  Sorry, "one each", even though you have
_five_ credits.  For the curious, here's the roster of most credited
contributors (remember, significant comments we merged into other's
recipes also count!-)...:

If you wished to count only _authored_ recipes (but that's a bit
misleading, since in several recipes-as-published there is a merge of
two or three separately submitted and accepted recipes, and here I'm
counting only the first-listed-author per published-recipe...):
 1: 25 u'Luther Blissett'

...but each still gets ONE free copy...!-)
Alex
Since I'm certain Luther won't be claiming his copy ;-) perhaps we could 
auction it off?

Best,
Brian vdB
--
http://mail.python.org/mailman/listinfo/python-list

Re: The Industry choice

[Bulba!]

On Mon, 03 Jan 2005 20:16:35 -0600, "Rob Emmons"
<[EMAIL PROTECTED]> wrote:
>> 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. 

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.

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

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.

See:

http://blogs.sun.com/roller/page/bmc/20040828#the_economics_of_software

IMHO this:

'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.'

...hits the nail on the head.


>> 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, 

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".

>(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. 

That doesn't seem like a good idea to me. 

>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.

As much as people tend to hate outsourcing, it frequently _does_
increase the efficiency of the industries, see this paper:

http://econpapers.hhs.se/article/fipfednep/y_3A2003_3Ai_3Asep_3Ap_3A23-33_3An_3Av.9no.3.htm


--

Real world is perfectly indifferent to lies that 
are the foundation of leftist "thinking".
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Hlelp clean up clumpsy code

[It's me]

What's "LBYL"?  Oh...Look-before-you-leap.  OK.

I think I understand what's going on now (I read up on generator and
iterators and my head still hurts).  I knew there must be a cleaner way of
"walking" around in Python.  I will experiment with generator more.

Thanks everybody.


"Jp Calderone" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
>
> On Tue, 04 Jan 2005 08:18:58 -0800, Scott David Daniels
<[EMAIL PROTECTED]> wrote:
> >Nick Coghlan wrote:
> > > A custom generator will do nicely:
> > >
> > > Py> def flatten(seq):
> > > ...   for x in seq:
> > > ... if hasattr(x, "__iter__"):
> > > ...   for y in flatten(x):
> > > ... yield y
> > > ... else:
> > > ...   yield x
> >
> > Avoiding LBYL gives you:
> >  def flatten(seq):
> >  for x in seq:
> >  try:
> >  for y in flatten(x):
> >  yield y
> >  except TypeError:
> >  yield x
>
>   But totally messes up on error handling.  Instead:
>
> def flatten(seq):
> for x in seq:
> try:
> subseq = iter(x)
> except TypeError:
> yield x
> else:
> for subx in flatten(subseq):
> yield subx
>
>   to avoid catching TypeErrors from .next().
>
>   Jp


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

RE: Pexpect getting a defuct process

[Baillargeon, Sonny]

Nothing...I know that's the default answer but considering I control the 
environment, I can assure you that nothing changed. 

-Original Message-
From: Jorge Luiz Godoy Filho [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, January 04, 2005 12:06 PM
To: python-list@python.org
Subject: Re: Pexpect getting a defuct process

Baillargeon, Sonny, Terça 04 Janeiro 2005 14:42, wrote:

> This used to work before but now I get a defunct process after it runs.
> Any ideas?

"before" what?  What has changed in your environment to make it stop working? 

-- 
Godoy. <[EMAIL PROTECTED]>






This e-mail and any attachments may contain confidential and privileged 
information. If you are not the intended recipient, please notify the sender 
immediately by return e-mail, delete this e-mail and destroy any copies. Any 
dissemination or use of this information by a person other than the intended 
recipient is unauthorized and may be illegal. Unless otherwise stated, opinions 
expressed in this e-mail are those of the author and are not endorsed by the 
author's employer.

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

Re: The Industry choice

[Bulba!]

On Sun, 2 Jan 2005 23:59:53 -0800, "Eric Pederson" <[EMAIL PROTECTED]>
wrote:

>I'm decades behind on economics research, but I remember 
>modeling clustering based on mass and distance (the gravity model).  
>On a decision making basis there seems to be an aspect of it that is 
>binary: (0) either give in to gravity and gain shared advantage as 
>part of a massive object, or (1) choose an alternate "location" far 
>enough away not to be much affected by the force of the massive 
>objects, and try to build "mass" there.  I suspect Python is a (1) in 
>that regard, but I may be wrong.

Frankly, I find such models to be built on over-stretched analogies
to physics - how _exactly_ is gravity supposed to be an analogy
equivalent to economic "forces"? Sure such model can be built - but
is it adequate in explaining real-world phenomenons? Analogy
tends to be the weakest form of reasoning. I'd be wary of making
such analogies.

Models like this probably tend to be built by French engineers from
this joke:

The American and French engineers work together on some 
product (that would look strange nowadays but it's not impossible 
in principle). 

The Americans show the French engineers a working prototype.

The French engineers scratch their heads and ask warily:

"OK, it works in practice; but will it work in theory?"



--

Real world is perfectly indifferent to lies that 
are the foundation of leftist "thinking".
-- 
http://mail.python.org/mailman/listinfo/python-list