Re: Calling Python functions from Excel

[Carsten Haese]

Cannonbiker wrote:
> Please I need Calling Python functions from Excel and receive result
> back in Excel. Can me somebody advise simplest solution please? I am
> more VBA programmer than Python.

Maybe this will help:
http://oreilly.com/catalog/pythonwin32/chapter/ch12.html (Scroll down to
"Implementing a COM Server.")

--
Carsten Haese
http://informixdb.sourceforge.net

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

Re: python simply not scaleable enough for google?

[greg]

John Nagle wrote:

   Take a good look at Shed Skin.  ...
You give up some flexibility; a variable can have only one primitive type
in its life, or it can be a class object.  That's enough to simplify the
type analysis to the point that most types can be nailed down before the
program is run.


These restrictions mean that it isn't really quite
Python, though.

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

Calling Python functions from Excel

[Cannonbiker]

Hi,
unfortunately is my question about server COM (win32com)
http://groups.google.com/group/comp.lang.python/browse_thread/thread/ee804cec7f58c6a7#
without answer.

Please I need Calling Python functions from Excel and receive result
back in Excel. Can me somebody advise simplest solution please? I am
more VBA programmer than Python.

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

Re: python simply not scaleable enough for google?

[Terry Reedy]

John Nagle wrote:

Steven D'Aprano wrote:

   Take a good look at Shed Skin.  One guy has been able to build a system
that compiles Python to C++, without requiring the user to add 
"annotations" about types.


In *only* compiles a subset of Python, as does Cython. Both cannot 
(currently) do generators, but that can be done and probably will 
eventually at least for Cython. Much as I love them, they can be 
rewritten by hand as iterator classes and even then are not needed for a 
lot of computational code.


I think both are good pieces of work so far.

>  The system uses type inference to figure it out itself.

You give up some flexibility; a variable can have only one primitive type
in its life, or it can be a class object.  That's enough to simplify the
type analysis to the point that most types can be nailed down before the
program is run.  (Note, though, that the entire program may have to
be analyzed as a whole.  Separate compilation may not work; you need
to see the callers to figure out how to compile the callees.)

   It's 10 to 60x faster than CPython.

   It's the implementation, not the language.  Just because PyPy was a
dud doesn't mean it's impossible. There are Javascript JIT systems
far faster than Python.

   Nor do you really need a JIT system.  (Neither does Java; GCC has
a hard-code Java compiler.  Java is JIT-oriented for historical reasons.
Remember browser applets?)  If you're doing server-side work, the
program's structure and form have usually been fully determined by
the time the program begins execution.

John Nagle


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

Re: python simply not scaleable enough for google?

[Rami Chowdhury]

On Saturday 14 November 2009 18:42:07 Vincent Manis wrote:
> 
> 3. Very clearly CPython can be improved. I don't take most benchmarks
>  very seriously, but we know that CPython interprets bytecode, and
>  thus suffers relative to systems that compile into native code, and
>  likely to some other interpretative systems. (Lua has been
>  mentioned, and I recall looking at a presentation by the Lua guys on
>  why they chose a register rather than stack-based approach.)
> 

For those interested in exploring the possible performance benefits of 
Python on a register-based VM, there's Pynie 
(http://code.google.com/p/pynie/)... and there's even a JIT in the works 
for that (http://docs.parrot.org/parrot/1.0.0/html/docs/jit.pod.html)...



Rami Chowdhury
"A man with a watch knows what time it is. A man with two watches is 
never sure". -- Segal's Law
408-597-7068 (US) / 07875-841-046 (UK) / 0189-245544 (BD)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A "terminators' club" for clp

[Aahz]

In article <7xiqddt1fd@ruckus.brouhaha.com>,
Paul Rubin   wrote:
>
>There is automatic moderation software that auto-approves any post
>from an address that has had one or two posts manually approved.
>While that's susceptible to address forgery, the typical spammer
>doesn't do that.

There's even auto-mod with e-mail confirmation (similar to subscribing to
a mailing list), see soc.singles.moderated.
-- 
Aahz (a...@pythoncraft.com)   <*> http://www.pythoncraft.com/

[on old computer technologies and programmers]  "Fancy tail fins on a
brand new '59 Cadillac didn't mean throwing out a whole generation of
mechanics who started with model As."  --Andrew Dalke
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Documentation bugs in 3.1 - C-API - TypeObjects

[DreiJane]

Thanks !

Okay, i've already used the call of tp_free as the last
statement in tp_dealloc and do understand now, that a
call of tp_dealloc should be the last statement in the
code for tp_free in specific cases.

And yes, "Py_Type(&Foo_Type) = &PyType_Type" will be
more stable against changes of the object implementation.
Still there remains the difference to what is told with the
Noddy_Type in the tutorial.

Skimmimg through PyType_Ready in typeobject.c i find,
that

3760 if (Py_TYPE(type) == NULL && base != NULL)
3761  Py_TYPE(type) = Py_TYPE(base);

are the only lines referring to what is ob_type now. Thus
the quoted lines from the tutorial ending with "Fortunately,
this member will be filled in for us by PyType_Ready()."
are possibly wrong (respective outdated) too.

The two lines above are, what happens to my extension
classes, if i want to derive application classes from them.

class(my_extension_class): ...

will of course call more from Python than PyTypeReady,
but PyType(type) = Py_TYPE(base) is not getting corrected
by this "more" here and the class statement doesn't create
a new type. I will examine now, why this happens (without
a crash of the calling application !), but still welcome every
hint.  Seen from a strict perspective this is a bug in Python's
C-API. I'll save a freeze of the code for my extension for
anyone, who might interested to reproduce this.

Joost

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

Re: A "terminators' club" for clp

[Aahz]

In article <877htsskox@benfinney.id.au>,
Ben Finney   wrote:
>Terry Reedy  writes:
>>
>> So, the only reason to use c.l.p is if one wants to post anonymously,
>> like the spammers do ;-).
>
>Or if one has an ISP who provides a Usenet feed, like mine does.

Mine does, too.

>A pox upon Andrew Cuomo for bashing ISPs in the USA with the stick of
>“child pornography” (which he discovered on 88 out of many thousands of
>forums). Faced with the unreasonable role of policing Usenet, they shut
>it all off http://news.cnet.com/8301-13578_3-9964895-38.html>.

Actually, my ISP is in New York City.
-- 
Aahz (a...@pythoncraft.com)   <*> http://www.pythoncraft.com/

[on old computer technologies and programmers]  "Fancy tail fins on a
brand new '59 Cadillac didn't mean throwing out a whole generation of
mechanics who started with model As."  --Andrew Dalke
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python & Go

[Michele Simionato]

Let me add a quote from the FAQ:

"""
Why does Go not have exceptions?

Exceptions are a similar story. A number of designs for exceptions
have been proposed but each adds significant complexity to the
language and run-time. By their very nature, exceptions span functions
and perhaps even goroutines; they have wide-ranging implications.
There is also concern about the effect they would have on the
libraries. They are, by definition, exceptional yet experience with
other languages that support them show they have profound effect on
library and interface specification. It would be nice to find a design
that allows them to be truly exceptional without encouraging common
errors to turn into special control flow that requires every
programmer to compensate.

Like generics, exceptions remain an open issue.
"""
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python as network protocol

[Aahz]

In article ,
Cooch   wrote:
>
>I want to implement such specific feature:
>I have a server written in Python. I have a client written in C++. I
>want to use Python as network protocol between them. I mean: client
>send to server such string: "a = MyObject()", so object of this type
>will appear in server. Any ideas how to simplify this implementation?
>I make XML-RPC/SOAP server using twisted which just execute sended
>string. But I don't know how to:
>1. Restrict usage of some modules on client side (os, sys etc..)
>2. Divide variables of different clients. Generally, I know that I
>should use "exec .. in .. " construct, but don't know how to
>distinguish between clients in twisted.

What you want is a DSL -- domain-specific language.  That might be a
subset of Python that you parse yourself.
-- 
Aahz (a...@pythoncraft.com)   <*> http://www.pythoncraft.com/

[on old computer technologies and programmers]  "Fancy tail fins on a
brand new '59 Cadillac didn't mean throwing out a whole generation of
mechanics who started with model As."  --Andrew Dalke
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A different take on finding primes

[Dave Angel]

Vincent Davis wrote:

Out of pure curiosity I would like to compare the efficiency of different
methods of finding primes (need not be consecutive). Let me be clear, given
2min, how many primes can you find, they need not be in order or
consecutive. I have not seen any examples of this. I am assume the solution
is different depending on the time give,  2min or 2 hours. I assume a sieve
solution would be best for larger times. When the numbers get really large
checking to see if they are a prime gets costly.
So what do you think?

  *Vincent Davis
720-301-3003 *
vinc...@vincentdavis.net
 my blog  |
LinkedIn

  
The sieve can be very efficiently written, but you have to decide 
whether to optimize for memory size or for speed.  At a minimum for size 
you need an object for each prime currently found, and you will be 
looking through that list for each new candidate.  Incidentally this 
approach can be done without any division.  If you have memory to burn, 
you make a bit array equal in size to the largest prime you expect to 
encounter.


There are also good algorithms for deciding whether a number of a 
particular form is prime.  For example, there's a test for numbers of 
the form 2**n + 1.


And don't forget the Miller-Rabin test.

DaveA



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

Re: Easy way to play single musical notes in Python

[r]

On Nov 14, 6:21 pm, James Harris 
wrote:
> Is there a simple way to play musical notes in Python? Something like
>   voice.play("c4")


Uhh, tksnack is pretty easy to use IMO, see this link...
http://www.daniweb.com/code/snippet216655.html

No python does not have access to cross platform soundcard
capabilities built into the language. I think there is a wrapper for
csound somewhere. But there are many 3rd party modules that do have
capabilities to some extent. You could make calls to the underlying OS
machinery and there is the winsound module (not exactly what you want
though). Just look over this Google splooge...

http://www.google.com/search?hl=en&rlz=1C1CHMI_enUS340US340&q=Python+sound&aq=f&oq=&aqi=g10
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Req. comments on "first version" ch 2 progr. intro (using Python 3.x in Windows)

[Aahz]

In article ,
sstein...@gmail.com  wrote:
>On Nov 9, 2009, at 11:54 AM, Jon Clements wrote:
>> On Nov 9, 4:10 pm, "Alf P. Steinbach"  wrote:
>>> First, because as opposed to ch 1 there is quite a bit of code  
>>> here, and since I'm a
>>> Python newbie I may be using non-idiomatic constructs,
>
>Welp, there goes my last excuse.
>
>I'm off to write my book:
>
>Heart Surgery at Home
>
>   ***
>How to Save Thousands and
>Get Results Just Like in Hospital
>   
>
>Chapter 1: Sanitation, Schmanitation: How Clean is Clean Enough?
>Chapter 2: Surgical Tools vs. Ginsu: How Sharp is Sharp Enough?
>Chapter 3: Gray's Anatomy and Sharpies: Laying out The Surgery
>Chapter 4: Before You Start: Charging Your Cell Phone, and Testing 911
>Chapter 5: Anesthesia: Jack Daniels or Smirnoffs; How Much is Enough?
>Chapter 6: The Insanity Defense: Laying the Groundwork with 6 Month Plan
>
>That's as far as I've gotten...
>
>Amazon best seller list, here I come!

+1 QOTW
-- 
Aahz (a...@pythoncraft.com)   <*> http://www.pythoncraft.com/

[on old computer technologies and programmers]  "Fancy tail fins on a
brand new '59 Cadillac didn't mean throwing out a whole generation of
mechanics who started with model As."  --Andrew Dalke
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python & Go

[Michele Simionato]

On Nov 15, 3:00 am, Terry Reedy  wrote:
> It seems to me that generators are already 'channels' that connect the
> calling code to the __next__ method, a semi-coroutine based on the body
> of the generator function. At present, the next method waits until an
> object is requested. Then it goes into action, yields an object, and
> rests again.
>
> I see no reason why we cannot have that with Python. I not even sure we
> cannot have it with CPython, but I am not familiar enough with threads,
> processes, and CPython internals.

