Basic question about speed/coding style/memory

[Jan Riechers]

Hello Pythonlist,

I have one very basic question about speed,memory friendly coding, and 
coding style of the following easy "if"-statement in Python 2.7, but Im 
sure its also the same in Python 3.x


Block
#--
if statemente_true:
doSomething()
else:
doSomethingElseInstead()

#--

versus this block:
#--
if statement_true:
doSomething()
return

doSomethingElseInstead()

#--


I understand the first pattern that I tell the interpreter to do:
Check if the conditional is true, run "doSomething()" else go inside the 
else block and "doSomethingElseInstead()".


while the 2nd does only checks:
doSomething() if statement_true, if not, just go directly to 
"doSomethingElseInstead()



Now, very briefly, what is the better way to proceed in terms of 
execution speed, readability, coding style?
Letting out the fact that, in order to prevent 
"doSomethingElseInstead"-Block to execute, a return has to provided.


Thank you for reading and hope someone brings light into that.

Your fellow python programmer
Jan
--
http://mail.python.org/mailman/listinfo/python-list

Re: Basic question about speed/coding style/memory

[Andrew Berg]

On 7/21/2012 2:33 AM, Jan Riechers wrote:
> Block
> ...
> versus this block:
> ...
> Now, very briefly, what is the better way to proceed in terms of 
> execution speed, readability, coding style?
Using if/else is the most readable in the general sense. Using return
(or break or continue as applicable) in this manner would indicate (at
least to me) that it's an exceptional or otherwise special case and that
the function can't do what it's supposed to. In that case, I would try
to catch an exception rather than use if/else whenever possible. I
highly doubt there is a significant performance difference between them.
-- 
CPython 3.3.0b1 | Windows NT 6.1.7601.17803
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: ANN: dbf.py 0.94

[Ethan Furman]

Steven D'Aprano wrote:
This mailing list is about helping our fellow Python developers improve 
their skills and solve problems. That doesn't just mean *coding* 
problems, it also means helping them to write better documentation and 
promote their software better.


Indeed it is, and your reminder is appreciated.  Hopefully my 
followup-post was more explanatory.



Unless the software is so well-known that everybody knows what it is, 
failure to mention what the software does gives the impression that: 

1) the software is so niche, or so ill-thought out, that the developer 
*can't* describe it succinctly;


Nah -- just the end of a long week, needed to go get my daughter, and 
wanted it out there for those few who actually need the bug fixes (which 
I neglected to mention).


2) the developer has such poor communication skills that trying to get 
support will be a nightmare;


My support is pretty good.  :)



3) that he just doesn't give a monkey's toss for anyone else's time


See point one.


or all three. Ethan is a good, helpful member of this community, and
so I'm pretty sure that neither 2) nor 3) are true, but others may get
the wrong impression.


Thank you.  The project is kinda niche, but very useful if you happen to 
be in that niche.




Here are a few randomly selected examples of good release announcements:

http://mail.python.org/pipermail/python-announce-list/2012-June/009528.html

http://mail.python.org/pipermail/python-announce-list/2012-June/009509.html

http://mail.python.org/pipermail/python-announce-list/2012-June/009524.html


Those are good.  My announcement will be better next time.

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

Re: ANN: dbf.py 0.94

[Ethan Furman]

Simon Cropper wrote:


Question 1 - What version of VFP will dbf work with? Is VFP9 OK?


As long as you don't use auto-incrementing fields nor varchar fields 
you'll be fine.




Question 2 - You statement of compatibility is unclear.


Works with CPython 2.4 - 2.7. (Tested)

Works with PyPy 1.8. (Tested)

Should work with the others.  (Not tested)


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

Re: Basic question about speed/coding style/memory

[Jan Riechers]

On 21.07.2012 11:02, Andrew Berg wrote:

On 7/21/2012 2:33 AM, Jan Riechers wrote:

Block
...
versus this block:
...
Now, very briefly, what is the better way to proceed in terms of
execution speed, readability, coding style?

Using if/else is the most readable in the general sense. Using return
(or break or continue as applicable) in this manner would indicate (at
least to me) that it's an exceptional or otherwise special case and that
the function can't do what it's supposed to. In that case, I would try
to catch an exception rather than use if/else whenever possible. I
highly doubt there is a significant performance difference between them.



Hello Andrew,

Your answer is right, in other circumstances I also would stick to 
try/except, break-statements in loops and so forth.

But the question was a bit more elementary.

Cause, as I understand the interpreter chooses either the "else" (1st 
block) or just proceeds with following code outside the if.


So if there is some overhead in some fashion in case we don't offer the 
else, assuming the interpreter has to exit the evaluation of the 
"if"-statement clause and return to a "normal parsing code"-state 
outside the if statement itself.


I hope this explanation makes more sense in what I want to ask ;)

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

Re: A thread import problem

[Dieter Maurer]

Bruce Sherwood  writes:
> ...
> from visual import box, rate
> b = box()
> while True:
> rate(100) # no more than 100 iterations per second
> b.pos.x += .01
>
> This works because a GUI environment is invoked by the visual module
> in a secondary thread (written mainly in C++, connected to Python by
> Boost). The OpenGL rendering of the box in its current position is
> driven by a 30-millisecond timer. This works fine with any environment
> other than Mac Cocoa.
>
> However, the Mac Cocoa GUI environment and interact loop are required
> to be the primary thread, so the challenge is to have the visual
> module set up the Cocoa environment, with the user's program running
> in a secondary thread. Any ideas?

The usual approach to this situation is to invoke the user code via
a callback from the UI main loop or invoke it explicitely
after the UI system has been set up immediately before its main loop
is called. Might look somehow like this:

main thread:

from thread import start_new_thread
from visual import setup_gui, start_main_loop
setup_gui() # sets up the GUI subsystem
start_new_thread(lambda: __import__(), ())
start_main_loop()




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

Re: Basic question about speed/coding style/memory

[Chris Angelico]

On Sat, Jul 21, 2012 at 5:33 PM, Jan Riechers  wrote:
> Block
> #--
> if statemente_true:
> doSomething()
> else:
> doSomethingElseInstead()
>
> #--

This means, to me, that the two options are peers - you do this or you do that.

> versus this block:
> #--
> if statement_true:
> doSomething()
> return
>
> doSomethingElseInstead()
>
> #--

This would be for an early abort. Don't bother doing most of this
function's work, just doSomething. Might be an error condition, or
perhaps an optimized path.

Definitely for error conditions, I would use the second option. The
"fail and bail" notation keeps the entire error handling in one place:

def func(x,y,z):
  if x<0:
y+=5
return
  if y<0:
raise PEBKAC("There's an idiot here somewhere")
  # ... do the rest of the work

Note the similarity between the control structures. Raising an
exception immediately terminates processing, without polluting the
rest of the function with an unnecessary indentation level. Early
aborting through normal function return can do the same thing.

But this is purely a matter of style. I don't think there's any
significance in terms of processing time or memory usage, and even if
there is, it would be dwarfed by considerations of readability. Make
your code look like what it's doing, and let the execution take care
of itself.

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

Re: Basic question about speed/coding style/memory

[Andrew Berg]

On 7/21/2012 3:13 AM, Jan Riechers wrote:
> Cause, as I understand the interpreter chooses either the "else" (1st 
> block) or just proceeds with following code outside the if.
If none of the if/elif statements evaluate to something true, the else
block is executed.

> So if there is some overhead in some fashion in case we don't offer the 
> else, assuming the interpreter has to exit the evaluation of the 
> "if"-statement clause and return to a "normal parsing code"-state 
> outside the if statement itself.
I really don't understand. You can look into the dis module if you want
to look at how CPython bytecode is executed and the timeit module to
measure speed. In any case, I don't see how there would be any
significant difference.

http://docs.python.org/py3k/library/dis.html
http://docs.python.org/py3k/library/timeit.html
-- 
CPython 3.3.0b1 | Windows NT 6.1.7601.17803
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: ANN: dbf.py 0.94

[Chris Angelico]

On Sat, Jul 21, 2012 at 6:02 PM, Ethan Furman  wrote:
> Works with CPython 2.4 - 2.7. (Tested)

Have you considered supporting 3.2/3.3 at all? It's often not
difficult to make your code compatible with both. Or is there some
dependency that is locked to 2.X?

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

Re: Basic question about speed/coding style/memory

