Re: python simply not scaleable enough for google?

2009-11-13 Thread sturlamolden
On 14 Nov, 08:39, Robert Brown  wrote:

> > Using Python 3 annotations, one can imagine a Python compiler that does the
> > appropriate thing (shown in the comments) with the following code.
>
> I can imagine a lot too, but we're talking about Python as it's specified
> *today*.  The Python language as it's specified today is hard to execute
> quickly.  Not impossible, but very hard, which is why we don't see fast Python
> systems.

It would not be too difficult to have a compiler like Cython recognize
those annotations instead of current "cdef"s.

With Cython we can get "Python" to run at "the speed of C" just by
adding in optional type declarations for critical variables (most need
not be declared).

With CMUCL and SBCL we can make Common Lisp perform at "the speed of
C", for the same reason.

Also a Cython program will usually out-perform most C code. It
combines the strengths of C, Fortran 90 and Python.












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


Re: python simply not scaleable enough for google?

2009-11-13 Thread Robert Brown

Vincent Manis  writes:

> On 2009-11-13, at 18:02, Robert Brown wrote:
>
>> Common Lisp and Scheme were designed by people who wanted to write
>> complicated systems on machines with a tiny fraction of the horsepower of
>> current workstations.  They were carefully designed to be compiled
>> efficiently, which is not the case with Python.  There really is a
>> difference here.  Python the language has features that make fast
>> implementations extremely difficult.
>
> Not true. Common Lisp was designed primarily by throwing together all of the
> features in every Lisp implementation the design committee was interested
> in.  Although the committee members were familiar with high-performance
> compilation, the primary impetus was to achieve a standardized language that
> would be acceptable to the Lisp community. At the time that Common Lisp was
> started, there was still some sentiment that Lisp machines were the way to
> go for performance.

Common Lisp blends together features of previous Lisps, which were designed to
be executed efficiently.  Operating systems were written in these variants.
Execution speed was important.  The Common Lisp standardization committee
included people who were concerned about performance on C-optimized hardware.

> As for Scheme, it was designed primarily to satisfy an aesthetic of
> minimalism. Even though Guy Steele's thesis project, Rabbit, was a Scheme
> compiler, the point here was that relatively simple compilation techniques
> could produce moderately reasonable object programs. Chez Scheme was indeed
> first run on machines that we would nowadays consider tiny, but so too was
> C++. Oh, wait, so was Python!

The Scheme standard has gone through many revisions.  I think we're up to
version 6 at this point.  The people working on it are concerned about
performance.  For instance, see the discussions about whether the order of
evaluating function arguments should be specified.  Common Lisp evaluates
arguments left to right, but Scheme leaves the order unspecified so the
compiler can better optimize.  You can't point to Rabbit (1978 ?) as
representative of the Scheme programming community over the last few decades.

> Using Python 3 annotations, one can imagine a Python compiler that does the
> appropriate thing (shown in the comments) with the following code.

I can imagine a lot too, but we're talking about Python as it's specified
*today*.  The Python language as it's specified today is hard to execute
quickly.  Not impossible, but very hard, which is why we don't see fast Python
systems.

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


python-daemonize and upstart

2009-11-13 Thread Paul Rudin

I'm experimenting with the daemon module
 and upstart
. 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.

Here's a test script:
#!/usr/bin/python2.6
import daemon
import time

def work():
count = 0
while True:
with open('/tmp/test.txt', 'a') as f:
f.write(str(count))
f.write('\n')
count += 1
time.sleep(5)

def main():
with daemon.DaemonContext(working_directory='/tmp'):
work()

if __name__ == "__main__":
main()

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. 

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


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


Re: the unicode saga continues...

2009-11-13 Thread Ulrich Eckhardt
Ethan Furman wrote:
> Python 2.5.4 (r254:67916, Dec 23 2008, 15:10:54) [MSC v.1310 32 bit
> (Intel)] on win32
> Type "help", "copyright", "credits" or "license" for more information.
>  >>> print u'\xed'
> í
>  >>> print u'\xed'.encode('cp437')
> í
>  >>> print u'\xed'.encode('cp850')
> í
>  >>> print u'\xed'.encode('cp1252')
> φ
>  >>> import locale
>  >>> locale.getdefaultlocale()
> ('en_US', 'cp1252')
> 
> My confusion lies in my apparant codepage (cp1252), and the discrepancy
> with character u'\xed' which is absolutely an i with an accent; yet when
> I encode with cp1252 and print it, I get an o with a line.
 ^^
For the record: I read a small Greek letter phi in your posting, not an o 
with a line. If I encode according to my default locale (UTF-8), I get the 
letter i with the accent. If I encode with codepage 1252, I get a marker for 
an invalid character on my terminal. This is using Debian though, not MS 
Windows.

Try printing the repr() of that. The point is that internally, you have the 
codepoint u00ED (u'\xed'). Then, you encode this thing in various codepages, 
which yields a string of bytes representing this thing ('\xa1', '\xa1' and 
'\xed'), useful for storing on disk when the file uses said codepage or 
other forms of IO.

Now, with a Unicode string, the output (print) knows what to do, it encodes 
it according to the defaultlocale and sends the resulting bytes to stdout. 
With a byte string, I think it directly forwards the content to stdout.

Note:
 * If you want to verify your code, rather use 'print repr(..)'.
 * I could imagine that your locale is simply not set up correctly.

Uli

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


Re: python simply not scaleable enough for google?

2009-11-13 Thread Vincent Manis
On 2009-11-13, at 22:51, Alf P. Steinbach wrote:
> It's sort of hilarious. 
It really is, see below. 

> So no, it's not a language that is slow, it's of course only concrete 
> implementations that may have slowness flavoring. And no, not really, they 
> don't, because it's just particular aspects of any given implementation that 
> may exhibit slowness in certain contexts. And expanding on that trend, later 
> in the thread the observation was made that no, not really that either, it's 
> just (if it is at all) at this particular point in time, what about the 
> future? Let's be precise! Can't have that vague touchy-feely impression about 
> a /language/ being slow corrupting the souls of readers.
Because `language is slow' is meaningless. 

An earlier post of mine listed four examples where the common wisdom was `XXX 
is slow' and yet where that 
turned out not to be the case.

Some others. 

1. I once owned a Commodore 64. I got Waterloo Pascal for it. I timed the 
execution of some program 
(this was 25 years ago, I forget what the program did) at 1 second per 
statement. Therefore: `Pascal 
is slow'. 

2. Bell Labs produced a fine programming language called Snobol 4. It was slow. 
But some folks at 
IIT in Chicago did their own implementation, Spitbol, which was fast and 
completely compatible. 
Presto: Snobol 4 was slow, but then it became fast. 

3. If you write the following statements in Fortran IV (the last version of 
Fortran I learned)

   DO 10 I=1, 100
 DO 10 J=1, 100
   A(I, J) = 0.0
10 CONTINUE

you would paralyze early virtual memory systems, because Fortran IV defined 
arrays to be stored 
in column major order, and the result was extreme thrashing. Many programmers 
did not realize 
this, and would naturally write code like that. Fortran cognoscenti would 
interchange the two 
DO statements and thus convert Fortran from being a slow language to being a 
fast one. 

4. When Sun released the original Java system, programs ran very slowly, and 
everybody said 
`I will not use Java, it is a slow language'. Then Sun improved their JVM, and 
other organizations 
wrote their own JVMs which were fast. Therefore Java became a fast language. 