Of course we can have Go capabilities with Python. We already have
generators and the multiprocessing module. It is just a matter of
performance: I assume the Go implementation is more efficient. It
would be nice to have numbers to quantify this claim. One can still
write prototypes in Python and convert them in Go and the process
looks less cumbersome than converting them in C or C++. I could never
force myself to write C or C++; but I do not have any particular
resistence to coding in Go, should I need a performance-oriented
language.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python & Go

[Michele Simionato]

On Nov 14, 7:18 pm, John Nagle  wrote:
>      Leaving out exceptions was a mistake.  Exceptions are well understood 
> now,
> and they're far better than the usual "ignore errors" approach one sees in 
> lamer
> C programs.

I am also surprised about the lack of exceptions. I could infer that
Rob Pike and Ken Thompson are idiots that lack experience with
languages with exceptions, or I could infer that they have reasons for
doing so. I do not know about exceptions enough to have an opinion
myself. However I will notice that in Python, when using threads,
exceptions do not work so well: if I forget to trap an exception in a
thread I see a traceback on stderr, but the other threads continue to
run, basically ignoring the exception. Probably the language that get
things right is Erlang, which is supervising all crashed process and
it is designed to safely recover for unexpected events.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: QuerySets in Dictionaries

[Steven D'Aprano]

On Fri, 13 Nov 2009 14:10:10 -0800, scoopseven wrote:

> I actually had a queryset that was dynamically generated, so I ended up
> having to use the eval function, like this...
> 
> d = {}
> for thing in things:
> query_name = 'thing_' + str(thing.id) 
> query_string = 'Thing.objects.filter(type=' + str(thing.id) +  
> ').order_by(\'-date\')[:3]'
> executable_string = query_name + ' = Thing.objects.filter
> (type=' + str(thing.id) + ').order_by(\'-date\')[:3]'
> exec(executable_string)
> d[query_name] = eval(query_string)


What an unmaintainable mess.

If I've understood it, you can make it less crap by (1) getting rid of 
the unnecessary escaped quotes, (2) avoiding generating the same strings 
multiple times, and (3) avoiding string concatenation.

d = {}
for thing in things:
expr = "Thing.objects.filter(type=%s).order_by('-date')[:3]"
expr = rhs % thing.id
name = "thing_%s" % thing.id
exec("%s = %s" % (name, expr))
d[name] = eval(expr)


What else can we do to fix it? Firstly, why are you creating local 
variables "thing_XXX" (where XXX is the thing ID) *and* dictionary keys 
of exactly the same name? I'm sure you don't need the local variables. 
(If you think you do, you almost certainly don't.) That gets rid of the 
exec.

Next, let's get rid of the eval:

d = {}
for thing in things:
x = thing.id
name = "thing_%s" % x
d[name] = Thing.objects.filter(type=x).order_by('-date')[:3]


About half the size, ten times the speed, and 1000 times the readability.

Unless I've missed something, you don't need either exec or eval.



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

Re: python simply not scaleable enough for google?

[John Nagle]

Steven D'Aprano wrote:

On Wed, 11 Nov 2009 16:38:50 -0800, Vincent Manis wrote:


I'm having some trouble understanding this thread. My comments aren't
directed at Terry's or Alain's comments, but at the thread overall.

1. The statement `Python is slow' doesn't make any sense to me. Python
is a programming language; it is implementations that have speed or lack
thereof.


Of course you are right, but in common usage, "Python" refers to CPython, 
and in fact since all the common (and possibly uncommon) implementations 
of Python are as slow or slower than CPython, it's not an unreasonable 
short-hand.


   Take a good look at Shed Skin.  One guy has been able to build a system
that compiles Python to C++, without requiring the user to add "annotations"
about types.  The system uses type inference to figure it out itself.
You give up some flexibility; a variable can have only one primitive type
in its life, or it can be a class object.  That's enough to simplify the
type analysis to the point that most types can be nailed down before the
program is run.  (Note, though, that the entire program may have to
be analyzed as a whole.  Separate compilation may not work; you need
to see the callers to figure out how to compile the callees.)

   It's 10 to 60x faster than CPython.

   It's the implementation, not the language.  Just because PyPy was a
dud doesn't mean it's impossible. There are Javascript JIT systems
far faster than Python.

   Nor do you really need a JIT system.  (Neither does Java; GCC has
a hard-code Java compiler.  Java is JIT-oriented for historical reasons.
Remember browser applets?)  If you're doing server-side work, the
program's structure and form have usually been fully determined by
the time the program begins execution.

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

Re: Anything better than shutil?

[Steven D'Aprano]

On Sat, 14 Nov 2009 07:48:39 -0800, Roy Smith wrote:

> I'm converting some old bash scripts to python.  There's lots of places
> where I'm doing things like "rm $source_dir/*.conf".  The best way I can
> see to convert this into python is:
> 
> configs = glob.glob(os.path.join(source_dir, '*.conf')) 
> for conf_file in configs:
> shutil.copy(conf_file, conf_dir)
> 
> which is pretty clunky.

Particularly since you're converting a remove to a copy...

I suppose if you're used to the sort of terse code filled with magic 
characters that you find in bash, then the Python code might seem a bit 
verbose. And I suppose you would be right :) But trying to do something 
complicated in bash rapidly becomes *far* more verbose, unreadable and 
clunky than Python.



> The idea interface I see would be one like:
> 
>   shutil.copy([source_dir, '*.conf'], conf_dir)

Then write a helper function, and call that.

# Untested.
def copy(glb, destination):
if not isinstance(glb, str):
glb = os.path.join(*glb)
glb = glob.glob(glb)
for source in glb:
shutil.copy(source, destination)



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

Re: Python & Go

[Steven D'Aprano]

On Sat, 14 Nov 2009 11:14:04 +, kj wrote:

> In <7xpr7lixnn@ruckus.brouhaha.com> Paul Rubin
>  writes:
> 
>>It seems a little weird to me that they (Google) are concerned with the
>>speed of the compiler, indicating that they plan to write enormous
>>programs in the language.
> 
> Fast compilation also means that Go can conceivably become an attractive
> alternative to interpreted languages, because the compilation stage can
> be made as unobtrusive as, say, Python's byte-compilation stage (except
> that the Go compiler is generating native code).


Python (like many other languages) already has unobtrusive compilation. 
That's why you get .pyc files, and that's what the compile() built-in 
function does. It is compilation to byte-code rather than machine-code, 
but still.

Psyco does JIT compilation to machine-code for CPython, at the cost of 
much extra memory. It's also limited to 32-bit Intel processors. The aim 
of the PyPy project is to (eventually) make JIT machine-code compilation 
available to any Python, on any machine.


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

Re: The ol' [[]] * 500 bug...

[Steven D'Aprano]

On Fri, 13 Nov 2009 21:26:01 +, kj wrote:

> ...just bit me in the "fuzzy posterior".  

It's not a bug. Just because it doesn't behave as you would like it to 
behave doesn't mean it isn't behaving as designed.


> The best I can come up with is the hideous
>
>   lol = [[] for _ in xrange(500)]

That's not hideous.

 
> Is there something better?  What did one do before comprehensions were
> available?  I suppose in that case one would have to go all the way with
> 
>   lol = [None] * 500
>   for i in xrange(len(lol)):
>   lol[i] = []
> 
> Yikes.  10 miles uphill, both ways...

What's wrong with that?


lol = []
for _ in xrange(500): lol.append([])


is a simple alternative too, although the list comp is better.


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

Re: Vote on PyPI comments

[Steven D'Aprano]

On Fri, 13 Nov 2009 07:53:05 -0800, Michele Simionato wrote:

> I am skeptical about the utility of both rating and comments. If
> somebody wants to know
> if a package is good, she should ask here.

Because unlike people writing comments, people here are never 
incompetent, misinformed, dishonest, confused, trolling or just wrong.


But sometimes sarcastic.


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

Re: python simply not scaleable enough for google?

[Steven D'Aprano]

On Fri, 13 Nov 2009 18:25:59 -0800, Vincent Manis wrote:

> On 2009-11-13, at 15:32, Paul Rubin wrote:
>>   This is Usenet so
>> please stick with Usenet practices.
> Er, this is NOT Usenet.

Actually it is. I'm posting to comp.lang.python.


> 1. I haven't, to the best of my recollection, made a Usenet post in this
> millennium.

Actually you have, you just didn't know it.


> 2. I haven't fired up a copy of rn or any other news reader in at least
> 2 decades.
> 
> 3. I'm on the python-list mailing list, reading this with Apple's Mail
> application, which actually doesn't have convenient ways of enforcing
> `Usenet practices' regarding message format.

Nevertheless, the standards for line length for email and Usenet are 
compatible.


> 4. If we're going to adhere to tried-and-true message format rules, I
> want my IBM 2260 circa 1970, with its upper-case-only display and weird
> little end-of-line symbols.

No you don't, you're just taking the piss.


> Stephen asked me to wrap my posts. I'm happy to do it. Can we please
> finish this thread off and dispose of it?

My name is actually Steven, but thank you for wrapping your posts.



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

Re: Simple object reference

[Chris Rebert]

On Sat, Nov 14, 2009 at 6:53 PM, Terry Reedy  wrote:
> Chris Rebert wrote:
>> On Sat, Nov 14, 2009 at 3:25 PM, AON LAZIO  wrote:
>>> Hi, I have some problem with object reference
>>> Say I have this code
>>>
>>> a = b = c = None
>>> slist = [a,b,c]
>>
>> Values are stored in the list, not references to names.
>
> That is not right either, or else newbies would not be surprised by
 a = [0]
 b = [a]
 b[0][0] = 1
 a
> [1]
>
> Subscriptable collections associate subscripts with objects.
> Namespaces associated names with objects.
> In either case, if you change the object, you change it, regardless of how
> you access it, such as by means of other associations.
> If you replace an association by associating a name or subscript with a new
> object, the old object is untouched (unless that was its last association)
> and other access methods by means of other associations are not affected.

Okay, I should have technically said "references to objects" rather
than "values", but in any case, names themselves are certainly not
referenced or the following would print "[1]".

>>> a = [0]
>>> b = [a]
>>> a = [42]
>>> b[0][0] = 1
>>> a
[42]

Cheers,
Chris
--
http://blog.rebertia.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Simple object reference

[Terry Reedy]

Chris Rebert wrote:

On Sat, Nov 14, 2009 at 3:25 PM, AON LAZIO  wrote:

Hi, I have some problem with object reference
Say I have this code

a = b = c = None
slist = [a,b,c]


Values are stored in the list, not references to names.


That is not right either, or else newbies would not be surprised by
>>> a = [0]
>>> b = [a]
>>> b[0][0] = 1
>>> a
[1]

Subscriptable collections associate subscripts with objects.
Namespaces associated names with objects.
In either case, if you change the object, you change it, regardless of 
how you access it, such as by means of other associations.
If you replace an association by associating a name or subscript with a 
new object, the old object is untouched (unless that was its last 
association) and other access methods by means of other associations are 
not affected.


Terry Jan Reedy

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

Re: python simply not scaleable enough for google?

[Vincent Manis]

This whole thread has now proceeded to bore me senseless. I'm going to respond 
once with a restatement of what I originally said. Then I'm going to drop it, 
and
never respond to the thread again. Much of what's below has been said by others 
as well; I'm taking no credit for it, just trying to put it together into a 
coherent
framework. 

1. The original question is `Is Python scalable enough for Google' (or, I 
assume 
any other huge application). That's what I was responding to.

2. `Scalable' can mean performance or productivity/reliability/maintenance 
quality.
A number of posters conflated those. I'll deal with p/r/m by saying I'm not 
familiar 
with any study that has taken real enterprise-type programs and compared, e.g., 
Java, Python, and C++ on the p/r/m criteria. Let's leave that issue by saying 
that 
we all enjoy programming in Python, and Python has pretty much the same feature 
set (notably modules) as any other enterprise language. This just leaves us with
performance. 

3. Very clearly CPython can be improved. I don't take most benchmarks very 
seriously, 
but we know that CPython interprets bytecode, and thus suffers relative to 
systems 
that compile into native code, and likely to some other interpretative systems. 
(Lua
has been mentioned, and I recall looking at a presentation by the Lua guys on 
why they
chose a register rather than stack-based approach.)

4. Extensions such as numpy can produce tremendous improvements in productivity 
AND
performance. One answer to `is Python scalable' is to rephrase it as `is 
Python+C 
scalable'. 

5. There are a number of JIT projects being considered, and one or more of 
these might 
well hold promise. 

6. Following Scott Meyers' outstanding advice (from his Effective C++ books), 
one should
prefer compile time to runtime wherever possible, if one is concerned about 
performance. 
An implementation that takes hints from programmers, e.g., that a certain 
variable is 
not to be changed, or that a given argument is always an int32, can generate 
special-case
code that is at least in the same ballpark as C, if not as fast. 

This in no way detracts from Python's dynamic nature: these hints would be 
completely
optional, and would not change the semantics of correct programs. (They might 
cause
programs running on incorrect data to crash, but if you want performance, you 
are kind of 
stuck). These hints would `turn off' features that are difficult to compile 
into efficient
code, but would do so only in those parts of a program where, for example, it 
was known that
a given variable contains an int32. Dynamic (hint-free) and somewhat 
less-dynamic (hinted)
code would coexist. This has been done for other languages, and is not a 
radically new 
concept. 

Such hints already exist in the language; __slots__ is an example. 

The language, at least as far as Python 3 is concerned, has pretty much all the 
machinery 
needed to provide such hints. Mechanisms that are recognized specially by a 
high-performance
implementation (imported from a special module, for example) could include: 
annotations, 
decorators, metaclasses, and assignment to special variables like __slots__.

7. No implementation of Python at present incorporates JITting and hints fully. 
Therefore, 
the answer to `is CPython performance-scalable' is likely `NO'. Another 
implementation that 
exploited all of the features described here might well have satisfactory 
performance for 
a range of computation-intensive problems. Therefore, the answer to `is the 
Python language 
performance-scalable' might be `we don't know, but there are a number of 
promising implementation
techniques that have been proven to work well in other languages, and may well 
have tremendous
payoff for Python'. 

-- v




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

Re: A "terminators' club" for clp

[Terry Reedy]

Ben Finney wrote:

Terry Reedy  writes:


So, the only reason to use c.l.p is if one wants to post anonymously,
like the spammers do ;-).


Or if one has an ISP who provides a Usenet feed, like mine does.


Gmane is a nntp news feed, just not a usenet feed. If you can read 
usenet, you can read gmane, probably in the time it took you to write 
this post -- and get access to 1000s of mirrer mailing lists. I switched 
to gmane's mirror of python-list *before* I had to because it was 
superior, overall, to my ISP at the time. Hoever, if you like the extra 
spam, don't spend the minute it takes. But my comment is directed at 
those complaining about it.


Just tell your newsreader to make a new news 'account' for
news.gmane.org or snews.gmane.org (port 563) to use ssl - either at the 
corresponding default ports.


tjr

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

Re: A "terminators' club" for clp

[Terry Reedy]

r wrote:

On Nov 14, 4:52 pm, Terry Reedy  wrote:

So, the only reason to use c.l.p is if one wants to post anonymously,
like the spammers do ;-).


I don't think that completely correct. Lots of people find GG's to be
more suited to their news reading pleasures,


I was referring to c.l.p on a nntp newsserver read by a newsreader 
program. That was the context of the previous discussion. G.G. is 
different, read through a browser (and only that, as far as I know).


 i am one of them. I hate

to have an email just overflowing with mails all the time. Here in
GG's, i just come and go without worrying about deleting messages or
kill filters or whatever.


That is why I read python-list and other mailing lists (that are not 
available as a g.g.) via gmane.


Terry Jan Reedy

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

Re: A "terminators' club" for clp

[Terry Reedy]

Paul Rubin wrote:

Terry Reedy  writes:

To post from g.c.p.g, one must use a real email address and respond
once to an email sent to that address.

So, the only reason to use c.l.p is if one wants to post anonymously,
like the spammers do ;-).