[Steven D'Aprano]

On Sat, 21 Jul 2012 10:33:27 +0300, Jan Riechers wrote:

> Hello Pythonlist,
> 
> I have one very basic question about speed,memory friendly coding, and
> coding style of the following easy "if"-statement in Python 2.7, but Im
> sure its also the same in Python 3.x

I assume that the following is meant to be inside a function, otherwise 
the return in the second example is illegal.

But in general, you're worrying too much about trivia. One way or the 
other, any speed difference will be trivial. Write whatever style reads 
and writes most naturally, and only worry about what's faster where it 
actually counts.

To give it an analogy that might be clear, this question is not too far 
from worrying about whether your car will be faster with the radio aerial 
up or down. Yes, technically the car will be slower with the aerial up, 
due to air resistance, but you'd have a job measuring it, and it makes no 
difference whether you are zooming down the highway at 120mph or stuck in 
traffic crawling along at 5mph.


Here's a minimal example:


def with_else(x):
if x:
a = x
else:
a = x+1
return a


def without_else(x):
if x:
a = x
return a
a = x+1
return a


Notice that I try to make each function do the same amount of work, so 
that we're seeing only the difference between "else" vs "no else".

Now let's test the speed difference with Python 2.7. Because this is 
timing small code snippets, we should use the timeit module to time the 
code:

from timeit import Timer
setup = "from __main__ import with_else, without_else"
t1 = Timer("for i in (0, 1): result = with_else(i)", setup)
t2 = Timer("for i in (0, 1): result = without_else(i)", setup)

Each snippet calls the function twice, once to take the if branch, then 
to take the else branch.

Now we time how long it takes to run each code snippet 100 times. We 
do that six times each, and print the best (lowest) speed:

py> min(t1.repeat(repeat=6))
0.9761919975280762
py> min(t2.repeat(repeat=6))
0.9494419097900391

So there is approximately 0.03 second difference per TWO MILLION 
if...else blocks, or about 15 nanoseconds each. This is highly unlikely 
to be the bottleneck in your code. Assuming the difference is real, and 
not just measurement error, the difference is insignificant.

So, don't worry about which is faster. Write whichever is more natural, 
easier to read and write.


> Block
> #--
> if statemente_true:
>   doSomething()
> else:
>   doSomethingElseInstead()

This style is especially recommended when the two clauses are equal in 
importance.


> versus this block:
> #--
> if statement_true:
>   doSomething()
>   return
> doSomethingElseInstead()

This style is especially recommended when the doSomethingElseInstead() 
block is the "normal" procedure, and the doSomething() block is a special 
case. Not necessarily rare, but nevertheless special in some sense.

Of course, the decision as to which is the "special" case and which is 
the "normal" case is often entirely arbitrary.



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

Re: Basic question about speed/coding style/memory

[Jan Riechers]

On 21.07.2012 12:06, Steven D'Aprano wrote:


But in general, you're worrying too much about trivia. One way or the
other, any speed difference will be trivial. Write whatever style reads
and writes most naturally, and only worry about what's faster where it
actually counts.





Notice that I try to make each function do the same amount of work, so
that we're seeing only the difference between "else" vs "no else".

Now let's test the speed difference with Python 2.7. Because this is
timing small code snippets, we should use the timeit module to time the
code:

from timeit import Timer
setup = "from __main__ import with_else, without_else"
t1 = Timer("for i in (0, 1): result = with_else(i)", setup)
t2 = Timer("for i in (0, 1): result = without_else(i)", setup)

Each snippet calls the function twice, once to take the if branch, then
to take the else branch.

Now we time how long it takes to run each code snippet 100 times. We
do that six times each, and print the best (lowest) speed:

py> min(t1.repeat(repeat=6))
0.9761919975280762
py> min(t2.repeat(repeat=6))
0.9494419097900391

So there is approximately 0.03 second difference per TWO MILLION
if...else blocks, or about 15 nanoseconds each. This is highly unlikely
to be the bottleneck in your code. Assuming the difference is real, and
not just measurement error, the difference is insignificant.

So, don't worry about which is faster. Write whichever is more natural,
easier to read and write.




Hello Steven,

very nice example and thank you very much for also for the Timeit test!
Actually it confirms my assumption in some way:

[SNIP myself]
So if there is some overhead in some fashion in case we don't offer the
else, assuming the interpreter has to exit the evaluation of the
"if"-statement clause and return to a "normal parsing code"-state
outside the if statement itself.
[SNAP]

Without having looked at Andrew's bytecode excecution hint, using the 
dis module, to see how the interpreter handles the task on lower level.


But fare enough for me :)

But I agree, the return in my example is misleading and it would be 
illegal outside of a function call. I just added it to make clear that 
the fellow code below the return should not be executed in comparison to 
the 2nd example.


Thank you very much
Jan
--
http://mail.python.org/mailman/listinfo/python-list

Re: PyPy, is it a 1:1 replacement for CPython?

[Terry Reedy]

On 7/20/2012 11:52 PM, Alec Taylor wrote:

ask on PyPy's list

But yes, it is designed as a 1:1 replacement of CPython


It is a replacement for some late 2.x versions but not, at present, for 
Python 3.



--
Terry Jan Reedy



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

Sudden doubling of nearly all messages

[Dave Angel]

Has anybody else noticed the sudden double-posting of nearly all
messages in the python mailing list?

Previously, I've seen some messages double posted, and it was nearly
always a newbie, presumably posting via some low-end gateway.  But now
i'm noticing nearly every message appears twice, identical datestamps,
and usually one message considered a reply to the other.

Deleting these locally is not only a pain, but if I get the wrong one,
it messes up the threading.

I'm using Thunderbird 14.0 on Linux 11.04, with mail configured for
non-digest mode.  I read the messages in threaded mode.

Probably related, I've had a serious spate of messages are obvious Re:
types, but not threaded to the original set.  I'm guessing because it's
because I earlier deleted one of a pair.

-- 

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

Re: Sudden doubling of nearly all messages

[Andrew Berg]

On 7/21/2012 5:48 AM, Dave Angel wrote:
> Has anybody else noticed the sudden double-posting of nearly all
> messages in the python mailing list?
I am also using the mailing list, but I haven't experienced this.
-- 
CPython 3.3.0b1 | Windows NT 6.1.7601.17803
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Sudden doubling of nearly all messages

[Mark Lawrence]

On 21/07/2012 11:48, Dave Angel wrote:

Has anybody else noticed the sudden double-posting of nearly all
messages in the python mailing list?


No.



Previously, I've seen some messages double posted, and it was nearly
always a newbie, presumably posting via some low-end gateway.  But now
i'm noticing nearly every message appears twice, identical datestamps,
and usually one message considered a reply to the other.

Deleting these locally is not only a pain, but if I get the wrong one,
it messes up the threading.


I have noticed some problems with threading.



I'm using Thunderbird 14.0 on Linux 11.04, with mail configured for
non-digest mode.  I read the messages in threaded mode.


Windows Vista, rest the same.



Probably related, I've had a serious spate of messages are obvious Re:
types, but not threaded to the original set.  I'm guessing because it's
because I earlier deleted one of a pair.



Could well be.

Just sorry I can't be of more help. :(

--
Cheers.

Mark Lawrence.

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

Re: Sudden doubling of nearly all messages

[Dave Angel]

On 07/21/2012 07:05 AM, Andrew Berg wrote:
> On 7/21/2012 5:48 AM, Dave Angel wrote:
>> Has anybody else noticed the sudden double-posting of nearly all
>> messages in the python mailing list?
> I am also using the mailing list, but I haven't experienced this.
Well, my own message was doubled, but not your reply.

When I look at the message sources, they definitely are different.  The
one looks to me like an ordinary email. The other is much longer, but I
don't claim to know what all the fields mean.

One pair of fields that looks interesting is:

...X-Original-To: python-list@python.org
...Delivered-To: python-l...@mail.python.org

I sent to  python-list@python.org, and when I do a reply-all that's what
gets filled in.  But what about the other address?


The pervasive doubling just started in the last day or two;  I saw 50
new messages overnight, between about 10pm and 4am, EDT.   I haven't
changed any settings on purpose, and the only new software is whatever
the Linux update manager changes.

-- 

DaveA

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

Re: Sudden doubling of nearly all messages

[Colin J. Williams]

On 21/07/2012 6:48 AM, Dave Angel wrote:

Has anybody else noticed the sudden double-posting of nearly all
messages in the python mailing list?



No.

Colin W.

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

Calling Java jar class with parameter from Python

[Jason Veldicott]

Hi,

I have read a number of posts on how this can be done, but I have not been
able to replicate success with the particular command I'm wishing to
execute.

I am wanting to execute the following Java command from Python in Windows:

java -cp c:\antlr\antlr-3.4-complete.jar org.antlr.Tool
"C:\Users\Jason\Documents\antlr\java grammar\Java.g"


This command works outside of Python at the command prompt.

So I do the same using Python's os.system:

