ANNOUNCE: Elisa 0.1.4
The Elisa team is proud to announce 0.1.4 release of the core of the Elisa home multimedia system. Elisa is a project to create an open source cross platform media center solution. While our primary development and deployment platform is GNU/Linux and Unix operating systems we also currently support Microsoft Windows and also hope to support MacOSX in the future. Elisa runs on top of the GStreamer multimedia framework and is developped in Python. We fixed many issues, bugs and added some features since the last release: - the media database system has been improved, one step further towards big media collections support - pictures/movies thumbnails are now compatible with Freedesktop specifications - the skin has been slightly improved in many places (new pictos, better animations, picture-folders icon compositing) - Pigment labels now display much better and are now scalable - The SDL Pigment backend has been replaced by a XWindow/GLX backend - Pigment now handle screens with non-square aspect ratio resolutions -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations.html
ANN: Einführung in die Programmierung mit Python part 7 - Funktionen (1 Ge rman ShowMeDo video)
Summary: Lucas Holland and Marius Meinert continue their introductory German Python series, in this instalment they have released their 7th video. German video description: Funktionen “In dieser Episode geht es um Funktionen, also um das Gruppieren von Code zu Einheiten, die wiederverwendbar sind.” http://showmedo.com/videos/video?name=pythonHollandIntroToPython7_germanfromSeriesID=44 About Lucas Holland and Marius Meinert: This is Lucas and Marius' first ShowMeDo series and the have made our first non-English series. If you like their videos, please leave some words of encouragement and thanks for their efforts. About ShowMeDo.com: Free videos (we call them ShowMeDos) showing you how to do things. The videos are made by us and our users, for everyone. 74 of our 148 videos are for Python, with more to come. We'd love to have more contributions - would you share what you know? The founders, Ian Ozsvald, Kyran Dale http://ShowMeDo.com -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations.html
Front Range Pythoneers Monthly Meeting: Wed, Feb 21, in Boulder, Colorado
== Meeting: Wednesday, February 21, 2007 == * Time: 6-8 PM * Location: bivio Software, Inc., 28th and Iris. Above Hair Elite in Suite S. There is abundant parking. We have a line up of PyCon talks. Our presenters will have a chance to practice on you, while giving you a sneak peek of what will happen in Dallas next weekend: * Fernando Perez will present his joint talk with Brian Granger, IPython: Getting the most out of working interactively in Python: IPython (if you do not know it yet) is an enhanced interactive shell for Python. It provides a large number of features not found in the default shell that make interactive work in Python more seamless and convenient. * Jim Baker will present Iterators in Action: Using iterators well can make your code lean and your programming fun. We will distill current best practice by investigating some (mostly) useful examples of iterators in action. Expect to see a focus on itertools and recipes from the cookbook. Other items to talk about: * BoulderSprint. We had a great JythonSprint, focusing on getting IPython to work on it. Next sprint will be in April, also on IPython. Wait a second, what's up with IPython? * Google Summer of Code. One of our missions is to mentor Pythoneers. Does it make sense to add a local component to GSoC 2007? We will have food drink available as usual. Hope to see you there! More info: http://wiki.python.org/moin/FrontRangePythoneers -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations.html
Re: I'm faint why this can't work
[EMAIL PROTECTED] wrote: Hello, I got this similar sample script from books: $ cat sampdict.py #!/usr/bin/python class SampDict(dict): def __init__(self, filename=None): self[name] = filename But when I run it I got the errors: from sampdict import SampDict SampDict(/etc/passwd) Traceback (most recent call last): File stdin, line 1, in ? File sampdict.py, line 4, in __init__ self[name] = filename AttributeError: SampDict instance has no attribute '__setitem__' I'm using Python 2.3.4. Please help.Thanks. It works just fine in all versions of Python I could find: 2.3.3, 2.3.5, 2.4, and 2.5. My only guesses: Have you mixed spaces and tabs for the indentation, so that the code Python sees is not as we see it printed? (Don't ever do that.) Do you have several copies of sampdict.py (or even sampdict.pyc) so that the copy being imported is not the one you printed? (Run Python with a -v switch to test for this possibility.) Gary Herron -- http://mail.python.org/mailman/listinfo/python-list
Re: I'm faint why this can't work
En Fri, 16 Feb 2007 03:38:43 -0300, [EMAIL PROTECTED] escribió: Hello, I got this similar sample script from books: $ cat sampdict.py #!/usr/bin/python class SampDict(dict): def __init__(self, filename=None): self[name] = filename Are you sure you copied it exactly as it appears? Where did you find it? But when I run it I got the errors: from sampdict import SampDict SampDict(/etc/passwd) Traceback (most recent call last): File stdin, line 1, in ? File sampdict.py, line 4, in __init__ self[name] = filename AttributeError: SampDict instance has no attribute '__setitem__' Usually, when you inherit from another class, you have to call the base class __init__ from inside your own. That is, put this line: dict.__init__(self) as the firt statement on your __init__ -- Gabriel Genellina -- http://mail.python.org/mailman/listinfo/python-list
Re: I'm faint why this can't work
Hello, I got this similar sample script from books: $ cat sampdict.py #!/usr/bin/python class SampDict(dict): def __init__(self, filename=None): self[name] = filename Are you sure you copied it exactly as it appears? Where did you find it? Thank you for the help,Gabriel. The codes got by me from the book of Dive into Python.The original codes are below: class FileInfo(dict): store file metadata def __init__(self, filename=None): self[name] = filename It's in the chapter 5.5. -- http://mail.python.org/mailman/listinfo/python-list
Re: builtin set literal
Raymond Hettinger:
One of the reasons for the
rejection was that the small benefit of a literal notion was more than
offset by the attendant need for syntactical atrocities like those
listed above.
{:} for empty dict and {} for empty set don't look too much atrocious
to me.
Note: the language Fortress, that in graphic modality uses unicode for
its sources, has many collection literals (6 or more, you can see 3 of
them at page 21):
http://research.sun.com/projects/plrg/PLDITutorialSlides9Jun2006.pdf
Bye,
bearophile
--
http://mail.python.org/mailman/listinfo/python-list
Compression library
Hi all, I'm looking for a library in python containing severall compression algorithms like RLE, Deflate, LZ77-78-W, Huffman,.. do someone know if such of this type of lib exists?? Thanks -- http://mail.python.org/mailman/listinfo/python-list
KeyboardInterrupt not caught
Hi, why is KeyboardInterrupt not caught (xp)? import sys try: inp = sys.stdin.read() except (KeyboardInterrupt, SystemExit): print kbd-interr,SystemExit except EOFError: print eof encountered except: print caught all self.showtraceback() print normal end result after script startet and ^C hit: ctrl_test.py normal end Traceback (most recent call last): File C:\work\py_src\ctrl_test.py, line 11, in ? print normal end KeyboardInterrupt br Rudi -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter __call__
John McMonagle wrote:
Gigs_ wrote:
from Tkinter import *
from tkFileDialog import askopenfilename
from tkColorChooser import askcolor
from tkMessageBox import askquestion, showerror
from tkSimpleDialog import askfloat
demos = {
'Open': askopenfilename,
'Color': askcolor,
'Query': lambda: askquestion('Warning', 'You typed
...\nConfirm?'),
'Error': lambda: showerror('Error!', He's dead, Jim),
'Input': lambda: askfloat('Entry', 'Enter credit card number')
}
class Demo(Frame):
def __init__(self, parent=None):
Frame.__init__(self, parent)
self.pack()
Label(self, text=Basic demos).pack()
for (key, value) in demos.items():
func = (lambda: self.printit(key))
Button(self, text=key, command=func).pack(side=TOP,
fill=BOTH)
def printit(self, name):
print name, 'returns =', demos[name]()
I have tried but cant get it to work properly.
I want to instead printit method to put __call__ and call it like that
Can someone help me, please?
Add the following lines to the end of your script and all should work as
expected:
root = Tk()
app = Demo(root)
root.mainloop()
I have write root window, but forgot to write here
I want to use __call__ method instead printit
--
http://mail.python.org/mailman/listinfo/python-list
Re: rot13 in a more Pythonic style?
On Fri, 16 Feb 2007 04:53:23 +, Dennis Lee Bieber wrote: On 15 Feb 2007 11:10:53 -0800, Andy Dingley [EMAIL PROTECTED] declaimed the following in comp.lang.python: Fortunately I don't think it's _quite_ that bad. Possibly not, but that description of the problem would likely have gotten more applicable help than a debate on the merits of reimplementing translate(). The Original Poster did say in his first post that he knew about translate and encode and he wasn't looking for those solutions: [quote] Yes, I know of .encode() and .translate(). No, I don't actually need rot13 itself, it's just a convenient substitute example for the real job-specific task. [end quote] Perhaps rot13 wasn't the best choice in the world, but how was Andy to know people would answer his post without reading it in full? Oh wait, this is Usenet... *wink* -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Re: KeyboardInterrupt not caught
why is KeyboardInterrupt not caught (xp)? import sys try: inp = sys.stdin.read() except (KeyboardInterrupt, SystemExit): print kbd-interr,SystemExit except EOFError: print eof encountered except: print caught all self.showtraceback() print normal end result after script startet and ^C hit: ctrl_test.py normal end Traceback (most recent call last): File C:\work\py_src\ctrl_test.py, line 11, in ? print normal end KeyboardInterrupt Hi, are you sure this is exactly what you run? The code above works perfectly for me and prints kbd-interr,SystemExit normal end as it should upon pressing Ctrl-C (although I'm on linux not xp but that shouldn't matter at all). -- http://mail.python.org/mailman/listinfo/python-list
Re: I'm faint why this can't work
En Fri, 16 Feb 2007 05:27:46 -0300, [EMAIL PROTECTED] escribió: I got this similar sample script from books: $ cat sampdict.py #!/usr/bin/python class SampDict(dict): def __init__(self, filename=None): self[name] = filename Are you sure you copied it exactly as it appears? Where did you find it? Thank you for the help,Gabriel. Sorry, I was wrong. The code as it is (with the right indentation, of course) should work OK. Maybe, you were playing in the interpreter, and you wrote some test class and called it dict? Inadvertedly hiding the dict builtin. Try again, it must work... The codes got by me from the book of Dive into Python.The original A good book! -- Gabriel Genellina -- http://mail.python.org/mailman/listinfo/python-list
Approaches of interprocess communication
Hi all, Supposing you have two separate processes running on the same box, what approach would you suggest to communicate between those two processes. Let me list the ones I know of: * Sockets Advantage: Supported per se in nearly every programming language without even the need to install additional packages Disadvantage: Lot's of code to write, and it's kind of silly to communicate via TCP/IP if the processes run on the same machine. * Webservices Advantage: Relatively easy to use, can work across different languages Disadvantage: Even more overhead on the TCP/IP side that simple sockets, as really bulky SOAP messages need to be passed around. * CORBA -- similar to webservices but more complicated to code. * Shared memory I don't know much about this subject. Supposing both processes are written in Python, is there any other way to achieve this? To me, shared memory sound the most suited approach. But as said, I am still fuzzy in this area. Where can I find more information on this subject? -- http://mail.python.org/mailman/listinfo/python-list
Re: KeyboardInterrupt not caught
En Fri, 16 Feb 2007 06:58:54 -0300, Daniel Nogradi [EMAIL PROTECTED] escribió: why is KeyboardInterrupt not caught (xp)? Hi, are you sure this is exactly what you run? The code above works perfectly for me and prints kbd-interr,SystemExit normal end as it should upon pressing Ctrl-C (although I'm on linux not xp but that shouldn't matter at all). I'm using XP and it works as expected too. -- Gabriel Genellina -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter __call__
Gigs_ wrote: I have tried but cant get it to work properly. It does work, but not the way you want it to. I want to instead printit method to put __call__ and call it like that I don't understand. Can someone help me, please? Try to explain what you want a bit more explicitly. Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: KeyboardInterrupt not caught
On Fri, 16 Feb 2007 01:47:43 -0800, ruka_at_ wrote: Hi, why is KeyboardInterrupt not caught (xp)? import sys try: inp = sys.stdin.read() except (KeyboardInterrupt, SystemExit): print kbd-interr,SystemExit except EOFError: print eof encountered I don't think you ever get an EOFError from stdin. If you type ^D immediately, stdin.read() returns an empty string. except: print caught all self.showtraceback() I don't imagine you'll get any other exceptions either. Not that it matters, but what's self? print normal end result after script startet and ^C hit: ctrl_test.py normal end Traceback (most recent call last): File C:\work\py_src\ctrl_test.py, line 11, in ? print normal end KeyboardInterrupt It works as expected for me. I seem to have a vague recollection that the keyboard interrupt under Windows isn't ^C but something else... ^Z maybe? -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Re: Pep 3105: the end of print?
On Thu, 15 Feb 2007 19:04:34 -0600, Edward K Ream wrote: Isn't the very concept of major releases (1.x, 2.x, 3.x) that they *can* be not backwards-compatible with previous releases? Not at all. Backwards compatibility means that one can still run old code provided the code eschews new features. Python releases have generally been backwards compatible with previous releases, with a few minor exceptions. That's fine, but Python 3 has been explicitly stated to be where Python will have backwards _in_compatible changes made. That's not to say that all Python 2.x programs will break under Python 3, but some surely will. For example, my app runs fine on Python 2.2.2 through Python 2.5, and little work was required to make this happen. In fact, my app should run find on Python 3.x, but that's because it doesn't use print :-) It's too early to say for sure what will run under Python 3, because it hasn't been decided fully yet, but it is quite probable that it will still compile and/or run and possibly even do what you intended. In other words, the consequence of pep 3105 will be that *nobody* who wants their app to be portable will be able to use print until *everybody* has converted to Python 3.x. I doubt that is what Guido had in mind, but I may be mistaken :-) I'm pretty sure you're mistaken. Python 3 will be the release that breaks code. Hopefully very little, but there almost certainly will be some. -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Re: Approaches of interprocess communication
En Fri, 16 Feb 2007 07:11:36 -0300, exhuma.twn [EMAIL PROTECTED] escribió: Hi all, Supposing you have two separate processes running on the same box, what approach would you suggest to communicate between those two processes. Let me list the ones I know of: * Sockets Advantage: Supported per se in nearly every programming language without even the need to install additional packages Disadvantage: Lot's of code to write, and it's kind of silly to communicate via TCP/IP if the processes run on the same machine. Not so much code, really. (And I would expect that making a connection to localhost actually does *not* go down up to the network card hardware layer, but I don't know for real if this is the case or not). * Webservices Advantage: Relatively easy to use, can work across different languages Disadvantage: Even more overhead on the TCP/IP side that simple sockets, as really bulky SOAP messages need to be passed around. You could use XMLRPC, wich is a lot simpler (but less powerful). * CORBA -- similar to webservices but more complicated to code. I would stay away as far as I could. * Shared memory I don't know much about this subject. You forget the most basic one, stdio redirection. Easy, available on almost any language, but limited to just a pair of processes. You can add queues and messages. Supposing both processes are written in Python, is there any other way to achieve this? To me, shared memory sound the most suited approach. But as said, I am still fuzzy in this area. Where can I find more information on this subject? Pyro appears to be a good alternative (altough I've never used it yet). -- Gabriel Genellina -- http://mail.python.org/mailman/listinfo/python-list
Re: KeyboardInterrupt not caught
En Fri, 16 Feb 2007 07:26:09 -0300, Steven D'Aprano [EMAIL PROTECTED] escribió: I seem to have a vague recollection that the keyboard interrupt under Windows isn't ^C but something else... ^Z maybe? Ctrl-C is the keyboard interrupt, Ctrl-Z means EOF. -- Gabriel Genellina -- http://mail.python.org/mailman/listinfo/python-list
Re: The Python interactive interpreter has no command history
Il Thu, 15 Feb 2007 15:14:00 -0200, Eduardo EdCrypt O. Padoan ha scritto: Are you using Ubuntu? The last comes with 2.4.x and 2.5. This only occurs on 2.5. This happens when you compile Python with libreadline installed, AFAIK. I'm on Edgy and command history works well both with 2.4 and 2.5 with my config. If it's really an Edgy glitch, it must be configuration-related! -- Alan Franzoni [EMAIL PROTECTED] - Togli .xyz dalla mia email per contattarmi. Remove .xyz from my address in order to contact me. - GPG Key Fingerprint (Key ID = FE068F3E): 5C77 9DC3 BD5B 3A28 E7BC 921A 0255 42AA FE06 8F3E -- http://mail.python.org/mailman/listinfo/python-list
Pickling of generators
Generators are becoming more and more important and powerful in Python. The inability of pickle to save/restore generators has become a major (and growing) limitation to the full exploitation of generators. The requirement for pickling generators has already been raised in 2003. My project (SimPy - Simulation in Python) has had this requirement since its inception in 2002. Generator pickling would make saving and reloading simulation state trivial. The workarounds one has to use without this capability are baroque and beyond the expertise of a typical simulation user. Is there any hope of action in this area in the foreseeable future? Klaus Muller (Lead designer of SimPy) -- http://mail.python.org/mailman/listinfo/python-list
Re: I'm faint why this can't work
[EMAIL PROTECTED] writes: The codes got by me from the book of Dive into Python.The original codes are below: class FileInfo(dict): store file metadata def __init__(self, filename=None): self[name] = filename You've put the lines of code in your message without indentation. Please remember that Python uses indentation syntactically. If you're showing code examples in your message, you must make sure that the indentation survives correctly. The best way to do that is to use only tabs, *or* only spaces, for indentation; many programs will mangle tabs in different ways, so spaces are usually safest. -- \ My aunt gave me a walkie-talkie for my birthday. She says if | `\ I'm good, she'll give me the other one next year. -- Steven | _o__) Wright | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: Approaches of interprocess communication
Supposing you have two separate processes running on the same box, what approach would you suggest to communicate between those two processes. Let me list the ones I know of: * Sockets Advantage: Supported per se in nearly every programming language without even the need to install additional packages Disadvantage: Lot's of code to write, and it's kind of silly to communicate via TCP/IP if the processes run on the same machine. * Webservices Advantage: Relatively easy to use, can work across different languages Disadvantage: Even more overhead on the TCP/IP side that simple sockets, as really bulky SOAP messages need to be passed around. * CORBA -- similar to webservices but more complicated to code. * Shared memory I don't know much about this subject. Supposing both processes are written in Python, is there any other way to achieve this? To me, shared memory sound the most suited approach. But as said, I am still fuzzy in this area. Where can I find more information on this subject? Hi, if your requirements are sufficiently light then pylinda might be an easy-to-use solution: http://www-users.cs.york.ac.uk/~aw/pylinda/ A simple example is here: http://www-users.cs.york.ac.uk/~aw/pylinda/beginner.html HTH, Daniel -- http://mail.python.org/mailman/listinfo/python-list
Re: Approaches of interprocess communication
exhuma.twn [EMAIL PROTECTED] writes: Supposing you have two separate processes running on the same box, what approach would you suggest to communicate between those two processes. Let me list the ones I know of: * Sockets Advantage: Supported per se in nearly every programming language without even the need to install additional packages This would be my choice. But first, set up a well-defined *protocol* (preferably based on text commands) for the two processes to use for communication; don't have each of them being intricately aware of each others' implementation. Disadvantage: Lot's of code to write, and it's kind of silly to communicate via TCP/IP if the processes run on the same machine. You can cut down on the amount of code by using the standard library cmd module to handle a command interface, hooking the stdin and stdout of the commandline handler to the socket. If you're already thinking about cooperating processes, you should make them network-neutral anyway from the start. Here's what _The Art of Unix Programming_ has to say on the topic of text protocols: URL:http://www.catb.org/~esr/writings/taoup/html/ch05s01.html and IPC tactics for peer processes: URL:http://www.catb.org/~esr/writings/taoup/html/ch07s07.html -- \There are only two ways to live your life. One is as though | `\ nothing is a miracle. The other is as if everything is. -- | _o__) Albert Einstein | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter __call__
Gigs_ wrote:
from Tkinter import *
from tkFileDialog import askopenfilename
from tkColorChooser import askcolor
from tkMessageBox import askquestion, showerror
from tkSimpleDialog import askfloat
demos = {
'Open': askopenfilename,
'Color': askcolor,
'Query': lambda: askquestion('Warning', 'You typed
...\nConfirm?'),
'Error': lambda: showerror('Error!', He's dead, Jim),
'Input': lambda: askfloat('Entry', 'Enter credit card number')
}
class Demo(Frame):
def __init__(self, parent=None):
Frame.__init__(self, parent)
self.pack()
Label(self, text=Basic demos).pack()
for (key, value) in demos.items():
func = (lambda key=key: self.printit(key))
Button(self, text=key, command=func).pack(side=TOP, fill=BOTH)
def printit(self, name):
print name, 'returns =', demos[name]()
I have tried but cant get it to work properly.
I want to instead printit method to put __call__ and call it like that
Can someone help me, please?
The code you have should work. My guess is that you don't understand
lambda and so you want to do it a different way, using a callable?
Well, that's what lambda does, it makes a callable object:
Python 2.5 (r25:51918, Sep 19 2006, 08:49:13)
[GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin
Type help, copyright, credits or license for more information.
py key = 1
py callable(lambda key=key: self.printit(key))
True
py '__call__' in dir(lambda key=key: self.printit(key))
True
So the code you have already does what you want to do. Maybe understand
what you are studying before you reinvent the wheel--you will save
yourself a lot of frustration.
James
--
http://mail.python.org/mailman/listinfo/python-list
Re: Approaches of interprocess communication
Gabriel Genellina [EMAIL PROTECTED] writes: (And I would expect that making a connection to localhost actually does *not* go down up to the network card hardware layer, but I don't know for real if this is the case or not). It damned well better. That's the entire point of the loopback interface: to get all the network layer code involved, but not to talk on a physical network interface. If a programmer decides on behalf of the user that localhost should be treated specially, that programmer is making an error. -- \ If you can't beat them, arrange to have them beaten. -- | `\ George Carlin | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Any Idea about thread safe issue with python
Hi All I need help guys. I have a code running properly and execute again after a certain time. But The thing i am looking for that it should not start from other instance says looking for thread safe In Simple words self.lock = thread.allocate_lock() .. is not solving my purpose. Would any body like to help. Regards Alok -- http://mail.python.org/mailman/listinfo/python-list
Re: KeyboardInterrupt not caught
On 16 Feb., 11:44, Gabriel Genellina [EMAIL PROTECTED] wrote: Thanks to all of you, for the fast answers. The code I showed you is actually the code running. I tried to catch eof, cause I read ^C could produce EOF (the self.showtraceback() was just a stupid cut 'n paste). But not even the except that should catch all exceptions is triggered. Thanks again, br Rudi -- http://mail.python.org/mailman/listinfo/python-list
Re: KeyboardInterrupt not caught
On 16 Feb., 12:16, [EMAIL PROTECTED] wrote: On 16 Feb., 11:44, Gabriel Genellina [EMAIL PROTECTED] wrote: I've tried it in cygwin, result: $ python.exe c:/work/py_src/ctrl_test.py kbd-interr,SystemExit normal end br Rudi -- http://mail.python.org/mailman/listinfo/python-list
Re: Pep 3105: the end of print?
On 2/15/07, Edward K Ream [EMAIL PROTECTED] wrote: Isn't the very concept of major releases (1.x, 2.x, 3.x) that they *can* be not backwards-compatible with previous releases? Not at all. [...] It is the only intent of Python 3.0: be free of backward compatibity constraints. There are a tool called 2to3 that translates things like print foo to print(foo). -- EduardoOPadoan (eopadoan-altavix::com) Bookmarks: http://del.icio.us/edcrypt -- http://mail.python.org/mailman/listinfo/python-list
Command line prompt broken on XP with Python 2.5 - help!
My last version of Python was 2.4, running smoothly on XP with path c: \Python24 - no need even to include this path in PATH; everything worked as it's supposed to at the command line. Just installed Python 2.5, after uninstalling 2.4 (and also 2.3 which had lingered). Now if I open a shell in Windows Python is not available! Here are the symptoms: - If I open a shell using Command line here with XP Powertools, then enter python at the prompt, nothing happens. I don't get a message that the command is not recognized, but neither do I get the Python prompt. Instead the Windows prompt comes back. No messages, no Python, no nothing. - If I go so far as to specify the full path to the Python executable, I do get the Python prompt and Python appears to work properly - except that I can't exit with CTRL-Z. - If I open a shell from the Start menu, e.g. Start run command, then try entering python, the shell simply blows up. What is going on here? I have uninstalled and reinstalled Python 2.5, to no avail. I have gone so far as to specify c:\Python25 (the install path) in my PATH variable, but this makes no difference. Right now Python is unusable to me from the command prompt, meaning all of my automation scripts that I run at the command line are gone too. -- http://mail.python.org/mailman/listinfo/python-list
Re: Pep 3105: the end of print?
In short, if you need to support 2.3, you're not ready to be looking at 3.0. I hope this turns out not to be true. As a developer, I have no way to force people to 3.0, and no reason to want to. For me, maintaining two incompatible code bases is out of the question. It will be interesting to see how this plays out. Users, not developers, will determine when Python 2.x becomes extinct. Edward Edward K. Ream email: [EMAIL PROTECTED] Leo: http://webpages.charter.net/edreamleo/front.html -- http://mail.python.org/mailman/listinfo/python-list
Re: Pep 3105: the end of print?
There are a tool called 2to3 that translates things like print foo to print(foo). The point of my original post was that if I want to maintain a common code base the tool must translate 'print foo' to 'print2(foo)'. Edward Edward K. Ream email: [EMAIL PROTECTED] Leo: http://webpages.charter.net/edreamleo/front.html -- http://mail.python.org/mailman/listinfo/python-list
Re: Pep 3105: the end of print?
I'm pretty sure you're mistaken. Python 3 will be the release that breaks code. Hopefully very little, but there almost certainly will be some. Pep 3105 breaks a *lot* of code, despite the bland assertion that most production programs don't use print. Presumably, Guido wanted to improve print in such a way that *more* people would use it. But the effect of the pep is that *less* people will be able to use print, *regardless* of how backward compatible Python 3.x is 'allowed' to be. Edward Edward K. Ream email: [EMAIL PROTECTED] Leo: http://webpages.charter.net/edreamleo/front.html -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter __call__
James Stroud wrote:
Gigs_ wrote:
from Tkinter import *
from tkFileDialog import askopenfilename
from tkColorChooser import askcolor
from tkMessageBox import askquestion, showerror
from tkSimpleDialog import askfloat
demos = {
'Open': askopenfilename,
'Color': askcolor,
'Query': lambda: askquestion('Warning', 'You typed
...\nConfirm?'),
'Error': lambda: showerror('Error!', He's dead, Jim),
'Input': lambda: askfloat('Entry', 'Enter credit card number')
}
class Demo(Frame):
def __init__(self, parent=None):
Frame.__init__(self, parent)
self.pack()
Label(self, text=Basic demos).pack()
for (key, value) in demos.items():
func = (lambda key=key: self.printit(key))
Button(self, text=key, command=func).pack(side=TOP,
fill=BOTH)
def printit(self, name):
print name, 'returns =', demos[name]()
I have tried but cant get it to work properly.
I want to instead printit method to put __call__ and call it like that
Can someone help me, please?
The code you have should work. My guess is that you don't understand
lambda and so you want to do it a different way, using a callable?
Well, that's what lambda does, it makes a callable object:
Python 2.5 (r25:51918, Sep 19 2006, 08:49:13)
[GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin
Type help, copyright, credits or license for more information.
py key = 1
py callable(lambda key=key: self.printit(key))
True
py '__call__' in dir(lambda key=key: self.printit(key))
True
So the code you have already does what you want to do. Maybe understand
what you are studying before you reinvent the wheel--you will save
yourself a lot of frustration.
James
I understand lambda, and I know that code is working. But want to do for
exercise with __call__. This coed is from programming python 2ed boo
--
http://mail.python.org/mailman/listinfo/python-list
Re: Pep 3105: the end of print?
Is that what you intend to say? I intended to say what I did say: Python releases have generally been backwards compatible with previous releases, with a few minor exceptions. Imo, this is compatible with what you are saying. So long as it's done in a well-documented way, with a change in major version number, it's a reasonable way (probably the *only* reasonable way) to remove particular kinds of cruft from any application. Agreed. Edward Edward K. Ream email: [EMAIL PROTECTED] Leo: http://webpages.charter.net/edreamleo/front.html -- http://mail.python.org/mailman/listinfo/python-list
Re: Bush, yank bastards kicked by india in their arse Re: *POLL* How many sheeple believe in the 911 fairy tale and willing to accept an Orwellian doublespeak and enslavement world ?
You are a moron... OL -- http://mail.python.org/mailman/listinfo/python-list
Re: Pep 3105: the end of print?
On Feb 16, 11:54 am, Edward K Ream [EMAIL PROTECTED] wrote: In short, if you need to support 2.3, you're not ready to be looking at 3.0. I hope this turns out not to be true. As a developer, I have no way to force people to 3.0, and no reason to want to. For me, maintaining two incompatible code bases is out of the question. It will be interesting to see how this plays out. Users, not developers, will determine when Python 2.x becomes extinct. As has been mentioned 3.0 will deliberately break backwards compatibilit in a few ways in order to remove cruft and make changes that *can't* be done any other way. That said, the changing of print feels to me like gratutitous breakage - but then I've never had the need to go through old code replacing print with logging code (the need that Guido cites as the reasn for the change). There are various of the 3.0 changes being discussed for inclusion (or at least support) in Python 2.6 so it might be possible to write code that will run unchanged on Python 2.6 and 3.0. (That is *some* code - nt arbitrary code.) There is also the 2to3 converter. The aim is that this will be effective enough that coders should be able to maintain a 2.X (2.6 ?) codebase, run it through 2to3 and have the result run unchanged on Python 3. That way there will be no need to maintain two code bases. Also bear in mind that people using Python 3.0 will be aware that most existing libraries won't work - and it will be a long time (2 to 3 yearsafter the release of 3.0 final ?) before the majority of Python users have switched. This will provide plenty of time for migration patterns and tools to be established. Fuzzyman http://www.voidspace.org.uk/python/articles.shtml Edward Edward K. Ream email: [EMAIL PROTECTED] Leo:http://webpages.charter.net/edreamleo/front.html -- http://mail.python.org/mailman/listinfo/python-list
Re: Approaches of interprocess communication
In article [EMAIL PROTECTED], exhuma.twn [EMAIL PROTECTED] wrote: Supposing you have two separate processes running on the same box, what approach would you suggest to communicate between those two processes. [...] * Webservices Advantage: Relatively easy to use, can work across different languages Disadvantage: Even more overhead on the TCP/IP side that simple sockets, as really bulky SOAP messages need to be passed around. * CORBA -- similar to webservices but more complicated to code. Lots of people say that, but I don't think it's true. Obviously as the maintainer of a CORBA implementation I'm biased, but take a look at some examples of code that implement SOAP clients and servers and compare it to similar CORBA code. Especially in Python, the SOAP code tends to be incredibly verbose and complex, and the CORBA code really small and simple. My recommendation would be that for simple communications where performance isn't important use XML-RPC; for more complex cases where performance is a bit more important but you don't need anything except Python, use Pyro; for cases where performance is particularly important and/or you need cross-language communications, use CORBA. Cheers, Duncan. -- -- Duncan Grisby -- -- [EMAIL PROTECTED] -- -- http://www.grisby.org -- -- Posted via NewsDemon.com - Premium Uncensored Newsgroup Service ---http://www.NewsDem -- http://mail.python.org/mailman/listinfo/python-list
Re: Bush, yank bastards kicked by india in their arse Re: *POLL* How many sheeple believe in the 911 fairy tale and willing to accept an Orwellian doublespeak and enslavement world ?
On Jan 29, 10:18 pm, [EMAIL PROTECTED] wrote: On Jan 29, 11:15 am, Vance P. Frickey [EMAIL PROTECTED] wrote: Directorate (overseas espionage), his old employers owned someone in just about every important government agency in India, from the 1970s until they stopped being able to afford paying all those bribes. But in this anglo-saxon heaven, monica lewinsky owns every president by his balls. Reagan and Herber Walker Bush have a serious pedophilia charges against them. The jewcons control George Bush. In another article I will describe how You're a racist malicious moron. -- http://mail.python.org/mailman/listinfo/python-list
Regex - where do I make a mistake?
I have string=span class=test45655/span. tdspan class=test123128/span span class=test789170/span where I need to replace span class=test45655/span. span class=test789170/span by space. So I tried # import re string=tdspan class=test45655/span.span class=test123128/spanspan class=test789170/span Newstring=re.sub(r'span class=test(?!123).*/span', ,string) ### But it does NOT work. Can anyone explain why? Thank you L. -- http://mail.python.org/mailman/listinfo/python-list
Re: Pep 3105: the end of print?
There is also the 2to3 converter. The aim is that this will be effective enough that coders should be able to maintain a 2.X (2.6 ?) codebase, run it through 2to3 and have the result run unchanged on Python 3. That way there will be no need to maintain two code bases. I have offered a proof that the converter must change print to print2 (or some other name) in order to maintain a common code base. How much clearer can I be? If a common code base is desired, it *is* the end of print Edward Edward K. Ream email: [EMAIL PROTECTED] Leo: http://webpages.charter.net/edreamleo/front.html -- http://mail.python.org/mailman/listinfo/python-list
Re: Pep 3105: the end of print?
Edward K Ream wrote: There is also the 2to3 converter. The aim is that this will be effective enough that coders should be able to maintain a 2.X (2.6 ?) codebase, run it through 2to3 and have the result run unchanged on Python 3. That way there will be no need to maintain two code bases. I have offered a proof that the converter must change print to print2 (or some other name) in order to maintain a common code base. How much clearer can I be? If a common code base is desired, it *is* the end of print There could be something like from __future__ import print_function to remove the print keyword in 2.x. Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: Pep 3105: the end of print?
There could be something like from __future__ import print_function To repeat: this would be compatible only with Python 2.6. Edward Edward K. Ream email: [EMAIL PROTECTED] Leo: http://webpages.charter.net/edreamleo/front.html -- http://mail.python.org/mailman/listinfo/python-list
Re: Bush, yank bastards kicked by india in their arse Re: *POLL* How many sheeple believe in the 911 fairy tale and willing to accept an Orwellian doublespeak and enslavement world ?
On 16 Feb 2007 04:34:08 -0800, Fuzzyman [EMAIL PROTECTED] wrote: You're a racist malicious moron. You mis-spelled 'troll'. -- # p.d. -- http://mail.python.org/mailman/listinfo/python-list
Re: Approaches of interprocess communication
On Feb 16, 1:33 pm, Duncan Grisby [EMAIL PROTECTED] wrote: In article [EMAIL PROTECTED], exhuma.twn [EMAIL PROTECTED] wrote: Supposing you have two separate processes running on the same box, what approach would you suggest to communicate between those two processes. [...] * Webservices Advantage: Relatively easy to use, can work across different languages Disadvantage: Even more overhead on the TCP/IP side that simple sockets, as really bulky SOAP messages need to be passed around. * CORBA -- similar to webservices but more complicated to code. Lots of people say that, but I don't think it's true. Obviously as the maintainer of a CORBA implementation I'm biased, but take a look at some examples of code that implement SOAP clients and servers and compare it to similar CORBA code. Especially in Python, the SOAP code tends to be incredibly verbose and complex, and the CORBA code really small and simple. My recommendation would be that for simple communications where performance isn't important use XML-RPC; for more complex cases where performance is a bit more important but you don't need anything except Python, use Pyro; for cases where performance is particularly important and/or you need cross-language communications, use CORBA. Maybe this line of mine was a bit too condensed ;) I fully agree with you on what you say about CORBA. It's just that for most people IDL looks a bit out of place. Especially because it resembles C. But once you actually wrote a few projects using CORBA, you actually begin to see it's elegance ;) I find Webservices easier as you can (although it's not recommendable) leave out the WSDL part. And some implementations actually generate the WSDL for you. But it's true, comparing WSDL and IDL I'd rather write some IDL than WSDL ;) But, returning back to topic, I first want to thank you all for your input. I appreciate all the ideas. Especially the idea of using the cmd module for sockets. That sound's very intriguing and I will very likely play around with that. But also PYRO seems quite useful. About Linda: Am I right that it looks very similar to JavaSpaces? If yes, are there any funcdamental differences between those two? -- http://mail.python.org/mailman/listinfo/python-list
Re: Pep 3105: the end of print?
Edward K Ream wrote: There could be something like from __future__ import print_function To repeat: this would be compatible only with Python 2.6. Indeed. Don't lose your nerves over that bunch of casual readers of your thread :-) Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: Regex - where do I make a mistake?
Johny wrote: I have string=span class=test45655/span. tdspan class=test123128/span span class=test789170/span where I need to replace span class=test45655/span. span class=test789170/span by space. So I tried # import re string=tdspan class=test45655/span.span class=test123128/spanspan class=test789170/span Newstring=re.sub(r'span class=test(?!123).*/span', ,string) ### But it does NOT work. Can anyone explain why? (?!123) is a negative lookahead assertion, i. e. it ensures that test is not followed by 123, but /doesn't/ consume any characters. For your regex to match test must be /immediately/ followed by a ''. Regular expressions are too lowlevel to use on HTML directly. Go with BeautifulSoup instead of trying to fix the above. Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: Approaches of interprocess communication
Maybe this line of mine was a bit too condensed ;) I fully agree with you on what you say about CORBA. It's just that for most people IDL looks a bit out of place. Especially because it resembles C. But once you actually wrote a few projects using CORBA, you actually begin to see it's elegance ;) It looks out of the place in comparison to what exactly? A WSDL-document? You certainly me laugh hard on that I find Webservices easier as you can (although it's not recommendable) leave out the WSDL part. And some implementations actually generate the WSDL for you. You can't leave WSDL out of SOAP, you can leave it out of XMLRPC. Which is nice and easy, but lacks any contract whatsoever. Nothing I as a Pythoneer care to much about, but some people bother. And generating the WSDL works from what exactly? ah, Java-code for example, using java2wsdl. Which has a striking resemblance to C. Funny But it's true, comparing WSDL and IDL I'd rather write some IDL than WSDL ;) So - you say that yourself, but still you previously claimed IDL looks strange to the eye? Diez -- http://mail.python.org/mailman/listinfo/python-list
Re: builtin set literal
{:} for empty dict and {} for empty set don't look too much atrocious
to me.
this looks consistent to me
--
http://mail.python.org/mailman/listinfo/python-list
Re: Pep 3105: the end of print?
On Feb 16, 12:47 pm, Edward K Ream [EMAIL PROTECTED] wrote: There is also the 2to3 converter. The aim is that this will be effective enough that coders should be able to maintain a 2.X (2.6 ?) codebase, run it through 2to3 and have the result run unchanged on Python 3. That way there will be no need to maintain two code bases. I have offered a proof that the converter must change print to print2 (or some other name) in order to maintain a common code base. How much clearer can I be? If a common code base is desired, it *is* the end of print Why won't it be possible to make 'print' in Python 3 that supports all the functionality of the current print statement, and then translate to that ? I saw an assertion to the effect that it wasn't possible - but no proof. It sounds relatively straightforward for me... Fuzzyman http://www.voidspace.org.uk/python/articles.shtml Edward Edward K. Ream email: [EMAIL PROTECTED] Leo:http://webpages.charter.net/edreamleo/front.html -- http://mail.python.org/mailman/listinfo/python-list
Re: Regex - where do I make a mistake?
On Feb 16, 2:14 pm, Peter Otten [EMAIL PROTECTED] wrote: Johny wrote: I have string=span class=test45655/span. tdspan class=test123128/span span class=test789170/span where I need to replace span class=test45655/span. span class=test789170/span by space. So I tried # import re string=tdspan class=test45655/span.span class=test123128/spanspan class=test789170/span Newstring=re.sub(r'span class=test(?!123).*/span', ,string) ### But it does NOT work. Can anyone explain why? (?!123) is a negative lookahead assertion, i. e. it ensures that test is not followed by 123, but /doesn't/ consume any characters. For your regex to match test must be /immediately/ followed by a ''. Regular expressions are too lowlevel to use on HTML directly. Go with BeautifulSoup instead of trying to fix the above. Peter- Hide quoted text - - Show quoted text - Yes, I know (?!123) is a negative lookahead assertion, but do not know excatly why it does not work.I thought that (?!...) Matches if ... doesn't match next. For example, Isaac (?!Asimov) will match 'Isaac ' only if it's not followed by 'Asimov'. -- http://mail.python.org/mailman/listinfo/python-list
Re: Approaches of interprocess communication
On 16 Feb, 14:16, Diez B. Roggisch [EMAIL PROTECTED] wrote: You can't leave WSDL out of SOAP Yes you can, since they're two different things. What you probably meant was that you can't leave WSDL out of big architecture, W3C standards-intensive Web services. Of course, RPC-style SOAP without the contracts imposed by WSDL may remove some of the attractions for some people (who really should consider CORBA, anyway), but then there's always document-oriented SOAP, although if you don't want the baggage associated with routing and other things, plain XML messaging would be easier. And there's always XMPP if you want stuff like routing and a standard that isn't undergoing apparently continuous change. Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: Regex - where do I make a mistake?
Johny wrote: On Feb 16, 2:14 pm, Peter Otten [EMAIL PROTECTED] wrote: Johny wrote: I have string=span class=test45655/span. tdspan class=test123128/span span class=test789170/span where I need to replace span class=test45655/span. span class=test789170/span by space. So I tried # import re string=tdspan class=test45655/span.span class=test123128/spanspan class=test789170/span Newstring=re.sub(r'span class=test(?!123).*/span', ,string) ### But it does NOT work. Can anyone explain why? (?!123) is a negative lookahead assertion, i. e. it ensures that test is not followed by 123, but /doesn't/ consume any characters. For your regex to match test must be /immediately/ followed by a ''. Regular expressions are too lowlevel to use on HTML directly. Go with BeautifulSoup instead of trying to fix the above. Peter- Hide quoted text - - Show quoted text - Yes, I know (?!123) is a negative lookahead assertion, but do not know excatly why it does not work.I thought that (?!...) Matches if ... doesn't match next. For example, Isaac (?!Asimov) will match 'Isaac ' only if it's not followed by 'Asimov'. The problem is that your regex does not end with the lookahead assertion and there is nothing to consume the '456' or '789'. To illustrate: for example in [before123after, before234after, beforeafter]: ... re.findall(before(?!123)after, example) ... [] [] ['beforeafter'] for example in [before123after, before234after, beforeafter]: ... re.findall(rbefore(?!123)\d\d\dafter, example) ... [] ['before234after'] [] Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: Approaches of interprocess communication
Paul Boddie wrote: On 16 Feb, 14:16, Diez B. Roggisch [EMAIL PROTECTED] wrote: You can't leave WSDL out of SOAP Yes you can, since they're two different things. What you probably meant was that you can't leave WSDL out of big architecture, W3C standards-intensive Web services. Of course, RPC-style SOAP without the contracts imposed by WSDL may remove some of the attractions for some people (who really should consider CORBA, anyway), but then there's always document-oriented SOAP, although if you don't want the baggage associated with routing and other things, plain XML messaging would be easier. And there's always XMPP if you want stuff like routing and a standard that isn't undergoing apparently continuous change. Didn't know that. Yet I presume it is pretty awful to manually decompose and compose the method invocations and parameter sets. I've got no idea what document-orientied SOAP means either. Is that just pushing XML-files over a protocol? Diez -- http://mail.python.org/mailman/listinfo/python-list
starship.python.net is down
One of the system administrators had to reboot starship.python.net last night, but it appears that the machine did not come back up properly. starship.python.net is currently down while we investigate. ---Tom -- http://mail.python.org/mailman/listinfo/python-list
Re: Pep 3105: the end of print?
Why won't it be possible to make 'print' in Python 3 that supports all
the functionality of the current print statement, and then translate to
that ?
I saw an assertion to the effect that it wasn't possible - but no proof.
As discussed in the original post, the problem is the reverse: the Python
2.x print statement does not support the keyword args required by the pep,
so that print(foo) **in Python 2.x** can not simulate the effect of the
print statement with a trailing comma. Here is the theorum carefully stated
and proved.
Theorem: is not possible to define a function called print in Python 3.x
such that
A) print (whatever) is syntaxtically valid in Python 2.x and
B) print(whatever) outputs what 'print whatever' outputs in Python 2.x for
all values of 'whatever'.
Proof:
It is impossible for the print function to simulate the effect of the print
statement with a trailing comma. Indeed, print ('line'), and print
('line',) (note the position of the commas) are valid in Python 2.x, but
neither does what is wanted. And print('line',end='') is invalid in Python
2.x. Let's look at some examples:
1. The following works (prints 'line after\n') in Python 2.x, but will not
suppress the newline in Python 3.x:
print('line'),
print('after')
2. The following doesn't work in Python 2.x. (It prints
('line',)\nafter).
print ('line',)
print ('after')
3. print ('line',end='') produces a syntax error in Python 2.x:
print ('line',end='')
^
SyntaxError: invalid syntax
That's the proof. Can you find a flaw in it?
Edward
Edward K. Ream email: [EMAIL PROTECTED]
Leo: http://webpages.charter.net/edreamleo/front.html
--
http://mail.python.org/mailman/listinfo/python-list
Re: Regex - where do I make a mistake?
On Fri, 2007-02-16 at 05:34 -0800, Johny wrote: On Feb 16, 2:14 pm, Peter Otten [EMAIL PROTECTED] wrote: Johny wrote: I have string=span class=test45655/span. tdspan class=test123128/span span class=test789170/span where I need to replace span class=test45655/span. span class=test789170/span by space. So I tried # import re string=tdspan class=test45655/span.span class=test123128/spanspan class=test789170/span Newstring=re.sub(r'span class=test(?!123).*/span', ,string) ### But it does NOT work. Can anyone explain why? (?!123) is a negative lookahead assertion, i. e. it ensures that test is not followed by 123, but /doesn't/ consume any characters. For your regex to match test must be /immediately/ followed by a ''. Regular expressions are too lowlevel to use on HTML directly. Go with BeautifulSoup instead of trying to fix the above. Yes, I know (?!123) is a negative lookahead assertion, but do not know excatly why it does not work. It *does* work, it just doesn't do what you think it does. The lookahead assertion is a zero-width match that doesn't match any actual characters from the subject. It matches an imaginary vertical line between two consecutive characters of the subject. Nothing in your pattern matches the string of digits that follows test, hence the subject fails to match the pattern. Also, please note Peter's advice that Regular Expressions are almost always the wrong tool for working with HTML. It may work in very limited cases, and maybe you have such a limited case, but you'd better make sure that you'll never ever have to handle anything beyond this limited case. -Carsten -- http://mail.python.org/mailman/listinfo/python-list
Re: Approaches of interprocess communication
On 16 Feb, 14:53, Diez B. Roggisch [EMAIL PROTECTED] wrote: [XMPP, XML messaging] Didn't know that. Yet I presume it is pretty awful to manually decompose and compose the method invocations and parameter sets. It depends on how well you like working with XML, I suppose. I've got no idea what document-orientied SOAP means either. Is that just pushing XML-files over a protocol? As I understand it, yes, although you still have to put the payload inside the usual SOAP boilerplate. Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: numpy, numarray, or numeric?
On Feb 15, 11:23 pm, Frank [EMAIL PROTECTED] wrote: On Feb 15, 4:40 pm, Christian Convey [EMAIL PROTECTED] wrote: I need to bang out an image processing library (it's schoolwork, so I can't just use an existing one). But I see three libraries competing for my love: numpy, numarray, and numeric. Can anyone recommend which one I should use? If one is considered the officially blessed one going forward, that would be my ideal. Thanks, Christian Hi, yeah numpy is the newest one. It has only one drawback, there is no comprehensive documentation available that would be free but of course you could buy one. numpy is very similar to the other two packages but not identical that means one has always some troulbe finding out how things work. For example, in numarray you can calculate the eigenvectors of a matrix with eigenvectors(A), in numpy it is eig(A). This looks similar, but the difference is that in numarray the eigenvectors are returned as rows and in numpy as columns. If someone knows of a free manual, let me know. Frank Frank, I bought the manual, and I do recommend it, but I find the most useful documentation is in the docstrings, which I view via pydoc -g and then view in a browser. Rick -- http://mail.python.org/mailman/listinfo/python-list
Re: Pep 3105: the end of print?
Edward K Ream schreef: I'm pretty sure you're mistaken. Python 3 will be the release that breaks code. Hopefully very little, but there almost certainly will be some. Pep 3105 breaks a *lot* of code, despite the bland assertion that most production programs don't use print. Presumably, Guido wanted to improve print in such a way that *more* people would use it. But the effect of the pep is that *less* people will be able to use print, *regardless* of how backward compatible Python 3.x is 'allowed' to be. AFAIK the intention is not primarily to get more people to use print. Instead Guido has felt for some time that the print statement is a wart in the language (see the references in PEP 3105 for his arguments), and Python 3000 seems like a good opportunity to fix it once and for all. Precisely because AFAIK the point of Python 3000 is to fix a number of long-standing shortcomings, even if that means giving up a degree of backward compatibility. -- If I have been able to see further, it was only because I stood on the shoulders of giants. -- Isaac Newton Roel Schroeven -- http://mail.python.org/mailman/listinfo/python-list
Re: Pep 3105: the end of print?
Edward K Ream schreef: There are a tool called 2to3 that translates things like print foo to print(foo). The point of my original post was that if I want to maintain a common code base the tool must translate 'print foo' to 'print2(foo)'. At first sight it seems to me that it's pretty straightforward to translate print(foo) to print2(foo) once 2to3 has done its job. It looks your main issue is that you're complaining that Python 3000 is going to break things in a non-backward compatible way. If you want to change that, you're going to be fighting an uphill battle, as this quote from PEP 3000 illustrates: We need a meta-PEP to describe the compatibility requirements. Python 3000 will break backwards compatibility. There is no requirement that Python 2.9 code will run unmodified on Python 3.0. I'm not sure whether it is reasonable to require that Python 2.x code can be mechanically translated to equivalent Python 3.0 code; Python's dynamic typing combined with the plans to change the semantics of certain methods of dictionaries, for example, would make this task really hard. However, it would be great if there was some tool that did at least an 80% job of translation, pointing out areas where it wasn't sure using comments or warnings. Perhaps such a tool could be based on something like Pychecker. -- If I have been able to see further, it was only because I stood on the shoulders of giants. -- Isaac Newton Roel Schroeven -- http://mail.python.org/mailman/listinfo/python-list
Re: Pep 3105: the end of print?
On Fri, 16 Feb 2007 06:07:42 -0600, Edward K Ream wrote:
I'm pretty sure you're mistaken. Python 3 will be the release that breaks
code. Hopefully very little, but there almost certainly will be some.
Pep 3105 breaks a *lot* of code, despite the bland assertion that most
production programs don't use print.
Presumably, Guido wanted to improve print in such a way that *more* people
would use it.
I don't think Guido cares about _how many_ people use print. I think he
cares about making print better. If that leads to more people using it,
that's a bonus. But your and my guesses about what Guido cares about
aren't terribly important.
But the effect of the pep is that *less* people will be able
to use print, *regardless* of how backward compatible Python 3.x is
'allowed' to be.
I don't think that follows at all. print is only a problem if you expect
your code to work under both Python 2.x and 3.x. I wouldn't imagine
that many people are going to expect that: I know I don't. There are
likely to be a whole lot of things which change, sometimes radically, from
one to the other. They'll support one or the other, or fork the code, or
in extreme cases take over maintenance of Python 2.x (it is open source,
you can do that).
If you want to future-proof your Python code, well, you can't fully
because nobody yet knows all the things which will change. But you can
start by not calling print directly. There are a number of alternatives,
depending on what you're doing. Here's a simple function that does very
close to what print currently does:
def print_(*args, where=None, newline=True):
if where is None:
where = sys.stdout
args = [str(arg) for arg in args]
where.write(' '.join(args))
if newline:
where.write('\n')
--
Steven.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Pep 3105: the end of print?
On Feb 16, 2:01 pm, Edward K Ream [EMAIL PROTECTED] wrote:
Why won't it be possible to make 'print' in Python 3 that supports all
the functionality of the current print statement, and then translate to
that ?
I saw an assertion to the effect that it wasn't possible - but no proof.
As discussed in the original post, the problem is the reverse: the Python
2.x print statement does not support the keyword args required by the pep,
so that print(foo) **in Python 2.x** can not simulate the effect of the
print statement with a trailing comma. Here is the theorum carefully stated
and proved.
Theorem: is not possible to define a function called print in Python 3.x
such that
A) print (whatever) is syntaxtically valid in Python 2.x and
B) print(whatever) outputs what 'print whatever' outputs in Python 2.x for
all values of 'whatever'.
Proof:
It is impossible for the print function to simulate the effect of the print
statement with a trailing comma. Indeed, print ('line'), and print
('line',) (note the position of the commas) are valid in Python 2.x, but
neither does what is wanted. And print('line',end='') is invalid in Python
2.x. Let's look at some examples:
1. The following works (prints 'line after\n') in Python 2.x, but will not
suppress the newline in Python 3.x:
print('line'),
print('after')
2. The following doesn't work in Python 2.x. (It prints
('line',)\nafter).
print ('line',)
print ('after')
3. print ('line',end='') produces a syntax error in Python 2.x:
print ('line',end='')
^
SyntaxError: invalid syntax
That's the proof. Can you find a flaw in it?
I mentioned the 2to3 translator- the goal of which is *precisely* to
allow you to write code that will run on Python 2.X and when
translated run under Python 3.0.
You then repeated the problem with the 'print' statement.
It may be true that you won't be able to write code that runs
untranslated on 2 and 3. That doesn't stop you writing code for Python
2.X, then translating a version for Python 3. (Uhm... indeed that's
the point of 2to3.)
So you only have one codebase to maintain and you can still use
print...
Fuzzyman
http://www.voidspace.org.uk/python/articles.shtml
Edward
Edward K. Ream email: [EMAIL PROTECTED]
Leo:http://webpages.charter.net/edreamleo/front.html
--
http://mail.python.org/mailman/listinfo/python-list
Re: Pep 3105: the end of print?
print is only a problem if you expect your code to work under both Python 2.x and 3.x. Exactly. Edward Edward K. Ream email: [EMAIL PROTECTED] Leo: http://webpages.charter.net/edreamleo/front.html -- http://mail.python.org/mailman/listinfo/python-list
Re: Pep 3105: the end of print?
on 16.02.2007 13:02 Edward K Ream said the following: There are a tool called 2to3 that translates things like print foo to print(foo). The point of my original post was that if I want to maintain a common code base the tool must translate 'print foo' to 'print2(foo)'. I think you are misunderstanding the purpose of the 2to3 tool. It is supposed to create a new version of the code that runs on py3, while you can still run your *old* code on py2.x There won't be a common code base for all python versions. You will have to decide at what point you want to switch from developing the 2.x code (and using the 2to3 tool to support py3) to developing the py3 code. (You might then develop a 3to2 tool, but I think this discussion is getting way ahead of its time. ;-) -- http://mail.python.org/mailman/listinfo/python-list
Re: Pep 3105: the end of print?
On Sat, 17 Feb 2007 01:32:21 +1100, Steven D'Aprano [snip] I don't think that follows at all. print is only a problem if you expect your code to work under both Python 2.x and 3.x. I wouldn't imagine that many people are going to expect that: I know I don't. I think some people are confused that the language Python 3.x has Python in its name, since there is already a language with Python in its name, with which it is not compatible. Jean-Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: Pep 3105: the end of print?
It looks your main issue is that you're complaining that Python 3000 is going to break things in a non-backward compatible way. No. My complaint is *only* that changing the meaning of 'print' is needless pain. Edward Edward K. Ream email: [EMAIL PROTECTED] Leo: http://webpages.charter.net/edreamleo/front.html -- http://mail.python.org/mailman/listinfo/python-list
Re: Approaches of interprocess communication
Ben Finney wrote: Gabriel Genellina [EMAIL PROTECTED] writes: (And I would expect that making a connection to localhost actually does *not* go down up to the network card hardware layer, but I don't know for real if this is the case or not). It damned well better. That's the entire point of the loopback interface: to get all the network layer code involved, but not to talk on a physical network interface. If a programmer decides on behalf of the user that localhost should be treated specially, that programmer is making an error. Inter-process TCP/IP communication between two processes on the same host invariably uses the loopback interface (network 127.0.0.0). According to standards, all addresses in that network space refer to the local host, though 127.0.0.1 is conventionally used. The transmit driver for the loopback interface receives a datagram from the local network layer and immediately announces its reception back to the local network layer. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://del.icio.us/steve.holden Blog of Note: http://holdenweb.blogspot.com See you at PyCon? http://us.pycon.org/TX2007 -- http://mail.python.org/mailman/listinfo/python-list
Re: Pep 3105: the end of print?
On Fri, 16 Feb 2007 08:01:11 -0600, Edward K Ream wrote: Why won't it be possible to make 'print' in Python 3 that supports all the functionality of the current print statement, and then translate to that ? I saw an assertion to the effect that it wasn't possible - but no proof. As discussed in the original post, the problem is the reverse: the Python 2.x print statement does not support the keyword args required by the pep, so that print(foo) **in Python 2.x** can not simulate the effect of the print statement with a trailing comma. Here is the theorum carefully stated and proved. Theorem: is not possible to define a function called print in Python 3.x such that A) print (whatever) is syntaxtically valid in Python 2.x and B) print(whatever) outputs what 'print whatever' outputs in Python 2.x for all values of 'whatever'. [snip] That's the proof. Can you find a flaw in it? No, but it doesn't matter. There's no particular reason why you have to write print (whatever) in your code. What you need is *some function* that is capable of duplicating the functionality of print, which can be used under Python 2.x and 3. It isn't hard to write a function that will duplicate print's functionality, so long as you give up the requirement that it is called just like print. The problem you describe with the print syntax only is a problem if you insist on supporting Python 2.x and 3 from the same codebase. I don't expect many people will try to do that. For those who do, don't use the print syntax. As for the rest of us, we'll just continue to use print using whichever syntax is appropriate. -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Re: Pep 3105: the end of print?
On Fri, 16 Feb 2007 06:42:55 -0800, Fuzzyman wrote: I mentioned the 2to3 translator- the goal of which is *precisely* to allow you to write code that will run on Python 2.X and when translated run under Python 3.0. Unfortunately, that is not a realistic goal for the 2to3 translator. The goal is to accurately translate 80% of Python code that needs changing, and issue warnings for the other 20%. You then repeated the problem with the 'print' statement. It may be true that you won't be able to write code that runs untranslated on 2 and 3. That doesn't stop you writing code for Python 2.X, then translating a version for Python 3. (Uhm... indeed that's the point of 2to3.) So you only have one codebase to maintain and you can still use print... No, you have TWO sets of code. You have the code you write, and the code you have run through 2to3. Even if 2to3 gives you 100% coverage, which it won't, you still have two codebases. -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Re: Pickling of generators
KIaus Muller wrote: Generators are becoming more and more important and powerful in Python. The inability of pickle to save/restore generators has become a major (and growing) limitation to the full exploitation of generators. The requirement for pickling generators has already been raised in 2003. My project (SimPy - Simulation in Python) has had this requirement since its inception in 2002. Generator pickling would make saving and reloading simulation state trivial. The workarounds one has to use without this capability are baroque and beyond the expertise of a typical simulation user. Is there any hope of action in this area in the foreseeable future? I doubt it, though who can know what's in the minds of other developers. You might want to look at Stackless Python, which allows you to pickle tasklets and resume them - even on a machine of a different architecture. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://del.icio.us/steve.holden Blog of Note: http://holdenweb.blogspot.com See you at PyCon? http://us.pycon.org/TX2007 -- http://mail.python.org/mailman/listinfo/python-list
Re: Command line prompt broken on XP with Python 2.5 - help!
On Feb 16, 5:52 am, Endless Story [EMAIL PROTECTED] wrote: My last version of Python was 2.4, running smoothly on XP with path c: \Python24 - no need even to include this path in PATH; everything worked as it's supposed to at the command line. Just installed Python 2.5, after uninstalling 2.4 (and also 2.3 which had lingered). Now if I open a shell in Windows Python is not available! Here are the symptoms: - If I open a shell using Command line here with XP Powertools, then enter python at the prompt, nothing happens. I don't get a message that the command is not recognized, but neither do I get the Python prompt. Instead the Windows prompt comes back. No messages, no Python, no nothing. - If I go so far as to specify the full path to the Python executable, I do get the Python prompt and Python appears to work properly - except that I can't exit with CTRL-Z. - If I open a shell from the Start menu, e.g. Start run command, then try entering python, the shell simply blows up. What is going on here? I have uninstalled and reinstalled Python 2.5, to no avail. I have gone so far as to specify c:\Python25 (the install path) in my PATH variable, but this makes no difference. Right now Python is unusable to me from the command prompt, meaning all of my automation scripts that I run at the command line are gone too. Are you talking about the Environment Variables--System Variable-- path? You may want to right click on My Computer--System Properties-- Advanced--Environment Variables--System variables--Path--Edit. And check to see if it's there, if not then add it. Thanks, Jim -- http://mail.python.org/mailman/listinfo/python-list
Re: Pep 3105: the end of print?
So you only have one codebase to maintain and you can still use print... Not if the theorum is correct. It may be true that you won't be able to write code that runs untranslated on 2 and 3. That's my definition of a common code base. That is the content of the theorum. That doesn't stop you writing code for Python 2.X, then translating a version for Python 3. (Uhm... indeed that's the point of 2to3.) That is not what I would call a common code base. The developer would have to run the translater every time the code changed. And if the Python 3.0 code were considered the 'master' code, the developer would need a 3to2 translater. Either disprove the theorum or give up the notion of having a common code base that uses print. Edward Edward K. Ream email: [EMAIL PROTECTED] Leo: http://webpages.charter.net/edreamleo/front.html -- http://mail.python.org/mailman/listinfo/python-list
Re: Pep 3105: the end of print?
That's the proof. Can you find a flaw in it? No, but it doesn't matter. There's no particular reason why you have to write print (whatever) in your code. What you need is *some function* that is capable of duplicating the functionality of print, Precisely wrong. The title of this thread is 'the end of print', and the whole point of my comments is that spelling matters. I would have absolutely no objection to the pep if it specified some other name for an 'official' print function. Pick any name, preferably longer than two characters, that does not conflict with either an existing global function or module. Edward Edward K. Ream email: [EMAIL PROTECTED] Leo: http://webpages.charter.net/edreamleo/front.html -- http://mail.python.org/mailman/listinfo/python-list
Re: Pep 3105: the end of print?
On Fri, 16 Feb 2007 09:49:03 -0500, Jean-Paul Calderone wrote: On Sat, 17 Feb 2007 01:32:21 +1100, Steven D'Aprano [snip] I don't think that follows at all. print is only a problem if you expect your code to work under both Python 2.x and 3.x. I wouldn't imagine that many people are going to expect that: I know I don't. I think some people are confused that the language Python 3.x has Python in its name, since there is already a language with Python in its name, with which it is not compatible. There is no language Python 3 -- yet. We're still all guessing just how compatible it will be with Python 2. To be precise, there is an experimental Python 3, but the specifications of the language are not fixed yet. As for the name... big deal. C and C++ and Objective C are completely different languages. Fortran 77 and Fortran 90 aren't exactly the same; nobody expects the same code to run unmodified on Forth 77 and FigForth, or any of another three dozen varieties of Forth. And dare I mention Java and Javascript? Even in the Python world, nobody expects to run the same code base under C Python and Jython and IronPython and PyPy. -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Re: Pep 3105: the end of print?
On Feb 16, 2:54 pm, Steven D'Aprano [EMAIL PROTECTED] wrote: On Fri, 16 Feb 2007 06:42:55 -0800, Fuzzyman wrote: I mentioned the 2to3 translator- the goal of which is *precisely* to allow you to write code that will run on Python 2.X and when translated run under Python 3.0. Unfortunately, that is not a realistic goal for the 2to3 translator. The goal is to accurately translate 80% of Python code that needs changing, and issue warnings for the other 20%. Right, but it *was* a stated aim of the translator when discussed on Python-dev recently. You then repeated the problem with the 'print' statement. It may be true that you won't be able to write code that runs untranslated on 2 and 3. That doesn't stop you writing code for Python 2.X, then translating a version for Python 3. (Uhm... indeed that's the point of 2to3.) So you only have one codebase to maintain and you can still use print... No, you have TWO sets of code. You have the code you write, and the code you have run through 2to3. Even if 2to3 gives you 100% coverage, which it won't, you still have two codebases. Only one of which you maintain - if the translator works 100% (which I accept may be unrealistic). Fuzzyman http://www.voidspace.org.uk/python/articles.shtml -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Re: Command line prompt broken on XP with Python 2.5 - help!
On Feb 16, 9:56 am, Jim [EMAIL PROTECTED] wrote: On Feb 16, 5:52 am, Endless Story [EMAIL PROTECTED] wrote: Are you talking about the Environment Variables--System Variable--path? You may want to right click on My Computer--System Properties--Advanced-- Environment Variables--System variables--Path--Edit. And check to see if it's there, if not then add it. I've already added the new python to my path in this fashion, but to no avail. Besides, if it were a path problem in the usual sense, the symptom would be a message at the command line saying that python is not recognized. Since I don't get this message, it's not a typical path problem. What it is, I don't know - that's my quandry. -- http://mail.python.org/mailman/listinfo/python-list
Re: Pep 3105: the end of print?
On Feb 16, 3:00 pm, Edward K Ream [EMAIL PROTECTED] wrote: So you only have one codebase to maintain and you can still use print... Not if the theorum is correct. It may be true that you won't be able to write code that runs untranslated on 2 and 3. That's my definition of a common code base. That is the content of the theorum. Ok - in which case it is very limited. That doesn't stop you writing code for Python 2.X, then translating a version for Python 3. (Uhm... indeed that's the point of 2to3.) That is not what I would call a common code base. But it is what I call a common code base. We are at an impasse. :-) The developer would have to run the translater every time the code changed. And if the Python 3.0 code were considered the 'master' code, the developer would need a 3to2 translater. Either disprove the theorum or give up the notion of having a common code base that uses print. Yes the use of print is changing in a backwards incompatible way, no one is disputing that. Personally I wish it wasn't, print 'feels like a statement' to me. But it's not the end of the world and it is *definitely* going to be able to be handled by 2to3. It's also not about to change. Fuzzyman http://www.voidpsace.org.uk/python/articles.shtml Edward Edward K. Ream email: [EMAIL PROTECTED] Leo:http://webpages.charter.net/edreamleo/front.html -- http://mail.python.org/mailman/listinfo/python-list
Reg Google Web Toolkit and Python
Hi , We have a project where I need to read files store them in database in the backend.We have done this in python.Now we decided to use Ajax technique for user interface.For that we found that GWT is one of the best toolkits.Now I got a doubt can I interface GWT with python. Thanks , Shadab. Send instant messages to your online friends http://uk.messenger.yahoo.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Pep 3105: the end of print?
On Sat, 17 Feb 2007 02:17:23 +1100, Steven D'Aprano [EMAIL PROTECTED] wrote: On Fri, 16 Feb 2007 09:49:03 -0500, Jean-Paul Calderone wrote: On Sat, 17 Feb 2007 01:32:21 +1100, Steven D'Aprano [snip] I don't think that follows at all. print is only a problem if you expect your code to work under both Python 2.x and 3.x. I wouldn't imagine that many people are going to expect that: I know I don't. I think some people are confused that the language Python 3.x has Python in its name, since there is already a language with Python in its name, with which it is not compatible. There is no language Python 3 -- yet. We're still all guessing just how compatible it will be with Python 2. To be precise, there is an experimental Python 3, but the specifications of the language are not fixed yet. As for the name... big deal. C and C++ and Objective C are completely different languages. Fortran 77 and Fortran 90 aren't exactly the same; nobody expects the same code to run unmodified on Forth 77 and FigForth, or any of another three dozen varieties of Forth. And dare I mention Java and Javascript? I was just pointing out that some people might be confused. I didn't make any judgement about that fact. You seem to be suggesting that because there are other confusing things, it's okay for Python to be confusing too. I'm not making any judgements about that, either. Even in the Python world, nobody expects to run the same code base under C Python and Jython and IronPython and PyPy. I wonder if the fact that Jython and IronPython can't run most Python programs is one of the reasons they are generally only used in special circumstances? PyPy isn't finished yet, however, it _is_ an /explicit/ goal of PyPy to be compatible with CPython, so it doesn't really belong on that list. Jean-Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: Command line prompt broken on XP with Python 2.5 - help!
Endless Story wrote: On Feb 16, 9:56 am, Jim [EMAIL PROTECTED] wrote: On Feb 16, 5:52 am, Endless Story [EMAIL PROTECTED] wrote: Are you talking about the Environment Variables--System Variable--path? You may want to right click on My Computer--System Properties--Advanced-- Environment Variables--System variables--Path--Edit. And check to see if it's there, if not then add it. I've already added the new python to my path in this fashion, but to no avail. Besides, if it were a path problem in the usual sense, the symptom would be a message at the command line saying that python is not recognized. Since I don't get this message, it's not a typical path problem. What it is, I don't know - that's my quandry. I've certainly never seen anything like what you've described, and I've had Python 2.5 installed and uninstalled on several different machines (Win2k WinXP). I would ask if you had *any* other Python installation -- say a cygwin one -- which might just be getting in the way? Are you an administrator on the machine you're on? Sometimes (a while ago and with the ActiveState distro rather than python.org one) it has been known to cause problems if you're not. Do the previous installations still work? Clutching at straws, really. TJG -- http://mail.python.org/mailman/listinfo/python-list
[ANN] wxCocoaDialog v0.3
wxCocoaDialog v0.3 http://code.google.com/p/wxcocoadialog/ wxCocoaDialog is an multi-platform port of the CocoaDialog application for OS X, that allows the use of common GUI controls such as file selectors, text input, progress bars, yes/no confirmations and more with a command-line application. It is ideal for use in shell and Python scripts (or Perl, or Ruby, or... etc). Since the use of the original CocoaDialog is very common in shell scripts on Mac OS X, the port makes it possible to to also use such scripts on Linux and Windows (with cygwin). Implemented Controls As of wxCocoaDialog v0.3, the following controls are implemented: * inputbox * standard-inputbox * secure-inputbox * secure-standard-inputbox * dropdown * progressbar * textbox * msgbox * ok-msgbox * yesno-msgbox The wxWidgets port was originally created for use in the e text editor ( http://e-texteditor.com ), which supports TextMate bundles and can be extended with shell scripts (through cygwin) and in any scripting language. Since it could be useful in a lot of other contexts than e, it was released to the community as open source. -- http://mail.python.org/mailman/listinfo/python-list
why I don't like range/xrange
Hello! Many times I was suggested to use xrange and range instead of the while constructs, and indeed, they are quite more elegant - but, after calculating the overhead (and losen flexibility) when working with range/xrange, and while loops, you get to the conclusion that it isn't really worth using range/xrange loops. I'd like to show some examples and I'll be glad if someone can suggest some other fixes than while a loop :-) a) range overfllow : for i in range(0, 1 len(S)) : . OverflowError: range() result has too many items ok, so we fix this one with xrange ! b) xrange long int overflow : for i in xrange(0, 1 len(S)) : OverflowError: long int too large to convert to int Next thing I miss is the flexibility as in C for loops : for (i = 0; some_function() /* or other condition */ ; i++) or, for (i = 0 ; i 10 ; i++) i = 10; I don't think range/xrange sucks, but I really think there should be some other constructs to improve the looping flexibility. Other thing may be, that I just miss an equally elegant alternative that's why I'd like to hear some suggestions on how to fix the above issues.. (btw, I've already browsed the archives related to my issue,but i don't see any good solution) Thanks Jernej. -- http://mail.python.org/mailman/listinfo/python-list
Re: Pep 3105: the end of print?
Even in the Python world, nobody expects to run the same code base under C Python and Jython and IronPython and PyPy. Leo now runs under CPython with both wxWidgets and Tkinter. The gui code is confined to plugins, and a similar gui plugin will suffice to run Leo under IronPython. Indeed, Leo's startup code already runs unchanged under CPython and IronPython. I expect minimal changes will be needed to run Leo's core under Jython. And I *am* talking about a single code base: no translator needed. Edward Edward K. Ream email: [EMAIL PROTECTED] Leo: http://webpages.charter.net/edreamleo/front.html -- http://mail.python.org/mailman/listinfo/python-list
Re: Pep 3105: the end of print?
On Fri, 16 Feb 2007 09:07:02 -0600, Edward K Ream wrote: That's the proof. Can you find a flaw in it? No, but it doesn't matter. There's no particular reason why you have to write print (whatever) in your code. What you need is *some function* that is capable of duplicating the functionality of print, Precisely wrong. Are you trying to say that the name print is more important to you than the functionality? If not, then I have no idea why you say I'm wrong. The title of this thread is 'the end of print', and the whole point of my comments is that spelling matters. That might be the point you are trying to make, but you haven't succeeded. I would have absolutely no objection to the pep if it specified some other name for an 'official' print function. Pick any name, preferably longer than two characters, that does not conflict with either an existing global function or module. Huh? Now you're just not making sense. If Python 3 dropped the print statement and replaced it with official_print_function(), how would that help you in your goal to have a single code base that will run on both Python 2.3 and Python 3, while still using print? In software development there is a common saying: Good, Fast, Cheap -- Pick any two. The same holds here: Keep the print name; Keep the print functionality; Keep a single code base. Pick any two. -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Re: Reg Google Web Toolkit and Python
On 2/16/07, Shadab Sayani [EMAIL PROTECTED] wrote: Hi , We have a project where I need to read files store them in database in the backend.We have done this in python.Now we decided to use Ajax technique for user interface.For that we found that GWT is one of the best toolkits.Now I got a doubt can I interface GWT with python. http://pyjamas.pyworks.org/ is the way to go. -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ -- http://mail.python.org/mailman/listinfo/python-list
Re: output to console and to multiple files
On Feb 15, 5:48 pm, Gabriel Genellina [EMAIL PROTECTED] wrote: En Thu, 15 Feb 2007 19:35:10 -0300, Matimus [EMAIL PROTECTED] escribió: I think you should be able to use my or goodwolf's solution with the subprocess module. Something like this (untested): [code] class TeeFile(object): def __init__(self,*files): self.files = files def write(self,txt): for fp in self.files: fp.write(txt) I tried this at lunch and it doesn't work. Some version of this method may work, but Popen tries to call the 'fileno' method of the TeeFile object (at least it did on my setup) and it isn't there. This is just a preemptive warning before someone comes back to let me know my code doesn't work. I don't think any Python only solution could work. The pipe options available for subprocess are those of the underlying OS, and the OS knows nothing about Python file objects. -- Gabriel Genellina I've tried the subprocess method before without any luck. Thanks for all your suggestions. I guess it's time to rethink what I want to do. -- http://mail.python.org/mailman/listinfo/python-list
Re: Pep 3105: the end of print?
Keep the print name; Keep the print functionality; Keep a single code base. Retain the print statement and its functionality, and define an official_print_function to be used in the common code base. I would be satisfied with this (it's what I do now), and it would cause no needless problems for anyone. Having an official print function is a *good* idea, provided it isn't called print :-) Edward Edward K. Ream email: [EMAIL PROTECTED] Leo: http://webpages.charter.net/edreamleo/front.html -- http://mail.python.org/mailman/listinfo/python-list
MS Word mail merge automation
Hi Steve M. , Your articole is very interesting to me becouse I'm just tring to do the same thing. Could you please show me the last version of your python code so that I could use it for my purpose. I'm not a programmer but a my friend could help me for this. Thanks so much in advance for your help Giovanni -- Passa a Infostrada. ADSL e Telefono senza limiti e senza canone Telecom http://click.libero.it/infostrada16feb07 -- http://mail.python.org/mailman/listinfo/python-list
Re: Pep 3105: the end of print?
On 2/16/07, Jean-Paul Calderone [EMAIL PROTECTED] wrote: I was just pointing out that some people might be confused. I didn't make any judgement about that fact. You seem to be suggesting that because there are other confusing things, it's okay for Python to be confusing too. I'm not making any judgements about that, either. Does not change always cause confusion? The confusion in Python land is pretty minor in comparison to the one caused Java 1.1, 1.2, 1.3, 1.4, 1.5, 1.6, 1, 2, 4, 5, 6 SE/ME/EE. I think that people are just complaining to much. The python-devvers are managing the transition extraordinarily well. Even in the Python world, nobody expects to run the same code base under C Python and Jython and IronPython and PyPy. I wonder if the fact that Jython and IronPython can't run most Python programs is one of the reasons they are generally only used in special circumstances? Or maybe it is because Jython requires Java and IronPython a CLR? -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: Pep 3105: the end of print?
On Fri, 16 Feb 2007 16:49:05 +0100, BJörn Lindqvist [EMAIL PROTECTED] wrote: On 2/16/07, Jean-Paul Calderone [EMAIL PROTECTED] wrote: I was just pointing out that some people might be confused. I didn't make any judgement about that fact. You seem to be suggesting that because there are other confusing things, it's okay for Python to be confusing too. I'm not making any judgements about that, either. Does not change always cause confusion? The confusion in Python land is pretty minor in comparison to the one caused Java 1.1, 1.2, 1.3, 1.4, 1.5, 1.6, 1, 2, 4, 5, 6 SE/ME/EE. You're just repeating the same argument. I don't buy it, but I'm sure you and other people will continue to repeat it. Fine, whatever, but I'm not interested, and your not countering the point I made. I think that people are just complaining to much. The python-devvers are managing the transition extraordinarily well. Even in the Python world, nobody expects to run the same code base under C Python and Jython and IronPython and PyPy. I wonder if the fact that Jython and IronPython can't run most Python programs is one of the reasons they are generally only used in special circumstances? Or maybe it is because Jython requires Java and IronPython a CLR? I have a JVM and I have Mono. I don't use Jython or IronPython. Maybe because none of my Python programs run on it? Jean-Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: why I don't like range/xrange
On 16 Feb 2007 07:30:15 -0800, stdazi [EMAIL PROTECTED] wrote: Hello! Many times I was suggested to use xrange and range instead of the while constructs, and indeed, they are quite more elegant - but, after calculating the overhead (and losen flexibility) when working with range/xrange, and while loops, you get to the conclusion that it isn't really worth using range/xrange loops. I'd like to show some examples and I'll be glad if someone can suggest some other fixes than while a loop :-) a) range overfllow : for i in range(0, 1 len(S)) : . OverflowError: range() result has too many items ok, so we fix this one with xrange ! b) xrange long int overflow : for i in xrange(0, 1 len(S)) : OverflowError: long int too large to convert to int xrange should be able to handle this. It's probably worth a bug report. Next thing I miss is the flexibility as in C for loops : for (i = 0; some_function() /* or other condition */ ; i++) You'd use a regular for or a while loop here, without the loop index. or, for (i = 0 ; i 10 ; i++) i = 10; This doesn't do anything as written. For all reasonable uses of it, you can do it the same way in Python. Writing C code in Python is a waste of time and an exercise in frustration. I don't think range/xrange sucks, but I really think there should be some other constructs to improve the looping flexibility. Other thing may be, that I just miss an equally elegant alternative that's why I'd like to hear some suggestions on how to fix the above issues.. (btw, I've already browsed the archives related to my issue,but i don't see any good solution) Enumeration over range() and xrange() is rare in Python. loops like: data = [...] for ii in xrange(len(data)): datum = data[ii] are a wart. Enumerate over whatever you're going to work with. In some cases, you want the index and the item. Use enumerate for that: for index, datum in enumerate(data): -- http://mail.python.org/mailman/listinfo/python-list
Re: why I don't like range/xrange
On Feb 16, 9:30 am, stdazi [EMAIL PROTECTED] wrote: Hello! Many times I was suggested to use xrange and range instead of the while constructs, and indeed, they are quite more elegant - but, after calculating the overhead (and losen flexibility) when working with range/xrange, and while loops, you get to the conclusion that it isn't really worth using range/xrange loops. I'd like to show some examples and I'll be glad if someone can suggest some other fixes than while a loop :-) a) range overfllow : for i in range(0, 1 len(S)) : . OverflowError: range() result has too many items ok, so we fix this one with xrange ! b) xrange long int overflow : for i in xrange(0, 1 len(S)) : OverflowError: long int too large to convert to int Next thing I miss is the flexibility as in C for loops : for (i = 0; some_function() /* or other condition */ ; i++) or, for (i = 0 ; i 10 ; i++) i = 10; I don't think range/xrange sucks, but I really think there should be some other constructs to improve the looping flexibility. Other thing may be, that I just miss an equally elegant alternative that's why I'd like to hear some suggestions on how to fix the above issues.. (btw, I've already browsed the archives related to my issue,but i don't see any good solution) Thanks Jernej. Very little of my own code uses range or xrange, most of my for loops iterate over a sequence or generator, as in for item in blahList: do something with item. I think range/xrange are common beginner's constructs, since they reflect a more C-like looping method (for i in range(len(blahList)): do something with blahList[i]). I really would *not* encourage use of range/xrange, but feel that iteration over sequences and generators is the more elegant/Pythonic way to go - who is suggesting you use range/xrange? For that matter, just what is it you plan to do 2**len(S) times? If S is of any significant length, the sun may be a lump of coal before you are finished, regardless of what loop mechanism you use (although it would make sense to avoid range's implementation of creating a list of 2**len(S) items - fortunately the implementation already resolves this problem by raising a that's too many items exception, and thankfully so). Maybe instead of working around range/xrange, you should think whether a 2**len(S) approach to your problem is feasible in the first place. -- Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: Command line prompt broken on XP with Python 2.5 - help!
On Feb 16, 10:29 am, Tim Golden [EMAIL PROTECTED] wrote: I would ask if you had *any* other Python installation -- say a cygwin one -- which might just be getting in the way? It's a cygwin problem, guddammit. I was wondering if this might be the case - I should have mentioned in my initial post that I've got a whole Cygwin setup, including Python. I know the conflict is the problem because just now I opened up a command shell in XP (not the Cywgin bash window), and instead of typing python and getting nothing, I tried which python - which when you think about it, shouldn't even work in a XP shell. But somehow Cygwin is mingling some of its capabilities with the XP shell, because which python actually gets an answer - /usr/bin/python, which is Cygwin. Now the question is how to fix this - I don't want to uninstall the Cygwin version. Instead I need some way of unknotting Cygwin's intrusion into what should be an XP-only shell, or else a way of giving priority when in that shell (and not the bash shell, which I also use) to the Python executable residing at C:\Python25. -- http://mail.python.org/mailman/listinfo/python-list
Re: why I don't like range/xrange
stdazi wrote: Hello! Many times I was suggested to use xrange and range instead of the while constructs, and indeed, they are quite more elegant - but, after calculating the overhead (and losen flexibility) when working with range/xrange, and while loops, you get to the conclusion that it isn't really worth using range/xrange loops. I'd like to show some examples and I'll be glad if someone can suggest some other fixes than while a loop :-) a) range overfllow : for i in range(0, 1 len(S)) : . OverflowError: range() result has too many items ok, so we fix this one with xrange ! b) xrange long int overflow : for i in xrange(0, 1 len(S)) : OverflowError: long int too large to convert to int Next thing I miss is the flexibility as in C for loops : for (i = 0; some_function() /* or other condition */ ; i++) or, for (i = 0 ; i 10 ; i++) i = 10; I don't think range/xrange sucks, but I really think there should be some other constructs to improve the looping flexibility. Other thing may be, that I just miss an equally elegant alternative that's why I'd like to hear some suggestions on how to fix the above issues.. (btw, I've already browsed the archives related to my issue,but i don't see any good solution) Thanks Jernej. Your example of for i in xrange(0, 1len(s)): must have resulted in a number greater than 1 billion. Are you really doing this much or are you just pointing out an edge case here? You can always use while loop: i=0 while i (1len(s)): i+=1 or i=1 while 1: if i == 10: break i+=1 Personally I use a lot of for loops in my code where I iterate over lists or with a generator as my target that returns instances of my data until exhausted and find the code easy to read: for line in myfile: # do something with the line No need to even think about numbers here unless I want to keep track of the line numbers in which case I would do: for linenumber, line in enumerate(myfile): # do something with each linenumber, line I find that I use i, j, k pointers less and less as I write more code in Python. I guess it is just what you get accustomed to using. -Larry -- http://mail.python.org/mailman/listinfo/python-list
Re: why I don't like range/xrange
On Fri, 16 Feb 2007 07:30:15 -0800, stdazi wrote: Hello! Many times I was suggested to use xrange and range instead of the while constructs, and indeed, they are quite more elegant - but, after calculating the overhead (and losen flexibility) when working with range/xrange, and while loops, you get to the conclusion that it isn't really worth using range/xrange loops. I prefer to _measure_ the overhead instead of guessing. import timeit whileloop = i = 0 while i N: i += 1 pass forloop = for i in xrange(N): pass Now let's see how fast the loops are. timeit.Timer(whileloop, N = 1).repeat(3, 1000) [3.5716907978057861, 3.5263650417327881, 3.5975079536437988] timeit.Timer(forloop, N = 1).repeat(3, 1000) [1.3608510494232178, 1.341961145401001, 1.3180010318756104] Looks to me that a for loop using xrange is more than twice as fast as a while loop. The advantage is about the same for small N: timeit.Timer(whileloop, N = 100).repeat(3, 1000) [0.052264213562011719, 0.049374103546142578, 0.041945934295654297] timeit.Timer(forloop, N = 100).repeat(3, 1000) [0.012259006500244141, 0.013512134552001953, 0.015196800231933594] What makes you think that a while loop has less overhead? I'd like to show some examples and I'll be glad if someone can suggest some other fixes than while a loop :-) a) range overfllow : for i in range(0, 1 len(S)) : . OverflowError: range() result has too many items ok, so we fix this one with xrange ! By the way, you don't need to write range(0, N). You can just write range(N). Yes, you're correct, range(some_enormous_number) will fail if some_enormous_number is too big. b) xrange long int overflow : for i in xrange(0, 1 len(S)) : OverflowError: long int too large to convert to int Are you really doing something at least 2147483647 times? I'm guessing that you would be better off rethinking your algorithm. Next thing I miss is the flexibility as in C for loops : for (i = 0; some_function() /* or other condition */ ; i++) This would be written in Python as: i = 0 while some_function(): i += 1 A more flexible way would be to re-write some_function() as an iterator, then use it directly: for item in some_function(): # do something with item or, for (i = 0 ; i 10 ; i++) i = 10; This would be written in Python as: for i in xrange(10): i = 10 I don't think range/xrange sucks, but I really think there should be some other constructs to improve the looping flexibility. Every loop can be turned into a while loop. If you have while, you don't _need_ anything else. But for elegance and ease of use, a small number of looping constructs is good. Python has: while condition: block else: # runs if while exits *without* hitting break statement block for item in any_sequence: block else: # runs if for exits *without* hitting break statement block Nice, clean syntax. any_sequence isn't limited to mere arithmetic sequences -- it can be any sequence of any objects. But if you need a C-style for loop, using integers, range/xrange([start, ] stop [, step]) is provided. -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Re: Pep 3105: the end of print?
On Fri, 16 Feb 2007 09:32:56 -0600, Edward K Ream wrote: Even in the Python world, nobody expects to run the same code base under C Python and Jython and IronPython and PyPy. Leo now runs under CPython with both wxWidgets and Tkinter. The gui code is confined to plugins, and a similar gui plugin will suffice to run Leo under IronPython. Indeed, Leo's startup code already runs unchanged under CPython and IronPython. I expect minimal changes will be needed to run Leo's core under Jython. And I *am* talking about a single code base: no translator needed. Good for Leo. I'm not being sarcastic. But that doesn't just happen, it happens because Leo's developers don't insist on using mutually incompatible CPython and IronPython features or modules, but instead worked really hard to *make* Leo work with both. They didn't just expect IronPython code to work unchanged with CPython (or vice versa). -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Re: Approaches of interprocess communication
About Linda: Am I right that it looks very similar to JavaSpaces? If yes, are there any funcdamental differences between those two? Yes, they are both linda implementations, but I have no idea what so ever how they compare. A local java expert maybe? -- http://mail.python.org/mailman/listinfo/python-list