No I don't think so.  "Unwilling to disclose email address or enroll
yet another computer account" is not the same as "anonymous".


There is no 'enrolling' except for hitting reply to an email *when you 
first post*, but never to just read. You point your news reader to gmane 
just like to any other newsserver. Once you do, you have access to a 
couple hundred other Python mailing lists and 1000s of others. I believe 
c.l.p is one of the few that also appear on gmane, and only because of 
its gateway to/from python-list.


Terry Jan Reedy

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

Re: Documentation bugs in 3.1 - C-API - TypeObjects

[Martin v. Löwis]

> This cannot work, because Foo_Type is no PyObject but a PyVarObject
> (independent
> of the use of PyVarObject_HEAD_INIT or PyObject_HEAD_INIT). The code
> line would
> work so:
> 
> ((PyObject *)&Foo_Type)->ob_type = &PyType_Type

However, this is not what you should use. Instead, use

Py_Type(&Foo_Type) = &PyType_Type

> If the type is not subtypable (doesn’t have the
> Py_TPFLAGS_BASETYPE flag bit set), it is permissible to call the
> object deallocator directly instead of via tp_free.
> "
> 
> What ? Where do we "call" these methods ?

You should typically call tp_free inside of tp_dealloc. For example,
string_dealloc ends with

   Py_TYPE(op)->tp_free(op);

In the specific case (Py_TYPE(op) is not subtypeable), you could
alternatively also call

   PyObject_Del(op);

If there are subclasses, they might have used a different allocator
(rather than the object allocator), hence you must call the deallocator
through tp_free.

HTH,
Martin
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python & Go

[Terry Reedy]

Yoav Goldberg wrote:


On Sun, Nov 15, 2009 at 12:10 AM, Terry Reedy > wrote:


Paul Rubin wrote:

Mark Chu-Carroll has a new post about Go:

 
http://scienceblogs.com/goodmath/2009/11/the_go_i_forgot_concurrency_an.php


In a couple of minutes, I wrote his toy prime filter example in
Python, mostly from the text rather than the code, which I can
barely stand to read. It ran the first time without error.


Yes, but the cool thing about the Go version is that it does each 
generator in a different thread, so in theory it could run twice as fast 
on a multi-core machine. 


Which is why I added, in my opinion, that "It would be much better, for 
instance, to tweak Python, which it has had great success with, to 
better run on multiple cores."


For instance, add a new keyword 'go' such that

go def f(): yield 1

runs the generator in a different thread, possibly on a different core.

To go further, restrict Python's dynamism, require 3.x annotations, and 
call the result GoPython ;-).


Actually, it is already possible to post-process code objects to, in 
effect, remove the effect of many dynamic assumptions

http://code.activestate.com/recipes/277940/

Perhaps, with a different implementation, not even a keyword is needed, 
just a built-in decorator:


@go
def f(): yield 1

The go decorator would replace f with a wrapper that runs instances gf 
of f in threads or whatever, calls next(gf) immediately for parallel 
opereation, and caches the first yielded value until the calling 
function calls next(wrapper) to retrieve it.


It seems to me that generators are already 'channels' that connect the 
calling code to the __next__ method, a semi-coroutine based on the body 
of the generator function. At present, the next method waits until an 
object is requested. Then it goes into action, yields an object, and 
rests again. For parallel operations, we need eager, anticipatory 
evaluation that produces things that *will* be needed rather than lazy 
evaluation of things that *are* needed and whose absence is holding up 
everything else.


I see no reason why we cannot have that with Python. I not even sure we 
cannot have it with CPython, but I am not familiar enough with threads, 
processes, and CPython internals.


Terry Jan Reedy

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

Re: Run a external program.

[Terry Reedy]

Top-posting makes things more confusing. You cannot pass a Python file 
object to an external process. Pass the name instead.



Yasser Almeida Hernández wrote:

So, how can i pass an argument as a variable in this context...?


Quoting MRAB :


Yasser Almeida Hernández wrote:

Hi all!!

I'm writing a script where i call a external program which receive  
some arguments.
One of this arguments is stored in a variable, that is passed as  
argument as well:


import os
...
f = open(file1, 'r')
s = 'command $f -i file2 -w 1.4 -o file3.out'
os.system(s)
...

When i run the script i get the next message...
'-i: No such file or directory'
... with a obvious error in the exit of the program. If i remove  the 
option -i i get the same error with every option, even with  those 
who don't get any file as argument. (file2 exist).

BUT, when i run the external program in a python shell, it works...

What's wrong?


The name 'f' in the Python script exists only in Python and is unrelated
to the '$f' that the shell sees.
--
http://mail.python.org/mailman/listinfo/python-list







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

A different take on finding primes

[Vincent Davis]

Out of pure curiosity I would like to compare the efficiency of different
methods of finding primes (need not be consecutive). Let me be clear, given
2min, how many primes can you find, they need not be in order or
consecutive. I have not seen any examples of this. I am assume the solution
is different depending on the time give,  2min or 2 hours. I assume a sieve
solution would be best for larger times. When the numbers get really large
checking to see if they are a prime gets costly.
So what do you think?

  *Vincent Davis
720-301-3003 *
vinc...@vincentdavis.net
 my blog  |
LinkedIn
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Simple object reference

[Ben Finney]

Chris Rebert  writes:

> On Sat, Nov 14, 2009 at 3:25 PM, AON LAZIO  wrote:
> > Hi, I have some problem with object reference
> > Say I have this code
> >
> > a = b = c = None
> > slist = [a,b,c]
>
> Values are stored in the list, not references to names. Modifying the
> list does not change what values the names a, b, and c have. There is
> no Python-level notion of pointers.

There *is*, though, a notion of references, which is what the OP is
asking about. The list does not store values, it stores references to
values (just as a name references a value).

You're right that the names are irrelevant for the items in the list;
the name ‘a’ and the item ‘slist[0]’ are always independent references.

> > for i in range(len(slist)):
> > slist[i] = 5

Hence, this has no effect on what the names ‘a’, ‘b’, ‘c’ reference;
those names continue to reference whatever they were already
referencing. It is changing only what the list items ‘slist[0]’,
‘slist[1]’, ‘slist[2]’ reference.

> I would also recommend reading
> http://effbot.org/zone/call-by-object.htm for a good explanation of
> how Python's variables work.

Yes, the Effbot's explanations are good.

It's also worth noting that the Python reference documentation has
become much more readable recently, and the language reference has good
explanations of the data model
http://docs.python.org/reference/datamodel.html#objects-values-and-types>
and what assignment statements do
http://docs.python.org/reference/simple_stmts.html#assignment-statements>.

-- 
 \ “As we enjoy great advantages from the inventions of others, we |
  `\  should be glad to serve others by any invention of ours; and |
_o__) this we should do freely and generously.” —Benjamin Franklin |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Easy way to play single musical notes in Python

[James Harris]

On 15 Nov, 00:12, James Harris  wrote:

> Is there a simple way to play musical notes in Python? Something like
>
>   voice.play("c4")
>
> to play C in octave 4 would be ideal. I included a voice parameter as
> I'd like to play proper notes, not just beeps. This is for recognition
> of pitch. For example, the program plays a note and the user tries to
> identify the note played.
>
> There are many options at
>
>  http://wiki.python.org/moin/PythonInMusic
>
> but which to choose? They generally seem too complex. I'm looking for
> something really basic. It would help if it was cross platform and
> didn't need Tkinter as the snack library does. I presume pure Python
> is not possible.
>
> Any suggestions?

Oh, it would be OK if the system allowed numeric pitches such as

  voice.play(440)

to play a note at 440 Hertz.

Anything like the above should be good enough.

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

Re: A "terminators' club" for clp

[Ben Finney]

Terry Reedy  writes:

> So, the only reason to use c.l.p is if one wants to post anonymously,
> like the spammers do ;-).

Or if one has an ISP who provides a Usenet feed, like mine does.

A pox upon Andrew Cuomo for bashing ISPs in the USA with the stick of
“child pornography” (which he discovered on 88 out of many thousands of
forums). Faced with the unreasonable role of policing Usenet, they shut
it all off http://news.cnet.com/8301-13578_3-9964895-38.html>.

-- 
 \   “We spend the first twelve months of our children's lives |
  `\  teaching them to walk and talk and the next twelve years |
_o__)   telling them to sit down and shut up.” —Phyllis Diller |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list

Easy way to play single musical notes in Python

[James Harris]

Is there a simple way to play musical notes in Python? Something like

  voice.play("c4")

to play C in octave 4 would be ideal. I included a voice parameter as
I'd like to play proper notes, not just beeps. This is for recognition
of pitch. For example, the program plays a note and the user tries to
identify the note played.