os.system("C:\\Program Files (x86)\\Java\\jdk1.7.0_05\\bin\\java.exe -cp
c:\\antlr\\antlr-3.4-complete.jar org.antlr.Tool
'C:\\Users\\Jason\\Documents\\antlr\\java grammar\\Java.g'")


The return value is 1, which presumably indicates error.

Another variation using subprocess.call, one of many tried, gives the same
result:

subprocess.call(["C:\\Program Files
(x86)\\Java\\jdk1.7.0_05\\bin\\java.exe", "-cp
c:\\antlr\\antlr-3.4-complete.jar org.antlr.Tool",
"C:\\Users\\Jason\\Documents\\antlr\\java grammar\\Java.g"]  )

This variation using subprocess.Popen, gives a result, but it's ('', None).

subprocess.Popen(["C:\\Program Files
(x86)\\Java\\jdk1.7.0_05\\bin\\java.exe", "-cp
c:\\antlr\\antlr-3.4-complete.jar org.antlr.Tool",
"C:\\Users\\Jason\\Documents\\antlr\\java grammar\\Java.g"],
stdout=subprocess.PIPE, shell=True ).communicate()


Obviously, some trick is being missed.  Could anyone shed light on what it
may be?

Thanks

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

Re: Calling Java jar class with parameter from Python

[Peter Otten]

Jason Veldicott wrote:

> subprocess.Popen(["C:\\Program Files
> (x86)\\Java\\jdk1.7.0_05\\bin\\java.exe", "-cp
> c:\\antlr\\antlr-3.4-complete.jar org.antlr.Tool",
> "C:\\Users\\Jason\\Documents\\antlr\\java grammar\\Java.g"],
> stdout=subprocess.PIPE, shell=True ).communicate()
> 
> 
> Obviously, some trick is being missed.  Could anyone shed light on what it
> may be?

File names with spaces can be tricky. Try thoroughly separating the 
individual arguments and let subprocess do the necessary escaping. 
I think it should be

subprocess.Popen([
  "C:\\Program Files (x86)\\Java\\jdk1.7.0_05\\bin\\java.exe",
  "-cp",
  "C:\\antlr\\antlr-3.4-complete.jar",
  "org.antlr.Tool",
  "C:\\Users\\Jason\\Documents\\antlr\\java grammar\\Java.g"],
   stdout=subprocess.PIPE).communicate()


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

Re: Calling Java jar class with parameter from Python

[Roy Smith]

In article ,
 Peter Otten <__pete...@web.de> wrote:

> subprocess.Popen([
>   "C:\\Program Files (x86)\\Java\\jdk1.7.0_05\\bin\\java.exe",
>   "-cp",
>   "C:\\antlr\\antlr-3.4-complete.jar",
>   "org.antlr.Tool",
>   "C:\\Users\\Jason\\Documents\\antlr\\java grammar\\Java.g"],
>stdout=subprocess.PIPE).communicate()

You might also want to try raw strings.  This should be identical to 
Peter's version, but easier to read:

subprocess.Popen([
  r"C:\Program Files (x86)\Java\jdk1.7.0_05\bin\java.exe",
  r"-cp",
  r"C:\antlr\antlr-3.4-complete.jar",
  r"org.antlr.Tool",
  r"C:\Users\Jason\Documents\antlr\java grammar\Java.g"],
   stdout=subprocess.PIPE).communicate()

although I would probably refactor it like:

args = [r"C:\Program Files (x86)\Java\jdk1.7.0_05\bin\java.exe",
r"-cp",
r"C:\antlr\antlr-3.4-complete.jar",
r"org.antlr.Tool",
r"C:\Users\Jason\Documents\antlr\java grammar\Java.g",
   ]
proc = subprocess.Popen(args, stdout=subprocess.PIPE)
proc.communicate()
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A thread import problem

[Bruce Sherwood]

Thanks much for this suggestion. I'm not sure I've correctly
understood the operation "start_new_thread(lambda: __import__(), ())". By "your module" do you mean the user program which
imported the module that will execute start_new_thread? It hadn't
occurred to me to have A import B and B import A, though now that you
describe this (if that's indeed what you mean) it makes sense. The
original instance of A won't get past its initial import statement
because the main loop won't return to it.

Bruce Sherwood

On Sat, Jul 21, 2012 at 2:32 AM, Dieter Maurer  wrote:
> Bruce Sherwood  writes:
>> ...
>> from visual import box, rate
>> b = box()
>> while True:
>> rate(100) # no more than 100 iterations per second
>> b.pos.x += .01
>>
>> This works because a GUI environment is invoked by the visual module
>> in a secondary thread (written mainly in C++, connected to Python by
>> Boost). The OpenGL rendering of the box in its current position is
>> driven by a 30-millisecond timer. This works fine with any environment
>> other than Mac Cocoa.
>>
>> However, the Mac Cocoa GUI environment and interact loop are required
>> to be the primary thread, so the challenge is to have the visual
>> module set up the Cocoa environment, with the user's program running
>> in a secondary thread. Any ideas?
>
> The usual approach to this situation is to invoke the user code via
> a callback from the UI main loop or invoke it explicitely
> after the UI system has been set up immediately before its main loop
> is called. Might look somehow like this:
>
> main thread:
>
> from thread import start_new_thread
> from visual import setup_gui, start_main_loop
> setup_gui() # sets up the GUI subsystem
> start_new_thread(lambda: __import__(), ())
> start_main_loop()
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: can someone teach me this?

[Devin Jeanpierre]

On Fri, Jul 20, 2012 at 11:15 PM, hamilton  wrote:
> You are an idiot, or a scammer.

Please be nice.

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

Re: Calling Java jar class with parameter from Python

[jasonveldicott]

On Saturday, July 21, 2012 5:20:48 AM UTC-7, Peter Otten wrote:
> Jason Veldicott wrote:
> 
> > subprocess.Popen(["C:\\Program Files
> > (x86)\\Java\\jdk1.7.0_05\\bin\\java.exe", "-cp
> > c:\\antlr\\antlr-3.4-complete.jar org.antlr.Tool",
> > "C:\\Users\\Jason\\Documents\\antlr\\java grammar\\Java.g"],
> > stdout=subprocess.PIPE, shell=True ).communicate()
> > 
> > 
> > Obviously, some trick is being missed.  Could anyone shed light on what 
> it
> > may be?
> 
> File names with spaces can be tricky. Try thoroughly separating the 
> individual arguments and let subprocess do the necessary escaping. 
> I think it should be
> 
> subprocess.Popen([
>   "C:\\Program Files (x86)\\Java\\jdk1.7.0_05\\bin\\java.exe",
>   "-cp",
>   "C:\\antlr\\antlr-3.4-complete.jar",
>   "org.antlr.Tool",
>   "C:\\Users\\Jason\\Documents\\antlr\\java grammar\\Java.g"],
>stdout=subprocess.PIPE).communicate()

That did the trick, thanks.  

I had the impression from another post that the breaking up of command strings 
into subprocess arguments could be done arbitrarily as needed to deal with 
nested inverted commas.  Obviously as you've shown, this is not the case, at 
least for Popen.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A thread import problem

[Bruce Sherwood]

I couldn't get a simple test case to work. I append a listing of the
little test files, all in the same folder. The diagnostic statement
print('after start_new_thread\n') works, but then nothing. Originally
I tried importing testABA.py but was worried that the circular
importing (A imports B which imports A) would be a problem, hence the
test of importing a version of the test program without the import.

The failure of this test case suggests that one cannot do imports
inside secondary threads started in imported modules, something I keep
tripping over. But I hope you'll be able to tell me that I'm doing
something wrong!

Incidentally, a simple test is to execute the file ABA.py, in which
case everything works.

Bruce Sherwood

---
testABA.py -- execute this file

from ABA import *
print('exec testABA')
from math import sin
print(sin(3.14159/6))


testABA_noimport.py -- a version of testABA.py without the import of ABA

print('exec testABA_noimport')
from math import sin
print(sin(3.14159/6))

-
ABA.py

from thread import start_new_thread
from time import sleep
import sys

user = 'testABA_noimport'
start_new_thread(lambda: __import__(user), ())
print('after start_new_thread\n')

while True:
sleep(1)

On Sat, Jul 21, 2012 at 2:32 AM, Dieter Maurer  wrote:
> The usual approach to this situation is to invoke the user code via
> a callback from the UI main loop or invoke it explicitely
> after the UI system has been set up immediately before its main loop
> is called. Might look somehow like this:
>
> main thread:
>
> from thread import start_new_thread
> from visual import setup_gui, start_main_loop
> setup_gui() # sets up the GUI subsystem
> start_new_thread(lambda: __import__(), ())
> start_main_loop()
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Newbie question on python programming

[Tom P]

On 07/21/2012 02:30 AM, Ian Kelly wrote:

On Fri, Jul 20, 2012 at 5:38 PM, Chris Williams
 wrote:

Hello

I hope this is the right newsgroup for this post.

I am just starting to learn python programming and it seems very
straightforward so far. It seems, however, geared toward doing the sort of
programming for terminal output.

Is it possible to write the sort of applications you can create in something
like c-sharp or visual c++, or should I be looking at some other programming
language? I am using ubuntu 12.04.


There are plenty of options for GUI programming in Python.  Among the
most popular are Tkinter, wxPython, PyGTK, and PyQT, all of which are
cross-platform and free.  Also, since you specifically mention the
.NET languages, IronPython runs on .NET and so is able to make full
use of the .NET APIs including Windows Forms and WPF.  A more
comprehensive list can be found at:

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



Another platform independent approach is to write the program as a web 
server something like this-

def application(environ, start_response):
start_response("200 OK", [("Content-type", "text/plain")])
return ["Hello World!"]

if __name__ == '__main__':
from wsgiref.simple_server import make_server
server = make_server('localhost', 8080, application)
server.serve_forever()

Run this and then use your browser to connect to localhost:8080
You can then use html features such as forms for input/output.

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

Re: A thread import problem

[Dave Angel]

On 07/21/2012 10:54 AM, Bruce Sherwood wrote:
> Thanks much for this suggestion. I'm not sure I've correctly
> understood the operation "start_new_thread(lambda: __import__( module>), ())". By "your module" do you mean the user program which
> imported the module that will execute start_new_thread? It hadn't
> occurred to me to have A import B and B import A, though now that you
> describe this (if that's indeed what you mean) it makes sense. The
> original instance of A won't get past its initial import statement
> because the main loop won't return to it.
>
> Bruce Sherwood
>

Two of the things you mustn't do during an import:

1) start or end any threads
2) import something that's already in the chain of pending imports. 
(otherwise known as recursive imports, or import loop).  And there's a
special whammy reserved for those who import the script as though it
were a module.

Like any rule, there are possible exceptions.  But you're much better
off factoring your code better.

I haven't managed to understand your software description, so i'm not
making a specific suggestion.  But I know others have pointed out that
you should do as little as possible in top-level code of an imported
module.  Make the work happen in a function, and call that function from
the original script, not from inside some import.  An imported module's
top-level code should do nothing more complex than initialize module
constants.


-- 

DaveA


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

Re: Calling Java jar class with parameter from Python

[jasonveldicott]

On Saturday, July 21, 2012 6:57:48 AM UTC-7, Roy Smith wrote:
> In article ,
>  Peter Otten <__pete...@web.de> wrote:
> 
> > subprocess.Popen([
> >   "C:\\Program Files (x86)\\Java\\jdk1.7.0_05\\bin\\java.exe",
> >   "-cp",
> >   "C:\\antlr\\antlr-3.4-complete.jar",
> >   "org.antlr.Tool",
> >   "C:\\Users\\Jason\\Documents\\antlr\\java grammar\\Java.g"],
> >stdout=subprocess.PIPE).communicate()
> 
> You might also want to try raw strings.  This should be identical to 
> Peter's version, but easier to read:
> 
> subprocess.Popen([
>   r"C:\Program Files (x86)\Java\jdk1.7.0_05\bin\java.exe",
>   r"-cp",
>   r"C:\antlr\antlr-3.4-complete.jar",
>   r"org.antlr.Tool",
>   r"C:\Users\Jason\Documents\antlr\java grammar\Java.g"],
>stdout=subprocess.PIPE).communicate()
> 
> although I would probably refactor it like:
> 
> args = [r"C:\Program Files (x86)\Java\jdk1.7.0_05\bin\java.exe",
> r"-cp",
> r"C:\antlr\antlr-3.4-complete.jar",
> r"org.antlr.Tool",
> r"C:\Users\Jason\Documents\antlr\java grammar\Java.g",
>]
> proc = subprocess.Popen(args, stdout=subprocess.PIPE)
> proc.communicate()

The r string notation at least saves having to double type a bunch of 
backslashes, although the appearance prepended to the string takes a little 
getting used to.

Visually the separate array to handle arguments is perhaps cleaner, having more 
resemblance to the original command.

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

Re: can someone teach me this?

[hamilton]

On 7/21/2012 9:06 AM, Devin Jeanpierre wrote:

On Fri, Jul 20, 2012 at 11:15 PM, hamilton  wrote:

You are an idiot, or a scammer.


Please be nice.

-- Devin


Devin,

When someone asks me to download a compressed file, its just like the 
SCAM junk email I get all too often.


If the OP would learn how to post on usenet, I would have been happy to 
help out.


I apologize to the group, but the OP needs to learn how to post.

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

Re: Sudden doubling of nearly all messages

[Dave Angel]

On 07/21/2012 06:48 AM, Dave Angel wrote:
> Has anybody else noticed the sudden double-posting of nearly all
> messages in the python mailing list?
>
> Previously, I've seen some messages double posted, and it was nearly
> always a newbie, presumably posting via some low-end gateway.  But now
> i'm noticing nearly every message appears twice, identical datestamps,
> and usually one message considered a reply to the other.
>
> Deleting these locally is not only a pain, but if I get the wrong one,
> it messes up the threading.
>
> I'm using Thunderbird 14.0 on Linux 11.04, with mail configured for
> non-digest mode.  I read the messages in threaded mode.
>
> Probably related, I've had a serious spate of messages are obvious Re:
> types, but not threaded to the original set.  I'm guessing because it's
> because I earlier deleted one of a pair.
>

Well, since nobody else (so far) saw it, and I don't see it any more
(except for messages from a relatively few individuals), I'll drop it.

Sorry for the noise.

-- 

DaveA

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

Sudden doubling of nearly all messages

[Sergi Pasoev]

> I'm using Thunderbird 14.0 on Linux 11.04, with mail configured for
> non-digest mode.  I read the messages in threaded mode.

I wonder how many decades should pass for linux to reach its 11.04
version. OK, I know you mean Ubuntu. There is already a lot of wrong use
of names connected to Gnu, Linux, POSIX, etc. Don't make it worse,
please. 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Sudden doubling of nearly all messages

[Rick Johnson]

On Saturday, July 21, 2012 5:48:29 AM UTC-5, Dave Angel wrote:
> Has anybody else noticed the sudden double-posting of nearly all
> messages in the python mailing list?
> 
> Previously, I've seen some messages double posted, and it was nearly
> always a newbie, presumably posting via some low-end gateway.  But now
> i'm noticing nearly every message appears twice, identical datestamps,
> and usually one message considered a reply to the other.

It's due to the new Google Groups interface. They started forcing everyone to 
use the new buggy version about a week ago EVEN THOUGH the old interface is 
just fine. Another bug: If you look at the text i quoted you will see HTML 
character references. Usually i clean the text before posting but sometimes i 
forget.

Google is starting to SUCK!

You know, i really went out of my way to support Google for many years even 
though i knew they were spying on me. But since they were giving me 
"interesting software" for free, i did not mind so much. But now they have 
dropped great software and refuse to maintain the software they do have.

Their online docs were a great idea, but have you ever tried to use the docs 
interface for anything serious? S-U-C-K-S! 

Seriously, i can see Google going the way of yahoo soon. Heck, i even use Bing 
as my search engine now. I MUST be a disgruntled customer if i am using the 
search engine of the evil empire!

It was a nice run Google. We had good times and bad times. A few smiles and 
cries. 

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

Re: ANN: dbf.py 0.94

[Ethan Furman]

Chris Angelico wrote:

On Sat, Jul 21, 2012 at 6:02 PM, Ethan Furman  wrote:

Works with CPython 2.4 - 2.7. (Tested)


Have you considered supporting 3.2/3.3 at all? It's often not
difficult to make your code compatible with both. Or is there some
dependency that is locked to 2.X?


I'll support 3.3+, but not with the same code base:  I want to use all 
the cool features that 3.3 has!  :)


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