> Actually, although C++ has the potential for being really really fast (and 
> some C++ programs are), the amount of work you have to add to realize the 
> potential can be staggering. This is most clearly evidenced by C++'s standard 
> iostreams, which have the potential of being much much faster than C FILE i/o 
> (in particular Dietmar Kuhl made such an implementation), but where the 
> complexity of and the guidance offered by the "design" is such that nearly 
> all extant implementations are painfully slow, even compared to C FILE. So, 
> we generally talk about iostreams being slow, knowing full well what we mean 
> and that fast implementations are theoretically possible (as evidenced by 
> Dietmar's)  --  but "fast" and "slow" are in-practice terms, and so what 
> matters is in-practice, like, how does your compiler's iostreams 
> implementation hold up.
OK, let me work this one out. Because most iostreams implementations are very 
slow, C++ is a slow 
language. But since Kuhl did a high-performance implementation, he made C++ 
into a fast language. 
But since most people don't use his iostreams implementation, C++ is a slow 
language again, except
for organizations that have banned iostreams (as my previous employers did) 
because it's too slow, 
therefore C++ is a fast language. 

Being imprecise is so much fun! I should write my programs this imprecisely. 

More seriously, when someone says `xxx is a slow language', the only thing they 
can possibly mean 
is `there is no implementation in existence, and no likelihood of an 
implementation being possible, 
that is efficient enough to solve my problem in the required time' or perhaps 
`I must write peculiar
code in order to get programs to run in the specified time; writing code in the 
way the language seems
to encourage produces programs that are too slow'. This is a very sweeping 
statement, and at the very
least ought to be accompanied by some kind of proof. If Python is indeed a slow 
language, then Unladen 
Swallow and pypy, and many other projects, are wastes of time, and should not 
be continued. 

Again, this doesn't have anything to do with features of an implementation that 
are slow or fast. 
The only criterion that makes sense is `do programs run with the required 
performance if written 
in the way the language's inventors encourage'. Most implementations of every 
language have a nook 
or two where things get embarrassingly slow; the question is `are most programs 
unacceptably slow'. 

But, hey, if we are ok with being imprecise, let's go for it. Instead of saying 
`slow' and `fast',
why not say `good' and `bad'?

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


Re: python simply not scaleable enough for google?

2009-11-13 Thread Robert Brown

Vincent Manis  writes:

> On 2009-11-13, at 17:42, Robert Brown wrote, quoting me: 

>> ... Python *the language* is specified in a way that
>> makes executing Python programs quickly very very difficult.  

> That is untrue. I have mentioned before that optional declarations integrate
> well with dynamic languages. Apart from CL and Scheme, which I have
> mentioned several times, you might check out Strongtalk (typed Smalltalk),
> and Dylan, which was designed for high-performance compilation, though to my
> knowledge no Dylan compilers ever really achieved it.

You are not making an argument, just mentioning random facts.  You claim I've
made a false statement, then talk about optional type declarations, which
Python doesn't have.  Then you mention Smalltalk and Dylan.  What's your
point?  To prove me wrong you have to demonstrate that it's not very difficult
to produce a high performance Python system, given current Python semantics.

>> I'm tempted to say it's impossible, but great strides have been made
>> recently with JITs, so we'll see.
>
>> If you want to know why Python *the language* is slow, look at the Lisp
>> code CLPython generates and at the code implementing the run time.  Simple
>> operations end up being very expensive.  Does the object on the left side
>> of a comparison implement compare?  No, then does the right side implement
>> it?  No, then try something else 

> I've never looked at CLPython. Did it use a method cache (see Peter
> Deutsch's paper on Smalltalk performance in the unfortunately out-of-print
> `Smalltalk-80: Bits of History, Words of Advice'? That technique is 30 years
> old now.

Please look at CLPython.  The complexity of some Python operations will make
you weep.  CLPython uses Common Lisp's CLOS method dispatch in various places,
so yes, those method lookups are definitely cached.

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

   ;; This function is used in comparisons like <, <=, ==.
   ;; 
   ;; The CPython logic is a bit complicated; hopefully the following
   ;; is a correct translation.

   ;; If the class is equal and it defines __cmp__, use that.

   ;; The "rich comparison" operations __lt__, __eq__, __gt__ are
   ;; now called before __cmp__ is called.
   ;; 
   ;; Normally, we take these methods of X.  However, if class(Y)
   ;; is a subclass of class(X), the first look at Y's magic
   ;; methods.  This allows the subclass to override its parent's
   ;; comparison operations.
   ;; 
   ;; It is assumed that the subclass overrides all of
   ;; __{eq,lt,gt}__. For example, if sub.__eq__ is not defined,
   ;; first super.__eq__ is called, and after that __sub__.__lt__
   ;; (or super.__lt__).
   ;; 
   ;; object.c - try_rich_compare_bool(v,w,op) / try_rich_compare(v,w,op)

   ;; Try each `meth'; if the outcome it True, return `res-value'.

   ;; So the rich comparison operations didn't lead to a result.
   ;; 
   ;; object.c - try_3way_compare(v,w)
   ;; 
   ;; Now, first try X.__cmp__ (even if y.class is a subclass of
   ;; x.class) and Y.__cmp__ after that.

   ;; CPython now does some number coercion attempts that we don't
   ;; have to do because we have first-class numbers. (I think.)

   ;; object.c - default_3way_compare(v,w)
   ;; 
   ;; Two instances of same class without any comparison operator,
   ;; are compared by pointer value. Our function `py-id' fakes
   ;; that.

   ;; None is smaller than everything (excluding itself, but that
   ;; is catched above already, when testing for same class;
   ;; NoneType is not subclassable).

   ;; Instances of different class are compared by class name, but
   ;; numbers are always smaller.

   ;; Probably, when we arrive here, there is a bug in the logic
   ;; above. Therefore print a warning.
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: python simply not scaleable enough for google?

2009-11-13 Thread Alf P. Steinbach

* Rami Chowdhury:
On Thu, 12 Nov 2009 12:02:11 -0800, Alf P. Steinbach  
wrote:
I think that was in the part you *snipped* here. Just fill in the 
mentioned qualifications and weasel words.


OK, sure. I don't think they're weasel words, because I find them 
useful, but I think I see where you're coming from.


Specifically, I reacted to the statement that >, made in response to 
someone upthread, in the context of Google finding CPython overall too 
slow.


IIRC it was "the speed of a language" that was asserted to be nonsense, 
wasn't it?


Yes, upthread.

It's sort of hilarious. 

  Alain Ketterlin:
  "slide/page 22 explains why python is so slow"

  Vincent Manis (response):
  "Python is a programming language; it is implementations that have speed
  or lack thereof"

This was step 1 of trying to be more precise than the concept warranted.

Then Steven D'Aprano chimed in, adding even more precision:

  Steven D'Aprano (further down response stack):
  "it is sheer nonsense to talk about "the" speed of an implementation"

So no, it's not a language that is slow, it's of course only concrete 
implementations that may have slowness flavoring. And no, not really, they 
don't, because it's just particular aspects of any given implementation that may 
exhibit slowness in certain contexts. And expanding on that trend, later in the 
thread the observation was made that no, not really that either, it's just (if 
it is at all) at this particular point in time, what about the future? Let's be 
precise! Can't have that vague touchy-feely impression about a /language/ being 
slow corrupting the souls of readers.


Hip hurray, Google's observation annuled, by the injections of /precision/. :-)


Which IMO is fair -- a physicist friend of mine works with a 
C++ interpreter which is relatively sluggish, but that doesn't mean C++ 
is slow...


Actually, although C++ has the potential for being really really fast (and some 
C++ programs are), the amount of work you have to add to realize the potential 
can be staggering. This is most clearly evidenced by C++'s standard iostreams, 
which have the potential of being much much faster than C FILE i/o (in 
particular Dietmar Kuhl made such an implementation), but where the complexity 
of and the guidance offered by the "design" is such that nearly all extant 
implementations are painfully slow, even compared to C FILE. So, we generally 
talk about iostreams being slow, knowing full well what we mean and that fast 
implementations are theoretically possible (as evidenced by Dietmar's)  --  but 
"fast" and "slow" are in-practice terms, and so what matters is in-practice, 
like, how does your compiler's iostreams implementation hold up.



Cheers,

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


Re: the unicode saga continues...

2009-11-13 Thread Mark Tolonen


"Ethan Furman"  wrote in message 
news:4afe4141.4020...@stoneleaf.us...
So I've added unicode support to my dbf package, but I also have some 
rather large programs that aren't ready to make the switch over yet.  So 
as a workaround I added a (rather lame) option to convert the 
unicode-ified data that was decoded from the dbf table back into an 
encoded format.


Here's the fun part:  in figuring out what the option should be for use 
with my system, I tried some tests...


Python 2.5.4 (r254:67916, Dec 23 2008, 15:10:54) [MSC v.1310 32 bit 
(Intel)] on win32

Type "help", "copyright", "credits" or "license" for more information.
>>> print u'\xed'
í
>>> print u'\xed'.encode('cp437')
í
>>> print u'\xed'.encode('cp850')
í
>>> print u'\xed'.encode('cp1252')
φ
>>> import locale
>>> locale.getdefaultlocale()
('en_US', 'cp1252')

My confusion lies in my apparant codepage (cp1252), and the discrepancy 
with character u'\xed' which is absolutely an i with an accent; yet when I 
encode with cp1252 and print it, I get an o with a line.


Can anybody clue me in to what's going on here?


Yes, your console window actually uses cp437, cp850 happens to map to the 
same character, and cp1252 does not.  cp1252 is the default Windows encoding 
(what Notepad uses, for example):


Python 2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit (Intel)] 
on

win32
Type "help", "copyright", "credits" or "license" for more information.

import locale
locale.getdefaultlocale()

('en_US', 'cp1252')

import sys
sys.stdout.encoding

'cp437'

print u'\xed'.encode('cp437')

í

print u'\xed'.encode('cp1252')

φ

-Mark 



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


Re: python simply not scaleable enough for google?

2009-11-13 Thread Vincent Manis
On 2009-11-13, at 19:53, Paul Rubin wrote:

> "Robert P. J. Day"  writes:
>> http://groups.google.com/group/unladen-swallow/browse_thread/thread/4edbc406f544643e?pli=1
>>  thoughts?
> 
> I'd bet it's not just about multicore scaling and general efficiency,
> but also the suitability of the language itself for large, complex
> projects.  It's just not possible to be everything for everybody.
> Python is beginner-friendly, has a very fast learning curve for
> experienced programmers in other languages, and is highly productive
> for throwing small and medium sized scripts together, that are
> debugged through iterated testing.  One might say it's optimized for
> those purposes.  I use it all the time because a lot of my programming
> fits the pattern.  The car analogy is the no-frills electric commuter
> car, just hop in and aim it where you want to go; if you crash it,
> brush yourself off and restart.  But there are times (large production
> applications) when you really want the Airbus A380 with the 100's of
> automatic monitoring systems and checkout procedures to follow before
> you take off, even if the skill level needed to use it is much higher
> than the commuter car.

OK. The quoted link deals with Unladen Swallow, which is an attempt to deal 
with the 
very real performance limitations of current Python systems. The remarks above 
deal with
productivity scalability, which is a totally different matter. So...

People can and do write large programs in Python, not just `throwing...medium 
sized 
scripts together'. Unlike, say, Javascript, it has the necessary machinery to 
build very
large programs that are highly maintainable. One can reasonably compare it with 
Java, C#, 
and Smalltalk; the facilities are comparable, and all of those (as well as 
Python) are 
used for building enterprise systems. 

I believe that the A380's control software is largely written in Ada, which is 
a 
perfectly fine programming language that I would prefer not to write code in. 
For 
approximately 10 years, US DOD pretty much required the use of Ada in military 
(and 
aerospace) software (though a a couple of years ago I discovered that there is 
still 
one remaining source of Jovial compilers that still sells to DOD). According to 
a 
presentation by Lt. Colonel J. A. Hamilton, `Programming Language Policy in the 
DOD:
After The Ada Mandate', given in 1999, `We are unlikely to see a return of a 
programming
language mandate' (www.drew-hamilton.com/stc99/stcAda_99.pdf). As I understand 
it, 
the removal of the Ada mandate came from the realization (20 years after many 
computer
scientists *told* DOD this) that software engineering processes contribute more 
to 
reliability than do programming language structures (c.f. Fred Brooks, `No 
Silver 
Bullet').

So: to sum up, there are lots of large systems where Python might be totally 
appropriate, 
especially if complemented with processes that feature careful specification 
and strong 
automated testing. There are some large systems where Python would definitely 
NOT be 
the language of choice, or even usable at all, because different engineering 
processes 
were in place. 

>From a productivity viewpoint, there is no data to say that Python is more, 
>less, or equally
scalable than  in that it produces correctly-tested, 
highly-maintainable programs
at a lower, higher, or equal cost. I would appreciate it if people who wanted 
to comment on
Python's scalability or lack thereof would give another programming language 
that they would 
compare it with. 

-- v



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


Re: 2.6.4 Mac x86_64 ?

2009-11-13 Thread Zvezdan Petkovic
On Nov 13, 2009, at 3:58 PM, chris grebeldinger wrote:

> Hi All,
> I've been having some trouble getting a x86_64/i386 universal
> readline.so to build against libedit, on MacOS 10.5.6 as Apple does.
> Does anyone have any pointers about what changes I need to make to
> setup.py or readline.c to achive this?
> Has someone already done this and would like to share it?

The fix for use of native editline (readline emulation) was done and is already 
implemented on the trunk (2.7).
Please see: http://bugs.python.org/issue6877
You can find the patch in that tracker issue or here:
http://svn.python.org/view?view=rev&revision=74970

It was marked for a backport to a future 2.6.5 release too.

> Are there any plans to provide 64 bit support in future Mac OS 2.6.x
> releases?

AFAIK, it is already supported.
Perhaps you should specify the exact problems you have.
I believe that a more appropriate place for that would be pythonmac-sig mailing 
list, though.

Best regards,

Zvezdan

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


the unicode saga continues...

2009-11-13 Thread Ethan Furman
So I've added unicode support to my dbf package, but I also have some 
rather large programs that aren't ready to make the switch over yet.  So 
as a workaround I added a (rather lame) option to convert the 
unicode-ified data that was decoded from the dbf table back into an 
encoded format.


Here's the fun part:  in figuring out what the option should be for use 
with my system, I tried some tests...


Python 2.5.4 (r254:67916, Dec 23 2008, 15:10:54) [MSC v.1310 32 bit 
(Intel)] on win32

Type "help", "copyright", "credits" or "license" for more information.
>>> print u'\xed'
í
>>> print u'\xed'.encode('cp437')
í
>>> print u'\xed'.encode('cp850')
í
>>> print u'\xed'.encode('cp1252')
φ
>>> import locale
>>> locale.getdefaultlocale()
('en_US', 'cp1252')

My confusion lies in my apparant codepage (cp1252), and the discrepancy 
with character u'\xed' which is absolutely an i with an accent; yet when 
I encode with cp1252 and print it, I get an o with a line.


Can anybody clue me in to what's going on here?

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


Re: Choosing GUI Module for Python

2009-11-13 Thread Aahz
In article ,
Antony   wrote:
>
>   I just wanted to know which module is best for developing designing
>interface in python .

Haven't tried it, but a new release was just announced for this:

http://www.cosc.canterbury.ac.nz/greg.ewing/python_gui/
-- 
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

2009-11-13 Thread Michele Simionato
On Nov 14, 4:38 am, Paul Rubin  wrote:
> 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.  I've heard they use a 1000-node cluster to
> compile their large C++ apps.  Go seems too primitive (so far) to
> really be suitable for such large-scale development, and (for a newly
> designed language) seems to be missing a lot of the latest ideas.

It does not look so primitive to me, compared to commonly used
languages.
I am pretty sure that they are "missing a lot of the latest ideas" on
purpose. If they want to succeed and make Go a popular language in the
Google
infrastructure (ideally replacing C++) their selling point must be a
nearly zero
learning curve. Python succeded with the low learning curve idea. I
wish them
the best. Certainly it is time to replace C with something more
modern, be it Go
or some other language.
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: python simply not scaleable enough for google?

2009-11-13 Thread Paul Rubin
"Robert P. J. Day"  writes:
> http://groups.google.com/group/unladen-swallow/browse_thread/thread/4edbc406f544643e?pli=1
>   thoughts?

I'd bet it's not just about multicore scaling and general efficiency,
but also the suitability of the language itself for large, complex
projects.  It's just not possible to be everything for everybody.
Python is beginner-friendly, has a very fast learning curve for
experienced programmers in other languages, and is highly productive
for throwing small and medium sized scripts together, that are
debugged through iterated testing.  One might say it's optimized for
those purposes.  I use it all the time because a lot of my programming
fits the pattern.  The car analogy is the no-frills electric commuter
car, just hop in and aim it where you want to go; if you crash it,
brush yourself off and restart.  But there are times (large production
applications) when you really want the Airbus A380 with the 100's of
automatic monitoring systems and checkout procedures to follow before
you take off, even if the skill level needed to use it is much higher
than the commuter car.
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Writing an emulator in python - implementation questions (for performance)

2009-11-13 Thread greg

Santiago Romero wrote:


 Can the above be easily done with another already-existing
application? (example: can m4 do this job)?


The problem you're going to have with something like
m4 is indentation. When you inline a function call,
somehow the inserted code has to be shifted to the
same indentation level as the statement containing
the call.

I don't know of any off-the-shelf macro processor
that can handle that sort of thing easily.

You may want to consider writing a custom one in
Python. You could use the ast facilities to parse
the code, operate on the parse tree and then write
it back out as code.

You might be able to get some ideas from 2to3,
which does similar kinds of source-to-source
translations.

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


Re: Python & Go

2009-11-13 Thread Paul Rubin
Duncan Booth  writes:
> > Haskell handles lookups through its type system; dealing with
> > lookup errors (say by chaining the Maybe type) is clean and elegant.
> I said exceptions or any other method of error handling.

I think the use of an option type (like Maybe) is pretty standard
and works fine.  Go's use of multiple-value returns isn't so bad,
but seems old-fashioned.

> go routines are executed using a thread pool,...
> Most types are not thread safe, so you should never access any mutable 
> value from more than one go routine. If you need to access something 
> like a map from multiple parallel routines you need to use channels to 
> protect it.

OK, this sounds sort of like Erlang.

>var ch = make(chan int, 3);
> would create a channel that holds 3 int values. ...
> You can also use a select statement (syntax similar to a switch 
> statement) to read or write channels in parallel. It arbitrarily chooses 
> one of the case statements that can proceed to execute,...

Thanks, that is informative.  The mechanism looks kind of primitive
and it would be nice if there were a higher level wrapper of some
sort.  But again, it seems sort of Erlang-like (though I haven't used
Erlang so I only have a vague sense of its similarity).

> There doesn't seem to be any way to specify a timeout on a read or 
> write. I think you can create a timer channel with regular ticks and 
> select from that to provide an effective timeout, but that sounds like a 
> lot of boilerplate if you have to do very often.

I wonder how Erlang handles this.

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.  I've heard they use a 1000-node cluster to
compile their large C++ apps.  Go seems too primitive (so far) to
really be suitable for such large-scale development, and (for a newly
designed language) seems to be missing a lot of the latest ideas.
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: python simply not scaleable enough for google?

2009-11-13 Thread Paul Rubin
Vincent Manis  writes:
> 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.

Oh, I see.  Damn gateway.

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

Please wrap to 72 columns or less.  It's easier to read that way.  (I
actually don't care if you do it or not.  If you don't, I'll just
stop responding to you, which might even suit your wishes.)
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: python simply not scaleable enough for google?

2009-11-13 Thread Vincent Manis
On 2009-11-13, at 18:02, Robert Brown wrote:

> Common Lisp and Scheme were designed by people who wanted to write complicated
> systems on machines with a tiny fraction of the horsepower of current
> workstations.  They were carefully designed to be compiled efficiently, which
> is not the case with Python.  There really is a difference here.  Python the
> language has features that make fast implementations extremely difficult.

Not true. Common Lisp was designed primarily by throwing together all of the 
features in every Lisp implementation the design committee was interested in. 
Although the committee members were familiar with high-performance compilation, 
the primary impetus was to achieve a standardized language that would be 
acceptable
to the Lisp community. At the time that Common Lisp was started, there was still
some sentiment that Lisp machines were the way to go for performance.  

As for Scheme, it was designed primarily to satisfy an aesthetic of minimalism. 
Even
though Guy Steele's thesis project, Rabbit, was a Scheme compiler, the point 
here was
that relatively simple compilation techniques could produce moderately 
reasonable 
object programs. Chez Scheme was indeed first run on machines that we would 
nowadays
consider tiny, but so too was C++. Oh, wait, so was Python!

I would agree that features such as exec and eval hurt the speed of Python 
programs, 
but the same things do the same thing in CL and in Scheme. There is a mystique 
about
method dispatch, but again, the Smalltalk literature has dealt with this issue 
in the 
past. 

Using Python 3 annotations, one can imagine a Python compiler that does the 
appropriate
thing (shown in the comments) with the following code. 

  import my_module# static linking

  __private_functions__ = ['my_fn']   # my_fn doesn't appear in the module 
dictionary.

  def my_fn(x: python.int32): # Keeps x in a register
def inner(z): # Lambda-lifts the function, no nonlocal 
vars
  return z // 2   #   does not construct a closure
y = x + 17# Via flow analysis, concludes that y can 
be registerized;
return inner(2 * y)   # Uses inline integer arithmetic 
instructions. 

  def blarf(a: python.int32):
return my_fn(a // 2)  # Because my_fn isn't exported, it can be 
inlined. 

A new pragma statement (which I am EXPLICITLY not proposing; I respect and 
support
the moratorium) might be useful in telling the implementation that you don't 
mind
integer overflow. 

Similarly, new library classes might be created to hold arrays of int32s or 
doubles. 

Obviously, no Python system does any of these things today. But there really is 
nothing stopping a Python system from doing any of these things, and the 
technology 
is well-understood in implementations of other languages. 

I am not claiming that this is _better_ than JIT. I like JIT and other runtime 
things
such as method caches better than these because you don't have to know very 
much about 
the implementation in order to take advantage of them. But there may be some 
benefit
in allowing programmers concerned with speed to relax some of Python's dynamism 
without ruining it for the people who need a truly dynamic language. 

If I want to think about scalability seriously, I'm more concerned about 
problems that
Python shares with almost every modern language: if you have lots of processors 
accessing 
a large shared memory, there is a real GC efficiency problem as the number of 
processors 
goes up. On the other hand, if you have a lot of processors with some degree of 
private 
memory sharing a common bus (think the Cell processor), how do we build an 
efficient 
implementation of ANY language for that kind of environment?

Somehow, the issues of Python seem very orthogonal to performance scalability. 

-- v


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


Re: python simply not scaleable enough for google?

2009-11-13 Thread David Robinow
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
I don't use usenet and I have no intention to stick with Usenet practices.
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: tkFileDialog question

2009-11-13 Thread r
Opps, i see you answered your own question ;-)

To save you more hours of Googling take a look at these two sites!

#great reference
http://infohost.nmt.edu/tcc/help/pubs/tkinter/

#more in-depth
http://effbot.org/tkinterbook/

you'll want to keep them both under your pillow.
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: python simply not scaleable enough for google?

2009-11-13 Thread Vincent Manis

On 2009-11-13, at 17:42, Robert Brown wrote, quoting me: 

> ... Python *the language* is specified in a way that
> makes executing Python programs quickly very very difficult.  
That is untrue. I have mentioned before that optional declarations integrate 
well with dynamic languages. Apart from CL and Scheme, which I have mentioned 
several times, you might check out Strongtalk (typed Smalltalk), and Dylan, 
which was designed for high-performance compilation, though to my knowledge
no Dylan compilers ever really achieved it. 

> I'm tempted to
> say it's impossible, but great strides have been made recently with JITs, so
> we'll see.

> If you want to know why Python *the language* is slow, look at the Lisp code
> CLPython generates and at the code implementing the run time.  Simple
> operations end up being very expensive.  Does the object on the left side of a
> comparison implement compare?  No, then does the right side implement it?  No,
> then try something else 
I've never looked at CLPython. Did it use a method cache (see Peter Deutsch's 
paper on Smalltalk performance in the unfortunately out-of-print `Smalltalk-80:
Bits of History, Words of Advice'? That technique is 30 years old now.

I have more to say, but I'll do that in responding to Bob's next post.

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


Re: tkFileDialog question

2009-11-13 Thread r
On Nov 13, 2:47 pm, "Matt Mitchell"  wrote:
> ---
> The information contained in this electronic message and any attached 
> document(s) is intended only for the personal and confidential use of the 
> designated recipients named above. This message may be confidential. If the 
> reader of this message is not the intended recipient, you are hereby notified 
> that you have received this document in error, and that any review, 
> dissemination, distribution, or copying of this message is strictly 
> prohibited. If you have received this communication in error, please notify 
> sender immediately by telephone (603) 262-6300 or by electronic mail 
> immediately. Thank you.
>
>
>
> -Original Message-
> From: python-list-bounces+mmitchell=transparent@python.org
>
> [mailto:python-list-bounces+mmitchell=transparent@python.org] On
> Behalf Of Matt Mitchell
> Sent: Friday, November 13, 2009 9:33 AM
> To: python-l...@python.org
> Subject: tkFileDialog question
>
> Hi,
>
> This is my first attempt to write a script with any kind of gui.   All I
> need the script to do is ask the user for a directory and then do stuff
> with the files in that directory.  I used tkFileDialog.askdirectory().
> It works great but it pops up an empty tk window.  Is there any way to
> prevent the empty tk window from popping up? Here's the code:
>
> import tkFileDialog
>
> answer = tkFileDialog.askdirectory()
>
> if answer is not '':
>         #do stuff
>
> Thanks!
> Matt
> --http://mail.python.org/mailman/listinfo/python-list
>
> Hi,
>
> After a few more hours of googling I answered my own question:
>
> import Tkinter, tkFileDialog
>
> root = Tk()
> root.withdraw()
>
> answer = tkFileDialog.askdirectory()
>
> if answer is not '':
>         #do stuff
>
> Thanks!!

hello Matt,

Here is one way


import Tkinter as tk
from tkFileDialog import askdirectory
import os

root = tk.Tk()
root.withdraw()

folder = askdirectory()
if folder:
root.destroy() #make sure to do this
print os.listdir(folder)

root.mainloop()

good luck!
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: #define (from C) in Python

2009-11-13 Thread Rhodri James
On Fri, 13 Nov 2009 08:43:14 -, Ulrich Eckhardt  
 wrote:



Santiago Romero wrote:

Well, In the above concrete example, that would work, but I was
talking for multiple code lines, like:


#define LD_r_n(reg) (reg) = Z80ReadMem(r_PC++)

#define LD_rr_nn(reg)   r_opl = Z80ReadMem(r_PC); r_PC++; \
r_oph = Z80ReadMem(r_PC); r_PC++; \
reg = r_op

#define LOAD_r(dreg, saddreg)   (dreg)=Z80ReadMem((saddreg))

#define LOAD_rr_nn(dreg)   r_opl = Z80ReadMem(r_PC); r_PC++; \
   r_oph = Z80ReadMem(r_PC); r_PC++; \
   r_tmpl = Z80ReadMem(r_op); \
   r_tmph = Z80ReadMem((r_op)+1); \
   dreg=r_tmp

#define STORE_nn_rr(dreg) \
r_opl = Z80ReadMem(r_PC); r_PC++;\
r_oph = Z80ReadMem(r_PC); r_PC++; \
r_tmp = dreg; \
Z80WriteMem((r_op),r_tmpl, regs); \
Z80WriteMem((r_op+1),r_tmph, regs)


Someone writing such code and calling it C should be taken behind the  
barn

and shot.


Having spent all day working on C code with *much* more complex
#defines than that, I beg to disagree.  Particularly in embedded
applications, there are occasions when you absolutely must have
bits of code inlined rather than as function calls.  In those
cases, declaring a function 'inline' is insufficient, as the
compiler can choose to ignore you.

In Python, however, the point is moot; you don't get to play
those games without using a separate preprocessor.  I've never
particularly felt the urge to try, either.

--
Rhodri James *-* Wildebeest Herder to the Masses
--
http://mail.python.org/mailman/listinfo/python-list


Re: python simply not scaleable enough for google?

2009-11-13 Thread Vincent Manis

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

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

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. 

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. 

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

-- v

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


Re: python simply not scaleable enough for google?

2009-11-13 Thread Vincent Manis
On 2009-11-13, at 12:46, Brian J Mingus wrote:
> You're joking, right? Try purchasing a computer manufactured in this 
> millennium. Monitors are much wider than 72 characters nowadays, old timer.
I have already agreed to make my postings VT100-friendly. Oh, wait, the VT-100, 
or at least some models of it, had a mode where you could have a line width of 
132 characters. 

And what does this have to do with Python? About as much as an exploding 
penguin 
on your television. 

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


Re: python simply not scaleable enough for google?

2009-11-13 Thread Robert Brown

J Kenneth King  writes:

> mcherm  writes:
>> I think you have a fundamental misunderstanding of the reasons why Python
>> is slow. Most of the slowness does NOT come from poor implementations: the
>> CPython implementation is extremely well-optimized; the Jython and Iron
>> Python implementations use best-in-the-world JIT runtimes. Most of the
>> speed issues come from fundamental features of the LANGUAGE itself, mostly
>> ways in which it is highly dynamic.
>>
>> -- Michael Chermside

> You might be right for the wrong reasons in a way.  Python isn't slow
> because it's a dynamic language.  All the lookups you're citing are highly
> optimized hash lookups.  It executes really fast.

Sorry, but Michael is right for the right reason.  Python the *language* is
slow because it's "too dynamic".  All those hash table lookups are unnecessary
in some other dynamic languages and they slow down Python.  A fast
implementation is going to have to be very clever about memoizing method
lookups and invalidating assumptions when methods are dynamically redefined.

> As an implementation though, the sky really is the limit and Python is
> only getting started.

Yes, but Python is starting in the basement.

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


Re: query regarding file handling.

2009-11-13 Thread Rhodri James
On Thu, 12 Nov 2009 09:59:40 -, ankita dutta  
 wrote:



hi all,

i have a file of 3x3 matrix of decimal numbers(tab separated). like this  
:


0.020.380.01
0.040.320.00
0.030.400.02

now i want to read 1 row and get the sum of a particular row. but when i  
am

trying with the following code, i am getting errors :

*code*:
"
ln1=open("A.txt","r+")# file "A.txt" contains my matrix
lines1=ln1.readlines()


You can iterate through the file line by line, so there's no need to read  
the whole thing in one go like this.



n_1=[ ]

for p1 in range (0,len(lines1)):
f1=lines1[p1]


If you ever write range(len(some_list)) in a 'for' statement, you're  
almost certainly making life harder for yourself than you need to.  Since  
all you use 'pl' for is pulling out the 'current' line, you might as well  
just iterate through the list, i.e. replace those two lines with this:


for fl in lines1:

Better, as I mentioned earlier you can skip the whole business of slurping  
the file in using 'readlines' and read it one line at a time:


for fl in ln1:


n_1.append((f1) )
print n_1
print  sum(n_1[0])


[snip]


* what I think:*

as the list is in form of   '0.0200\t0.3877\t0.0011\n',  n_1[0]   
takes

it as a whole string   which includes "\t" , i think thats why they are
giving error.


You think right.


now how can i read only required numbers from this line
'0.0200\t0.3877\t0.0011\n'  and find their sum ?
can you kindly help me out how to properly code thing .


Read the line (as before), then split it on whitespace (the tabs in this  
case), and then sum the resulting list.  Or as Chris said, get the 'csv'  
module to do the hard work for you.


--
Rhodri James *-* Wildebeest Herder to the Masses
--
http://mail.python.org/mailman/listinfo/python-list


Re: python simply not scaleable enough for google?

2009-11-13 Thread Robert Brown

Vincent Manis  writes:
> My point in the earlier post about translating Python into Common Lisp or
> Scheme was essentially saying `look, there's more than 30 years experience
> building high-performance implementations of Lisp languages, and Python
> isn't really that different from Lisp, so we ought to be able to do it too'.

Common Lisp and Scheme were designed by people who wanted to write complicated
systems on machines with a tiny fraction of the horsepower of current
workstations.  They were carefully designed to be compiled efficiently, which
is not the case with Python.  There really is a difference here.  Python the
language has features that make fast implementations extremely difficult.

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


Re: python simply not scaleable enough for google?

2009-11-13 Thread Robert Brown
Vincent Manis  writes:

> On 2009-11-11, at 14:31, Alain Ketterlin 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.

This is generally true, but Python *the language* is specified in a way that
makes executing Python programs quickly very very difficult.  I'm tempted to
say it's impossible, but great strides have been made recently with JITs, so
we'll see.

> 2. A skilled programmer could build an implementation that compiled Python
> code into Common Lisp or Scheme code, and then used a high-performance
> Common Lisp compiler such as SBCL, or a high-performance Scheme compiler
> such as Chez Scheme, to produce quite fast code ...

A skilled programmer has done this for Common Lisp.  The CLPython
implementation converts Python souce code to Common Lisp code at read time,
which is then is compiled.  With SBCL you get native machine code for every
Python expression.

  http://github.com/franzinc/cl-python/
  http://common-lisp.net/project/clpython/

If you want to know why Python *the language* is slow, look at the Lisp code
CLPython generates and at the code implementing the run time.  Simple
operations end up being very expensive.  Does the object on the left side of a
comparison implement compare?  No, then does the right side implement it?  No,
then try something else 

I'm sure someone can come up with a faster Python implementation, but it will
have to be very clever.

> This whole approach would be a bad idea, because the compile times would be
> dreadful, but I use this example as an existence proof that Python
> implementations can generate reasonably efficient executable programs.

The compile times are fine, not dreadful.  Give it a try.

> 3. It is certainly true that CPython doesn't scale up to environments where
> there are a significant number of processors with shared memory.

Even on one processor, CPython has problems.

I last seriously used CPython to analyze OCRed books.  The code read in the
OCR results for one book at a time, which included the position of every word
on every page.  My books were long, 2000 pages, and dense and I was constantly
fighting address space limitations and CPython slowness related to memory
usage.  I had to resort to packing and unpacking data into Python integers in
order to fit all the OCR data into RAM.

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


Re: Compiler malware rebutted

2009-11-13 Thread Aahz
In article ,
David M. Besonen  wrote:
>On 11/13/2009 3:26 PM, Aahz wrote:
>>
>> Ken Thompson's classic paper on bootstrapped malware
>> finally gets a rebuttal:
>> 
>> http://lwn.net/Articles/360040/
>
>thanks for pointing this out.

Actually, I found out about it on panix.chat  ;-)
-- 
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: ANN: esky 0.2.1

2009-11-13 Thread Aahz
In article ,
Ryan Kelly   wrote:
>
>Out of curiosity, what freezer package did you settle on in the end?
>I'm curious it see if esky could easily switch between different
>freezers (although it currently depends on some rather deep details of
>the bbfreeze format).

We're currently using py2app and py2exe and are planning to use cx_freeze
for Linux.
-- 
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: questions regarding stack size use for multi-threaded python programs

2009-11-13 Thread Andrew MacIntyre

Gabriel Genellina wrote:

En Mon, 09 Nov 2009 16:05:31 -0300, Eyal Gordon 
escribió:


background:
we are using python 2.4.3 on CentOS 5.3 with many threads - and our 
shell's

default stack size limit is set to 10240KB (i.e. ~10MB).

we noticed that python's Threading module appears to create threads with
this value as their stack size (we ran a sample program that creates 10
threads and measured its virtual memory size, then reduced the stack size
limit of the shell to 5120KB - and saw that the program's virtual memory
size was reduced by ~50MBs).

the problem:
our program uses numerous threads, and thus the virtual memory size 
gets to
be very large. we would like to reduce the size of the stack to reduce 
this

size. we were looking for information about recommendation for the stack
size to use, but found none.


You can set the thread stack size (for threads that are going to be
created, not existing threads) using threading.stack_size(SIZE)
http://docs.python.org/library/threading.html#threading.stack_size


Sadly for the OP, that capability was introduced in Python 2.5.  Prior
to that, the only way to adjust thread stack size is via a compile time
option (THREAD_STACK_SIZE).  In the absence of that compile time option,
the platform default is used - on pthread systems (incl Linux) refer to
the manpage for pthread_attr_setstacksize() for more info, but I believe
what the OP reports could reasonably be expected for his platform.

The threading.stack_size() support would not be hard to backport to
Python 2.4.


questions:
1. is there some rule-of-thumb for the recommended stack size for python
programs of various sorts?


There is no rule of thumb because there are too many variables amongst
the supported platforms.  Extensive testing would be required to
validate any selected size.

I would suggest starting with 1MB and working down.  On a 32bit platform
I would suggest that 64kb might be adequate for child threads but most
likely not for the primary thread (the thread that the Python
interpreter starts in).  If your app uses regexes, your stack space
requirements are likely to be larger.

FWIW the default thread stack size on Win32 is 1MB which anecdotally
seems sufficient for a wide variety of applications on that platform.

{...}

4. would the size of the stacks (which are probably not really 
allocated by

the linux virtual memory sub-system, unless used) have a noticeable
performance effect on a python program? same question regarding the 
use of a

large number of threads?


I think it doesn't matter, unless you create so many threads as to exhaust
the available addressing space (in 32bits, 4GB address space and 10MB per
thread means 400 threads maximum).


The performance of course will degrade once the committed memory in the
active working set exceeds the available real memory, as the OS will
start swapping.  How the OS treats unused stack space will affect that
threshold.

--
-
Andrew I MacIntyre "These thoughts are mine alone..."
E-mail: andy...@bullseye.apana.org.au  (pref) | Snail: PO Box 370
   andy...@pcug.org.au (alt) |Belconnen ACT 2616
Web:http://www.andymac.org/   |Australia

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


Re: New syntax for blocks

2009-11-13 Thread r
On Nov 13, 3:20 pm, Bruno Desthuilliers
 wrote:
(...snip...)
> > I think because (like me) Carl
> > put's the language before sewing circles. I think it's just personal
> > like all the times before,
>
> Well, to be true, you did manage to make a clown of yourself more than
> once, so don't be surprised if some people here tend to treat you as one
> - even when you come up with something that _may_ have some value.

Well, i must agree with that assessment. There have been some
*interesting* post from me here. I am human and prone to make mistakes
like anyone 0:-)

> My (hopefully friendly) 2 cents.

Thanks, the tone of this message was very good!

But anyway this is all moot now. I received a message last night from
a very intelligent person who i will not name since the message was
only addressed to me (no it's not Guido! I don't want to start any
crazy rumors people!) This "persons" response was *so* intelligent and
informative i was awe struck whilst reading it and concluded i have no
further basis to argue for this syntax change (not at this time
anyway). I would like to post this person's message for all to see but
i will not without their permission. I can now see how the pros *may*
not outweigh the cons and so with that i concede to my opponents.

Anyway, good discussion chaps!
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Compiler malware rebutted

2009-11-13 Thread David M. Besonen
On 11/13/2009 3:26 PM, Aahz wrote:

> Ken Thompson's classic paper on bootstrapped malware
> finally gets a rebuttal:
> 
> http://lwn.net/Articles/360040/

thanks for pointing this out.



  -- david

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


Re: A "terminators' club" for clp

2009-11-13 Thread r
On Nov 13, 5:29 pm, kj  wrote:
> This is "meta-question" about comp.lang.python.  I apologize in
> advance if it has been already discussed.  Also, I don't know enough
> about the underlying mechanics of comp.lang.python, so this may be
> *totally unfeasible*, but how about giving a few bona fide *and
> frequent* clp posters the ability to *easily* delete spam from the
> comp.lang.python server?


How long you been hanging around here?

There are problems inherent in all moderated groups. When you give
anyone the power to delete post they can use it for good and for evil.
c.l.py like all groups has good and bad followers, spam, and trollers
like anywhere else. What you consider spam and trolling i may consider
freedom of speech although like anyone here i vehemently hate spammers
and would like to put them out of business permanently! Trolls don't
bother me so much because i just skip past their posts -- And there
are many levels of trolling.

However if you are selling something (that is *not* directly python
related) then i think we could *safely* say that you are spamming this
group. Nobody has come here to buy a knockoff Rolex's or Nike tennis
shoes at ten bucks each. If you are posting porn links then we could
*safely* say that porn is in no way applicable to this group and
delete them on that merit. I'm OK with that, but would it stop there?

If you look back through history you will find many instances of the
powerful robbing the innocent peoples of freedoms in the name of good,
or even the name of God, despicable hypocrite's!. Heck people where
murdered by nation states just because of fear and ignorance ("Salem
witch trials" ring a bell, the holocaust ring a bell?, and many many
more sad cases).

So if i had a choice between trollers, spammers, and power hungry
murderers, i'll buy the rolex and listen to x-and-lee's all day long
thank you very much!

Power is corrupting, and absolute power is absolutely corrupting!
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: A "terminators' club" for clp

2009-11-13 Thread Paul Rubin
kj  writes:
> frequent* clp posters the ability to *easily* delete spam from the
> comp.lang.python server?

Um, this is usenet; there is no comp.lang.python server.  Are you
saying you want a moderated newsgroup?  Hmm, maybe this group is busy
enough that there is some merit to that idea.  
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: python simply not scaleable enough for google?

2009-11-13 Thread Paul Rubin
Tim Chase  writes:
> Or even just pipe to
> your text editor of choice:  vi, emacs, ed, cat, and even Notepad
> has a "wrap long lines" sort of setting or does the right thing
> by default (okay, so cat relies on your console to do the
> wrapping, but it does wrap).

No, auto wrapping long lines looks like crap.  It's better to keep the
line length reasonable when you write the posts.  This is Usenet so
please stick with Usenet practices.  If you want a web forum there are
plenty of them out there.
-- 
http://mail.python.org/mailman/listinfo/python-list


A "terminators' club" for clp

2009-11-13 Thread kj


This is "meta-question" about comp.lang.python.  I apologize in
advance if it has been already discussed.  Also, I don't know enough
about the underlying mechanics of comp.lang.python, so this may be
*totally unfeasible*, but how about giving a few bona fide *and
frequent* clp posters the ability to *easily* delete spam from the
comp.lang.python server?

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!)

One possible *initial* criterion for selecting these "terminators"
would be the number of posts to clp between, say, January 2009 and
July 2009.  The members of this seed set could then select new
members for the terminators' club.

Just a thought.

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


Compiler malware rebutted

2009-11-13 Thread Aahz
Ken Thompson's classic paper on bootstrapped malware finally gets a
rebuttal:

http://lwn.net/Articles/360040/
-- 
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: ANN: esky 0.2.1

2009-11-13 Thread Ryan Kelly

> >> Recently I was looking into distribution mechanisms, and I passed over
> >> bbfreeze because I saw no indication that Python 2.6 was supported.
> >
> >Not sure if it's officially supported, but I do most of my development
> >on Python 2.6 and bbfreeze hasn't given me any problems as yet.
> 
> Also, bbfreeze doesn't seem to have active development.

It's slow but certainly active.  Development was recently moved to
github with almost no fanfare (in fact I only discovered the github site
by accident):

   http://github.com/schmir/bbfreeze


Out of curiosity, what freezer package did you settle on in the end?
I'm curious it see if esky could easily switch between different
freezers (although it currently depends on some rather deep details of
the bbfreeze format).


  Cheers,

Ryan


-- 
Ryan Kelly
http://www.rfk.id.au  |  This message is digitally signed. Please visit
r...@rfk.id.au|  http://www.rfk.id.au/ramblings/gpg/ for details



signature.asc
Description: This is a digitally signed message part
-- 
http://mail.python.org/mailman/listinfo/python-list


__import__ returns module without it's attributes?

2009-11-13 Thread Zac Burns
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
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: #define (from C) in Python

2009-11-13 Thread Santiago Romero
> Hey, I got 100% with ASM ZX Spectrum emulator on a low end 386 :-) (I do
> not remember the CPU freqeuncy anymore, maybe 25MHz).

 Yes, in ASM a simple 25 or 33Mhz 386 computer was able to emulate
the
Spectrum. At least, under MSDOS, like did Warajevo, Z80, x128 and
"Spectrum"
from Pedro Gimeno.

> First emulator in C that appeared on the emu-scene (I guess it
> was x128) needed 486 (~80MHz?) to run at realtime. Pentium and
> Pentium II was A LOT of  power :-)

 x128 was not pure C. The first emulator written in pure C was
Aspectrum,
although Philip Kendall "finished" FUSE (Free UNIX Spectrum Emulator)
before my emulator was able to emulate 128K models.

 But currently only FUSE and ASpectrum can be compiled in lost of
platforms
(Wii, Dreamcast, PocketPC, NDS...) just by translating the O.S.
dependent
functions or if the destination platform supports the Allegro
library...

 And at least a P1-P2 is needed for that :-)

> http://perl-spectrum.sourceforge.net/
>
> It is quite fast IMHO.

 It does not run 100% in my 1.8Ghz centrino computer :-(, but almost.
At least, is a good start to see that is possible, at least no current
DualCore computers :-)

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


Re: QuerySets in Dictionaries

2009-11-13 Thread Jerry Hill
On Fri, Nov 13, 2009 at 5:10 PM, 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)
>
> And no, this is not based on user-generated input.
>

I don't get it.  If you're already storing the name to query mapping in a
dictionary, why do you also need to use exec to do the same thing in the
local namespace?  If you're generating these names dynamically (which you
obviously are, based on this snippet), it's going to be faster and more
legible if you just look them up in the dictionary, instead of having to use
exec and eval all over the place.

Then all you'd need is something like:

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

then later you just look them up as d['thing_1'] (or d[thing_name] if you're
dynamically generating the names again).

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


Re: bootstrapping on machines without Python

2009-11-13 Thread mmanns
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.

[...]

> In the long run, to be useful for real projects, the bootstrapper
> would need to manage some nasty details:
> * different versions of the interpreter for different applications
> * download required packages
> * manage conflicting versions of packages

An easy approach could be to use the portable apps version of Python.
(I assume that you use Windows.)

After installing portable Python on your computer, your application
and any additional libraries are put into the site-packages / Scripts
folders. Next, the install folder is zipped and provided for download. 

A batch script, which is downloaded and run by the user, downloads the
zip file and extracts it. The script executes python.exe with your
Python script as command line argument.

In this scenario, the user would not need Administrator privileges. 
You could also get around compatibility problems by providing
preferred versions of additional libraries in the site-packages folder
of portable Python.

However, the download size would probably exceed 100 MB. I also do not
know if there are licensing issues using portable Python like this.

Martin

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


Re: New syntax for blocks

2009-11-13 Thread Bruno Desthuilliers
r a écrit :
> On Nov 12, 2:37 pm, Bruno Desthuilliers
>  wrote:
> 
>>> Oh i get it now! If i assign a valid value to a variable the variable
>>> is also valid...thats...thats... GENUIS! *sarcasm*
>> It's not about "assigning a valid value to a variable", it's about the
>> name being created (or not) in the current namespace, whatever it's
>> bound to.
> 
> And thats what my sarcasm was alluding to. Steven's argument is moot
> because it will blow up either way due to the fact that "value" is non-
> existent! 

Sorry, but Steve's code, ie:

var = range(100)
if var:
  ...

will not break - after the first line, the name "var" exists, whether
it's bound to true or false value.

While with your proposal *as it is* (or at least as I and Steve
understood it), the existence of name "var" depends on some
unpredictable condition.

> Every argument that has been brought forth about how this
> will break is just False

Actually, identity testing on True or False is considered a very bad
practice. You really want equality testing 

> and basically a bunch of FUD! It just garbage
> so you can discredit the idea.

Please take a deep breath and calm down. There's no conspiracy, no
secret plan, no hidden agenda, and pointing out the shortcomings of a
proposals is definitly not "discredit"ing "the idea".

> It's actually quite funny when someone as small as me can bring down
> the iron curtain of c.l.py.
>   '''Mr. Gorbachev, Tear down this wall!'''
> 
> How about one of you "esteemed" Pythonista's show me a real example
> where it will break.

Steve did. But I'm afraid you missed his point.

> 
> PS: And if it were so dangerous why would someone as knowledgeable as
> Carl have stepped in and supported it.

Carl supported the idea of a syntax for "assignment and test", but
that's not what Steve's comments were about - well, it may be that Steve
also refuses to consider the whole idea, but he still has a good point
wrt/ some shortcoming of your idea in it's current state.

> I think because (like me) Carl
> put's the language before sewing circles. I think it's just personal
> like all the times before,

Well, to be true, you did manage to make a clown of yourself more than
once, so don't be surprised if some people here tend to treat you as one
- even when you come up with something that _may_ have some value.

> that's OK, i have very thick skin! If it's
> wrong for a good reason i will graciously accept that, but no one has
> proven it's non-worth, not yet!

wrong != non-worth. I mean: having some possibly valid use case doesn't
imply the proposed solution is the good one in it's current state. And
pointing out the shortcomings of the proposed solution doesn't imply the
problem is not real neither (now whether it's a critical enough problem
to _require_ a solution is another problem I won't even debate here).

Anyway, just going to personal considerations won't help. If you ever
hope to be taken seriously, first behave as a reasonably sensible and
mature person.

My (hopefully friendly) 2 cents.
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: QuerySets in Dictionaries

2009-11-13 Thread scoopseven
On Nov 12, 8:55 pm, Steven D'Aprano  wrote:
> On Thu, 12 Nov 2009 10:39:33 -0800, scoopseven wrote:
> > I need to create a dictionary of querysets.  I have code that looks
> > like:
>
> > query1 = Myobject.objects.filter(status=1)
> > query2 = Myobject.objects.filter(status=2)
> > query3 = Myobject.objects.filter(status=3)
>
> > d={}
> > d['a'] = query1
> > d['b'] = query2
> > d['c'] = query3
>
> > Is there a way to do this that I'm missing?
>
> I don't understand your problem. Assuming Myobject is defined, and has
> the appropriate attribute objects.filter, the above should work exactly
> as you give it.
>
> What is your actual problem? Are you asking for help in defining a
> queryset?
>
> --
> Steven

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)

And no, this is not based on user-generated input.

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


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

2009-11-13 Thread Jon Clements
On 13 Nov, 21:26, kj  wrote:
> ...just bit me in the "fuzzy posterior".  The best I can come up with
> is the hideous
>
>   lol = [[] for _ in xrange(500)]
>
> Is there something better?  

That's generally the accepted way of creating a LOL.

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

>>> lol = map(lambda L: [], xrange(5))
>>> [id(i) for i in lol]
[167614956, 167605004, 167738060, 167737996, 167613036]

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


Re: converting latitude and longitude

2009-11-13 Thread ezd
On Nov 13, 2:25 pm, MRAB  wrote:
> Ronn Ross wrote:
>
> > I'm attempting to convert latitude and longitude coordinates from ...
> > Does anyone know of a library or some existing out their to help with
> > this conversion?
>
Some time ago I saw file named LLUTM... for such conversions with more
than 20 ellipsoids.
Language of the file - C or Python, not sure. Try Google for LLUTM to
find more.
Regards, Eugene
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: New syntax for blocks

2009-11-13 Thread Bruno Desthuilliers
r a écrit :
> On Nov 12, 7:44 pm, Steven D'Aprano  cybersource.com.au> wrote
>> Oh, but those hundreds of thousands of man-hours lost to bugs caused by
>> assignment-as-an-expression is nothing compared to the dozens of man-
>> minutes saved by having one fewer line of code!
> 
> OK, what *if* the variable would only be valid in *that* block and
> *that* block only! 

Python doesn't have the notion of a "block scope" (or "block namespace").

> My first idea was to have the variable avaiable in
> the local scope (if that is correct terminology?) so if the
> conditional was in global space the value would be available in global
> space, alright? You follow me? Now forget all that and observe the
> following. ;-)
> 
> if value=range(10):
> #this block *would* execute and "value" would be a valid name
> #but only IN this block!!!
> value.append(1)
> elif value=fetch(0):
> #this block would *never* execute
> value.append(1)
> 
> value.append(1) -> this throws a NameError

Yuck.

> 
> Is that different than how other languages handle "assignment-by-
> expression"? Will that avoid the cataclysmic downward spiral you speak
> of? 

It's different, but only worse. It doesn't solve the problem of
mystyping "=" instead of "==" - which is the reason why Python's
assignement is not an expression, and it's not even consistent with
mainstream languages that support "assignement as an expression".

> I can't see any problems with it

I do see at least two big ones !-)

Now I don't mean there's not a use case for some "assign and test"
syntax - Carl provided a good one, and indeed there are some cases where
a dispatcher is *not* the simplest and obvious solution. But by all
means, not *this* syntax.
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: python simply not scaleable enough for google?

2009-11-13 Thread Terry Reedy

Aaron Watters wrote:

On Nov 11, 3:15 pm, Terry Reedy  wrote:

Robert P. J. Day wrote:
I can imagine a day when code compiled from Python is routinely
time-competitive with hand-written C.


That time is now, in many cases.


By routinely, I meant ***ROUTINELY***, as in
"C become the province of specialized tool coders, much like assembly is 
now, while most programmers use Python (or similar languages) because 
they cannot (easily) beat it with hand-coded C."  We are not yet at 
*tha* place yet.



I still stand by my strategy published in Unix World
ages ago: get it working in Python, profile it, optimize
it, if you need to do it faster code the inner loops in
C.


Agreed

By the way: the GO language smells like Rob Pike,
and I certainly hope it is more successful than
Limbo was.  Of course, if Google decides to really
push it then it's gonna be successful regardless
of all other considerations, just like Sun
did to Java...

> By the way: the GO language smells like Rob Pike,
> and I certainly hope it is more successful than

It still has the stupid, unnecessary, redundant C brackets, given that 
all their example code is nicely indented like Python. That alone is a 
deal killer for me.


Terry Jan Reedy

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


Re: wsgi with separate css file

2009-11-13 Thread Aaron Watters

RE: serving static CSS files using WSGI

> ...However, this method is fragile and very inefficient. If you want to  
> eventually deploy this application somewhere, I would suggest starting  
> with a different method.

The WHIFF WSGI tools are meant to make this kind of thing easy.
In fact the quick start tells you how to do this

http://aaron.oirt.rutgers.edu/myapp/docs/W0500.quickstart

And if you want to deploy to the Google App Engine there's a
tutorial for that too:

http://aaron.oirt.rutgers.edu/myapp/docs/W1100_2300.GAEDeploy

For example the http://listtree.appspot.com/ service is implemented
using WHIFF under the Google App Engine environment.

   -- Aaron Watters

===
TO INFINITY... AND BEYOND!

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


Re: A beginner question about GUI use and development

2009-11-13 Thread CM
On Nov 13, 3:55 am, uap12  wrote:
> Hi!
> I have written som Python programs but no one with a GUI yet,
> i have look around and found a lot of diffrent gui module.
>
> I will develop program that will use a small amout of GUI part
> eg. program to show status about server etc.
>
> I have looked att wxWidget, but i like a rekommendation here
> (Will develop Windows program but somtimes OSX to)

In the context of Python, it is called wxPython.  WxWidgets is
the C++ version (and around which wxPython is a thin wrapper).

> When i givet the program away i like to pack it, so the enduser
> just run it, i don't like to tell the user to install Python, and/or
> som GUI package. is this possible.

As others mentioned, yes.  Many people use py2exe for Windows, and
py2app for Mac OS X.  These have nothing to do with the choice of
GUI,
though.  However, if you choose wxPython as the widget toolkit, you
can use a really nice application called GUI2Exe, which is a GUI
interface for py2exe, py2app, and a few other such tools, and makes
creating a packaged-up executable much easier.

> In the beginning it is okej to code the gui "by hand" to learn
> but after that i like som kind of GUI-designtool, and god
> to recommade ??

Sure--that's one good way.  I learned the other way around:  by
using a GUI designer to teach me what options there were for widgets
and how they were coded.  One nice IDE and GUI builder for wxPython
is Boa Constructor.

> I know this is basic question, but i have't found any god answer
> so if some takes time to answer i would be happy.

Googling these issues or searching this group should turn up
dozens of answers and opinions; it has been asked many times.

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


2.6.4 Mac x86_64 ?

2009-11-13 Thread chris grebeldinger
Hi All,
I've been having some trouble getting a x86_64/i386 universal
readline.so to build against libedit, on MacOS 10.5.6 as Apple does.
Does anyone have any pointers about what changes I need to make to
setup.py or readline.c to achive this?
Has someone already done this and would like to share it?
Are there any plans to provide 64 bit support in future Mac OS 2.6.x
releases?

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


Re: bootstrapping on machines without Python

2009-11-13 Thread Thomas Heller
M.-A. Lemburg schrieb:
> 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.
>> 
>> An application source code could be distributed with this small exe to
>> wrap its top level 'main.py', and the application could then be run on
>> machines which do not (yet) have Python installed.
>> 
>> The goal of this is to provide a way for end-users to download and
>> double-click a Python application, without having to know what Python
>> is or whether (an appropriate version of) it is installed. This method
>> has some disadvantages compared to using py2exe et al, but it has the
>> advantage that a small application would remain small: there is no
>> need to bundle a whole interpreter with every application.
> 
> There are two major issues with such an approach:
> 
>  * users will not necessarily like it if a small application
>downloads a several MB from the web somewhere without asking
> 
>  * installing applications on Windows typically requires admin
>rights or at least user interaction
> 
> I think a good solution to the problem is wrapping the application's
> main.py in a batch file which pops up a window to let the user know
> that s/he will need to install Python first and point him/her to the
> www.python.org web site, if necessary.

Here is a batch file that simulates a similar approach,
for demonstration purposes it doesn't download and install python,
instead it simply copies 'c:\python25\python.exe' to the current directory
under a different name (if it is not yet present), and executes the script with 
it.
Batchfile experts should also be able to improve other things:


@echo off && if exist py_exe.exe (py_exe.exe -x %0 %* && goto exit) else (goto 
download)
# The python script
import sys
print "Hi, this is Python", sys.version
sys.exit()

# rest of the batch file
"""
:download
echo Simulating download...
copy c:\python25\python.exe py_exe.exe
echo Done.
REM start the script again after downloading
%0 %*

:exit
rem """


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


RE: tkFileDialog question

2009-11-13 Thread Matt Mitchell


 
---
The information contained in this electronic message and any attached 
document(s) is intended only for the personal and confidential use of the 
designated recipients named above. This message may be confidential. If the 
reader of this message is not the intended recipient, you are hereby notified 
that you have received this document in error, and that any review, 
dissemination, distribution, or copying of this message is strictly prohibited. 
If you have received this communication in error, please notify sender 
immediately by telephone (603) 262-6300 or by electronic mail immediately. 
Thank you.
 
-Original Message-
From: python-list-bounces+mmitchell=transparent@python.org
[mailto:python-list-bounces+mmitchell=transparent@python.org] On
Behalf Of Matt Mitchell
Sent: Friday, November 13, 2009 9:33 AM
To: python-list@python.org
Subject: tkFileDialog question

Hi,

This is my first attempt to write a script with any kind of gui.   All I
need the script to do is ask the user for a directory and then do stuff
with the files in that directory.  I used tkFileDialog.askdirectory().
It works great but it pops up an empty tk window.  Is there any way to
prevent the empty tk window from popping up? Here's the code:


import tkFileDialog

answer = tkFileDialog.askdirectory()

if answer is not '':
#do stuff

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


Hi, 

After a few more hours of googling I answered my own question:

import Tkinter, tkFileDialog

root = Tk()
root.withdraw()

answer = tkFileDialog.askdirectory()

if answer is not '':
#do stuff


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


Re: python simply not scaleable enough for google?

2009-11-13 Thread Brian J Mingus
On Fri, Nov 13, 2009 at 12:19 AM, Steven D'Aprano <
st...@remove-this-cybersource.com.au> wrote:

> On Thu, 12 Nov 2009 22:20:11 -0800, Vincent Manis wrote:
>
> > When I was approximately 5, everybody knew that higher level languages
> were too slow for high-speed numeric computation (I actually didn't know
> that then, I was too busy watching Bill and Ben the Flowerpot Men), and
> therefore assembly languages were mandatory. Then IBM developed Fortran, and
> higher-level languages were not too slow for numeric computation.
>
> Vincent, could you please fix your mail client, or news client, so
> that it follows the standard for mail and news (that is, it has a
> hard-break after 68 or 72 characters?
>
> Having to scroll horizontally to read your posts is a real pain.
>
>
You're joking, right? Try purchasing a computer manufactured in this
millennium. Monitors are much wider than 72 characters nowadays, old timer.
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Psyco on 64-bit machines

2009-11-13 Thread 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.

Has anyone tried this?
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: python simply not scaleable enough for google?

2009-11-13 Thread Aaron Watters
On Nov 11, 3:15 pm, Terry Reedy  wrote:
> Robert P. J. Day wrote:
> I can imagine a day when code compiled from Python is routinely
> time-competitive with hand-written C.

That time is now, in many cases.

I still stand by my strategy published in Unix World
ages ago: get it working in Python, profile it, optimize
it, if you need to do it faster code the inner loops in
C.

Of course on google app engine, the last step is not possible,
but I don't think it is needed for 90% of applications
or more.

My own favorite app on google app engine/appspot is

http://listtree.appspot.com/

implemented using whiff
   http://whiff.sourceforge.net
as described in this tutorial
   http://aaron.oirt.rutgers.edu/myapp/docs/W1100_2300.GAEDeploy

not as fast as I would like sporadically.  But that's
certainly not Python's problem because the same application
running on my laptop is *much* faster.

By the way: the GO language smells like Rob Pike,
and I certainly hope it is more successful than
Limbo was.  Of course, if Google decides to really
push it then it's gonna be successful regardless
of all other considerations, just like Sun
did to Java...

   -- Aaron Watters

===
Limbo: how low can you go?


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


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

2009-11-13 Thread Tobiah

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


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


Re: Vote on PyPI comments

2009-11-13 Thread Diez B. Roggisch

Michele Simionato schrieb:

On Nov 13, 4:39 pm, Chris Withers  wrote:

PyPI grew a commenting and rating system a while back, apparently in
response to requests from users. However, since it's been rolled out,
there's been a backlash from package maintainers who already have
mailing lists, bug trackers, etc for their packages and don't want to
have to try and keep track of yet another support forum.



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.


The ratio user to posters certainly speaks against that - for any given 
package, there are so many users that never appear here - but they stil 
might share insights about the package.


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


Re: Dynamic property names on class

2009-11-13 Thread Diez B. Roggisch

Bryan schrieb:

On Nov 13, 9:34 am, "Diez B. Roggisch"  wrote:

Bryan schrieb:




I have several properties on a class that have very similar behavior.
If one of the properties is set, all the other properties need to be
set to None.  So I wanted to create these properties in a loop like:
class Test(object):
   for prop in ['foo', 'bar', 'spam']:
   # Attribute that data is actually stored in
   field = '_' + prop
   # Create getter/setter
   def _get(self):
   return getattr(self, field)
   def _set(self, val):
   setattr(self, field, val)
   for otherProp in prop:
   if otherProp != prop: setattr(self, '_' + otherProp, 
None)
   # Assign property to class
   setattr(Test, prop, property(_get, _set))
t = Test()
t.foo = 1
assert t.bar == t.spam == None
But the class Test is not defined yet, so I can't set a property on
it.  How can I do this?

With a metaclass, or a post-class-creation function. Which is a
metaclass without being fancy.

Just put your above code into a function with the class in question as
argument, and invoke it after Test is defined.

Diez


I think there are some closure issues with this as I am getting very
strange results.  I think all properties have the getter/setters of
whatever the last item in the list was.
t.foo = 'settingFoo' actually sets t.spam, as 'spam' was the last
property generated.


That's a FAQ. Closures capture the *names*, not the values. There are 
various options to remedy this, e.g. by something like this:



def gen_property(prop):

def _get(...) # your code


return property(_get, _set)

setattr(Test, prop, gen_property(prop))


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


Python 2.6.3 TarFile Module Add odd behavior

2009-11-13 Thread Tilson, Greg (IS)

In Windows Python 2.6.3 calling TarFile.add requires arcname= to be set
to work with WinZIP or WinRAR

Documentation reads:
TarFile.add(name, arcname=None, recursive=True, exclude=None) 
Add the file name to the archive. name may be any type of file
(directory, fifo, symbolic link, etc.). If given, arcname specifies an
alternative name for the file in the archive. Directories are added
recursively by default. This can be avoided by setting recursive to
False. If exclude is given it must be a function that takes one filename
argument and returns a boolean value. Depending on this value the
respective file is either excluded (True) or added (False).

Changed in version 2.6: Added the exclude parameter.

If arcname= is not set during extraction all filenames are "None"

Suggest document change or filing a bug report
I am accessing comp.lang.python through email because of Northrop
Grumman News server issue
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: bootstrapping on machines without Python

2009-11-13 Thread M.-A. Lemburg
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.
> 
> An application source code could be distributed with this small exe to
> wrap its top level 'main.py', and the application could then be run on
> machines which do not (yet) have Python installed.
> 
> The goal of this is to provide a way for end-users to download and
> double-click a Python application, without having to know what Python
> is or whether (an appropriate version of) it is installed. This method
> has some disadvantages compared to using py2exe et al, but it has the
> advantage that a small application would remain small: there is no
> need to bundle a whole interpreter with every application.

There are two major issues with such an approach:

 * users will not necessarily like it if a small application
   downloads a several MB from the web somewhere without asking

 * installing applications on Windows typically requires admin
   rights or at least user interaction

I think a good solution to the problem is wrapping the application's
main.py in a batch file which pops up a window to let the user know
that s/he will need to install Python first and point him/her to the
www.python.org web site, if necessary.

Another aspect to consider is whether a py2exe wrapped Python
application is really too big at all.

We ship a rather complex application using py2exe (mxODBC Connect Server)
and the resulting installed footprint is just around 14 MB - that's
roughly the size of a typical YouTube video.

By comparison, a full Python 2.5 installation is around 84 MB and
includes lots of stuff normally not needed for a small
Python application.

> From an
> advocacy point of view, it also must help that merely running such an
> application would seamlessly put a usable Python interpreter installed
> and on the PATH on Windows boxes.
> 
> Even my very limited understanding of the issues is enough to see that
> the idea is far from trivial. I'm aware that great minds are working
> on related and overlapping problems, so I thought I'd ask whether many
> people have done this already, and if not, is there any value in
> taking the trivial first step described above? ie. Ignore all
> complications, and write a simple C program to download & install an
> interpreter, then use that to run my Python.
> 
> In the long run, to be useful for real projects, the bootstrapper
> would need to manage some nasty details:
> * different versions of the interpreter for different applications
> * download required packages
> * manage conflicting versions of packages
> I'm hoping that these thorny problems will be solved, if they aren't
> already, by the great minds working on packaging, etc.
> 
> I'm very aware that I don't know anything at all about this, compared
> to many on the list. Be gentle with me. :-)

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Nov 13 2009)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try our new mxODBC.Connect Python Database Interface for free ! 


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: converting latitude and longitude

2009-11-13 Thread MRAB

Ronn Ross wrote:



I'm attempting to convert latitude and longitude coordinates from 
degrees minutes and second to decimal form. I would like to go from:

N39 42 36.3 W77 42 51.5

to:
-77.739855,39.70

Does anyone know of a library or some existing out their to help with 
this conversion?



The conversion is simple enough. Why do you need a library?

BTW, are you sure the values are correct? I get '-77.714306,39.710083'.
--
http://mail.python.org/mailman/listinfo/python-list


converting latitude and longitude

2009-11-13 Thread Ronn Ross
I'm attempting to convert latitude and longitude coordinates from degrees
minutes and second to decimal form. I would like to go from:
  N39 42 36.3 W77 42 51.5
 to:
-77.739855,39.70

Does anyone know of a library or some existing out their to help with this
conversion?
-- 
http://mail.python.org/mailman/listinfo/python-list


[no subject]

2009-11-13 Thread Ronn Ross
I'm attempting to convert latitude and longitude coordinates from degrees
minutes and second to decimal form. I would like to go from:
N39 42 36.3 W77 42 51.5
 to:
-77.739855,39.70

Does anyone know of a library or some existing out their to help with this
conversion?
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Vote on PyPI comments

2009-11-13 Thread Daniel Fetchinson
>> PyPI grew a commenting and rating system a while back, apparently in
>> response to requests from users. However, since it's been rolled out,
>> there's been a backlash from package maintainers who already have
>> mailing lists, bug trackers, etc for their packages and don't want to
>> have to try and keep track of yet another support forum.
>>
>
> 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.

Hmm, do you really think subscribing to python-list should be a
prerequisite for people who want to have some clue which python
software they want to use?

Cheers,
Daniel

-- 
Psss, psss, put it down! - http://www.cafepress.com/putitdown
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: object serialization as python scripts

2009-11-13 Thread Chris Rebert
On Fri, Nov 13, 2009 at 10:26 AM, King  wrote:
>> Why is it easier than the above mentioned - they are *there* (except the
>> custom xml), and just can be used. What don't they do you want to do?
>>
>> Other than that, and even security issues put aside, I don't see much
>> difference between pickle and python code, except the latter being more
>> verbose. Which suits humans, but other than that has no advantage.
>>
>> Diez
>
> My application is PyQt based and objects that I am trying to save are
> couple of QGraphicsItem instances. You can't save instances of
> QGraphicsItem
> using pickle or shelve.
> Custom xml format would be a real pain as you have to write code for
> writing/reading both.
>
> I am aware of security issue but over all there are only 5 statements
> I have to use to get the entire
> information back. I can do syntax checking and other stuff before I
> should execute the script.
>
> Another reason is that data should be in human readable form.

Did you consider the `json` module? JSON is almost identical to Python
literal syntax.
http://docs.python.org/library/json.html

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


Re: object serialization as python scripts

2009-11-13 Thread King
> Why is it easier than the above mentioned - they are *there* (except the
> custom xml), and just can be used. What don't they do you want to do?
>
> Other than that, and even security issues put aside, I don't see much
> difference between pickle and python code, except the latter being more
> verbose. Which suits humans, but other than that has no advantage.
>
> Diez

My application is PyQt based and objects that I am trying to save are
couple of QGraphicsItem instances. You can't save instances of
QGraphicsItem
using pickle or shelve.
Custom xml format would be a real pain as you have to write code for
writing/reading both.

I am aware of security issue but over all there are only 5 statements
I have to use to get the entire
information back. I can do syntax checking and other stuff before I
should execute the script.

Another reason is that data should be in human readable form.

Prashant

Python 2.6.2
Win XP 32
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Unexpected python exception

2009-11-13 Thread Tino Wildenhain

Am 11.11.2009 15:29, schrieb Richard Purdie:

On Wed, 2009-11-11 at 05:04 -0800, Chris Rebert wrote:

On Wed, Nov 11, 2009 at 4:37 AM, Richard Purdie  wrote:


Is there a way to make the "global x" apply to all functions without
adding it to each one?


Thankfully, no.


Hmm :(.


What I'm trying to do is to avoid having "import X" statements
everywhere by changing __builtin__. It seems my approach doesn't have
quite the same effect as a true import though.


And you can't just put all your imports together at the top of the
file because...?


The application in question is bitbake, the parsing tool for the
OpenEmbedded and Poky projects.

We're talking about python code fragments spread across about 8,000
files which make up the "metadata" some of which is public and some of
which is not. Rightly or wrongly bitbake does some interesting things
with its execution contexts for these code fragments.


And you can't just use __import__() to programmatically include some
of the fragments instead of having this local/global weirdness in
funtions in those modules?


Lets just say its not a traditional use case, we know the way bitbake
does some things is evil but it does other things rather well and we
can't break those.


I'd need to see the bigger picture because I don't know of bitbake but I
have a feeling this can be done much nicer in the end.

Regards
Tino



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Dynamic property names on class

2009-11-13 Thread Bryan
On Nov 13, 9:34 am, "Diez B. Roggisch"  wrote:
> Bryan schrieb:
>
>
>
> > I have several properties on a class that have very similar behavior.
> > If one of the properties is set, all the other properties need to be
> > set to None.  So I wanted to create these properties in a loop like:
>
> > class Test(object):
> >    for prop in ['foo', 'bar', 'spam']:
> >            # Attribute that data is actually stored in
> >            field = '_' + prop
> >            # Create getter/setter
> >            def _get(self):
> >                    return getattr(self, field)
> >            def _set(self, val):
> >                    setattr(self, field, val)
> >                    for otherProp in prop:
> >                            if otherProp != prop: setattr(self, '_' + 
> > otherProp, None)
> >            # Assign property to class
> >            setattr(Test, prop, property(_get, _set))
>
> > t = Test()
> > t.foo = 1
> > assert t.bar == t.spam == None
>
> > But the class Test is not defined yet, so I can't set a property on
> > it.  How can I do this?
>
> With a metaclass, or a post-class-creation function. Which is a
> metaclass without being fancy.
>
> Just put your above code into a function with the class in question as
> argument, and invoke it after Test is defined.
>
> Diez

I think there are some closure issues with this as I am getting very
strange results.  I think all properties have the getter/setters of
whatever the last item in the list was.
t.foo = 'settingFoo' actually sets t.spam, as 'spam' was the last
property generated.
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: object indexing and item assignment

2009-11-13 Thread John Posner

King wrote:


class MyFloat(object):
def __init__(self, value=0.):
self.value = value

def set(self, value):
self.value = value

def get(self):
return self.value

class MyColor(object):
def __init__(self, value=(0,0,0)):
self.value = (MyFloat(value[0]),
MyFloat(value[1]),
MyFloat(value[2]))

def set(self, value):
self.value[0].set(value[0])
self.value[1].set(value[1])
self.value[2].set(value[2])

def get(self):
return (self.value[0].get(),
self.value[1].get(),
self.value[2].get())

col = MyColor()
col[0].set(0.5) # 'MyColor' object does not support indexing
col[0] = 0.5 # 'MyColor' object does not support item assignment
  


King, I think you might be trying too hard. (Since I don't know your 
"big picture", my suspicion might be wrong.) Python does not *require* 
you to implement "get" and "set" methods in user-defined classes. More 
detail ...


* You might not need the MyFloat class at all. Try using a plain old 
Python "float" value.


* You don't need the "set" and "get" methods in the MyColor class. So 
this might suffice:


   class MyColor(object):
   def __init__(self, value=(0.,0.,0.)):
   self.value = list(value)

It's important for self.value to be a *list* object only if you want 
modify individual components of a MyColor instance.  If you *do* want to 
modify individual components, then it *does* make sense to implement 
"set" and "get" methods:


   def set_comp(self, index, comp_value):
   self.value[index] = comp_value

   def get_comp(self, index):
   return self.value[index]

For debugging, it makes senses to implement a __str__ or __repr__ 
method, so that "print" produces useful output:


   def __str__(self):
   return "MyColor: %3.1f %3.1f %3.1f" % tuple(self.value)

Putting it all together ...

#-
class MyColor(object):
   def __init__(self, value=(0.,0.,0.)):
   self.value = list(value)

   def __str__(self):
   return "MyColor: %3.1f %3.1f %3.1f" % tuple(self.value)

   def set_comp(self, index, comp_value):
   self.value[index] = comp_value

   def get_comp(self, index):
   return self.value[index]

col = MyColor()
print col  # output: MyColor: 0.0 0.0 0.0

col.set_comp(0, 0.5)
print col  # MyColor: 0.5 0.0 0.0

col.set_comp(2, 0.7)
print col  # MyColor: 0.5 0.0 0.7

col = MyColor((0.2, 0.3, 0.4))
print col  # MyColor: 0.2 0.3 0.4
#-

-John

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


Re: Dynamic property names on class

2009-11-13 Thread Diez B. Roggisch

Bryan schrieb:

I have several properties on a class that have very similar behavior.
If one of the properties is set, all the other properties need to be
set to None.  So I wanted to create these properties in a loop like:

class Test(object):
for prop in ['foo', 'bar', 'spam']:
# Attribute that data is actually stored in
field = '_' + prop
# Create getter/setter
def _get(self):
return getattr(self, field)
def _set(self, val):
setattr(self, field, val)
for otherProp in prop:
if otherProp != prop: setattr(self, '_' + 
otherProp, None)
# Assign property to class
setattr(Test, prop, property(_get, _set))

t = Test()
t.foo = 1
assert t.bar == t.spam == None

But the class Test is not defined yet, so I can't set a property on
it.  How can I do this?


With a metaclass, or a post-class-creation function. Which is a 
metaclass without being fancy.


Just put your above code into a function with the class in question as 
argument, and invoke it after Test is defined.


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


Re: object serialization as python scripts

2009-11-13 Thread Diez B. Roggisch

King schrieb:

I have looked upon various object serialization de-serialization
techniques.
(shelve, pickle, anydbm, custom xml format etc.) What I personally
feel that instead of all these
methods for saving the objects it would be easier to save the data as
python scripts itself.
In this case, loading the data is merely to run the script in the
context itself.
Need some expert advice and pointers here. Is there any thing (module,
script, doc, article)
helpful out there for the concern?


Why is it easier than the above mentioned - they are *there* (except the 
custom xml), and just can be used. What don't they do you want to do?


Other than that, and even security issues put aside, I don't see much 
difference between pickle and python code, except the latter being more 
verbose. Which suits humans, but other than that has no advantage.


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


[ANN] pyOpenSSL 0.10

2009-11-13 Thread exarkun

I'm happy to announce the release of pyOpenSSL 0.10.

pyOpenSSL 0.10 exposes several more OpenSSL APIs, including support for 
running TLS connections over in-memory BIOs, access to the OpenSSL 
random number generator, the ability to pass subject and issuer 
parameters when creating an X509Extension instance, more control over 
PKCS12 creation and an API for exporting PKCS12 objects, and APIs for 
controlling the client CA list servers send to clients.


Several bugs have also been fixed, including a crash when certain 
X509Extension instances are deallocated, a mis-handling of the OpenSSL 
error queue in the X509Name implementation, Windows build issues, and a 
possible double free when using a debug build.


The style of the docstrings for APIs implemented in C has also been 
changed throughout the project to be more useful to Python programmers. 
Extension type objects can also now be used to instantiate those types.


Many thanks to numerous people who contributed patches to this release.

You can find pyOpenSSL 0.10 on the Python Package Index:

   http://pypi.python.org/pypi/pyOpenSSL/0.10

You can now also find the pyOpenSSL documentation there:

   http://packages.python.org/pyOpenSSL/

As part of the ongoing transition away from SourceForge, I won't be 
uploading the release or the documentation to SourceForge.  Please 
continue to use the pyOpenSSL Launchpad page for bug reports:


   https://launchpad.net/pyopenssl

Enjoy!

Jean-Paul Calderone
--
http://mail.python.org/mailman/listinfo/python-list


Re: wsgi with separate css file

2009-11-13 Thread Rami Chowdhury
On Fri, 13 Nov 2009 08:55:33 -0800, Alena Bacova   
wrote:



Hi,
I'm using:

from wsgiref import simple_server
httpd = simple_server.make_server(HOST, PORT, Test)
try:
httpd.serve_forever()
except KeyboardInterrupt:
  pass

But I can use something else if needed.  Application and htmk, css and
images are stored on the same machine, everything is stored in one  
folder.


Alena.



If you are just using this to learn to develop WSGI applications, I would  
recommend implementing a method to distinguish requests for static files,  
and handle them separately. A very naive implementation handling .css  
files might look like:


from wsgiref import util
import os

def do_get(environ, start_response):
REQUEST_URI = util.request_uri(environ)
if (REQUEST_URI.endswith('.css')):
return do_css(REQUEST_URI, start_response)

# your regular code here

def do_css(request_uri, start_response):
full_path = os.path.abspath(os.path.join(MY_HTTP_DIRECTORY, 
request_uri))
if os.path.exists(full_path):
file_obj = open(full_path, 'r')
response_lines = file_obj.readlines()
file_obj.close()
start_response('200 OK', [('Content-Type', 'text/css')])
return response_lines
else:
start_response('404 Not Found', [])
return []

However, this method is fragile and very inefficient. If you want to  
eventually deploy this application somewhere, I would suggest starting  
with a different method.


Hope that helps,
Rami

--
Rami Chowdhury
"Never attribute to malice that which can be attributed to stupidity" --  
Hanlon's Razor

408-597-7068 (US) / 07875-841-046 (UK) / 0189-245544 (BD)
--
http://mail.python.org/mailman/listinfo/python-list


Dynamic property names on class

2009-11-13 Thread Bryan
I have several properties on a class that have very similar behavior.
If one of the properties is set, all the other properties need to be
set to None.  So I wanted to create these properties in a loop like:

class Test(object):
for prop in ['foo', 'bar', 'spam']:
# Attribute that data is actually stored in
field = '_' + prop
# Create getter/setter
def _get(self):
return getattr(self, field)
def _set(self, val):
setattr(self, field, val)
for otherProp in prop:
if otherProp != prop: setattr(self, '_' + 
otherProp, None)
# Assign property to class
setattr(Test, prop, property(_get, _set))

t = Test()
t.foo = 1
assert t.bar == t.spam == None

But the class Test is not defined yet, so I can't set a property on
it.  How can I do this?
-- 
http://mail.python.org/mailman/listinfo/python-list


object serialization as python scripts

2009-11-13 Thread King
I have looked upon various object serialization de-serialization
techniques.
(shelve, pickle, anydbm, custom xml format etc.) What I personally
feel that instead of all these
methods for saving the objects it would be easier to save the data as
python scripts itself.
In this case, loading the data is merely to run the script in the
context itself.
Need some expert advice and pointers here. Is there any thing (module,
script, doc, article)
helpful out there for the concern?

Prashant

Python 2.6.2
Win XP 32
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Adding methods to an object instance

2009-11-13 Thread Bruno Desthuilliers

lallous a écrit :

Hello

class __object(object):



the convention for reusing reserved words as identifiers is to *suffix* 
them with a single underscore, ie:


class object_(object):
   #



   def __getitem__(self, idx):
   return getattr(self, idx)

class __dobject(object): pass

x = __object()
setattr(x, "0", "hello")
print x["0"]

y = __dobject(a=1,b=2)

setattr(y, "0", "world")
#print y["0"]

How can I, given an object of instance "__dobject", add to that instance 
a __getitem__ method so that I can type:

print y["0"]


Adding per-instance methods won't work for __magic_methods__. But you 
could use the Decorator pattern here:



class IndexableDecorator(object):
def __init__(self, other):
self._other = other
def __getitem__(self, idx):
return getattr(self._other, idx)
def __setattr__(self, name, value):
if name = "_other":
object.__setattr__(self, name, value)
else:
setattr(self._other, name, value)

x = IndexableDecorator(x)

NB : not tested, so it probably contains at least one obvious error !-)
--
http://mail.python.org/mailman/listinfo/python-list


Re: wsgi with separate css file

2009-11-13 Thread Rami Chowdhury
On Fri, 13 Nov 2009 08:34:57 -0800, Alena Bacova   
wrote:



Hi all,

I just wanted to know if anybody tried using wsgi as a web server that  
would

be serving html file with separate css file. I managed to make my wsgi
server display only on html file ( it has got the form tag, and I'm  
serving

do_get and do_post call to) but I would like to have formatting stored in
separate css file, rather then embedded in html code. Plus being able to
serve image files with the html would be nice addition.

I tried to google the thing, but there wasn't any explicit example of  
such
thing. After I get the do_get request from browser and html is posted I  
do

get "do_get /file.css" request, but I have no idea how to serve that.

Any help, examples, suggestions more then welcome.



Hi Alena,

Can you tell us a little more about your setup? For instance, are you  
using the simple_server from the wsgiref module? Where are the application  
and CSS files being stored and run?


Cheers
Rami

--
Rami Chowdhury
"Never attribute to malice that which can be attributed to stupidity" --  
Hanlon's Razor

408-597-7068 (US) / 07875-841-046 (UK) / 0189-245544 (BD)
--
http://mail.python.org/mailman/listinfo/python-list


Adding methods to an object instance

2009-11-13 Thread lallous

Hello

class __object(object):
   def __getitem__(self, idx):
   return getattr(self, idx)

class __dobject(object): pass

x = __object()
setattr(x, "0", "hello")
print x["0"]

y = __dobject(a=1,b=2)

setattr(y, "0", "world")
#print y["0"]

How can I, given an object of instance "__dobject", add to that instance a 
__getitem__ method so that I can type:

print y["0"]

Thanks,
Elias 


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


wsgi with separate css file

2009-11-13 Thread Alena Bacova
Hi all,

I just wanted to know if anybody tried using wsgi as a web server that would
be serving html file with separate css file. I managed to make my wsgi
server display only on html file ( it has got the form tag, and I'm serving
do_get and do_post call to) but I would like to have formatting stored in
separate css file, rather then embedded in html code. Plus being able to
serve image files with the html would be nice addition.

I tried to google the thing, but there wasn't any explicit example of such
thing. After I get the do_get request from browser and html is posted I do
get "do_get /file.css" request, but I have no idea how to serve that.

Any help, examples, suggestions more then welcome.

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


Re: ANN: esky 0.2.1

2009-11-13 Thread Aahz
In article ,
Ryan Kelly   wrote:
>
>>>Esky is an auto-update framework for frozen python apps, built on top of
>>>bbfreeze.  It provides a simple API through which apps can find, fetch
>>>and install updates, and a bootstrapping mechanism that keeps the app
>>>safe in the face of failed or partial updates.
>>
>> Recently I was looking into distribution mechanisms, and I passed over
>> bbfreeze because I saw no indication that Python 2.6 was supported.
>
>Not sure if it's officially supported, but I do most of my development
>on Python 2.6 and bbfreeze hasn't given me any problems as yet.

Also, bbfreeze doesn't seem to have active development.
-- 
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: Vote on PyPI comments

2009-11-13 Thread Michele Simionato
On Nov 13, 4:39 pm, Chris Withers  wrote:
>
> PyPI grew a commenting and rating system a while back, apparently in
> response to requests from users. However, since it's been rolled out,
> there's been a backlash from package maintainers who already have
> mailing lists, bug trackers, etc for their packages and don't want to
> have to try and keep track of yet another support forum.
>

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.
-- 
http://mail.python.org/mailman/listinfo/python-list


Vote on PyPI comments

2009-11-13 Thread Chris Withers

Hi All,

Apologies for the cross post, but I'm not sure this has received the 
publicity it deserves...


PyPI grew a commenting and rating system a while back, apparently in 
response to requests from users. However, since it's been rolled out, 
there's been a backlash from package maintainers who already have 
mailing lists, bug trackers, etc for their packages and don't want to 
have to try and keep track of yet another support forum.


The arguments for and against are listed here:

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

To resolve the future of the commenting and rating system, a vote has 
been set up so everyone can have their say.


To vote, please log in to:

http://pypi.python.org/pypi

...and follow the instructions you'll be presented with.

I would like to remain neutral on this, and for me that means giving 
package authors the ability to choose whether they want to receive 
comments, ratings or neither rather than either forcing package authors 
to accept comments and ratings or abandoning the idea of comments and 
ratings completely.


The closest option to that is:

"Allow package owners to disallow comments (ratings unmodified)"

I hope the majority of you feel the same way...

Chris

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


Re: Does turtle graphics have the wrong associations?

2009-11-13 Thread Jonathan Campbell

Alf P. Steinbach wrote:
One reaction to http://preview.tinyurl.com/ProgrammingBookP3> has been that turtle 
graphics may be off-putting to some readers because it is associated 
with children's learning.




Incidentally ... something you may wish to consider for inclusion in you 
book ... games programming and Pygame.


See, e.g.,

Andy Harris, Game Programming (L Line: The Express Line to Learning), 
John Wiley & Sons, 2007, ISBN-10: 0470068221 or


Will McGugan, Beginning Game Development with Python and Pygame : From 
Novice to Professional, APRESS, 2007, ISBN-10: 1590598725.


I have the impression that there are many young people who could learn 
programming via games programming. On the other hand, in languages like 
C++ or Java, the threshold to games programming is extremely high.


Not so using Pygame.

The additional nice thing about Pygame is that it is based on a Python 
binding of SDL (Simple DirectMedia Layer) an open-source games API. This 
could mean easy migration to C++ games programming (using SDL).


Best regards,

Jon C.

--
Jonathan Campbell www.jgcampbell.com BT48, UK.
--
http://mail.python.org/mailman/listinfo/python-list


tkFileDialog question

2009-11-13 Thread Matt Mitchell
Hi,

This is my first attempt to write a script with any kind of gui.   All I
need the script to do is ask the user for a directory and then do stuff
with the files in that directory.  I used tkFileDialog.askdirectory().
It works great but it pops up an empty tk window.  Is there any way to
prevent the empty tk window from popping up? Here's the code:


import tkFileDialog

answer = tkFileDialog.askdirectory()

if answer is not '':
#do stuff

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


Re: bootstrapping on machines without Python

2009-11-13 Thread Martin P. Hellwig

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.



I can see two distinctive scenarios:
- Local temporarily installation
- System wide installation (possible conflicts with older versions)

Anyway this reminds me of the web installers where you only download the 
 installer which download the rest from the net, like they used to be 
available from adobe and for java.


It should be doable, for example you have an executable which has only 
one function; download a second stage installer from a fixed location.


That second stage installer is a bit bigger and knows how to check for 
dependencies for that particular platform and install other dependencies.


So you can chain a lot of installers after each other, for example the 
second stage installer can be a python installer then you could do all 
the remaining installing from the convenience of python.



--
MPH
http://blog.dcuktec.com
'If consumed, best digested with added seasoning to own preference.'
--
http://mail.python.org/mailman/listinfo/python-list


Re: bus error in Py_Finalize with ctypes imported

2009-11-13 Thread Robin
On Nov 13, 2:14 pm, Robin  wrote:
> I am trying to embed Python in a MATLAB mex function. This is loaded
> into the MATLAB interpreter - I would like the Python interpreter to
> be initialized once and stay there for future calls. I added a call to
> Py_Finalize as a mexAtExit handler which is called when the library is
> unloaded in MATLAB (with clear funcname) or when MATLAB shuts down. So
> far, things were working well, but I get a random but easily
> repeatable bus error in Py_Finalize if I have imported ctypes.

Looks like I've run into this bug:
http://bugs.python.org/issue6869

I will try the attached patch - hopefully it will make into a
forthcoming release.

Cheers

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


Re: Does turtle graphics have the wrong associations?

2009-11-13 Thread BGB / cr88192

"Peter Nilsson"  wrote in message 
news:ed7d74f6-c84d-40f1-a06b-642f988fb...@x25g2000prf.googlegroups.com...
> "Alf P. Steinbach"  wrote:
>> One reaction to http://preview.tinyurl.com/ProgrammingBookP3> 
>> has
>> been that turtle graphics may be off-putting to some
>> readers because it is associated with children's learning.
>
> [I'll be honest and say that I merely glanced at the two
> pdf files.]
>
> Who is your target audience? The opening Getting Started
> paragraph would probably put off many beginners right from
> the get go! You're talking about a 'first language' but
> throwing 'syntax', 'windows', 'graphics', 'networking',
> 'file and database access' and 'standard libraries' at them.
>
> The success of ' for Dummies' is certainly not their
> accuracy, but rather that they make far fewer assumptions
> that people already know the subject being tought! That
> assumption seems almost ingrained in every 'beginner'
> programming book I've ever seen!
>

yep, but I guess it depends some on the type of beginner...

many beginner books take the style of lots of examples and verbosity, and 
trying to gradually ease the person into the topic, ...

also common is more of a "crash course" style, where topics are introduced 
and defined, and where the contents tend to be far more categorical (in 
these books, often the later chapters and/or appendices are long, and often 
consist largely of definitions and reference material).

there are merits to both styles I think...


I have also seen where they try to fictionalize the topic, or turn it into 
some huge mass of allegories, but I don't really like this style so much...

it is possible the 'turtle' may hold these sorts of associations...


>> What do you think?
>
> Whilst everyone knows children tend to think visually more
> than abstractly, the same is precisely true of adults.
> However, the ultimate problem with Turtle is that it ends
> up teaching a 'mathematical' perspective and it's far from
> intuitive how you map that perspective to tackling more
> real world issues. It's simply substituting one difficult
> abstraction with another.
>
> My recollection is that many children struggled with Turtle
> graphics because they had very little concept of trigonometry.
> [Why would they? Many wouldn't learn for another 2-10 years.]
> Adults tend to have even less concept since they almost never
> use trig (or much else from school ;-) in the real world.
>

yep, much the same as trying to teach trig in a pseudo-fantasy setting by 
addressing the relative dimensions of the various parts of Excalibur...

one gets much more amusement out of just watching a sword fight where all 
they do is whack the swords into each other and pause momentarily, with 
whoever was doing the mixing unable to get the delay between the swords 
hitting and the 'clang' much less than about 300ms...


> They can see the patterns and understand there's a logic to
> it, but they struggle replicating it. Get an angle wrong
> and you end up with a mess where it's not clear whether it's
> your algorithm or the maths that's at fault.
>

yep...

simple, unstructured, thinking is easier.
if one screws up somewhere, it is a lot easier to find and correct the 
problem.

this is probably part of why procedural and OO have traditionally been more 
popular than functional programming:
one does not have to try to bend their mind so much to get things written or 
figure out just what the hell is going on...

granted, some level of mind-bending in necessary for programming, but IMO it 
is more of a necessary evil...


> The visual aspect might pique interest, but may put just as
> many people off. In any case, it won't relieve the difficulty
> of having to teach what is fundamentally an abstraction that
> doesn't have very good parallels with how people approach
> problems in the real world. Humans simply don't think like
> mathematicians^W computers. :-)
>
> I've met a lot of mathematics and comp sci teachers who
> honestly believe that you can't teach these subjects without
> a mathematical perspective. That stands in contrast to the
> number of people I see using spreadsheets with a very high
> proficiency who would never dream of saying they were good
> at mathematics or programming.
>

apparently, I don't even approach math in a mathematical manner...


I had thought I had understood math, and I use it enough, but I am 
suspecting that the thing I am familiar with is a good deal different than 
that seen by mathematicians (partly as a result of some interactions with, 
and observation of, physics teachers...).

or, it could be that my world is severely 'bent' because of my exposure to 
computers, and almost complete lack of need or desire to write proofs or to 
expand-out and perform huge amounts of symbolic manipulations by hand...


so, I guess my difficulty curve is rather "unusual" as well...

I live in a world where vectors and matrices are fairly simple, and 
quaternions would be, apart 

bus error in Py_Finalize with ctypes imported

2009-11-13 Thread Robin
Hi,

I am trying to embed Python in a MATLAB mex function. This is loaded
into the MATLAB interpreter - I would like the Python interpreter to
be initialized once and stay there for future calls. I added a call to
Py_Finalize as a mexAtExit handler which is called when the library is
unloaded in MATLAB (with clear funcname) or when MATLAB shuts down. So
far, things were working well, but I get a random but easily
repeatable bus error in Py_Finalize if I have imported ctypes.

Here is my code:

#include 
#include 

static int PYRUNNING = 0;

static void Cleanup(void)
{
mexPrintf("Finalising Python...\n");
Py_Finalize();
}

void mexFunction(int nlhs, mxArray *plhs[], int nrhs, const
mxArray*prhs[])
{
mexPrintf("hello from mex\n");

if (!PYRUNNING) {
Py_Initialize();
PYRUNNING = 1;
mexAtExit(Cleanup);
PyRun_SimpleString("import ctypes");
}

PyRun_SimpleString("print 'hello from python'");

}

If I load, run the function, and unload many times eventually I get
the following stack trace (whcih i don't get if I'm not import
ctypes). Does anyone have any idea what might be up? Could it be a bug
in Py_Finalize or ctypes? Is there a problem with my approach (ie is
it bad to leave the interpreter initialized between mex function calls
- it seems to work provided ctypes is not imported - but I need ctypes
to access other mex functions from python).


 Bus error detected at Fri Nov 13 14:06:12 2009


Configuration:
  MATLAB Version:   7.8.0.347 (R2009a)
  MATLAB License:   161051
  Operating System: Darwin 10.0.0 Darwin Kernel Version 10.0.0: Fri
Jul 31 22:47:34 PDT 2009; root:xnu-1456.1.25~1/RELEASE_I386 i386
  Window System:The X.Org Foundation (10402000), display /tmp/
launch-2p1ZWg/:0
  Current Visual:   0x24 (class 4, depth 24)
  Processor ID: x86 Family 6 Model 15 Stepping 10, GenuineIntel
  Virtual Machine:  Java 1.6.0_15-b03-219 with Apple Inc. Java HotSpot
(TM) Client VM mixed mode
  Default Encoding:  ISO-8859-1

Fault Count: 1

Register State:
  eax =   ebx = 3483d9be
  ecx = 33ff7620  edx = 
  esi = 32fb4dc0  edi = 001a
  ebp = b0b69938  esp = b0b69920
  eip = 3485559f  flg = 00010282

Stack Trace:
  [0] Python:type_dealloc~(0x32fb4dc0, 0x33f70818, 0x34854f0b,
0x34844410) + 26 bytes
  [1] Python:dict_dealloc~(0x33fef930, 0x348e4b40 "__builtin__",
0xb0b699bc, 0xb0b699b8) + 142 bytes
  [2] Python:dict_dealloc~(0x33f429c0, 0x348ee58c "exitfunc",
0xb0b699d8, 0x348b96b0) + 142 bytes
  [3] Python:_PyImport_Fini~(0x348ee58c "exitfunc", 0, 0, 0) + 82
bytes
  [4] Python:Py_Finalize~(673024, 1, 0, 0x00ab4700) + 207 bytes
  [5] libmex.dylib:SafeExitFunctionCall(void (*)())(0x30365df0,
0xb0b69ab8, 0xb0b69a80, 0x0073d01b) + 66 bytes
  [6] libmex.dylib:mexClearMexFileDefault(impl_info_tag*)(0x33e0dce0,
1, 0, 0x015fa3d8 "7Mfh_mex") + 80 bytes
  [7] libmex.dylib:safeMexClearMexFile(impl_info_tag*&)(0xb0b69bec
"‡‹‡3", 1, 0x015fc080, 0) + 76 bytes
  [8] libmex.dylib:Mlm_mex::unload_file()(0x32b01290, 0, 0, 0) + 250
bytes
  [9] libmwm_dispatcher.dylib:Mlm_file::unload_mf()(0x32b01290, 0, 0,
0) + 18 bytes
  [10] libmwm_dispatcher.dylib:Mlm_MATLAB_fn::clear()(0x32b01290, 0,
0xb0b69c9c, 236) + 82 bytes
  [11] libmwm_dispatcher.dylib:void clear
(Mlmmf_string_matcher, int)(0x05319c00, 0x33e24b8c "pytest",
0x30476300, 0x03f3b531 "pytest") + 296 bytes
  [12] libmwm_dispatcher.dylib:mdClearFunctionsByName(0x33e24b8c
"pytest", 42, 0xb0b6adf8, 10) + 650 bytes
  [13] libmwm_interpreter.dylib:InterpBridge::FullClearFcn(int,
mxArray_tag**, int, mxArray_tag**)(0x036225e0, 0, 0xb0b6af6c, 1) +
1234 bytes
  [14] libmwm_interpreter.dylib:inFullClearFcn(int, mxArray_tag**,
int, mxArray_tag**)(0, 0xb0b6af6c, 1, 0xb0b6afcc) + 50 bytes
  [15] libmwm_dispatcher.dylib:Mfh_builtin::dispatch_mf(int,
mxArray_tag**, int, mxArray_tag**)(0x2dd025a0, 0, 0xb0b6af6c, 1) + 95
bytes
  [16] libmwm_dispatcher.dylib:Mfh_MATLAB_fn::dispatch_fh(int,
mxArray_tag**, int, mxArray_tag**)(0x2dd025a0, 0, 0xb0b6af6c, 1) + 192
bytes
  [17] libmwm_interpreter.dylib:inDispatchFromStack(int, char const*,
int, int)(0, 0x304fa51c "clear", 0, 1) + 998 bytes
  [18] libmwm_interpreter.dylib:inDispatchCall(char const*, int, int,
int, int*, int*)(1, 0xb0b6b298, 0x33e11a28, 0x9322e76b) + 152 bytes
  [19] libmwm_interpreter.dylib:inInterp(inDebugCheck, int, int,
opcodes, inPcodeNest_tag volatile*, int*)(1, 0, 1, 0) + 5167 bytes
  [20] libmwm_interpreter.dylib:protected_inInterp(inDebugCheck, int,
int, opcodes, inPcodeNest_tag*, int*)(1, 0, 1, 0) + 112 bytes
  [21] libmwm_interpreter.dylib:inInterPcodeSJ(inDebugCheck, int, int,
opcodes, inPcodeNest_tag*, int*)(0, 0x33e007d0, 0xb0b6b460,
0xb0b6b460) + 266 bytes
  [22] libmwm_interpreter.dylib:inExecuteMFunctionOrScript(Mfh_mp*,
bool)(0x33e263c0, 1, 0xb0b6b99c, 0) + 932 bytes
  [23] libmwm_interpreter

Re: A beginner question about GUI use and development

2009-11-13 Thread Philip Semanchuk


On Nov 13, 2009, at 3:55 AM, uap12 wrote:


Hi!
I have written som Python programs but no one with a GUI yet,
i have look around and found a lot of diffrent gui module.

I will develop program that will use a small amout of GUI part
eg. program to show status about server etc.

I have looked att wxWidget, but i like a rekommendation here
(Will develop Windows program but somtimes OSX to)


Hej Anders,
wxWidgets and PyQT are very popular. As Marcus pointed out, Tkinter  
has the advantage that it ships with Python. These three should be  
your top candidates.




When i givet the program away i like to pack it, so the enduser
just run it, i don't like to tell the user to install Python, and/or
som GUI package. is this possible.


Yes, but the solutions aren't straightforward. Look at py2exe for  
Windows and py2app for the Mac. I don't know what to recommend for  
*nix (Linux, FreeBSD, etc.)




In the beginning it is okej to code the gui "by hand" to learn
but after that i like som kind of GUI-designtool, and god
to recommade ??


wxGlade is popular for wxWidgets. I don't know about PyQT or Tkinter.


Lycka till,
Philip
--
http://mail.python.org/mailman/listinfo/python-list


Re: bootstrapping on machines without Python

2009-11-13 Thread Tim Golden

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
--
http://mail.python.org/mailman/listinfo/python-list


Re: #define (from C) in Python

2009-11-13 Thread garabik-news-2005-05
Santiago Romero  wrote:
> 
>> > #define STORE_nn_rr(dreg) \
>> >                         r_opl = Z80ReadMem(r_PC); r_PC++;\
>> >                         r_oph = Z80ReadMem(r_PC); r_PC++; \
>> >                         r_tmp = dreg; \
>> >                         Z80WriteMem((r_op),r_tmpl, regs); \
>> >                         Z80WriteMem((r_op+1),r_tmph, regs)
>>
>> Someone writing such code and calling it C should be taken
>> behind the barn and shot.
> 
> That code is mine and maybe you should look the context
> before doing such kind of affirmations.
> 
> In the Intel Pentium and P-II ages, I started to wrote the
> very first Spectrum emulator in C. With that "cpu power", emulators
> had to be written in ASM to be capable to emulate the destination
> machines at 100% full speed in multitasking systems.
> 

Hey, I got 100% with ASM ZX Spectrum emulator on a low end 386 :-) (I do
not remember the CPU freqeuncy anymore, maybe 25MHz). First emulator in
C that appeared on the emu-scene (I guess it was x128) needed 486
(~80MHz?) to run at realtime. Pentium and Pentium II was A LOT of 
power :-)

...

> 
> Now I'm porting the emulator to a scripted language, so I need
> even more previous design ideas before starting to code, so that
> I can achieve (I hope I'll be able to do it with this group's help)
> 100% cpu speed in an standard desktop PC.
> 
>> >  But it seems that is not possible :-(

http://perl-spectrum.sourceforge.net/

It is quite fast IMHO. 
Just remember to use psyco...

-- 
 ---
| Radovan Garabík http://kassiopeia.juls.savba.sk/~garabik/ |
| __..--^^^--..__garabik @ kassiopeia.juls.savba.sk |
 ---
Antivirus alert: file .signature infected by signature virus.
Hi! I'm a signature virus! Copy me into your signature file to help me spread!
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Writing an emulator in python - implementation questions (for performance)

2009-11-13 Thread Bearophile
Try creation an extension module with ShedSkin.

Bye,
bearophile
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: object indexing and item assignment

2009-11-13 Thread Benjamin Kaplan
On Fri, Nov 13, 2009 at 7:57 AM, King  wrote:
> class MyFloat(object):
>    def __init__(self, value=0.):
>        self.value = value
>
>    def set(self, value):
>        self.value = value
>
>    def get(self):
>        return self.value
>
> class MyColor(object):
>    def __init__(self, value=(0,0,0)):
>        self.value = (MyFloat(value[0]),
>                        MyFloat(value[1]),
>                        MyFloat(value[2]))
>
>    def set(self, value):
>        self.value[0].set(value[0])
>        self.value[1].set(value[1])
>        self.value[2].set(value[2])
>
>    def get(self):
>        return (self.value[0].get(),
>                self.value[1].get(),
>                self.value[2].get())
>
> col = MyColor()
> col[0].set(0.5) # 'MyColor' object does not support indexing
> col[0] = 0.5 # 'MyColor' object does not support item assignment
>
>
> The last two lines of the script produce errors. (written as
> comments). I know it won't work as I am expecting. One solution I can
> think of is to rewrite MyFloat and MyColor by sub classing default
> python types "float and "tuple". Is this the only solution?
>
> Prashant
>
> Python 2.6.2
> Win XP 32
> --

In order to support indexing and item assignment, implement the
__getitem__ and __setitem__ methods.


def __getitem__(self, index) :
   return self.value[index]

def __setitem__(self, index, value) :
   self.value[index].set(value)



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


Re: #define (from C) in Python

2009-11-13 Thread Bearophile
Santiago Romero:

>Obviously, I prefer to write well structured code but I had to sacrifize SIZE 
>by SPEED<

In C99 you have "inline" (and gcc/gcc-llvm usually inline small
functions anyway) that helps avoid many macros.


>  Now I'm porting the emulator to a scripted language, so I need
> even more previous design ideas before starting to code, so that
> I can achieve (I hope I'll be able to do it with this group's help)
> 100% cpu speed in an standard desktop PC.

The tecniques needed to speed up Python code are very different from
the ones you use in C. You may need a lot of time to learn Python
performance tricks. Psyco helps a lot.


>  Well, I don't agree with that, "constants" and "macros" wouldn't
> hurt python, when using them in the right situations.

I miss true constants in Python, but it may be impossible to add them
to this language, because of how it uses references. In Python you
rely on convention, writing their names ALL_UPPERCASE.

Bye,
bearophile
-- 
http://mail.python.org/mailman/listinfo/python-list


object indexing and item assignment

2009-11-13 Thread King
class MyFloat(object):
def __init__(self, value=0.):
self.value = value

def set(self, value):
self.value = value

def get(self):
return self.value

class MyColor(object):
def __init__(self, value=(0,0,0)):
self.value = (MyFloat(value[0]),
MyFloat(value[1]),
MyFloat(value[2]))

def set(self, value):
self.value[0].set(value[0])
self.value[1].set(value[1])
self.value[2].set(value[2])

def get(self):
return (self.value[0].get(),
self.value[1].get(),
self.value[2].get())

col = MyColor()
col[0].set(0.5) # 'MyColor' object does not support indexing
col[0] = 0.5 # 'MyColor' object does not support item assignment


The last two lines of the script produce errors. (written as
comments). I know it won't work as I am expecting. One solution I can
think of is to rewrite MyFloat and MyColor by sub classing default
python types "float and "tuple". Is this the only solution?

Prashant

Python 2.6.2
Win XP 32
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Writing an emulator in python - implementation questions (for performance)

2009-11-13 Thread Gabriel Genellina
En Thu, 12 Nov 2009 23:29:03 -0300, greg   
escribió:

Carl Banks wrote:

You
can define constants to access specific registers:
 R1L = 1
R1H = 2
R1 = 1
 breg[R1H] = 2
print wreg[R1]


But keep in mind that named "constants" at the module level
are really global variables, and therefore incur a dictionary
lookup every time they're used.

For maximum speed, nothing beats writing the numeric literals
directly into the code, unfortunately.


This recipe may improve speed dramatically in those cases:
http://code.activestate.com/recipes/277940/

--
Gabriel Genellina

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


Re: Python & Go

2009-11-13 Thread Duncan Booth
Paul Rubin  wrote:

> Nah, exceptions are an ugly effect that gets in the way of
> parallelism.  Haskell handles lookups through its type system; dealing
> with lookup errors (say by chaining the Maybe type) is clean and
> elegant.  Erlang handles it by crashing the process, and dealing with
> the crash through a supervision tree that cleans up after crashes and
> restarts the crashed processes.

I said exceptions or any other method of error handling.

>> What that article didn't mention, and what is possibly Go's real
>> strong point is that it has built-in support for parallel processing.
>> Again though the implementation looks weak...
> 
> I'd like to know more about this; is there a link with a short
> write-up?  I haven't gotten around to looking at the reference
> materials.

I just read the reference manual. As I understand it:

Any function or method can be executed in parallel: instead of calling 
the function you use the go keyword:

   go doSomething();

go routines are executed using a thread pool, and an individual go 
routine might vary its execution thread depending on which threads are 
available.

Most types are not thread safe, so you should never access any mutable 
value from more than one go routine. If you need to access something 
like a map from multiple parallel routines you need to use channels to 
protect it.

You can declare and pass around channel variables. A channel can hold 
values or pointers of any type and has a specific number of free slots.
e.g.

   var ch = make(chan int, 3);

would create a channel that holds 3 int values.

To write to a channel (blocking if it is full):

   ch <- value;

To read from a channel (blocking if empty):

   value <- ch;

To read from a channel blocking and discarding the result (e.g. to wait 
for a routine to finish):

  <- ch;

To read without blocking:

  value, ok <- ch;

ok set true if something was read. And to write without blocking:

   ok := ch <- value;

or in fact any write in an expression context.

You can also use a select statement (syntax similar to a switch 
statement) to read or write channels in parallel. It arbitrarily chooses 
one of the case statements that can proceed to execute, otherwise if 
there is a default statement it executes that. If there is no default 
statement the entire select blocks until one of the case statements can 
proceed. e.g. (example from the docs)

var c1, c2 chan int;
var i1, i2 int;
select {
case i1 = <-c1:
print("received ", i1, " from c1\n");
case c2 <- i2:
print("sent ", i2, " to c2\n");
default:
print("no communication\n");
}

There doesn't seem to be any way to specify a timeout on a read or 
write. I think you can create a timer channel with regular ticks and 
select from that to provide an effective timeout, but that sounds like a 
lot of boilerplate if you have to do very often.

-- 
Duncan Booth http://kupuguy.blogspot.com
-- 
http://mail.python.org/mailman/listinfo/python-list


  1   2   >