BayPIGgies: August 11, 7:30pm (Ironport)
The next meeting of BayPIGgies will be Thurs, August 11 at 7:30pm at Ironport. Hasan Diwan will present RRsR, a web-based RSS reader written using feedparser and python CGI. This is expected to be a short presentation; afterward, anyone who was at OSCON is invited to summarize what they saw/heard. BayPIGgies meetings alternate between IronPort (San Bruno, California) and Google (Mountain View, California). For more information and directions, see http://www.baypiggies.net/ Before the meeting, we plan to meet at 6pm for dinner. Discussion of dinner plans is handled on the BayPIGgies mailing list. This week will probably be at Creperie du Monde, six long blocks from IronPort (i.e., walking distance). Advance notice: The September 8 meeting agenda has not been set. Please send e-mail to [EMAIL PROTECTED] if you want to suggest an agenda (or volunteer to give a presentation). We already have a speaker for October. -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ The way to build large Python applications is to componentize and loosely-couple the hell out of everything. -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations.html
re:Python HTTP digest authentication woes...
I hacked this a little bit and it seems to do the trick. import urllib2 theurl = 192.168.0.25/TiVoConnect?Container=%2FNowPlayingCommand=QueryContainerRecurse=Yes print theurl protocol = 'https://' username = 'tivo' password = '11' authhandler = urllib2.HTTPDigestAuthHandler() authhandler.add_password(TiVo DVR, 192.168.0.25, username, password) opener = urllib2.build_opener(authhandler) urllib2.install_opener(opener) try: pagehandle = urllib2.urlopen(protocol + theurl) print pagehandle.readlines() except IOError, e: if hasattr(e, 'code'): if e.code != 401: print 'We got another error' print e.code else: print Error 401 print e.headers print e.headers['www-authenticate'] Cheers Dave -- http://mail.python.org/mailman/listinfo/python-list
Re: Metaclasses and new-style classes
Jan-Ole Esleben wrote: Hi! I've just posted a question about metaclasses in ZOPE on the ZOPE list, and one of the replies said that metaclasses (at least painless metaclasses) cannot be used without new-style classes (or rather, that they don't work where you cannot explicitly use new-style classes). I haven't so far been able to find _anything_ on the subject - what is true here? http://docs.python.org/ref/metaclasses.html http://www.python.org/2.2.3/descrintro.html In short, yes. The preferred method for making metaclasses requires new-style classes. There is an older method which uses what is called the Don Beaudry hook; Zope used to use it extensively before Python 2.2. You should avoid using that older method and stick to new-style classes. -- Robert Kern [EMAIL PROTECTED] In the fields of hell where the grass grows high Are the graves of dreams allowed to die. -- Richard Harter -- http://mail.python.org/mailman/listinfo/python-list
Re: How to determine that if a folder is empty?
could ildg: I want to check if a folder named foldername is empty. I use os.listdir(foldername)==[] to do this, but it will be very slow if the folder has a lot of sub-files. Is there any efficient ways to do this? The first thing to do is measure the performance of this operation in the context of your application to see if it is really worth extra effort. Tweaking this will depend on the platform. On Windows you can use ctypes and the system functions FindFirstFile/FindNextFile/FindClose, finishing once you see a single file. Directories always contain . and .. entries so they should be ignored. On other platforms there will be similar low level functions. Neil -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP: Specialization Syntax
Nicolas Fleury wrote: It is necessary to maintain a dictionary of types (to avoid redundacy) and simple things like: def makeType(someArgument): class MyObject: someArgument = someArgument return MyObject are not allowed. def makeClass(cls_name, **kw): return type(cls_name,(), kw) MyObject = makeClass(MyObject,a=8) MyObject class '__main__.MyObject' MyObject.a 8 Regards, Kay -- http://mail.python.org/mailman/listinfo/python-list
Re: Oreilly CodeZoo
gene tani wrote: http://radar.oreilly.com/archives/2005/08/codezoo_program_1.html http://python.codezoo.com/ Nice to see that python is in-demand, but what is the rationale for another ASPN cookbook/Parnassus / pypackage / dmoz type repository? We (PyPI / Cheese Shop developers) are talking to the CodeZoo people about the relationship between the two systems. Things PyPI has: 1. python setup.py register 2. python setup.py (sdist|bdist|bdist_egg|bdist_wininst|...) upload 3. http://cheeseshop.python.org/ 4. better categorisation (IMO) 5. XML-RPC interface 6. 852 packages registered The things that CodeZoo has: 1. reviews, user tips and ratings 2. a full-time editor to make sure that the reviews are reasonable 3. links to O'Reilly articles 4. a big DOWNLOAD button. hurm, that's a good idea, I should add one of those to the PyPI interface... I hope no-one has that patented 5. DOAP (being added to PyPI) 6. Ads in the top bar and a sidebar (hehe) Getting links from PyPI over to the CodeZoo information would be pretty easy. Getting links from the CodeZoo pages to PyPI information / packages would be pretty easy. Richard -- http://mail.python.org/mailman/listinfo/python-list
Re: How to determine that if a folder is empty?
Thank you . so you mean that this is not platform-independent? On 8/8/05, Neil Hodgson [EMAIL PROTECTED] wrote: could ildg: I want to check if a folder named foldername is empty. I use os.listdir(foldername)==[] to do this, but it will be very slow if the folder has a lot of sub-files. Is there any efficient ways to do this? The first thing to do is measure the performance of this operation in the context of your application to see if it is really worth extra effort. Tweaking this will depend on the platform. On Windows you can use ctypes and the system functions FindFirstFile/FindNextFile/FindClose, finishing once you see a single file. Directories always contain . and .. entries so they should be ignored. On other platforms there will be similar low level functions. Neil -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: How to determine that if a folder is empty?
could ildg wrote: I want to check if a folder named foldername is empty. I use os.listdir(foldername)==[] to do this, but it will be very slow if the folder has a lot of sub-files. Is there any efficient ways to do this? try: os.rmdir(path) empty = True except OSError: empty = False should be efficient. A directory (please stop calling them folders) can only be removed if it's empty. Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: IronPython 0.9 Released
Al Christians wrote: EP wrote: yes, my apologies to all things Iron and or Python. language and version can be confusing if one stays up late without coffee, or perhaps if one has not been debugging their English code properly. Still, it's a bit of a PITB to me that it says XP and not Win2000. Forcing you to upgrade, isn't it? Usual MS strategy. Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: Embedding a runtime graph in Qt3 designer generated UI
Hi Two questions : 1. Is it possible to use an import command in a qt3 designer code ? (I know that it is possible to write python inside the braces -- but is it possible to use an import command for some rather large libraries I wrote that I need to access ?). You can include import statements in Designer's comment dialog by prefixing them with Python: . This is covered in the PyQt documentation. 2. In the same vein, how does one embed a runtime plot in a qt3 UI ? It will need to be a python solution since I am using python libraries to acquire the data. Have a look at PyQwt which is a set of Python bindings for the Qt-based Qwt plotting library. Phil -- http://mail.python.org/mailman/listinfo/python-list
Re: Python's CSV reader
Stephan wrote: DictReader field names on the fly. Here is a rudimentary example of my working code and the data it can parse. - John|Smith Beef|Potatos|Dinner Roll|Ice Cream Susan|Jones Chicken|Peas|Biscuits|Cake Roger|Miller Pork|Salad|Muffin|Cookies - That sample data would have been valuable information in your original post. Here's what becomes of your code if you apply the zip trick from my first post (yes, I am sometimes stubborn): import itertools import csv HeaderFields = [First Name, Last Name] DetailFields = [Entree, Side Dish, Starch, Desert] instream = open(testdata.txt) heads = csv.DictReader(instream, HeaderFields, delimiter=|) details = csv.DictReader(instream, DetailFields, delimiter=|) for header, detail in itertools.izip(heads, details): print Header (%d fields): %s % (len(header), header) print Detail (%d fields): %s % (len(detail), detail) Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: Python HTTP digest authentication woes...
john wrote: I'm trying to access the XML version of my Tivo now playing list with python. It uses auth digest HTTP authentication. I could really use some help! I'm able to get this page using curl: curl --dump-header tivoHeaders --insecure --anyauth --user tivo:808 https://192.168.1.102/TiVoConnect?Command=QueryContainerContainer=%2FNowPlayingRecurse=Yes; But when I use my python script, I get rejected: https://192.168.1.102/TiVoConnect?Container=%2FNowPlayingCommand=QueryContainerRecurse=Yes Error 401 Server: tivo-httpd-1:7.1b-01-2:140 Set-Cookie: sid=DEC2D78EABF48A6D; path=/; expires=Saturday, 16-Feb-2013 00:00:00 GMT; WWW-Authenticate: Digest realm=TiVo DVR, nonce=FD08EF226909CA85, qop=auth Content-Length: 31 Content-Type: text/html Connection: close Digest realm=TiVo DVR, nonce=FD08EF226909CA85, qop=auth I've scrounged for examples out there and the couple that I've found just don't seem to work for me.. Here's one way I've tried: = import urllib2 theurl = 192.168.1.102/TiVoConnect?Container=%2FNowPlayingCommand=QueryContainerRecurse=Yes print Oh yeah - I didn't spot this before theurl = 192.168.1.102/TiVoConnect?Container=%2FNowPlayingCommand=QueryContainerRecurse=Yes this includes the parameters - which it shouldn't. :-) Fuzzy http://www.voidspace.org.uk/python -- http://mail.python.org/mailman/listinfo/python-list
Re: How to determine that if a folder is empty?
Reinhold Birkenfeld wrote: could ildg wrote: I want to check if a folder named foldername is empty. I use os.listdir(foldername)==[] to do this, but it will be very slow if the folder has a lot of sub-files. Is there any efficient ways to do this? try: os.rmdir(path) empty = True except OSError: empty = False should be efficient. A directory (please stop calling them folders) can only be removed if it's empty. Reinhold Unfortunately that destroys the directory if it was empty, and then you can't recreate it unless (a) you went to the trouble of preserving all of its attributes before deleting it, and (b) your script has OS-level permissions to recreate the directory with its original attributes (such as owners and permissions). Also note that modifying a filesystem can be significantly slower than reading from it (it varies widely across platforms). -- James -- http://mail.python.org/mailman/listinfo/python-list
Re: Splitting a string into groups of three characters
import re
str = '123456789983qw'
re.findall((.{3}), str)+[str[-(len(str) % 3):]]
[EMAIL PROTECTED] wrote:
Hi,
Is there a function that split a string into groups, containing an x
amount of characters?
Ex.
TheFunction(Hello World,3)
Returns:
['Hell','o W','orl','d']
Any reply would be truly appreciated.
Thank You,
--
Best regards,
Maksim Kasimov
mailto: [EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python -- (just) a successful experiment?
Hallöchen! Terry Reedy [EMAIL PROTECTED] writes: [...] Consider Hypothesis 1: someone learned Python and Tkinter, felt dissatisfied with Tkinter, went searching the universe for an alternative, found GTK, and wrote PyGTK, perhaps learning C in the process. Hypothesis 2: a C-programmer who is a satisfied user of GTK (on *nix, presumably) learns Python. Neat, but I also want to keep using GTK. Which he can because it is relatively easy. Repeat H1 and H2 for every wrapping. You believe in H1. I suspect H2 is more often true, but admit I have no data. It is probably H2 (otherwise the reluctance to learn GTK so thoroughly would be too great) but with the important addition that the creator of PyGTK felt the general dissatisfaction with Tkinter. Getting users is a very very important motivation for a developer after all. That by itself says the stdlib is lacking. I have an alternate interpretation. There is a Python wrapping for as many C libraries as there are because Python is neat and wrapping is fairly easy and the rewards great. Yes, absolutely; but for the core functionality (which must contain a good GUI toolkit in my opinion) you should have more that just a binding. Instead, it should be well-embedded into the standard library and the language. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
Re: Python -- (just) a successful experiment?
Robert Kern [EMAIL PROTECTED] wrote: Which is exactly why I said at the beginning that people shouldn't bother with this thread and should instead just get to work. Robert, you are probably right, but I think how we get to work is important as well. What I posted was a little intellectually thin, but it would be nice to stir the collective energy toward some common (and useful) objectives. I think that something more than a superior language specification is required for a language to get a firm foothold in the IT world (and that is something I would personally like for Python.) It seems there are people very capable and willing to develop the good applications/tools/frameworks on top of Python, but too many of those projects do not gain critical mass; rather we have dozens of competing applications and frameworks that never blossom to their full potential. I'd love to see a little consensus on what goodies should be developed atop the language; what standards, principles, and API/hooks those goodies should provide; and then a collaborative effort to get there. Projects with a broader buy-in have a greater chance of achieving their potential. It does seem that perhaps some ground was gained with the WSGI effort. I understand Django [http://www.djangoproject.com/], a RoR alternative based on the WSGI spec, already has some buzz though the cat got out of the bag a bit early and Django is not officially launched just yet. It makes sense to ask one's fellow developers and Python users what a new open source development should look and act like if one wants to develop something great. Open source code denotes sharing, but we should add teamwork and community involvement in the code as connotations if we want our open source to reach its potential. What are the top 5 developments, aside from specification and implementation details of the language itself, which Python still needs for greater success in the day to day IT world? EriPy pyDerson P.S. In terms of a more concrete suggestion, I propose the Python community form an intervention team who are ready to fly in and intercede any time a developer, whose brilliance has been expended in their heroic coding effort, goes to name their new module, package, or application with a py other than to the right of the dot. -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP: Specialization Syntax
Kay Schluehr wrote: def makeClass(cls_name, **kw): return type(cls_name,(), kw) MyObject = makeClass(MyObject,a=8) MyObject As said to Bengt, a place is needed to write the class definition. There's no need for metaclass in that case: def makeType(a, b, c=someDefault): arguments = locals() class MyObject: pass # Complete definition here MyObject.__dict__.update(arguments) return MyObject Regards, Nicolas -- http://mail.python.org/mailman/listinfo/python-list
Re: Point and click GUI builder for Python
Use Eric3 with QtDesigner. Works like a charm. Adriaan Renting| Email: [EMAIL PROTECTED] ASTRON | Phone: +31 521 595 217 P.O. Box 2 | GSM: +31 6 24 25 17 28 NL-7990 AA Dwingeloo | FAX: +31 521 597 332 The Netherlands| Web: http://www.astron.nl/~renting/ Madhusudan Singh [EMAIL PROTECTED] 08/06/05 5:39 AM Is there such a thing for python ? Like Qt Designer for instance ? -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: visual studio 2005
wilf wrote: Has anyone had success compiling python with this? I personally didn't try yet. Did you? Regards, Martin -- http://mail.python.org/mailman/listinfo/python-list
Re: Python -- (just) a successful experiment?
Terry Reedy [EMAIL PROTECTED] writes: Hypothesis 1: someone learned Python and Tkinter, felt dissatisfied with Tkinter, went searching the universe for an alternative, found GTK, and wrote PyGTK, perhaps learning C in the process. Hypothesis 2: a C-programmer who is a satisfied user of GTK (on *nix, presumably) learns Python. Neat, but I also want to keep using GTK. Which he can because it is relatively easy. Repeat H1 and H2 for every wrapping. You believe in H1. I suspect H2 is more often true, but admit I have no data. I dunno about PyGTK but one of the more common complaints about wxPython is that it's not Pythonic enough. And wxPython is probably the most popular Python GUI toolkit after Tkinter. So people don't want C wrappers. I think what they mostly want is a wide choice of good looking widgets. They don't like Tkinter because its widget set is limited and what widgets it does have, look like crap. I have an alternate interpretation. There is a Python wrapping for as many C libraries as there are because Python is neat and wrapping is fairly easy and the rewards great. I think Python outgrew this glue orientation years ago and its main failings today are where it holds onto that orientation instead of trying to stand as a language in its own right. The Python docs should specify what Python code actually does, not simply that Python wraps the C library. When I learned Python several years ago, being able to interactively drive and easily script foreign libraries was touted as one of its killer applications. Numerical Python, wrapping BLAS, LINPACK, and FTPPACK was a prime example. So in a sense, you are criticizing Python for being successful at what I believe was one of its design goals. Having a good FFI is certainly an important feature but Python programs should first and foremost be Python programs. Compare the situation with Java or Common Lisp for example. Both of those languages have better FFI's than Python in every serious implementation (consider why SWIG is popular--because Python's C API is so clumsy), and yet the specs for those languages are far more thorough than the Python docs. -- http://mail.python.org/mailman/listinfo/python-list
issues with doctest and threads
I am getting a strange error with this script: $ cat doctest-threads.py import time, threading def example(): ... thread.out = [] ... while thread.running: ... time.sleep(.01) ... thread.out.append(.) thread = threading.Thread(None, example) thread.running = True; thread.start() time.sleep(.1) thread.running = False print thread.out ['.', '.', '.', '.', '.', '.', '.', '.', '.'] if __name__ == __main__: import doctest; doctest.testmod() $ python doctest-threads.py Exception in thread Thread-1: Traceback (most recent call last): File /usr/lib/python2.4/threading.py, line 442, in __bootstrap self.run() File /usr/lib/python2.4/threading.py, line 422, in run self.__target(*self.__args, **self.__kwargs) File doctest __main__[1], line 5, in example NameError: global name 'thread' is not defined I have found out a workaround, putting 'thread' in the main program (i.e. in the globals): $ cat doctest-threads2.py thread.running = True thread.start() time.sleep(.1) thread.running = False print thread.out ['.', '.', '.', '.', '.', '.', '.', '.', '.'] import time, threading def example(): thread.out = [] while thread.running: time.sleep(.01) thread.out.append(.) thread = threading.Thread(None, example) if __name__ == __main__: import doctest; doctest.testmod() However this is strange, since replacing in the first script globals()[thread] = threading.Thread(None, example) does NOT work, so it is not just putting stuff in the globals. Also, it seems that I cannot reproduce the same error in absense of threads. Any idea of what is happening? Thanks for sharing, Michele Simionato -- http://mail.python.org/mailman/listinfo/python-list
Re: How to use DrPython plugins
On Sat, 06 Aug 2005 13:38:24 +0200, Laszlo Zsolt Nagy [EMAIL PROTECTED] wrote: Hi All! Hello Laszlo, I have DrPython installed. I see there are cool plugins but I cannot user them. I'm glad, you like DrPython and the plugins. What Platform do you have? Python, WxPython Version, latest DrPython 3.10.3 Version? You see this, when you call Help = About DrPython = System Info. For example, I installed the CodeCompletion and CodeMark plugins. I have enabled the CodeCompletion plugin by default. I assigned the shortcut CTRL+SPACE to Plugin:CodeCompletion Toggle Code Completion. The code completition plugin is special, it is hardcoded to use the '.' char to launch the completion. However, when I'm editing a file nothing happens. No matter if I hit CTRL+SPACE or not. I have the same problem with CodeMark too. I could duplicate it. In codemark there there was a bug. updated Codemarks to 0.0.6. https://sourceforge.net/forum/forum.php?thread_id=1331861forum_id=382892 Download: http://sourceforge.net/project/showfiles.php?group_id=83074 I setup the shortcuts but nothing happens. What am I doing wrong? Could you try again? Cheers, -- Franz Steinhaeusler -- http://mail.python.org/mailman/listinfo/python-list
Re: How to use DrPython plugins
On 6 Aug 2005 08:03:59 -0700, RunLevelZero [EMAIL PROTECTED] wrote: Well I think you should post in this forum and you will get your answer more quickly. http://sourceforge.net/forum/?group_id=83074 Hi RunLevelZero, I have changed the Codemarks meanwhile. For testing, one could edit: plugins\default.idx and add manually the plugins: for example plugins\default.idx: CodeCompletion -- Franz Steinhaeusler -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP: Specialization Syntax
Nicolas Fleury schrieb: Kay Schluehr wrote: def makeClass(cls_name, **kw): return type(cls_name,(), kw) MyObject = makeClass(MyObject,a=8) MyObject As said to Bengt, a place is needed to write the class definition. There's no need for metaclass in that case: def makeType(a, b, c=someDefault): arguments = locals() class MyObject: pass # Complete definition here MyObject.__dict__.update(arguments) return MyObject Regards, Nicolas I have to admit that i don't actually understand what you want? The problems you try to solve seem trivial to me but it's probably my fault and i'm misreading something. You might be correct that your PEP may be interesting only if optional static typing will be introduced to Py3K and then we will suddenly have an immediate need for dealing with generic types so that the syntax can be reused for deferred functions ( the concept of specialization is usually coupled with some kind of partial evaluation which doesn't take place somewhere in your proposal ). But i'm not sure if this makes sense at all. Kay -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Kamaelia 0.2.0 released!
The project aims to make it simple to build networked multimedia systems (eg audio, video, interactive systems), Why limit the scope of application artificially? Axon/Kamaelia imho is perfectly applicable to any kind of application that does some kind of data processing. Think workflow applications, business applications, application integration... J. Paul Morrison has used the concept he named Flow-Based-Programming for financial applications since the 60's, any control systems engineer knows function-block-diagrams etc. and so on... Sincerely, Wolfgang Keller -- http://mail.python.org/mailman/listinfo/python-list
Re: Replacement for keyword 'global' good idea? (e.g. 'modulescope'or 'module' better?)
Bengt Richter wrote: Nor do we have any correspondence for bare names analogous to setattr(obj, name, value) = obj.name = value e.g., setname(namespace_selection, name, value) Probably this parallelism is a better approach to what I commented before.Thanks for clarity. There is nowhere near the kind of control the programmer has over attribute namespace use for bare-name use, even though by various means we are able to select from a limited set of namespaces. (BTW, if namespace_selection were a call to a suitable builtin function that could return objects whose attribute namespace were the desired name space, then setname could be effected with setattr, e.g., setattr(get_ns_obj(), name, value)# name = value (defaulting to local, same as get_ns_obj(0)) setattr(get_ns_obj(1), name, value) # name = value (in lexically immediately (1) enclosing scope) setattr(get_ns_obj(-1), name, value) # name = value (in global module scope) ) Yes namespaces should be unified in their base behaviour. I am thinking that there is a subliminal discussion under a layer of red herrings ;-) I refer to the subject of unification/generalizing/orthogonalizing by removing special legacy restrictions (or not introducing special restrictions in a new feature). E.g., recently decorators were introduced, and part of the discussion (which became explicit ;-) was whether to allow the expression following the '@' to be a fully general expression, or whether to restrict it to names, dotted names, and function calls. The latter won out. Some regard this kind of restriction as paternalistic, and protest that we are adults here (even though we are not all, and we others not all the time ;-) Uhmpf, adults==theorists and childrens==experimentals ? The BDFL has introduced many new ideas, yet has retained or introduced restrictions on fully orthogonal functionality that might otherwise be allowed if e.g. names in certain contexts were allowed to be full expressions. It goes the other way too. IIRC the list of bases for a class will be allowed to be an empty () soon. Bottom line, I think Python is eminently usable and very pleasant to use, but I think bare name mechanisms could be improved. A good dose of humility could be good for reingeneering something ,if necessary.Python is very usable,and has an almost perfect surface layer. But this is not enough.It needs to be strong and elegant in the insides to survive.More, isn't the Namespaces do more of them a Python Zen Law ? Thanks again for putting things in a saner and more open way then I did. Regards Paolino ___ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it -- http://mail.python.org/mailman/listinfo/python-list
Re: Oreilly CodeZoo
There it is, right on homepage. Thanks, it looks quite nice, and i see you'll be an indep. gems server, and more... I did try searching on postscript and it didn't pull up pyscript. Also, HTML on the Search results page is kind of not rendered great in Firefox1.06 /WinXP SP2. BUt it's a really great start overall. http://python.codezoo.com/news.csp -- http://mail.python.org/mailman/listinfo/python-list
Re: How to determine that if a folder is empty?
could ildg so you mean that this is not platform-independent? Your existing code is platform-independent but I think for faster code you will need to write platform-dependent code. FindFirstFile is only available on Windows. Neil -- http://mail.python.org/mailman/listinfo/python-list
Re: Decline and fall of scripting languages ?
Kay Schluehr ([EMAIL PROTECTED]) wrote: : No good news for scripting-language fans: : http://www.phpmag.net/itr/news/psecom,id,23284,nodeid,113.html What incredible horse dooey. The only thing that NEVER penetrates the enterprise space is good sense. Does anyone read history books? There is no such thing as a large corporation that is not doomed. There are a few names which are older than 1/2 a century but the companies and players are unrecognizable. We have barbeque joints in Texas older than IBM. And noone from 1970 would recognize IBM. The enterprise is good for one thing. Devouring each other. The enterprise's opinion about what is good for the future is like this broker I knew in Dallas. All you had to do was find out which stock he was recommending, then short it. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python -- (just) a successful experiment?
EP wrote: Robert Kern [EMAIL PROTECTED] wrote: Which is exactly why I said at the beginning that people shouldn't bother with this thread and should instead just get to work. Robert, you are probably right, but I think how we get to work is important as well. What I posted was a little intellectually thin, but it would be nice to stir the collective energy toward some common (and useful) objectives. What I'm trying to say is that posting to c.l.py is absolutely ineffective in achieving that goal. Code attracts people that like to code. Tedious, repetitive c.l.py threads attract people that like to write tedious, repetitive c.l.py threads. In the open source world, you can't tell people what to do. It's often a waste of time even to try to get them to *agree* on what they should do particularly when the group (Python programmers) is so large and the goals (create a powerful web framework as good as the language) are so amorphous. Ruby on Rails isn't the phenomenon that it is today because a bunch of Ruby programmers got together on c.l.ruby and all decided to work on one web app framework and bless it as the One True Way to write Ruby web apps. Instead, they wrote good code that solved their problems, code that would solve other people's problems, too. They released it in such a way that got people talking about their code and people talking about people talking about their code (and me talking about people talking about ... yeah). I'm not sure that this phenomenon is particularly repeatable. It was the result of a large number of uncontrollable factors and relied very heavily on network effects. Plone has, for a long time, made all-in-one distributions of itself+Zope+Python+et al. for Windows and Mac just like the one you tried for Ruby on Rails. When Zope was first released as open source, it got the same kind of people talking about people talking ... that Ruby on Rails is now getting; Zope was widely purported to be *the* Killer App for Python that would draw users of other languages in droves. Django is getting the right kind of attention, and is simple enough to get started with a small project, but it's in the unfortunate position of having come out *after* Ruby on Rails. You can do everything right and still not get what you want. There's a better question that you should have asked instead: What can I do to help make Python a more attractive language to program? And I would suggest that far and away, Python will get the largest payoff for your effort if you hammer hammer hammer on setuptools/PythonEggs/EasyInstall. Distribution affects *everyone* from the hobbiest, to the Java guy who just wants to try out one of the funky dynamic languages, to the enterprise programmer. And there are a large number of diverse, small projects that don't need a whole lot of coordination with anybody else; you can do them without needing to forge much consensus. You can make your own packages distributable via eggs. You can sumbit patches for your favorite 3rd party packages to work well as eggs. You can build and donate binary eggs for the platforms you care about. You can build a GUI interface for managing the installation of eggs via EasyInstall. You can work out a way for eggs to work well with dpkg/rpm/whatever package manager your system uses. You can add signatures for eggs. You can work out a way to easy associate documentation packages associated with the runtime eggs. The more you improve this technology, even incrementally, the more people will buy into it and thus improve it for you, too. Or we can keep posting here. Your choice. -- Robert Kern [EMAIL PROTECTED] In the fields of hell where the grass grows high Are the graves of dreams allowed to die. -- Richard Harter -- http://mail.python.org/mailman/listinfo/python-list
Re: error with examples (UDP broadcast)
Damir Hakimov wrote:
Hi All!
I'm writing a small programm which must send and service UDP broadcast
packets.
As start of it I looked at
/usr/share/doc/python2.4/Examples/Demo/sockets/broadcast.py
Well, this is the broken code (from examples):
---
MYPORT = 5
import sys, time
from socket import *
s = socket(AF_INET, SOCK_DGRAM)
s.bind(('', 0))
s.setsockopt(SOL_SOCKET, SO_BROADCAST, 1)
while 1:
data = repr(time.time()) + '\n'
s.sendto(data, ('broadcast', MYPORT))
time.sleep(2)
---
And this is a Traceback (most recent call last):
File broadcast.py, line 14, in ?
s.sendto(data, ('broadcast', MYPORT))
socket.error: (101, 'Network is unreachable')
If I replace 'broadcast' to '192.168.10.255' (this is my network's
broadcast addres) it's working fine.
Were is the truble?
Damir.
--
http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Kamaelia 0.2.0 released!
On Mon, 08 Aug 2005 10:49:32 +0100, Wolfgang Keller [EMAIL PROTECTED] wrote: The project aims to make it simple to build networked multimedia systems (eg audio, video, interactive systems), Why limit the scope of application artificially? Axon/Kamaelia imho is perfectly applicable to any kind of application that does some kind of data processing. You're absolutely right - Axon/Kamaelia hopefully will not just be limited to those areas. It just so happens that those kinds of systems are the underlying reasons why we started building Axon/Kamaelia. That's therefore where we're concentrating our resources at the moment. Think workflow applications, business applications, application integration... J. Paul Morrison has used the concept he named Flow-Based-Programming for financial applications since the 60's, any control systems engineer knows function-block-diagrams etc. and so on... We have ... alot! I really do hope that this system is used for more. I'd be very interested to know if anyone has had a go at building any components - for whatever purpose. The potential for component re-use might mean less work for us! :-) regards Matt Hammond -- | Matt Hammond | RD Engineer, BBC Research and Development, Tadworth, Surrey, UK. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python -- (just) a successful experiment?
Hallöchen! Robert Kern [EMAIL PROTECTED] writes: [...] What I'm trying to say is that posting to c.l.py is absolutely ineffective in achieving that goal. Code attracts people that like to code. Tedious, repetitive c.l.py threads attract people that like to write tedious, repetitive c.l.py threads. Although I mostly agree with you, I must also say that it can be a significant motivation for a developer to see that his project is urgently needed and that he can expect a quite big user base and early fellow developers. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
Re: Python -- (just) a successful experiment?
Torsten Bronger wrote: Hallöchen! Robert Kern [EMAIL PROTECTED] writes: [...] What I'm trying to say is that posting to c.l.py is absolutely ineffective in achieving that goal. Code attracts people that like to code. Tedious, repetitive c.l.py threads attract people that like to write tedious, repetitive c.l.py threads. Although I mostly agree with you, I must also say that it can be a significant motivation for a developer to see that his project is urgently needed and that he can expect a quite big user base and early fellow developers. Sure, that's a *far* more specific request that can be sensibly answered. Such a thread is also unlikely to be just a repeat of the same discussion made over and over again for years; after all, the hypothetical project is probably something new. -- Robert Kern [EMAIL PROTECTED] In the fields of hell where the grass grows high Are the graves of dreams allowed to die. -- Richard Harter -- http://mail.python.org/mailman/listinfo/python-list
Re: zipped socket
As far as I know, there is not a prefabbed solution for this problem. One issue that you must solve is the issue of buffering (when must some data you've written to the compressor really go out to the other side) and the issue of what to do when a read() or recv() reads gzipped bytes but these don't produce any additional unzipped bytes---this is a problem because normally a read() that returns '' indicates end-of-file. If you only work with whole files at a time, then one easy thing to do is use the 'zlib' encoding: abc.encode(zlib) x\x9cKLJ\x06\x00\x02M\x01' _.decode(zlib) 'abc' ... but because zlib isn't self-delimiting, this won't work if you want to write() multiple times, or if you want to read() less than the full file Jeff pgpTDmUWPuhcf.pgp Description: PGP signature -- http://mail.python.org/mailman/listinfo/python-list
Re: How to determine that if a folder is empty?
On standard Unix fileystems, one way to check for this is to check that the st_nlink of the directory is 2. However, even on Unix systems this isn't guaranteed for all filesystem types. Of course, finding whether a directory is empty is inherently racy: a file could be created between the time you decide it's empty and take whatever action is appropriate for the empty directory... I'll side with those who say to use 'not os.listdir()' as the test for emptyness, until you are certain it's not fast enough. os.listdir(/): 1 loops, best of 3: 39.3 usec per loop os.stat(/).st_nlink: 10 loops, best of 3: 7.27 usec per loop Jeff pgpjUuqMqcwQd.pgp Description: PGP signature -- http://mail.python.org/mailman/listinfo/python-list
Re: How to determine that if a folder is empty?
Reinhold Birkenfeld wrote: could ildg wrote: I want to check if a folder named foldername is empty. I use os.listdir(foldername)==[] to do this, but it will be very slow if the folder has a lot of sub-files. Is there any efficient ways to do this? try: os.rmdir(path) empty = True except OSError: empty = False should be efficient. But it removes the folder if it is empty. Perhaps it's not efficient to create the folder again. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python -- (just) a successful experiment?
Paul Rubin wrote: I dunno about PyGTK but one of the more common complaints about wxPython is that it's not Pythonic enough. And wxPython is probably the most popular Python GUI toolkit after Tkinter. So people don't want C wrappers. I think what they mostly want is a wide choice of good looking widgets. They don't like Tkinter because its widget set is limited and what widgets it does have, look like crap. I not only didn't like the look of Tkinter (but could have lived with it if that's all that was wrong with it), but I also simply couldn't figure out how to make it do the things I wanted to do. Fairly simple things, I thought, yet things that would have (apparently) required delving deeply into the innards or obscure documentation to figure out how to do it. In some cases, after extensive efforts to develop my own, I would stumble across an example of what I wanted. Often I was surprised to find that it was relatively simple solution, yet it was always unclear to me how I would have figured out something like that on my own. With wxPython, I don't like the non-Pythonic nature any more than I liked the non-Pythonic nature of Tkinter. I don't use the wider set of existing widgets very much, since often I need to roll my own anyway. I can always, however, figure out how to get what I want done, and it usually doesn't take me very long to do it. wxPython fits my brain. Tkinter didn't. YMMV. C wrappers? Existing widget sets? Pythonic nature? None of these were really interesting or important to me.** Getting stuff done, that was important. I was and am able to do that with wxPython while with Tkinter I was not. (And no, folks, this isn't a flame against Tkinter at all. I fully appreciate that the problem was me, since many others are capable of getting the results they need from the framework. But they weren't sitting next to me when I needed them. ;-) ) FWIW, -Peter ** Pythonic nature is actually of interest, but it's definitely not an overriding concern when you have work to do. -- http://mail.python.org/mailman/listinfo/python-list
Re: issues with doctest and threads
I don't see the problem with your doctest usage, but what makes you believe that the code you show below produces exactly 9 dots? strangely enough, re-working the code to this import time, threading def example(): ... thread.out = [] ... for i in range(9): thread.out.append(.) thread = threading.Thread(None, example) thread.running = True; thread.start() time.sleep(.1) thread.running = False print thread.out ['.', '.', '.', '.', '.', '.', '.', '.', '.'] makes the test succeed (though it can fail for some of the same reasons the original test isn't guaranteed to give 9 dots either). Jeff pgpzCyHhOP4G4.pgp Description: PGP signature -- http://mail.python.org/mailman/listinfo/python-list
Re: zipped socket
John wrote: Is there anyway open a socket so that every send/listen/recv goes thru a zipping/unzipping process automatically? You ought to be able to do this easily by wrapping a bz2 compressor around the socket (maybe using socket.makefile() to return a file object first) and probably using a generator as well: http://effbot.org/librarybook/bz2.htm includes relevant examples (not specifically with sockets though). Googling for python incremental compression ought to turn up any other alternatives. -Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: How to determine that if a folder is empty?
could ildg wrote: I want to check if a folder named foldername is empty. I use os.listdir(foldername)==[] to do this, but it will be very slow if the folder has a lot of sub-files. Is there any efficient ways to do this? I'm just curious to know under what circumstances where it's important to know whether a directory is empty it's also important that the operation occur with lightning speed... Reinhold's suggestion to delete the folder was interesting in this respect... isn't that (prior to deleting a folder) just about the only time one cares if it's empty, normally? And in this case you don't need to do the check, as Reinhard shows, so performance isn't an issue. -Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: Decline and fall of scripting languages ?
phil wrote: Kay Schluehr ([EMAIL PROTECTED]) wrote: : No good news for scripting-language fans: : http://www.phpmag.net/itr/news/psecom,id,23284,nodeid,113.html What incredible horse dooey. The only thing that NEVER penetrates the enterprise space is good sense. Does anyone read history books? There is no such thing as a large corporation that is not doomed. There are a few names which are older than 1/2 a century but the companies and players are unrecognizable. We have barbeque joints in Texas older than IBM. And noone from 1970 would recognize IBM. The enterprise is good for one thing. Devouring each other. The enterprise's opinion about what is good for the future is like this broker I knew in Dallas. All you had to do was find out which stock he was recommending, then short it. snip Err, that's not what is meant by enterprise, it's a catch all term for large distributed systems, take a look at the link below for an idea of this: http://java.sun.com/j2ee/faq.html Obviously there are other variations on this than the Sun stuff but enterprise dosn't mean 'very large companies' in this case. Cheers, Neil -- Neil Benn Senior Automation Engineer Cenix BioScience BioInnovations Zentrum Tatzberg 47 D-01307 Dresden Germany Tel : +49 (0)351 4173 154 e-mail : [EMAIL PROTECTED] Cenix Website : http://www.cenix-bioscience.com -- http://mail.python.org/mailman/listinfo/python-list
Re: IronPython 0.9 Released
could ildg wrote: Why is iron python runs so fast but jython runs so slow while C# and java seem very much the same? I've been playing with Ironpython since its first release and, in my experience, it is not faster than Cpython, although this is what they claim. Anyway, it is in alpha stage so lets wait until it's mature... -- http://mail.python.org/mailman/listinfo/python-list
Re: listing users in Plone
plz let me know the proper google group -- http://mail.python.org/mailman/listinfo/python-list
PyQt: Problem finding and showing a record in a QDataBrowser
[I've also posted this to pyqt-pykde list, but I haven't got any answers so
far. I also thought that someone here might have solved it or have a
different idea to help me :-) Sorry for those that read it twice. ]
Hi.
I have created an interface where I have a QDataBrowser and all of its
editing and navigating controls and one of the displayed controls is in a
QSpinBox.
I have the navigation from current to next and previous records working fine
if I only use the data browser controls. I also can recover the correct
record if I type in a valid code at the spin box.
For the spin box to work, I'm doing this:
def codAmostra_valueChanged(self, amostra_id):
cursor = self.dbAmostras.sqlCursor()
cursor.select('amostra_id=%s' % amostra_id)
self.dbAmostras.first()
self.dbAmostras.refresh()
(codAmostra is my spinbox, dbAmostras is my QDataBrowser -- just as a
curiosity, amostra is the pt_BR for sample)
I was willing to use self.dbAmostras.seek(), but it requires that I know
the exact position of the record -- using it I wouldn't need to filter my
data and I think the problem would be solved... -- but I don't know it.
There can be holes in my sequence (otherwise I'd use only the spinbox) and
I'll be having a few million entries (what makes it impossible to go
through each and every record every time I change the value at the spinbox
manually).
I was reading Qt3 docs trying to find out some other mean to recover the
record I need without messing with the filter because if I use the filter,
then I can't paginate through all records anymore.
Any hints on an alternative approach that would allow me to use both
controls?
* Python 2.4
* SIP 4.1.1 (4.1.1-255)
* qt.qVersion()
'3.3.4'
Thanks in advance,
--
Jorge Godoy [EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python -- (just) a successful experiment?
Paul Rubin schrieb: Having a good FFI is certainly an important feature but Python programs should first and foremost be Python programs. Python was originally created as an extension language for C. In some sense it is an abstraction layer for C libs. Compare the situation with Java or Common Lisp for example. Both of those languages have better FFI's than Python in every serious implementation (consider why SWIG is popular--because Python's C API is so clumsy), and yet the specs for those languages are far more thorough than the Python docs. Did you ever check out ctypes? I appreciate it very much. http://starship.python.net/crew/theller/ctypes/ Kay -- http://mail.python.org/mailman/listinfo/python-list
Re: Python -- (just) a successful experiment?
On Sun, 2005-08-07 at 06:55 -0700, Paul Boddie wrote: Eric Pederson wrote: Why is Ruby, and Ruby on Rails, getting such strong play? Relentless hype from blogging celebrities? This is certainly part of it, but I feel it ignores the much deeper reasons which are the root of this hype. I recently went to FOSCON (a free seminar coinciding with OSCON put on by the local Ruby UG here in Portland) and listened to a few presentations on Ruby and Rails by David Hansson (the creator of Rails) and others. By the end it was clear that Ruby is wonderfully suited to writing domain-specific languages (DSL) and that Rails is an excellent example of a DSL geared toward writing database-driven web applications. A friend of mine is writing a book on Rails for a large publisher and admitted to me that he barely knows Ruby (and has used Rails for only around six months). The second presentation (I don't recall the speaker's name) specifically covered metaprogramming (writing DSLs) and one of the things I found interesting was that despite Ruby having far more syntax than Python in general, the resulting Ruby-based DSLs presented had far *less* syntax than had they been written in Python. This is undoubtedly the reason why Rails is apparently completely usable even if one knows very little Ruby. Regards, Cliff -- [EMAIL PROTECTED] http://www.develix.com :: Web applications and hosting :: Linux, PostgreSQL and Python specialists :: -- http://mail.python.org/mailman/listinfo/python-list
Re: Embedding a runtime graph in Qt3 designer generated UI
I find Eric3 very easy to work with when using Qt+Python. It will generate a Python wrapper for your Qt (Designer designed) form, that you can the sub-class and use as if it was a Python object. I'm hoping it will be available (together with PyQt, etc.) for Qt4 soon, but as I'm not paying a dime for it, I can only hope... Adriaan Renting| Email: [EMAIL PROTECTED] ASTRON | Phone: +31 521 595 217 P.O. Box 2 | GSM: +31 6 24 25 17 28 NL-7990 AA Dwingeloo | FAX: +31 521 597 332 The Netherlands| Web: http://www.astron.nl/~renting/ Phil Thompson [EMAIL PROTECTED] 08/08/05 9:21 AM Hi Two questions : 1. Is it possible to use an import command in a qt3 designer code ? (I know that it is possible to write python inside the braces -- but is it possible to use an import command for some rather large libraries I wrote that I need to access ?). You can include import statements in Designer's comment dialog by prefixing them with Python: . This is covered in the PyQt documentation. 2. In the same vein, how does one embed a runtime plot in a qt3 UI ? It will need to be a python solution since I am using python libraries to acquire the data. Have a look at PyQwt which is a set of Python bindings for the Qt-based Qwt plotting library. Phil -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Python -- (just) a successful experiment?
On 8/8/05, Robert Kern [EMAIL PROTECTED] wrote: What I'm trying to say is that posting to c.l.py is absolutely ineffective in achieving that goal. Code attracts people that like to code. Tedious, repetitive c.l.py threads attract people that like to write tedious, repetitive c.l.py threads. +1 QOTW -- # p.d. -- http://mail.python.org/mailman/listinfo/python-list
epyDoc Questions
Hello, I can;t find a epyDoc specific mailing list, so I'll try here - if you know of a epyDoc mailing list then please let me know (google is not my friend, I can only find an announce, devel and commit list from 'epydoc mailing list'). I'm working on marking up a class in epyDoc and have a few things that I strongly suspect I can do but can't find instructions for in the docs - I was hoping that someone has cracked this already: 1. I want to document the attributes (instance and also class) of a class and or module, I know the tags are there - where does they go (before/after theclass decleration, top of the module, if someone puts in the class doc but misses out the module stuff, how will epydoc know that this is meant to be class and not module (although someone doing this will probably get shouted at in a code review!)? 2. In the argument to the tag for raises, how can I put a link through to the exception? 3. How would I go about marking up the property docs so that it knows what the setter and getter methods are - it links through to the methods but the docs arn't in there, they are in the fifth argument to the property method (I can manually do this using sections but is there a tag I can use?) Cheers for your help, Neil -- Neil Benn Senior Automation Engineer Cenix BioScience BioInnovations Zentrum Tatzberg 47 D-01307 Dresden Germany Tel : +49 (0)351 4173 154 e-mail : [EMAIL PROTECTED] Cenix Website : http://www.cenix-bioscience.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Decline and fall of scripting languages ?
Paul Rubin wrote: Ruby just doesn't interest me that much though (maybe I'm missing something). I don't think you are. My impression is that if you've never used Python or Ruby, you'll generally end up liking whichever of the two you really discover first (since the common case is that you're coming from Java/C++/PHP/etc - the more mainstream languages). IIRC, the creator of Ruby got really hung up on the fact that Python was not a pure OO language, so he decided to make a new language that was (this was in the pre-metaclass, old-style class days of Python). I was hoping for a concise explanation of what Rails does I'd say it's similar to Zope in that (1) For both, the introductory tutorials make it seem deceptively easy to use, but they hide a sometimes steep learning curve (2) For both, it's hard to find clear, concise documentation midway between introductory tutorials and reading the source code (3) For both, being frameworks, you have to commit yourself to them almost entirely and be prepared for some serious lock-in (4) Oh yeah, they're both web application frameworks :) (ROR has libraries to aid in building database-centric web applications: it includes an database ORM, a web templating language, libraries for user sessions, etc.) and whether it's feasible to do something like it in (say) Python. I did look at the rubyonrails.com site but there were too many marketing buzzwords and downloadable videos for me to deal with. Yes, it's incredibly feasible. I think the Subway project is sort of heading down a similar path but using Python instead. I've tried a couple of times to use Ruby on Rails and, I have to admit, I had a tough time cutting through the hype (also, it seemed like the preferred method of learning about features was through downloading large videos). The ActiveRecord library (for handling mapping objects to the database) seems sort of powerful, but the tutorials and demo videos make a huge deal about how ROR can generate a web form by inspecting the database table metadata. (Useful? Probably. Mind-blowingly cool? Hardly.) Beyond ActiveRecord, there is some additional stuff to help you build Model-View-Controller web UIs, and then lots of the standard web app components (user sessions, security, logging, etc.). I think ROR's big selling point isn't technology-related at all: it's hype machine has helped build an active community, and it's a single framework as opposed to Python's bazillions. :) -Dave -- http://mail.python.org/mailman/listinfo/python-list
Extending and altering httplib to handle bad servers
In the course of my current project, I've had to deal with connecting to an HTTP server that isn't fully compliant with the HTTP requirements for chunked encodings. Rather than sending the end-of-data sentinel (0-length chunk), it just closes the connection (without even sending the CRLF at the end of the data). Because of this, using httplib would always throw nasty errors and not give me any useful data. Therefore, I've had to modify the httplib.py code to do something reasonable when the server just closes the connection. So, my questions are (my changes follow, against Python 2.3): - Did I patch the right place to do Something Reasonable in this case of server non-compliance? - Is there a better way to handle this case that may be more robust? Or handle more similar cases? - Is there anything special I should do (besides obviously diff-ing against CVS) before submitting a patch for this to SourceForge? (it seems to me that being tolerant of bad servers is something that would be of general interest.) Thanks, Michael ---8--- BEGIN CONTEXT DIFF *** /usr/lib/python2.3/httplib.py 2005-05-04 02:08:57.0 -0500 --- httplib.py 2005-08-05 10:33:08.0 -0500 *** *** 1,5 --- 1,7 HTTP/1.1 client library + Copyright (c) 2001 Python Software Foundation; All Rights Reserved + intro stuff goes here other stuff, too *** *** 64,69 --- 66,75 Unread-response_CS_IDLE response_class Req-started-unread-response_CS_REQ_STARTEDresponse_class Req-sent-unread-response _CS_REQ_SENT response_class + + Modified 2005-07-20 by Michael Ekstrand [EMAIL PROTECTED] to deal + gracefully wtih non-compliant systems which just terminate the connection + rather than sending the end-of-data chunk in chunked HTTP responses. import errno *** *** 442,448 amt -= chunk_left # we read the whole chunk, get another ! self._safe_read(2) # toss the CRLF at the end of the chunk chunk_left = None # read and discard trailer up to the CRLF terminator --- 448,460 amt -= chunk_left # we read the whole chunk, get another ! try: ! self._safe_read(2) # toss the CRLF at the end of the chunk ! except IncompleteRead: ! # The server just closed on us, without providing appropriate ! # end-of-data things. ! self.close() ! return value chunk_left = None # read and discard trailer up to the CRLF terminator ---8- END CONTEXT DIFF - -- http://mail.python.org/mailman/listinfo/python-list
Re: gettext again
stasz a écrit : Your steps seems alright. Just a thought; you do start test1.py from a [EMAIL PROTECTED] environment do you? I mean in a xterm do: export [EMAIL PROTECTED] And then start test1.py from there. Stas Wht ! Working at last, after three days... It wasn't the LANG param which is [EMAIL PROTECTED] allright. I inadvertantly suppressed the '.mo' part of gettext.install(test1.mo') and it just worked. I guess gettext was looking for a 'test1.mo.mo' file or something. Anyways, you made my day my friend ! Many many thanks ! -- http://mail.python.org/mailman/listinfo/python-list
Is there a better/simpler logging module?
I just tried to use the python standard logging module in a small program and I found myself lost among all those features, all those configuration options and so on. Is there any better/simpler logging module around? What do you use for logging in your programs? Thanks in advance. --- Alessandro Bottoni -- http://mail.python.org/mailman/listinfo/python-list
Re: gettext again
BTW stasz, Maybe you'll have still some time for the following question. Trying my luck :)) Suppose I have several units (.py files), say test.py test1.py tets2.py , test.py being my main file. I've read I can import gettext and install in the main unit. Then, must I create .po files for each unit or is there a way to make a single .po file for the whole app. ? -- http://mail.python.org/mailman/listinfo/python-list
BayPIGgies: August 11, 7:30pm (Ironport)
The next meeting of BayPIGgies will be Thurs, August 11 at 7:30pm at Ironport. Hasan Diwan will present RRsR, a web-based RSS reader written using feedparser and python CGI. This is expected to be a short presentation; afterward, anyone who was at OSCON is invited to summarize what they saw/heard. BayPIGgies meetings alternate between IronPort (San Bruno, California) and Google (Mountain View, California). For more information and directions, see http://www.baypiggies.net/ Before the meeting, we plan to meet at 6pm for dinner. Discussion of dinner plans is handled on the BayPIGgies mailing list. This week will probably be at Creperie du Monde, six long blocks from IronPort (i.e., walking distance). Advance notice: The September 8 meeting agenda has not been set. Please send e-mail to [EMAIL PROTECTED] if you want to suggest an agenda (or volunteer to give a presentation). We already have a speaker for October. -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ The way to build large Python applications is to componentize and loosely-couple the hell out of everything. -- http://mail.python.org/mailman/listinfo/python-list
Python framework
hi ! what's the best python framework to create web applications? -- http://mail.python.org/mailman/listinfo/python-list
Re: Is there a better/simpler logging module?
If you need some simple logging why not create a logger like one of the basic examples, see http://docs.python.org/lib/minimal-example.html, these examples are not that complex. -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP: Specialization Syntax
On 8 Aug 2005 02:26:40 -0700, Kay Schluehr [EMAIL PROTECTED] wrote: I have to admit that i don't actually understand what you want? Me neither. I don't see the point of this. -- Email: zen19725 at zen dot co dot uk -- http://mail.python.org/mailman/listinfo/python-list
Re: GUI programming, embedding, real time plots, etc.
In article [EMAIL PROTECTED], Madhusudan Singh [EMAIL PROTECTED] wrote: 1. In using matplotlib (my code essentially involved creating a plot and show()'ing it inside a loop), the color of the plot changed. Is there a way to tell matplotlib to not treat each new invocation as a new plot, but to really overwrite the old one ? You were able to get matplotlib to open a new plot each time (assuming you closed the old one, too)? Can you show a simple example of this? Thanks. -- Lou Pecora (my views are my own) REMOVE THIS to email me. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python -- (just) a successful experiment?
On Mon, 8 Aug 2005 00:51:04 -0800, EP [EMAIL PROTECTED] wrote: Robert Kern [EMAIL PROTECTED] wrote: Which is exactly why I said at the beginning that people shouldn't = bother with this thread and should instead just get to work. = Robert, you are probably right, but I think how we get to work is important= as well. What I posted was a little intellectually thin, but it would be nice to sti= r the collective energy toward some common (and useful) objectives. I thin= k that something more than a superior language specification is required fo= r a language to get a firm foothold in the IT world (and that is something = I would personally like for Python.) It seems there are people very capable and willing to develop the good appl= ications/tools/frameworks on top of Python, but too many of those projects = do not gain critical mass; rather we have dozens of competing applications = and frameworks that never blossom to their full potential. I'd love to see= a little consensus on what goodies should be developed atop the language= ; what standards, principles, and API/hooks those goodies should provide; a= nd then a collaborative effort to get there. Projects with a broader buy-i= n have a greater chance of achieving their potential. It occurs to me that we have the PEP process for core python, but no PEP process for the python app/lib environment. What about starting a PEEP process (Python Environment Enhancement Proposals) modeled on PEPs, where those motivated to formalize their pet projects or feature requests could collaborate to create a spec to document and guide development? It does seem that perhaps some ground was gained with the WSGI effort. I u= nderstand Django [http://www.djangoproject.com/], a RoR alternative based o= n the WSGI spec, already has some buzz though the cat got out of the bag a= bit early and Django is not officially launched just yet. It makes sense to ask one's fellow developers and Python users what a new o= pen source development should look and act like if one wants to develop som= ething great. Open source code denotes sharing, but we should add teamwork= and community involvement in the code as connotations if we want our open = source to reach its potential. PEEP as a vehicle? What are the top 5 developments, aside from specification and implementatio= n details of the language itself, which Python still needs for greater succ= ess in the day to day IT world? EriPy pyDerson P.S. In terms of a more concrete suggestion, I propose the Python communit= y form an intervention team who are ready to fly in and intercede any time = a developer, whose brilliance has been expended in their heroic coding effo= rt, goes to name their new module, package, or application with a py othe= r than to the right of the dot. Probably better to have the PSF hire a patent/trademark lawyer to reserve rights to py... names and the py-prefixing business process ;-/ Regards, Bengt Richter -- http://mail.python.org/mailman/listinfo/python-list
Re: How to determine that if a folder is empty?
Mike Meyer wrote: Just out of curiosity, is there an OS out there where you can have the permissions needed to delete a directory without having the permissions needed to create it appropriately? Not an OS, but AFS has a wider set of permissions (RLIDWKA - which, if I remember correctly, are read, look, index, delete, write, lock, administrate). -- http://mail.python.org/mailman/listinfo/python-list
Re: Python -- (just) a successful experiment?
Kay Schluehr [EMAIL PROTECTED] writes: Having a good FFI is certainly an important feature but Python programs should first and foremost be Python programs. Python was originally created as an extension language for C. In some sense it is an abstraction layer for C libs. I'd have to respond: that was then, this is now. As Python has gotten more powerful, that C extension feature has gotten less central. That is to say, the language is growing up, and unwillingness to recognize that is in some places stunting Python's growth. Did you ever check out ctypes? I appreciate it very much. http://starship.python.net/crew/theller/ctypes/ I think I did see something about it before. I should check it out further. But mainly I want my Python programs to be Python programs, not wrappers for C programs. And frankly I'm more comfortable with something like SWIG, which turns the C functions into actual Python modules rather than exposing naked C functions to Python code (destroying Python's type safety). -- http://mail.python.org/mailman/listinfo/python-list
Re: Python -- (just) a successful experiment?
Cliff Wells [EMAIL PROTECTED] writes: The second presentation (I don't recall the speaker's name) specifically covered metaprogramming (writing DSLs) and one of the things I found interesting was that despite Ruby having far more syntax than Python in general, the resulting Ruby-based DSLs presented had far *less* syntax than had they been written in Python. This is undoubtedly the reason why Rails is apparently completely usable even if one knows very little Ruby. Interesting. But if we can generalize from that, then Lisp should be ruling the web. -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP: Specialization Syntax
Kay Schluehr wrote: I have to admit that i don't actually understand what you want? The problems you try to solve seem trivial to me but it's probably my fault and i'm misreading something. You might be correct that your PEP may be interesting only if optional static typing will be introduced to Py3K and then we will suddenly have an immediate need for dealing with generic types so that the syntax can be reused for deferred functions ( the concept of specialization is usually coupled with some kind of partial evaluation which doesn't take place somewhere in your proposal ). But i'm not sure if this makes sense at all. Well, the partial evaluation is done when using []. def getMember[memberName](obj): return getattr(obj, memberName) x = getMember[xyz] # specialization y = x(obj) # use I realize the term specialization can be confusing, since people might think of what is called in C++ explicit specialization and partial specialization, while these concepts are not present in the PEP. The point is that I'm already using static-like typing in frameworks interacting with other languages with generic types. So I would already benefit from such a capability, and yes, there's workarounds. I'm clearly in a minority with such a need, but the first point fo the PEP is to extend [] syntax, so that it is possible to prototype generic types using [] operators. Regards, Nicolas -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP: Specialization Syntax
On Sun, 07 Aug 2005 21:41:33 -0400, Nicolas Fleury [EMAIL PROTECTED] wrote:
Bengt Richter wrote:
[...]
But here the problem is not in the __getitem__ method:
c.__getitem__(kw='key word arg')
(__main__.C object at 0x02EF498C, (), {'kw': 'key word arg'})
It's just that square bracket expression trailer syntax does not
allow the same arg list syntax as parenthesis calling trailer syntax.
I totally agree and that's what I mean. The formulation of the PEP is
wrong, I should almost not talk about __getitem__ since as you said it
can have any signature. The PEP is about extending [] syntax to call
automtically __getitem__ function with more complex signatures.
Should other operators that square brackets be used for
specialization?
Didn't quite parse that ;-) You mean list comprehensions? Or ??
I mean should angle brackets like in C++, or another operator, be
used instead?
I am getting the feeling that your PEP is about a means to do something C++-like
in python, not necessarily to enhance python ;-) IOW, it seems like you
want the [new syntax] to do something like C++ type_spec in templates?
(BTW, I have nothing against giving python new capabilities (quite the reverse),
but not by grafting limbs from other animals ;-)
Maybe you want hidden name-mangling of function defs according to arg types
and corresponding dispatching of calls? I am afraid I am still not clear
on the fundamental motivation for all this ;-)
Regards and thx for your feedback,
You're welcome.
Regards,
Bengt Richter
--
http://mail.python.org/mailman/listinfo/python-list
Re: gettext again
On Mon, 08 Aug 2005 17:01:21 +0200, cantabile wrote: stasz a écrit : Wht ! Working at last, after three days... It wasn't the LANG param [...] Anyways, you made my day my friend ! Many many thanks ! Your welcome :-) Stas -- http://mail.python.org/mailman/listinfo/python-list
Re: Is there a better/simpler logging module?
Alessandro Bottoni wrote: I just tried to use the python standard logging module in a small program and I found myself lost among all those features, all those configuration options and so on. If you don't want to mess with all this stuff it's easy enough to do: import logging logging.warning(my warning) logging.debug(debug message) The configuration options are strictly optional. Personally I use a package I wrote called autolog, which sets up configuration from a dot-file in the home directory if it exists, and a basic logger for each module automagically. And it does this all using the stdlib logging module. :) -- Michael Hoffman -- http://mail.python.org/mailman/listinfo/python-list
Re: Python -- (just) a successful experiment?
That's it: got to get the PEEPs involved. Acronym of the year (AOTY). -- http://mail.python.org/mailman/listinfo/python-list
Re: Splitting a string into groups of three characters
Yes i know i made a mistake, ['Hell','o W','orl','d'] but you know what I mean lol, I'll probly use John Machin's def nsplit(s, n): return [s[k:k+n] for k in xrange(0, len(s), n)] It seems fast, and does not require any imports. But anyways, thank you for all your help, you rpck! :) -- http://mail.python.org/mailman/listinfo/python-list
Re: Splitting a string into groups of three characters
Yes i know i made a mistake, ['Hell','o W','orl','d'] but you know what I mean lol, I'll probly use John Machin's def nsplit(s, n): return [s[k:k+n] for k in xrange(0, len(s), n)] It seems fast, and does not require any imports. But anyways, thank you for all your help, you rock! :) -- http://mail.python.org/mailman/listinfo/python-list
Re: gettext again
On Mon, 08 Aug 2005 17:39:34 +0200, cantabile wrote: BTW stasz, Maybe you'll have still some time for the following question. Trying my luck :)) Suppose I have several units (.py files), say test.py test1.py tets2.py , test.py being my main file. I've read I can import gettext and install in the main unit. Then, must I create .po files for each unit or is there a way to make a single .po file for the whole app. ? Yes there is. As a reminder, make sure that you install gettext in the namespace of your toplevel module. What I mean is this: test1.py imports test2.py and test3.py test2.py imports test4.py Now you have to place the gettext.install call in test1.py and then the other modules can access it. If you place the gettext call in, for example, test2.py then only test2.py and test4.py have access to it. So when it don't work as you expect make sure to check if every module has access to the _ from gettext. So now for your question about one po/mo file for multiple modules. I use this file for a project of mine it also includes some explanation in case I forget it myself :-) shameless plug The project is called Guido van Robot. http://gvr.sf.net /shameless plug The files mentioned inside this file are used in the above project and serve as an example in this case. You could replace the files with your own to try it. The file itself is called FilesForTrans so you could put this file together with your test modules inside a directory and follow the instructions in side FilesForTrans. Stas Z Contents of FilesForTrans cut here - ## These files contain i18n strings ## Use: xgettext -f ./FilesForTrans -p /tmp ## The message.po will be located in /tmp ## Now do: msgmerge ./po/nl/gvr.po /tmp/messages.po /tmp/new_nl.po ## compile the .po to mo (place the .po after editing in ./po/nl/) ## msgfmt ./po/nl/gvr.po -o ./locale/nl/LC_MESSAGES/gvr.mo gvr.py gvrparser.py world.py worldMap.py Editorwindows.py -- http://mail.python.org/mailman/listinfo/python-list
Re: OT: World's largest Python caught!:)
http://www.afghania.com/News-article-sid-4792-mode-thread.html 3rd hit in google with world's largest python. The first two hits were your email below to the newsgroups. James On Sunday 07 August 2005 09:15 pm, Ashok Rajasingh wrote: Hi Can I please get some information on this python? I saw a brief news clip last year am very keen to know more. Thanks Ashok Rajasingh 21 Cumberland street New Plymouth New Zealand +646 7575698 (home) 7599592 (work) ## Attention: The information contained in this message and or attachments is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any system and destroy any copies. Please note that the views or opinions expressed in this message may be those of the individual and not necessarily those of Tegel Foods Ltd. This email was scanned and cleared by NetIQ MailMarshal. ## -- James Stroud UCLA-DOE Institute for Genomics and Proteomics Box 951570 Los Angeles, CA 90095 http://www.jamesstroud.com/ -- http://mail.python.org/mailman/listinfo/python-list
sample script to write results of html scrape to mysql db?
does anyone have a sample script that writes results of html scraping to a mysql db? -- http://mail.python.org/mailman/listinfo/python-list
Re: Decline and fall of scripting languages ?
In article [EMAIL PROTECTED], Paul Rubin http://[EMAIL PROTECTED] wrote: Donn Cave [EMAIL PROTECTED] writes: My vote would be Haskell first, then other functional languages. Learning FP with Objective CAML is like learning to swim in a wading pool -- you won't drown, but there's a good chance you won't really learn to swim either. Has an interesting, very rigorous OOP model though. I'm not sure what you mean by that about OCAML. That its functional model is not pure enough? I'd like to look at Haskell as well, but I have the impression that its implementation is not as serious as OCaml's, i.e. no native-code compiler. On the contrary, there are a couple. Ghc is probably the leading implementation these days, and by any reasonable measure, it is serious. Objective CAML is indeed not a pure functional language. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Decline and fall of scripting languages ?
Donn Cave [EMAIL PROTECTED] writes: I'm not sure what you mean by that about OCAML. That its functional model is not pure enough? I'd like to look at Haskell as well, but I have the impression that its implementation is not as serious as OCaml's, i.e. no native-code compiler. On the contrary, there are a couple. Ghc is probably the leading implementation these days, and by any reasonable measure, it is serious. OK, I've looked at the Haskell gentle introduction page a little bit and it's nice. I do remember Ocaml beating Haskell on a performance shootout and am not sure whether Ghc was used for the Haskell entry. I notice that Haskell strings are character lists, i.e. at least conceptually, hello takes the equivalent of five cons cells. Do real implementations (i.e. GHC) actually work like that? If so, that's enough to kill the whole thing right there. Objective CAML is indeed not a pure functional language. Should that bother me? I should say, my interest in Ocaml or Haskell is not just to try out something new, but also as a step up from both Python and C/C++ for writing practical code. That is, I'm looking for something with good abstraction (unlike Java) and type safety (unlike C/C++), but for the goal of writing high performance code (like C/C++). I'm even (gasp) thinking of checking out Ada. -- http://mail.python.org/mailman/listinfo/python-list
Re: Fat and happy Pythonistas (was Re: Replacement forkeyword'global' good idea? ...)
On Sun, 7 Aug 2005 23:52:40 -0400, Terry Reedy [EMAIL PROTECTED] wrote:
Bengt Richter [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
I think the relationship of abstract entities and their concrete
representations
is very interesting.
ditto
BTW, maybe this is a place to mention the concept of an AST decorator,
that works like
a function decorator except that it is prefixed with @@ instead of @ and
it operates
at compile time when the AST becomes available, but before it gets
translated to code,
and what gets passed to the decorator is the AST
One can do this much today:
import compiler
new_ast = ast_transformer(compiler.parse('''\
code here
''')
However, I can't see any way in the docs to get a code object from the AST.
I believe the AST-to-code compilet is currently being worked on. When it
is, @@ would be nice syntactic sugar but not really necessary.
The idea is that this form of decoration could transform the
AST arbitrarily before code generation, and be a very flexible tool
for mischief of course, but also useful tricky things.
At the moment, we are limited to manipulating concrete text before
compiling it.
Have we gone backwards from this?
http://groups.google.com/group/comp.lang.python/browse_thread/thread/5fa80186d9f067f4/7a2351b221063a8c
I've been meaning to do something with that, to implement @@ decoration, I
think probably in the context
of a customized importer, where I would be able to control the whole source
conversion process, anticipating
usage something like (ut is my hodgepodge utility package ;-)
from ut.astdecoimport import astdecoimport
amodule = astdecoimport('amodule') # searches like import for amodule.py
and does its thing
Regards,
Bengt Richter
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python -- (just) a successful experiment?
On Mon, 08 Aug 2005 16:58:40 GMT, Bengt Richter [EMAIL PROTECTED] wrote: It occurs to me that we have the PEP process for core python, but no PEP process for the python app/lib environment. What about starting a PEEP process (Python Environment Enhancement Proposals) modeled on PEPs, where those motivated to formalize their pet projects or feature requests could collaborate to create a spec to document and guide development? The PEP process could be used for some of this. There are existing informational PEPs that aren't connected to the core language, but just specify some interface for the community's use: IR 216 Docstring Format IF 248 Python Database API Specification v1.0 IF 249 Python Database API Specification v2.0 I 333 Python Web Server Gateway Interface v1.0 Other PEPs describe how to modernize code (PEP 290) and hack the code (290, 339). This is similar to RFCs: there are normative RFCs that actually specify something, and informative RFCs that publish information about an experimental protocol or system. PEPs would be especially good for things like WSGI that are intended to be supported by many different projects; it's less useful to document how a pet project works. --amk -- http://mail.python.org/mailman/listinfo/python-list
Re: Making a timebomb
Peter Hansen wrote: Cantankerous Old Git wrote: Peter Hansen wrote: Cantankerous Old Git wrote: The dirty way, which can leave corrupt half-written files and other nasties, is something like sys.exit(). sys.exit() won't help you if your server is running in the main thread, nor if your server thread is not marked as a daemon, but that does raise another possibility. I assume you know that I actually meant System.exit(). Why do you think that won't help? No, I didn't know that, but if you were confused the first time, I think you're getting even more confused now. What is System.exit()? I don't have one, and have never seen it mentioned. Perhaps you meant SystemExit, the exception that's raised when you call sys.exit()? If so, I still don't see your point, because there's no difference between the two in this context. Maybe you meant os._exit()? Now *that* one is messy, and will work as you described. -Peter TILTRESET Yup - I guess you're not interested in java.lang.System.exit() at all, are you. You're right about me getting confused! Perhaps I should take a break between reading the two newsgroups. Doh! sys.exit() docs (for Python) say it raises a SystemExit exception. A quick test shows that: * You can catch this to prevent being killed * It only gets raised on the calling thread - not the others So you're right - sys.exit is not very helpful in this case. os._exit is the one I was thinking of - equivalent to java's System.exit(). And to the OP, Bill - sorry for messing you around. As you see - I got confused. -- http://mail.python.org/mailman/listinfo/python-list
Re: Splitting a string into groups of three characters
Another solution derived from an old discussion about the same problem?
def takeBy(s, n):
import itertools
list(''.join(x) for x in itertools.izip(*[iter(s)]*n))
(Hoping len(s) % n = 0)
CyrilOn 8 Aug 2005 11:04:31 -0700, [EMAIL PROTECTED] [EMAIL PROTECTED]
wrote:Yes i know i made a mistake,['Hell','o W','orl','d']but you know what I mean lol,
I'll probly useJohn Machin's def nsplit(s, n):return [s[k:k+n] for k in xrange(0, len(s), n)]It seems fast, and does not require any imports.But anyways, thank you for all your help, you rock! :)
--http://mail.python.org/mailman/listinfo/python-list
--
http://mail.python.org/mailman/listinfo/python-list
Re: PEP: Specialization Syntax
Bengt Richter wrote: On Sun, 07 Aug 2005 21:41:33 -0400, Nicolas Fleury [EMAIL PROTECTED] wrote: I mean should angle brackets like in C++, or another operator, be used instead? I am getting the feeling that your PEP is about a means to do something C++-like in python, not necessarily to enhance python ;-) IOW, it seems like you want the [new syntax] to do something like C++ type_spec in templates? Yes, exactly. Actually Guido also mentionned pointy brackets: http://www.artima.com/weblogs/viewpost.jsp?thread=86641 (BTW, I have nothing against giving python new capabilities (quite the reverse), but not by grafting limbs from other animals ;-) If I look at a very recent blog entry of Guido, it seems the idea is still in the air: http://www.artima.com/weblogs/viewpost.jsp?thread=92662 Maybe you want hidden name-mangling of function defs according to arg types and corresponding dispatching of calls? I am afraid I am still not clear on the fundamental motivation for all this ;-) I wrote the PEP to see if was the only one that would benefit from generic types *before* having optional static typing in the language. It seems I'm the only one;) According to blog entry 86641, Guido himself is prototyping with __getitem__. However, I cannot do the same, because the framework I use is much more complete and keyword arguments are a must. Regards, Nicolas -- http://mail.python.org/mailman/listinfo/python-list
Re: OT: World's largest Python caught!:)
Hi All-- James Stroud wrote: http://www.afghania.com/News-article-sid-4792-mode-thread.html 3rd hit in google with world's largest python. The first two hits were your email below to the newsgroups. This hit says it's not the world's largest: http://www.reptilia.org/NEWS.htm And this one offers a better picture: http://www.clubavalanche.com/forums/index.php?showtopic=2837; Metta, Ivan James On Sunday 07 August 2005 09:15 pm, Ashok Rajasingh wrote: Hi Can I please get some information on this python? I saw a brief news clip last year am very keen to know more. Thanks Ashok Rajasingh 21 Cumberland street New Plymouth New Zealand +646 7575698 (home) 7599592 (work) ## Attention: The information contained in this message and or attachments is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any system and destroy any copies. Please note that the views or opinions expressed in this message may be those of the individual and not necessarily those of Tegel Foods Ltd. This email was scanned and cleared by NetIQ MailMarshal. ## -- James Stroud UCLA-DOE Institute for Genomics and Proteomics Box 951570 Los Angeles, CA 90095 http://www.jamesstroud.com/ -- http://mail.python.org/mailman/listinfo/python-list -- -- Ivan Van Laningham God N Locomotive Works http://www.pauahtun.org/ http://www.foretec.com/python/workshops/1998-11/proceedings.html Army Signal Corps: Cu Chi, Class of '70 Author: Teach Yourself Python in 24 Hours -- http://mail.python.org/mailman/listinfo/python-list
Re: Splitting a string into groups of three characters
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Hi,
Is there a function that split a string into groups, containing an x
amount of characters?
Ex.
TheFunction(Hello World,3)
Returns:
['Hell','o W','orl','d']
Any reply would be truly appreciated.
Look into 're' module. Essentially, split using '...', but return the
separator as well. Then, remove empty items. In Bash shell, you would
do
a=Hello World
set -- ${a|?...} # extract '...' separators
pp_collapse # remove null items
printf '{%s}\n' [EMAIL PROTECTED]
Translating to Python is left as homework.
--
William Park [EMAIL PROTECTED], Toronto, Canada
ThinFlash: Linux thin-client on USB key (flash) drive
http://home.eol.ca/~parkw/thinflash.html
BashDiff: Super Bash shell
http://freshmeat.net/projects/bashdiff/
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python -- (just) a successful experiment?
Bengt Richter wrote: It occurs to me that we have the PEP process for core python, but no PEP process for the python app/lib environment. What about starting a PEEP process (Python Environment Enhancement Proposals) modeled on PEPs, where those motivated to formalize their pet projects or feature requests could collaborate to create a spec to document and guide development? I already see the headline: PEEP is the answer - PSF votes for software patents. All ideas are written down by volunteers in great detail they just have to be coded. Due to intellectual property rights PSF becomes one of the richest organizations in the world. Guido van Rossum, chairman of PSF and mighty governor of California recommends an invasion into Iran: we cannot accept that they didn't payed us for a PEEP describing a steering mechism for a nuclear power station to be written in Python. They are dangerous. They didn't have our commitment. Mr. van Rossum also commented the unfriendly takeover of the former software giant Microsoft that was immediately renamed into Snakeoil Corp. succinctly: They had a platform we were interested in. Yes, the Python experiment was (not just) successfull. Kay -- http://mail.python.org/mailman/listinfo/python-list
python for microcontrollers
Hi all, I'm currently tackling the problem of implementing a python to assembler compiler for PIC 18Fxxx microcontrollers, and thought I'd open it up publicly for suggestions before I embed too many mistakes in the implementation. The easy part is getting the ast, via compiler.ast. Also easy is generating the code, once the data models are worked out. The hard part is mapping from the abundant high-level python reality to the sparse 8-bit microcontroller reality. I looked at pyastra, but it has fatal problems for my situation: - no backend for 18fxxx devices - only 8-bit ints supported I'm presently ripping some parts from the runtime engine of a forth compiler I wrote earlier, to add support for 8-32 bit ints, floats, and a dual-stack environment that offers comfortable support for local variables/function parameters, as well as support for simpler and more compact code generation. Python is all about implicitly and dynamically creating/destroying arbitrarily typed objects from a heap. I've got a very compact malloc/free, and could cook up a refcounting scheme, but using this for core types like ints would destroy performance, on a chip that's already struggling to do 10 mips. The best idea I've come up with so far is to use a convention of identifier endings to specify type, eg: - foo_i16 - signed 16-bit - foo_u32 - unsigned 32-bit - bar_f - 24-bit float - blah - if an identifier doesn't have a 'magic ending', it will be deemed to be signed 16-bit also, some virtual functions uint16(), int16(), uint32(), int32(), float() etc, which work similar to C casting and type conversion, so I don't have to struggle with type inference at compile time. Yes, this approach sucks. But can anyone offer any suggestions which suck less? -- Cheers EB -- One who is not a conservative by age 20 has no brain. One who is not a liberal by age 40 has no heart. -- http://mail.python.org/mailman/listinfo/python-list
Re: python for microcontrollers
Benji York wrote: Perhaps porting Pyrex would be easier. Pyrex takes a python-like syntax (plus type information, etc.) and emits C, which is then compiled. Pyrex totally rocks. But for the PIC targetting, no can do: - pyrex generates a **LOT** of code, which makes extensive use of the python-C api, which is inextricably tied to dynamic objects - PIC program memory is 32kbytes max Thanks all the same. Any other suggestions? -- Cheers EB -- One who is not a conservative by age 20 has no brain. One who is not a liberal by age 40 has no heart. -- http://mail.python.org/mailman/listinfo/python-list
Re: Syntax error after upgrading to Python 2.4
[EMAIL PROTECTED] writes: On Sat, Aug 06, 2005 at 05:15:22PM -0400, Terry Reedy wrote: In any case letting developers add new features is part of the price of getting unpaid bug fixes for free software. But note that PSF does not make you to upgrade. Here is the current list of possible downloads. [a mere 8 versions] Oh, don't give such a short list! Here's what I found on the python.org ftp site: [...] And then there's CVS... Which doesn't build for the really early versions. I think python1.0.1.tar.gz is as old as it's easy to get. Cheers, mwh -- Ignoring the rules in the FAQ: 1 slice in spleen and prevention of immediate medical care. -- Mark C. Langston, asr -- http://mail.python.org/mailman/listinfo/python-list
Re: python for microcontrollers
Evil Bastard wrote: Benji York wrote: Perhaps porting Pyrex would be easier. Pyrex totally rocks. But for the PIC targetting, no can do: ... Any other suggestions? Yes, port Lua instead. Lua is pretty much designed for this sort of application, and is probably Pythonic enough to provide whatever advantages you were trying to get from using Python, short of it actually being Python. FWIW, the interpreter/virtual machine appears to be designed to be very conservative with memory, though there's a chance it is somewhat tied to having 32-bit integers available (yet could perhaps be ported easily to some freaky 12-bit microcontroller anyway :-) ). -Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: Decline and fall of scripting languages ?
Donn Cave [EMAIL PROTECTED] writes: On the contrary, there are a couple. Ghc is probably the leading implementation these days, and by any reasonable measure, it is serious. Objective CAML is indeed not a pure functional language. *cough* unsafePerformIO *cough* Cheers, mwh -- MAN: How can I tell that the past isn't a fiction designed to account for the discrepancy between my immediate physical sensations and my state of mind? -- The Hitch-Hikers Guide to the Galaxy, Episode 12 -- http://mail.python.org/mailman/listinfo/python-list
Re: Decline and fall of scripting languages ?
In article [EMAIL PROTECTED], Paul Rubin http://[EMAIL PROTECTED] wrote: ... I notice that Haskell strings are character lists, i.e. at least conceptually, hello takes the equivalent of five cons cells. Do real implementations (i.e. GHC) actually work like that? If so, that's enough to kill the whole thing right there. Yep. There is a separate packed string type. Objective CAML is indeed not a pure functional language. Should that bother me? I should say, my interest in Ocaml or Haskell is not just to try out something new, but also as a step up from both Python and C/C++ for writing practical code. That is, I'm looking for something with good abstraction (unlike Java) and type safety (unlike C/C++), but for the goal of writing high performance code (like C/C++). I'm even (gasp) thinking of checking out Ada. It's up to you, I'm just saying. Speaking of C++, would you start someone with Python or Java for their first OOPL? Kind of the same idea. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Splitting a string into groups of three characters
I guess this question has already been thouroughly answered but here
is my version:
def split(string,n):
outlist=[]
for bottom in range(0,len(string),n):
top=min(bottom+n,len(string))
outlist.append(string[bottom:top])
return outlist
On 8/8/05, William Park [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Hi,
Is there a function that split a string into groups, containing an x
amount of characters?
Ex.
TheFunction(Hello World,3)
Returns:
['Hell','o W','orl','d']
Any reply would be truly appreciated.
Look into 're' module. Essentially, split using '...', but return the
separator as well. Then, remove empty items. In Bash shell, you would
do
a=Hello World
set -- ${a|?...} # extract '...' separators
pp_collapse # remove null items
printf '{%s}\n' [EMAIL PROTECTED]
Translating to Python is left as homework.
--
William Park [EMAIL PROTECTED] , Toronto, Canada
ThinFlash: Linux thin-client on USB key (flash) drive
http://home.eol.ca/~parkw/thinflash.html
BashDiff: Super Bash shell
http://freshmeat.net/projects/bashdiff/
--
http://mail.python.org/mailman/listinfo/python-list
--
Gregory Piñero
Chief Innovation Officer
Blended Technologies
(www.blendedtechnologies.com)
--
http://mail.python.org/mailman/listinfo/python-list
Re: python for microcontrollers
Evil Bastard [EMAIL PROTECTED] writes: Yes, this approach sucks. But can anyone offer any suggestions which suck less? I don't think you want to do this. Runtime type tags and the overhead of checking them on every operation will kill you all by themselves. Processors like that haven't been used much as Lisp targets either, for the same reasons. Pick a different language. -- http://mail.python.org/mailman/listinfo/python-list
Re: python for microcontrollers
How about just helping this project: http://pyastra.sourceforge.net/ I know he's trying to rewrite it to work across multiple uC's (AVR,msp430 etc) HTH, Guy Evil Bastard wrote: Hi all, I'm currently tackling the problem of implementing a python to assembler compiler for PIC 18Fxxx microcontrollers, and thought I'd open it up publicly for suggestions before I embed too many mistakes in the implementation. The easy part is getting the ast, via compiler.ast. Also easy is generating the code, once the data models are worked out. The hard part is mapping from the abundant high-level python reality to the sparse 8-bit microcontroller reality. I looked at pyastra, but it has fatal problems for my situation: - no backend for 18fxxx devices - only 8-bit ints supported I'm presently ripping some parts from the runtime engine of a forth compiler I wrote earlier, to add support for 8-32 bit ints, floats, and a dual-stack environment that offers comfortable support for local variables/function parameters, as well as support for simpler and more compact code generation. Python is all about implicitly and dynamically creating/destroying arbitrarily typed objects from a heap. I've got a very compact malloc/free, and could cook up a refcounting scheme, but using this for core types like ints would destroy performance, on a chip that's already struggling to do 10 mips. The best idea I've come up with so far is to use a convention of identifier endings to specify type, eg: - foo_i16 - signed 16-bit - foo_u32 - unsigned 32-bit - bar_f - 24-bit float - blah - if an identifier doesn't have a 'magic ending', it will be deemed to be signed 16-bit also, some virtual functions uint16(), int16(), uint32(), int32(), float() etc, which work similar to C casting and type conversion, so I don't have to struggle with type inference at compile time. Yes, this approach sucks. But can anyone offer any suggestions which suck less? -- http://mail.python.org/mailman/listinfo/python-list
Re: Splitting a string into groups of three characters
William Park wrote:
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Hi,
Is there a function that split a string into groups, containing an x
amount of characters?
Ex.
TheFunction(Hello World,3)
Returns:
['Hell','o W','orl','d']
Any reply would be truly appreciated.
Look into 're' module. Essentially, split using '...', but return the
separator as well. Then, remove empty items. In Bash shell, you would
This would have to be a candidate for arcane side-effect of the month.
Not in front of the children, please.
do
a=Hello World
set -- ${a|?...}# extract '...' separators
pp_collapse # remove null items
printf '{%s}\n' [EMAIL PROTECTED]
Translating to Python is left as homework.
Given that the OP was struggling to write a simple loop in Python,
giving him an answer in hieroglypghics and suggesting he translate it
into Python could be described as unhelpful.
--
http://mail.python.org/mailman/listinfo/python-list
Re: python for microcontrollers
Paul Rubin wrote: I don't think you want to do this. Runtime type tags and the overhead of checking them on every operation will kill you all by themselves. Processors like that haven't been used much as Lisp targets either, for the same reasons. Pick a different language. I was thinking that you could avoid this by adding some type inference to Python and/or reducing everything to two basic types (strings and ints), but the end result would require a lot of work and not look much like Python. For a PIC, I'm not even sure I'd want to use C++. Then again, I'm not much of a fan of BASIC stamp modules, either, so... -- http://mail.python.org/mailman/listinfo/python-list
Re: issues with doctest and threads
[Michele Simionato] I am getting a strange error with this script: $ cat doctest-threads.py import time, threading def example(): ... thread.out = [] ... while thread.running: ... time.sleep(.01) ... thread.out.append(.) thread = threading.Thread(None, example) thread.running = True; thread.start() time.sleep(.1) thread.running = False print thread.out ['.', '.', '.', '.', '.', '.', '.', '.', '.'] if __name__ == __main__: import doctest; doctest.testmod() $ python doctest-threads.py Exception in thread Thread-1: Traceback (most recent call last): File /usr/lib/python2.4/threading.py, line 442, in __bootstrap self.run() File /usr/lib/python2.4/threading.py, line 422, in run self.__target(*self.__args, **self.__kwargs) File doctest __main__[1], line 5, in example NameError: global name 'thread' is not defined It looks like pure thread-race accident to me. The main program does nothing to guarantee that the thread is finished before it prints `thread.out`, neither anything to guarantee that Python doesn't exit while the thread is still running. Stuff, e.g., a time.sleep(5) after thread.running = False, and it's much more likely to work the way you intended (but still not guaranteed). A guarantee requires explicit synchronization; adding thread.join() after thread.running = False should be sufficient. That ensures two things: 1. The `example` thread is done before thread.out gets printed. 2. The *main* thread doesn't exit (and Python doesn't start tearing itself down) while the `example` thread is still running. The exact output depends on OS scheduling accidents, but I expect you'll see 10 dots most often. BTW, trying to coordinate threads with sleep() calls is usually a Bad Idea; you can't generally expect more from an OS than that it will treat sleep's argument as a lower bound on the elapsed time the sleeper actually yields the CPU. -- http://mail.python.org/mailman/listinfo/python-list
Re: [Python-Dev] PEP-343 - Context Managment variant
falcon [EMAIL PROTECTED] wrote: It's idea was token from Ruby. But I think, good idea is good whatever it came from. It can be not Pythonic. Just because something may be a good idea, doesn't mean that the idea is Pythonic. The only person who can truely say is Guido, but you can gain some insight by reading the zens (from the console, 'import this'). The fact is, context management has a syntax that has been accepted. Your first example: def Synhronised(lock,func): lock.acquire() try: func() finally: lock.release() lock=Lock() def Some(): local_var1=x local_var2=y local_var3=Z def Work(): global local_var3 local_var3=Here_I_work(local_var1,local_var2,local_var3) Synhronised(lock,Work) return asd(local_var3) ... becomes ... def Synchronized(lock): lock.acquire() try: yield None finally: lock.release() def Some(): ... with Synchronized(lock): local_var3 = Here_I_work(local_var1,local_var2,local_var3) ... Which is quite close to what you offer: Synhronised(lock,block) local_var3=Here_I_work(local_var1,local_var2,local_var3) It is of my opinion that your proposal is destined to fail for at least two reasons; 1) context management already has an accepted syntax 2) ruby blocks were found (due to lack of evidence to the contrary) to gain Python users very little (if anything) over the accepted context management syntax. To note; unless your post is of the utmost importance, cross-posting to python-list and python-dev seems quite rude to me. Further, a variant of Ruby block syntax was offered way back in February and March (read the python-dev archives available at http://mail.python.org/pipermail/python-dev/ ). Reading what was already discussed may offer you insight into what (if any) open issues were remaining, and precisely why the context management syntax was supported over anonymous blocks/thunks/Ruby blocks. - Josiah -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP: Specialization Syntax
On Mon, 08 Aug 2005 16:18:50 -0400, Nicolas Fleury [EMAIL PROTECTED] wrote:
Bengt Richter wrote:
On Sun, 07 Aug 2005 21:41:33 -0400, Nicolas Fleury [EMAIL PROTECTED] wrote:
I mean should angle brackets like in C++, or another operator, be
used instead?
I am getting the feeling that your PEP is about a means to do something
C++-like
in python, not necessarily to enhance python ;-) IOW, it seems like you
want the [new syntax] to do something like C++ type_spec in templates?
Yes, exactly. Actually Guido also mentionned pointy brackets:
http://www.artima.com/weblogs/viewpost.jsp?thread=86641
(BTW, I have nothing against giving python new capabilities (quite the
reverse),
but not by grafting limbs from other animals ;-)
If I look at a very recent blog entry of Guido, it seems the idea is
still in the air:
http://www.artima.com/weblogs/viewpost.jsp?thread=92662
Maybe you want hidden name-mangling of function defs according to arg types
and corresponding dispatching of calls? I am afraid I am still not clear
on the fundamental motivation for all this ;-)
I wrote the PEP to see if was the only one that would benefit from
generic types *before* having optional static typing in the language.
It seems I'm the only one;)
According to blog entry 86641, Guido himself is prototyping with
__getitem__. However, I cannot do the same, because the framework I use
is much more complete and keyword arguments are a must.
Here is a decorator object to set up function call dispatch according to type.
It only uses positional arguments, but could be fleshed out, I think.
Not tested beyond what you see ;-)
typedispatcher.py -
# typedispatcher.py
Provides a decorator to dispatch function
calls according to arg types and signature.
Example usage:
foodisp = TypeDispatcher() # instance dedicated to foo variants
@foodisp(a=int, b=str)
def foo(a, b):
assert type(a) is int and type(b) is str
return (a,b)
@foodisp(a=str, b=str)
def foo(a, b):
assert type(a) is str and type(b) is str
return (a,b)
class TypeDispatcher(object):
def __init__(self):
self.dispdict = {}
def __call__(self, **kwtypes):
self.kwtemp = kwtypes
return self.dodeco
def dodeco(self, f):
if not hasattr(self, 'name'):
self.name = f.func_name
if f.func_name != self.name:
raise ValueError('This TypeDispatcher instance decorates only
functions named %r' % self.name)
sig = tuple((self.kwtemp[argname] for argname in
f.func_code.co_varnames[:f.func_code.co_argcount]))
assert len(set([f.func_name]+list(f.func_name for f in
self.dispdict.values(
self.dispdict[sig] = f
return self.docall
def docall(self, *args):
sig = tuple(map(type, args))
try: f = self.dispdict[sig]
except KeyError:
raise TypeError('no function %r with signature %r' % (self.name,
sig))
return f(*args)
def test():
try:
foodisp = TypeDispatcher()
@foodisp(a=int, b=str)
def foo(a, b):
assert type(a) is int and type(b) is str
return 'foo(int, str):', (a,b)
@foodisp(a=str, b=str)
def foo(a, b):
assert type(a) is str and type(b) is str
return 'foo(str, str):', (a,b)
@foodisp()
def foo():
return 'foo()', ()
print foo(123, 'hello')
print foo('hi','there')
print foo()
print foo(456, 789)
except Exception, e:
print 'Exception %s: %s' % (e.__class__.__name__, e)
try:
@foodisp()
def bar(): pass
except Exception, e:
print 'Exception %s: %s' % (e.__class__.__name__, e)
if __name__ == '__main__':
test()
--
Result:
[17:12] C:\pywk\utpy24 typedispatcher.py
('foo(int, str):', (123, 'hello'))
('foo(str, str):', ('hi', 'there'))
('foo()', ())
Exception TypeError: no function 'foo' with signature (type 'int', type
'int')
Exception ValueError: This TypeDispatcher instance decorates only functions
named 'foo'
Regards,
Bengt Richter
--
http://mail.python.org/mailman/listinfo/python-list
Re: PEP: Specialization Syntax
On Tue, 09 Aug 2005 00:14:25 GMT, [EMAIL PROTECTED] (Bengt Richter) wrote: [...] Here is a decorator object to set up function call dispatch according to type. It only uses positional arguments, but could be fleshed out, I think. Not tested beyond what you see ;-) typedispatcher.py - # typedispatcher.py [...] assert len(set([f.func_name]+list(f.func_name for f in self.dispdict.values( [...] Oops, that was a leftover hack that was supposed to check that all names were the same, and was missing ==1 at the right. Replaced by using self.name. Sorry. There's probably more, but the overall idea should be clear. Using **kw is also a leftover of starting down the trail of handling more signature variants, but I was too lazy. Regards, Bengt Richter -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP: Specialization Syntax
Bengt Richter wrote: On Mon, 08 Aug 2005 16:18:50 -0400, Nicolas Fleury [EMAIL PROTECTED] wrote: I wrote the PEP to see if was the only one that would benefit from generic types *before* having optional static typing in the language. It seems I'm the only one;) According to blog entry 86641, Guido himself is prototyping with __getitem__. However, I cannot do the same, because the framework I use is much more complete and keyword arguments are a must. Here is a decorator object to set up function call dispatch according to type. It only uses positional arguments, but could be fleshed out, I think. Not tested beyond what you see ;-) That's nice. Guido also posted this multimethods solution: http://www.artima.com/weblogs/viewpost.jsp?thread=101605 The only thing I was saying it that I can use generic types in Python right now (and I do), by using (), but I can't with what will probably be the syntax in future, i.e. using []. Regards, Nicolas -- http://mail.python.org/mailman/listinfo/python-list