Re: Sudden doubling of nearly all messages

[Chris Angelico]

On Sun, Jul 22, 2012 at 4:16 AM, Rick Johnson
 wrote:
> It was a nice run Google. We had good times and bad times. A few smiles and 
> cries.
>
> LMBTFY

So, what... you reckon Microsoft is going to be the paragon of
righteousness against the squalor of Google's information-grubbing
tactics? Fascinating.

Oh, and make sure you get yourself a new email address Rick, can't
have you connected with *Google* mail now can we.

Use whichever service you like, but don't seriously expect anything
that you don't pay money for to be perfectly featured AND not spy on
you.

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

Re: ANN: dbf.py 0.94

[Chris Angelico]

On Sun, Jul 22, 2012 at 4:15 AM, Ethan Furman  wrote:
> I'll support 3.3+, but not with the same code base:  I want to use all the
> cool features that 3.3 has!  :)

The trouble with double-codebasing is that you have double
maintenance. But sure. So long as your time isn't under great
pressure, it can be quite effective.

Recommendation: Figure out a way to minimize double-handling of
things. One way might be to have source control manage it for you -
apply a patch to your 3.3+ source tree, then merge it into your 2.4+
tree and see if it applies cleanly. I dunno how successful that'd be,
but I really dread the idea of maintaining, unassisted, two identical
projects in two dialects of the same language. Recipe for burnout I'd
predict.

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

Re: ANN: dbf.py 0.94

[Matej Cepl]

On 21/07/12 05:26, Ethan Furman wrote:

dbf (also known as python dbase) is a module for reading/writing
dBase III, FP, VFP, and soon Clipper, .dbf database files. It's
an ancient format that still finds lots of use.


Other than the caring for the ancient legacy data, it is still widely 
used in GIS, because shapefiles (http://en.wikipedia.org/wiki/Shapefile) 
are based on it.


Matěj
--
http://mail.python.org/mailman/listinfo/python-list

My first ever Python program, comments welcome

[Lipska the Kat]

Greetings Pythoners

A short while back I posted a message that described a task I had set 
myself. I wanted to implement the following bash shell script in Python


Here's the script

sort -nr $1 | head -${2:-10}

this script takes a filename and an optional number of lines to display
and sorts the lines in numerical order, printing them to standard out.
if no optional number of lines are input the script prints 10 lines

Here's the file.

50  Parrots
12  Storage Jars
6   Lemon Currys
2   Pythons
14  Spam Fritters
23  Flying Circuses
1   Meaning Of Life
123 Holy Grails
76  Secret Policemans Balls
8   Something Completely Differents
12  Lives of Brian
49  Spatulas


... and here's my very first attempt at a Python program
I'd be interested to know what you think, you can't hurt my feelings
just be brutal (but fair). There is very little error checking as you 
can see and I'm sure you can crash the program easily.

'Better' implementations most welcome

#! /usr/bin/env python3.2

import fileinput
from sys import argv
from operator import itemgetter

l=[]
t = tuple
filename=argv[1]
lineCount=10

with fileinput.input(files=(filename)) as f:
for line in f:
t=(line.split('\t'))
t[0]=int(t[0])
l.append(t)
l=sorted(l, key=itemgetter(0))

try:
inCount = int(argv[2])
lineCount = inCount
except IndexError:
#just catch the error and continue  
None

for c in range(lineCount):
t=l[c]
print(t[0], t[1], sep='\t', end='')

Thanks

Lipska


--
Lipska the Kat: Troll hunter, Sandbox destroyer
and Farscape dreamer of Aeryn Sun.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Basic question about speed/coding style/memory

[Thomas 'PointedEars' Lahn]

Jan Riechers wrote:

> I have one very basic question about speed,memory friendly coding, and
> coding style of the following easy "if"-statement in Python 2.7, but Im
> sure its also the same in Python 3.x
> 
> Block
> #--
> if statemente_true:
> doSomething()
> else:
> doSomethingElseInstead()
> 
> #--
> 
> versus this block:
> #--
> if statement_true:
> doSomething()
> return
> 
> doSomethingElseInstead()
> 
> #--
> 
> 
> I understand the first pattern that I tell the interpreter to do:

A common misconception.  As a writer of Python source code, (usually) you 
never tell the (CPython) interpreter anything (but to start working on the 
source code).  Python source code is automatically *compiled* into bytecode 
by the (CPython) interpreter, and that bytecode is executed by a virtual 
machine.¹  So at most, you are telling that virtual machine to do something, 
through the bytecode created from your source code.

> Check if the conditional is true, run "doSomething()" else go inside the
> else block and "doSomethingElseInstead()".
> 
> while the 2nd does only checks:
> doSomething() if statement_true, if not, just go directly to
> "doSomethingElseInstead()
> 
> 
> Now, very briefly, what is the better way to proceed in terms of
> execution speed, readability, coding style?

Since this is comp.lang.python, you just need to check against the Zen of 
Python to know what you should do ;-)