There are many options at

  http://wiki.python.org/moin/PythonInMusic

but which to choose? They generally seem too complex. I'm looking for
something really basic. It would help if it was cross platform and
didn't need Tkinter as the snack library does. I presume pure Python
is not possible.

Any suggestions?

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

Re: A "terminators' club" for clp

[r]

On Nov 14, 4:52 pm, Terry Reedy  wrote:
> So, the only reason to use c.l.p is if one wants to post anonymously,
> like the spammers do ;-).

I don't think that completely correct. Lots of people find GG's to be
more suited to their news reading pleasures, i am one of them. I hate
to have an email just overflowing with mails all the time. Here in
GG's, i just come and go without worrying about deleting messages or
kill filters or whatever.

Maybe even Guido himself uses GG's? Heck for all we know Guido could
have a "pybot" sending all these spams just so Python's TIOBE index
will increase! ;-)

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

Re: Psyco on 64-bit machines

[Russ P.]

On Nov 12, 12:06 pm, "Russ P."  wrote:
> I have a Python program that runs too slow for some inputs. I would
> like to speed it up without rewriting any code. Psyco seemed like
> exactly what I need, until I saw that it only works on a 32-bit
> architecture. I work in an environment of Sun Ultras that are all 64-
> bit. However, the Psyco docs say this:
>
> "Psyco does not support the 64-bit x86 architecture, unless you have a
> Python compiled in 32-bit compatibility mode."
>
> Would it make sense to compile Python in the 32-bit compatibility mode
> so I can use Psyco? What would I lose in that mode, if anything?
> Thanks.

I just stumbled across "unladen swallow," a "faster implementation of
Python." Is it ready for operational usage? How does it compare to
Psyco? I poked around their website a bit, but I don't see answers to
those questions. Thanks.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Simple object reference

[Chris Rebert]

On Sat, Nov 14, 2009 at 3:25 PM, AON LAZIO  wrote:
> Hi, I have some problem with object reference
> Say I have this code
>
> a = b = c = None
> slist = [a,b,c]

Values are stored in the list, not references to names. Modifying the
list does not change what values the names a, b, and c have. There is
no Python-level notion of pointers.

> for i in range(len(slist)):
> slist[i] = 5

This modifies the contents of the list, it does not affect any other
variables/names.

> print slist
> print a,b,c
>
> I got this
> [5, 5, 5]
> None None None
>
>     Question is how can I got all a,b,c variable to have value 5 also?

Use tuple unpacking:

#at start of code
slist = [None]*3
#...
#at end of code
a, b, c = slist

I would also recommend reading
http://effbot.org/zone/call-by-object.htm for a good explanation of
how Python's variables work.

Cheers,
Chris
--
http://blog.rebertia.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Simple object reference

[AON LAZIO]

Hi, I have some problem with object reference
Say I have this code

a = b = c = None
slist = [a,b,c]
for i in range(len(slist)):
slist[i] = 5
print slist
print a,b,c

I got this
[5, 5, 5]
None None None

Question is how can I got all a,b,c variable to have value 5 also?
Thanks in advance
-- 
Passion is my style
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A "terminators' club" for clp

[Paul Rubin]

Terry Reedy  writes:
> To post from g.c.p.g, one must use a real email address and respond
> once to an email sent to that address.
> 
> So, the only reason to use c.l.p is if one wants to post anonymously,
> like the spammers do ;-).

No I don't think so.  "Unwilling to disclose email address or enroll
yet another computer account" is not the same as "anonymous".
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python simply not scaleable enough for google?

[Robert Brown]

