ANN: PyGUI 2.3.2
PyGUI 2.3.2 is available: http://www.cosc.canterbury.ac.nz/greg.ewing/python_gui/ This version fixes a problem in Cocoa whereby the coordinate system for drawing in a Pixmap was upside down, and corrects a slight mistake in the Canvas documentation. What is PyGUI? -- PyGUI is a cross-platform GUI toolkit designed to be lightweight and have a highly Pythonic API. -- Gregory Ewing greg.ew...@canterbury.ac.nz http://www.cosc.canterbury.ac.nz/greg.ewing/ -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/
ANN: Shed Skin 0.7
Hi all, I have just released Shed Skin 0.7, an optimizing (restricted-)Python-to-C++ compiler. It comes with lots of minor fixes and some optimizations, a new Windows package (which includes GCC 4.5), and two nice new examples, for a total of 52 examples at around 14,000 lines (sloccount). Please see my blog for the full announcement: http://shed-skin.blogspot.com Or go straight to the homepage: http://shedskin.googlecode.com Please have a look at the tutorial, try it out, and report issues at the homepage. Thanks, Mark Dufour -- http://www.youtube.com/watch?v=E6LsfnBmdnk -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/
Re: Dealing with pywin32 on Linux
On 15/12/2010 16:54, Stefan Sonnenberg-Carstens wrote: snip Just change to LDAP as authentication method. Even Active Directory offers LDAP (w/o SSL), and there are modules to interact with LDAP using python. And, it is platform indipendent. See here: http://www.python-ldap.org/ I've done this quite often to auth users in an AD with apache/ldap-auth. I've already ported some code yesterday with python-ldap. It works so it's fine for now, Regards, Benedict -- http://mail.python.org/mailman/listinfo/python-list
Re: O'Reilly Python Certification
Can someone provide any links or any starting points on how to apply and what are the prerequisites Thanks, Nitin On Thu, Dec 16, 2010 at 12:18 PM, Steve Holden st...@holdenweb.com wrote: On 12/15/2010 4:21 PM, Stefan Sonnenberg-Carstens wrote: Am 15.12.2010 22:11, schrieb Steve Holden: On 12/15/2010 3:40 PM, Tim Chase wrote: On a more serious note, it would be interesting to know if it's possible to test out of the certification for those of us that have been using Python for a long time. That's an interesting idea - let a bunch of experienced Python users tell me what a lousy job I have done of explaining the language. :) Seriously, I would be interested, and it's a terrific idea. I can't do anything before January, but if anyone is interested in taking part in such a review of the materials I'd be grateful if they would contact me privately by email on a no promises basis. regards Steve I think he meant: take the test without study first. I'd be interested in both, though. There isn't a test. The award of the certificate is based on providing working solutions to projects at the end of each lesson. Bear in mind I have not spoken to my O'Reilly contacts about whether they would be OK with such a scheme, hence the no promises. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 PyCon 2011 Atlanta March 9-17 http://us.pycon.org/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/ -- http://mail.python.org/mailman/listinfo/python-list -- Nitin Pawar -- http://mail.python.org/mailman/listinfo/python-list
Re: Added Python, WSGI to XAMPP
From: Ian Kelly ian.g.ke...@gmail.com On Mon, Dec 13, 2010 at 5:58 PM, Gerry Reno gr...@verizon.net wrote: The VIEW is the bits that stream out of the webserver back to the users browser. Why only to the user's browser? A web app could also offer the results in formats that can be accessed with something else than a browser. The view just offer the results, no matter what way. The CONTROLLER is the code that gathers all the pieces from the model and constructs the python code that is then fed to the engine that then creates the view. And just because the controller navigates the logic to dynamically contruct/render a view, that does not make 'it' the view. In traditional MVC, the controller is the part that receives the user input, decides how to react to it, and instructs the model to update itself accordingly. It is not supposed to be some sort of intermediary between the model and the view, as many people seem to make it; the view is supposed to gather the data it needs to render itself directly from the model. How can the view know what data it should render if the controller doesn't inform it about it? It is less important if the view uses a smart templating system that doesn't need to ask the controller for data but can access the model directly, but the view or that templating system need to be informed by the controller what data need to ask from the model, so we can say that the intermediary is still the controller. And accessing the model directly from the view/templating system is not a good idea, because MVC is also prefered because it decouples the programming code and the web design, and in some cases it can be a security issue if the web designer that might not know programming would be able to change by mistake or with intention the code from the view/templating system that access the model. In that light, I think that this quote from the Django FAQ is defensible: In our interpretation of MVC, the “view” describes the data that gets presented to the user. It’s not necessarily how the data looks, but which data is presented. The view describes which data you see, not how you see it. It’s a subtle distinction. But if the view doesn't decide how the data looks, who decide it? :-) Traditionally, the view would describe both of these things, but since how you see it is ultimately decided by the user's browser, they are fundamentally separated in the context of the web. The Django template-view split is in recognition of this fact. The same data can have any format that's not decided by the user browser. For example it can be displayed in .csv format, or .xls, or .xlsx, or .pdf, or .html, or it can be submitted by email, or sent to Twitter or another web site... As for where the controller went, there are basically two decisions that need to be made when input is received: how to update the model as a result, and what data should be displayed next. The former decision belongs to the controller, the latter to the view. The update of the model depends on the model and the display of results depends on the view. But the decision is controlled by the... controller. That's why it has that name, because it controls these things. Of course, the frontiers between the M and V and C might be subtle in some cases, but it is a good idea to push as much logic to the base. It is not a good idea to make the controller do the job of the model and imply in the business logic or make the view do the job of the controller and do something else than just present the data it receives. But in a web app, these two things tend to be highly correlated, and there seems to be little reason to separate them out into distinct components. This part then is both controller and view, and which word we use for it is not terribly important. Yes, but in that case such a program wouldn't use the MVC model. And as I exemplified above, there are reasons why the view should only present the data it receives and don't access the model directly. Some web developers aren't even alowed to offer the ORM objects to the templates, although the coding would be much easier that way, but need to generate other objects in the controller that don't allow the web designers to change some things in the templates and access more data from the database than it is needed. For these reasons, I find that in practice traditional MVC does not lend itself well to the HTTP request/response cycle, where the view as you define it has no access to the model and lacks any continuity whatsoever from one request to the next; but the Django MTV approach works just fine once you're willing to accept that it's not the same thing. Cheers, Ian There is no traditional MVC. There is just MVC or not MVC. The view shouldn't have any kind of continuity. The view should just present the data. HTTP is a stateless protocol and the controller that handles the requests,
Re: while True or while 1
Steve Holden st...@holdenweb.com wrote in message news:mailman.462.1292214062.2649.python-l...@python.org... On 12/12/2010 2:32 PM, Christian Heimes wrote: Am 12.12.2010 19:31, schrieb Steve Holden: $ python -m timeit -n20 -- i = 0 while 1: i+=1 if i == 100: break 20 loops, best of 3: 89.7 msec per loop $ python -m timeit -n20 -- i = 0 while True: i+=1 if i == 100: break 20 loops, best of 3: 117 msec per loop No argue with that! I was merely making a point that while 1 executes different byte code than while True. Readability is important but sometimes speed is of the essence. while 1 is one of the few tricks to speed up tight loops a bit. OK, but the figures you quote save you 27.3 ms per million iterations, for a grand total saving of 27.3 ns per iteration. So a bit is hardly worth considering for most programs, is it? One these is 30% faster than the other. That's an appreciable difference, which you can't really just dismiss. And you can't tell what the overall effect on a program will be: perhaps the loop will be in a library function , which might be called billions of times. -- Bartc -- http://mail.python.org/mailman/listinfo/python-list
string identity and comparison
Fellows,
I'd like to illutrate the fact that comparing strings using identity is,
most of the time, a bad idea. However I'm searching a short example of
code that yields 2 differents object for the same string content.
id('foo')
3082385472L
id('foo')
3082385472L
Anyone has that kind of code ?
JM
--
http://mail.python.org/mailman/listinfo/python-list
Re: string identity and comparison
On Thursday, December 16, 2010 7:55:20 AM UTC-4, jeanmichel wrote:
Fellows,
I'd like to illutrate the fact that comparing strings using identity is,
most of the time, a bad idea. However I'm searching a short example of
code that yields 2 differents object for the same string content.
id('foo')
3082385472L
id('foo')
3082385472L
Anyone has that kind of code ?
JM
How about this:
Python 2.6 (trunk:66714:66715M, Oct 1 2008, 18:36:04)
[GCC 4.0.1 (Apple Computer, Inc. build 5370)] on darwin
Type help, copyright, credits or license for more information.
a = 'spam'
b = 'spa'
c = a[:-1]
c
'spa'
id(c)
548256
id(b)
548224
Or, even more simply, this:
Jython 2.5.0 (Release_2_5_0:6476, Jun 16 2009, 13:33:26)
[Java HotSpot(TM) Client VM (Apple Inc.)] on java1.5.0_26
Type help, copyright, credits or license for more information.
a = 'foo'
b = 'foo'
id(a)
1
id(b)
2
Reusing immutable objects, for the sake of efficiency, is an implementation
details which should not be relied upon (as you know since you ask for
examples).
André
--
http://mail.python.org/mailman/listinfo/python-list
Re: string identity and comparison
On 16 déc, 12:55, Jean-Michel Pichavant jeanmic...@sequans.com
wrote:
Fellows,
I'd like to illutrate the fact that comparing strings using identity is,
most of the time, a bad idea. However I'm searching a short example of
code that yields 2 differents object for the same string content.
id('foo')
3082385472L
id('foo')
3082385472L
Anyone has that kind of code ?
2 points:
1- an id is only valid for the lifetime of a given object - when the
object has been collected, the id can be reused for another object.
2- in CPython, strings that would be valid Python identifiers are
interned. Try using a string that would not be a valid Python
identifier
Python 2.6.2 (release26-maint, Apr 19 2009, 01:56:41)
[GCC 4.3.3] on linux2
Type help, copyright, credits or license for more information.
id(Not a valid python identifier)
3076522016L
id(Not a valid python identifier)
3076522016L
s1 = Not a valid python identifier
s2 = Not a valid python identifier
s1 is s2
False
s1 == s2
True
HTH
--
http://mail.python.org/mailman/listinfo/python-list
Re: Calling function from another module
craf wrote:
Hi.
The query code is as follows:
--
import Tkinter
import tkMessageBox
class App:
def __init__(self, master):
master.protocol(WM_DELETE_WINDOW,quit)
def quit():
if tkMessageBox.askyesno('','Exit'):
master.quit()
master =Tkinter.Tk()
app = App(master)
master.mainloop()
---
As you can see, when I run and close the main window displays
a text box asking if you want to quit, if so, closes
application.
Question:
Is it possible to define the quit() function in another separate
module?.
I tried it, but it throws the error that the global name
'master' is not defined.
You can have the modules import each other and then access the master as
module.master where you'd have to replace module with the actual name of
the module, but that's a bad design because
(1) you create an import circle
(2) functions relying on global variables already are a bad idea
Your other option is to pass 'master' explicitly and then wrap it into a
lambda function (or functools.partial):
$ cat tkquitlib.py
import tkMessageBox
def quit(master):
if tkMessageBox.askyesno('','Exit'):
master.quit()
$ cat tkquit_main.py
import Tkinter
import tkquitlib
class App:
def __init__(self, master):
master.protocol(WM_DELETE_WINDOW, lambda: tkquitlib.quit(master))
master = Tkinter.Tk()
app = App(master)
master.mainloop()
Peter
--
http://mail.python.org/mailman/listinfo/python-list
Re: while True or while 1
On 12/16/2010 5:44 AM, BartC wrote: On 12/12/2010 2:32 PM, Christian Heimes wrote: Am 12.12.2010 19:31, schrieb Steve Holden: $ python -m timeit -n20 -- i = 0 while 1: i+=1 if i == 100: break 20 loops, best of 3: 89.7 msec per loop $ python -m timeit -n20 -- i = 0 while True: i+=1 if i == 100: break 20 loops, best of 3: 117 msec per loop No argue with that! I was merely making a point that while 1 executes different byte code than while True. Readability is important but sometimes speed is of the essence. while 1 is one of the few tricks to speed up tight loops a bit. OK, but the figures you quote save you 27.3 ms per million iterations, for a grand total saving of 27.3 ns per iteration. So a bit is hardly worth considering for most programs, is it? One these is 30% faster than the other. That's an appreciable difference, which you can't really just dismiss. And you can't tell what the overall effect on a program will be: perhaps the loop will be in a library function , which might be called billions of times. It might. But if the code it is calling does *anything* at all significant I can promise you that spending an extra 30% purely on the looping construct will still make a negligible difference to a program's execution time, and there are almost certainly going to be many other aspects of performance that will yield greater benefits from tuning. I realise that there are going to be some people who just flatly say since 'while 1:' is quicker I am going to use it every time, and that their programs will still work. And I still maintain that (for English speakers) while True: is to be preferred. shol...@lifeboy ~ $ python -m timeit -- i = 1 while True: i += 1 if i == 100: break 10 loops, best of 3: 157 msec per loop shol...@lifeboy ~ $ python -m timeit -- i = 1 while True: i += 1 if i == 100: break x = i+1 10 loops, best of 3: 238 msec per loop shol...@lifeboy ~ $ python -m timeit -- i = 1 while 1: i += 1 if i == 100: break 10 loops, best of 3: 116 msec per loop shol...@lifeboy ~ $ python -m timeit -- i = 1 while 1: i += 1 if i == 100: break x = i+1 10 loops, best of 3: 195 msec per loop If binding a simple arithmetic expression adds more to the loop than the difference between while 1: and while True: you are wasting your time thinking about the savings under all but the most rigorous circumstances. Fortunately there is no penalty for ignoring my advice. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 PyCon 2011 Atlanta March 9-17 http://us.pycon.org/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: string identity and comparison
On 12/16/2010 6:55 AM, Jean-Michel Pichavant wrote:
Fellows,
I'd like to illutrate the fact that comparing strings using identity is,
most of the time, a bad idea. However I'm searching a short example of
code that yields 2 differents object for the same string content.
id('foo')
3082385472L
id('foo')
3082385472L
Anyone has that kind of code ?
JM
id(foo)
2146743808
id (f+o+o)
2146744096
regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
PyCon 2011 Atlanta March 9-17 http://us.pycon.org/
See Python Video! http://python.mirocommunity.org/
Holden Web LLC http://www.holdenweb.com/
--
http://mail.python.org/mailman/listinfo/python-list
[Fwd: Re: Calling function from another module]
- Mensaje reenviado
De: Peter Otten __pete...@web.de
Para: python-list@python.org
Asunto: Re: Calling function from another module
Fecha: Thu, 16 Dec 2010 13:16:30 +0100
Grupos de noticias: comp.lang.python
craf wrote:
Hi.
The query code is as follows:
--
import Tkinter
import tkMessageBox
class App:
def __init__(self, master):
master.protocol(WM_DELETE_WINDOW,quit)
def quit():
if tkMessageBox.askyesno('','Exit'):
master.quit()
master =Tkinter.Tk()
app = App(master)
master.mainloop()
---
As you can see, when I run and close the main window displays
a text box asking if you want to quit, if so, closes
application.
Question:
Is it possible to define the quit() function in another separate
module?.
I tried it, but it throws the error that the global name
'master' is not defined.
You can have the modules import each other and then access the master as
module.master where you'd have to replace module with the actual name of
the module, but that's a bad design because
(1) you create an import circle
(2) functions relying on global variables already are a bad idea
Your other option is to pass 'master' explicitly and then wrap it into a
lambda function (or functools.partial):
$ cat tkquitlib.py
import tkMessageBox
def quit(master):
if tkMessageBox.askyesno('','Exit'):
master.quit()
$ cat tkquit_main.py
import Tkinter
import tkquitlib
class App:
def __init__(self, master):
master.protocol(WM_DELETE_WINDOW, lambda: tkquitlib.quit(master))
master = Tkinter.Tk()
app = App(master)
master.mainloop()
Peter
Hi Peter.
¡Right!. Your example can separate the creation of the interface to the
code execution. Thanks for your time.
Regards
Cristian
--
http://mail.python.org/mailman/listinfo/python-list
ANN: Shed Skin 0.7
Hi all, I have just released Shed Skin 0.7, an optimizing (restricted-)Python-to-C++ compiler. It comes with lots of minor fixes and some optimizations, a new Windows package (which includes GCC 4.5), and two nice new examples, for a total of 52 examples at around 14,000 lines (sloccount). Please see my blog for the full announcement: http://shed-skin.blogspot.com Or go straight to the homepage: http://shedskin.googlecode.com Please have a look at the tutorial, try it out, and report issues at the homepage. Thanks, Mark Dufour -- http://www.youtube.com/watch?v=E6LsfnBmdnk -- http://mail.python.org/mailman/listinfo/python-list
Re: string identity and comparison
Steve Holden wrote:
On 12/16/2010 6:55 AM, Jean-Michel Pichavant wrote:
Fellows,
I'd like to illutrate the fact that comparing strings using identity is,
most of the time, a bad idea. However I'm searching a short example of
code that yields 2 differents object for the same string content.
id('foo')
3082385472L
id('foo')
3082385472L
Anyone has that kind of code ?
JM
id(foo)
2146743808
id (f+o+o)
2146744096
Note that the concatenation may be misleading because it's not the direct
reason that the ids differ; the first string doesn't exist anymore when the
second is built, but the memory location of the first foo is occupied
(perhaps by an intermediate string) when the second foo is created. To
illustrate:
id(foo)
14039470912
id(bar)
14039470912
id(foo)
14039470912
x = 1234
id(foo)
14039471008
--
http://mail.python.org/mailman/listinfo/python-list
Re: string identity and comparison
Peter Otten wrote:
Steve Holden wrote:
On 12/16/2010 6:55 AM, Jean-Michel Pichavant wrote:
Fellows,
I'd like to illutrate the fact that comparing strings using identity is,
most of the time, a bad idea. However I'm searching a short example of
code that yields 2 differents object for the same string content.
id('foo')
3082385472L
id('foo')
3082385472L
Anyone has that kind of code ?
JM
id(foo)
2146743808
id (f+o+o)
2146744096
Note that the concatenation may be misleading because it's not the direct
reason that the ids differ; the first string doesn't exist anymore when
the second is built, but the memory location of the first foo is
occupied (perhaps by an intermediate string) when the second foo is
created. To illustrate:
id(foo)
14039470912
id(bar)
14039470912
id(foo)
14039470912
x = 1234
id(foo)
14039471008
Or less convoluted:
foo = f + o + o
foo is foo
True
--
http://mail.python.org/mailman/listinfo/python-list
Re: Extending Thunderbird mail client with Python
John Bond li...@asd-group.com writes: Anyone have any experience with this, ideally using Python 3? I don't but there is a great need to have a working SyncML client for Thunderbird. Funambol used to have one available, but it has crashing problems with Thunderbird 3 for some people. The existing extension was done in C++. -- http://mail.python.org/mailman/listinfo/python-list
Re: string identity and comparison
Jean-Michel Pichavant wrote:
Fellows,
I'd like to illutrate the fact that comparing strings using identity is,
most of the time, a bad idea. However I'm searching a short example of
code that yields 2 differents object for the same string content.
id('foo')
3082385472L
id('foo')
3082385472L
Anyone has that kind of code ?
Currently, CPython interns strings that look like identifiers. Any strings
that don't look like identifiers are on their own:
mwil...@tecumseth:~/sandbox/candlekit/stringlight-1$ python
Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56)
[GCC 4.4.3] on linux2
Type help, copyright, credits or license for more information.
a = 'x(3)'
id(a)
3075373248L
c='x(3)'
id(c)
3075373856L
a==c
True
Mel.
--
http://mail.python.org/mailman/listinfo/python-list
Re: string identity and comparison
Jean-Michel Pichavant wrote:
Fellows,
I'd like to illutrate the fact that comparing strings using identity
is, most of the time, a bad idea. However I'm searching a short
example of code that yields 2 differents object for the same string
content.
id('foo')
3082385472L
id('foo')
3082385472L
Anyone has that kind of code ?
JM
a = 'foo'
b = '%s' % a
a is b
False
Yet another Auto replied thread from myself :-/
JM
--
http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Shed Skin 0.7
Mark, Congratulations on your latest release! How well do python extension modules created with ShedSkin work with applications that expose a GUI, eg. Tkinter or wxPython apps? Can ShedSkin code be run in a thread and communicate with the main interpreter thread through a Queue or Lock? (Or should one use the multiprocessing module?) Thank you, Malcolm -- http://mail.python.org/mailman/listinfo/python-list
Re: string identity and comparison
bruno.desthuilli...@gmail.com wrote:
On 16 déc, 12:55, Jean-Michel Pichavant jeanmic...@sequans.com
wrote:
id('foo')
3082385472L
id('foo')
3082385472L
Anyone has that kind of code ?
2 points:
1- an id is only valid for the lifetime of a given object - when the
object has been collected, the id can be reused for another object.
that's exactly what happened in my example, the 2 'foo' are not the same
object actually, the fact that the 2 successive id() calls return the
same value is implementation specific.
Thanks for pointing that out, I didn't realize in the first place.
JM
--
http://mail.python.org/mailman/listinfo/python-list
Re: string identity and comparison
Mel wrote:
Jean-Michel Pichavant wrote:
Fellows,
I'd like to illutrate the fact that comparing strings using identity is,
most of the time, a bad idea. However I'm searching a short example of
code that yields 2 differents object for the same string content.
id('foo')
3082385472L
id('foo')
3082385472L
Anyone has that kind of code ?
Currently, CPython interns strings that look like identifiers. Any strings
that don't look like identifiers are on their own:
mwil...@tecumseth:~/sandbox/candlekit/stringlight-1$ python
Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56)
[GCC 4.4.3] on linux2
Type help, copyright, credits or license for more information.
a = 'x(3)'
id(a)
3075373248L
c='x(3)'
id(c)
3075373856L
a==c
True
Mel.
thanks to all who replied.
It looks like there are some differences between python 2.5 2.6, I
tested all the possibilities I've been given in this thread and did not
always get the same result.
Anyway I found what I was looking for.
JM
--
http://mail.python.org/mailman/listinfo/python-list
Re: How to pop the interpreter's stack?
Tim Arnold wrote: Ethan Furman et...@stoneleaf.us wrote in message news:mailman.4.1292379995.6505.python-l...@python.org... kj wrote: The one thing I don't like about this strategy is that the tracebacks of exceptions raised during the execution of __pre_spam include one unwanted stack level (namely, the one corresponding to __pre_spam itself). __pre_spam should be completely invisible and unobtrusive I am unaware of any way to accomplish what you desire. I also think this is one of those things that's not worth fighting -- how often are you going to see such a traceback? When somebody makes a coding mistake? I would say change the name (assuming yours was a real example) to something more meaningful like _spam_arg_verifier and call it good. Alternatively, perhaps you could make a more general arg_verifier that could be used for all such needs, and then your traceback would have: caller spam arg_verifier and that seems useful to me (it is, in fact, how I have mine set up). Hope this helps! ~Ethan~ I thought people would advise using a decorator for this one. Wouldn't that work? thanks, --Tim A decorator was one of the items kj explicity didn't want. Also, while it would have a shallower traceback for exceptions raised during the __pre_spam portion, any exceptions raised during spam itself would then be one level deeper than desired... while that could be masked by catching and (re-?)raising the exception in the decorator, Steven had a very good point about why that is a bad idea -- namely, tracebacks shouldn't lie about where the error is. ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list
Re: while True or while 1
BartC wrote: Steve Holden st...@holdenweb.com wrote in message news:mailman.462.1292214062.2649.python-l...@python.org... On 12/12/2010 2:32 PM, Christian Heimes wrote: Am 12.12.2010 19:31, schrieb Steve Holden: $ python -m timeit -n20 -- i = 0 while 1: i+=1 if i == 100: break 20 loops, best of 3: 89.7 msec per loop $ python -m timeit -n20 -- i = 0 while True: i+=1 if i == 100: break 20 loops, best of 3: 117 msec per loop No argue with that! I was merely making a point that while 1 executes different byte code than while True. Readability is important but sometimes speed is of the essence. while 1 is one of the few tricks to speed up tight loops a bit. OK, but the figures you quote save you 27.3 ms per million iterations, for a grand total saving of 27.3 ns per iteration. So a bit is hardly worth considering for most programs, is it? One these is 30% faster than the other. That's an appreciable difference, which you can't really just dismiss. Anecdotal evidence says it is easily dismissed: I had a routine that processed records from a table using custom, on the fly, code. I could either use exec for each record to do the work, or create a function that would then be called. I timed exec vs function, and found the function style to be about 200% faster... Eureka!, I thought. After putting the functional method in place, a run that took about 16 minutes using the old exec method ran two (2!) seconds faster. Great learning experience, for both the function method (which I prefer), and the need for profiling. ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list
Re: O'Reilly Python Certification
Please don't top-post. :) Nitin Pawar wrote: Can someone provide any links or any starting points on how to apply and what are the prerequisites http://www.oreillyschool.com/certificates/python-programming.php No prerequisites that I could see, and currently they are running a 25% discount promotional. ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list
Re: string identity and comparison
On 16 déc, 15:52, Jean-Michel Pichavant jeanmic...@sequans.com
wrote:
bruno.desthuilli...@gmail.com wrote:
On 16 d c, 12:55, Jean-Michel Pichavant jeanmic...@sequans.com
wrote:
id('foo')
3082385472L
id('foo')
3082385472L
Anyone has that kind of code ?
2 points:
1- an id is only valid for the lifetime of a given object - when the
object has been collected, the id can be reused for another object.
that's exactly what happened in my example, the 2 'foo' are not the same
object actually, the fact that the 2 successive id() calls return the
same value is implementation specific.
Thanks for pointing that out, I didn't realize in the first place.
been here, done that :-/
--
http://mail.python.org/mailman/listinfo/python-list
Re: string identity and comparison
On 16 déc, 15:53, Jean-Michel Pichavant jeanmic...@sequans.com
wrote:
Mel wrote:
Jean-Michel Pichavant wrote:
Fellows,
I'd like to illutrate the fact that comparing strings using identity is,
most of the time, a bad idea. However I'm searching a short example of
code that yields 2 differents object for the same string content.
id('foo')
3082385472L
id('foo')
3082385472L
Anyone has that kind of code ?
Currently, CPython interns strings that look like identifiers. Any strings
that don't look like identifiers are on their own:
mwil...@tecumseth:~/sandbox/candlekit/stringlight-1$ python
Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56)
[GCC 4.4.3] on linux2
Type help, copyright, credits or license for more information.
a = 'x(3)'
id(a)
3075373248L
c='x(3)'
id(c)
3075373856L
a==c
True
Mel.
thanks to all who replied.
It looks like there are some differences between python 2.5 2.6, I
tested all the possibilities I've been given in this thread and did not
always get the same result.
Which FWIW is one more reason to avoid identity testing on strings -
too much implementation specific stuff happening here.
--
http://mail.python.org/mailman/listinfo/python-list
Re: How to pop the interpreter's stack?
On Thu, 16 Dec 2010 07:29:25 -0800, Ethan Furman wrote: Tim Arnold wrote: Ethan Furman et...@stoneleaf.us wrote in message news:mailman.4.1292379995.6505.python-l...@python.org... kj wrote: The one thing I don't like about this strategy is that the tracebacks of exceptions raised during the execution of __pre_spam include one unwanted stack level (namely, the one corresponding to __pre_spam itself). [...] A decorator was one of the items kj explicity didn't want. Also, while it would have a shallower traceback for exceptions raised during the __pre_spam portion, any exceptions raised during spam itself would then be one level deeper than desired... while that could be masked by catching and (re-?)raising the exception in the decorator, Steven had a very good point about why that is a bad idea -- namely, tracebacks shouldn't lie about where the error is. True, very true... but many hours later, it suddenly hit me that what KJ was asking for wasn't *necessarily* such a bad idea. My thought is, suppose you have a function spam(x) which raises an exception. If it's a *bug*, then absolutely you need to see exactly where the error occurred, without the traceback being mangled or changed in any way. But what if the exception is deliberate, part of the function's documented behaviour? Then you might want the exception to appear to come from the function spam even if it was actually generated inside some private sub-routine. So, with qualifications, I have half changed my mind. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: How to pop the interpreter's stack?
On 12/16/10 10:23 AM, Steven D'Aprano wrote: On Thu, 16 Dec 2010 07:29:25 -0800, Ethan Furman wrote: Tim Arnold wrote: Ethan Furmanet...@stoneleaf.us wrote in message news:mailman.4.1292379995.6505.python-l...@python.org... kj wrote: The one thing I don't like about this strategy is that the tracebacks of exceptions raised during the execution of __pre_spam include one unwanted stack level (namely, the one corresponding to __pre_spam itself). [...] A decorator was one of the items kj explicity didn't want. Also, while it would have a shallower traceback for exceptions raised during the __pre_spam portion, any exceptions raised during spam itself would then be one level deeper than desired... while that could be masked by catching and (re-?)raising the exception in the decorator, Steven had a very good point about why that is a bad idea -- namely, tracebacks shouldn't lie about where the error is. True, very true... but many hours later, it suddenly hit me that what KJ was asking for wasn't *necessarily* such a bad idea. My thought is, suppose you have a function spam(x) which raises an exception. If it's a *bug*, then absolutely you need to see exactly where the error occurred, without the traceback being mangled or changed in any way. But what if the exception is deliberate, part of the function's documented behaviour? Then you might want the exception to appear to come from the function spam even if it was actually generated inside some private sub-routine. Obfuscating the location that an exception gets raised prevents a lot of debugging (by inspection or by pdb), even if the exception is deliberately raised with an informative error message. Not least, the code that decides to raise that exception may be buggy. But even if the actual error is outside of the function (e.g. the caller is passing bad arguments), you want to at least see what tests the __pre_spam function is doing in order to decide to raise that exception. Tracebacks are inherently over-verbose. This is necessarily true because no algorithm (or clever programmer) can know all the pieces of information that the person debugging may want to know a priori. Most customizations of tracebacks *add* more verbosity rather than reduce it. Removing one stack level from the traceback barely makes the traceback more readable and removes some of the most relevant information. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco -- http://mail.python.org/mailman/listinfo/python-list
ANN: PyGUI 2.3.2
PyGUI 2.3.2 is available: http://www.cosc.canterbury.ac.nz/greg.ewing/python_gui/ This version fixes a problem in Cocoa whereby the coordinate system for drawing in a Pixmap was upside down, and corrects a slight mistake in the Canvas documentation. What is PyGUI? -- PyGUI is a cross-platform GUI toolkit designed to be lightweight and have a highly Pythonic API. -- Gregory Ewing greg.ew...@canterbury.ac.nz http://www.cosc.canterbury.ac.nz/greg.ewing/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Extending Thunderbird mail client with Python
On Nov 11, 11:48 pm, John Bond li...@asd-group.com wrote: Anyone have any experience with this, ideally using Python 3? I'd like to sync my Thunderbird contacts with various things including my mobile phone. Of course, I want to do it with Python! I've seen some stuff around, eg. an XPI that provides Python bindings to the Mozilla XPCOM APIs (through which I imagine you can access Thunderbird data like its contacts database), but it doesn't seem maintained or ported to Python 3. Cheers, JB While this doesn't provide a solution right now...look at https://mozillalabs.com/messaging/thunderbird-contacts/ and the highly experimental-working-but-not-yet-right sync addon for thunderbird (weave-ext and weaver repos) at https://bitbucket.org/mixedpuppy The sync addon is Firefox sync for thunderbird, not an ability to sync to your phone (yet). however, this is all js. shane -- http://mail.python.org/mailman/listinfo/python-list
Re: O'Reilly Python Certification
So how exactly does the class work? Is it like an elementary CS class where you have a teacher, assignments, etc. Or is it more like a guided tour through the O'Reilly Python book/cookbook? On Thu, Dec 16, 2010 at 10:40 AM, Ethan Furman et...@stoneleaf.us wrote: Please don't top-post. :) Nitin Pawar wrote: Can someone provide any links or any starting points on how to apply and what are the prerequisites http://www.oreillyschool.com/certificates/python-programming.php No prerequisites that I could see, and currently they are running a 25% discount promotional. ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: O'Reilly Python Certification
Each lesson required you to complete a practical assignment. You submit these assignments for evaluation, and do not proceed to the next lesson until your assignment reaches a satisfactory standard. Thus, less experienced students will tend to have more interaction with their tutors. A class will typically have between twelve and sixteen lessons. There are also quizzes and a final practical project. regards Steve On 12/16/2010 12:12 PM, Matty Sarro wrote: So how exactly does the class work? Is it like an elementary CS class where you have a teacher, assignments, etc. Or is it more like a guided tour through the O'Reilly Python book/cookbook? On Thu, Dec 16, 2010 at 10:40 AM, Ethan Furman et...@stoneleaf.us wrote: Please don't top-post. :) Nitin Pawar wrote: Can someone provide any links or any starting points on how to apply and what are the prerequisites http://www.oreillyschool.com/certificates/python-programming.php No prerequisites that I could see, and currently they are running a 25% discount promotional. ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list -- Steve Holden +1 571 484 6266 +1 800 494 3119 PyCon 2011 Atlanta March 9-17 http://us.pycon.org/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Python creates locked temp dir
FWIW, I got around the issue with some samba mount options. They still show as 0700, but I, or anybody elsefor that matter, can still access them. Computers are weird. :P Thanks to all who responded. :) On Dec 10, 2:57 pm, Alex Willmer a...@moreati.org.uk wrote: On Dec 8, 6:26 pm, Christian Heimes li...@cheimes.de wrote: There isn't a way to limit access to a single process. mkdtemp creates the directory with mode 0700 and thus limits it to the (effective) user of the current process. Any process of the same user is able to access the directory. Christian Quite right. My apologies for confusing temporary file creation, for which exclusive access is used and temporary directory creation for which there is no such mode. -- http://mail.python.org/mailman/listinfo/python-list
Is text processing with dicts a good use case for Python cross-compilers like Cython/Pyrex or ShedSkin?
Is text processing with dicts a good use case for Python cross-compilers like Cython/Pyrex or ShedSkin? (I've read the cross compiler claims about massive increases in pure numeric performance). I have 3 use cases I'm considering for Python-to-C++ cross-compilers for generating 32-bit Python extension modules for Python 2.7 for Windows. 1. Parsing UTF-8 files (basic Python with lots of string processing and dict lookups) 2. Generating UTF-8 files from nested list/dict structures 3. Parsing large ASCII CSV-like files and using dict's to calculate simple statistics like running totals, min, max, etc. Are any of these text processing scenarios good use cases for tools like Cython, Pyrex, or ShedSkin? Are any of these specifically bad use cases for these tools? We've tried Psyco and it has sped up some of our parsing utilities by 200%. But Psyco doesn't support Python 2.7 yet and we're committed to using Python 2.7 moving forward. Malcolm -- http://mail.python.org/mailman/listinfo/python-list
Re: while True or while 1
Ethan Furman et...@stoneleaf.us writes: ...I timed exec vs function, and found the function style to be about 200% faster... So it finished before it started? -- Arnaud -- http://mail.python.org/mailman/listinfo/python-list
Re: while True or while 1
On 12/16/2010 7:23 AM, Steve Holden wrote: On 12/16/2010 5:44 AM, BartC wrote: One these is 30% faster than the other. That's an appreciable difference, which you can't really just dismiss. And you can't tell what the overall effect on a program will be: perhaps the loop will be in a library function , which might be called billions of times. It might. But if the code it is calling does *anything* at all significant I can promise you that spending an extra 30% purely on the looping construct will still make a negligible difference to a program's execution time, and there are almost certainly going to be many other aspects of performance that will yield greater benefits from tuning. I realise that there are going to be some people who just flatly say since 'while 1:' is quicker I am going to use it every time, and that their programs will still work. And I still maintain that (for English speakers) while True: is to be preferred. shol...@lifeboy ~ $ python -m timeit -- i = 1 while True: i += 1 if i == 100: break 10 loops, best of 3: 157 msec per loop shol...@lifeboy ~ $ python -m timeit -- i = 1 while True: i += 1 if i == 100: break x = i+1 10 loops, best of 3: 238 msec per loop shol...@lifeboy ~ $ python -m timeit -- i = 1 while 1: i += 1 if i == 100: break 10 loops, best of 3: 116 msec per loop shol...@lifeboy ~ $ python -m timeit -- i = 1 while 1: i += 1 if i == 100: break x = i+1 10 loops, best of 3: 195 msec per loop This are all Python2 timings. If binding a simple arithmetic expression adds more to the loop than the difference between while 1: and while True: you are wasting your time thinking about the savings under all but the most rigorous circumstances. *Especially* when the 'problem' has been fixed in Python 3. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Added Python, WSGI to XAMPP
On 12/16/2010 04:36 AM, Octavian Rasnita wrote: From: Ian Kelly ian.g.ke...@gmail.com On Mon, Dec 13, 2010 at 5:58 PM, Gerry Reno gr...@verizon.net wrote: The VIEW is the bits that stream out of the webserver back to the users browser. Why only to the user's browser? A web app could also offer the results in formats that can be accessed with something else than a browser. The view just offer the results, no matter what way. The CONTROLLER is the code that gathers all the pieces from the model and constructs the python code that is then fed to the engine that then creates the view. And just because the controller navigates the logic to dynamically contruct/render a view, that does not make 'it' the view. In traditional MVC, the controller is the part that receives the user input, decides how to react to it, and instructs the model to update itself accordingly. It is not supposed to be some sort of intermediary between the model and the view, as many people seem to make it; the view is supposed to gather the data it needs to render itself directly from the model. How can the view know what data it should render if the controller doesn't inform it about it? It is less important if the view uses a smart templating system that doesn't need to ask the controller for data but can access the model directly, but the view or that templating system need to be informed by the controller what data need to ask from the model, so we can say that the intermediary is still the controller. And accessing the model directly from the view/templating system is not a good idea, because MVC is also prefered because it decouples the programming code and the web design, and in some cases it can be a security issue if the web designer that might not know programming would be able to change by mistake or with intention the code from the view/templating system that access the model. In that light, I think that this quote from the Django FAQ is defensible: In our interpretation of MVC, the “view” describes the data that gets presented to the user. It’s not necessarily how the data looks, but which data is presented. The view describes which data you see, not how you see it. It’s a subtle distinction. But if the view doesn't decide how the data looks, who decide it? :-) Traditionally, the view would describe both of these things, but since how you see it is ultimately decided by the user's browser, they are fundamentally separated in the context of the web. The Django template-view split is in recognition of this fact. The same data can have any format that's not decided by the user browser. For example it can be displayed in .csv format, or .xls, or .xlsx, or .pdf, or .html, or it can be submitted by email, or sent to Twitter or another web site... As for where the controller went, there are basically two decisions that need to be made when input is received: how to update the model as a result, and what data should be displayed next. The former decision belongs to the controller, the latter to the view. The update of the model depends on the model and the display of results depends on the view. But the decision is controlled by the... controller. That's why it has that name, because it controls these things. Of course, the frontiers between the M and V and C might be subtle in some cases, but it is a good idea to push as much logic to the base. It is not a good idea to make the controller do the job of the model and imply in the business logic or make the view do the job of the controller and do something else than just present the data it receives. But in a web app, these two things tend to be highly correlated, and there seems to be little reason to separate them out into distinct components. This part then is both controller and view, and which word we use for it is not terribly important. Yes, but in that case such a program wouldn't use the MVC model. And as I exemplified above, there are reasons why the view should only present the data it receives and don't access the model directly. Some web developers aren't even alowed to offer the ORM objects to the templates, although the coding would be much easier that way, but need to generate other objects in the controller that don't allow the web designers to change some things in the templates and access more data from the database than it is needed. For these reasons, I find that in practice traditional MVC does not lend itself well to the HTTP request/response cycle, where the view as you define it has no access to the model and lacks any continuity whatsoever from one request to the next; but the Django MTV approach works just fine once you're willing to accept that it's not the same thing. Cheers, Ian There is no traditional MVC. There is just MVC or not
Re: while True or while 1
Arnaud Delobelle wrote: Ethan Furman et...@stoneleaf.us writes: ...I timed exec vs function, and found the function style to be about 200% faster... So it finished before it started? Hmmm Let me check my calculator... . . . Ah! Okay, that was 200x faster. :) I think -- it was a few months ago now, and my numbers might be off a bit, but I was definitely impressed with A) how much faster the function style was, and B), how very little time it saved me. ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list
Re: string identity and comparison
Jean-Michel Pichavant jeanmic...@sequans.com writes:
Fellows,
I'd like to illutrate the fact that comparing strings using identity
is, most of the time, a bad idea. However I'm searching a short
example of code that yields 2 differents object for the same string
content.
id('foo')
3082385472L
id('foo')
3082385472L
Anyone has that kind of code ?
JM
Have you tried this?
id(foo)
3078219968L
id(bar)
3078219968L
And this?
id(foo)
3077306560L
n = 42
id(foo)
3077306720L
And this?
a*2 is a*2
True
a*30 is a*30
False
n = 2
a*n is a*n
False
--
Arnaud
--
http://mail.python.org/mailman/listinfo/python-list
pudb on windows (dependent upon unix only termios ?)
Hi - I was just trying to install the Python debugger pudb (http:// pypi.python.org/pypi/pudb) and easy install fell over saying it couldn't find a module termios. It turns out termios is only for Unix (http://docs.python.org/library/ termios.html). Does anyone know of way around this ? Is there an equivalent to termios which would run on windows and which could be hacked into pudb ? Alternatively suggestions for a pudb workalike ? (I like the console/ keyboard centric aspect of pudb). Thanks Richard. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is text processing with dicts a good use case for Python cross-compilers like Cython/Pyrex or ShedSkin?
pyt...@bdurham.com, 16.12.2010 21:03: Is text processing with dicts a good use case for Python cross-compilers like Cython/Pyrex or ShedSkin? (I've read the cross compiler claims about massive increases in pure numeric performance). Cython is generally a good choice for string processing, simply because it can drop a lot of code into plain C, such as character iteration and comparison. Depending on what kind of operations you do, you can get speed-ups of 100x or more for that. http://docs.cython.org/src/tutorial/strings.html However, when it comes to dict lookups, it uses CPython's own dicts which are heavily optimised for string lookups already. So the speedup in that area will likely stay below 30%. Similarly, encoding and decoding use Python's codecs, so don't expect a major difference there. I have 3 use cases I'm considering for Python-to-C++ cross-compilers for generating 32-bit Python extension modules for Python 2.7 for Windows. 1. Parsing UTF-8 files (basic Python with lots of string processing and dict lookups) Parsing sounds like something that could easily benefit from Cython compilation. 2. Generating UTF-8 files from nested list/dict structures That should be much faster in Cython, too, simply because iteration on builtin types is much faster than in Python. 3. Parsing large ASCII CSV-like files and using dict's to calculate simple statistics like running totals, min, max, etc. Again, parsing will be much faster, especially when reading from raw C files (which would also enable freeing the GIL, in case you want to use multi-threading). The rest may not win that much. A nice feature of Cython is that you do not have to go low-level right away. You can use all the niceness of Python, and only push the code closer to C level where your benchmarks point you. And if you really have to go all the way down to C, it's just a declaration away. Are any of these text processing scenarios good use cases for tools like Cython, Pyrex, or ShedSkin? Are any of these specifically bad use cases for these tools? Pyrex isn't worth trying here, simply because you'd have to invest a lot more work to make it as fast as what Cython gives you anyway. ShedSkin may be worth a try, depending on how well you get your ShedSkin module integrated with CPython. (It seems that it has support for building extension modules by now, but I have no idea how well that is fleshed out). We've tried Psyco and it has sped up some of our parsing utilities by 200%. But Psyco doesn't support Python 2.7 yet and we're committed to using Python 2.7 moving forward. If 3x is not enough for you, I strongly suggest you try Cython. The C code that it generates compiles nicely in all major Python versions, currently from 2.3 to 3.2. Stefan -- http://mail.python.org/mailman/listinfo/python-list
If/then style question
(This is mostly a style question, and perhaps one that has already been discussed elsewhere. If so, a pointer to that discussion will be appreciated!) When I started learning Python, I wrote a lot of methods that looked like this: def myMethod(self, arg1, arg2): if some_good_condition: if some_other_good_condition: if yet_another_good_condition: do_some_useful_stuff() exitCode = good1 else: exitCode = bad3 else: exitCode = bad2 else: exitCode = bad1 return exitCode But lately I've been preferring this style: def myMethod(self, arg1, arg2): if some_bad_condition: return bad1 elif some_other_bad_condition: return bad2 elif yet_another_bad_condition: return bad3 do_some_useful_stuff() return good1 I like this style more, mostly because it eliminates a lot of indentation. However I recall one of my college CS courses stating that one entry, one exit was a good way to write code, and this style has lots of exits. Are there any concrete advantages of one style over the other? Thanks. -- John Gordon A is for Amy, who fell down the stairs gor...@panix.com B is for Basil, assaulted by bears -- Edward Gorey, The Gashlycrumb Tinies -- http://mail.python.org/mailman/listinfo/python-list
Re: If/then style question
John Gordon wrote: (This is mostly a style question, and perhaps one that has already been discussed elsewhere. If so, a pointer to that discussion will be appreciated!) When I started learning Python, I wrote a lot of methods that looked like this: def myMethod(self, arg1, arg2): if some_good_condition: if some_other_good_condition: if yet_another_good_condition: do_some_useful_stuff() exitCode = good1 else: exitCode = bad3 else: exitCode = bad2 else: exitCode = bad1 return exitCode But lately I've been preferring this style: def myMethod(self, arg1, arg2): if some_bad_condition: return bad1 elif some_other_bad_condition: return bad2 elif yet_another_bad_condition: return bad3 do_some_useful_stuff() return good1 I like this style more, mostly because it eliminates a lot of indentation. As far as if/else goes, I prefer the second style also. As far as returning bad codes, you are better off raising exceptions: def myMethod(self, arg1, arg2): if some_bad_condition: raise Bad1() elif some_other_bad_condition: raise Bad2() elif yet_another_bad_condition: raise Bad3() do_some_useful_stuff # no need to return 'good' code -- success means no problems ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list
Re: If/then style question
On 2010-12-16, John Gordon gor...@panix.com wrote: I like this style more, mostly because it eliminates a lot of indentation. However I recall one of my college CS courses stating that one entry, one exit was a good way to write code, and this style has lots of exits. So, take the good intentation from one and the single exit from the other: def myMethod(self, arg1, arg2): if some_bad_condition: exitCode = bad1 elif some_other_bad_condition: exitCode = bad2 elif yet_another_bad_condition: exitCode = bad3 else: exitCode = do_some_useful_stuff() # possible common cleanup code here return exitCode Or, raise an exception on bad condtions rather then passing an error code. -- http://mail.python.org/mailman/listinfo/python-list
Re: If/then style question
On 2010-12-16, John Gordon gor...@panix.com wrote: (This is mostly a style question, and perhaps one that has already been discussed elsewhere. If so, a pointer to that discussion will be appreciated!) When I started learning Python, I wrote a lot of methods that looked like this: def myMethod(self, arg1, arg2): if some_good_condition: if some_other_good_condition: if yet_another_good_condition: do_some_useful_stuff() exitCode = good1 else: exitCode = bad3 else: exitCode = bad2 else: exitCode = bad1 return exitCode But lately I've been preferring this style: def myMethod(self, arg1, arg2): if some_bad_condition: return bad1 elif some_other_bad_condition: return bad2 elif yet_another_bad_condition: return bad3 do_some_useful_stuff() return good1 I like this style more, mostly because it eliminates a lot of indentation. There's nothing inherently wrong with indentation, but in this case the latter style is a _lot_ easier to read (and modify without breaking). However I recall one of my college CS courses stating that one entry, one exit was a good way to write code, and this style has lots of exits. Are there any concrete advantages of one style over the other? I think the check/exit style is far more readable. It can trip you up if there is cleanup stuff that needs to happen before you return from the function. In that case putting the whole function in a try statement and raising exceptions for the bad conditions works nicely. Then you get the more readable style of the check/exit style, plus the advantage of a single exit (it's easy to verify visually that all the required cleanup is happening). -- Grant Edwards grant.b.edwardsYow! I want a WESSON OIL at lease!! gmail.com -- http://mail.python.org/mailman/listinfo/python-list
Re: If/then style question
Am 16.12.2010 22:49, schrieb John Gordon: (This is mostly a style question, and perhaps one that has already been discussed elsewhere. If so, a pointer to that discussion will be appreciated!) When I started learning Python, I wrote a lot of methods that looked like this: def myMethod(self, arg1, arg2): if some_good_condition: if some_other_good_condition: if yet_another_good_condition: do_some_useful_stuff() exitCode = good1 else: exitCode = bad3 else: exitCode = bad2 else: exitCode = bad1 return exitCode But lately I've been preferring this style: def myMethod(self, arg1, arg2): if some_bad_condition: return bad1 elif some_other_bad_condition: return bad2 elif yet_another_bad_condition: return bad3 else: do_some_useful_stuff() return good1 I like this style more, mostly because it eliminates a lot of indentation. However I recall one of my college CS courses stating that one entry, one exit was a good way to write code, and this style has lots of exits. Are there any concrete advantages of one style over the other? Thanks. The advantage in latter case is fewer operations, because you can skip the assignments, and it is more readable. The one entry, one exit is an advice. Not a law. Your code is OK. As long as it works ;-) P.S.: Sorry, I could not resist: return bad1 if some_bad_condition else bad2 if some_other_bad_condition else bad3 if yet_another_bad_condition else good1 if do_some_useful_stuff() else good1 Or consider this: return [x for x,y in ((bad1,some_bad_condition),(bad2,some_other_bad_condition),(bad3,yet_another_bad_condition),(good1,do_some_useful_stuff() or True)) if x][0] Neither self explanatory nor readable :-( -- http://mail.python.org/mailman/listinfo/python-list
Re: If/then style question
On Thu, 2010-12-16 at 21:49 +, John Gordon wrote: (This is mostly a style question, and perhaps one that has already been discussed elsewhere. If so, a pointer to that discussion will be appreciated!) When I started learning Python, I wrote a lot of methods that looked like this: def myMethod(self, arg1, arg2): if some_good_condition: if some_other_good_condition: if yet_another_good_condition: do_some_useful_stuff() exitCode = good1 else: exitCode = bad3 else: exitCode = bad2 else: exitCode = bad1 return exitCode But lately I've been preferring this style: def myMethod(self, arg1, arg2): if some_bad_condition: return bad1 elif some_other_bad_condition: return bad2 elif yet_another_bad_condition: return bad3 do_some_useful_stuff() return good1 I like this style more, mostly because it eliminates a lot of indentation. However I recall one of my college CS courses stating that one entry, one exit was a good way to write code, and this style has lots of exits. Are there any concrete advantages of one style over the other? one entry, one exit has its good points, but it's *way* overquoted and overused. Do you raise any exceptions? Do you call any functions that might raise exceptions? If so, you've got multiple exit points already. I think this style a lot more important in a language like C where you have to be super-careful about cleaning up after yourself. The single exit point makes it easier to verify that all cleanup tasks have been performed. Assuming you're using with or try-finally then you just don't need such guarantees in python. I'm not a PEP-8 pedant by any means, but I think that the first section of PEP-8 contains the best advice I've ever read about programming language style. In fact, I'm going to quote it right here: A Foolish Consistency is the Hobgoblin of Little Minds == One of Guido's key insights is that code is read much more often than it is written. The guidelines provided here are intended to improve the readability of code and make it consistent across the wide spectrum of Python code. As PEP 20 says, Readability counts. ...snip... But most importantly: know when to be inconsistent -- sometimes the style guide just doesn't apply. When in doubt, use your best judgment. Look at other examples and decide what looks best. And don't hesitate to ask! In your example, the first style is difficult to read wile the second style is easy to read. You don't need any further justification for preferring the latter. 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
Re: If/then style question
On Thu, Dec 16, 2010 at 3:41 PM, Stefan Sonnenberg-Carstens stefan.sonnenb...@pythonmeister.com wrote: return [x for x,y in ((bad1,some_bad_condition),(bad2,some_other_bad_condition),(bad3,yet_another_bad_condition),(good1,do_some_useful_stuff() or True)) if x][0] This doesn't work. do_some_usefull_stuff() gets called during the tuple construction regardless of the conditions, not during the list comprehension execution as you would want. Here's my take on an unreadable one-liner: return reduce(lambda x, y: (x or (y[0]() and y[1])), [(some_bad_condition, bad1), (some_other_bad_condition, bad2), (yet_another_bad_condition, bad3), (lambda: (do_some_useful_stuff() or True), good1)], None) This of course assumes that bad1, bad2, and bad3 all evaluate as true. Cheers, Ian -- http://mail.python.org/mailman/listinfo/python-list
Re: while True or while 1
Steve Holden st...@holdenweb.com wrote in message news:mailman.54.1292502247.6505.python-l...@python.org... On 12/16/2010 5:44 AM, BartC wrote: One these is 30% faster than the other. That's an appreciable difference, which you can't really just dismiss. shol...@lifeboy ~ $ python -m timeit -- i = 1 while True: i += 1 if i == 100: break 10 loops, best of 3: 157 msec per loop $ python -m timeit -- i = 1 while 1: i += 1 if i == 100: break 10 loops, best of 3: 116 msec per loop I used a single loop counting to 10 million, and the timings were roughly 2.5xx and 1.8xx seconds, on Python 2.5 (1.35 and 1.05 seconds inside a function). In terms of a more realistic function (admittedly still a little contrived, as the loop would be written differently), I tried this: def p2(n): p=1 while True: if n=p: return p p=1 return 0 for i in xrange(100): x=p2(i) p2() calculates the smallest power of 2 = it's operand. Using while True as shown, it took 3.4 seconds. Using While 1, it took 2.6 seconds (Python 2.5). -- Bartc -- http://mail.python.org/mailman/listinfo/python-list
Re: If/then style question
On Thu, 16 Dec 2010 21:49:07 +, John Gordon wrote: (This is mostly a style question, and perhaps one that has already been discussed elsewhere. If so, a pointer to that discussion will be appreciated!) When I started learning Python, I wrote a lot of methods that looked like this: def myMethod(self, arg1, arg2): if some_good_condition: if some_other_good_condition: if yet_another_good_condition: do_some_useful_stuff() exitCode = good1 else: exitCode = bad3 else: exitCode = bad2 else: exitCode = bad1 return exitCode It doesn't look like you were learning Python. It looks like you were learning C with Python syntax :( The above would be more Pythonically written as: def myMethod(self, arg1, arg2): if not some_good_condition: raise SomeException(message) if not some_other_good_condition: raise SomeOtherException(another message) if yet_another_good_condition: do_some_useful_stuff() else: raise SomeThirdException(whatever) using exceptions to communicate errors out-of-band. Since no return result is needed, no explicit return is used and the method is the closest thing to a procedure that Python can offer. The problem with in-band transmission of errors is that they invite the anti-pattern of this: result = obj.myMethod(arg1, arg2) if result == good1: do_something_good() elif result == bad1: handle_error1() elif result == bad2: handle_error2() elif result == bad3(): handle_error3() else: print This can't ever happen, but if it does... which all too often becomes: result = obj.myMethod(arg1, arg2) if result == good1: do_something_good() else: # assume result is bad1 handle_error1() or even: who_cares = obj.myMethod(arg1, arg2) do_something_good() But lately I've been preferring this style: def myMethod(self, arg1, arg2): if some_bad_condition: return bad1 elif some_other_bad_condition: return bad2 elif yet_another_bad_condition: return bad3 do_some_useful_stuff() return good1 I like this style more, mostly because it eliminates a lot of indentation. Well, that's better, but still more like C rather than Python. Avoid the anti-pattern of returning in-band error codes. In some languages, either exceptions aren't available at all, or the overhead of them is so great that for performance you have to avoid them, but Python is not one of those languages. In Python, exceptions are *the* primary way of communicating exceptional cases such as (but not limited to) errors. I can only think of two, er, exceptions to this rule: str.find() and some of the regular expression methods. However I recall one of my college CS courses stating that one entry, one exit was a good way to write code, and this style has lots of exits. Functions always have one entry. The only way to have multiple entry points is if the language allows you to GOTO into the middle of a function, and Python sensibly does not allow this. The one entry, one exit rule comes from the days when people would routinely write spaghetti code, jumping into and out of blocks of code without using functions at all. If one entry is pointless (all functions have one entry!) then one exit is actively harmful. It leads to adding unnecessary complexity to functions, purely to meet the requirements of a rule invented to discourage spaghetti code. This hides bugs and increases the maintenance burden. Don't get me wrong... spaghetti code is *bad*. But there are other ways of writing bad code too, and hanging around inside a function long after you've finished is also bad: def function(arg): done = False do_something() if some_condition: result = finished done = True if not done: do_something_else() if another_condition: result = now we're finished done = True if not done: do_yet_more_work() if third_condition: result = finished this time for sure done = True if not done: for i in range(100): if not done: do_something_small() if yet_another_condition: result = finally done! done = True return result It's far more complicated than it need be, and does *lots* of unnecessary work. This can be written more simply and efficiently as: def function(arg): do_something() if some_condition: return finished do_something_else() if another_condition: return now we're finished do_yet_more_work() if third_condition: return finished this time for sure for i in range(100): do_something_small() if yet_another_condition: return finally done! Over 40% of the code in the first version is
Re: while True or while 1
On Dec 16, 4:34 pm, BartC b...@freeuk.com wrote: def p2(n): p=1 whileTrue: if n=p: return p p=1 return 0 for i in xrange(100): x=p2(i) p2() calculates the smallest power of 2 = it's operand. def p2(n): return 1 n.bit_length() -- http://mail.python.org/mailman/listinfo/python-list
Re: If/then style question
John Gordon gor...@panix.com wrote: But lately I've been preferring this style: def myMethod(self, arg1, arg2): if some_bad_condition: return bad1 elif some_other_bad_condition: return bad2 elif yet_another_bad_condition: return bad3 do_some_useful_stuff() return good1 For more than 2 tests in a function like this, I'd probably use dictionary dispatch: def myMethod(self, arg1, arg2): branches = dict( cond1: bad1, cond2: bad2, cond3: bad3 ) cond = expression if cond == cond_good: do_some_useful_stuff() exitCode = good1 else: exitCode = branches[cond] return exitCode -- http://mail.python.org/mailman/listinfo/python-list
Re: How to pop the interpreter's stack?
On Thu, 16 Dec 2010 10:39:34 -0600, Robert Kern wrote:
On 12/16/10 10:23 AM, Steven D'Aprano wrote:
On Thu, 16 Dec 2010 07:29:25 -0800, Ethan Furman wrote:
Tim Arnold wrote:
Ethan Furmanet...@stoneleaf.us wrote in message
news:mailman.4.1292379995.6505.python-l...@python.org...
kj wrote:
The one thing I don't like about this strategy is that the
tracebacks of exceptions raised during the execution of __pre_spam
include one unwanted stack level (namely, the one corresponding to
__pre_spam itself).
[...]
A decorator was one of the items kj explicity didn't want. Also,
while it would have a shallower traceback for exceptions raised during
the __pre_spam portion, any exceptions raised during spam itself would
then be one level deeper than desired... while that could be masked by
catching and (re-?)raising the exception in the decorator, Steven had
a very good point about why that is a bad idea -- namely, tracebacks
shouldn't lie about where the error is.
True, very true... but many hours later, it suddenly hit me that what
KJ was asking for wasn't *necessarily* such a bad idea. My thought is,
suppose you have a function spam(x) which raises an exception. If it's
a *bug*, then absolutely you need to see exactly where the error
occurred, without the traceback being mangled or changed in any way.
But what if the exception is deliberate, part of the function's
documented behaviour? Then you might want the exception to appear to
come from the function spam even if it was actually generated inside
some private sub-routine.
Obfuscating the location that an exception gets raised prevents a lot of
debugging (by inspection or by pdb), even if the exception is
deliberately raised with an informative error message. Not least, the
code that decides to raise that exception may be buggy. But even if the
actual error is outside of the function (e.g. the caller is passing bad
arguments), you want to at least see what tests the __pre_spam function
is doing in order to decide to raise that exception.
And how do you think you see that from the traceback? The traceback
prints the line which actually raises the exception (and sometimes not
even that!), which is likely to be a raise statement:
import example
example.func(42)
Traceback (most recent call last):
File stdin, line 1, in module
File example.py, line 3, in func
raise ValueError('bad value for x')
ValueError: bad value for x
The actual test is:
def func(x):
if x 10 and x%2 == 0:
raise ValueError('bad value for x')
but you can't get that information from the traceback.
Python's exception system has to handle two different situations: buggy
code, and bad data. It's not even clear whether there is a general
distinction to be made between the two, but even if there's not a general
distinction, there's certainly a distinction which we can *sometimes*
make. If a function contains a bug, we need all the information we can
get, including the exact line that causes the fault. But if the function
deliberately raises an exception due to bad input, we don't need any
information regarding the internals of the function (assuming that the
exception is sufficiently detailed, a big assumption I grant you!). If I
re-wrote the above func() like this:
def func(x):
if !(x = 10):
if x%2 != 0:
pass
else:
raise ValueError('bad value for x')
return
I would have got the same traceback, except the location of the exception
would have been different (line 6, in a nested if-block). To the caller,
whether I had written the first version of func() or the second is
irrelevant. If I had passed the input validation off to a second
function, that too would be irrelevant.
I don't expect Python to magically know whether an exception is a bug or
not, but there's something to be said for the ability to turn Python
functions into black boxes with their internals invisible, like C
functions already are. If (say) math.atan2(y, x) raises an exception, you
have no way of knowing whether atan2 is a single monolithic function, or
whether it is split into multiple pieces. The location of the exception
is invisible to the caller: all you can see is that atan2 raised an
exception.
Tracebacks are inherently over-verbose. This is necessarily true because
no algorithm (or clever programmer) can know all the pieces of
information that the person debugging may want to know a priori. Most
customizations of tracebacks *add* more verbosity rather than reduce it.
Removing one stack level from the traceback barely makes the traceback
more readable and removes some of the most relevant information.
Right. But I have thought of a clever trick to get the result KJ was
asking for, with the minimum of boilerplate code. Instead of this:
def _pre_spam(args):
if condition(args):
raise SomeException(message)
if another_condition(args):
raise
Re: string identity and comparison
On Dec 16, 9:55 pm, Jean-Michel Pichavant jeanmic...@sequans.com wrote: I'd like to illutrate the fact that comparing strings using identity is, most of the time, a bad idea. However I'm searching a short example of code that yields 2 differents object for the same string content. Anyone has that kind of code ? It's quite obvious when they come from different contexts: def f(): return 'some string' ... def g(): return 'some string' ... f() == g() True f() is g() False -- http://mail.python.org/mailman/listinfo/python-list
Re: while True or while 1
On Thu, 16 Dec 2010 23:34:21 +, BartC wrote: In terms of a more realistic function (admittedly still a little contrived, as the loop would be written differently), I tried this: def p2(n): p=1 while True: if n=p: return p p=1 return 0 for i in xrange(100): x=p2(i) p2() calculates the smallest power of 2 = it's operand. Using while True as shown, it took 3.4 seconds. Using While 1, it took 2.6 seconds (Python 2.5). Right. And a saving of 0.8 microseconds per iteration is a micro- optimization which is likely to be invisible in any real situation. I mean, yes, you saved almost an entire second. Wow. Save another 179 of them and you'll almost have enough time to make yourself a coffee. Bart, we get it. Nobody denies that the optimization is real, only that it is generally meaningful. Who cares whether it takes 2 seconds or 4 seconds to generate one million results if the rest of the application takes 3 minutes to run? *If* your application is such that saving 0.8 microseconds per iteration actually is useful, AND your loop has to be written as a while True loop, then this *may* be a useful micro-optimization to save 0.8 microseconds per iteration. That's a vanishingly tiny proportion of all code written. If your code happens to meet those conditions, then by all means use while 1. Or move to Python 3, where while True has the same optimization performed. But in general, such micro-optimizations are not terribly useful. If you shave off 1 second off a program that runs in 3 seconds, chances are nobody is even going to notice. Two seconds or three, who cares? Either way, it's too short to do anything else, and not long enough to matter. If you shave off an hour off a program that takes 20 hours, who is going to care? But so long as it doesn't introduce bugs, or make maintenance harder, or add complexity, such micro-optimizations don't harm either. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Read / Write OpenOffice SpreadSheet ?
Hi, i search for a possibility to access OpenOffoce SpreadSheets from Python with a reasonably new version of Python. Can anybody point me to a package that can do this? Best regards, Torsten. -- http://mail.python.org/mailman/listinfo/python-list
Re: Read / Write OpenOffice SpreadSheet ?
On 12/16/2010 5:07 PM Torsten Mohr said... Hi, i search for a possibility to access OpenOffoce SpreadSheets from Python with a reasonably new version of Python. Can anybody point me to a package that can do this? If you're open to 'saving as xls' then xlrd/xlwt works well. Otherwise, when I last checked in on this about 18 months ago, it appeared that python support in OO never quite got the traction I hoped it might... Emile -- http://mail.python.org/mailman/listinfo/python-list
Re: If/then style question
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote in message news:4d0aa5e7$0$29997$c3e8da3$54964...@news.astraweb.com... It doesn't look like you were learning Python. It looks like you were learning C with Python syntax :( True, although in many cases one has to interface to legacy C code where it'd be rather more code to start throwing exceptions left or right... since sooner or later those exceptions would still have to be turned into a single status (error) code! which all too often becomes: result = obj.myMethod(arg1, arg2) if result == good1: do_something_good() else: # assume result is bad1 handle_error1() This really isn't a bad way to go *if you weren't planning on spending the time to really, fully flesh out the individual error cases anyway.* I see this pretty often: Peple put in sophisticated exception handling infrastructure, but when an error actually occurs, all six dozen cases handled individually end up just printing some generic message and exiting the program anyway. In an ideal world all the error cases would do something smart, but pragmatically one has to balance how likely an error is to occur and how much damage it does with how much time you want to spend making a really smart error handler. or even: who_cares = obj.myMethod(arg1, arg2) do_something_good() Even this can be OK if do_something_good() behaves in a relatively benign fashion when feed gibberish. I mean, how many people actually check to see whether or not printf() succeeded, you know? But I would agree that often you see... who_care = obj.myMethod(arg1, arg2) do_something_really_dangerous_that_depends_on_the_success_of_myMethod() :-) Well, that's better, but still more like C rather than Python. Avoid the anti-pattern of returning in-band error codes. The main sticky point here is that what's an error vs. a warning or note (but not success) is often rather a grey area. E.g., Pyhton's open() raises an IOError is the file can't be opened, but in my mind that's still a common enough/expected occurrence that elevating its behavior to an exception is more a judgement call than something everyone would agree on. (On the other hand, trying to read or write to an un-opened file is now clearly in the realm of an error and deserves an exception.) ---Joel -- http://mail.python.org/mailman/listinfo/python-list
Re: Read / Write OpenOffice SpreadSheet ?
On 2010-12-17, Torsten Mohr tm...@s.netic.de wrote: i search for a possibility to access OpenOffoce SpreadSheets from Python with a reasonably new version of Python. Can anybody point me to a package that can do this? There is no package needed to read or write the new open document files. The files are merely a jar archive containing XML files. You can open and update them using jar as a subprocess and manipulate the XML files using your favorite XML libraries DOM/SAX/XPath/Etree/etc. If that doesn't suit you, you can manipulate them using OO.org through its UNO interface; but, I find that much more involved then simply accessing the files directly. -- http://mail.python.org/mailman/listinfo/python-list
Re: Read / Write OpenOffice SpreadSheet ?
On 12/16/2010 07:53 PM, Tim Harig wrote: On 2010-12-17, Torsten Mohrtm...@s.netic.de wrote: i search for a possibility to access OpenOffoce SpreadSheets from Python with a reasonably new version of Python. Can anybody point me to a package that can do this? There is no package needed to read or write the new open document files. The files are merely a jar archive containing XML files. You can open and update them using jar as a subprocess and manipulate the XML files using your favorite XML libraries DOM/SAX/XPath/Etree/etc. To make that even easier (no need for a subprocess launching a JAR tool), JAR files are just ZIP files (IIRC, they may have some particularly-named files for metadata purposes, but it's all just a big zip-blob), so you can use Python's native zipfile module to crack into it. Then, as TimH suggests, wander around in the XML (and other files) inside. -tkc -- http://mail.python.org/mailman/listinfo/python-list
Re: Read / Write OpenOffice SpreadSheet ?
Torsten Mohr 写入消息 news:ieed6o$iq...@news.lf.net... Hi, i search for a possibility to access OpenOffoce SpreadSheets from Python with a reasonably new version of Python. Can anybody point me to a package that can do this? Best regards, Torsten. --- news://freenews.netfront.net/ - complaints: n...@netfront.net --- -- http://mail.python.org/mailman/listinfo/python-list
Newbie question about importing modules.
Hi I'm starting my first python project but I'm having trouble getting off the ground. I've read all I can find about relative and absolute import paths but it's just not making sense to me... There seems to be around ten different ways to import a script. I need my project to be portable so I can copy the whole folder to run on any PC that has python installed. Is it always possible to simply include modules in the project directory and reference them without installing into the main python directory? I've managed this with small classes through trial and error but when I try it with anything larger (like PIL module for example) I get errors. Do I need to actually install anything or is it enough just to include the relevant scripts? All the modules I've found come with tonnes of files and subdirectories. Do I need all these files or should I just choose the scripts/folders I need? Thanks, cronoklee -- http://mail.python.org/mailman/listinfo/python-list
Re: If/then style question
On Dec 16, 2:56 pm, Ryan Kelly r...@rfk.id.au wrote: On Thu, 2010-12-16 at 21:49 +, John Gordon wrote: (This is mostly a style question, and perhaps one that has already been discussed elsewhere. If so, a pointer to that discussion will be appreciated!) When I started learning Python, I wrote a lot of methods that looked like this: def myMethod(self, arg1, arg2): if some_good_condition: if some_other_good_condition: if yet_another_good_condition: do_some_useful_stuff() exitCode = good1 else: exitCode = bad3 else: exitCode = bad2 else: exitCode = bad1 return exitCode But lately I've been preferring this style: def myMethod(self, arg1, arg2): if some_bad_condition: return bad1 elif some_other_bad_condition: return bad2 elif yet_another_bad_condition: return bad3 do_some_useful_stuff() return good1 I like this style more, mostly because it eliminates a lot of indentation. However I recall one of my college CS courses stating that one entry, one exit was a good way to write code, and this style has lots of exits. Are there any concrete advantages of one style over the other? one entry, one exit has its good points, but it's *way* overquoted and overused. Do you raise any exceptions? Do you call any functions that might raise exceptions? If so, you've got multiple exit points already. I think this style a lot more important in a language like C where you have to be super-careful about cleaning up after yourself. The single exit point makes it easier to verify that all cleanup tasks have been performed. Assuming you're using with or try-finally then you just don't need such guarantees in python. Even without the cleanup issue, sometimes you want to edit a function to affect all return values somehow. If you have a single exit point you just make the change there; if you have mulitple you have to hunt them down and change all of them--if you remember to. I just got bit by that one. It's a trade-off. Readability and/or conciseness versus error robustness. I tend to go for the former but mileage varies. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie question about importing modules.
Hi, cronoklee maybe you should check every module directory you want to import to see if there is a __init__.py in it? missing a __init__.py file would cause error when you try to import the directory as a module. 在 Fri, 17 Dec 2010 11:42:48 +0800，cronoklee cronok...@gmail.com 写道: Hi I'm starting my first python project but I'm having trouble getting off the ground. I've read all I can find about relative and absolute import paths but it's just not making sense to me... There seems to be around ten different ways to import a script. I need my project to be portable so I can copy the whole folder to run on any PC that has python installed. Is it always possible to simply include modules in the project directory and reference them without installing into the main python directory? I've managed this with small classes through trial and error but when I try it with anything larger (like PIL module for example) I get errors. Do I need to actually install anything or is it enough just to include the relevant scripts? All the modules I've found come with tonnes of files and subdirectories. Do I need all these files or should I just choose the scripts/folders I need? Thanks, cronoklee -- 使用 Opera 革命性的电子邮件客户程序: http://www.opera.com/mail/ -- http://mail.python.org/mailman/listinfo/python-list
Re: If/then style question
On 12/16/2010 11:32 PM, Carl Banks wrote: On Dec 16, 2:56 pm, Ryan Kelly r...@rfk.id.au wrote: On Thu, 2010-12-16 at 21:49 +, John Gordon wrote: (This is mostly a style question, and perhaps one that has already been discussed elsewhere. If so, a pointer to that discussion will be appreciated!) When I started learning Python, I wrote a lot of methods that looked like this: def myMethod(self, arg1, arg2): if some_good_condition: if some_other_good_condition: if yet_another_good_condition: do_some_useful_stuff() exitCode = good1 else: exitCode = bad3 else: exitCode = bad2 else: exitCode = bad1 return exitCode But lately I've been preferring this style: def myMethod(self, arg1, arg2): if some_bad_condition: return bad1 elif some_other_bad_condition: return bad2 elif yet_another_bad_condition: return bad3 do_some_useful_stuff() return good1 I like this style more, mostly because it eliminates a lot of indentation. However I recall one of my college CS courses stating that one entry, one exit was a good way to write code, and this style has lots of exits. Are there any concrete advantages of one style over the other? one entry, one exit has its good points, but it's *way* overquoted and overused. Do you raise any exceptions? Do you call any functions that might raise exceptions? If so, you've got multiple exit points already. I think this style a lot more important in a language like C where you have to be super-careful about cleaning up after yourself. The single exit point makes it easier to verify that all cleanup tasks have been performed. Assuming you're using with or try-finally then you just don't need such guarantees in python. Even without the cleanup issue, sometimes you want to edit a function to affect all return values somehow. If you have a single exit point you just make the change there; if you have mulitple you have to hunt them down and change all of them--if you remember to. I just got bit by that one. It's a trade-off. Readability and/or conciseness versus error robustness. I tend to go for the former but mileage varies. Heaven forfend you should just wrap the existing function inside another one which takes its name, if all its returns need to be altered. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 PyCon 2011 Atlanta March 9-17 http://us.pycon.org/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: How to pop the interpreter's stack?
On Dec 15, 2:16 am, Steven D'Aprano steve +comp.lang.pyt...@pearwood.info wrote: On Tue, 14 Dec 2010 21:14:35 +, kj wrote: Consider this code: def spam(*args, **kwargs): args, kwargs = __pre_spam(*args, **kwargs) # args kwargs are OK: proceed # ... def __pre_spam(*args, **kwargs): # validate args kwargs; # return canonicalized versions of args kwargs; # on failure, raise some *informative* exception # ... return canonicalized_args, canonicalized_kwargs Double leading underscores don't have any special meaning in the global scope. Save yourself an underscore and call it _pre_spam instead :) In fact, even if spam and __pre_spam are methods, it's probably a good idea to avoid the double-underscore name mangling. It's usually more trouble than it's worth. I write functions like __pre_spam for one reason only: to remove clutter from a corresponding spam function that has a particularly complex argument-validation/canonicalization stage. In effect, spam outsources to __pre_spam the messy business of checking and conditioning its arguments. A perfectly sensible arrangement. The one thing I don't like about this strategy is that the tracebacks of exceptions raised during the execution of __pre_spam include one unwanted stack level (namely, the one corresponding to __pre_spam itself). But why is it unwanted? The traceback shows where the error occurs -- it occurs in __pre_spam, not spam, or __post_spam, or spam_caller, or anywhere else. Even if it's possible, having the traceback *lie* about where it occurs is a bad idea which will cause confusion to anyone trying to maintain the software in the future. I don't agree with kj's usage, but I have customized the traceback to remove items before. In my case it was to remove lines for endemic wrapper functions. The traceback lines showing the wrapper functions in the stack were useless, and since pretty much every function was wrapped it meant half the lines in that traceback were useless. (Really. I was scanning the loaded modules and adding wrappers to every function found. Never mind why.) I only printed the wrapper line if it was the very top of the stack. I can't think of any way to do it, You override sys.excepthook to print lines from the traceback selectively. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: How to pop the interpreter's stack?
On 12/14/2010 6:31 PM, Ethan Furman wrote: kj wrote: The one thing I don't like about this strategy is that the tracebacks of exceptions raised during the execution of __pre_spam include one unwanted stack level (namely, the one corresponding to __pre_spam itself). __pre_spam should be completely invisible and unobtrusive I am unaware of any way to accomplish what you desire. I also think this is one of those things that's not worth fighting -- how often are you going to see such a traceback? When somebody makes a coding mistake? Right. If you are worried about what the user sees in a traceback, you are doing it wrong. Consider reporting detailed error information via the logging module, for example. John Nagle -- http://mail.python.org/mailman/listinfo/python-list
Re: How to pop the interpreter's stack?
On 12/16/2010 7:33 PM, Steven D'Aprano wrote:
Python's exception system has to handle two different situations: buggy
code, and bad data. It's not even clear whether there is a general
distinction to be made between the two, but even if there's not a general
distinction, there's certainly a distinction which we can *sometimes*
make.
The two are intertwined. Production code that passes bad data to a
function without catching the exception is buggy.
def func(x):
if !(x= 10):
if x%2 != 0:
pass
else:
raise ValueError('bad value for x')
return
I would have got the same traceback,
A traceback is printed only if the code passes bad data and does not
catch the exception. Tracebacks are for developers, not for users.
--
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
[issue10692] imap lib server compabilities
Yevgeniy shchemele...@gmail.com added the comment: I found than it is server configuration problem. When i add variable IMAP_COPABILITY to /etc/courier/imapd-ssl all troubles are gone. Variable did not exported from /etc/courier/imapd, but documentation sad that it imports automatically. Thank you very much for your attention and help. -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10692 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10711] Rip out HTTP 0.9 support
Senthil Kumaran orsent...@gmail.com added the comment: +1 removing HTTP 0.9, and falling back to HTTP 1.0 behavior where ever it was HTTP 0.9. Removing support for response without status (which was acceptable by 0.9) is fine. I reviewed the patch too and it seems good to go. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10711 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9234] argparse: aliases for positional arguments (subparsers)
Raymond Hettinger rhettin...@users.sourceforge.net added the comment: Georg, I believe this should go in 3.2. The alias capability is an essential part of what subparsers are all about and these absence of aliases would leave them partially crippled (i.e. unable to emulate the likes of svn blame/annotate/praise). Please approve for the second beta. -- assignee: - georg.brandl versions: +Python 3.2 -Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9234 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10573] Consistency in unittest assert methods: order of actual, expected
Raymond Hettinger rhettin...@users.sourceforge.net added the comment: This should get fixed-up before the second beta. Try to confirm the most common argument ordering using Google's code search to ascertain actual practice in real code. FWIW, I also tend to use actual/expected and find the reverse to be a form Yoda-speak, assert 5 == x, perhaps misread the prophecy was, etc. -- nosy: +rhettinger priority: normal - high ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10573 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10515] csv sniffer does not recognize quotes at the end of line
Changes by Raymond Hettinger rhettin...@users.sourceforge.net: -- assignee: - skip.montanaro ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10515 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9938] Documentation for argparse interactive use
Tan Zong Xuan tzxru...@gmail.com added the comment:
I am also trying to use argparse interactively, but in this case by combining
it with the cmd module. So I'm doing something like below:
class MyCmd(cmd.Cmd):
parser = argparse.ArgumentParser(prog='addobject')
parser.add_argument('attribute1')
parser.add_argument('attribute2')
parser.add_argument('attribute3')
def do_addobject(self, line):
args = MyCmd.parser.parse_args(line.split())
newobject = object(args.attribute1, args.attribute2, args.attribute3)
myobjects.append(newobject)
I'm faced with the same problem that when given invalid input, parse_args exits
the program completely, instead of exiting just to the Cmd shell.
I have the feeling that this use case is sufficiently common such that it would
be good if people did not have to override the exit method themselves, and
instead an alternative to parse_args was provided that only raises exceptions
for the surrounding code to handle rather than exiting the program entirely.
--
nosy: +ZOMGxuan
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9938
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10669] Document Deprecation Warnings and how to fix
Raymond Hettinger rhettin...@users.sourceforge.net added the comment: FWIW, whatsnew is not primary documentation -- it should not be the sole or central source of anything except a highlevel overview and examples for the author's choice of selected version differences to highlight. A howto document would work best as a central place to list all deprecations and advice on what to do about them. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10669 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10605] ElementTree documentation
Changes by Raymond Hettinger rhettin...@users.sourceforge.net: -- assignee: - effbot nosy: +effbot ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10605 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10592] pprint module doesn't work well with OrderedDicts
Changes by Raymond Hettinger rhettin...@users.sourceforge.net: -- Removed message: http://bugs.python.org/msg122983 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10592 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10592] pprint module doesn't work well with OrderedDicts
Changes by Raymond Hettinger rhettin...@users.sourceforge.net: -- versions: +Python 3.3 -Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10592 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6454] Add example keyword argument to optparse constructor
Raymond Hettinger rhettin...@users.sourceforge.net added the comment: The two principals on the two argument parsing modules both find this unnecessary. -- resolution: - rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6454 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10716] Modernize pydoc to use CSS
New submission from Raymond Hettinger rhettin...@users.sourceforge.net: This is a straight-forward project. Pydoc currently generated 1990's style html which mixes content and presentation, making it very difficult for users to customize the appearance of the output. It is full of html like: table width=100%% cellspacing=0 cellpadding=2 border=0 summary=heading tr bgcolor=%s td valign=bottomnbsp;br font color=%s face=helvetica, arialnbsp;br%s/font/td td align=right valign=bottom font color=%s face=helvetica, arial%s/font/td/tr/table ''' % (bgcol, fgcol, title, fgcol, extras or 'nbsp;') def section(self, title, fgcol, bgcol, contents, width=6, prelude='', marginalia=None, gap='nbsp;'): Format a section with a heading. if marginalia is None: marginalia = 'tt' + 'nbsp;' * width + '/tt' result = '''p table width=100%% cellspacing=0 cellpadding=2 border=0 summary=section tr bgcolor=%s td colspan=3 valign=bottomnbsp;br font color=%s face=helvetica, arial%s/font/td/tr ''' % (bgcol, fgcol, title) if prelude: result = result + ''' tr bgcolor=%std rowspan=2%s/td td colspan=2%s/td/tr trtd%s/td''' % (bgcol, marginalia, prelude, gap) Please convert it to simple, validated HTML with the formatting moved to a simple, validated default style sheet. Liberally apply div/span elements with class/id attributes as necessary. -- components: Library (Lib) keywords: gsoc messages: 124119 nosy: rhettinger priority: normal severity: normal status: open title: Modernize pydoc to use CSS type: feature request versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10716 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10715] uninformative error message
Amaury Forgeot d'Arc amaur...@gmail.com added the comment:
Normally the filename is part of the error message, as you can see below.
It's possible that some operations omit it, though. Which function were you
calling?
open('foo')
Traceback (most recent call last):
File stdin, line 1, in module
IOError: [Errno 2] No such file or directory: 'foo'
--
nosy: +amaury.forgeotdarc
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10715
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10715] uninformative error message
Eric Smith e...@trueblade.com added the comment: Operating systems also return this errno for many, many things unrelated to files. So while we might be able to fix this in some specific cases, in general it's not possible to add file names to all errors. Once we know your specific case we can see if it's fixable. -- nosy: +eric.smith ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10715 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10716] Modernize pydoc to use CSS
Changes by Łukasz Langa luk...@langa.pl: -- assignee: - lukasz.langa nosy: +lukasz.langa ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10716 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10566] gdb debugging support additions (Tools/gdb/libpython.py)
Mark Florisson markflorisso...@gmail.com added the comment: I forgot to remove a tempfile and reverted the Cython note at the top. A diff is provided (that should be applied upon the previously submitted patch). It's a diff because I don't have commit rights and svn does not support local commits. -- Added file: http://bugs.python.org/file20075/libpython.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10566 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10566] gdb debugging support additions (Tools/gdb/libpython.py)
Changes by Mark Florisson markflorisso...@gmail.com: Removed file: http://bugs.python.org/file19857/libpython_patch.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10566 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5625] test_urllib2 fails - urlopen error file not on local host
Senthil Kumaran orsent...@gmail.com added the comment:
Well, ignore my comment on order of ip addresses. It definitely does not matter
in this case for test_urllib2.
However, readability does matter again as per my previous explanation, since
http://localhost/ was being exercised in the test_file,
gethostbyname('localhost') is much better than that return value's [2][0]
element.
I overlooked one thing in your first message, namely gethostbyname and
gethostbyname_ex()[2] returning completely different ips and turning out to be
exclusive. This should not be the case. gethostbyname_ex()[2] should include
the ip which was returned by gethostbyname. If it were the case, the test would
not have failed as well.
And btw, both these are supposed have similar behavior (The default action is
to query named(8), followed by /etc/hosts) only thing is gethostbyname_ex uses
the reentrant c function call and is thread-safe.
(You may probably want to identify the problem for the difference in o/p there)
And for this bug report, I am still inclined to having 'localhost' for
readability purposes or leaving it as such because the problem seems be
elsewhere.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5625
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1633941] for line in sys.stdin: doesn't notice EOF the first time
Vetoshkin Nikita nikita.vetosh...@gmail.com added the comment: I guess http://bugs.python.org/issue1195 might be related -- nosy: +nvetoshkin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1633941 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10692] imap lib server compabilities
R. David Murray rdmur...@bitdance.com added the comment: You are welcome. Glad you were able to solve it. -- resolution: - invalid stage: unit test needed - committed/rejected ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10692 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6791] httplib read status memory usage
Antoine Pitrou pit...@free.fr added the comment: Well, removing 0.9 support doesn't make this obsolete, does it? -- status: pending - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6791 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9991] xmlrpc client ssl check faulty
Jesse Kaukonen jesse.kauko...@gmail.com added the comment: I tested the latest release of Python (3.1.3) with Blender and everything worked beautifully. Renderfarm.fi thanks you for fixing this! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9991 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9938] Documentation for argparse interactive use
Éric Araujo mer...@netwok.org added the comment: You can always catch SystemExit. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9938 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10669] Document Deprecation Warnings and how to fix
Éric Araujo mer...@netwok.org added the comment: PEP 4 and PEP 290 are related to this subject, but not comprehensive, not on docs.python.org, and not tutorial-like. I think we could try Ezio’s idea. Sphinx can produce a document containing only version* directives (“make changes”). If such a document is clear enough and has links to the longer docs, there would be no need to write separate howtos. -- nosy: +eric.araujo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10669 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6791] httplib read status memory usage
Senthil Kumaran orsent...@gmail.com added the comment: On Thu, Dec 16, 2010 at 01:18:30PM +, Antoine Pitrou wrote: Well, removing 0.9 support doesn't make this obsolete, does it? It does. Doesn't it? Because I saw in your patch that you fall back on HTTP 1.0 behaviour when the server does not return a status line and in which case a Exception will be raise and this issue won't be observed. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6791 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6454] Add example keyword argument to optparse constructor
Éric Araujo mer...@netwok.org added the comment: I understood Greg’s reply to mean that there was no need for an examples keyword if simple paragraph splitting was added. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6454 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10669] Document Deprecation Warnings and how to fix
Changes by Éric Araujo mer...@netwok.org: -- components: -2to3 (2.x to 3.0 conversion tool) ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10669 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6791] httplib read status memory usage
Antoine Pitrou pit...@free.fr added the comment: It does. Doesn't it? Because I saw in your patch that you fall back on HTTP 1.0 behaviour when the server does not return a status line and in which case a Exception will be raise and this issue won't be observed. I don't think you understood the issue here. Calling readline() without a maximum length means the process memory potentially explodes, if the server sends gigabytes of data without a single \n. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6791 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10717] Multiprocessing module Pickling unPickling issues
New submission from Dimitrios Pritsos dprit...@extremepro.gr: My name is Dimitrios and I am newbie in python. I am working on a Project (part of my PhD) that is called Synergeticprocessing module. Initially is imitating the multiprocessing built in module but the processes are distributed on a LAN and not Locally. The main issue I have is with Pickle module. And I think I found some kind of BUG in the built in multiprocessing module. (Synergeticprocessing module is located at GitHub: https://github.com/dpritsos/synergeticprocessing) Starting with the BUG. In case someone uses the multiprocessing.Pool of processes he/she has to face the problem of types.MehtodType Impossible pickling. That is you cannot dispatch an class instance method to the to the Process Pool. However, digging in to the Source Code of the module there are few lines that resolve this issue however are not activated or they are faultily activated so they do not work. This is the 'BUG' @ ../multiprocessing/forking.py . . . # # Try making some callable types picklable # from pickle import Pickler class ForkingPickler(Pickler): dispatch = Pickler.dispatch.copy() @classmethod def register(cls, type, reduce): def dispatcher(self, obj): rv = reduce(obj) self.save_reduce(obj=obj, *rv) cls.dispatch[type] = dispatcher def _reduce_method(m): if m.im_self is None: return getattr, (m.im_class, m.im_func.func_name) else: return getattr, (m.im_self, m.im_func.func_name) ForkingPickler.register(type(ForkingPickler.save), _reduce_method) def _reduce_method_descriptor(m): return getattr, (m.__objclass__, m.__name__) ForkingPickler.register(type(list.append), _reduce_method_descriptor) ForkingPickler.register(type(int.__add__), _reduce_method_descriptor) #def _reduce_builtin_function_or_method(m): #return getattr, (m.__self__, m.__name__) #ForkingPickler.register(type(list().append), _reduce_builtin_function_or_method) #ForkingPickler.register(type(int().__add__), _reduce_builtin_function_or_method) . . . The RED lines are not doing the job, for some reason they are not managing to register the GREEN function as a global reduce/pickling function even if you call the registration function into you __main__ script. The solution I found is just to do this import copy_reg import types def _reduce_method(m): if m.im_self is None: return getattr, (m.im_class, m.im_func.func_name) else: return getattr, (m.im_self, m.im_func.func_name) copy_reg.pickle(types.MethodType, _reduce_method) . . . Doing that everything works FINE. But ONLY for local methods i.e. the ones that their class is defined on the __main__ script or other import-ed. In case you want to send something remotely (in an other machine) or to an other __main__ script running separately then you get a message like this: 'module' object has no attribute 'my_class' The only way to resolve this is firstly to import a script that has my_class defined there and everything works fine. SO the problems it seems to be that the m.im_class (look code above) has some attribute __module__ defined as __module__ = '__main__' or something like that. And this is the reason why remote script cannot execute the function. I mean that the _reduce_method() above DOES is pickling the whole CLASS object so there is no reason not to be executed at the remote script. Besides it does as mentioned above in you just import this the user defined class form an other script. I have already spent about 12 weeks working on building my synergeticPool and resolve the issue of Pickling and only 2 days needed for the code of the Pool and the rest of the time was spent for the Pickling issues, and study all the Class related mechanics of python. That was the reason I ve started digging the multipocessessing module and found this say 'BUG', and finally sent this email. Best Regards, Dimitrios -- components: None messages: 124133 nosy: dimitrios priority: normal severity: normal status: open title: Multiprocessing module Pickling unPickling issues type: behavior versions: Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10717 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10717] Multiprocessing module Pickling unPickling issues
Changes by Antoine Pitrou pit...@free.fr: -- nosy: +asksol, jnoller versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10717 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10718] brand new to programming. crashes at run
New submission from Jill jillcoste...@gmail.com: Hello and thanks in advance. I installed Python 2.7 from the python site onto my MAC with OS X 10.6.4. After entering my code (which makes me feel humbled and brilliant all at the same time) I am prompted to save, which I do and then when I select run the whole thing crashes. Error message below. Process: Python [14162] Path:/Applications/Python 2.7/IDLE.app/Contents/MacOS/Python Identifier: org.python.IDLE Version: 2.7.1 (2.7.1) Code Type: X86 (Native) Parent Process: launchd [149] Date/Time: 2010-12-16 09:09:15.644 -0500 OS Version: Mac OS X 10.6.4 (10F569) Report Version: 6 Interval Since Last Report: 8227 sec Crashes Since Last Report: 2 Per-App Interval Since Last Report: 1974 sec Per-App Crashes Since Last Report: 2 Anonymous UUID: 48621F8F-C51F-400A-8AA8-76DDA70F8973 Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x30747369 Crashed Thread: 0 Dispatch queue: com.apple.main-thread Application Specific Information: objc_msgSend() selector name: release Thread 0 Crashed: Dispatch queue: com.apple.main-thread 0 libobjc.A.dylib 0x9798eedb objc_msgSend + 27 1 com.apple.CoreFoundation0x96ec191d _CFAutoreleasePoolPop + 253 2 com.apple.Foundation0x9309cdb6 NSPopAutoreleasePool + 76 3 com.apple.Foundation0x9309ccde -[NSAutoreleasePool drain] + 130 4 Tk 0x0072cf18 XQueryPointer + 2393 5 Tk 0x0072d219 Tk_MacOSXSetupTkNotifier + 634 6 Tcl 0x005f4aa8 Tcl_DoOneEvent + 310 7 _tkinter.so 0x003d75b2 Tkapp_MainLoop + 450 8 org.python.python 0x000c18e0 PyEval_EvalFrameEx + 26576 9 org.python.python 0x000c3c7c PyEval_EvalCodeEx + 1996 10 org.python.python 0x000c15ce PyEval_EvalFrameEx + 25790 11 org.python.python 0x000c2ba3 PyEval_EvalFrameEx + 31379 12 org.python.python 0x000c3c7c PyEval_EvalCodeEx + 1996 13 org.python.python 0x000c3dc7 PyEval_EvalCode + 87 14 org.python.python 0x000e82fc PyRun_FileExFlags + 172 15 org.python.python 0x000e8664 PyRun_SimpleFileExFlags + 596 16 org.python.python 0x00100255 Py_Main + 3365 17 Python 0x1f65 start + 53 Thread 1: Dispatch queue: com.apple.libdispatch-manager 0 libSystem.B.dylib 0x961f4942 kevent + 10 1 libSystem.B.dylib 0x961f505c _dispatch_mgr_invoke + 215 2 libSystem.B.dylib 0x961f4519 _dispatch_queue_invoke + 163 3 libSystem.B.dylib 0x961f42be _dispatch_worker_thread2 + 240 4 libSystem.B.dylib 0x961f3d41 _pthread_wqthread + 390 5 libSystem.B.dylib 0x961f3b86 start_wqthread + 30 Thread 2: 0 libSystem.B.dylib 0x961ed086 select$DARWIN_EXTSN + 10 1 Tcl 0x0062a72b Tcl_InitNotifier + 1643 2 libSystem.B.dylib 0x961fb81d _pthread_start + 345 3 libSystem.B.dylib 0x961fb6a2 thread_start + 34 Thread 3: 0 libSystem.B.dylib 0x961f39d2 __workq_kernreturn + 10 1 libSystem.B.dylib 0x961f3f68 _pthread_wqthread + 941 2 libSystem.B.dylib 0x961f3b86 start_wqthread + 30 Thread 4: 0 libSystem.B.dylib 0x961f39d2 __workq_kernreturn + 10 1 libSystem.B.dylib 0x961f3f68 _pthread_wqthread + 941 2 libSystem.B.dylib 0x961f3b86 start_wqthread + 30 Thread 5: 0 libSystem.B.dylib 0x961ce0fa mach_msg_trap + 10 1 libSystem.B.dylib 0x961ce867 mach_msg + 68 2 com.apple.CoreFoundation0x96ec4faf __CFRunLoopRun + 2079 3 com.apple.CoreFoundation0x96ec4094 CFRunLoopRunSpecific + 452 4 com.apple.CoreFoundation0x96ec9fd4 CFRunLoopRun + 84 5 com.apple.DesktopServices 0x91b61e13 TSystemNotificationTask::SystemNotificationTaskProc(void*) + 643 6 ...ple.CoreServices.CarbonCore 0x90dc1dee PrivateMPEntryPoint + 68 7 libSystem.B.dylib 0x961fb81d _pthread_start + 345 8 libSystem.B.dylib 0x961fb6a2 thread_start + 34 Thread 6: 0 libSystem.B.dylib 0x961f39d2 __workq_kernreturn + 10 1 libSystem.B.dylib 0x961f3f68 _pthread_wqthread + 941 2 libSystem.B.dylib 0x961f3b86 start_wqthread + 30 Thread 7: 0 libSystem.B.dylib 0x961ed086 select$DARWIN_EXTSN + 10 1 com.apple.CoreFoundation0x96f0480d __CFSocketManager + 1085 2 libSystem.B.dylib