For me, this boils down in this case to the common recommendation "return 
early, return often" as "explicit is better than implicit" and "readability 
counts".  If there is nothing else than the `else' block in the function, 
there is no use for you to continue in the function, so you should return 
explicitly at this point.

On the other hand, if you can *avoid repeating code* in each branch by _not_ 
returning in the first branch, you should do that instead ("practicality 
beats purity").

HTH

_
¹  This is not unlike in other so-called "scripting languages"; although for
   reasons that escape me, the software that compiles the source code – the
   compiler – is called the (C)Python *interpreter*, even in
   .
-- 
PointedEars

Please do not Cc: me. / Bitte keine Kopien per E-Mail.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: My first ever Python program, comments welcome

[Ian Foote]

On 21/07/12 20:08, Lipska the Kat wrote:

Greetings Pythoners

A short while back I posted a message that described a task I had set 
myself. I wanted to implement the following bash shell script in Python


Here's the script

sort -nr $1 | head -${2:-10}

this script takes a filename and an optional number of lines to display
and sorts the lines in numerical order, printing them to standard out.
if no optional number of lines are input the script prints 10 lines

Here's the file.

50Parrots
12Storage Jars
6Lemon Currys
2Pythons
14Spam Fritters
23Flying Circuses
1Meaning Of Life
123Holy Grails
76Secret Policemans Balls
8Something Completely Differents
12Lives of Brian
49Spatulas


... and here's my very first attempt at a Python program
I'd be interested to know what you think, you can't hurt my feelings
just be brutal (but fair). There is very little error checking as you 
can see and I'm sure you can crash the program easily.

'Better' implementations most welcome

#! /usr/bin/env python3.2

import fileinput
from sys import argv
from operator import itemgetter

l=[]
t = tuple
What is this line supposed to do? If you're trying to make an empty 
tuple, you can write:

t = ()
But I don't think this is needed at all.

filename=argv[1]
lineCount=10

with fileinput.input(files=(filename)) as f:
for line in f:
t=(line.split('\t'))
t[0]=int(t[0])
l.append(t)
l=sorted(l, key=itemgetter(0))

try:
inCount = int(argv[2])
lineCount = inCount

I don't think you need to split this into two lines here.
try:
lineCount = int(argv[2])
should work.

except IndexError:
#just catch the error and continue
None
I would use pass instead of None here - I want to "do nothing" rather 
than create a None object.

for c in range(lineCount):
t=l[c]
print(t[0], t[1], sep='\t', end='')

Thanks

Lipska



My only other point is that you might find it helpful to use slightly 
more verbose names than l or t - its not immediately obvious to the 
reader what these are intended to represent.


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

Re: My first ever Python program, comments welcome

[MRAB]

On 21/07/2012 20:08, Lipska the Kat wrote:

Greetings Pythoners

A short while back I posted a message that described a task I had set
myself. I wanted to implement the following bash shell script in Python

Here's the script

sort -nr $1 | head -${2:-10}

this script takes a filename and an optional number of lines to display
and sorts the lines in numerical order, printing them to standard out.
if no optional number of lines are input the script prints 10 lines

Here's the file.

50  Parrots
12  Storage Jars
6   Lemon Currys
2   Pythons
14  Spam Fritters
23  Flying Circuses
1   Meaning Of Life
123 Holy Grails
76  Secret Policemans Balls
8   Something Completely Differents
12  Lives of Brian
49  Spatulas


... and here's my very first attempt at a Python program
I'd be interested to know what you think, you can't hurt my feelings
just be brutal (but fair). There is very little error checking as you
can see and I'm sure you can crash the program easily.
'Better' implementations most welcome

#! /usr/bin/env python3.2

import fileinput
from sys import argv
from operator import itemgetter

l=[]
t = tuple

What's the purpose of this line?


filename=argv[1]
lineCount=10

with fileinput.input(files=(filename)) as f:
for line in f:
t=(line.split('\t'))
t[0]=int(t[0])
l.append(t)
l=sorted(l, key=itemgetter(0))

Short is:

l.sort(key=itemgetter(0))



try:
inCount = int(argv[2])
lineCount = inCount

You may as well say:

lineCount = int(argv[2])


except IndexError:
#just catch the error and continue  
None

The do-nothing statement is:

pass



for c in range(lineCount):
t=l[c]

If there are fewer than 'lineCount' lines, this will raise IndexError.
You could do this instead:

for t in l[ : lineCount]:


print(t[0], t[1], sep='\t', end='')



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

Re: My first ever Python program, comments welcome

[Dave Angel]

On 07/21/2012 03:08 PM, Lipska the Kat wrote:
> Greetings Pythoners
>
> A short while back I posted a message that described a task I had set
> myself. I wanted to implement the following bash shell script in Python
>

You already have comments from Ian and MRAB, and I'll try to point out
only things that they did not.

Congratulations on getting your first program running.  And when reading
the following, remember that getting it right is more important than
getting it pretty.

> Here's the script
>
> sort -nr $1 | head -${2:-10}
>
> this script takes a filename and an optional number of lines to display
> and sorts the lines in numerical order, printing them to standard out.
> if no optional number of lines are input the script prints 10 lines
>
> Here's the file.
>
> 50Parrots
> 12Storage Jars
> 6Lemon Currys
> 2Pythons
> 14Spam Fritters
> 23Flying Circuses
> 1Meaning Of Life
> 123Holy Grails
> 76Secret Policemans Balls
> 8Something Completely Differents
> 12Lives of Brian
> 49Spatulas
>
>
> ... and here's my very first attempt at a Python program
> I'd be interested to know what you think, you can't hurt my feelings
> just be brutal (but fair). There is very little error checking as you
> can see and I'm sure you can crash the program easily.
> 'Better' implementations most welcome
>
> #! /usr/bin/env python3.2
>
> import fileinput
> from sys import argv
> from operator import itemgetter
>
> l=[]

I prefer to initialize an empty collection just before the loop that's
going to fill it.  Then if you later decide to generalize some other
part of the code, it's less likely to break.  So i'd move this line to
right-before the for loop.

> t = tuple

Even if you were going to use this initialization later, it doesn't do
what you think it does.  It doesn't create a tuple, it just makes
another reference to the class.  If you had wanted an empty tuple, you
should either do  t=tuple(), or better  t=()

> filename=argv[1]
> lineCount=10
>

I'd suggest getting into the habit of doing all your argv parsing in one
place.  So check for argv[2] here, rather than inside the loop below. 
Eventually you're going to have code complex enough to use an argument
parsing library.  And of course, something to tell your use what the
arguments are supposed to be.

> with fileinput.input(files=(filename)) as f:

fileinput is much more general than you want for processing a single
file.  That may be deliberate, if you're picturing somebody using
wildcards on their input.  But if so, you should probably use a
different name, something that indicates plural.

> for line in f:
> t=(line.split('\t'))
> t[0]=int(t[0])
> l.append(t)


> l=sorted(l, key=itemgetter(0))
>

Your sample data has duplicate numbers.  So you really ought to decide
how you'd like such lines sorted in the output.  Your present code
simply preserves the present order of such lines.  But if you remove the
key parameter entirely, the default sort order will sort with t[0] as
primary key, and t[1] as tie-breaker.  That'd probably be what I'd do,
after trying to clarify with the client what the desired sort order was.

> try:   
> inCount = int(argv[2])
> lineCount = inCount
> except IndexError:
> #just catch the error and continue   
> None
>
> for c in range(lineCount):
> t=l[c]
> print(t[0], t[1], sep='\t', end='')
>
> Thanks
>
> Lipska
>
>

A totally off-the-wall query.  Are you using a source control system,
such as git ?  It can make you much braver about refactoring a working
program.

-- 

DaveA

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

Re: A thread import problem

[Bruce Sherwood]

Thanks much for this clear statement. I hadn't managed to find any
documentation on this specific issue.

Bruce Sherwood

On Sat, Jul 21, 2012 at 10:26 AM, Dave Angel  wrote:
> Two of the things you mustn't do during an import:
>
> 1) start or end any threads
> 2) import something that's already in the chain of pending imports.
> (otherwise known as recursive imports, or import loop).  And there's a
> special whammy reserved for those who import the script as though it
> were a module.
>
> Like any rule, there are possible exceptions.  But you're much better
> off factoring your code better.
>
> I haven't managed to understand your software description, so i'm not
> making a specific suggestion.  But I know others have pointed out that
> you should do as little as possible in top-level code of an imported
> module.  Make the work happen in a function, and call that function from
> the original script, not from inside some import.  An imported module's
> top-level code should do nothing more complex than initialize module
> constants.
>
>
> --
>
> DaveA
>
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A thread import problem

