Distribute 0.6.4 released
On behalf of the Distribute team I am happy to announce the release of Distribute 0.6.4. == What is Distribute == Distribute is a fork of the Setuptools project. Distribute is intended to replace Setuptools as the standard method for working with Python module distributions, on the top of Distutils. == What's new in 0.6.4 == - This release is now compatible with zc.buildout, as long as you use the special bootstrap.py file provided at http://nightly.ziade.org/bootstrap.py - A new upload_docs command to easily upload project documentation to PyPI's http://packages.python.org was added. As a matter of fact, Distribute documentation uses it and is now available at : http://packages.python.org/distribute - A bug was fixed in the bootstrapping process (IOError: Could not build the egg) The release is available at PyPI, together with the installation instructions: http://pypi.python.org/pypi/distribute == What's next == The next release in the 0.6.x will continue the work on fixing bugs. The roadmap of the project is here: http://packages.python.org/distribute/roadmap.html == feedback == bug tracker: http://bitbucket.org/tarek/distribute/issues mailing list : distutils-...@python.org Regards Tarek -- Tarek Ziadé | http://ziade.org | オープンソースはすごい! | 开源传万世，因有你参与 -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/
Re: The rap against while True: loops
On Saturday, 10 October 2009 22:15:21 kj wrote: I'm coaching a group of biologists on basic Python scripting. One of my charges mentioned that he had come across the advice never to use loops beginning with while True. Of course, that's one way to start an infinite loop, but this seems hardly a sufficient reason to avoid the construct altogether, as long as one includes an exit that is always reached. (Actually, come to think of it, there are many situations in which a bona fide infinite loops (typically within a try: block) is the required construct, e.g. when implementing an event loop.) I use while True-loops often, and intend to continue doing this while True, but I'm curious to know: how widespread is the injunction against such loops? Has it reached the status of best practice? Others have given various valid answers, but I have not seen this one: It is often necessary, in long running applications, to set up loops that you would really like to run until the end of time. - the equivalent of a serve forever construct. Then while True is the obvious way to spell it. - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Why ELIF?
I wonder the reason for ELIF. it's not aligned with IF, make code ugly IMHO OR maybe better? if foo == bar: ... or foo == baz: ... or foo == bra: ... else: ... -- http://mail.python.org/mailman/listinfo/python-list
Re: code in a module is executed twice (cyclic import problems) ?
On Sunday, 11 October 2009 02:24:34 Stephen Hansen wrote: It's really better all around for modules to be considered like libraries, that live over There, and aren't normally executed. Then you have scripts over Here which may just be tiny and import a module and call that module's main method. Okay, I'm not arguing you should never execute a module, sometimes its useful and needful-- especially for testing or more complex project organization. But in general... this is just gonna cause no end of suffering if you don't at least try to maintain the script vs module mental separation. Modules are the principle focus of code-reuse and where most things happen, scripts are what kickstart and get things going and drive things. IMHO. If not that, then at least make sure that nothing is ever /executed/ at the top-level of your files automatically; when imported call 'module.meth()' to initialize and/or get My_List or whatever, and when executed use the __name__ == __main__ block to do whatever you want to do when the file is started as a main script. Otherwise, things'll get weird. ... gah snip huge write-up I threw in about how we organize our code around the office. Not important! Your use-case is probably different enough that you'd surely organize differently. But still, I really recommend treating modules like static repositories of code that scripts call into / invoke / execute. Even if sometimes you execute the modules directly (and thus use a main() function to run in whatever default way you choose). I have been using the __name__== main part of what you call modules to do the test code for the module. So if you execute it at the top level, it does its testing, and if you import it, it is like a library. This works for me, but it is probably not of general use - the stuff we do tends to be smallish and long running. - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: Why ELIF?
metal wrote: I wonder the reason for ELIF. it's not aligned with IF, make code ugly IMHO OR maybe better? if foo == bar: ... or foo == baz: ... or foo == bra: ... else: ... Because that's uglier. `or` means something completely unrelated in expressions. Variations of `else if` in `if ... else if ...` chains is routine in computer languages. Choosing a deliberately different syntax just for the sake it of is obtuse at best. -- Erik Max Francis m...@alcyone.com http://www.alcyone.com/max/ San Jose, CA, USA 37 18 N 121 57 W AIM/Y!M/Skype erikmaxfrancis And covenants, without the sword, are but words and of no strength to secure a man at all. -- Thomas Hobbes, 1588-1679 -- http://mail.python.org/mailman/listinfo/python-list
Re: organizing your scripts, with plenty of re-use
On Sat, 10 Oct 2009 13:44:18 -0300, Gabriel Genellina wrote: The frustrating thing, for me, is that all these requirements are met if you leave the scripts in jumbled into a flat directory. I bet that's not true. I bet that they Just Work only if the user cd's into the directory first. In other words, if you have all your scripts in the directory /tools/mycompany/bin/scripts, this will work: $ cd /tools/mycompany/bin/scripts $ animals.py but this won't: $ cd /home/username $ /tools/mycompany/bin/scripts/animals.py In the first case, it works because the current working directory is included in the PYTHONPATH, and all the modules you need are there. In the second, it doesn't because the modules aren't in either the current directory or any other directory in the PYTHONPATH. That's my prediction. Mmm, I predict you won't have much success in your new fortune teller career... :) You got it backwards. At least on Windows, the current directory *isn't* on the Python path, but the directory containing the script *is* included. So both alternatives above work. Oops. Serves me right for making what I thought was a sure bet before testing :) It's the same for Linux too, and it seems to hold at least back to Python 1.5. On the ignominy of it all! I guess I'll have to give up the fortune- telling and get a proper job :( -- Steven -- http://mail.python.org/mailman/listinfo/python-list
ANN: yappi 0.1 beta : Yet Another Python Profiler
Hi all, After implementing a game server on which 100k people playing games per-day, it turns out to be that continuous and efficient profiling is key to improve an long-running applications like these. With this idea in mind, I am motivated to write a profiler. I am not a Python expert or even close to it but thanks to the ease of language and C API, I can come up with a source code profiler with multithreading support. Thanks for all the people here for answering my silly questions. I have tested the profiler in our game server for about 3 days without any issues but please use it at your own risk and note that this is still beta. Expect silly errors and if possible, help me to fix them:) Get more information: (thanks to Google Code) http://code.google.com/p/yappi/ Download: http://code.google.com/p/yappi/downloads/list Not to mention any comment/idea/curse is welcome. -- Sumer Cip -- http://mail.python.org/mailman/listinfo/python-list
Re: The rap against while True: loops
On Sat, 10 Oct 2009 20:15:21 +, kj wrote: I use while True-loops often, and intend to continue doing this while True, but I'm curious to know: how widespread is the injunction against such loops? Has it reached the status of best practice? Such an injunction probably made more sense back in the days of single- tasking computers. Back in ancient days when dinosaurs walked the Earth, and I was programming in THINK Pascal on Apple Macintosh System 6, I'd go into nervous palpitations writing the equivalent of while True because if I got it wrong, I'd lock up the machine and need to hit the power button. (At least if I was still testing in the THINK Pascal IDE, and had the whole range of debugging options turned on, I could interrupt it.) These days, I must admit I still have a tiny little shiver whenever I write while True, but that's entirely irrational and I pay no attention to it. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Why ELIF?
On Sat, 10 Oct 2009 23:47:38 -0700, metal wrote:
I wonder the reason for ELIF. it's not aligned with IF, make code ugly
IMHO
OR maybe better?
if foo == bar:
...
or foo == baz:
...
or foo == bra:
...
else:
...
`or` has another meaning in Python, and many other languages:
flag = len(mystring) 10 or count 50
By the way, if you're testing a single name against a series of
alternatives, it is often better to look up the value in a dictionary:
table = {bar: 23, baz: 42, boop: 73, beep: 124}
value = table[foo]
instead of:
if foo == bar:
value = 23
elif foo == baz:
value = 42
elif ...
You can even provide a default value by using table.get().
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: Script to complete web form fields
On Oct 10, 9:39 pm, Feyo dkatkow...@gmail.com wrote: How can I use Python to complete web form fields automatically? My work web-based email time-out is like 15 seconds. Every time I need to access my calendar, address book, or email, I have to type in my username and password. I'm just tired of it. I found the ClientForm module and have been working with it. Can do what I want in a unit testing sense to have responses sent and returned, but what I want to do is much simpler. Any ideas? Thanks. See this recent thread for ideas: http://groups.google.com/group/comp.lang.python/browse_thread/thread/58b7513596ab648c However, why not take a more direct approach? Speak to management and see if your company can correct this. It's obviously hindering productivity, and that's something they may have overlooked. There should be a more reasonable compromise between efficiency and security. It's worth a shot. -- http://mail.python.org/mailman/listinfo/python-list
Re: code in a module is executed twice (cyclic import problems) ?
On Oct 10, 7:36 pm, Stef Mientki stef.mien...@gmail.com wrote: hello, I always thought code in a module was only executed once, but doesn't seem to be true. I'm using Python 2.5. And this is the example: == A.py == My_List = [] == B.py == from A import * My_List.append ( 3 ) print 'B', My_List import C == C.py == from A import * from B import * print 'C', My_List Now when you start with B.py as the main program, this is the resulting output: B [3] B [3, 3] C [3, 3] Why is the B.py executed twice ? thanks, Stef FYI, there was actually a related discussion about this just recently: http://groups.google.com/group/comp.lang.python/browse_thread/thread/e24be42ecbee7cad -- http://mail.python.org/mailman/listinfo/python-list
Re: code in a module is executed twice (cyclic import problems) ?
thanks very much Stephen, This is the first time I become aware of the difference between script and module !! Starting with the wrong book Learning Python second edition, from Lutz and Ascher, based on Python 2.3 in combination with using Python only from a high level IDE (PyScripter), (never seeing the m-switch), I never was aware of this important difference. A quick Googling on python module vs script doesn't reveal many (good) links, the best one I found is http://effbot.org/zone/import-confusion.htm thanks again, Stef Mientki Stephen Hansen wrote: On Sat, Oct 10, 2009 at 4:36 PM, Stef Mientki stef.mien...@gmail.com mailto:stef.mien...@gmail.com wrote: hello, I always thought code in a module was only executed once, but doesn't seem to be true. This is one of the reasons why that whole big mess of a ton separate scripts that all call each-other and are sometimes imported and sometimes executed is just a bad way to achieve code re-use and organization... :) IMHO :) I'm using Python 2.5. And this is the example: == A.py == My_List = [] == B.py == from A import * My_List.append ( 3 ) print 'B', My_List import C == C.py == from A import * from B import * print 'C', My_List Now when you start with B.py as the main program, this is the resulting output: B [3] B [3, 3] C [3, 3] Why is the B.py executed twice ? Because when you start B, it's not the module B. Its a script that is being run. Python doesn't byte-compile such scripts, nor do those scripts count really as the modules you're expecting them to be. When you import B after executing B as a main module, it won't find that module B has already been loaded. When you execute B directly, its actually the module __main__. When you import B, it's the module B. It's really better all around for modules to be considered like libraries, that live over There, and aren't normally executed. Then you have scripts over Here which may just be tiny and import a module and call that module's main method. Okay, I'm not arguing you should never execute a module, sometimes its useful and needful-- especially for testing or more complex project organization. But in general... this is just gonna cause no end of suffering if you don't at least try to maintain the script vs module mental separation. Modules are the principle focus of code-reuse and where most things happen, scripts are what kickstart and get things going and drive things. IMHO. If not that, then at least make sure that nothing is ever /executed/ at the top-level of your files automatically; when imported call 'module.meth()' to initialize and/or get My_List or whatever, and when executed use the __name__ == __main__ block to do whatever you want to do when the file is started as a main script. Otherwise, things'll get weird. ... gah snip huge write-up I threw in about how we organize our code around the office. Not important! Your use-case is probably different enough that you'd surely organize differently. But still, I really recommend treating modules like static repositories of code that scripts call into / invoke / execute. Even if sometimes you execute the modules directly (and thus use a main() function to run in whatever default way you choose). HTH, --S -- http://mail.python.org/mailman/listinfo/python-list
Re: code in a module is executed twice (cyclic import problems) ?
(please don't top-post. Put your reply *after* the message you're quoting.) Stef Mientki wrote: div class=moz-text-flowed style=font-family: -moz-fixedthanks very much Stephen, This is the first time I become aware of the difference between script and module !! Starting with the wrong book Learning Python second edition, from Lutz and Ascher, based on Python 2.3 in combination with using Python only from a high level IDE (PyScripter), (never seeing the m-switch), I never was aware of this important difference. A quick Googling on python module vs script doesn't reveal many (good) links, the best one I found is http://effbot.org/zone/import-confusion.htm thanks again, Stef Mientki snip The point you should get from that link is Don't do circular imports. Ever. It's generally worse if the circle includes the original script, treated as a module, but even between modules it can get you into trouble in many subtle ways. Some of them cause runtime errors, so you'll fix them. Some of them will just fail quietly, and you'll be searching for subtle bugs. I don't agree with the author's advice that sometimes moving the import to the end helps. Best advice is to break the circle, by rearranging the modules, moving commonly needed symbols into someplace else that both import. It's probably safe if none of the modules in the circle has any top-level code that references imported symbols. But top-level code includes default values for function definitions, and class initializers for class definitions. Does anybody know if there's a way to activate a warning for this? DaveA -- http://mail.python.org/mailman/listinfo/python-list
Re: python performance on Solaris
inaf cem.ezberci at gmail.com writes: My code seem to return lookups from a in memory data structure I build combining bunch of dictionaries and lists 6-8 times faster on a 32 bit Linux box than on a Solaris zone. Well, if your workload is CPU-bound, the issue here is not really Solaris vs. Linux but rather CPU power. You should try to run a generic (non-Python) CPU benchmark (*) on both systems, perhaps this 6-8 factor is expected. If only Python shows such a performance difference, on the other hand, perhaps you can give us more precisions on those systems. Regards Antoine. (*) for example one of the C programs on http://shootout.alioth.debian.org/u64/c.php -- http://mail.python.org/mailman/listinfo/python-list
Re: mxDateTime history (Re: mktime, how to handle dates before 01-01-1970 ?)
On Fri, 09 Oct 2009 13:39:43 +0100, Tim Chase python.l...@tim.thechases.com wrote: Month arithmetic is a bit of a mess, since it's not clear how to map e.g. Jan 31 + one month. Jan 31 + one month usually means add one to the month value and then keep backing off the day if you get an exception making the date, so you'd get Feb 31, exception, Feb 30, exception, Feb 29, possibly an exception, and possibly/finally Feb 28th. This makes pretty intuitive sense to most folks and is usually what's meant. I've found that issues and confusion stem more from the non-commutative reality that Jan 31 + (1 month) + (-1 month) != Jan 31 + (-1 month) + (1 month) or the non-associative Jan 31 + (1 month + 1 month) != (Jan 31 + 1 month) + 1 month :-/ I'd hazard a guess that what we're actually seeing is people mentally rebasing their indices, i.e. counting from the end of the month rather than the start, which makes the last day of January and January 31 not the same thing really. Unfortunately we're very fuzzy about when we do things like this, which makes it hard on a poor programmer. -- Rhodri James *-* Wildebeest Herder to the Masses -- http://mail.python.org/mailman/listinfo/python-list
Re: Script to complete web form fields
Feyo schrieb: How can I use Python to complete web form fields automatically? My work web-based email time-out is like 15 seconds. Every time I need to access my calendar, address book, or email, I have to type in my username and password. I'm just tired of it. I found the ClientForm module and have been working with it. Can do what I want in a unit testing sense to have responses sent and returned, but what I want to do is much simpler. Any ideas? Thanks. 1) hit your sysadmin with a cluestick 2) in case of failure of 1), install greasemonkey to make some nonsense-action on the page every few seconds. Diez -- http://mail.python.org/mailman/listinfo/python-list
Writing to function arguments during execution
I'm writing a (music-generating) program incorporating a generator function which takes dictionaries as its arguments. I want to be able to change the values of the arguments while the program is running. I have it working as in this toy example (python 2.5): from sys import argv from threading import Thread from my_functions import option_processor, work #Make a dictionary of arguments to the main work function argdict = option_processor(argv[1:]) def argdict_rewriter(argdict): Write new values to a dictionary of arguments while 1: new_dict = option_processor(raw_input().split()) argdict.update(new_dict) #Write to the dictionary while program is running rewriter = Thread(target=argdict_rewriter, args=(argdict,)) rewriter.setDaemon(True) rewriter.start() #The main generator function work(argdict) Now I can change the output of the work function while it's running via raw_input(). However it's very crude, not least because the terminal echo of the new options is interspersed with the output of the program. In future I hope to be able to have several instances of the work function running as threads simultaneously, and to separately control the arguments to each. I think the general problem is how to send output from a thread to a different place from that of its parent thread, but I'm not sure. Is there a standard way to do this kind of thing? In particular, I'm after a solution whereby I can enter new arguments in one terminal window and observe the program's output in another. Regards, John -- http://mail.python.org/mailman/listinfo/python-list
Re: except KeyError: print(this was not a key error?)
On Oct 11, 7:48 am, Michel Alexandre Salim
michael.silva...@gmail.com wrote:
On Oct 10, 7:59 pm, gert gert.cuyk...@gmail.com wrote:
http://code.google.com/p/appwsgi/source/browse/appwsgi/wsgi/order.wsgi
I screwed up some sql statement
INSERT INTO orders (pid,uid,bid,time) VALUES (?,?,2,DATETIME('NOW')),
(v['pid']),s.UID)
bid does not exist anymore, but why does the KeyError exception occur
when only my sql statement is wrong ?
Sure it's not from this line?
def stats2(db,v,s): db.execute(SELECT * FROM orders WHERE bid=? AND
uid=?,(v['bid'],s.UID))
It references v['bid']
Hmm that is also a key error :)
--
http://mail.python.org/mailman/listinfo/python-list
interfacing python haskell code with ctypes on linux
Hi Folks, Just in case anyone is interested, I've just added a very simple example for linux showing how to access haskell functions from python code using ctypes. It's on the wiki: http://wiki.python.org/moin/PythonVsHaskell AK -- http://mail.python.org/mailman/listinfo/python-list
Re: strange behaviour when inheriting from tuple
On 10月11日, 下午5时30分, ryles ryle...@gmail.com wrote: On Oct 11, 3:04 am, metal metal...@gmail.com wrote: Environment: PythonWin 2.5.4 (r254:67916, Apr 27 2009, 15:41:14) [MSC v.1310 32 bit (Intel)] on win32. Portions Copyright 1994-2008 Mark Hammond - see 'Help/About PythonWin' for further copyright information. Evil Code: class Foo: def __init__(self, *args): print args Foo(1, 2, 3) # (1, 2, 3), good class Bar(tuple): def __init__(self, *args): print args Bar(1, 2, 3) # TypeError: tuple() takes at most 1 argument (3 given) what the heck? I even didn't call tuple.__init__ yet When subclassing immutable types you'll want to override __new__, and should ensure that the base type's __new__ is called: __ class MyTuple(tuple): __ def __new__(cls, *args): __ return tuple.__new__(cls, args) __ print MyTuple(1, 2, 3) (1, 2, 3) Seehttp://www.python.org/download/releases/2.2.3/descrintro/#__new__ That's it. Thank you very much. -- http://mail.python.org/mailman/listinfo/python-list
Re: Writing to function arguments during execution
On Sun, 11 Oct 2009 14:18:25 +0100, John O'Hagan resea...@johnohagan.com wrote: Now I can change the output of the work function while it's running via raw_input(). However it's very crude, not least because the terminal echo of the new options is interspersed with the output of the program. In future I hope to be able to have several instances of the work function running as threads simultaneously, and to separately control the arguments to each. I think the general problem is how to send output from a thread to a different place from that of its parent thread, but I'm not sure. Is there a standard way to do this kind of thing? In particular, I'm after a solution whereby I can enter new arguments in one terminal window and observe the program's output in another. The standard way (if you don't want to write a GUI for the whole thing) is to have separate programs communicating with sockets. Start your music program in one terminal and the control program in the other, and have a thread listening to the socket rather than using raw_input(). Exactly what processing your control program should do before tossing the data through the socket is a matter of religious debate :-) -- Rhodri James *-* Wildebeest Herder to the Masses -- http://mail.python.org/mailman/listinfo/python-list
Re: The rap against while True: loops
On 2009-10-11, Hendrik van Rooyen hend...@microcorp.co.za wrote: It is often necessary, in long running applications, to set up loops that you would really like to run until the end of time. - the equivalent of a serve forever construct. Then while True is the obvious way to spell it. Once upon a time I was working on the software requirements specifications for a missile launcher for the US Navy. In the section on the system's scheduler task I wrote something like this: The scheduler shall consist of an infinite loop that executes the following: 1. Call this function. 2. Call that function. [...] The review team (mainly from Johns Hopkins University Applied Physics Lab) told me I couldn't put an infinite loop in the requirements document. I replied, OK, when or under what circumstances do you want the launcher to stop working? They said that I misunderstood their comment. I can (and indeed must) have an infinite loop in the software. I just can't put the phrase infinite loop in the document. They explained that ship captains get to review these documents. Ship captains all took a year of undergrad FORTRAN programming and therefore believe that an infinite loop is a bad thing. I changed the text to read something like this: The secheduler shall repeatedly execute the following until the system is powered off or reset: 1. Call this function. 2. Call that function. [...] Everybody was happy. Tax dollars at work... -- Grant -- http://mail.python.org/mailman/listinfo/python-list
Re: Why ELIF?
On 2009-10-11, metal metal...@gmail.com wrote: I wonder the reason for ELIF. it's not aligned with IF, make code ugly It most certainly is aligned with IF: if cond1: do this elif cond2: do that else: do the other The if elif and else are all aligned in all of the code I've ever seen. -- Grant -- http://mail.python.org/mailman/listinfo/python-list
Re: Why ELIF?
On Oct 11, 7:07 am, Erik Max Francis m...@alcyone.com wrote:
Because that's uglier. `or` means something completely unrelated in
expressions. Variations of `else if` in `if ... else if ...` chains is
routine in computer languages. Choosing a deliberately different syntax
just for the sake it of is obtuse at best.
I agree - first thing I do when learning a language, is find out what
the local brew is, e.g.: if (expr) {block} else if (expr) {block} else
{block}. It is just a part of programming. Which style it uses, is
mostly inconsequential, as long as the language documents the syntax
and behaviour, all is good [sic].
On Oct 11, 8:07 am, Steven D'Aprano st...@remove-this-
cybersource.com.au wrote:
By the way, if you're testing a single name against a series of
alternatives, it is often better to look up the value in a dictionary:
table = {bar: 23, baz: 42, boop: 73, beep: 124}
value = table[foo]
instead of:
if foo == bar:
value = 23
elif foo == baz:
value = 42
elif ...
my personally favorite is: foo in table, when applicable.
--
http://mail.python.org/mailman/listinfo/python-list
run exe and create exe
Hi everybody, I have 2 questions: 1) I created my python application. It has QT Gui. How can I make exe of it? I don't want everytime I run the file it'll open the command line window which does nothing. 2) My Application suppose to be a client server app. Anyhow, for now It's running only on local host. I added a button that run the server file. my server file located at c:\temp\server.py. It takes no arguments. I tried the following codes at the push button function: os.system(c:\temp\server.py) - It stuck my GUI. I guess that this function doesn't open a new proccess. I also tried : os.spawnv(os.P_NOWAIT,c:\temp\server.py); It raised the following error: OSError: [Errno 8] Exec format error. Any Idea what to do? Thanks DaveD -- http://mail.python.org/mailman/listinfo/python-list
Re: Why ELIF?
Steven D'Aprano wrote:
By the way, if you're testing a single name against a series of
alternatives, it is often better to look up the value in a dictionary:
table = {bar: 23, baz: 42, boop: 73, beep: 124}
value = table[foo]
instead of:
if foo == bar:
value = 23
elif foo == baz:
value = 42
elif ...
You can even provide a default value by using table.get().
cool .. I hadn't seen that. Not working quite at the 'pythonic' level yet
I am not sure I think it's more readable that the if statement. Also, curious
if the dictionary approach is more efficient.
thanks,
Esmail
--
http://mail.python.org/mailman/listinfo/python-list
Re: Why ELIF?
Grant Edwards wrote: On 2009-10-11, metal metal...@gmail.com wrote: I wonder the reason for ELIF. it's not aligned with IF, make code ugly It most certainly is aligned with IF: if cond1: do this elif cond2: do that else: do the other The if elif and else are all aligned in all of the code I've ever seen. In some other languages, eg Modula-2, it's 'elsif'; the disadvantage there is that if you were hearing it read out you might ask: Do you mean 'elsif' or 'else if'? so 'elif' is not only shorter, it's clearer. -- http://mail.python.org/mailman/listinfo/python-list
Re: run exe and create exe
On Oct 11, 10:15 am, daved170 daved...@gmail.com wrote: Hi everybody, I have 2 questions: 1) I created my python application. It has QT Gui. How can I make exe of it? I don't want everytime I run the file it'll open the command line window which does nothing. If you want to run your script without the command line popping up... 1. rename the script to myscript.pyw *OR* 2. run the script by C:\\PYVER\\pythonw.exe myscript.py if you want an exe check out py2exe... Google knows where to find it. -- http://mail.python.org/mailman/listinfo/python-list
Re: mxDateTime history (Re: mktime, how to handle dates before 01-01-1970 ?)
Rhodri James wrote: On Fri, 09 Oct 2009 13:39:43 +0100, Tim Chase python.l...@tim.thechases.com wrote: Month arithmetic is a bit of a mess, since it's not clear how to map e.g. Jan 31 + one month. Jan 31 + one month usually means add one to the month value and then keep backing off the day if you get an exception making the date, so you'd get Feb 31, exception, Feb 30, exception, Feb 29, possibly an exception, and possibly/finally Feb 28th. This makes pretty intuitive sense to most folks and is usually what's meant. I've found that issues and confusion stem more from the non-commutative reality that Jan 31 + (1 month) + (-1 month) != Jan 31 + (-1 month) + (1 month) or the non-associative Jan 31 + (1 month + 1 month) != (Jan 31 + 1 month) + 1 month :-/ I'd hazard a guess that what we're actually seeing is people mentally rebasing their indices, i.e. counting from the end of the month rather than the start, which makes the last day of January and January 31 not the same thing really. Unfortunately we're very fuzzy about when we do things like this, which makes it hard on a poor programmer. And when someone says January 30, do they really mean the day before the last day of the month? Where would it end? :-) -- http://mail.python.org/mailman/listinfo/python-list
Re: run exe and create exe
daved170 wrote: Hi everybody, I have 2 questions: 1) I created my python application. It has QT Gui. How can I make exe of it? I don't want everytime I run the file it'll open the command line window which does nothing. 2) My Application suppose to be a client server app. Anyhow, for now It's running only on local host. I added a button that run the server file. my server file located at c:\temp\server.py. It takes no arguments. I tried the following codes at the push button function: os.system(c:\temp\server.py) - It stuck my GUI. I guess that this function doesn't open a new proccess. is an empty string, so c:\temp\server.py is just the empty string followed by c:\temp\server.py and then another empty string . I also tried : os.spawnv(os.P_NOWAIT,c:\temp\server.py); It raised the following error: OSError: [Errno 8] Exec format error. Any Idea what to do? A backslash starts an escape sequence, which you don't want because it's a path. You should either double the backslashes: os.spawnv(os.P_NOWAIT, c:\\temp\\server.py) or use a raw string: os.spawnv(os.P_NOWAIT, rc:\temp\server.py) -- http://mail.python.org/mailman/listinfo/python-list
Re: The rap against while True: loops
En Sat, 10 Oct 2009 19:32:25 -0300, Björn Lindqvist bjou...@gmail.com escribió: I have many times screwed up while True-loops. When I thought I had a safe exit condition which turned out to be never reached in some rare corner cases. Leading to weird bugs with hanging threads. I have seen colleges screw up in the same way too. But that's not a problem with the while True: construct, that's a problem with your condition. Had you written the code using while some_condition: it would have failed in the same way. [...] Recursive functions can also be more readable than while True because it is easier to make the exit condition explicit. But sometimes they are necessary and then you have to be careful to check that the while True always breaks somewhere. That's true for any loop. The only difference is, with a while condition: loop, the condition is right at the while statement. In a while True: loop, you have to look for the condition elsewhere (likely, an if statement preceding a break). -- Gabriel Genellina -- http://mail.python.org/mailman/listinfo/python-list
Re: Persistent Distributed Objects
Does pyro work inside of stackless? On Sat, Oct 10, 2009 at 9:54 AM, Simon Forman sajmik...@gmail.com wrote: On Fri, Oct 9, 2009 at 1:11 AM, John Haggerty bouncy...@gmail.com wrote: I am interested in seeing how it would be possible in python to have persistent objects (basically be able to save objects midway through a computation, etc) and do so across multiple computers. Something that would allow for memory, disk space, processing power, etc to be distributed across the nodes not just for number crunching. So for example a warehouse program started up on 3 machines one for adding orders, one for searching for orders, one for organizing the warehouse and them running on a different machine with a single interface. I've seen evidence about this being done wrt what looks like insanely complex stuff on this list but I'm wondering if there is something to do this with any number of nodes and just farm out random classes/objects to them? Check out Pyro (Python Remote Objects): http://pyro.sourceforge.net/ or perhaps Stackless Python http://www.stackless.com/ (Tasklets can be serialized and passed around.) -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: code in a module is executed twice (cyclic import problems) ?
ryles wrote: I always thought code in a module was only executed once, but doesn't seem to be true. I'm using Python 2.5. And this is the example: == A.py == My_List = [] == B.py == from A import * My_List.append ( 3 ) print 'B', My_List import C == C.py == from A import * from B import * print 'C', My_List Now when you start with B.py as the main program, this is the resulting output: B [3] B [3, 3] C [3, 3] Why is the B.py executed twice ? B.py is the entry point of the program and it is known internally as __main__. There is no record of a B.py. If you really must import objects from the main module you can do it like this. from __main__ import * -- Stephen Fairchild -- http://mail.python.org/mailman/listinfo/python-list
Re: postprocessing in os.walk
Well, you could use the alternative os.path.walk instead. You can pass a callback as a parameter, which will be invoked every time you bump into a new directory. The signature is os.path.walk (path,visit,arg). Take a look at the python library documentation. On 11 Oct, 00:12, kj no.em...@please.post wrote: Perl's directory tree traversal facility is provided by the function find of the File::Find module. This function accepts an optional callback, called postprocess, that gets invoked just before leaving the currently processed directory. The documentation goes on to say This hook is handy for summarizing a directory, such as calculating its disk usage, which is exactly what I use it for in a maintenance script. This maintenance script is getting long in the tooth, and I've been meaning to add a few enhancements to it for a while, so I thought that in the process I'd port it to Python, using the os.walk function, but I see that os.walk does not have anything like this File::Find::find's postprocess hook. Is there a good way to simulate it (without having to roll my own File::Find::find in Python)? TIA! kynn -- http://mail.python.org/mailman/listinfo/python-list
getting equal behavior for scripts and modules ?
hello, I do agree that circular references should preferable be avoided. In languages like Delphi, you get an error message, trying to use circular references, but solving them in large programs with a lot of history can be very painful. Now I finally (after 2 years) knowing there's a difference between modules and scripts, I want to guarantee that I always get the same functional behavior. I found 2 solutions to realize the above. === solution 1 === Inserting a launcher into the IDE, so instead of running the application as a script, the file will always be executed as a module. == Launcher == instead of if __name__ == '__main__' : define a function def main () : and start this Launcher with the first parameter being the name of the module Launcher module to be tested other arguments import sys __My_Main_Application = __import__ ( sys.argv[1] ) if 'main' in dir ( __My_Main_Application ) : __My_Main_Application.main () === solution 2 === Prevent execution of the code in this file if the file is ran as a script. if __name__=='__main__': import os, sys # determine the name of myself a = sys._getframe().f_code.co_filename X = os.path.splitext ( os.path.split(a)[1] ) [0] #import myself as 'ME' ME = __import__ ( X ) # run some code in myself ME.functional_code () # prevent that the code below is executed, # ( for the second time ) # if this file is used as a script sys.exit() print 'One time import code' def functional_code () : print 'Functional Code' any comment ? thanks, Stef Mientki -- http://mail.python.org/mailman/listinfo/python-list
Re: getting equal behavior for scripts and modules ?
On Sun, Oct 11, 2009 at 10:50 AM, Stef Mientki stef.mien...@gmail.comwrote: [...] In languages like Delphi, you get an error message, trying to use circular references, but solving them in large programs with a lot of history can be very painful. [...] === solution 1 === Inserting a launcher into the IDE, so instead of running the application as a script, the file will always be executed as a module. [...] Eh. If you must do it this way, just launch the program as 'python -c import modulename; modulename.main() arguments'. Then the __main__ becomes that little string. The only cost then becomes make sure there's a main function. That's pretty minimal isn't it? Sure you'll make changes to lots of different modules, but only once, and those changes are probably almost boilerplate and simple. === solution 2 === Prevent execution of the code in this file if the file is ran as a script. AHH RUN! RUN FOR YOUR LIFE :) Really.. at a certain point all these hacks to get Python to work in some weird-other-unpythony-way WILL come back and make your large program with lots of history descend into a pit of chaos and either rise up again and conquer the world in its evil ways, or, just decay and die under the weight of its own hacks :) [ I'm still slightly reeling, I admit, for the module you posted the other day which recursively added package directories to PYTHONPATH :) ] I can't help but think you're overestimating the very on very painful -- either way that's a one-time cost. I am responsible for maintaining a project whose non-thirdparty code totals about 157k lines over 690 files (Interesting statistic: including thirdparty code the project jumps to 644k over almost 2.5k files) and have on occasion had to go and do some global refactor to designs things I did before that were Badly when I was first learning big-projects-in-Python. Yeah it's a little painful. The overall reward of a more maintainable system down the road doing things in the natural Python way were so worth it :) But. YMMV :) --S if __name__=='__main__': import os, sys # determine the name of myself a = sys._getframe().f_code.co_filename X = os.path.splitext ( os.path.split(a)[1] ) [0] #import myself as 'ME' ME = __import__ ( X ) # run some code in myself ME.functional_code () # prevent that the code below is executed, # ( for the second time ) # if this file is used as a script sys.exit() print 'One time import code' def functional_code () : print 'Functional Code' any comment ? thanks, Stef Mientki -- http://mail.python.org/mailman/listinfo/python-list -- Stephen Hansen Development Advanced Prepress Technology shan...@advpubtech.com (818) 748-9282 -- http://mail.python.org/mailman/listinfo/python-list
Re: A new Internet-search website written in Python
On 10/10/09, John Nagle na...@animats.com wrote: hrg...@gmail.com wrote: The purpose of this email is to inform the Python-list mailing-list subscribers of an Internet-search website that is run by software written in Python. All the site seems to do is frame the results from other search engines. What does the Python code do? John Nagle That is correct, the result pages of the search engines are presented in frames, and the website doesn't do any searching itself. So it is not exactly a search engine. The Python code manages other aspects of the website, like URL mapping and generation of navigation items. Taro Taniguchi -- http://mail.python.org/mailman/listinfo/python-list
Re: Why ELIF?
On Oct 11, 3:42 pm, Esmail ebo...@hotmail.com wrote:
cool .. I hadn't seen that. Not working quite at the 'pythonic' level yet
I am not sure I think it's more readable that the if statement. Also, curious
if the dictionary approach is more efficient.
Somehow I doubt that Look up X in dictionary D could ever be more
efficient (in terms of space and time, at least) then Check if X is
equal to Y. It's not about what you get in runtime but what you get
in monkey time.
Most expressions that would make someone reach for a C-like switch()
statement can be expressed with dictionaries or attributes instead.
Here is a dorks approach to calling a specific function with arguments
based on a command:
args = re.split('\s', line)
cmd = args.pop(0)
if cmd == ham:
...(args)
elif cmd == spam:
...(args)
elif cmd == eggs:
...(args)
else:
raise SyntaxWarning(Syntax error in above program)
Here is more of a look up table approach:
Note: let Commands be a dictionary, such that { ham : ...,
spam : ..., eggs : ... }.
args = re.split('\s', line)
cmd = args.pop(0)
if cmd in Commands:
Commands[cmd](args)
else:
raise SyntaxWarning(Syntax error in above program)
What values does this second approach offer over the first one? The
most obvious one is that the program does more of the work, then the
maintenance programmer. In a more Object-Oriented light, you could
also fetch a member of an object at run time, and use that in place of
a dictionary. Take a look how the standard 'cmd' module dispatches
stuff.
I might take flak here, for writing something like 'dict[key]
(func_args)' instead of something more Pythonic, but the code serves
to express a point, not teach a system of branch of Zen :-P.
--
TerryP.
Just Another Programmer.
--
http://mail.python.org/mailman/listinfo/python-list
Re: getting equal behavior for scripts and modules ?
En Sun, 11 Oct 2009 14:50:31 -0300, Stef Mientki stef.mien...@gmail.com escribió: I do agree that circular references should preferable be avoided. In languages like Delphi, you get an error message, trying to use circular references, but solving them in large programs with a lot of history can be very painful. Now I finally (after 2 years) knowing there's a difference between modules and scripts, I want to guarantee that I always get the same functional behavior. In Delphi terms, you have units (.pas) and programs (.dpr). You can't add a .dpr to the Uses clause of an unit. In case you have some code in a .dpr that you want to use somewhere else, you move it into a new unit and Use it from both places. Translated to Python terms: you have modules and scripts. You shouldn't import a script from a module. In case you have some code in a script that you want to use somewhere else, move it into a new module and import it from both places. Note the change between can't and shouldn't. Delphi just won't let you import the main program from another place; Python does, with strange effects, but you should not do that. You can avoid the temptation by naming your scripts with another extension (or no extension at all). I found 2 solutions to realize the above. [...] Too much hassle and magic for what should be a non-issue. -- Gabriel Genellina -- http://mail.python.org/mailman/listinfo/python-list
Re: Why ELIF?
On Sun, Oct 11, 2009 at 2:15 PM, TerryP bigboss1...@gmail.com wrote:
On Oct 11, 3:42 pm, Esmail ebo...@hotmail.com wrote:
cool .. I hadn't seen that. Not working quite at the 'pythonic' level yet
I am not sure I think it's more readable that the if statement. Also, curious
if the dictionary approach is more efficient.
Somehow I doubt that Look up X in dictionary D could ever be more
efficient (in terms of space and time, at least) then Check if X is
equal to Y. It's not about what you get in runtime but what you get
in monkey time.
Most expressions that would make someone reach for a C-like switch()
statement can be expressed with dictionaries or attributes instead.
Here is a dorks approach to calling a specific function with arguments
based on a command:
args = re.split('\s', line)
cmd = args.pop(0)
if cmd == ham:
...(args)
elif cmd == spam:
...(args)
elif cmd == eggs:
...(args)
else:
raise SyntaxWarning(Syntax error in above program)
Here is more of a look up table approach:
Note: let Commands be a dictionary, such that { ham : ...,
spam : ..., eggs : ... }.
args = re.split('\s', line)
cmd = args.pop(0)
if cmd in Commands:
Commands[cmd](args)
else:
raise SyntaxWarning(Syntax error in above program)
I'll often do that this way:
args = re.split('\s', line)
cmd = args.pop(0)
def no_cmd(*a, **b):
raise SyntaxWarning(Syntax error in above program)
Commands.get(cmd, no_cmd)(args)
~Simon
--
http://mail.python.org/mailman/listinfo/python-list
Re: Persistent Distributed Objects
On Sun, Oct 11, 2009 at 12:46 PM, John Haggerty bouncy...@gmail.com wrote: Does pyro work inside of stackless? I have no idea, but you wouldn't need both. Only one or the other. ~Simon On Sat, Oct 10, 2009 at 9:54 AM, Simon Forman sajmik...@gmail.com wrote: On Fri, Oct 9, 2009 at 1:11 AM, John Haggerty bouncy...@gmail.com wrote: I am interested in seeing how it would be possible in python to have persistent objects (basically be able to save objects midway through a computation, etc) and do so across multiple computers. Something that would allow for memory, disk space, processing power, etc to be distributed across the nodes not just for number crunching. So for example a warehouse program started up on 3 machines one for adding orders, one for searching for orders, one for organizing the warehouse and them running on a different machine with a single interface. I've seen evidence about this being done wrt what looks like insanely complex stuff on this list but I'm wondering if there is something to do this with any number of nodes and just farm out random classes/objects to them? Check out Pyro (Python Remote Objects): http://pyro.sourceforge.net/ or perhaps Stackless Python http://www.stackless.com/ (Tasklets can be serialized and passed around.) -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: run exe and create exe
On Sun, Oct 11, 2009 at 11:15 AM, daved170 daved...@gmail.com wrote: Hi everybody, I have 2 questions: 1) I created my python application. It has QT Gui. How can I make exe of it? I don't want everytime I run the file it'll open the command line window which does nothing. Two things about this.. One, if you want to freeze your app (turn it into a finalized exe binary that doesn't require you to have Python or QT installed), use py2exe. The problem with this is that your final binary will include the Python interpreter, QT, and any other modules you use so it will be pretty big. The other thing you can do is run the script with pythonw.exe instead of python.exe. It will still be a Python script, but it will run without opening a command prompt. 2) My Application suppose to be a client server app. Anyhow, for now It's running only on local host. I added a button that run the server file. my server file located at c:\temp\server.py. It takes no arguments. I tried the following codes at the push button function: os.system(c:\temp\server.py) - It stuck my GUI. I guess that this function doesn't open a new proccess. It does open a new process. But the new process is a child process of your original script and the first script will wait for it to finish so that it can get the return code. I also tried : os.spawnv(os.P_NOWAIT,c:\temp\server.py); It raised the following error: OSError: [Errno 8] Exec format error. Any Idea what to do? In a normal string, \t = tab, so you're actually running the file C: emp\server.py which doesn't exist. Try using a raw string, double your backslashes, or use forward slashes instead. Thanks DaveD -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Why ELIF?
TerryP schrieb:
Note: let Commands be a dictionary, such that { ham : ...,
spam : ..., eggs : ... }.
args = re.split('\s', line)
cmd = args.pop(0)
if cmd in Commands:
Commands[cmd](args)
else:
raise SyntaxWarning(Syntax error in above program)
[...] I might take flak here, for writing something like 'dict[key]
(func_args)' instead of something more Pythonic, but the code serves
to express a point, not teach a system of branch of Zen :-P.
But this *is* pythonic. It must be, since Guido has identified it as a
Pattern and named it the Dommand Dispatch Pattern. Also, it is in
perfect compliance to The Zen (import this).
Regards,
Mick.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Why ELIF?
Simon Forman wrote:
[snip]
I'll often do that this way:
args = re.split('\s', line)
This has the same result, but is shorter and quicker:
args = line.split()
--
http://mail.python.org/mailman/listinfo/python-list
Re: datetime.datetime. or datetime. ?
On Oct 10, 8:43 pm, Carl Banks pavlovevide...@gmail.com wrote:
On Oct 10, 2:26 am, niklasr nikla...@gmail.com wrote:
On Oct 8, 10:17 pm, Carl Banks pavlovevide...@gmail.com wrote:
On Oct 8, 3:11 pm, niklasr nikla...@gmail.com wrote:
On Oct 8, 5:25 pm, Diez B. Roggisch de...@nospam.web.de wrote:
NiklasRTZ schrieb:
Hello, my basic question is which recommendation is after slight
restructuring datetime.datetime to datetime
Both works but only one should be chosen probably adjust my package
to
comply to dependencies.
Spec integrated code where datetime.datetime.now() refactored to
datetime.now()
set rather
from datetime import datetime, timedelta
than
import datetime
or no matter and completely flexible (then why gae error that
datetime.datetime wasn't datetime?)
Naturally better not to customize external dependencies but
seemingly
impossible to use both for a little xmpp project.
Thanks with best regards
Some remarks:
- whitespace is significant. In python. And in posting here.
- please show us the exact traceback you get, and a minimal example
that produces it.
- how to import is mostly a matter of taste, as long as you refrain
from using from datetime import *e
Diez
type object 'datetime.datetime' has no attribute 'datetime' Traceback
(most recent call last):
is flexible, both ways worked just that self complying towards more
professional projects naturally feels right. Above error log seemingly
caused by import datetime instead of from datetime import datetime.
Then changed import and cut the first datetime occurance which looks
good but breaks next sync with other. The project is the crowdguru
xmpp chat test reachable via gae app classifiedsmarket@
{gmail,appspot} currently importing
from datetime import datetime, timedelta
instead of
import datetime
Many thanks for the help and all further recommendation
code disponible montao.googlecode.com- Hide quoted text -
When you do this:
import datetime
you have to do this
d = datetime.datetime()
And when you do this:
from datetime import datetime
you have to do this:
d = datetime()
You evidently did this:
from datetime import datetime
then this:
d = datetime.datetime()
which is not allowed.
If you want to self-comply, I recommend always doing it the first way.
Understood it's a choice and to stay consistent with chosen. If the
first is recommended, why is second way possible?
Because not everything in Python is a professional project that
needs self-complying.
Also there are occasions where the second way is better. In a piece
of code that does a lot of math, would you rather write math.sin(x
+2) all over the place, or sin(x+2)?
Carl Banks
just sin(x+2) looks most natural. exactly why I asked, first module
and class or class and function have same name so we don't know which
is which, then conflict when dev1 uses one convention and dev2
another. I anyway complied towards the devendency so that next commit
from dev 2 is compatible with dev 1 and viceversa. My choice would
have been ...=datetime.now which was incompatible
with ...=datetime.datime.now() therefore just rather refactoring my
thing to comply with the dependecies than the other way, changing the
patch, appears the smoothest way here.
Thanks for all help
Niklas r
--
http://mail.python.org/mailman/listinfo/python-list
Re: getting equal behavior for scripts and modules ?
Stephen Hansen wrote: On Sun, Oct 11, 2009 at 10:50 AM, Stef Mientki stef.mien...@gmail.com mailto:stef.mien...@gmail.com wrote: [...] In languages like Delphi, you get an error message, trying to use circular references, but solving them in large programs with a lot of history can be very painful. [...] === solution 1 === Inserting a launcher into the IDE, so instead of running the application as a script, the file will always be executed as a module. [...] Eh. If you must do it this way, just launch the program as 'python -c import modulename; modulename.main() arguments'. Then the __main__ becomes that little string. The only cost then becomes make sure there's a main function. That's pretty minimal isn't it? Sure you'll make changes to lots of different modules, but only once, and those changes are probably almost boilerplate and simple. thanks for the tip, your suggestion works equally well, but I guess it will be somewhat more complicated to implement that as a general solution in an IDE. === solution 2 === Prevent execution of the code in this file if the file is ran as a script. AHH RUN! RUN FOR YOUR LIFE :) Really.. at a certain point all these hacks to get Python to work in some weird-other-unpythony-way WILL come back and make your large program with lots of history descend into a pit of chaos and either rise up again and conquer the world in its evil ways, or, just decay and die under the weight of its own hacks :) ok, I admit it's a little bit tricky, ... ... on the other hand, I don't see any invalid python statement in the code [ I'm still slightly reeling, I admit, for the module you posted the other day which recursively added package directories to PYTHONPATH :) ] Well that was / is a very rare case: Design specifications: - an general purpose builder / distributor / ... - minimalistic input from the user - all settings also available from a GUI So the most minimalistic input I can think of is : Exe_Files.append ( New_Program.py ) There is one simpeler line I can think of, namely : New_Program But as real life is somewhat more complicated, the last line isn't discriminative enough. In the final situation, given the above input, a distro should be build (through py2exe + lots of exceptions due to standard libs ;-) ), an inno setup installer should be created, the zip file should be uploaded and an announcement should be made. So without having to build a parser myself, the above code should be pure Python code. So if there's a better way to implement that one line of code (or in real life it might grow to 10 lines with user content) in a script performing these tasks, please let me know. thanks, Stef -- http://mail.python.org/mailman/listinfo/python-list
Error en el bus from python
Hi. I did installed a library for python named pyswip-0.2.2 but when I run a python example with the next lines, the python interpreter, it throw me the following error: Error en el bus. The code lines are: from pyswip.prolog import Prolog from pyswip.easy import getList, registerForeign N = 3 # Number of disks def main(): def notify(t): print move disk from %s pole to %s pole. % tuple(t) notify.arity = 1 prolog = Prolog() registerForeign(notify) prolog.consult(hanoi.pl) list(prolog.query(hanoi(%d) % N)) if __name__ == __main__: main() where hanoy.pl is a program with python code. Any solution for this error?. Thanks. -- http://mail.python.org/mailman/listinfo/python-list
Re: getting equal behavior for scripts and modules ?
Gabriel Genellina wrote: En Sun, 11 Oct 2009 14:50:31 -0300, Stef Mientki stef.mien...@gmail.com escribió: I do agree that circular references should preferable be avoided. In languages like Delphi, you get an error message, trying to use circular references, but solving them in large programs with a lot of history can be very painful. Now I finally (after 2 years) knowing there's a difference between modules and scripts, I want to guarantee that I always get the same functional behavior. In Delphi terms, you have units (.pas) and programs (.dpr). You can't add a .dpr to the Uses clause of an unit. In case you have some code in a .dpr that you want to use somewhere else, you move it into a new unit and Use it from both places. I never ever edited a dpr file, it's created fully automatically (don't know what is in it) and I even think you don't need to use it at all. In Delphi there's a main unit and other units, but it's up to the programmer which unit is set as the main unit. Although I admit (because of the forbidden circular references) that's not easy to use a unit designed as main, and use as normal unit or even better as a general purpose library. Translated to Python terms: you have modules and scripts. You shouldn't import a script from a module. In case you have some code in a script that you want to use somewhere else, move it into a new module and import it from both places. Note the change between can't and shouldn't. Delphi just won't let you import the main program from another place; well is does, notice Delphi has 2 locations for the uses clause ! Python does, with strange effects, but you should not do that. You can avoid the temptation by naming your scripts with another extension (or no extension at all). Going from Delphi to Python, using a module (unit) both as standalone program and a library for other programs, was a beautiful relief. Now finally I could play with software as if it was Lego ( those children building blocks). And indeed I've a few stand alone Python applications, that can fully be embedded in other Python applications and docked in their GUI. I found 2 solutions to realize the above. [...] Too much hassle and magic for what should be a non-issue. If you choose for a strict separation between script and module, I guess it's indeed a non-issue. Using software as if it was Lego, needs either a detection or prevention of effects of the difference between script and module. thanks, Stef -- http://mail.python.org/mailman/listinfo/python-list
Re: Why ELIF?
On Sun, 11 Oct 2009 11:15:06 -0700, TerryP wrote: On Oct 11, 3:42 pm, Esmail ebo...@hotmail.com wrote: cool .. I hadn't seen that. Not working quite at the 'pythonic' level yet I am not sure I think it's more readable that the if statement. Also, curious if the dictionary approach is more efficient. Somehow I doubt that Look up X in dictionary D could ever be more efficient (in terms of space and time, at least) then Check if X is equal to Y. It's not about what you get in runtime but what you get in monkey time. A single equality check, obviously not. Now suppose you have 100 conditions to test. Which is faster, one dict lookup, or up to 100 separate if X == Y tests? (On average, you need to test half the conditions before finding the match.) Hint: dicts are used internally by Python for storing names. I might take flak here, for writing something like 'dict[key] (func_args)' instead of something more Pythonic, Looking up a first-class function in a dictionary and passing arguments to it is perfectly Pythonic. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: The rap against while True: loops
Mensanator wrote: On Oct 10, 3:15�pm, kj no.em...@please.post wrote: I'm coaching a group of biologists on basic Python scripting. �One of my charges mentioned that he had come across the advice never to use loops beginning with while True. �Of course, that's one way to start an infinite loop, but this seems hardly a sufficient reason to avoid the construct altogether, as long as one includes an exit that is always reached. �(Actually, come to think of it, there are many situations in which a bona fide infinite loops (typically within a try: block) is the required construct, e.g. when implementing an event loop.) I use while True-loops often, and intend to continue doing this while True, but I'm curious to know: how widespread is the injunction against such loops? �Has it reached the status of best practice? If you know this exit that is always reached, why do you pretend not to know it by writing while True? When I'm starting to code something I haven't yet fully worked out, it often starts with an infinite loop like this, until the body is coded and I've figured out how to escape from it. At the end if may or may not be tidied up, depending on how much work it is to reconcile several possible break points into a single terminating condition to be place at one end, and whether that is likely to break or obfuscate a currently working program. But if it's never going to be seen by the brigade who hate all break, exit, goto and multiple return statements, then I won't bother. -- Bartc -- http://mail.python.org/mailman/listinfo/python-list
Re: Why ELIF?
On Oct 11, 7:10 am, Grant Edwards inva...@invalid.invalid wrote: On 2009-10-11, metal metal...@gmail.com wrote: I wonder the reason for ELIF. it's not aligned with IF, make code ugly It most certainly is aligned with IF: if cond1: do this elif cond2: do that else: do the other The if elif and else are all aligned in all of the code I've ever seen. The condition in the elif clause is two columns to the right of the condition in the if clause. It's a silly thing to worry about, in fact the slight visual distinctness of it probably helps readability. Some people do get finicky about columns and try to line things up all the time. It's frustrating, wasteful, and ultimately hopeless, and sometimes deceptive (lining things up can suggest relationships where none exists) so I make it a point not to do it, however prettier it'll make those two lines. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: getting equal behavior for scripts and modules ?
On Sun, 11 Oct 2009 19:50:31 +0200, Stef Mientki wrote: Now I finally (after 2 years) knowing there's a difference between modules and scripts, I want to guarantee that I always get the same functional behavior. You are confused. Scripts *are* modules. What makes a script a script is that it is executed from the shell: $ python ~/scripts/helloworld.py Hello World. $ The difference isn't between files which *are* scripts and files which *are* modules, but between modules which do something useful when *run as a script* versus modules which don't. Recent versions of Python even include a switch -m that searches the sys.path for the named module and runs the module's .py file as a script. You don't get the same behaviour between *running* a module and *importing* a module because they do different thing. When you say import module inside the Python environment, the module goes through the import machine. When you say python script.py in the shell, it doesn't. When you import a module, Python looks to see if it has already been imported, and if it has, it returns the module object in the cache. If not, then it does a whole lot of magic which includes executing the code inside the module. This means that modules get executed only once in any session (unless you remove it from the cache). When you run a module as a script from the shell, it doesn't go through the import machinery, it doesn't get looked up in the cache, and it gets executed every time. The consequence of this is that if you run a module as a script, it gets executed. If, in the process of being executed, it imports itself (directly or indirectly), the import machinery has to run it again. Hence the module gets executed twice. I found 2 solutions to realize the above. Over-engineered overly-complicated non-solution to a non-problem. The simplest solution is as follows: code that must always be executed goes in the body of the module. Code that *only* gets executed when running as a script goes under a test: if __name__ == '__main__': # running as a script # code goes here pass That code will *only* run when running as a script, and not when you import the module. Everything outside such a test will always run. If you don't want that distinction, then don't use such a test. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Error en el bus from python
On Sun, 11 Oct 2009 13:45:54 -0700, Yusniel wrote: Hi. I did installed a library for python named pyswip-0.2.2 but when I run a python example with the next lines, the python interpreter, it throw me the following error: Error en el bus. ... where hanoy.pl is a program with python code. Any solution for this error?. Thanks. Please post the entire traceback. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: The rap against while True: loops
On Oct 11, 4:51�pm, bartc ba...@freeuk.com wrote: Mensanator wrote: On Oct 10, 3:15 pm, kj no.em...@please.post wrote: I'm coaching a group of biologists on basic Python scripting. One of my charges mentioned that he had come across the advice never to use loops beginning with while True. Of course, that's one way to start an infinite loop, but this seems hardly a sufficient reason to avoid the construct altogether, as long as one includes an exit that is always reached. (Actually, come to think of it, there are many situations in which a bona fide infinite loops (typically within a try: block) is the required construct, e.g. when implementing an event loop.) I use while True-loops often, and intend to continue doing this while True, but I'm curious to know: how widespread is the injunction against such loops? Has it reached the status of best practice? If you know this exit that is always reached, why do you pretend not to know it by writing while True? When I'm starting to code something I haven't yet fully worked out, it often starts with an infinite loop like this, until the body is coded and I've figured out how to escape from it. And when I'm in the early stages of a while not done: loop, it performs the exact same functionality while I'm working out what the terminating conditions are. At the end if may or may not be tidied up, depending on how much work it is to reconcile several possible break points into a single terminating condition to be place at one end, and whether that is likely to break or obfuscate a currently working program. Yes, that's a problem and is a good reason to avoid doing such a thing. With multiple breaks, your loop may not properly terminates which may put an unecessary burden on the code which follows the loop. Seeing the trees is important, but not at the expense of the forest. But if it's never going to be seen by the brigade who hate all break, exit, goto and multiple return statements, then I won't bother. Fine, but the OP is coaching others on how to program. I've not seen any evidence in this thread that while true is considered best practice. -- Bartc -- http://mail.python.org/mailman/listinfo/python-list
Re: The rap against while True: loops
On Oct 11, 2009, at 5:51 PM, bartc wrote: Mensanator wrote: On Oct 10, 3:15�pm, kj no.em...@please.post wrote: I'm coaching a group of biologists on basic Python scripting. �One of my charges mentioned that he had come across the advice never to use loops beginning with while True. �Of course, that's one way to start an infinite loop, but this seems hardly a sufficient reason to avoid the construct altogether, as long as one includes an exit that is always reached. �(Actually, come to think of it, there are many situations in which a bona fide infinite loops (typically within a try: block) is the required construct, e.g. when implementing an event loop.) I use while True-loops often, and intend to continue doing this while True, but I'm curious to know: how widespread is the injunction against such loops? �Has it reached the status of best practice? If you know this exit that is always reached, why do you pretend not to know it by writing while True? When I'm starting to code something I haven't yet fully worked out, it often starts with an infinite loop like this, until the body is coded and I've figured out how to escape from it. At the end if may or may not be tidied up, depending on how much work it is to reconcile several possible break points into a single terminating condition to be place at one end, and whether that is likely to break or obfuscate a currently working program. But if it's never going to be seen by the brigade who hate all break, exit, goto and multiple return statements, then I won't bother. I think you bring up a good point. I think while True has some legitimate uses (like event loops), and I don't mind seeing it there. What I don't like is goto, and to a lesser extent break, exit, and multiple returns. I don't find too many cases where they're the clearest way to express things. And where one sees a while True, one can almost always find a break or two lurking in the loop. IMHO, break, goto, etc. have their place, but they're ripe for abuse which leads to spaghetti code. Since the OP is teaching non- programmers to write code, I think the potential for abuse is especially important to keep in mind. I'd think that teaching them a tool like while True would encourage the code now, design later trap that even experienced programmers -- including myself -- sometimes fall into. Writing while condition instead forces one to stop at the beginning of the loop and think at least a little about exactly what it's meant to accomplish. In addition, isn't it easier to figure out how this loop ends -- while (condition1) and (condition2) and (condition3): ...lots of code here... than this one? while True: ...lots of code here... if not condition1: break ...lots of code here... if not condition2: break ...lots of code here... if not condition3: break My $.02, Philip -- http://mail.python.org/mailman/listinfo/python-list
What do I do now?
I've been programming since about 3 years, and come to think of it never written anything large. I know a few languages: c, python, perl, java. Right now, I just write little IRC bots that basically don't do anything. I have two questions: 1) What should I start programming (project that takes 1-2 months, not very short term)? 2) Whtat are some good open source projects I can start coding for? I'd rather not just waste time programming little useless things all the time. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why ELIF?
On Oct 11, 5:05�pm, Carl Banks pavlovevide...@gmail.com wrote: On Oct 11, 7:10�am, Grant Edwards inva...@invalid.invalid wrote: On 2009-10-11, metal metal...@gmail.com wrote: I wonder the reason for ELIF. it's not aligned with IF, make code ugly It most certainly is aligned with IF: � if cond1: � � � do this � elif cond2: � � � do that � else: � � � do the other The if elif and else are all aligned in all of the code I've ever seen. The condition in the elif clause is two columns to the right of the condition in the if clause. Why does that matter? Isn't whitespace only significant at the start of a line? It's a silly thing to worry about, in fact the slight visual distinctness of it probably helps readability. It doesn't, but you're right, it's silly to worry about. �Some people do get finicky about columns and try to line things up all the time. � But you can do it if you really want to: a = 1 if a5: print a elifa 10: print a / 3 else: print 'error' It's frustrating, wasteful, and ultimately hopeless, and sometimes deceptive (lining things up can suggest relationships where none exists) so I make it a point not to do it, however prettier it'll make those two lines. The above example is of dubious value. Where I use it is places like ONE = gmpy.mpz( 1) TWO = gmpy.mpz( 2) THREE = gmpy.mpz( 3) TEN = gmpy.mpz(10) Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: Why ELIF?
On Oct 11, 4:12 pm, Mensanator mensana...@aol.com wrote: On Oct 11, 5:05 pm, Carl Banks pavlovevide...@gmail.com wrote: On Oct 11, 7:10 am, Grant Edwards inva...@invalid.invalid wrote: On 2009-10-11, metal metal...@gmail.com wrote: I wonder the reason for ELIF. it's not aligned with IF, make code ugly It most certainly is aligned with IF: if cond1: do this elif cond2: do that else: do the other The if elif and else are all aligned in all of the code I've ever seen. The condition in the elif clause is two columns to the right of the condition in the if clause. Why does that matter? Isn't whitespace only significant at the start of a line? I don't think it matters. I'm explaining what the OP is complaining about. It's a silly thing to worry about, in fact the slight visual distinctness of it probably helps readability. It doesn't, but you're right, it's silly to worry about. No it helps me, not much, but a little. Whether the columns line up or not is a visual clue that can help spot errors. For instance, noticing that condition1 and contition2 line up might help me spot the error in the following code (second clause should be elif). if condition1: xxx() if contidion2: yyy() else: zzz() It might never help you, but that doesn't mean it can't help others. I can only recall once or twice being alerted to this mistake by column alignment, and definitely can recall several times where I missed it in spite of the extra visual clue. All I said is it was a slight visual clue, not an earth-shattering deal maker. Some people do get finicky about columns and try to line things up all the time. But you can do it if you really want to: a = 1 if a 5: print a elif a 10: print a / 3 else: print 'error' Ugh. It's frustrating, wasteful, and ultimately hopeless, and sometimes deceptive (lining things up can suggest relationships where none exists) so I make it a point not to do it, however prettier it'll make those two lines. The above example is of dubious value. Where I use it is places like ONE = gmpy.mpz( 1) TWO = gmpy.mpz( 2) THREE = gmpy.mpz( 3) TEN = gmpy.mpz(10) I never line up columns except when defining some kind of table. (E.g., PyMemberDef in a C module.) What happens when you have to add a constant like this: A_HUNDRED_MILLION = gmmp.mpz(1) Now you have to widen a dozen pair of parentheses, and the readability suffers when you have all kinds of space separating things: ONE = gmpy.mpz(1) Plus this has the implied fictional realtionship problem I mentioned (although not too dangerous or misleading here). It'd have been better not to have bothered. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Inserting into a database
Hello Guy's I am using python 2.6 on windows 7 and MySQLdb to make connections to the database.The issue here is that I am not able to insert from the python script to the database.When I run the same query in mysql query brower then the insert statement works .I am able to select from the database using the python script.The connection is fine.I am using Aptana to write the python script. I thought this could be a problem of the collation or character set problem the default character set of the system is cp1252 which corrosponds to latin_1 on mysql , I have chosen that and still no help. Any help is appreciated. Thanks Aditya -- http://mail.python.org/mailman/listinfo/python-list
Re: Inserting into a database
On Sun, Oct 11, 2009 at 4:46 PM, aditya shukla adityashukla1...@gmail.comwrote: Hello Guy's I am using python 2.6 on windows 7 and MySQLdb to make connections to the database.The issue here is that I am not able to insert from the python script to the database.When I run the same query in mysql query brower then the insert statement works .I am able to select from the database using the python script.The connection is fine.I am using Aptana to write the python script. No one will be able to help you unless you say precisely what I am not able to insert even means. Provide an actual line or three of code where the error's happening, and the full / complete traceback. Otherwise, the only thing anyone will be able to do is guess wildly. Which no one is likely to do :) --S -- http://mail.python.org/mailman/listinfo/python-list
Re: Inserting into a database
Hello Guys I am using python 2.6 on windows 7 and MySQLdb to make connections to the database.The issue here is that I am not able to insert from the python script to the database.When I run the same query in mysql query brower then the insert statement works .I am able to select from the database using the python script.The connection is fine.I am using Aptana to write the python script. I thought this could be a problem of the collation or character set problem the default character set of the system is cp1252 which corrosponds to latin_1 on mysql , I have chosen that and still no help. Any help is appreciated. this what the code looks like. db = MySQLdb.connect(localhost,root,juventus12,factoids,charset = utf8, use_unicode = True ) cursor= db.cursor() # i added charset = utf8, use_unicode = True just now and changed the character set of mysql still no help. cursor.execute(INSERT INTO question_table (question_id,source_id,question) VALUES (5,1,question)) language, output_encoding = locale.getdefaultlocale() print output_encoding, language traceback C:\Python26\lib\site-packages\MySQLdb\__init__.py:34: DeprecationWarning: the sets module is deprecated from sets import ImmutableSet cp1252 en_US Thanks Aditya -- http://mail.python.org/mailman/listinfo/python-list
Re: Inserting into a database
On Sun, Oct 11, 2009 at 5:06 PM, aditya shukla adityashukla1...@gmail.comwrote: Hello Stephen, I have put the code and the traceback.Can you please help me now? .I am scratching my head :) I am using python 2.6 on windows 7 and MySQLdb to make connections to the database.The issue here is that I am not able to insert from the python script to the database.When I run the same query in mysql query brower then the insert statement works .I am able to select from the database using the python script.The connection is fine.I am using Aptana to write the python script. I thought this could be a problem of the collation or character set problem the default character set of the system is cp1252 which corrosponds to latin_1 on mysql , I have chosen that and still no help. Any help is appreciated. this what the code looks like. db = MySQLdb.connect(localhost,root,juventus12,factoids,charset = utf8, use_unicode = True ) cursor= db.cursor() # i added charset = utf8, use_unicode = True just now and changed the character set of mysql still no help. cursor.execute(INSERT INTO question_table (question_id,source_id,question) VALUES (5,1,question)) language, output_encoding = locale.getdefaultlocale() print output_encoding, language traceback C:\Python26\lib\site-packages\MySQLdb\__init__.py:34: DeprecationWarning: the sets module is deprecated from sets import ImmutableSet cp1252 en_US Thanks Aditya -- http://mail.python.org/mailman/listinfo/python-list
Re: Inserting into a database
On Sun, Oct 11, 2009 at 5:06 PM, aditya shukla adityashukla1...@gmail.comwrote: this what the code looks like. db = MySQLdb.connect(localhost,root,juventus12,factoids,charset = utf8, use_unicode = True ) cursor= db.cursor() # i added charset = utf8, use_unicode = True just now and changed the character set of mysql still no help. cursor.execute(INSERT INTO question_table (question_id,source_id,question) VALUES (5,1,question)) First, I just suggest you use single quotes around string data in SQL. Even though mySQL allows double quotes in that context. Second, it looks like you just need to commit. E.g., db.commit() --S language, output_encoding = locale.getdefaultlocale() print output_encoding, language traceback C:\Python26\lib\site-packages\MySQLdb\__init__.py:34: DeprecationWarning: the sets module is deprecated from sets import ImmutableSet cp1252 en_US Thanks Aditya -- Stephen Hansen Development Advanced Prepress Technology shan...@advpubtech.com (818) 748-9282 -- http://mail.python.org/mailman/listinfo/python-list
Re: An assessment of Tkinter and IDLE
A few things i forgot to mention... +--+ Things i forgot... IDLE Editor +--+ 1. class and path browsers should be available in a tabbed widget located in the left side of the Editor window. Should also have a show/ hide button or have them contained in a paned window for user reszing. +--+ Things i forgot... Tkinter +--+ 1. Class naming makes no sense...? Text should be TextBox Radiobutton should be RadioButton Checkbutton should be CheckButton ListBox should be ListBox (but at least Text should be Textbox!) 2. All text related widgets (Text, Listbox, Entry, Label, CheckButton, RadioButton, should have a w.sets(setstr) and w.gets(getstr) methods along with their .insert() method. The settr/getter methods should take any argument in the form of [str, lst, tuple] and insert the lines automatically. Why you ask. Well because i hate calling... w.delete(start, stop) w.insert(END, str) #-- or even worse for x in collection: w.insert(END, x) #-- this should be the correct ways w.sets([1,2,3]) w.sets((1,2,3)) w.sets(line1\nline2\nline3\n) #splits lines for listbox thats all for now folks! -- http://mail.python.org/mailman/listinfo/python-list
Re: Why ELIF?
MRAB python at mrabarnett.plus.com writes:
Simon Forman wrote:
[snip]
I'll often do that this way:
args = re.split('\s', line)
This has the same result, but is shorter and quicker:
args = line.split()
HUH?
Shorter and quicker, yes, but provides much better functionality; it's NOT the
same result:
line = ' aaa bbb ccc '
import re
re.split('\s', line)
['', '', '', 'aaa', '', '', 'bbb', '', '', 'ccc', '', '', '']
line.split()
['aaa', 'bbb', 'ccc']
--
http://mail.python.org/mailman/listinfo/python-list
Re: The rap against while True: loops
On Oct 11, 6:46 pm, Philip Semanchuk phi...@semanchuk.com wrote:
On Oct 11, 2009, at 5:51 PM, bartc wrote:
Mensanator wrote:
On Oct 10, 3:15 pm, kj no.em...@please.post wrote:
I'm coaching a group of biologists on basic Python scripting. One
of my charges mentioned that he had come across the advice never
to use loops beginning with while True. Of course, that's one
way to start an infinite loop, but this seems hardly a sufficient
reason to avoid the construct altogether, as long as one includes
an exit that is always reached. (Actually, come to think of it,
there are many situations in which a bona fide infinite loops
(typically within a try: block) is the required construct, e.g.
when implementing an event loop.)
I use while True-loops often, and intend to continue doing this
while True, but I'm curious to know: how widespread is the
injunction against such loops? Has it reached the status of best
practice?
If you know this exit that is always reached,
why do you pretend not to know it by writing
while True?
When I'm starting to code something I haven't yet fully worked out,
it often starts with an infinite loop like this, until the body is
coded and I've figured out how to escape from it.
At the end if may or may not be tidied up, depending on how much
work it is to reconcile several possible break points into a single
terminating condition to be place at one end, and whether that is
likely to break or obfuscate a currently working program.
But if it's never going to be seen by the brigade who hate all
break, exit, goto and multiple return statements, then I won't bother.
I think you bring up a good point. I think while True has some
legitimate uses (like event loops), and I don't mind seeing it there.
What I don't like is goto, and to a lesser extent break, exit, and
multiple returns. I don't find too many cases where they're the
clearest way to express things. And where one sees a while True, one
can almost always find a break or two lurking in the loop.
IMHO, break, goto, etc. have their place, but they're ripe for abuse
which leads to spaghetti code. Since the OP is teaching non-
programmers to write code, I think the potential for abuse is
especially important to keep in mind. I'd think that teaching them a
tool like while True would encourage the code now, design later
trap that even experienced programmers -- including myself --
sometimes fall into. Writing while condition instead forces one to
stop at the beginning of the loop and think at least a little about
exactly what it's meant to accomplish.
I was a bit surprised that nobody in this discussion so far bantered
around the phrase loop invariant, but then I looked in
http://en.wikipedia.org/wiki/Loop_invariant and found it was draped in
so much formalism that it's sure to put off all but the most dedicated
of Computer Science fans. I haven't been in college in 35 years, so
I'll admit to being rusty on this, but as I remember it, any time we
wrote a loop, we were expected to be able to say what the loop
invariant is.
my_prissy_little_indicator_variable = true
while (my_prissy_little_indicator_variable){
body
}
isn't satisfying because it doesn't guard the body with any
assurance that the loop invariant will be true before you enter into
that block of code.
Similarly, the
Repeat {
first part
if (exit condition) break
second part
}
doesn't guard the first part code. Worse, when you get to the
Repeat in reading the code, you get no clue about when the loop will
terminate, except maybe for a comment that someone helpfully put by
the loop, but as the program evolves, the comments often lie.
I don't mind while(true) for the case of do forever like those
launcher requirements Peter Billam wrote about up above in this
thread. It essentially says the loop invariant is that the system
hasn't crashed yet. But beware of the universal structured
program:
pc=1
while(pc!=0){
select(pc){
case 1:
body1
pc=next block #
continue
case 2:
body2
}
}
# Look Ma! No goto statements
There are no goto statements but the universal structured program
has no meaningful structure visible to the casual reader's eye..
By making the setting of PC in each case be conditional, you can send
the program to any bodyN that you want. (Think of pc as standing
for program counter and you can see this has as much structure as
assembler language. Very hard to judge that the code always keeps
array references within bounds and that all loops are only entered
when the loop invariant holds and that the loops always terminate when
the loop invariant no longer holds. You might as well be programming
like its 1959. See, it wasn't just the presence of goto's that was
harmful, it was the lack of careful construction of the program that
was harmful.
And just to dust off
Re: The rap against while True: loops
En Sun, 11 Oct 2009 19:46:06 -0300, Philip Semanchuk phi...@semanchuk.com escribió: On Oct 11, 2009, at 5:51 PM, bartc wrote: Mensanator wrote: On Oct 10, 3:15�pm, kj no.em...@please.post wrote: I'm coaching a group of biologists on basic Python scripting. �One of my charges mentioned that he had come across the advice never to use loops beginning with while True.[...] If you know this exit that is always reached, why do you pretend not to know it by writing while True? When I'm starting to code something I haven't yet fully worked out, it often starts with an infinite loop like this, until the body is coded and I've figured out how to escape from it. At the end if may or may not be tidied up, depending on how much work it is to reconcile several possible break points into a single terminating condition to be place at one end, and whether that is likely to break or obfuscate a currently working program. I think you bring up a good point. I think while True has some legitimate uses (like event loops), and I don't mind seeing it there. What I don't like is goto, and to a lesser extent break, exit, and multiple returns. I don't find too many cases where they're the clearest way to express things. And where one sees a while True, one can almost always find a break or two lurking in the loop. IMHO, break, goto, etc. have their place, but they're ripe for abuse which leads to spaghetti code. Since the OP is teaching non-programmers to write code, I think the potential for abuse is especially important to keep in mind. I'd think that teaching them a tool like while True would encourage the code now, design later trap that even experienced programmers -- including myself -- sometimes fall into. Writing while condition instead forces one to stop at the beginning of the loop and think at least a little about exactly what it's meant to accomplish. I don't think so; forcing ALL loops to have the condition at the start is unnatural in some cases. Some loops are best written with the condition at the end (do/while or repeat/until in Pascal) and some loops require a test in the middle (in Python, while True: + break, because we don't have an unconditional loop). In addition, isn't it easier to figure out how this loop ends -- while (condition1) and (condition2) and (condition3): ...lots of code here... than this one? while True: ...lots of code here... if not condition1: break ...lots of code here... if not condition2: break ...lots of code here... if not condition3: break For a loop that can be written as the first one above, sure, that's pretty explicit. For a loop as the second one, try to rewrite it with the condition at the start: you'll end with duplicated tests and/or duplicated code and/or artificial boolean variables added. Some algorithms are *naturally* expressed as a loop with the condition in the middle. Forcing the condition to always happen at the start requires artificial steps that complicate unnecesarily the code. -- Gabriel Genellina -- http://mail.python.org/mailman/listinfo/python-list
Re: Error en el bus from python
On 11 oct, 18:29, Steven D'Aprano st...@remove-this- cybersource.com.au wrote: On Sun, 11 Oct 2009 13:45:54 -0700, Yusniel wrote: Hi. I did installed a library for python named pyswip-0.2.2 but when I run a python example with the next lines, the python interpreter, it throw me the following error: Error en el bus. ... where hanoy.pl is a program with python code. Any solution for this error?. Thanks. Please post the entire traceback. -- Steven Steven. Thanks for your answer. In this case, I am running the script in a terminal and the error is: Error en el bus only this, not more. Any idea?. -- http://mail.python.org/mailman/listinfo/python-list
Re: Error en el bus from python
On Oct 11, 2009, at 4:45 PM, Yusniel wrote: Hi. I did installed a library for python named pyswip-0.2.2 but when I run a python example with the next lines, the python interpreter, it throw me the following error: Error en el bus. The code lines are: from pyswip.prolog import Prolog from pyswip.easy import getList, registerForeign N = 3 # Number of disks def main(): def notify(t): print move disk from %s pole to %s pole. % tuple(t) notify.arity = 1 prolog = Prolog() registerForeign(notify) prolog.consult(hanoi.pl) list(prolog.query(hanoi(%d) % N)) if __name__ == __main__: main() where hanoy.pl is a program with python code. Any solution for this error?. Thanks. Are you on a Mac by any chance? I get a bus error out of Python once in a while, usually when a C library has done something bad. I don't know if this error is specific to OS X or not. The first thing you need to do is comment out lines one by one to see where the problem occurs. I'd start by commenting out all four calls to the pyswip.prolog library: # prolog = Prolog() # registerForeign(notify) # prolog.consult(hanoi.pl) # list(prolog.query(hanoi(%d) % N)) If the bus error no longer occurs, then you know the problem is in the pyswip.prolog library. With that knowledge, I'd move to the mailing list or newsgroup for pyswip. Hope that helps Philip -- http://mail.python.org/mailman/listinfo/python-list
Re: The rap against while True: loops
En Sun, 11 Oct 2009 23:01:47 -0300, RDrewD drewl...@gmail.com escribió:
On Oct 11, 6:46 pm, Philip Semanchuk phi...@semanchuk.com wrote:
On Oct 11, 2009, at 5:51 PM, bartc wrote:
Mensanator wrote:
On Oct 10, 3:15 pm, kj no.em...@please.post wrote:
I'm coaching a group of biologists on basic Python scripting. One
of my charges mentioned that he had come across the advice never
to use loops beginning with while True. Of course, that's one
way to start an infinite loop, but this seems hardly a sufficient
reason to avoid the construct altogether, as long as one includes
an exit that is always reached. (Actually, come to think of it,
there are many situations in which a bona fide infinite loops
(typically within a try: block) is the required construct, e.g.
when implementing an event loop.)
I use while True-loops often, and intend to continue doing this
while True, but I'm curious to know: how widespread is the
injunction against such loops? Has it reached the status of best
practice?
If you know this exit that is always reached,
why do you pretend not to know it by writing
while True?
When I'm starting to code something I haven't yet fully worked out,
it often starts with an infinite loop like this, until the body is
coded and I've figured out how to escape from it.
At the end if may or may not be tidied up, depending on how much
work it is to reconcile several possible break points into a single
terminating condition to be place at one end, and whether that is
likely to break or obfuscate a currently working program.
But if it's never going to be seen by the brigade who hate all
break, exit, goto and multiple return statements, then I won't bother.
I think you bring up a good point. I think while True has some
legitimate uses (like event loops), and I don't mind seeing it there.
What I don't like is goto, and to a lesser extent break, exit, and
multiple returns. I don't find too many cases where they're the
clearest way to express things. And where one sees a while True, one
can almost always find a break or two lurking in the loop.
IMHO, break, goto, etc. have their place, but they're ripe for abuse
which leads to spaghetti code. Since the OP is teaching non-
programmers to write code, I think the potential for abuse is
especially important to keep in mind. I'd think that teaching them a
tool like while True would encourage the code now, design later
trap that even experienced programmers -- including myself --
sometimes fall into. Writing while condition instead forces one to
stop at the beginning of the loop and think at least a little about
exactly what it's meant to accomplish.
I was a bit surprised that nobody in this discussion so far bantered
around the phrase loop invariant, but then I looked in
http://en.wikipedia.org/wiki/Loop_invariant and found it was draped in
so much formalism that it's sure to put off all but the most dedicated
of Computer Science fans. I haven't been in college in 35 years, so
I'll admit to being rusty on this, but as I remember it, any time we
wrote a loop, we were expected to be able to say what the loop
invariant is.
my_prissy_little_indicator_variable = true
while (my_prissy_little_indicator_variable){
body
}
isn't satisfying because it doesn't guard the body with any
assurance that the loop invariant will be true before you enter into
that block of code.
I think you meant the other way; the above is the simplest loop case, with
the test at the start. A loop with the test at the end, on the other hand,
is slightly harder to prove correct (but not much).
As an example, Ada has a general loop construct like this:
loop
...
exit when some_condition;
...
end loop;
and LOTS of work has been done in proving correctness of Ada programs, so
having the test at the start/middle/end of the loop is not an obstacle for
formal verification.
--
Gabriel Genellina
--
http://mail.python.org/mailman/listinfo/python-list
Re: Why ELIF?
On Oct 11, 6:43�pm, Carl Banks pavlovevide...@gmail.com wrote: On Oct 11, 4:12�pm, Mensanator mensana...@aol.com wrote: On Oct 11, 5:05 pm, Carl Banks pavlovevide...@gmail.com wrote: On Oct 11, 7:10 am, Grant Edwards inva...@invalid.invalid wrote: On 2009-10-11, metal metal...@gmail.com wrote: I wonder the reason for ELIF. it's not aligned with IF, make code ugly It most certainly is aligned with IF: if cond1: do this elif cond2: do that else: do the other The if elif and else are all aligned in all of the code I've ever seen. The condition in the elif clause is two columns to the right of the condition in the if clause. Why does that matter? Isn't whitespace only significant at the start of a line? I don't think it matters. �I'm explaining what the OP is complaining about. It's a silly thing to worry about, in fact the slight visual distinctness of it probably helps readability. It doesn't, but you're right, it's silly to worry about. No it helps me, not much, but a little. �Whether the columns line up or not is a visual clue that can help spot errors. �For instance, noticing that condition1 and contition2 line up might help me spot the error in the following code (second clause should be elif). if condition1: � � xxx() if contidion2: � � yyy() else: � � zzz() It might never help you, but that doesn't mean it can't help others. I can only recall once or twice being alerted to this mistake by column alignment, and definitely can recall several times where I missed it in spite of the extra visual clue. �All I said is it was a slight visual clue, not an earth-shattering deal maker. Some people do get finicky about columns and try to line things up all the time. But you can do it if you really want to: a � � � � �= �1 if � � �a � �5: � print a elif � �a � 10: � print a �/ �3 else: � print 'error' Ugh. It's frustrating, wasteful, and ultimately hopeless, and sometimes deceptive (lining things up can suggest relationships where none exists) so I make it a point not to do it, however prettier it'll make those two lines. The above example is of dubious value. Where I use it is places like ONE � = gmpy.mpz( 1) TWO � = gmpy.mpz( 2) THREE = gmpy.mpz( 3) TEN � = gmpy.mpz(10) I never line up columns except when defining some kind of table. (E.g., PyMemberDef in a C module.) �What happens when you have to add a constant like this: A_HUNDRED_MILLION = gmmp.mpz(1) Now you have to widen a dozen pair of parentheses, and the readability suffers when you have all kinds of space separating things: ONE � � � � � � � = gmpy.mpz( � � � �1) Plus this has the implied fictional realtionship problem I mentioned (although not too dangerous or misleading here). �It'd have been better not to have bothered. I would much prefer this A_HUNDRED_MILLION = gmpy.mpz(1) ONE = gmpy.mpz(1) to this HUMPTY = gmpy.mpz(3876497) DUMPTY = gmpy.mpz(912350) ALICE = gmpy.mpz(1278657) WHT_RABBIT = gmpy.mpz(75648) CHESHIRE = gmpy.mpz(913237) anyday. But that's me. The only one who has to read my code is me and I like to be able to follow my thoughts at a later date. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: Delete all list entries of length unknown
On Oct 4, 11:05 pm, Mark Tolonen metolone+gm...@gmail.com wrote: Chris Rebert c...@rebertia.com wrote in message Tuples are immutable (i.e. they cannot be modified after creation) and are createdusingparentheses. Slight correction: tuples are createdusingcommas. Parentheses are only needed to disambiguate from other uses ofcomma: Python 2.6.2 (r262:71605, Apr 14 2009, 22:40:02) [MSC v.1500 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. a=1, a (1,) a=1,2,3 a (1, 2, 3) uhh? what python you using? t = () t () type(t) type 'tuple' ;-) -- http://mail.python.org/mailman/listinfo/python-list
Re: Error en el bus from python
On Oct 11, 2009, at 11:56 PM, Dennis Lee Bieber wrote: On Sun, 11 Oct 2009 13:45:54 -0700 (PDT), Yusniel yhidalg...@gmail.com declaimed the following in gmane.comp.python.general: prolog.consult(hanoi.pl) snip where hanoy.pl is a program with python code. Any solution for this error?. Thanks. Are you sure? .pl is a common extension for PERL programs, not Python. My guess is that it is also a common extension for Prolog programs. I think the OP's program with python code should have been program with prolog code. -- http://mail.python.org/mailman/listinfo/python-list
Re: Inserting into a database
On Sun, Oct 11, 2009 at 8:56 PM, Dennis Lee Bieber wlfr...@ix.netcom.comwrote: On Sun, 11 Oct 2009 17:00:42 -0700, Stephen Hansen apt.shan...@gmail.com declaimed the following in gmane.comp.python.general: Otherwise, the only thing anyone will be able to do is guess wildly. Which no one is likely to do :) Actually, I will... I predict the OP forgot to call .commit() on the database connection... So once the connection was closed, it did a rollback on the inserts -- so they never took place G Showoff. :) --S -- http://mail.python.org/mailman/listinfo/python-list
Re: What do I do now?
On Monday 12 October 2009 00:53:42 Someone Something wrote: 1) What should I start programming (project that takes 1-2 months, not very short term)? 2) Whtat are some good open source projects I can start coding for? These kinds of questions amaze me. Surely you are a kid in a candy shop when it comes to things to code? The best place to start a project is to scratch an itch: pick something that really bugs you, or something that is plain missing, or something that you are interested in, and start solving the problem. No O/S or Desktop or App is perfect. There are a thousand gaps between all those things that need solutions or improvements. Find an itch and either: 1. Find a project in that direction and try to join. 2. Start your own. \d -- http://mail.python.org/mailman/listinfo/python-list
Re: Is pythonic version of scanf() or sscanf() planned?
On Oct 9, 5:59 pm, Joshua Kugler jos...@joshuakugler.com wrote: ryniek90 wrote: So maybe someone, someday decide to put in Python an alternative, really great implementation ofscanf() ? My idea of a greatscanf() function would be a clever combination of re.match(), int(), and float(). j Actually, the Python documentation has something interesting: http://docs.python.org/3.1/library/re.html#simulating-scanf -- http://mail.python.org/mailman/listinfo/python-list
Re: Is pythonic version of scanf() or sscanf() planned?
On Oct 3, 8:17 pm, Grant Edwards inva...@invalid.invalid wrote: (--snip--) One of the fist things I remember being taught as a C progrmmer was to never use scanf. Programs that use scanf tend to fail in rather spectacular ways when presented with simple typos and other forms of unexpected input. Given the bad behavior and general fragility of scanf(), I doubt there's much demand for something equally broken for Python. I don't think you can blame scanf() for that. More the bad behavior of humans and uncanny ability of human fingers to press the the wrong damn keys. -- http://mail.python.org/mailman/listinfo/python-list
Re: python performance on Solaris
On Oct 11, 6:59 am, Antoine Pitrou solip...@pitrou.net wrote: inaf cem.ezberci at gmail.com writes: My code seem to return lookups from a in memory data structure I build combining bunch of dictionaries and lists 6-8 times faster on a 32 bit Linux box than on a Solaris zone. Well, if your workload is CPU-bound, the issue here is not really Solaris vs. Linux but rather CPU power. You should try to run a generic (non-Python) CPU benchmark (*) on both systems, perhaps this 6-8 factor is expected. If only Python shows such a performance difference, on the other hand, perhaps you can give us more precisions on those systems. Regards Antoine. (*) for example one of the C programs onhttp://shootout.alioth.debian.org/u64/c.php Good point. I failed to compare the CPU power on these machines.. 32 bit linux box I have is 2666 Mhz vs the Solaris zone is 1415 Mhz.. I guess that explains :) Thank you for the tip.. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why ELIF?
On Oct 11, 9:43 pm, Steven D'Aprano st...@remove-this-
cybersource.com.au wrote:
On Sun, 11 Oct 2009 11:15:06 -0700, TerryP wrote:
I might take flak here, for writing something like 'dict[key]
(func_args)' instead of something more Pythonic,
Looking up a first-class function in a dictionary and passing arguments
to it is perfectly Pythonic.
It's a technique (learned through Perl), that greatly changed the way
I think about writing code. Since then I've looked for ways to tell
programming languages how to work harder, so that we can sit on our
bums more often.
My brain thinks about programming problems more abstractly then any
specific language, so I pay more attention to the art of it, then to
the idiomatic usage of language foo. As such, that also means I look
for good code instead of code that obeys some pattern or mantra - and
have never claimed to know what Pythonic code actually looks
like ;).
On Oct 12, 1:34 am, John Machin sjmac...@lexicon.net wrote:
MRAB python at mrabarnett.plus.com writes:
Simon Forman wrote:
[snip]
I'll often do that this way:
args = re.split('\s', line)
This has the same result, but is shorter and quicker:
args = line.split()
HUH?
Shorter and quicker, yes, but provides much better functionality; it's NOT the
same result:
line = ' aaa bbb ccc '
import re
re.split('\s', line)
['', '', '', 'aaa', '', '', 'bbb', '', '', 'ccc', '', '', '']
line.split()
['aaa', 'bbb', 'ccc']
As I expresssed, the code served make a point not teach. Brevity is
sometimes done for it's own sake. In real code I would do something
more like:
cmd, args = some_self_documenting_and_fully_qualified_function_name
(line)
and that would handle tokenizing the line correctly throughout the
body of code, for invocation anywhere that it is needed. I hate to
repeat myself when I can compose functions instead.
I chose the re.split() on '\s' whitespace bit as a short cut in
expressing what the most common case would have looked like without it
having to detract from the OP's topic. It also (subtly) implies that
one must look beyond the lotus flower in order to obtain enlightenment
\o/.
P.S. Mick Krippendorf, thanks I forgot about 'import this' :-}
--
TerryP.
--
http://mail.python.org/mailman/listinfo/python-list
Re: An assessment of Tkinter and IDLE
On Aug 27, 9:22 pm, r rt8...@gmail.com wrote:
-
from Tkinter import *
-
*Too many noobs start out with the from Tkinter import * idiom,
unknowing that they are horribly polluting their namespace. I feel
that all (tkinter) code should follow the import Tkinter as tk
policy and never use from Tkinter import *. To push this agenda i
propose all docs be modified so that no one should see such global
import blasphemy again. We should at least keep all example code in
the latter non-polluting form and frown heavily upon global imports in
Tkinter code or any code for that matter.
'import Tkinter as tk', that I like -- my fingers are lazier then the
mind ;).
When I see the from whatever import *; I generally regard it in one of
two Things: Good Thing or Bad Thing.
Good Thing:
sometimes program-locale modules are better used
with import *, unless you really should be writing
BazInternals.quxmire everywhere.
Bad Thing:
ahh crap, now I need to know what *is* being
slammed into this namespace.
The programmer should be competent to judge which is appropriate, if
not then they should be *educated* rather then have a hand held, and
told a lullaby. Pass the whisky.
However, I admit that I wish more official documentation dispensed
with the brevity of writing bar() over foo.bar(), it would save me
from having to pay attention to what they are saying in the first
place ;)
On Aug 27, 9:22 pm, r rt8...@gmail.com wrote:
W1 W2 ---
| for x in range(10): |
... | print x |
... | for y in range(x): |
... | print y |
|1
|2
I agree, there should be some reason to use IDLE instead of your
systems command prompt ;).
On my Pentium D machine, under Windows NT 5.1 (XP), just *moving* the
IDLE shell window around causes taskmgr to report double the CPU
usage, not to mention the choppy feeling it produces. I assume that is
a Tkinter problem. I doubt splitting it the way you describe would
make it any slower.
On Aug 27, 9:22 pm, r rt8...@gmail.com wrote:
Since IDLE has no horizontal scroll bar you must
use MMB to scroll left-right.
What about having a mouse wheel that tilts left or right? ;}
On Aug 27, 9:22 pm, r rt8...@gmail.com wrote:
*Something that always gets a Python IDLE noob is open-bracket-syntax-
errors in IDLE. When Python throws this type of error normally the
only clue you will get from IDLE is to see the last line highlighted.
However, the missing or misplaced bracket is usually no where near the
end of the script. IDLE can be easily fixed to show a much closer or
even exact location of the last open bracket.
Considering how often people fuddle up matching marks [], (), {}, '',
, etc --- why not make Python 'throw' something more helpful
instead? :-P.
For the amount of time that I have used Perl over the years, I learned
two things very important from it. 0.) All language implementations
tend to _s_u_c_k_ at reporting syntax errors; and 1.) if the syntax
error being reported sounds utterly insane, you probably forgot
something; somewhere.
On Aug 27, 9:22 pm, r rt8...@gmail.com wrote:
*One of my all time pet peeves with all text editors. Everybody repeat
after me...
NO TEXT EDITOR SHOULD EVER COPY AN EMPTY STRING TO THE
CLIPBOARD!!
...I can't tell you how many times I've had to re-copy some text
because i accidentally pressed Control-C instead of Control-V,
arggh! This bug needs to be fixed yesterday! Pressing Control-C with
no active selection should sound the error bell, not copy .
No, that is probably wrong.
People should use (and create) better software, not create software
that side steps even worse software. Be liberal in what you accept,
and conservative in what you generate -- good idea, unless your job
is (almost) strictly GIGO. The clipboard is a garbage buffer, not a
water filter.
If you use Windows a lot, might I suggest a small program called
Qlipboard http://code.google.com/p/heresylabs/wiki/Qlipboard.
kind off topic
The first GUI widget toolkit [sic] that I ever learned, was Qt. It
took me three nights of after work play time to do it: one each to
(re)learn Python, learn Qt/GUI stuff, and practice them both. I did
that using the C++ documentation for Qt and the Python documentation
index for Python. That was with NO experience what so ever in
developing software around graphical user interfaces, unless you count
a love for the `cat f1 f2 f3 | sort | uniq | mail -s subject
u...@cli.users.org` school of software design.
Tk is probably an excellent toolkit for people to use at first (I've
never used it) but good documentation and an API that's light on brain
damage is the *best* thing to follow up with, next to mind reading ;).
--
TerryP.
Just Another Programmer
--
[issue6894] urllib2 doesn't respect no_proxy environment (python2.6.2)
Senthil Kumaran orsent...@gmail.com added the comment: merged in release31-maint in revision 75336 Closing the issue. -- status: open - closed versions: +Python 2.7, Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6894 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4064] distutils.util.get_platform() is wrong for universal builds on macosx
Changes by Ronald Oussoren ronaldousso...@mac.com: -- nosy: -ronaldoussoren ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4064 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7102] Problems building pyhton from source on Snow Leopard (Mac OS X 10.6)
New submission from Fredrik Hedman fredrik.hed...@me.com: -*- mode: outline -*- * Problems building pyhton from source on Snow Leopard (Mac OS X 10.6) 1 error and 39 warnings and a quick fix. ** Building python from source with --enable-framework I have a fresh install of Snow Leopard and the accompanying Xcode 3.2; see below for platform details. I'm trying to build python from Python-3.1.1.tar.bz2. The build $ export MACOSX_DEPLOYMENT_TARGET=10.6 $ ./configure --enable-framework $ make fails with the following error: gcc -framework CoreFoundation Python.framework/Versions/3.1/Python - o python \ Modules/python.o \ Python.framework/Versions/3.1/Python -ldl ld: warning: in Python.framework/Versions/3.1/Python, file is not of required architecture ld: warning: in Python.framework/Versions/3.1/Python, file is not of required architecture Undefined symbols: _PyMem_Malloc, referenced from: _main in python.o _main in python.o _main in python.o _main in python.o _Py_Main, referenced from: _main in python.o _main in python.o _PyMem_Free, referenced from: _main in python.o _main in python.o _main in python.o _main in python.o ld: symbol(s) not found collect2: ld returned 1 exit status make: *** [python] Error 1 ** Error analysis and quick fix The symbols above that are not defined are all defined in the library built before the error occurs: libpython3.1.a. For some reason configure does not include this library when linking. Looking at the generated Makefile and the rule BUILDPYTHON one sees that BLDLIBRARY seems to be not set properly. If I tweak the Makefile and set BLDLIBRARY= -L. $(LIBRARY) then relaunching make works just fine. The failed rule above completes just fine and make completes without error. ** 39 warnings and file is not of required architecture? The results are not flawless since there are some complaints: Python build finished, but the necessary bits to build these modules were not found: ossaudiodevspwd To find the necessary bits, look in setup.py in detect_modules() for the module's name. Failed to build these modules: _curses_curses_panel I choose to ignore these missing bits along with the other 39 warnings generated during the build. Most seem to be about quality of code. The most worrying is the one about ld: warning: in Python.framework/Versions/3.1/Python, file is not of required architecture which I do not really understand at this point, being quite new to Cocoa and frameworks. ** Testing make test reports: test_zlib 310 tests OK. 1 test failed: test_telnetlib 24 tests skipped: test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_curses test_epoll test_largefile test_nis test_normalization test_ossaudiodev test_pep277 test_smtpnet test_socketserver test_startfile test_timeout test_tk test_ttk_guionly test_urllib2net test_urllibnet test_winreg test_winsound test_xmlrpc_net test_zipfile64 Those skips are all expected on darwin. So the quick fix should be acceptable. * A more permanent fix? Needs verification In file configure.in change (line 674) BLDLIBRARY='' to BLDLIBRARY='-L. -lpython$(VERSION)' Then generate a new configure script with autoreconf ./configure MACOSX_DEPLOYMENT_TARGET=10.6 --enable-framework make make test This seems to work fine, but must to be verified by someone with more Cocoa and Framework knowledge since it sort of goes against the comments that precede the changed line in configure.in. * Platform $ uname -a Darwin beech.local 10.0.0 Darwin Kernel Version 10.0.0: Fri Jul 31 22:47:34 PDT 2009; root:xnu-1456.1.25~1/RELEASE_I386 i386 $ xcode-select -version xcode-select version 895. -- assignee: ronaldoussoren components: Installation, Macintosh messages: 93851 nosy: FredrikHedman, ronaldoussoren severity: normal status: open title: Problems building pyhton from source on Snow Leopard (Mac OS X 10.6) type: compile error versions: Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7102 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7102] Problems building pyhton from source on Snow Leopard (Mac OS X 10.6)
Ronald Oussoren ronaldousso...@mac.com added the comment: Fredrik: OSX 10.6 was released after Python 3.1.1. I know that we had to apply a number of patches to the 2.6 branch to get that to compile properly on 10.6, and those should have been forward ported to the 3.1 branch. Could you please do a checkout of the 3.1 branch and test if that solves the issue for you (it does for me)? One issue you are running into is that the compiler on 10.6 generates 64-bit code by default, while Python's build system assumes that the compiler generates 32-bit code. This was fixed in python 2.6.3 and the 3.x branches a while back, but hasn't made it into a release of 3.1 yet. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7102 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7100] test_xmlrpc: global name 'stop_serving' is not defined
Kristján Valur Jónsson krist...@ccpgames.com added the comment: I can't repro on my windows box. From what I can see, for some reason the server thread isn't terminating, so we enter an errorhandling codepath that is broken. The slew of errors that follow occur when the process is exiting and the worker threads have had the carpet pulled from underneath them, as it were. We should remove the stop_serving() call, it is some rudiment of ancient code. But the real error is still hidden, whatever caused the server to not exit. If this is easily repro, maybe you can produce a traceback of the worker thread at this point? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7100 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7060] test_multiprocessing dictionary changed size errors and hang
Antoine Pitrou pit...@free.fr added the comment: It was a bad idea to revert the change, because we may now forget about the problem rather than fix it. It is likely that the dictionary changed size during iteration occurs because a GC collection gets triggered during the iteration on the weakdict. A GC collection can destroy some objects in that case because keeping an exception around (which the unittest change does) usually creates reference cycles through the frame's locals. It seems that WeakValueDictionary.items() isn't very robust in py3k ;) We probably need to add list-returning variants, e.g. a listitems() method (and, probably, listkeys() and listvalues() too)? -- nosy: +benjamin.peterson, pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7060 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7060] test_multiprocessing dictionary changed size errors and hang
Kristján Valur Jónsson krist...@ccpgames.com added the comment: The unittest only keeps an exception _object_ around, not the associated traceback. There should be no frames and thus reference cycles associated with this. I agree that the problem should be tackled, rather than swept under the carpet like a revert does. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7060 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7060] test_multiprocessing dictionary changed size errors and hang
Antoine Pitrou pit...@free.fr added the comment: The unittest only keeps an exception _object_ around, not the associated traceback. In py3k, the traceback is attached to the exception (on the __traceback__ attribute) ;) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7060 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7060] test_multiprocessing dictionary changed size errors and hang
Benjamin Peterson benja...@python.org added the comment: I disagree about reverting it. We have this bug report, and that change is sitting on the merge queue again... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7060 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7103] Error in config parser example (w/ Patch)
New submission from Thomas Courbon hart...@yahoo.fr:
When ran in python 3.1.1 (hand compiled, fedora 11), the first example
of configparser module fail with :
Traceback (most recent call last):
File test1.py, line 22, in module
config.write(configfile)
File /usr/local/lib/python3.1/configparser.py, line 394, in write
fp.write([%s]\n % section)
TypeError: write() argument 1 must be bytes or buffer, not str
This can be solved by replacing :
with open('example.cfg', 'wb') as configfile:
by :
with open('example.cfg', 'w') as configfile:
Patch attached.
Cheer !
Thomas
--
assignee: georg.brandl
components: Documentation
messages: 93858
nosy: georg.brandl, tcourbon
severity: normal
status: open
title: Error in config parser example (w/ Patch)
versions: Python 3.1
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7103
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7103] Error in config parser example (w/ Patch)
Changes by Thomas Courbon hart...@yahoo.fr: -- keywords: +patch Added file: http://bugs.python.org/file15101/configparser_example_issue_7103.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7103 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7060] test_multiprocessing dictionary changed size errors and hang
Kristján Valur Jónsson krist...@ccpgames.com added the comment: I didn't realize that the traceback was attached to the exception object in py3k. This makes the use of such objects more dangerous because of the circular references. The recommended practice of exc_type, exc_obj = sys.exc_info()[:2] is precisely to avoid any accidents with the tracebacks. See also http://mail.python.org/pipermail/python-dev/2005- August/055251.html So, can one just clear the __traceback__ member? That would make sense for the unittests, but it would make this manifestation of a GC bug go into hiding again. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7060 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6027] test_xmlrpc_net fails when the ISP returns 302 Found
Changes by Ezio Melotti ezio.melo...@gmail.com: -- nosy: +krisvale, loewis priority: - low ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6027 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7092] Test suite emits many DeprecationWarnings when -3 is enabled
Changes by Ezio Melotti ezio.melo...@gmail.com: -- nosy: +ezio.melotti ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7092 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6896] Intermittent failures in test_mailbox
Changes by Ezio Melotti ezio.melo...@gmail.com: -- nosy: +akuchling ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6896 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2100] unit test UnicodeWarning
Ezio Melotti ezio.melo...@gmail.com added the comment: That try/except no longer exists on trunk. This issue can probably be closed. -- status: open - pending ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2100 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1729305] test_doctest fails when run in verbose mode
Ezio Melotti ezio.melo...@gmail.com added the comment: This test still fail on Win7 with Py2.6.3rc1 in verbose mode, it works fine in normal mode. I attached a file with the traceback. -- nosy: +ezio.melotti versions: +Python 2.6 -Python 2.5 Added file: http://bugs.python.org/file15102/doctestfail.txt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1729305 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7103] Error in config parser example (w/ Patch)
Changes by Ezio Melotti ezio.melo...@gmail.com: -- assignee: georg.brandl - ezio.melotti nosy: +ezio.melotti priority: - low ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7103 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7104] test_descr uses __cmp__ which will never be called
New submission from Daniel Stutzbach dan...@stutzbachenterprises.com: The following is from Lib/test/test_descr.py. It's trying to test if looking up a special method on an object leaks references. It tests it by using __cmp__. The test will always pass because Python 3 is trying to look up __eq__, not __cmp__. Hence, __cmp__ should be changed to __eq__. # Test lookup leaks [SF bug 572567] import sys,gc if hasattr(gc, 'get_objects'): class G(object): def __cmp__(self, other): return 0 g = G() orig_objects = len(gc.get_objects()) for i in range(10): g==g new_objects = len(gc.get_objects()) self.assertEqual(orig_objects, new_objects) -- components: Tests messages: 93862 nosy: stutzbach severity: normal status: open title: test_descr uses __cmp__ which will never be called versions: Python 3.0, Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7104 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7105] weak dict iterators are fragile because of unpredictable GC runs
New submission from Antoine Pitrou pit...@free.fr: As mentioned in issue7060, weak dict iterators are easily broken by cyclic garbage collection changing the size of the underlying dict storage: File /home/rdmurray/python/py3k/Lib/weakref.py, line 121, in items for wr in self.data.values(): RuntimeError: dictionary changed size during iteration One possible solution is to delay all removals until all iterators are done. Here is a context manager-based solution. -- components: Library (Lib) files: weakiter.patch keywords: patch messages: 93863 nosy: pitrou priority: normal severity: normal stage: patch review status: open title: weak dict iterators are fragile because of unpredictable GC runs type: behavior versions: Python 3.1, Python 3.2 Added file: http://bugs.python.org/file15103/weakiter.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7105 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