Vincent Manis  writes:
> The false statement you made is that `... Python *the language* is specified
> in a way that makes executing Python programs quickly very very difficult.
> I refuted it by citing several systems that implement languages with
> semantics similar to those of Python, and do so efficiently.

The semantic details matter.  Please read Willem's reply to your post.  It
contains a long list of specific differences between Python (CPython) language
semantics and Common Lisp language semantics that cause Python performance to
suffer.

> OK, let me try this again. My assertion is that with some combination of
> JITting, reorganization of the Python runtime, and optional static
> declarations, Python can be made acceptably fast, which I define as program
> runtimes on the same order of magnitude as those of the same programs in C
> (Java and other languages have established a similar goal). I am not pushing
> optional declarations, as it's worth seeing what we can get out of
> JITting. If you wish to refute this assertion, citing behavior in CPython or
> another implementation is not enough. You have to show that the stated
> feature *cannot* be made to run in an acceptable time.

It's hard to refute your assertion.  You're claiming that some future
hypothetical Python implementation will have excellent performance via a JIT.
On top of that you say that you're willing to change the definition of the
Python language, say by adding type declarations, if an implementation with a
JIT doesn't pan out.  If you change the Python language to address the
semantic problems Willem lists in his post and also add optional type
declarations, then Python becomes closer to Common Lisp, which we know can be
executed efficiently, within the same ballpark as C and Java.

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

Re: Psyco on 64-bit machines

[Russ P.]

On Nov 14, 10:15 am, "Diez B. Roggisch"  wrote:
> Russ P. schrieb:
>
> > I have a Python program that runs too slow for some inputs. I would
> > like to speed it up without rewriting any code. Psyco seemed like
> > exactly what I need, until I saw that it only works on a 32-bit
> > architecture. I work in an environment of Sun Ultras that are all 64-
> > bit. However, the Psyco docs say this:
>
> > "Psyco does not support the 64-bit x86 architecture, unless you have a
> > Python compiled in 32-bit compatibility mode."
>
> > Would it make sense to compile Python in the 32-bit compatibility mode
> > so I can use Psyco? What would I lose in that mode, if anything?
> > Thanks.
>
> Isn't the SUN Ultra using an ULTRA-Sparc core? If so, the point is moot.
>
> Diez

No, it's Intel based.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A "terminators' club" for clp

[Terry Reedy]

r wrote:

On Nov 14, 4:59 am, kj  wrote:

But, as I already showed, I'm out of my depth here,
so I'd better shut up.


Don't give up so easy! The idea is great, what Paul is saying is that
most people who read this group use newsreaders and that has nothing
to do with google groups. These guy's have kill filters for just this
sort of thing but either way the emails are on their puters so they
have to deal with them on an individual basis. It would be nice
however to clean up the Google group version and rid it of the plagues
of spam infestations.


Anyone with a newsreader can, like me, read gmane.comp.python.general, 
which mirrors python-list, which now filters out much/most of the spam 
on c.l.p from G.g.


To post from g.c.p.g, one must use a real email address and respond once 
 to an email sent to that address.


So, the only reason to use c.l.p is if one wants to post anonymously, 
like the spammers do ;-).


Terry Jan Reedy


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

Re: python simply not scaleable enough for google?

[Terry Reedy]

Willem Broekema wrote:


It might have gotten a bit better, but the central message still
stands: Python has made design choices that make efficient compilation
hard.


OK, let me try this again. My assertion is that with some combination of 
JITting,
reorganization of the Python runtime, and optional static declarations, Python
can be made acceptably fast,


That does not contradict that, had other language design choices been
made, it could be much easier to get better performance. Python may in
general be about as dynamic as Common Lisp from a _user_ perspective,
but from an implementator's point of view Python is harder to make it
run efficiently.


I think you are right about the design choices. The reason for those 
design choices is that Guido intended from the beginning that Python 
implementations be part of open computational systems, and not islands 
to themselves like Smalltalk and some Lisps. While the public CPython 
C-API is *not* part of the Python language, Python was and has been 
designed with the knowledge that there *would be* such an interface, and 
that speed-critical code would be written in C or Fortran, or that 
Python programs would interface with and use such code already written.


So: Python the language was designed for human readability, with the 
knowledge that CPython the implementation (originally and still today 
just called python.exe) would exist in a world where intensive 
computation could be pushed onto C or Fortan when necessary.


So: to talk about the 'speed of Python', one should talk about the speed 
of human reading and writing. On this score, Python, I believe, beats 
most other algorithm languages, as intended. It certainly does for me. 
To talk about the speed of CPython, one must, to be fair, talk about the 
speed of CPython + extensions compiled to native code.


In the scale of human readability, I believe Google go is a step 
backwards from Python.


Terry Jan Reedy

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

Re: Python & Go

[Yoav Goldberg]

On Sun, Nov 15, 2009 at 12:10 AM, Terry Reedy  wrote:

> Paul Rubin wrote:
>
>  Mark Chu-Carroll has a new post about Go:
>>
>>
>> http://scienceblogs.com/goodmath/2009/11/the_go_i_forgot_concurrency_an.php
>>
>
> In a couple of minutes, I wrote his toy prime filter example in Python,
> mostly from the text rather than the code, which I can barely stand to read.
> It ran the first time without error.
>
>
Yes, but the cool thing about the Go version is that it does each generator
in a different thread, so in theory it could run twice as fast on a
multi-core machine.

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

Re: python simply not scaleable enough for google?

[Edward A. Falk]

In article ,
Terry Reedy   wrote:
>
>I can imagine a day when code compiled from Python is routinely 
>time-competitive with hand-written C.

I can't.  Too much about the language is dynamic.  The untyped variables
alone are a killer.

int a,b,c;
...
a = b + c;

In C, this compiles down to just a few machine instructions.  In Python,
the values in the variables need to be examined *at run time* to determine
how to add them or if they can even be added at all.  You'll never in
a million years get that down to just two or three machine cycles.

Yes, technically, the speed of a language depends on its implementation,
but the nature of the language constrains what you can do in an
implementation.  Python the language is inherently slower than C the
language, no matter how much effort you put into the implementation.  This
is generally true for all languages without strongly typed variables.

-- 
-Ed Falk, f...@despams.r.us.com
http://thespamdiaries.blogspot.com/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python & Go

[Terry Reedy]

Paul Rubin wrote:


Mark Chu-Carroll has a new post about Go:

  http://scienceblogs.com/goodmath/2009/11/the_go_i_forgot_concurrency_an.php


In a couple of minutes, I wrote his toy prime filter example in Python, 
mostly from the text rather than the code, which I can barely stand to 
read. It ran the first time without error.


def plurals():
  i = 2
  while True:
yield i
i += 1

def primefilter(src, prime):
  for i in src:
if i % prime:
  yield i

src = plurals()
while True:
  i = next(src)
  print(i)
  src = primefilter(src, i)

As I commented there
"It stopped at 7877 when it hit the default recursion limit of 1000, 
which could easily be increased to get out-of-memory error instead.


I think Google is making a blunder if it moves to another old-fashioned 
language whose code is bloated with junky boilerplate that doubles the 
size. It would be much better, for instance, to tweak Python, which it 
has had great success with, to better run on multiple cores."


Terry Jan Reedy

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

Re: python simply not scaleable enough for google?

[Terry Reedy]

sturlamolden wrote:


- For the few cases where a graphics program really need C, we can
always resort to using ctypes, f2py or Cython. Gluing Python with C or
Fortran is very easy using these tools. That is much better than
keeping it all in C++.


In case anyone thinks resorting to C or Fortran is cheating, they should 
know that CPython, the implementation, was designed for this. That is 
why there is a documented C-API and why the CPython devs are slow to 
change it. Numerical Python dates back to at least 1.3 and probably 
earlier. The people who wrote it were some of the first production users 
of Python.


Terry Jan Reedy

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

Re: 3.x and 2.x on same machine (is this info at Python.org??)

[Nobody]

On Fri, 13 Nov 2009 06:05:48 -0500, Dave Angel wrote:

>>> Currently i am using 2.6 on Windows and need to start writing code in
>>> 3.0. I cannot leave 2.x yet because 3rd party modules are still not
>>> converted. So i want to install 3.0 without disturbing my current
>>> Python2.x. What i'm afraid of is that some SYSVARIABLE will get
>>> changed to Python3.0 and when i double click a Python script it will
>>> try and run Python 3.x instead of 2.x. I only want to run 3.0 scripts
>>> from the command line... > python3.x myscript.py
>>>
>>> So how do i do this? Is my fear unfounded?
>>> 
>>
>> Windows determines the double-click action based on the file
>> extension.  You just have to make sure that *.py files are associated
>> with 2.x.
>> http://support.microsoft.com/kb/307859
>>
>>
>>   
> And if someone simply wants to check or change these associations 
> without all the Explorer nonsense, one can use
>assoc.exeandftype.exe

That isn't reliable.

The Windows registry has two distinct sets of mappings.

HKEY_LOCAL_MACHINE\Software\Classes contains system-wide mappings, while
HKEY_CURRENT_USER\Software\Classes contains per-user mappings. The
per-user mappings are checked first, with the system-wide mappings acting
as a fall-back. AFAICT, assoc and ftype modify the system-wide mappings,
so if you have a per-user mapping, they have no effect.

Note that HKEY_CLASSES_ROOT is a "virtual" key obtained by merging the
above two keys (analogous to a view in an RDBMS).

http://msdn.microsoft.com/en-us/library/ms724475(VS.85).aspx


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

Re: Run a external program.

[Yasser Almeida Hernández]

All ran ok!!

Thanks a lot



Quoting MRAB :


Yasser Almeida Hernández wrote:

So, how can i pass an argument as a variable in this context...?


You can't pass arbitrary values on a command line. In this case, why not
just pass the path of the file?

s = 'command "%s" -i file2 -w 1.4 -o file3.out' % file1



Quoting MRAB :


Yasser Almeida Hernández wrote:

Hi all!!

I'm writing a script where i call a external program which   
receive  some arguments.
One of this arguments is stored in a variable, that is passed as   
 argument as well:


import os
...
f = open(file1, 'r')
s = 'command $f -i file2 -w 1.4 -o file3.out'
os.system(s)
...

When i run the script i get the next message...
'-i: No such file or directory'
... with a obvious error in the exit of the program. If i remove   
 the option -i i get the same error with every option, even with   
 those who don't get any file as argument. (file2 exist).

BUT, when i run the external program in a python shell, it works...

What's wrong?


The name 'f' in the Python script exists only in Python and is unrelated
to the '$f' that the shell sees.




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




--
Lic. Yasser Almeida Hernández
Center of Molecular Inmunology (CIM)
Nanobiology Group
P.O.Box 16040, Havana, Cuba
Phone: (537) 271-7933, ext. 221


Correo FENHI



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

Re: Help with database planning

[Rob Williscroft]

Juliano wrote in
news:0e64893a-af82-4004-bf3c-f397f2022...@g22g2000prf.googlegroups.com
in comp.lang.python: 

[snip]

> So, for ONE *concept*, we have, usually, MANY *slots*, each *slot* has
> ONE *facet*, and each *facet* can have MORE THAN ONE *filler*.
> Besides, some *slots* and *fillers* are themselves *concepts*,
> creating a sort of recursive reference.

What I'm grokking from the data you show is that a "Concept" is
a table (or a python class), "slots" are attributes of the concept
and facets are the type of "slot", finally the "fillers" are 
(mostly) the data.

But also you seem to have "slots" that represent relationships
between "Concepts" and other tables, in this case the "slots"
should be tables.

For example with the slot type "INSTANCE-OF", what is 
"OTHER-NIGER-KORDOFANIAN-LANGUAGE" is it another concept or a 
list of concepts or a concept "OTHER-NIGER-KORDOFANIAN" and
a type "LANGUAGE", I suspect you have a table "Language"
and also an table "Region" in there too.

It may be time to start thinking in terms of what you are 
modeling and what the entities are (as apposed to trying to
convert the data you have), once you have that, work out 
how to load that data from your current file and check
that you can query your model correctly.

Maybe something like (using a made up ORM):

class Concept:
  name = TextField()
  definition = TextField()

  primary_key = PrimaryKey( name )

class IsASlot: 
  concept = ForeignKey( Concept )
  is_a = ForeignKey( Concept )

  primary_key = PrimaryKey( concept, is_a )

class LexeSlot:
  concept = ForeignKey( Concept )
  value = TextField()

  primary_key = PrimaryKey( concept, value )

class Region:
  region = TextField()  
  
  primary_key = PrimaryKey( region )

class Language:
  language = ForeignKey( Concept ) # or is it TextField() ?

  primary_key = PrimaryKey( language )

class LanguageOfSlot:
  language = ForeignKey( Language )
  region  = ForeignKey( Region )

  primary_key = PrimaryKey( language, region )


To reiterate, you should use your domain expertise to create
the model.

> 
> 
> line_no concepts slots facets fillers
> ---
> --- 0 ABANDON DEFINITION VALUE "to leave or
> desert something or someone"
> 1 ABANDON IS-A VALUE EXIT
> 2 ABANDON LEXE MAP-LEX "leave behind-V1"
> 3 ABANDON LEXE MAP-LEX abandon-V1

The "-V1" in the above looks worryingly like you have structure embedded
in the data field, if so you should extract is so its in its own field 
or table.

> (...)
> 97420 ZULU DEFINITION VALUE "a language or dialect
> spoken in south africa and others"
> 97421 ZULU INSTANCE-OF VALUE
>OTHER-NIGER-KORDOFANIAN-LANGUAGE 
> 97422 ZULU LANGUAGE-OF INV LESOTHO
> 97423 ZULU LANGUAGE-OF INV SOUTH-AFRICA 

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

Re: Run a external program.

[MRAB]

Yasser Almeida Hernández wrote:

So, how can i pass an argument as a variable in this context...?


You can't pass arbitrary values on a command line. In this case, why not
just pass the path of the file?

s = 'command "%s" -i file2 -w 1.4 -o file3.out' % file1



Quoting MRAB :


Yasser Almeida Hernández wrote:

Hi all!!

I'm writing a script where i call a external program which receive  
some arguments.
One of this arguments is stored in a variable, that is passed as  
argument as well:


import os
...
f = open(file1, 'r')
s = 'command $f -i file2 -w 1.4 -o file3.out'
os.system(s)
...

When i run the script i get the next message...
'-i: No such file or directory'
... with a obvious error in the exit of the program. If i remove  the 
option -i i get the same error with every option, even with  those 
who don't get any file as argument. (file2 exist).

BUT, when i run the external program in a python shell, it works...

What's wrong?


The name 'f' in the Python script exists only in Python and is unrelated
to the '$f' that the shell sees.




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

Re: Run a external program.

[Chris Rebert]

> Quoting MRAB :
>> Yasser Almeida Hernández wrote:
>>>
>>> Hi all!!
>>>
>>> I'm writing a script where i call a external program which receive  some
>>> arguments.
>>> One of this arguments is stored in a variable, that is passed as
>>>  argument as well:
>>>
>>> import os
>>> ...
>>> f = open(file1, 'r')
>>> s = 'command $f -i file2 -w 1.4 -o file3.out'
>>> os.system(s)
>>> ...
>>>
>>> When i run the script i get the next message...
>>> '-i: No such file or directory'
>>> ... with a obvious error in the exit of the program. If i remove  the
>>> option -i i get the same error with every option, even with  those who don't
>>> get any file as argument. (file2 exist).
>>> BUT, when i run the external program in a python shell, it works...
>>>
>>> What's wrong?
>>>
>> The name 'f' in the Python script exists only in Python and is unrelated
>> to the '$f' that the shell sees.

2009/11/14 Yasser Almeida Hernández :
> So, how can i pass an argument as a variable in this context...?

Use the string variable's value when specifying the arguments to the command.

Here's how you'd do it using the newer `subprocess` module:

import sys
import subprocess
args = ['command', file1, '-i', 'file2', '-w', '1.4', '-o',
'file3.out'] #assuming only file1 is variable
return_code = subprocess.call(args, stdin=sys.stdin,
stdout=sys.stdout, stderr=sys.stderr)

Cheers,
Chris
--
http://blog.rebertia.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python & Go

[Paul Rubin]

sturlamolden  writes:
> The go keyword could be a problem as well. I suspect it could infringe
> on Cilk++ patents. Perhaps Go cannot be used without a licence from
> Cilk Arts?

Also as somebody said, if after a while they decide to make a new
version of the language, they'll have to call it Go2, which will
necessarily be considered harmful.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python & Go

[sturlamolden]

On 14 Nov, 19:18, John Nagle  wrote:

> Syntax for queues is a minor win.

No, that's syntax bloat.

The go keyword could be a problem as well. I suspect it could infringe
on Cilk++ patents. Perhaps Go cannot be used without a licence from
Cilk Arts?





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

Re: Run a external program.

[Yasser Almeida Hernández]

So, how can i pass an argument as a variable in this context...?


Quoting MRAB :


Yasser Almeida Hernández wrote:

Hi all!!

I'm writing a script where i call a external program which receive   
some arguments.
One of this arguments is stored in a variable, that is passed as   
argument as well:


import os
...
f = open(file1, 'r')
s = 'command $f -i file2 -w 1.4 -o file3.out'
os.system(s)
...

When i run the script i get the next message...
'-i: No such file or directory'
... with a obvious error in the exit of the program. If i remove   
the option -i i get the same error with every option, even with   
those who don't get any file as argument. (file2 exist).

BUT, when i run the external program in a python shell, it works...

What's wrong?


The name 'f' in the Python script exists only in Python and is unrelated
to the '$f' that the shell sees.
--
http://mail.python.org/mailman/listinfo/python-list




--
Lic. Yasser Almeida Hernández
Center of Molecular Inmunology (CIM)
Nanobiology Group
P.O.Box 16040, Havana, Cuba
Phone: (537) 271-7933, ext. 221


Correo FENHI



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

Re: Run a external program.

[Mark Tolonen]

"Yasser Almeida Hernández"  wrote in message 
news:20091114142611.sj45qput2c84s...@correo.fenhi.uh.cu...

Hi all!!

I'm writing a script where i call a external program which receive  some 
arguments.
One of this arguments is stored in a variable, that is passed as  argument 
as well:


import os
...
f = open(file1, 'r')
s = 'command $f -i file2 -w 1.4 -o file3.out'
os.system(s)
...

When i run the script i get the next message...
'-i: No such file or directory'
... with a obvious error in the exit of the program. If i remove the 
option -i i get the same error with every option, even with those who 
don't get any file as argument. (file2 exist).

BUT, when i run the external program in a python shell, it works...

What's wrong?


Please post a small, complete example of your code and the error message. 
Cut-and-paste them exactly.  Also provide the shell command you are running 
that works.


-Mark


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

Re: Choosing GUI Module for Python

[sturlamolden]

On 14 Nov, 19:02, Dietmar Schwertberger  wrote:

> 08/23/2009 Version 3.01.63 (Beta)
> 08/19/2009 Version 3.01.62 (Beta)
>
> I tried 3.01.63.
> I can see in the Python window already that the code is not correct.

3.01.63

Did you remember to install the wxAdditions?

Could you send me an .fbp file demonstrating the error?





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

Re: Run a external program.

[MRAB]

Yasser Almeida Hernández wrote:

Hi all!!

I'm writing a script where i call a external program which receive some 
arguments.
One of this arguments is stored in a variable, that is passed as 
argument as well:


import os
...
f = open(file1, 'r')
s = 'command $f -i file2 -w 1.4 -o file3.out'
os.system(s)
...

When i run the script i get the next message...
'-i: No such file or directory'
... with a obvious error in the exit of the program. If i remove the 
option -i i get the same error with every option, even with those who 
don't get any file as argument. (file2 exist).

BUT, when i run the external program in a python shell, it works...

What's wrong?


The name 'f' in the Python script exists only in Python and is unrelated
to the '$f' that the shell sees.
--
http://mail.python.org/mailman/listinfo/python-list

Re: python-daemon and upstart

[Paul Rudin]

Paul Rudin  writes:

>
> So I would have expected it to be necessary in this case. Maybe this is
> more an upstart issue than a python-daemon one - not sure.

Aha - so I discover that if detach_process is not explicitly passed to
the DaemonContext initialiser it tries to guess whether it needs to do
the double fork thing or not, passing it through explicitly makes every
work as I expected. 

So it's probably an rtfm error on my part. Although I suppose that there
may be an argument the the DaemonContext guessing should try and detect
this situation not sure.
-- 
http://mail.python.org/mailman/listinfo/python-list

Run a external program.

[Yasser Almeida Hernández]

Hi all!!

I'm writing a script where i call a external program which receive  
some arguments.
One of this arguments is stored in a variable, that is passed as  
argument as well:


import os
...
f = open(file1, 'r')
s = 'command $f -i file2 -w 1.4 -o file3.out'
os.system(s)
...

When i run the script i get the next message...
'-i: No such file or directory'
... with a obvious error in the exit of the program. If i remove the  
option -i i get the same error with every option, even with those who  
don't get any file as argument. (file2 exist).

BUT, when i run the external program in a python shell, it works...

What's wrong?

Please help me...
Thanks








--
Lic. Yasser Almeida Hernández
Center of Molecular Inmunology (CIM)
Nanobiology Group
P.O.Box 16040, Havana, Cuba
Phone: (537) 271-7933, ext. 221


Correo FENHI



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

Re: python simply not scaleable enough for google?

[Grant Edwards]

On 2009-11-14, David Robinow  wrote:
> On Fri, Nov 13, 2009 at 3:32 PM, Paul Rubin
> wrote:
>> ... ?This is Usenet so
>> please stick with Usenet practices. ?If you want a web forum there are
>> plenty of them out there.
>  Actually this is python-list@python.org

Actually this is comp.lang.python

> I don't use usenet and I have no intention to stick with Usenet practices.

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

Re: Python & Go

[Paul Rubin]

kj  writes:
> One more thing: I found Rob Pike's mutterings on generics (towards
> the end of his rollout video) rather offputting, because he gave
> the impression that some important aspects of the language were
> not even considered before major decisions for it were set in stone.
> It looks like, if they ever get around to supporting generics, it
> will be a late-in-the-day hack.

Mark Chu-Carroll has a new post about Go:

  http://scienceblogs.com/goodmath/2009/11/the_go_i_forgot_concurrency_an.php

Someone named Mightybyte also has a post about Go, and its comment
thread is similarly pretty good:

   http://softwaresimply.blogspot.com/2009/11/standardizing-go.html

One of the commenters wrote something that I felt was similar to my
own impression of the language:

From a PLT perspective Go isn't that interesting. The concurrency and
"goroutines" look promising for possibly being able to do what Erlang
does. The type system is pretty weak.  From a practical perspective
people are singing praise for how fast it compiles, but not much
mention so far of how fast the resulting code is. Compare tinycc vs
gcc for speed of compilation vs resulting code performace to see why
I'm skeptical.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python & Go

[Paul Rubin]

sturlamolden  writes:
> And looking at Go, I cannot understand why Google prefer this over
> e.g. Lua.

I thought Lua had no type system and no concurrency.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A "terminators' club" for clp

[Paul Rubin]

"Alf P. Steinbach"  writes:
> The problem with moderation isn't getting rid of spam and trolls etc.,
> but turnaround time.

There is automatic moderation software that auto-approves any post
from an address that has had one or two posts manually approved.
While that's susceptible to address forgery, the typical spammer
doesn't do that.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The ol' [[]] * 500 bug...

[Paul Rubin]

Ulrich Eckhardt  writes:
> That said, [[]]*500 is IMHO more readable.

But the issue in the thread is that it does the wrong thing.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Psyco on 64-bit machines

[Diez B. Roggisch]

Russ P. schrieb:

I have a Python program that runs too slow for some inputs. I would
like to speed it up without rewriting any code. Psyco seemed like
exactly what I need, until I saw that it only works on a 32-bit
architecture. I work in an environment of Sun Ultras that are all 64-
bit. However, the Psyco docs say this:

"Psyco does not support the 64-bit x86 architecture, unless you have a
Python compiled in 32-bit compatibility mode."

Would it make sense to compile Python in the 32-bit compatibility mode
so I can use Psyco? What would I lose in that mode, if anything?
Thanks.


Isn't the SUN Ultra using an ULTRA-Sparc core? If so, the point is moot.

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

Re: python simply not scaleable enough for google?

[Paul Rubin]

sturlamolden  writes:
> Python on a better VM (LuaJIT, Parrot, LLVM, several
> JavaScript) will easily outperform CPython by orders of magnitide.


Maybe Python semantics make it more difficult to optimize than those
other languages.  For example, in
  a = foo.bar(1)
  b = muggle()
  c = foo.bar(2)
it is not ok to cache the value of foo.bar after the first assignment.
Maybe the second one goes and modifies it through foo.__dict__ .
See "Children of a Lesser Python" (linked in another post, or websearch)
for discussion.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A "terminators' club" for clp

[r]

On Nov 14, 7:28 am, gil_johnson  wrote:

> How about using a "rank this post" feature? Anybody could rank a post
> as spam, and a sufficiently large number of negatives would quickly
> draw the attention of someone with the power to kill the message. I
> suppose even this is subject to abuse, allowing harassment of a
> legitimate poster., but my guess is that the votes against counterfeit
> Nike shoes, etc., would outnumber the most energetic "vote troll."
> Gil

Actually there is a "rank this post" (gotta be careful with that
verbage!) AND a "report this post as spam". Of course it only exists
in GG's and not Usenet. I *do* know that the star system is used quite
frequently, but i doubt anyone bothers to use the "report as spam"
link since it seems have no effect whatsoever.

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

Re: Python & Go

[John Nagle]

sturlamolden wrote:

On 12 Nov, 01:53, kj  wrote:

I'm just learning about Google's latest: the GO (Go?) language.


It's interesting.  The semantics are closer to Java than any other
mainstream language.  While Java usually is run with a "virtual machine",
Go is more like Java hard-compiled (which you can do with GCC.)

It's far less dynamic than Python, which is good for performance.
(That's not an inherent problem with Python. It's a problem with the
CPython implementation.  See Shed Skin.)

The declaration syntax is borrowed from the Pascal/Modula/Ada
family of languages, and it's an improvement over the C/C++ approach.
I suspect that Go is LALR(1), which means it can be parsed with a
simple context-independent parser.  C and C++ are very difficult to
parse, and modules can't be parsed independently.  (Because of the
C/C++ type syntax, you have to look up type names to find out how
to parse declarations. So the include files have to be present
to parse declarations.  This is why there aren't many tools that
manipulate C and C++ source code.)

Having concurrency in the language is a win.  Syntax for queues
is a minor win. But the language doesn't directly address the issue of "who
locks what".  There are shared variables, and mutexes, but the language doesn't
let you talk about which variables are shared.  When the language doesn't
know that, you either have to restrict optimization (as in Python) or have
painful mechanisms like "mutable" as in C++.

Leaving out exceptions was a mistake.  Exceptions are well understood now,
and they're far better than the usual "ignore errors" approach one sees in lamer
C programs.

The interface mechanism is simple enough.  In a static language, you can
convert "duck typing" to inheritance at link time, when you have the chance
to see what can match what.  So the implementation doesn't actually have to
search for a match at run time.

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

Re: Choosing GUI Module for Python

[Dietmar Schwertberger]

sturlamolden schrieb:

On 14 Nov, 15:35, Dietmar Schwertberger  wrote:


   self.m_toolBar1 = self.CreateToolBar( wx.TB_HORIZONTAL, wx.ID_ANY )
   self.m_button1 = wx.Button( self.m_toolBar1, wx.ID_ANY, u"MyButton",
wx.DefaultPosition, wx.DefaultSize, 0 )
   m_toolBar1.AddControl( m_button1 )

(i.e. "self." is missing)


I had problem like that with the first beta, but not the one from
August.

Which one? There are two:

08/23/2009 Version 3.01.63 (Beta)
08/19/2009 Version 3.01.62 (Beta)

I tried 3.01.63.
I can see in the Python window already that the code is not correct.


Regards,

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

Re: How to know if a file is a text file

[Philip Semanchuk]

On Nov 14, 2009, at 11:02 AM, Luca Fabbri wrote:


Hi all.

I'm looking for a way to be able to load a generic file from the
system and understand if he is plain text.
The mimetype module has some nice methods, but for example it's not
working for file without extension.


Hi Luca,
You have to define what you mean by "text" file. It might seem  
obvious, but it's not.


Do you mean just ASCII text? Or will you accept Unicode too? Unicode  
text can be more difficult to detect because you have to guess the  
file's encoding (unless it has a BOM; most don't).


And do you need to verify that every single byte in the file is  
"text"? What if the file is 1GB, do you still want to examine every  
single byte?


If you give us your own (specific!) definition of what "text" means,  
or perhaps a description of the problem you're trying to solve, then  
maybe we can help you better.


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

Re: python-daemon and upstart

[Paul Rudin]

Paul Rudin  writes:

> Ben Finney  writes:
>
>> Paul Rudin  writes:

>>> description "test daemon"
>>> expect daemon
>>> chdir /tmp
>>> exec /tmp/testdaemon.py

Further experimentation reveals that by omitting the "expect daemon"
stanza everything works fine. But I'm still a confused - the manpage
says:


  expect daemon
 Specifies that the job's main process is a daemon, and will fork
 twice  after being run.  init(8) will follow this daemonisation,
 and will wait for this to occur before running the  job's  post-
 start script or considering the job to be running.

 Without  this  stanza init(8) is unable to supervise daemon pro‐
 cesses and will believe them to have stopped  as  soon  as  they
 daemonise on startup.

   
So I would have expected it to be necessary in this case. Maybe this is
more an upstart issue than a python-daemon one - not sure.

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

Re: bootstrapping on machines without Python

[Jonathan Hartley]

On Nov 13, 10:25 pm, mma...@gmx.net wrote:
> On Fri, 13 Nov 2009 02:40:28 -0800 (PST)
>
> Jonathan Hartley  wrote:
> > Even my very limited understanding of the issues is enough to see that
> > the idea is far from trivial.


Thanks heaps for the input from everyone. Martin Lemburg's 'chained'
approach does sound like the smart way to do it, and Thomas does
demonstrate pretty much the simplest possible example of what I'm
thinking of. Martin Manns' portable Python sounds useful too, and is
not disimilar to a suggestion made by Michael Foord off list.

However, the problems that Tim, Martin, Marc and Martin point out do
seem very real. I think users could be placated about 'backdoor
installation' if we tell them what's going on, with an OK button. But
I confess I wasn't aware that a full Python install is quite so large
compared to the bundle produced by py2exe et al.

Perhaps this idea is overly idealistic then - I was maybe transfixed
by the 'needless consistency' of sharing a single interpreter between
many applications.

Thanks for helping me straighten out my thoughts on the subject.

Best!

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

Re: Choosing GUI Module for Python

[sturlamolden]

On 14 Nov, 15:35, Dietmar Schwertberger  wrote:

>    self.m_toolBar1 = self.CreateToolBar( wx.TB_HORIZONTAL, wx.ID_ANY )
>    self.m_button1 = wx.Button( self.m_toolBar1, wx.ID_ANY, u"MyButton",
> wx.DefaultPosition, wx.DefaultSize, 0 )
>    m_toolBar1.AddControl( m_button1 )
>
> (i.e. "self." is missing)

I had problem like that with the first beta, but not the one from
August.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python & Go

[Michele Simionato]

On Nov 14, 12:26 pm, kj  wrote:
>
> The two goals of replacing C with "something more modern" and at
> the same time have a "nearly zero learning curve" seem to me mutually
> negating.  The closer to zero the learning curve is, the closer to
> C/C++, and therefore the less modern, that language will be.

Not at all. A language with a small learning curve should be as far as
possible for C++!

Go is in many ways simpler than C (no header files, a simpler
compilation process, no pointer arithmetic, no ternary operator, no
while loop, in a sense no threads, etc) and it has an object
orientation simpler than most languages; actually it looks even
simpler than Python in many respects (no properties, no decorators, no
metaclasses,
a much simpler version of inheritance ...). It has static typing that
makes things a bit more complicated, but also safer in same respect.
It has also reflection and the ability to do a lot of things at
runtime. If people starts writing libraries it has the potential to
cover both C and Python niches at the same time!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: bootstrapping on machines without Python

[Jonathan Hartley]

On Nov 13, 1:57 pm, Tim Golden  wrote:
> Jonathan Hartley wrote:
> > While examining py2exe et al of late, my thoughts keep returning to
> > the idea of writing, in C or similar, a compiled stand-alone
> > executable 'bootstrapper', which:
> > 1) downloads and install a Python interpreter if none exists
> > 2) runs the application's Python source code using this interpreter.
>
> Thinking aloud about what you're describing here... Assuming Windows,
> as your starting point is py2exe and I imagine that most Unix-like
> boxes already have Python on them.
>
> Step 1: The user downloads a tiny myapp.exe which is basically a zip of the
> myapp package / files plus an .exe header which will...
>
> Step 2a: ... download a minimised? (ie custom-built) Python interpreter
> and stdlib bundle which is just enough to run the app. Or...
>
> Step 2b: ... download and install the official python.org Windows
> installer for version x.y identified as the highest known to run
> this app if...
>
> Step 2bi) ... that version of the interpreter isn't already installed
> and registered on that machine (at least: for that user).
>
> My step 2a seems to be little better than a bundled py2exe, so I can
> only assume you mean Step 2b, especially given your comment below
> about ending up with an installation of Python where one wasn't
> before. This, though, seems fraught with accusations of backdoor
> installations etc.
>
> Have I misunderstood you? For the Record, I'm entirely in favour of moves
> to make Python use on Windows more seamless, attractive, consistent,
> etc. I was going to comment positively on your recent PyChooser widget
> and to plug a similar but unpublished one of my own. But I'm not sure
> if this particular proposal has enough wings to make it fly.
>
> TJG

Hi Tim. Thanks for that.

Yes, you have understood pretty much perfectly. I was envisaging
something like 2b.

I'm very much enamored of creating cross-platform apps, but I'm
focused on deployment on Windows first, because this is where most
users are, and also where the problem seems to need the most work.

Your input is very much appreciated. It may be that you are right that
I haven't thought this through clearly enough.

Incidentally, I'd love to see your approach of dealing with the
problem that pychoose addresses - Since creating it, I'm gripped with
paranoia that it is failing to take account of lots of things which
will trip me up later (or worse- trip other people up too, if anyone
uses it)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: More Python versions on an XP machine

[DreiJane]

Hi,

there are several ways to do that besides starting python scripts
with a double-click on a desktop icon (that can only work with the
one and only python version of the registry).

One is to start the new python version directly from a "DosBox".
You could copy python.exe or pythonw.exe from the new version
directly into the directory, where your python script is - both are
only some kB large - and then execute "python your_script" in the
cmd.exe. After some "cd"s to the directory of your script. Besides -
it is no bad idea to have some copies of the cmd.exe at several
places of your file system - the correct run of cmd.exe is not
depending on its place in C:\Windows\system32. It also runs from
external disks.

This is, how i do that, not optimal probably, but easy to understand.

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

Re: python-daemon and upstart

[Paul Rudin]

Ben Finney  writes:

> Paul Rudin  writes:
>
>> I'm experimenting with the daemon module
>>  and upstart
>> .
>
> First: Thank you for using ‘python-daemon’; it's getting more widespread
> use all the time, which is really helping to find all the quirks of API
> and implementation. (And good for my ego at the same time.)
>
>
Thanks for writing it.

> There's something I don't understand, which may be more of an upstart
>> issue than a python issue, but I thought I'd start by posting here.
>
> I'm unfamiliar with ‘upstart’, I hope others with more experience can
> offer more insight.
>

On Karmic it seems to be the standard way for starting and stopping
system processes.

>> Here's a test script:
> […]
>
> The program looks fine to me. What happens if you run the program,
> without getting ‘upstart’ involved?
>

As for as I can tell everything is ok invoking the script from the
command line.

>> and here's a testdaemon.conf upstart configuration:
>>
>> description "test daemon"
>> expect daemon
>> chdir /tmp
>> exec /tmp/testdaemon.py
>>
>> If I do "sudo start testdaemon" I see the "testdaemon.py" process
>> starting, and the file '/tmp/test.txt' is being written to every 5
>> seconds, so everything has kicked off. 
>
> Good to know.
>
>> The thing I don't understand is why start does not return. I guess it
>> doesn't think that the process and properly started and daemonized
>> itself? Quite possibly it's just that I don't understand this stuff
>> well...
>
> As I say, I'm completely unfamiliar with the details of ‘upstart’. Can
> you point me to whatever you used to understand it?

The man pages on Karmic - "man start" etc. and the documentation on the
upstart website:  - check the getting
started page and the wiki. Also some blog pages by its author:

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

Re: __import__ returns module without it's attributes?

[Dave Angel]

Zac Burns wrote:

I've overloaded __import__ to modify modules after they are
imported... but running dir(module) on the result only returns
__builtins__, __doc__, __file__,
__name__, __package__, and __path__.

Why is this? More importantly, where can I hook in that would allow me
to see the contents of the module?

--
Zachary Burns
(407)590-4814
Aim - Zac256FL
Production Engineer (Digital Overlord)
Zindagi Games

  
I'm probably not the one to give you the actual answer (at least not in 
the next couple of days), but I could help you ask a better question.


Provide a simple example of your code, and what it does.  Describe the 
python version and OS platform you're running it on.  And detail the 
contents of any extra files or environment values that are needed to 
reproduce the problem.


(You may find http://www.catb.org/~esr/faqs/smart-questions.html  useful)

BTW, I don't know of any method __import__(), only a builtin function, 
so I don't see how you can overload it. But your example should make it 
clear what you really meant.


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

Documentation bugs in 3.1 - C-API - TypeObjects

[DreiJane]

Hello,

this page http://docs.python.org/3.1/c-api/typeobj.html has a bad
error:

"
PyTypeObject* PyObject.ob_type

This is the type’s type, in other words its metatype. It is
initialized by the argument to the PyObject_HEAD_INIT macro, and its
value should normally be &PyType_Type. However, for dynamically
loadable extension modules that must be usable on Windows (at least),
the compiler complains that this is not a valid initializer.
Therefore, the convention is to pass NULL to the PyObject_HEAD_INIT
macro and to initialize this field explicitly at the start of the
module’s initialization function, before doing anything else. This is
typically done like this:

Foo_Type.ob_type = &PyType_Type;
"

This cannot work, because Foo_Type is no PyObject but a PyVarObject
(independent
of the use of PyVarObject_HEAD_INIT or PyObject_HEAD_INIT). The code
line would
work so:

((PyObject *)&Foo_Type)->ob_type = &PyType_Type

But in the Tutorial for Extensions and Embedding we are advised as
follows:
"
This is so important that we’re going to pick the top of it apart
still further:
  PyVarObject_HEAD_INIT(NULL, 0)
This line is a bit of a wart; what we’d like to write is:
  PyVarObject_HEAD_INIT(&PyType_Type, 0)
as the type of a type object is “type”, but this isn’t strictly
conforming C and some compilers complain. Fortunately, this member
will be filled in for us by PyType_Ready().
"

What now ?

Another problem, which might be a documentation bug, is the last
sentence here:
"
destructor PyTypeObject.tp_dealloc

A pointer to the instance destructor function. This function must be
defined unless the type guarantees that its instances will never be
deallocated (as is the case for the singletons None and Ellipsis).

The destructor function is called by the Py_DECREF() and Py_XDECREF()
macros when the new reference count is zero. At this point, the
instance is still in existence, but there are no references to it. The
destructor function should free all references which the instance
owns, free all memory buffers owned by the instance (using the freeing
function corresponding to the allocation function used to allocate the
buffer), and finally (as its last action) call the type’s tp_free
function. If the type is not subtypable (doesn’t have the
Py_TPFLAGS_BASETYPE flag bit set), it is permissible to call the
object deallocator directly instead of via tp_free.
"

What ? Where do we "call" these methods ? Primarily we write them down
to get members
of the Foo_Type struct and our question is where. Shall this sentence
mean, that we
write the function, we'd normally use for tp_dealloc und which behaves
like it, to the place of tp_free ?

I've run into terrible trouble with extension classes, which have
neither members nor init.
They work (and i am quite happy about that) but finding out, that
tp_dictoffset had to be
set (for what i wanted) took more than a day of searching - including
öecture of typeobject.c and object.c - and i cannot derive from them.

class(my_extension_class): ... doesn't crash, but results in objects,
which have the type
my_extension_class, what means, that they do not call their __init__.
In certain
circumstances a correct tp_free seems to be a premise for inheritance,
thus i'd very like
to understand the quoted passage.

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

How to know if a file is a text file

[Luca Fabbri]

Hi all.

I'm looking for a way to be able to load a generic file from the
system and understand if he is plain text.
The mimetype module has some nice methods, but for example it's not
working for file without extension.

Any suggestion?

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

Re: Anything better than shutil?

[Chris Withers]

Roy Smith wrote:

The idea interface I see would be one like:

  shutil.copy([source_dir, '*.conf'], conf_dir)

the idea is that if the first argument is a list (or maybe any
iterable other than a string?), it would automatically get run through
os.path.join().  And, the result would always get passed through glob
(), just like a normal shell would.  Does anything like this exist?


Why don't you wrap up your earlier code:

> configs = glob.glob(os.path.join(source_dir, '*.conf'))
> for conf_file in configs:
> shutil.copy(conf_file, conf_dir)


...in a module with the exact interface you're after?

Chris

--
Simplistix - Content Management, Batch Processing & Python Consulting
   - http://www.simplistix.co.uk
--
http://mail.python.org/mailman/listinfo/python-list

Anything better than shutil?

[Roy Smith]

I'm converting some old bash scripts to python.  There's lots of
places where I'm doing things like "rm $source_dir/*.conf".  The best
way I can see to convert this into python is:

configs = glob.glob(os.path.join(source_dir, '*.conf'))
for conf_file in configs:
shutil.copy(conf_file, conf_dir)

which is pretty clunky.  The old bash script ran under cygwin on
windows, and the cygwin layer handled the slash-backslash business for
me.  Is there a better way to do what I'm doing?

I don't want to use any of the popen() variants to call a real shell.
The problem I'm trying to solve is that fork/exec is painfully slow
under cygwin, so that would defeat the whole purpose.

The idea interface I see would be one like:

  shutil.copy([source_dir, '*.conf'], conf_dir)

the idea is that if the first argument is a list (or maybe any
iterable other than a string?), it would automatically get run through
os.path.join().  And, the result would always get passed through glob
(), just like a normal shell would.  Does anything like this exist?

I'm currently using python 2.5.1.  It's possible, but moderately
painful, to move to a newer version.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: feedback on function introspection in argparse

[Chris Withers]

Yuv wrote:

On Nov 8, 1:33 am, Carl Banks  wrote:

Is the docstring expected to be formatted according to some
convention?


We tried to comply to PEP 257 and we're open to suggestions on this.


I'd suggest at the very least supporting Sphinx docstrings that have the 
parameters in them...


Chris

--
Simplistix - Content Management, Batch Processing & Python Consulting
   - http://www.simplistix.co.uk
--
http://mail.python.org/mailman/listinfo/python-list

Re: run all scripts in sub-directory as subroutines?

[Dave Angel]

Tobiah wrote:

This works fine, but in the sub-modules the sys.path appropriately
returns the same as from the parent, I want them to know their own file
names. How?? I can pass it to them, but wondered if there is a more
self-sufficient way for a module to know from where it was invoked.



I like the idea of passing the information to the module.
Probably by setting a global variable into it.



  
As ryles pointed out in this thread, over a month ago, that's already 
there.  The system loader creates a global variable __file__ with the 
full path to the module.  So any module can see exactly where it was 
loaded from.



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

ANN: PyGUI 2.1

[Greg Ewing]

PyGUI 2.1 is available:

  http://www.cosc.canterbury.ac.nz/greg.ewing/python_gui/

Highlights of this version:

* Win32:
Fixed bug preventing PyGUI apps from working under pythonw
Fixed incorrect mouse coordinates in ScrollableView
Added more standard cursors

* MacOSX:
Application menu now has working Hide, Hide Others and Show All
commands.

Plus a few other bug fixes and improvements.


What is PyGUI?
--

PyGUI is a cross-platform GUI toolkit designed to be lightweight
and have a highly Pythonic API.
--
http://mail.python.org/mailman/listinfo/python-list

Re: The ol' [[]] * 500 bug...

[Ulrich Eckhardt]

Diez B. Roggisch wrote:
> kj schrieb:
>>   lol = [[] for _ in xrange(500)]
> 
> If you call that hideous, I suggest you perform the same exercise in
> Java or C++ - and then come back to python and relax

I might be missing something that's not explicitly mentioned here, but I'd 
say that all non-associative containers in C++ have a resize() method, some 
even taking an initial size in their constructor.

That said, [[]]*500 is IMHO more readable.

Uli

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

Re: Choosing GUI Module for Python

[Dietmar Schwertberger]

sturlamolden schrieb:

I personally feel the wxPython support in the 3.1 beta of
wxFormBuilder makes the choise rather simple. It generates a Python
file with classes for all WYSIWYG GUI forms/windows/dialogs. Then in
our Python code, we just import and inherit the form, and implement
the event handlers. It can't be done easier. GUI programming with
Python is now comparable to programming with VB, Delphi or C#. I am
using it for all my projects now. It just feels right.


Yes, wxFormBuilder looks very promising.

But I don't think that 3.1 in it's current state it can be recommended
for general use already. I just tried the latest version (from August)
and it does not even generate correct Python code:

  self.m_toolBar1 = self.CreateToolBar( wx.TB_HORIZONTAL, wx.ID_ANY )
  self.m_button1 = wx.Button( self.m_toolBar1, wx.ID_ANY, u"MyButton", 
wx.DefaultPosition, wx.DefaultSize, 0 )

  m_toolBar1.AddControl( m_button1 )

(i.e. "self." is missing)



Regards,

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

Re: COM Server wirh MS Excel

[Cannonbiker]

On 14 lis, 14:34, Chris Withers  wrote:
> Cannonbiker wrote:
> > Hi,
> > I would lake use win32com with Excel. I tried to use python COM
> > example from 'The Quick Python Book' on page 250 but without success.
>
> I suggest you have a good read ofhttp://www.python-excel.org.
>
> You may well find you don't need to use COM at all...#
>
> Chris
>
> --
> Simplistix - Content Management, Batch Processing & Python Consulting
>             -http://www.simplistix.co.uk

Thanks but this isn't solution for me. I need call Python functions
from Excel and receive result back in Excel...
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python simply not scaleable enough for google?

[Willem Broekema]

On Nov 14, 8:55 am, Vincent Manis  wrote:
> On 2009-11-13, at 23:20, Robert Brown wrote, quoting me:
> > Please look atCLPython. [...]
> Ah, that does explain it.

I bet you didn't even look at it. FWIW, I'm the author of CLPython.

> CLOS is most definitely the wrong vehicle for implementing
> Python method dispatch. CLOS is focused around generic functions that 
> themselves
> do method dispatch, and do so in a way that is different from Python's. If I 
> were
> building a Python implementation in CL, I would definitely NOT use CLOS, but
> do my own dispatch using funcall (the CL equivalent of the now-vanished Python
> function apply).

CLOS is way more than method dispatch, it's an infrastructure for
classes, metaclasses, slots, method combinations. And within method
dispatch there are lots of opportunities to customize the behaviour.
Ignoring all that functinality when implementing an object-oriented
language, and using "dispatch using funcall" whatever that means, just
sounds ridiculous. (And funcall != apply.)

> > Method lookup is just the tip if the iceburg.  How about comparison?  Here 
> > are
> > some comments fromCLPython'simplementation of compare.  There's a lot going
> > on.  It's complex and SLOW.

Right, although by special-casing the most common argument types you
can save most of that lookup.

> Re comparison. Python 3 has cleaned comparison up a fair bit. In particular, 
> you
> can no longer compare objects of different types using default comparisons.
> However, it could well be that there are nasty little crannies of inefficiency
> there, they could be the subject of PEPs after the moratorium is over.

It might have gotten a bit better, but the central message still
stands: Python has made design choices that make efficient compilation
hard.

> OK, let me try this again. My assertion is that with some combination of 
> JITting,
> reorganization of the Python runtime, and optional static declarations, Python
> can be made acceptably fast,

That does not contradict that, had other language design choices been
made, it could be much easier to get better performance. Python may in
general be about as dynamic as Common Lisp from a _user_ perspective,
but from an implementator's point of view Python is harder to make it
run efficiently.

Here are some examples of design choices in Common Lisp that help it
perform very well; while in Python there is more freedom at the cost
of performance:

 - Lisp hashtables, arrays, numbers, and strings are not subclassable.
The specialized operations on them, like function aref for array index
referencing, don't invoke arbitrary user-level code, and also not
lookup of magic methods.

 - Certain Lisp sequence objects, like lists and arrays, can easily be
allocated on the stack;

 - Lisp allows type declarations, like for variables, array types,
function arguments and return values.

 - Even if Python had type declarations, it is possible to define a
subclass that redefines semantics. E.g. it's possible to subclass
'int' and redefine what '+' means, making a declaration that "x is of
type int" not as valuable as in Lisp.

 - A recursive function defined at module level, can not assume that
its name refers to itself.

 - Every function can be called using keyword arguments or positional
arguments. E.g. with the definition "def f(x,y): ..", some possible
calls are: f(1), f(1,2), f(x=1, y=2), f(1,y=2) so every function must
be prepared to do keyword argument processing. (This can be considered
a lack of separation between internal details and external interface.)

 - Every function call could potentially be a call to locals() (e.g.
f=locals; f()), which means every function that contains a function
call must store the value of all locals, even of "dead" variables.

 - Built-in functions can be shadowed.

 - The potential fields of a Python object are often not defined, as
arbitrary attributes can be set. Accessors for fields generally
generally have to retrieve the value from a dict.

 - When limiting the potential fields of a class instance using
__slots__, subclasses may override __slots__ thus this is hardly
limiting.

 - Python attribute lookup and comparison (as shown in a previous
mail) are examples of hairy behaviour that often mean the lookup of
several (!) __magic__ methods and could invoke arbitrary user code.
(Lisp in particular offers "structures" whose definition is fixed,
that inline all accessors, for maximum efficiency.)

This is just to show how language design leads to efficieny
characteristics. That there is a need for projects like NumPy and
Cython, follows in my eyes from Python being too dynamic for its own
good, with no way to tame it. In Common Lisp there would be less need
to go to C for speed, because of user-supplied type declarations and
compiler-based type inferencing.

It has been said that CLPython is a very good counterargument for
"just write a Python to Lisp compiler to make things fast", and even I
as its developer agree. Li

Re: More Python versions on an XP machine

[Diez B. Roggisch]

Gabor Urban schrieb:

Hi guys,

this a very MS specific question. I do use a rather old Python
version, because we have a couple of applications written for that.
Porting them to a newer Python is not allowed by the bosses. Now we
will start a new project with latest stable Python. Can I have them
both on my computer, and how should I do that.


As numerous posts here have indicated over the past years, and even this 
week - and to say it with a somewhate prematurely awarded Nobel Prize 
Winner:


 YES, YOU CAN!

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

Re: A "terminators' club" for clp

[Alf P. Steinbach]

* gil_johnson:

On Nov 13, 5:29 pm, kj  wrote:
[...]

Or it could be set up so that at least n > 1 "delete" votes and no
"keep" votes are required to get something nixed.  Etc.

This seems simpler than all-out moderation.

("all-out moderation"? now, there's an oxymoron for ya!)



How about using a "rank this post" feature? Anybody could rank a post
as spam, and a sufficiently large number of negatives would quickly
draw the attention of someone with the power to kill the message. I
suppose even this is subject to abuse, allowing harassment of a
legitimate poster., but my guess is that the votes against counterfeit
Nike shoes, etc., would outnumber the most energetic "vote troll."


The problem with moderation isn't getting rid of spam and trolls etc., but 
turnaround time.


In some cases trivial questions cause a flood of essentially identical trivial 
responses to pile up before the mods can get at them. And then there's the 
dilemma of whether to approve all that or make judgements based on /content/. 
The latter leads to a very slippery slope, you really don't want the mods to do 
that, plus that in some cases what might appear trivial leads to very fruitful 
discussion of not-so-trivial aspects.


But it's not either/or: it's possible to have both an unmoderated group (fast 
turnaround, much spam, some heated discussion) and a corresponding moderated 
group (slow turnaround, no spam, far less heat, presence of more experts), e.g. 
as [comp.lang.c++] and [oomp.lang.c++.moderated]. :-)



Cheers & hth.,

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

Re: COM Server wirh MS Excel

[Cannonbiker]

On 14 lis, 14:24, Cannonbiker  wrote:
The ServerCOM file is here
http://home.tiscali.cz/fotogalerie7/ServerCOM.py

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

More Python versions on an XP machine

[Gabor Urban]

Hi guys,

this a very MS specific question. I do use a rather old Python
version, because we have a couple of applications written for that.
Porting them to a newer Python is not allowed by the bosses. Now we
will start a new project with latest stable Python. Can I have them
both on my computer, and how should I do that.

Thanks,

PS: This is my computer at the office :-)
-- 
Linux: Choice of a GNU Generation
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: COM Server wirh MS Excel

[Chris Withers]

Cannonbiker wrote:

Hi,
I would lake use win32com with Excel. I tried to use python COM
example from 'The Quick Python Book' on page 250 but without success.


I suggest you have a good read of http://www.python-excel.org.

You may well find you don't need to use COM at all...#

Chris

--
Simplistix - Content Management, Batch Processing & Python Consulting
   - http://www.simplistix.co.uk
--
http://mail.python.org/mailman/listinfo/python-list

Re: A "terminators' club" for clp

[gil_johnson]

On Nov 13, 5:29 pm, kj  wrote:
[...]
> Or it could be set up so that at least n > 1 "delete" votes and no
> "keep" votes are required to get something nixed.  Etc.
>
> This seems simpler than all-out moderation.
>
> ("all-out moderation"? now, there's an oxymoron for ya!)
>

How about using a "rank this post" feature? Anybody could rank a post
as spam, and a sufficiently large number of negatives would quickly
draw the attention of someone with the power to kill the message. I
suppose even this is subject to abuse, allowing harassment of a
legitimate poster., but my guess is that the votes against counterfeit
Nike shoes, etc., would outnumber the most energetic "vote troll."
Gil

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

COM Server wirh MS Excel

[Cannonbiker]

Hi,
I would lake use win32com with Excel. I tried to use python COM
example from 'The Quick Python Book' on page 250 but without success.
The COM Module is successfully registetred but MS Excel reported this
message
http://home.tiscali.cz/fotogalerie7/Error80004005.gif

I tried omitted following statement (how counselling on
http://manning-sandbox.com/thread.jspa?messageID=7263):
#_reg_class_spec_ = "ar_com_servers.DemoServer
and new registration but not successful :-(

Pleas help me
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Help with database planning

[Ben Finney]

Juliano  writes:

> We've been working with an ontology at my department […] I have been
> being pushed towards changing the basic plan and build a DB so that
> data access will be faster and easier for both the desktop GUI and the
> web app. Right now, I'm trying to work with sqlite, since it can be
> used as a separate file for the GUI and as a DB for Django (which may
> be the choice for the web interface).

You're also working with a relational database system, which will make
it relatively easy to migrate your database structure to a different
relational database system if that proves necessary.

> I have been redaing some books on DBs but I kind of get stuck when it
> comes to the normalization and the planning of the tables.

No shame in that; it's somewhat counter-intuitive, though it's an
essential topic when working with databases. Try the Wikipedia article
http://en.wikipedia.org/wiki/Database_normalization>.

> The problem is that we have basically four fields that can be arranged
> in a tree- like structure.

Tree-like structures don't fit into table-like relations very well; but
it's not hopeless.

> So, for ONE *concept*, we have, usually, MANY *slots*, each *slot* has
> ONE *facet*, and each *facet* can have MORE THAN ONE *filler*.
> Besides, some *slots* and *fillers* are themselves *concepts*,
> creating a sort of recursive reference.

Recursive references, on the other hand, are deadly to storing data
sanely in a relational database: while recursion is algorithmically
elegant, it makes for hideously slow operations querying, and especially
modifying, the database.

The focus, then, should be on teasing out a non-recursive, declarative
schema for the data. This is a well-known problem, with many possible
solutions. Several popular approaches (each with different trade-offs)
are “Adjacency list” , “Materialized path”, and “Nested sets”. Use those
terms in database-savvy circles and you'll get lots of explanations.

> What would be a good way to create tables for this situation?
> In fact, this is the first time I've ever tried to create a DB, so I'm
> completely lost.

This topic is rather orthogonal to Python. You would do well to seek
further guidance from a Usenet group such as news:comp.databases>.
Good fortune, and persist; you're going into databases off the deep end
with a problem domain like this :-)

-- 
 \   “I distrust those people who know so well what God wants them |
  `\to do to their fellows, because it always coincides with their |
_o__)  own desires.” —Susan Brownell Anthony, 1896 |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list