[Dave Angel]

On 07/21/2012 04:36 PM, Bruce Sherwood wrote:
> Thanks much for this clear statement. I hadn't managed to find any
> documentation on this specific issue.
>
> Bruce Sherwood
>
> On Sat, Jul 21, 2012 at 10:26 AM, Dave Angel  wrote:
>> Two of the things you mustn't do during an import:
>>
>> 1) start or end any threads
>> 2) import something that's already in the chain of pending imports.
>> (otherwise known as recursive imports, or import loop).  And there's a
>> special whammy reserved for those who import the script as though it
>> were a module.
>>
>> Like any rule, there are possible exceptions.  But you're much better
>> off factoring your code better.
>>
>> I haven't managed to understand your software description, so i'm not
>> making a specific suggestion.  But I know others have pointed out that
>> you should do as little as possible in top-level code of an imported
>> module.  Make the work happen in a function, and call that function from
>> the original script, not from inside some import.  An imported module's
>> top-level code should do nothing more complex than initialize module
>> constants.
>>
>>
>> --
>>
>> DaveA
>>
>>

(You top-posted, which makes it harder to figure out who said what.)

For docs on the threading thing, see:

http://docs.python.org/library/threading.html

" ... an import should not have the side effect of spawning a new thread
and then waiting for that thread in any way..."




-- 

DaveA

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

Re: ANN: dbf.py 0.94

[Alex Strickland]

Hi


Getting closer to a stable release.

Latest version has a simpler, cleaner API, and works on PyPy (and
hopefully the other implementations as well ;), as well as CPython.

Get your copy at http://python.org/pypi/dbf.

Bug reports, comments, and kudos welcome!  ;)


"Not supported: index files":

I have been using http://sourceforge.net/projects/harbour-project/ for 
years where a guy called Przemyslaw Czerpak has written an absolutely 
bullet proof implementation of NTX and CDX for DBF. Maybe it will 
interest you.


PS : bareable is spelt bearable.

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

Re: Encapsulation, inheritance and polymorphism

[Erik Max Francis]

On 07/20/2012 02:05 AM, Virgil Stokes wrote:

On 20-Jul-2012 10:27, Steven D'Aprano wrote:

The fellow looked relived and said "Oh thank god, I thought you said
*million*!"


How does this relate to the python list?


It's also a seriously old joke.

--
Erik Max Francis && m...@alcyone.com && http://www.alcyone.com/max/
 San Jose, CA, USA && 37 18 N 121 57 W && AIM/Y!M/Jabber erikmaxfrancis
  She's your moon, she's your sun / She could even be the one
   -- Nik Kershaw
--
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Erik Max Francis]

On 07/20/2012 03:28 AM, BartC wrote:

"Erik Max Francis"  wrote in message
news:gskdnwoqpkoovztnnz2dnuvz5s2dn...@giganews.com...

On 07/20/2012 01:11 AM, Steven D'Aprano wrote:

On Thu, 19 Jul 2012 13:50:36 -0500, Tim Chase wrote:



I'm reminded of Graham's Number, which is so large that there aren't
enough molecules in the universe to write it out as a power tower
a^b^c^d^..., or even in a tower of hyperpowers a^^b^^c^^d^^... It was
the
provable upper bound to a question to which experts in the field thought
the most likely answer was ... six.

(The bounds have since been reduced: the lower bound is now 13, and the
upper bound is *much* smaller than Graham's Number but still
inconceivably ginormous.)


You don't even need to go that high. Even a run-of-the-mill googol
(10^100) is far larger than the total number of elementary particles in
the observable Universe.


But you can write it down, even as a straightforward number, without any
problem. Perhaps a googolplex (10^10^100 iirc) would be difficult to
write it down in full, but I have just represented it as an exponent
with little difficulty.

These bigger numbers can't be written down, because there will never be
enough material, even using multiple systems of exponents.


But that's true for precisely the same reason as what I said.  If you're 
going to write a number down in standard format (whatever the base), 
then the number of digits needed scales as the logarithm of the number 
(again, whatever the base).  log_10 10^100 is trivially 100, so a rough 
order of magnitude in that form is easy to write down.  But the log_10 
10^10^100 is 10^100 = a googol, which is already more than the number of 
elementary particles in the observable Universe.



(A few years ago the biggest number I'd heard of was Skewes' Number
(something like 10^10^10^34), but even that is trivial to write using
conventional exponents as I've just shown. Graham's Number is in a
different
class altogether.)


Anything's trivial to "write down."  Just say "the number such that ..." 
and you've written it down.  Even "numbers" that aren't really numbers, 
such as transfinite cardinals!


--
Erik Max Francis && m...@alcyone.com && http://www.alcyone.com/max/
 San Jose, CA, USA && 37 18 N 121 57 W && AIM/Y!M/Jabber erikmaxfrancis
  She's your moon, she's your sun / She could even be the one
   -- Nik Kershaw
--
http://mail.python.org/mailman/listinfo/python-list

Re: A thread import problem

[Bruce Sherwood]

On Sat, Jul 21, 2012 at 2:53 PM, Dave Angel  wrote:
> On 07/21/2012 04:36 PM, Bruce Sherwood wrote:
>> Thanks much for this clear statement. I hadn't managed to find any
>> documentation on this specific issue.
>>
>> Bruce Sherwood
>>
>> On Sat, Jul 21, 2012 at 10:26 AM, Dave Angel  wrote:
>>> Two of the things you mustn't do during an import:
>>>
>>> 1) start or end any threads
>>> 2) import something that's already in the chain of pending imports.
>>> (otherwise known as recursive imports, or import loop).  And there's a
>>> special whammy reserved for those who import the script as though it
>>> were a module.
>>>
>>> Like any rule, there are possible exceptions.  But you're much better
>>> off factoring your code better.
>>>
>>> I haven't managed to understand your software description, so i'm not
>>> making a specific suggestion.  But I know others have pointed out that
>>> you should do as little as possible in top-level code of an imported
>>> module.  Make the work happen in a function, and call that function from
>>> the original script, not from inside some import.  An imported module's
>>> top-level code should do nothing more complex than initialize module
>>> constants.
>>>
>>>
>>> --
>>>
>>> DaveA
>>>
>>>
>
> (You top-posted, which makes it harder to figure out who said what.)
>
> For docs on the threading thing, see:
>
> http://docs.python.org/library/threading.html
>
> " ... an import should not have the side effect of spawning a new thread
> and then waiting for that thread in any way..."
>
>
>
>
> --
>
> DaveA
>

Thanks. I had read that as forbidding "waiting for that thread", not
forbidding spawning a new thread. The following sentence says,
"Failing to abide by this restriction can lead to a deadlock if the
spawned thread directly or indirectly attempts to import a module." I
gather that a clearer, more forceful statement might be, "Failing to
abide by this restriction WILL lead to a deadlock if the spawned
thread directly or indirectly attempts to import a module." All of
which implies the behavior I've seen in various experiments, namely
that as long as the spawned thread doesn't do any imports, I haven't
seen any problems with spawning a thread in an imported module. I take
your word for it that this is a no-no, but I don't know why.

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

Re: ANN: dbf.py 0.94

[Mark Lawrence]

On 21/07/2012 21:57, Alex Strickland wrote:

Hi


Getting closer to a stable release.

Latest version has a simpler, cleaner API, and works on PyPy (and
hopefully the other implementations as well ;), as well as CPython.

Get your copy at http://python.org/pypi/dbf.

Bug reports, comments, and kudos welcome!  ;)


"Not supported: index files":

I have been using http://sourceforge.net/projects/harbour-project/ for
years where a guy called Przemyslaw Czerpak has written an absolutely
bullet proof implementation of NTX and CDX for DBF. Maybe it will
interest you.

PS : bareable is spelt bearable.



and PS is spelt p.s. :)

--
Cheers.

Mark Lawrence.

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

Re: A thread import problem

[Dave Angel]

On 07/21/2012 05:35 PM, Bruce Sherwood wrote:
> On Sat, Jul 21, 2012 at 2:53 PM, Dave Angel  wrote:
>> 
>> For docs on the threading thing, see:
>>
>> http://docs.python.org/library/threading.html
>>
>> " ... an import should not have the side effect of spawning a new thread
>> and then waiting for that thread in any way..."
>>
>>
>>
>>
>> --
>>
>> DaveA
>>
> Thanks. I had read that as forbidding "waiting for that thread", not
> forbidding spawning a new thread. The following sentence says,
> "Failing to abide by this restriction can lead to a deadlock if the
> spawned thread directly or indirectly attempts to import a module." I
> gather that a clearer, more forceful statement might be, "Failing to
> abide by this restriction WILL lead to a deadlock if the spawned
> thread directly or indirectly attempts to import a module." All of
> which implies the behavior I've seen in various experiments, namely
> that as long as the spawned thread doesn't do any imports, I haven't
> seen any problems with spawning a thread in an imported module. I take
> your word for it that this is a no-no, but I don't know why.
>
> Bruce Sherwood

I don't know just what will work and what will not;   But there are lots
of subtle and indirect ways of "waiting for that thread" and I suspect
that import is one of them.

Since I've never seen a case where we had to break the general rule, it
just seems easier to keep it clean.  No threading inside an import.

Same with recursive imports.  I could list some of the specific problems
that crop up, but since the only time recursive imports are unavoidable
is when you're constrained by preexisting 3rd party software that does
something strange, it seems easier to make a simple rule that's easy
enough to test for.

if you try to import the script (that imported you) as though it were a
module, you end up with two copies of that module, and if they have any
non-constant globals, you can get very strange symptoms.  In other
recursion cases,

-- 

DaveA

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

Re: Sudden doubling of nearly all messages

[Devin Jeanpierre]

On Sat, Jul 21, 2012 at 2:25 PM, Chris Angelico  wrote:
> On Sun, Jul 22, 2012 at 4:16 AM, Rick Johnson
>  wrote:
>> It was a nice run Google. We had good times and bad times. A few smiles and 
>> cries.
>>
>> LMBTFY
>
> So, what... you reckon Microsoft is going to be the paragon of
> righteousness against the squalor of Google's information-grubbing
> tactics? Fascinating.

It's happened before. The example that made me really realize this was
when my university, the University of Toronto, was considering both
Microsoft and Google as mail providers for students last year. They
chose Microsoft, to a mass of student responses to the effect of "but
Microsoft is Evil!". It turns out that they ended up choosing
Microsoft because they gave stronger privacy guarantees.

People hold grudges against MS too strongly, and they believe too much
in Google's righteousness. They are both big companies that don't
necessarily care about you.

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

Re: A thread import problem

[Bruce Sherwood]

On Sat, Jul 21, 2012 at 4:16 PM, Dennis Lee Bieber
 wrote:
> On Sat, 21 Jul 2012 10:11:30 -0600, Bruce Sherwood
>  declaimed the following in
> gmane.comp.python.general:
>
>
>>
>> ---
>> testABA.py -- execute this file
>>
>> from ABA import *
>> print('exec testABA')
>> from math import sin
>> print(sin(3.14159/6))
>>
>> 
>> testABA_noimport.py -- a version of testABA.py without the import of ABA
>>
>> print('exec testABA_noimport')
>> from math import sin
>> print(sin(3.14159/6))
>>
>> -
>> ABA.py
>>
>> from thread import start_new_thread
>> from time import sleep
>> import sys
>>
>> user = 'testABA_noimport'
>> start_new_thread(lambda: __import__(user), ())
>> print('after start_new_thread\n')
>>
>> while True:
>> sleep(1)
>>
>
> And all along you are still coding where imported modules are doing
> work DURING THE IMPORT. Anything beyond initializing module level
> constants or importing modules needed by the module should be placed
> into a function which can be executed by the top-level importer AFTER
> the import has finished.
>
> -=-=-=-=- testABA.py
> print ("testABA: top")
>
> from math import sin, pi
> import time
>
> print ("testABA: defining worker function")
> def runner():   #this is the key -- a function IN the module
> #that does the real work
> print ("testABA.runner: starting work\n")
> time.sleep(2.5)
> print (sin(pi))
> time.sleep(2.5)
> print ("\ntestABA.runner: end of work")
>
> print ("testABA: after set-up")
>
> if __name__ == "__main__":
> print ("testABA: was not an import, running main task")
> runner()#invoke the function if module is not imported
> print ("testABA: end")
> -=-=-=-=-
>
> -=-=-=-=- ABA.py
> import threading
>
> USER = "testABA"
>
> print ("ABA: importing " + USER)
> modl = __import__(USER)
>
> print ("ABA: starting runner")
> th = threading.Thread(target=modl.runner)
> th.start()
>
> print ("ABA: waiting for completion")
> th.join()
>
> print ("ABA: done")
> -=-=-=-=-
>
> And showing the results...
>
> -=-=-=-=-
> E:\UserData\Wulfraed\My Documents\Python Progs>testABA
> testABA: top
> testABA: defining worker function
> testABA: after set-up
> testABA: was not an import, running main task
> testABA.runner: starting work
>
> 1.22460635382e-016
>
> testABA.runner: end of work
> testABA: end
>
> E:\UserData\Wulfraed\My Documents\Python Progs>ABA
> ABA: importing testABA
> testABA: top
> testABA: defining worker function
> testABA: after set-up
> ABA: starting runner
> testABA.runner: starting work
>
> ABA: waiting for completion
> 1.22460635382e-016
>
> testABA.runner: end of work
> ABA: done
> -=-=-=-=-
>
> Note that "testABA.py" is designed to be used as a stand-alone
> program, but is also designed to be imported where all the real work is
> done from a function that is NOT run during the import. The program that
> imports "testABA" is then responsible for actually starting the worker.
>
> I put the sleeps into testABA.runner() so that you can see that the
> main process isn't blocked (note the "ABA: waiting..." output)
>
>
> --
> Wulfraed Dennis Lee Bieber AF6VN
> wlfr...@ix.netcom.comHTTP://wlfraed.home.netcom.com/
>
> --
> http://mail.python.org/mailman/listinfo/python-list

Thanks, but the problem I need to solve does not permit putting a
function like runner in the main program. I'm constrained to being
able to handle the API of VPython (vpython.org), which lets you write
programs like the following (call it user.py), which animates a 3D
cube moving to the right, using OpenGL:

from visual import box
b = box()
while True:
b.pos.x += 0.001

In VPython at present, the visual module sets up (using C++ and Boost)
a secondary thread that periodically updates the 3D scene using the
current objects and their attributes, and handles events. On the Mac
this is done with Carbon, which is dying, so I need to base VPython on
the Mac on Cocoa, for which the interact loop must be in the primary
thread. Hence my need to turn the architecture inside out while
nevertheless handling the existing API.

The cleanest scheme is to have the user's program user.py import a
module "visual" that spawns a new process, "python visual2.py
user.py", where visual2.py reads the source from user.py, comments out
the "import visual", and exec's this modified source in a secondary
thread. This works because visual2.py is now the main module.
Unfortunately, if user.py is run from IDLE, print output goes to a
terminal window rather than to the IDLE shell window, and I don't know
how to direct the output to that shell window.

For this reason I've been experimenting with other schemes, and it
took a while to understand that a thread spawned in an imported module
cannot do imports. I've even managed to carry out a real kludge of
executing imports found in user.py at the top level of v

Re: Sudden doubling of nearly all messages

[Chris Angelico]

On Sun, Jul 22, 2012 at 9:07 AM, Devin Jeanpierre
 wrote:
> People hold grudges against MS too strongly, and they believe too much
> in Google's righteousness. They are both big companies that don't
> necessarily care about you.

Just to clarify, I'm not advocating the "Google is perfect" stance
either; in both cases you're looking at a huge company and a
zero-dollar service. That means you're completely at their mercy in
terms of feature support, and you're most likely going to have your
information harvested as a means of spamming you with ads.

And as you can see from the headers, I use gmail too. I'm fully aware
that they're scanning my emails to target the ads I see; it doesn't
bother me. I have another email address at a domain that I own, with
the mail server being an actual computer that I own, and Google's
welcome to read through all my mailing list posts.

It'd be no different if python.org provided their own free-to-use
webmail service. I'd be assuming you guys are targeting me with ads,
and it wouldn't bother me. :)

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

Re: Sudden doubling of nearly all messages

[Steven D'Aprano]

On Sat, 21 Jul 2012 06:48:29 -0400, Dave Angel wrote:

> Has anybody else noticed the sudden double-posting of nearly all
> messages in the python mailing list?

No I have not.

It sounds like a problem with your Usenet provider. Remember that this 
news group is a mirror of the mailing list python-list@python.org so you 
can check the mail archives to see if the problem is there. It is also 
mirrored by gmane (I *think* it is gmane.comp.python.general).


> Previously, I've seen some messages double posted, and it was nearly
> always a newbie, presumably posting via some low-end gateway.

Some people also annoyingly send to both the newsgroup *and* the mailing 
list, not realising -- or not caring -- that they are the same thing.



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

Re: Sudden doubling of nearly all messages

[Steven D'Aprano]

On Sat, 21 Jul 2012 19:07:28 -0400, Devin Jeanpierre wrote:


> People hold grudges against MS too strongly, and they believe too much
> in Google's righteousness. They are both big companies that don't
> necessarily care about you.

+1

Google's motto "Don't be evil" should really be, "Don't be evil unless 
there's a lot of money in it".

I personally know a couple of people working for Google, and their famed 
geek-friendly work environment is not all it is cracked up to be either.

I think the IT world is better now than it was 10 years ago, because an 
industry dominated by three big, competing entities who hate each other 
(Microsoft, Apple, Google) is better than a monopoly of one (Microsoft). 
But we, the users and consumers, should never make the mistake of 
thinking that *any* of the three have our best interests at heart.


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

Re: Sudden doubling of nearly all messages

[Dave Angel]

On 07/21/2012 08:13 PM, Steven D'Aprano wrote:
> On Sat, 21 Jul 2012 06:48:29 -0400, Dave Angel wrote:
>
>> Has anybody else noticed the sudden double-posting of nearly all
>> messages in the python mailing list?
> No I have not.
>
> It sounds like a problem with your Usenet provider. Remember that this 
> news group is a mirror of the mailing list python-list@python.org so you 
> can check the mail archives to see if the problem is there. It is also 
> mirrored by gmane (I *think* it is gmane.comp.python.general).
>

I don't have a usenet provider, I use the straight email, collected as
regular email, by Thunderbird.  I thought for a while that perhaps my
imap provider had hiccupped, and just reloaded all the same messages. 
But it happened in several sessions, and for the messages I checked, the
emails were *NOT* identical.

>> Previously, I've seen some messages double posted, and it was nearly
>> always a newbie, presumably posting via some low-end gateway.
> Some people also annoyingly send to both the newsgroup *and* the mailing 
> list, not realising -- or not caring -- that they are the same thing.
>
>
>
That may be because many other messages (including this one from you)
list the newsgroup in the headers, so a reply-all generates it as one of
the recipients.  The only reason I don't fall into that trap is that I
have Thunderbird configured to *not* send to any newsgroup.



-- 

DaveA

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

Re: My first ever Python program, comments welcome

[Steven D'Aprano]

On Sat, 21 Jul 2012 20:40:46 +0100, MRAB wrote:

> On 21/07/2012 20:08, Lipska the Kat wrote:
>>  l=sorted(l, key=itemgetter(0))
>
> Short is:
> 
>  l.sort(key=itemgetter(0))

Shorter, and the semantics are subtly different.

The sorted function returns a copy of the input list.

The list.sort method sorts the list in place.



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

Re: Sudden doubling of nearly all messages

[Chris Angelico]

On Sun, Jul 22, 2012 at 10:20 AM, Steven D'Aprano
 wrote:
> On Sun, 22 Jul 2012 04:25:21 +1000, Chris Angelico wrote:
>
>> Use whichever service you like, but don't seriously expect anything that
>> you don't pay money for to be perfectly featured AND not spy on you.
>
> http://duckduckgo.com/privacy.html

They go for privacy at the cost of everything else, and that's fine.
But you still can't depend on its featureset. With a mailing list /
newsgroup reader, there's a whole lot of little things that you'd
probably like, but you can't depend on it; such things cost money, and
most companies that give you stuff that cost money without charging
you money are going to be selling ad space, ergo the temptation to
harvest information about you.

But as I said, I don't care. Google doesn't get any information about
me that I'm not willing for them to get. Let 'em show me ads. And
sometimes they're even useful!

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

Re: My first ever Python program, comments welcome

[Steven D'Aprano]

On Sat, 21 Jul 2012 16:10:51 -0400, Dave Angel wrote:

>> with fileinput.input(files=(filename)) as f:
> 
> fileinput is much more general than you want for processing a single
> file.  That may be deliberate, if you're picturing somebody using
> wildcards on their input.  But if so, you should probably use a
> different name, something that indicates plural.

Also, fileinput is more a convenience module than a serious production 
quality tool. It works, it does the job, but it can be slow. From the 
source:

Performance: this module is unfortunately one of the slower ways of
processing large numbers of input lines.


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

Re: Basic question about speed/coding style/memory

[Devin Jeanpierre]

On Sat, Jul 21, 2012 at 5:06 AM, Steven D'Aprano
 wrote:
> So there is approximately 0.03 second difference per TWO MILLION
> if...else blocks, or about 15 nanoseconds each. This is highly unlikely
> to be the bottleneck in your code. Assuming the difference is real, and
> not just measurement error, the difference is insignificant.

It's probably real. For if-else, the true case needs to make a jump
before it returns, but for if-return, there's no jump and the return
is inlined.

-- Devin

> So, don't worry about which is faster. Write whichever is more natural,
> easier to read and write.

The most important advice. Even when it's a larger difference! :)

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

Re: Sudden doubling of nearly all messages

[Rick Johnson]

On Saturday, July 21, 2012 6:16:24 PM UTC-5, Chris Angelico wrote:

> Just to clarify, I'm not advocating the 
[...snip...]

Well. Well. Backpedaling AND brown-nosing in a single post. Nice!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Sudden doubling of nearly all messages

[Chris Angelico]

On Sun, Jul 22, 2012 at 11:33 AM, Rick Johnson
 wrote:
> On Saturday, July 21, 2012 6:16:24 PM UTC-5, Chris Angelico wrote:
>
>> Just to clarify, I'm not advocating the
> [...snip...]
>
> Well. Well. Backpedaling AND brown-nosing in a single post. Nice!

Absolutely. Haven't you noticed that I'm one of those mad people who
goes everywhere in reverse? My backpedal is saying the exact same
thing as my frontpedal!

Curiouser and curiouser...

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

Re: My first ever Python program, comments welcome

[MRAB]

On 22/07/2012 01:32, Steven D'Aprano wrote:

On Sat, 21 Jul 2012 20:40:46 +0100, MRAB wrote:


On 21/07/2012 20:08, Lipska the Kat wrote:

l=sorted(l, key=itemgetter(0))


Short is:

 l.sort(key=itemgetter(0))


Shorter, and the semantics are subtly different.

The sorted function returns a copy of the input list.

The list.sort method sorts the list in place.


Since the result is bound to the original name, the
result is the same.

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

Re: My first ever Python program, comments welcome

[Chris Angelico]

On Sun, Jul 22, 2012 at 11:56 AM, MRAB  wrote:
> Since the result is bound to the original name, the
> result is the same.

Yes, assuming there are no other refs.

>>> a=[3,2,1]
>>> b=a
>>> a=sorted(a)
>>> a
[1, 2, 3]
>>> b
[3, 2, 1]

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

Re: My first ever Python program, comments welcome

[Dave Angel]

On 07/21/2012 09:56 PM, MRAB wrote:
> On 22/07/2012 01:32, Steven D'Aprano wrote:
>> On Sat, 21 Jul 2012 20:40:46 +0100, MRAB wrote:
>>
>>> On 21/07/2012 20:08, Lipska the Kat wrote:
 l=sorted(l, key=itemgetter(0))
>>>
>>> Short is:
>>>
>>>  l.sort(key=itemgetter(0))
>>
>> Shorter, and the semantics are subtly different.
>>
>> The sorted function returns a copy of the input list.
>>
>> The list.sort method sorts the list in place.
>>
> Since the result is bound to the original name, the
> result is the same.
>

In this particular program, yes.  But if there's another variable bound
to the same list, then the fact that there's a new object from sorted()
makes a difference.



-- 

DaveA

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

Re: ANN: dbf.py 0.94

[Ethan Furman]

Alex Strickland wrote:

Hi


Getting closer to a stable release.

Latest version has a simpler, cleaner API, and works on PyPy (and
hopefully the other implementations as well ;), as well as CPython.

Get your copy at http://python.org/pypi/dbf.

Bug reports, comments, and kudos welcome!  ;)


"Not supported: index files":

I have been using http://sourceforge.net/projects/harbour-project/ for 
years where a guy called Przemyslaw Czerpak has written an absolutely 
bullet proof implementation of NTX and CDX for DBF. Maybe it will 
interest you.


I'll check it out, thanks!


PS : bareable is spelt bearable.


I wondered about that.  :/

~Ethan~

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

Re: My first ever Python program, comments welcome

[rusi]

On Jul 22, 1:10 am, Dave Angel  wrote:

> A totally off-the-wall query.  Are you using a source control system,
> such as git ?  It can make you much braver about refactoring a working
> program.

Question in a similar vein: What development environment do you use?
My impression is that the majority of pythonistas use a non-ide editor
like vi or emacs
Ive been using emacs for 20 years and python-mode of emacs is very
useful but I am increasingly concerned that emacs is refusing to move
with the times.

Which is why I am particularly curious how an ol Java-head finds
eclipse+python (http://pydev.org/ )
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A thread import problem

[Dieter Maurer]

Bruce Sherwood  writes:

> Thanks much for this suggestion. I'm not sure I've correctly
> understood the operation "start_new_thread(lambda: __import__( module>), ())". By "your module" do you mean the user program which
> imported the module that will execute start_new_thread?

By "your_module", I meant what you have called "user.py" elsewhere
in this thread -- the thing that does the animation.

Of course, my suggestion implies that "visual.py" is somewhat changed.
It is supposed to no longer set up the GUI environment automatically
but do so only when its "setup_gui" function is called, and starting
the GUI main loop, too, is no longer automatic but explicite.

> It hadn't
> occurred to me to have A import B and B import A, though now that you
> describe this (if that's indeed what you mean) it makes sense.

I do not propose to do that -- it can lead to problems.

In my proposal, you have two modules: one the "main" module which
sets up the GUI environment, starts the animation in a separate thread
and then activate the GUI main loop. The second module contains
the code you have shown in a previous message.

Of course, the second module can be eliminated by putting its content
into a function and then calling this function in the "start_new_thread"
(instead of "lambda: __import__(...)").

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

Re: A thread import problem

[Dieter Maurer]

Bruce Sherwood  writes:
> ...
> The failure of this test case suggests that one cannot do imports
> inside secondary threads started in imported modules, something I keep
> tripping over. But I hope you'll be able to tell me that I'm doing
> something wrong!

As you know multiple threads can be dangerous when they concurrently
change common data structures. Locks are used to protect those
data structures. Locking can introduce other problems - like deadlocks
(something you seem to observe).

I have not looked at the concrete implementation. However, the Python
documentation suggests that the import machinery uses its own locks
(beside the "Global Interpreter Lock"). It seems to be a "thread lock",
which would mean that a thread is not blocked when it already
holds the lock - however any other thread would block.
This easily can lead to a deadlock -- when you wait for the other
thread "in any way".

There should be no problem when you complete the whole import chain
without any waiting for the thread. However, should you start
the GUI main loop inside the import chain, you will never complete
this chain.

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

Re: Sudden doubling of nearly all messages

[Dieter Maurer]

Dave Angel  writes:

> Has anybody else noticed the sudden double-posting of nearly all
> messages in the python mailing list?

I am reading this list via "gmane" and do not see any double postings.

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