Turn $6 into $6.000
HOW TO TURN 6 BUCKS INTO 6 THOUSAND! (WORLD WIDE) WARNING: READING THIS WILL CHANGE YOUR LIFE! I found this on a Bulletin board and decided to try it. A little while back, I was browsing through newsgroups, just like you are now, and came across an article similar to this that said you could make thousands of dollars within weeks with only an initial investment of $6.00! So I thought, "Yeah right, this must be a scam", but like most of us, I was curious, so I kept reading.Anyway, it said that you send $1.00 to each of the 6 names and addresses stated in the article. You then place your own name and address in the bottom of the list at #6, and post the article in at least 200 newsgroups. (There are thousands) No catch, that was it. So after thinking it over, and talking to a few people first, I thought about trying it. I figured: "what have I got to lose except 6 stamps and $6.00, right?" Then I invested the measly $6.00. Well GUESS WHAT!! Within 7 days, I started getting money in the mail! I was shocked! I figured it would end soon, but the money just kept coming in. In my first week, I made about $25.00. By the end of the second week I had made a total of over $1,000.00! In the third week I had over $10,000.00 and it's still growing. This is now my fourth week and I have made a total of just over $42,000.00 and it's still coming in rapidly. It's certainly worth $6.00, and 6 stamps, I have spent more than that on the lottery!! Let me tell you how this works and most importantly, why it works. Also, make sure you print a copy of this article NOW, so you can get the information off of it, as you need it. I promise you that if you follow the directions exactly, that you will start making more money than you thought possible by doing something so easy! Suggestion: Read this entire message carefully! (Print it out or download it.) Follow the simple directions and watch the money come in! It's easy. It's legal, and your investment is only $6.00 (Plus postage) IMPORTANT: This is not a rip-off; it is not indecent; it is not illegal; and it is virtually no risk because it really works!!!If all of the following instructions are adhered to exactly, you will receive extraordinary dividends. PLEASE NOTE: Please follow these directions EXACTLY, and $50,000 or more can be yours in 20 to 60 days. This program remains successful because of the honesty and integrity of the participants. Please continue its success by carefully adhering to the instructions. You will now become part of the Mail Order business. In this business your product is not solid and tangible, it's a service. You are in the business of developing Mailing Lists. Many large corporations are happy to pay big bucks for quality lists. However, the money made from the mailing lists is secondary to the income which is made from people like you and me asking to be included in that list. Here are the 4 easy steps to success: STEP 1: Get 6 separate pieces of paper and write the following on each piece of paper "PLEASE PUT ME ON YOUR MAILING LIST!" Now get 6 US $1.00 bills and place ONE inside EACH of the 6 pieces of paper so the bill will not be seen through the envelope (to prevent thievery). Next, place one paper in each of the 6 envelopes and seal them. You should now have 6 sealed envelopes, each with a piece of paper stating the above phrase, your name and address, and a $1.00 bill. What you are doing is creating a service. THIS IS ABSOLUTELY LEGAL! You are requesting a legitimate service and you are paying for it! Like most of us I was a little skeptical and a little worried about the legal aspects of it all. So I checked it out with the U.S. Post Office (1-800-725-2161) and they confirmed that it is indeed legal. Mail the 6 envelopes to the following addresses: Note: Make sure you put the correct amount of postage stamps on your envelopes.Other countries my need more stamps so be correct on how many you put.And remember your business will be running Throughout the world so when you start posting messages or emails to people this will bring in thousands of dollars from all over the world. So now, you have money flowing \ in from countries!That's how I became so successful in this business. Mail the 6 envelopes to the following addresses: #1) Tom Zimmerman IV 193 Yard St Nesquehoning, PA. 18240 #2) B. Pratt 5535 E 100 N Knox, IN 46534 #3) Michele Tyska PO Box 765 Northport, NY 11768 #4) David Weir PO Box 144 Schooleys Mt., NJ 07870 #5) S. Nagirnyak 14139 Pine Forest Drive #208 North Royalton, OH 44133 #6) Guillermo Oscar Sanchez Mallea Madero 225 Vicente Lopez CP:1638 Buenos Aires - Argentina STEP 2:Now take the #1 name off the list that you see above, move the other names up (6 becomes 5, 5 becomes 4, etc...) and add YOUR NAME as number 6 on the list.STEP 3: Change anything you need to, but try to keep this article as close to original as possible. Now, post your amended article to at least 200 newsgroups. (I think there a
Re: How to run PyOS_InputHook from python code (i.e. yield to event loops)
Sean DiZazzo <[EMAIL PROTECTED]> writes:
>> My eventual code would be something like:
>>
>> launch_process_in_thread('bzr pull')
>>
>> while not is_done:
>> pyos_inputhook()
>> time.sleep(0.1)
>>
>> print "Done!"
>
> I'm still recovering from a hangover, so don't quote me. I think you
> want the "after" function:
>
> launch_process_in_thread('bzr pull')
> self.update()
>
> def update(self):
> while not self.is_done:
> self.after(2000, self.update)
That's tk-specific, right? I'm looking for a snippet that
- Would not be tied to tk
- Would run sequentially, i.e. the next command would not be entered
before the process has finished. Just like os.system()
--
http://mail.python.org/mailman/listinfo/python-list
Python reliability
I would need to make some high-reliability software running on Linux in an embedded system. Performance (or lack of it) is not an issue, reliability is. The piece of software is rather simple, probably a few hundred lines of code in Python. There is a need to interact with network using the socket module, and then probably a need to do something hardware- related which will get its own driver written in C. Threading and other more error-prone techniques can be left aside, everything can run in one thread with a poll loop. The software should be running continously for practically forever (at least a year without a reboot). Is the Python interpreter (on Linux) stable and leak-free enough to achieve this? - Ville -- Ville Voipio, Dr.Tech., M.Sc. (EE) -- http://mail.python.org/mailman/listinfo/python-list
wxPython in a PDA
Does anyone know of an inexpensive PDA which would run wxPython? The availability of a conventional (wired) Ethernet would be nice, as well (e.g., using a CF adapter). TIA, - Ville -- Ville Voipio, Dr.Tech., M.Sc. (EE) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python reliability
In article <[EMAIL PROTECTED]>, Paul Rubin wrote: > I would say give the app the heaviest stress testing that you can > before deploying it, checking carefully for leaks and crashes. I'd > say that regardless of the implementation language. Goes without saying. But I would like to be confident (or as confident as possible) that all bugs are mine. If I use plain C, I think this is the case. Of course, bad memory management in the underlying platform will wreak havoc. I am planning to use Linux 2.4.somethingnew as the OS kernel, and there I have not experienced too many problems before. Adding the Python interpreter adds one layer on uncertainty. On the other hand, I am after the simplicity of programming offered by Python. - Ville -- Ville Voipio, Dr.Tech., M.Sc. (EE) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python reliability
In article <[EMAIL PROTECTED]>, Steven D'Aprano wrote: > If performance is really not such an issue, would it really matter if you > periodically restarted Python? Starting Python takes a tiny amount of time: Uhhh. Sounds like playing with Microsoft :) I know of a mission- critical system which was restarted every week due to some memory leaks. If it wasn't, it crashed after two weeks. Guess which platform... > $ time python -c pass > real0m0.164s > user0m0.021s > sys 0m0.015s This is on the limit of being acceptable. I'd say that a one-second time lag is the maximum. The system is a safety system after all, and there will be a hardware watchdog to take care of odd crashes. The software itself is stateless in the sense that its previous state does not affect the next round. Basically, it is just checking a few numbers over the network. Even the network connection is stateless (single UDP packet pairs) to avoid TCP problems with partial closings, etc. There are a gazillion things which may go wrong. A stray cosmic ray may change the state of one bit in the wrong place of memory, and that's it, etc. So, the system has to be able to recover from pretty much everything. I will in any case build an independent process which probes the state of the main process. However, I hope it is never really needed. > I'm not saying that you will need to restart Python once an hour, or even > once a month. But if you did, would it matter? What's more important is > the state of the operating system. (I'm assuming that, with a year uptime > the requirements, you aren't even thinking of WinCE.) Not even in my worst nightmares! The platform will be an embedded Linux computer running 2.4.somethingnew. - Ville -- Ville Voipio, Dr.Tech., M.Sc. (EE) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python reliability
In article <[EMAIL PROTECTED]>, Steven D'Aprano wrote: > If you have enough hardware grunt, you could think > about having three independent processes working in > parallel. They vote on their output, and best out of > three gets reported back to the user. In other words, > only if all three results are different does the device > throw its hands up in the air and say "I don't know!" Ok, I will give you a bit more information, so that the situation is a bit clearer. (Sorry, I cannot tell you the exact application.) The system is a safety system which supervises several independent measurements (two or more). The measurements are carried out by independent measurement instruments which have their independent power supplies, etc. The application communicates with the independent measurement instruments thrgough the network. Each instrument is queried its measurement results and status information regularly. If the results given by different instruments differ more than a given amount, then an alarm is set (relay contacts opened). Naturally, in case of equipment malfunction, the alarm is set. This covers a wide range of problems from errors reported by the instrument to physical failures or program bugs. The system has several weak spots. However, the basic principle is simple: if anything goes wrong, start yelling. A false alarm is costly, but not giving the alarm when required is downright impossible. I am not building a redundant system with independent instruments voting. At this point I am trying to minimize the false alarms. This is why I want to know if Python is reliable enough to be used in this application. By the postings I have seen in this thread it seems that the answer is positive. At least if I do not try apply any adventorous programming techniques. - Ville -- Ville Voipio, Dr.Tech., M.Sc. (EE) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python reliability
In article <[EMAIL PROTECTED]>, Paul Rubin wrote: > You might be better off with a 2.6 series kernel. If you use Python > conservatively (be careful with the most advanced features, and don't > stress anything too hard) you should be ok. Python works pretty well > if you use it the way the implementers expected you to. Its > shortcomings are when you try to press it to its limits. Just one thing: how reliable is the garbage collecting system? Should I try to either not produce any garbage or try to clean up manually? > You do want reliable hardware with ECC and all that, maybe with multiple > servers and automatic failover. This site might be of interest: Well... Here the uptime benefit from using several servers is not eceonomically justifiable. I am right now at the phase of trying to minimize the downtime with given hardware resources. This is not flying; downtime does not kill anyone. I just want to avoid choosing tools which belong more to the problem than to the solution set. - Ville -- Ville Voipio, Dr.Tech., M.Sc. (EE) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python reliability
In article <[EMAIL PROTECTED]>, Thomas Bartkus wrote: > > All in all, it would seem that the reliability of the Python run time is the > least of your worries. The best multi-tasking operating systems do a good > job of segragating different processes BUT what multitasking operating > system meets the standard you request in that last paragraph? Well, let's put it this way. I have seen many computers running Linux with a high load of this and that (web services, etc.) with uptimes of years. I have not seen any recent Linux crash without faulty hardware or drivers. If using Python does not add significantly to the level of irreliability, then I can use it. If it adds, then I cannot use it. > type of rugged use you are demanding. I would google "embedded systems". > If you want to use Python/Linux, I might suggest you search "Embedded > Linux". I am an embedded system designer by my profession :) Both hardware and software for industrial instruments. Computers are just a side effect of nicer things. But here I am looking into the possibility of making something with embedded PC hardware (industrial PC/104 cards). The name of the game is "as good as possible with the given amount of money". In that respect this is not flying or shooting. If something goes wrong, someone loses a bunch of dollars, not their life. I think that in this game Python might be handy when it comes to maintainability and legibility (vs. C). But choosing a tool which is known to be bad for the task is not a good idea. - Ville -- Ville Voipio, Dr.Tech., M.Sc. (EE) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python reliability
In article <[EMAIL PROTECTED]>, Peter Hansen wrote: > Other than that, we had no real issues and definitely felt the choice of > Python was completely justified. I have no hesitation recommending it, > other than to caution (as I believe Paul R did) that use of new features > is "dangerous" in that they won't have as wide usage and shouldn't > always be considered "proven" in long-term field use, by definition. Thank you for this information. Of course, we try to be as conservative as possible. The application fortunately allows for this, cyclic references and new features can most probably be avoided. > Also test heavily. We were using test-driven development and had > effectively thousands of hours of run-time by the time the first system > shipped, so we had great confidence in it. Yes, it is usually much nicer to debug the software in the quiet, air-conditioned lab than somewhere in a jungle on the other side of the globe with an extremely angry customer next to you... - Ville -- Ville Voipio, Dr.Tech., M.Sc. (EE) -- http://mail.python.org/mailman/listinfo/python-list
Re: UI toolkits for Python
In article <[EMAIL PROTECTED]>, Kenneth McDonald wrote: > 4) Ease of installation/use on OS X? There are two questions which may restrict your choice rather a lot: #1 Should the UI look the same on each platform or should it look the same as all other apps on the platform? #2 Are you trying to make a simple installation package which includes everything needed? With OS X compatibility you tend to come across with the fact that many "OS X compatible" things are actually X11 things. X11 certainly looks different from Aqua (the native interface). Also, X11 is not always installed, and some unixish things require using Fink to install them. Not something Joe A. User usually has on his Mac. GTK is an example of this. There is an Aqua version of GTK, but it seems to be rather outdated. The newer versions run on X11 but installing them may be just laborious or then plain pain depending on your luck. And you still need the X11 installed. So, if you are looking for something that looks like Mac and works like Mac, do not touch anything with X11. OTOH, if you just need to get something working on your own OS X computer, then X11 is fine. --- I have tried using wxPython for Mac/Windows cross-platform GUIs. This far it seems to work fine, but I have not tried anything very fancy. Mac applications have the OS X looks, and Windows applications look Windowsish. Without having a single line of platform-dependent code. Making simple installation files (exe for Windows and dmg for OS X) seems to work, as well. So, the installation should be easy for the user. - Ville -- Ville Voipio, Dr.Tech., M.Sc. (EE) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python! Is! Truly! Amazing!
>>>>> "jfj" == jfj <[EMAIL PROTECTED]> writes: jfj> There were functional and non-functional programming jfj> languages (the first being *much* simpler to jfj> implement). There is a *reason* people chose C over jfj> lisp. It's not that we were all blind and didn't see the jfj> amazingness of lisp. Procedural languages are simply better, jfj> and I'm not replying to this flamewar. You did already ;). Lisp is not a functional programming language, if that was the case it would be even less popular than it is now. Lisp had it's heyday, while pure FP languages didn't even have that much. Hey, it's 2005, I don't think we've used up our yearly Lisp flamewar quota yet. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Python evolution: Unease
>>>>> "Iwan" == Iwan van der Kleyn <[EMAIL PROTECTED]> writes: Iwan> And then I read the following sentence by Van Rossum: Iwan> "In order to make type inferencing a little more useful, I'd Iwan> like to restrict certain forms of extreme dynamic behavior Iwan> in Python" Iwan> In the end, it's mindset which counts. And I think that Iwan> mindset is going to be determine the way foreward for Iwan> Python: more features, increased complexity, less Iwan> dynamism. Lots of syntax crud, without addressing the need Iwan> to improve the infrastructure around the language. What form of extreme dynamic behaviour have you been using lately? Do you really think it's more worthwhile than the benefits provided by type inference, least of which isn't the ability by IDEs to provide you accurate code completion. Also, Python is not a monolithic entity. Guido certainly isn't going to write a better IDE for Python, so the time used on language features isn't removed from improving the infrastructure around the language. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Python evolution: Unease
>>>>> "Paul" == Paul Rubin <http://[EMAIL PROTECTED]> writes: Paul> Ville Vainio <[EMAIL PROTECTED]> writes: >> Also, Python is not a monolithic entity. Guido certainly isn't >> going to write a better IDE for Python, so the time used on >> language features isn't removed from improving the >> infrastructure around the language. Paul> There aren't THAT many people working on Python. Any time Paul> spent on feature X does tend to divert resources from Paul> feature Y. But the people working on wxPython, pygtk, pyqt, pydev, whatever, are largely not the same guys that commit stuff to CPython CVS. Paul> fully deployed. Too much of Python as we know it today is Paul> shaped by the weirdness of CPython. We ought to be able to Paul> get away from that. Type declarations are a feature that might benefit IronPython and Jython more than they would CPython. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Python evolution: Unease
>>>>> "Paul" == Paul Rubin <http://[EMAIL PROTECTED]> writes: Paul> inclusion in some bigger distro. E.g., I'm now running the Paul> Python Python into Fedora. So it's up to the Python Paul> maintainers, not the Fedora maintainers or the user, to make Paul> sure that the Python distro has everything that users need, Paul> without further downloading. To me, this seems to be the job for the Fedora maintainers, not Python maintainers. If something essential is not in the distro the distro maintainers have screwed up. Paul> And that was just about Tkinter, for which good docs exist Paul> but just don't happen to be in the distro. How about I think most people these days do a google search when they are learning how to use a feature to get the whole story. It's often also faster than finding the information in the bundled documentation - even if the first google hit often happens to refer to the page with the very documentation thu user would have looked up. Paul> The book is very good, but having to go buy a proprietary Paul> book is the opposite of what self-contained free software Paul> documentation is supposed to mean. I'm not sure the free software documentation is going to evolve to be more self-contained; the exact opposite is more likely. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Python evolution: Unease
>>>>> "Paul" == Paul Rubin <http://[EMAIL PROTECTED]> writes: Paul> Ville Vainio <[EMAIL PROTECTED]> writes: >> To me, this seems to be the job for the Fedora maintainers, not >> Python maintainers. If something essential is not in the distro >> the distro maintainers have screwed up. Paul> I can't parse that. It says two contradictory things. Paul> Sentence 2 says that if something essential is not in the Paul> (Python) distro then the (Python) distro maintainers have Paul> screwed up. Sentence 1 says it's the Fedora maintainer's Paul> job to deal with it. Huh? By "distro" I meant the Linux distribution, not the Python distribution. Distro is a customary term for a Linux distribution so I didn't qualify the word at the time. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Securing a future for anonymous functions in Python
>>>>> "James" == James Stroud <[EMAIL PROTECTED]> writes: James> I think we should not try too hard to make everything James> "English" like. Its a crappy language anyway (though its James> the only one I speak good). Matt Neuberg, QOTW material, unless you stole this from someone else :-). -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Port blocking
>>>>> "Mark" == Mark Carter <[EMAIL PROTECTED]> writes: Mark> Mark Carter wrote: >> Paul Rubin wrote: >>> Usually you wouldn't run a public corba or pyro service over >>> the internet. You'd use something like XMLRPC over HTTP port >>> 80 partly for the precise purpose of not getting blocked by >>> firewalls. Mark> I'm not sure if we're talking at cross-purposes here, but Mark> the application isn't intended for public consumption, but Mark> for fee-paying clients. Still, if the consumption happens over the internet there is almost 100% chance of the communication being prevented by firewalls. This is exactly what "web services" are for. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Port blocking
>>>>> "Steve" == Steve Holden <[EMAIL PROTECTED]> writes: >> >>> Usually you wouldn't run a public corba or pyro service over >> >>> the internet. You'd use something like XMLRPC over HTTP port >> >>> 80 partly for the precise purpose of not getting blocked by >> >>> firewalls. Mark> I'm not sure if we're talking at cross-purposes here, but Mark> the application isn't intended for public consumption, but Mark> for fee-paying clients. >> Still, if the consumption happens over the internet there is almost >> 100% chance of the communication being prevented by firewalls. >> This is exactly what "web services" are for. Steve> I teach the odd security class, and what you say is far Steve> from true. As long as the service is located behind a Steve> firewall which opens up the correct holes for it, it's most Steve> unlikely that corporate firewalls would disallow client Steve> connections to such a remote port. Yes, but "clients" might also act as servers, e.g. when they register a callback object and expect the "server" to invoke something later on. This is possible (and typical) with CORBA at least. ORBs can use the same client-initiated connection for all the traffic, but this is probably somewhere in the gray area. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: OCAMl a more natural extension language for python?
>>>>> "Jelle" == Jelle Feringa // EZCT / Paris <[EMAIL PROTECTED]> writes: Jelle> After reading about extending python with C/Fortran in the Jelle> excellent Python Scripting for Computational Science book Jelle> by Hans Langtangen, I'm wondering whether there's not a Jelle> more pythonic way of extending python. And frankly I think Jelle> there is: OCAML For many tasks the point of "extending" python is to gain access to libraries that have a C/C++ API. Extensions that merely provide a faster way to do something are much rarer. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] Good C++ book for a Python programmer
>>>>> "Rick" == rick [EMAIL PROTECTED] com <[EMAIL PROTECTED]> writes: Rick> I was wondering whether anyone could recommend a good C++ Rick> book, with "good" being defined from the perspective of a Rick> Python programmer. I A good C++ book from the perspective of a Python programmer would be one proclaiming that C++ is deprecated as a language, and it has become illegal to develop software with it. Rick> realize that there isn't a book titled "C++ for Python Rick> Programmers", but has anyone found one that they think goes Rick> particularly well with the Python way? I don't think that's possible, considering the nature of the language. Templates are closest to the Python way as far as C++ technologies go, but they are very unpythonic in their complexity. Rick> I'm asking this because evidently the C++ standard has Rick> changed a bit since 1994, when I bought my books. Who knew Rick> that fstream was deprecated? Stroustrup book, already mentioned by others, is the one if you just need a "refresh" your knowledge. "Effective C++" and "More effective C++" are also great to learn about all the nasty gotchas that your Python experience might make you neglect. They are also certain to deepen your appreciation of Python ;-). -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: IPython Article on O'Reilly's ONLamp site
>>>>> "Jeremy" == Jeremy Jones <[EMAIL PROTECTED]> writes: Jeremy> feedback is welcome. Regardless of what you may think of Jeremy> the article, I hope it encourages everyone to at least try Jeremy> out IPython. IPython has become an indispensible tool in Jeremy> my toolbox. I cannot say enough great things about it. I've said this before, but I'd just like to add that IPython (with the pysh profile) makes a damn fine command prompt for Windows. The loss of job control is not a problem there, because it never was there in the first place. Even if you never use the underlying Python functionality, you can enjoy the Bash-like filename completion (the only way to fly - the windows "4dos-style" completion doesn't cut it for me). I've never really trusted Bash (from cygwin) in Windows, it has always felt very alien. Just install ipython and the "unxutils" package, and windows command prompt suddenly becomes usable. What is essential for me (because I deal with complex source trees) is the persistent "bookmark functionality" for directories (yes, Fernando, this is a shameless plug ;-): Lines starting w/ @POR078 are commands typed by the user. --- ipython session - @POR078[prj]|22> %bookmark? Manage IPython's bookmark system. %bookmark- set bookmark to current dir %bookmark - set bookmark to %bookmark -l - list all bookmarks %bookmark -d - remove bookmark %bookmark -r - remove all bookmarks You can later on access a bookmarked folder with: %cd -b or simply '%cd ' if there is no directory called AND there is such a bookmark defined. Your bookmarks persist through IPython sessions, but they are associated with each profile. @POR078[testrunner]|24> %bookmark tr @POR078[testrunner]|25> cd /prj/SyncML/doc/ @POR078[doc]|26> %bookmark smldoc @POR078[doc]|27> Exit (IPython exits, I start a new session) @POR078[environmentswitch]|1> cd tr (bookmark:tr) -> C:\prj\testrunner @POR078[testrunner]|3> cd smldoc (bookmark:smldoc) -> C:\prj\SyncML\doc @POR078[doc]|4> -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Python for S60 mentioned in a mainstream Finnish e-news website
http://digitoday.fi/showPage.php?page_id=9&news_id=40179 Literal translation for those who can't read Finnish: Nokia has published the Open Source Python language for Series 60 based mobile devices. The company states that the language makes it easy for the wordwide Python community to execute commands and run scripts and apps in the devices. The language is available for free from the Nokia developer pages and can be installed on a S60 device with an installation package. - Python makes the mobile app devepment easy for the programmers who are looking for a rapid and developer friendly way to develop mobile applications, says Director Lee Epting from Forum Nokia. Nokia believes that Python for Series 60 is a good fit for developing prototype- and proof-of-concept apps. The company characterizes the language as efficient and relatively easy to learn. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Python for S60 mentioned in a mainstream Finnish e-news website
Of course there is the whole hog and more in the official Nokia press release, this time in English: http://press.nokia.com/PR/200501/978226_5.html It also paints an accurate and quite positive picture of Python. Now we just need ctypes or Symbianic Swig and world domination will be ours ;-). (Yeah, ctypes will probably be a problem because of the way Symbian handles DLLs) -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Python for S60 mentioned in a mainstream Finnish e-news website
>>>>> "Thomas" == Thomas Heller <[EMAIL PROTECTED]> writes: >> (Yeah, ctypes will probably be a problem because of the way Symbian >> handles DLLs) Thomas> How *does* symbian handle DLLs? By ordinal, so the dll does not include the symbol name (in order to keep the size small). Linker finds the ordinals from the .LIB file that corresponds to the DLL. (Someone who knows better might want to correct me if I'm wrong). -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Loop until condition is true
>>>>> "Stelios" == Stelios Xanthakis <[EMAIL PROTECTED]> writes: Stelios> Anyway, if you can't wait for 2.5 either use 'while 1:', Stelios> or pyc[1] ... and I can't see why people don't want to use 'while 1:' in the first place, given that everyone can identify the idiom immediately. It's 4 keystrokes less. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: *Python* Power Tools
>>>>> "John" == John Machin <[EMAIL PROTECTED]> writes: John> For windows users, apart from cygwin, there are a couple of John> sources of binaries for *x command-line utilities (unxutils, John> gnuwin32). unxutils is my personal favourite - cygwin is way too much an "environment", and gets broken too easily. I for one would like to see various shell tools implemented in pure python, if only to be able to import them as a module and use cross platform tools that have more power than e.g. 'shutil' or 'os' functions. The API exposed through the module (as opposed to normal execution from shell) could also be much richer, providing hooks for calling own stuff for just-in-time error handling, progress notification etc. So no, it doesn't seem like bad idea at all. It's also something that could evolve gradually, and reach a useful stage (i.e. have several handy tools) quickly. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Thoughts on Guido's ITC audio interview
>>>>> "Timothy" == Delaney, Timothy (Tim) <[EMAIL PROTECTED]> writes: Timothy> Absolutely. I've really tried to use Eclipse - it's the Timothy> standard editor for my current project (Java - blegh!). I Timothy> *hate* it. It's huge, bulky, slow ... I've gone back to Timothy> my text editor. I'm a hell of a lot more Have you tried the recently released 3.1 version? It seems to be a tad snappier than the old version. Timothy> The only IDE I've ever actually liked using was Timothy> Metrowerks CodeWarrior (on MacOS classic). Simple, Timothy> unobtrusive. Good project management, without trying to Timothy> control every aspect of the development process. And The debugger in CodeWarrior is quite crappy IMHO. Unlike visual studio, it doesn't show the return values of function calls. The editor is also quite lacking, without the ability to create macros etc. I agree about the project management part. Though I would still love to use Eclipse instead, if it only was supported for my line of work :-/. Timothy> it allowed me to use the entire screen for editing if I Timothy> wished whilst still having everything readily available. Eclipse allows this as well. ctrl+m is maximize/unmaximize. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Thoughts on Guido's ITC audio interview
>>>>> "Fabio" == Fabio Zadrozny <[EMAIL PROTECTED]> writes: >> I agree about the project management part. Though I would still love >> to use Eclipse instead, if it only was supported for my line of work >> :-/. Fabio> What line of work is not supported in eclipse? C++ programming for Symbian OS. Editing the C++ code works, debugging doesn't, at least yet. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
wxPython and window sizing
I have a small problem; I would like to have a reasonable minimum size for a wx.Window. A simplified version of my code: s = wx.SplitterWindow(self, -1) curves = wx.Notebook(s) curve = wx.Window(curves, ID_BLANKCURVE, style=wx.SUNKEN_BORDER, size=(300,200)) curves.AddPage(curve, "Blank") textbox = wx.TextCtrl(s, ID_TEXTBOX, style=wx.TE_MULTILINE, size=(-1,50)) s.SetMinimumPaneSize(50) s.SplitHorizontally(curves, textbox) s.SetSashGravity(0.8) Here 'self' is the main window class, i.e. inherited from wx.Frame. What I would like to happen is that both the curve area and the textbox would have an absolute minimum size when moving the sash or resizing the window. How to get this behaviour? I have tried setting the minimum sizes of the curve and the textbox by using the SetMinSize() method, but this does not seem to affect anything. Already when the window is shown the upper pane (i.e. the notebook curves) is smaller than (300,200) set in the code. TIA, - Ville -- Ville Voipio, Dr.Tech., M.Sc. (EE) -- http://mail.python.org/mailman/listinfo/python-list
Re: wxPython and window sizing
In article <[EMAIL PROTECTED]>, Franz GEIGER wrote: > Couldn't you register for a handler? Oui, mais... I can figure out a few ugly workarounds. However, my question is if there is a nice and clean way to make wxPython set the minimum size. I'd really hate to start calculating the sizes myself or making any extra handlers, if the existing infrastructure can handle what I want. - Ville -- Ville Voipio, Dr.Tech., M.Sc. (EE) -- http://mail.python.org/mailman/listinfo/python-list
Re: That horrible regexp idiom
>>>>> "Stephen" == Stephen Thorne <[EMAIL PROTECTED]> writes:
Stephen> We've all seen it before. Its a horrible idiom that you
Stephen> would achieve in another language by doing:
Stephen> if (m = foo_pattern.search(subject))
Stephen> { }
Stephen> else
Stephen> { }
Stephen> but it occured to me today, that it is possible to do it in python
Stephen> without the extra line.
Stephen> '
Stephen> '>>> def xsearch(pattern, subject):
Stephen> '>>> yield pattern.search(subject)
Stephen> '>>> for m in xsearch(foo_pattern, subject):
Stephen> '>>> pass
Stephen> '>>> else:
Stephen> '>>> pass
Stephen> simple, concise, requires no new syntax, and is only a
Stephen> little confusing[1]!
I'm always confused by for-else (lack of practice), but isn't the else
clause going to be always executed when there is no break in the for
suite?
--
Ville Vainio http://tinyurl.com/2prnb
--
http://mail.python.org/mailman/listinfo/python-list
Re: [ANN] IPython 0.6.11 is out.
Warning - if you are upgrading and have an old pysh.py dangling around in $HOME/.ipython, be sure to delete it. The old version is incompatible with the new ipython. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: [Fwd: Re: [Uuu-devel] languages] <-- Why Python
>>>>> "Arich" == Arich Chanachai <[EMAIL PROTECTED]> writes: Arich> From: "Richard Taytor" <[EMAIL PROTECTED]> Arich> To: <[EMAIL PROTECTED]> Arich> Sent: Thursday, February 17, 2005 4:28 PM Arich> Subject: [Uuu-devel] languages >> First, thank you for Unununium. I first learned of the project >> years ago and I'm happy to see it is alive and well. >> >> I'm curious: For the same reasons cited for using Python, why >> not use Lisp? I understand that Python is more >> popular/pervasive, but if reducing the cognitive load on the >> programmers, increasing the elegance and efficiency between >> programmer and code, &c., is of primary concern, Lisp (or as >> mentioned in the documentation, creating a new language) seems >> a better choice (as it appears to me). What do you think? Essentially this seems like advocacy material for Lisp (doesn't seem to address any UUU-specific issues, just claims that Lisp is "better" than Python), and should be treated as such. Go googling for heaps of Python vs. Lisp material. Go ahead and learn Lisp - I guess you'll quickly realize that perfectly rational people may well choose Python for reasons other than "not knowing Lisp". -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: [Fwd: Re: [Uuu-devel] languages] <-- Why Python
>>>>> "Donn" == Donn Cave <[EMAIL PROTECTED]> writes:
Donn> I don't know what the Windows version is like, but for all
Donn> the UNIX shell's weaknesses, it's very well suited to its
Donn> role. The Plan 9
I don't know about that - I don't see anything in shell that couldn't
be done better in Python (well, launching subshells perhaps, and the
smaller size == faster launch). The Windows incarnation is obviously
so horrible that it hardly deserves mention, but the scripts done with
unix shell also always have this "hackish" flavour.
(I'm aware that this is an unpopular opinion that is likely to collect
some flames, but some people never learn ;-).
Donn> shell (rc) is similar with much improved syntax, and has a
Donn> distant relative "es" that I think is the closest thing I've
Donn> ever seen to a 1st class language that works as a shell
I assume you've tried IPython ('ipython -p pysh')? I just apt-getted
es and it seems to be like ipython, only for scheme.
Donn> Well, honestly I think that's stretching it. Your order
Donn> issue here seems to apply only to operators, and they don't
Donn> really figure that heavily in the kinds of things we
Donn> normally do with the OS. The only
I think they do - summing sets of files, adding extensions to
filenames, etc.
Donn> Now, we Python users know very well that's not true, Python's as clear
Donn> as could be. But theoretically, if you wanted to talk about order
Donn> issues, for example ... is it really easier to understand when a
language
Donn> sometimes expresses a function f over x and y this way
Donn> f(x, y)
Donn> sometimes this way (+ is a function, really)
Donn> x f y
Donn> and sometimes this way
Donn> x.f(y)
Donn> ?
Yes - operators like + and - are very intuitive to everybody. Having
only one way to call functions is more orthogonal and "cleaner" in a
theoretical sense, but noi in practical sense.
Donn> I don't know, I'm just thinking that while Python's notation
Donn> might be just fine for people who've gotten here the way
Donn> most of us have, it's not obvious from this that it's just
Donn> fine 4 everyone.
Perhaps not for everyone but for the majority I guess the python
notation would be more suitable.
--
Ville Vainio http://tinyurl.com/2prnb
--
http://mail.python.org/mailman/listinfo/python-list
Re: [Fwd: Re: [Uuu-devel] languages] <-- Why Python
>>>>> "Mike" == Mike Meyer <[EMAIL PROTECTED]> writes: Mike> IPython's pysh seems a little clumsy for interactive use, as Mike> it requires special characters to distinguish between Mike> commands to be passed to the shell and commands to be passed Mike> to the scripting language. This should be contrasted with What do you mean by "the commands to be passed to the shell"? Commands on the path (the normal situation in Unix) can be executed directly just like in bash et al. Ditto for "magic" functions if "automagic" is on. I only use ! for calling commands that are in the current directory. A *real* deficiency with ipython/pysh under Linux is the lack of job control (in the sense that ^z suspends the whole ipython). I don't see why pysh would not be able to match and exceed the capabilities of shell in job control as well. It's not a priority for fperez himself ATM, but we'll see how easy it is to add shellish job control in the future after the refactoring... Mike> I'll say it again - if you're arguing about which language Mike> to use, you're arguing about the wrong thing. In a sense C is the native language of Unix and Windows (system calls are in C). It might make sense to expose the OS as Python objects. I work w/ Symbian OS in my day job, with the OS API in C++. I'm not sure whether it's a good idea or not, but at least some people are doing it :). -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: [Fwd: Re: [Uuu-devel] languages] <-- Why Python
>>>>> "Mike" == Mike Meyer <[EMAIL PROTECTED]> writes: Mike> I've actually done some work on using CORBA as a COM for Mike> Unix (or, as I think of it, an ARexx for Unix). After being Mike> exposed to Plan 9, I've decided that's a better Mike> solution. CORBA has the advantage that you can work on it Mike> without getting buy-in from kernel vendors. The problem w/ CORBA is the alleged lack of speed. ISTR there was lots of controversy w/ the way Gnome used CORBA (Bonobo) and how it was too slow for Desktop apps. I don't know what the current status is - CORBA has always seemed more than fast enough for me. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Attaching to a Python Interpreter a la Tcl
>>>>> "fuzzyman" == Fuzzyman <[EMAIL PROTECTED]> writes: fuzzyman> Do you mean making the interpreter available from within fuzzyman> a Python app ? There are various ways of doing that - fuzzyman> you can see the SPE editor which uses pycrust as one fuzzyman> example. http://spe.pycs.net I believe he means embedding he interpreter in his app, then accessing the interpreter from another process - so you could change and view global vars of the running process from the interpreter, for example. This basically means redirecting i/o of the interpreter to a socket to which you connect via, say, telnet. There are libs that do such a thing, I even remember trying one out myself, but I couldn't find it quickly enough from google. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Best IDe
>>>>> "Jaime" == Jaime Wyant <[EMAIL PROTECTED]> writes: Jaime> What wing does have going for it is a REALLY good Jaime> auto-completion system. Yeah it's slow, but its good. You Jaime> wing hints as to what objects are by using isinstance(). Jaime> For example, the code below tells wing that frame is a Jaime> wx.Frame -> Jaime> # make_frame returns a wx.Frame Jaime> frame = make_frame() Jaime> isinstance(frame, wx.Frame) Jaime> Once wing has a hint, it'll autocomplete the methods / Jaime> properties for you. But again, it is slow. Other IDEs, please take the hint. That should be trivial to implement once you have basic autocompletion system in place (e.g. SPE). That still leads to code clutter but it will do until someone implements a proper type inference system... Of course it should also heed the isinstance line when it's commented out. Jaime> As far as free software goes, I really like stani's python Jaime> editor. It seems to *watch* methods that you call on an Jaime> object and autocomplete based on that. For example suppose Yeah, SPE seems to be quite a solid offering - but pydev (the Eclipse plugin) seems to be getting there really fast also. It also has a debugger that SPE lacks. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: wanted: C++ parser written in Python
>>>>> "Franz" == Franz Steinhaeusler <[EMAIL PROTECTED]> writes: Franz> Thank you, but it is too big. Franz> Anyway: Franz> I'm looking for some (simple) "rules" to parse (regex) and Franz> try to implement myself, if nothing is available. Check out http://pyparsing.sourceforge.net/ Before you start implementing one yourself. Regexp solution would probably be a bit flakier. And do share your results when you get some; I'm in need of a c++ parser myself. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Wishlist item: itertools.flatten
For quick-and-dirty stuff, it's often convenient to flatten a sequence (which perl does, surprise surprise, by default): [1,2,[3,"hello",[[4 -> [1, 2, 3, 'hello', 4] One such implementation is at http://aspn.activestate.com/ASPN/Mail/Message/python-tutor/2302348 but something like this would be handy in itertools as well. It seems trivial, but I managed to screw up several times when trying to produce my own implementation (infinite recursion). -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Wishlist item: itertools.flatten
>>>>> "Christos" == TZOTZIOY writes: >> For quick-and-dirty stuff, it's often convenient to flatten a sequence >> (which perl does, surprise surprise, by default): >> >> [1,2,[3,"hello",[[4 -> >> >> [1, 2, 3, 'hello', 4] Christos> See Python Library Reference, "5.16.3 Recipes". Now Christos> that all and any (also The recipe is: def flatten(listOfLists): return list(chain(*listOfLists)) That one is trivial, because it only flattens one level. The flattening I'm talking about involves flattening to arbitrary depth to get a single sequence of "atoms". The itertools implementation might also be able to avoid recursion by using a stack. Christos> This is just a personal opinion, but I detest restraints Christos> on library (itertools module in this case) expansion Christos> when talking about such useful *building blocks*. Yeah - esp. in the case of flattening. If it was deemed useful enough to be the default behavior in perl (which is admittedly braindamaged), it should surely warrant being included as a single function in the stdlib. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Licensing Python code under the Python license
>>>>> "Daniel" == Daniel Keep <[EMAIL PROTECTED]> writes: Daniel> Thanks for the advice. I'll probably go with either the Daniel> BSD license, or possibly the LGPL. But I'm leaning Daniel> towards the BSD since it fits on the screen... Isn't MIT license even shorter and simpler? A while ago some Debian guys were speculating whether even BSD license is "free enough" to include in Debian... -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Wishlist item: itertools.flatten
>>>>> "Michael" == Michael Spencer <[EMAIL PROTECTED]> writes: Michael> Here's a non-recursive implementation. Thanks. Michael> There are lots around. Yet another fact that suggest the inclusion in stdlib would make sense ;-). -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Itertools wishlists
>>>>> "Raymond" == Raymond Hettinger <[EMAIL PROTECTED]> writes: Raymond> Each one of the options listed is a reason that flatten() Raymond> shouldn't be an itertool. It fails tests of obviousness, Raymond> learnability, complexity of implementation, and Raymond> simplicity of API. The options also suggest that the Raymond> abstraction is not as basic or universal as we would Raymond> hope. A simpler API: def flatten(sequence, atomic_test = lambda o: isinstance(o,basestring)): """ don't recurse into iterables if atomic_test -> True """ I believe speaking of the "levels" of flattening is contorted here. Raymond> Perhaps "require" was the wrong word. The issue is that Raymond> appear to be very few real situations where flatten() Raymond> would be the tool of choice. Suppose that I get a very complex data structure involving lists of tuples of tuples [] of strings. I just want to quickly search the sequence for valid file names, without going through elaborate unpacking. Then I just do files = (f fof f in flatten(monster_data_struct) if os.path.isfile(str(f))) Yep, this is a real use case (ipython + some of my own data munging tools). Raymond> Generalizing the two results, it may be fair to say that Raymond> the desire to flatten is a code smell indicating that Raymond> structure is being unnecessarily destroyed or that Raymond> earlier processing introduced unwanted structure. Let Raymond> the data guide the programming. You are looking the problem from a specific mindset, that of writing good clean pythonic code. flatten is for situations when you need an implementation 20 seconds ago (where someone might have recommended perl in the past, and which is a perfectly valid niche for Python as well). It's not a matter of life & death for me, obviously (it's in my own stdlib). I still can't see how its existence would make rest of itertools magically harder to learn. When I come up with a problem where I imagine itertools might come in handy, I check the docs to see whether there is anything appropriate for the problem. I don't memorize all the functions, just the fact that such functions exist. Also, the following itertool functions are not very useful anymore, with the advent of genexps: ifilter(pred, seq) --> elements of seq where pred(elem) is True ifilterfalse(pred, seq) --> elements of seq where pred(elem) is False imap(fun, p, q, ...) --> fun(p0, q0), fun(p1, q1), ... starmap(fun, seq) --> fun(*seq[0]), fun(*seq[1]), ... I don't believe a genuinely useful 'flatten' would increase the cognitive load any more than these. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Itertools wishlists
>>>>> "Steven" == Steven Bethard <[EMAIL PROTECTED]> writes: Steven> complex atomicity test). I also have the feeling that any Steven> complicated atomictiy test is more than a simple and-ing Steven> of several tests... I also have the feeling that if the atomicity criterion was any more complex in the API, the proposal would be shot down immediately on the grounds of not being fundamental enough as concept. -- Ville Vainio http://tinyurl.com/2prnbOB -- http://mail.python.org/mailman/listinfo/python-list
Re: Itertools wishlists
>>>>> "Raymond" == Raymond Hettinger <[EMAIL PROTECTED]> writes: Steven> complex atomicity test). I also have the feeling that any Steven> complicated atomictiy test is more than a simple and-ing Steven> of several tests... Raymond> "Ville Vainio" >> I also have the feeling that if the atomicity criterion was any >> more complex in the API, the proposal would be shot down >> immediately on the grounds of not being fundamental enough as >> concept. Raymond> Would this meet your needs? Raymond> def flatten(iterable, atomic_iterable_types=(basestring,)): Yes, completely. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Python becoming less Lisp-like
>>>>> "Tim" == Tim Daneliuk <[EMAIL PROTECTED]> writes: Tim> Except that in this case, removal will also complicate code Tim> in some cases. Consider this fragment of Tkinter logic: Tim> UI.CmdBtn.menu.add_command(label="MyLabel", Tim> command=lambda cmd=cmdkey: CommandMenuSelection(cmd)) Tim> Would it not be the case that, without lambda, we will need Tim> to pollute the name space with a bunch of specialized little Tim> functions for each and every construct like this? You can reuse the same name for all those little functions to avoid polluting the namespace. Choose 'L' if it gives you that cozy lambda-ish feel. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Python becoming less Lisp-like
>>>>> "Torsten" == Torsten Bronger <[EMAIL PROTECTED]> writes: >>> There would be keywords for static and class methods, no >>> distinction between Unicode and non-Unicode >> You couldn't do that 15 years ago because there were no Unicode >> that time. Torsten> I've never said that Guido was just too stupid at that Torsten> time. I only said "but you can definitely see that it's Torsten> the oldest one". In other words, a Ruby six years older Torsten> than the real one would have the same problem. And who Torsten> knows how C# looks like in 10 years. http://c2.com/cgi/wiki?PythonVsRuby seems to suggest that Python has better Unicode support than Ruby. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Lisp-likeness
>>>>> "Michele" == michele simionato <[EMAIL PROTECTED]> writes: Michele> But then why he agreed to have the loop variable Michele> disappear outside a generator comprehension? I think Michele> there is something more than a backward compatibility Michele> concern. With normal for-loop (as opposed to genexps and LCs), the "last" value of the loop variable might be useful outside the loop if the loop was exited prematurely through 'break' statement or exception. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Is Python like VB?
>>>>> "Cappy" == Cappy2112 <[EMAIL PROTECTED]> writes: Cappy> VB has a much better IDE than the IDE's for Python, Cappy> although Eric3 is one of the best, and is absolutely free. Eric3 is not easily available for win32, due to current state of Qt licensing (will change with Qt4 I think). Cappy> There are many gui toolkits/frameworks for Python, but the Cappy> foreunners are pyQT, wxPython, pyGTK, and TK/Tkinter. On windows it might make sense to choose wxPython, though I've heard some good stuff about new versions of pyGTK as well. People coming from VB background probably also appreciate the ability to draw the UI in point&click style: http://gazpacho.sicem.biz/ http://wxglade.sourceforge.net/ Unfortunately these seem to still be a tad rough around the edges... -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Python becoming less Lisp-like
>>>>> "Mike" == Mike Meyer <[EMAIL PROTECTED]> writes: Mike> The real problem is that newbies won't know which features Mike> are "meta" features best left to experts, and which features Mike> are ok for everyday programmers to use. I suppose that a typical lazy newbie will just skip metaclasses and descriptors on the grounds of not understanding them immediately. It's the 'quest of guruhood' phase when novices start browsing wikis and obscure python-dev discussions to find out how these things work. All the documentation I've seen regarding these features mentions that the user probably doesn't need to know about them; this is especially true for metaclasses. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: I can do it in sed...
>>>>> "Damjan" == Damjan <[EMAIL PROTECTED]> writes:
Damjan> Or, much nicer
>> if line[:5]=='start': printing=1
Damjan> if line.startswith('start'): printing=1
>> if line[:3]=='end': printing=0
Damjan> if line.endswith('end'): printing=0
No, it's still line.startswith('end'), not endswith.
--
Ville Vainio http://tinyurl.com/2prnb
--
http://mail.python.org/mailman/listinfo/python-list
Re: I can do it in sed...
>>>>> "John" == John Machin <[EMAIL PROTECTED]> writes: John> You can get gnu Windows versions of awk sed and most other John> suchlike goodies off the net ... Yeah, google for 'unxutils'. Cygwin versions of these tools can be a headache sometimes. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
REPOST: Re: Python becoming less Lisp-like
>>>>> "Tim" == Tim Daneliuk <[EMAIL PROTECTED]> writes: Tim> Except that in this case, removal will also complicate code Tim> in some cases. Consider this fragment of Tkinter logic: Tim> UI.CmdBtn.menu.add_command(label="MyLabel", Tim> command=lambda cmd=cmdkey: CommandMenuSelection(cmd)) Tim> Would it not be the case that, without lambda, we will need Tim> to pollute the name space with a bunch of specialized little Tim> functions for each and every construct like this? You can reuse the same name for all those little functions to avoid polluting the namespace. Choose 'L' if it gives you that cozy lambda-ish feel. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
REPOST: Re: Python becoming less Lisp-like
>>>>> "Torsten" == Torsten Bronger <[EMAIL PROTECTED]> writes: >>> There would be keywords for static and class methods, no >>> distinction between Unicode and non-Unicode >> You couldn't do that 15 years ago because there were no Unicode >> that time. Torsten> I've never said that Guido was just too stupid at that Torsten> time. I only said "but you can definitely see that it's Torsten> the oldest one". In other words, a Ruby six years older Torsten> than the real one would have the same problem. And who Torsten> knows how C# looks like in 10 years. http://c2.com/cgi/wiki?PythonVsRuby seems to suggest that Python has better Unicode support than Ruby. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Interface support?
>>>>> "Michael" == Michael Spencer <[EMAIL PROTECTED]> writes: Michael> Steve wrote: >> Is it possible to design interfaces that classes must implement >> in Python? Michael> PyProtocols: http://peak.telecommunity.com/PyProtocols.html, This (PyProtocols) seems to be the one with biggest momentum at the time being, so if you can't be bothered to perform an independent and balanced evaluation, go for PyProtocols :-). -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: UML and OO design tool with Python support
>>>>> "Paul" == Paul McGuire <[EMAIL PROTECTED]> writes: Paul> I just found out that my favorite UML modeling tool, Paul> Enterprise Architect, has just released a new version, Paul> *with* Python code support. You can ... Somewhat tangentially, but still on-topic for the subject line, the other day I was delighted to see that Dia (installable for the Linux Disto near you, and also available for Windows) has Python embedded into the program. Or at least you can choose "Python console" that throws you into an interactive Python session where you can go dir() - ing around to see all kinds of interesting diagram stuff. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Python on Nokia Phones ?
>>>>> "Mark" == Mark Doukidis <[EMAIL PROTECTED]> writes: Mark> An exciting prospect when I first heard of Nokia's proposal. Mark> I thought there would be a few more postings here since the Mark> idea first surfaced around Jan 2004. Do realize that giants like Nokia move slow and make a minimum amount of noise about what they are doing. They (Nokia) seemed pretty excited about the prospects back in the June workshop: http://www.forum.nokia.com/main/0,,4_22,00.html I think I'll try to check out whether they have come up with a new version. There are lots of changes happening with S60 / Symbian OS in general ATM, so I wouldn't be surprised if they chose to delay Python a little bit, at least as far as shipping it with the phones goes. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Semaphore or what should I use?
>>>>> "Bastian" == Bastian Hammer <[EMAIL PROTECTED]> writes: Bastian> Now I have to make sure, that both threads are Bastian> synchronal, 1 thread edits something and the other is Bastian> blocked until the first thread is ready. Bastian> Isn´t it a good idea to do this with a semaphore? Semaphore will do, but this is a classical use case for threading.Lock. There should be lots of stuff regarding locks (or more googleably, "mutexes") on the net. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Semaphore or what should I use?
>>>>> "Sergei" == Sergei Organov <[EMAIL PROTECTED]> writes: Sergei> My answer to OP's question is: use either lock (mutex) or Sergei> semaphore. I'd probably use semaphore as mutexes are Sergei> usually optimized for the case when contention probability Sergei> is low (i.e., they usually shouldn't be locked for a long Sergei> time). Both Mutexes and Semaphores put the thread to sleep, so I don't think there will be a big difference. The OP might also want to check out read/write lock. The first thing google finds is http://www.majid.info/mylos/weblog/2004/11/04-1.html -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Boo who? (was Re: newbie question)
>>>>> "Doug" == Doug Holton <[EMAIL PROTECTED]> writes: Doug> I already stated that I will not mention boo again, to Doug> comply with Fredrik's wishes and yours. I will refer to Relax, and go ahead talking about Boo all you want. I for one enjoy reading about it, and probably many others as well. Some people may bitch about it, but, well, that's what people do on usenet. Doug> only. But I will not be intimidated by the likes of Fredrik Doug> Lundh. Trollers will be held accountable. If it continues As mentioned elsewhere it's technically not trolling, but rather old fashioned flaming. Usenet is free-for-all, so people can expect to be flamed occasionally, often without good reason. It's quite rare in c.l.py but it happens. Often all you can do is to swallow it, unless the person in question just lost their temper for a moment and is willing to apologize. That is not not always the case. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Python for Series 60 update
Python for S60 seems to be available for the grand public as of today. Check out http://www.forum.nokia.com/main/0,,034-821,00.html Yes, this is good news :-). -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Optional Static Typing
>>>>> "Alex" == Alex Martelli <[EMAIL PROTECTED]> writes: Alex> I've always liked the (theoretical) idea that assertions Alex> (including of course contracts) could be used as axioms used Alex> to optimize generated code, rather than (necessarily) as a Alex> runtime burden. E.g. (and I don't know of any Alex> implementation of this concept, mind you), inferring (e.g. Alex> from such assertions) that x>=0, and that y<0, the compiler Alex> could simply cut away a branch of dead code guarded by "if Alex> x y if x < y: blah(y,x) needs a slap on the wrists anyway. Doing "if x < y" in blah() would make sense, but then there would need to be a special version of blah()... I could think of one worthwhile example as well: def foo(l): assert issorted(l) if "hi" in l: # in does a bsearch because the list is sorted blah() but things like this probably belong to languages like Lisp where the user gets to expand and mess with the compiler. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Optional Static Typing
>>>>> "Ryan" == Ryan Paul <[EMAIL PROTECTED]> writes: Ryan> I wrote a blog post this morning in which I briefly argue Ryan> using DbC and predicate based argument constraints instead Ryan> of static typing. Take a look I took a look. The first impression is that there is too much stuff to be added to the language, for a relatively unproven methodology (DbC). Yes, observe the herecy in my argument; I'm indeed referring to DbC as being an unproven way to write software. Eiffel never really made it, and explicit preconditions/postconditions haven't really appeared in other languages either. I'm not sure I'd like to see Python (which is not an academic language) take the risk of bloating the language definition with it. Let Ruby, or Boo, or whatever have a go before Python. And yes, I've read my OOSC, and my code has its share of asserts. Type declarations, on the other hand, are as mainstream as one can get. Being optional, they would not brutally murder the spirit of all the good that is Python, contrary to the doom and gloom people have been painting here and elsewhere. The implementation of CPython would become more complex, but I trust the people that are implementing it enough to not be overly concerned. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: IronPython 0.7 released!
>>>>> "fphsml" == James <[EMAIL PROTECTED]> writes: fphsml> http://www.gotdotnet.com/workspaces/workspace.aspx?id=ad7acff7-ab1e-4bcb-99c0-57ac5a3a9742 Apparently they are also going to put out a release every 2 weeks until 1.0 is out. Great news for those who were afraid the project is dead due to silence... -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: IronPython 0.7 released!
>>>>> "Robin" == Robin Becker <[EMAIL PROTECTED]> writes: Robin> well that's nice, but I don't do blogs and certainly don't You don't need to "do" much - just go to planetpython.org -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Suggestions for a Java programmer
>>>>> "bruno" == bruno modulix <[EMAIL PROTECTED]> writes: bruno> These two books should help you to get a grasp of Pythonic idioms: ... Regarding a Java programmer moving to Python, a lot of the mindset change is about the abundant use of built in data types of Python. So a Java programmer, when confronted with a problem, should think "how can I solve this using lists, dicts and tuples?" (and perhaps also my new favourite, sets). Class-based solution should be chosen only after seeing that the problem can't be trivially solved with built-in types. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Python for a 10-14 years old?
>>>>> "Christos" == TZOTZIOY writes: Christos> (first hw upgrade I ever did!), and one year and a half Christos> later, I managed to get the Sinclair QL, with better Christos> BASIC, multitasking capabilities, and something more Christos> like an OS than any other home computer till then. And Christos> man, wasn't 68k assembly a joy :) Linus Torvalds also bought Sinclair Ql back in the day - I was quite surprised to find out that it had a 32bit CPU (according to his autobiography). -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Python for a 10-14 years old?
>>>>> "Bengt" == Bengt Richter <[EMAIL PROTECTED]> writes: Bengt> Or they may identify with their gift and become Bengt> insufferable narcissistic egotists as a refuge from human Bengt> isolation and emotional starvation. Bengt> Or they may become wonderful human beings after all, happy Bengt> stewards of what becomes a gift to humanity, not just an Bengt> advantage to exploit meanly. Or they may determine to be exactly what they feel like being at the moment, independent of what their parents or the surrounding world feel they should be. (urgh, way too serious to be pythonic, but it's 5:14am here) -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: itertools to iter transition (WAS: Pre-PEP: Dictionary accumulator methods)
>>>>> "Raymond" == Raymond Hettinger <[EMAIL PROTECTED]> writes: Raymond> If the experience works out, then all you're left with is Raymond> the trivial matter of convincing Guido that function Raymond> attributes are a sure cure for the burden of typing Raymond> import statements. For one thing, it would make it harder to find the functions from the docs. It's easy to find the doc for 'itertools', but iter object methods would require browsing that infamous Chapter 2 of the documentation... Apart from that, I don't really see the advantage in moving away from itertools. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Why tuple with one item is no tuple
>>>>> "Antoon" == Antoon Pardon <[EMAIL PROTECTED]> writes:
Antoon> Op 2005-03-27, Joal Heagney schreef <[EMAIL PROTECTED]>:
>> Antoon Pardon wrote:
>>
>>> So python choose a non-deterministic direction. To me (2,3) + (4,5)
>>> equals (6,8). I don't dispute that having an operator to combine
>>> (2,3) and (4,5) in (2,3,4,5) is usefull, but they should never have
>>> used the "+" for that.
>>
>> ("alph", "bravo") + ("delta", "max") --> ("alphdelta", "bravomax")
Antoon> No, that wouldn't be the result. You are still using "+"
Antoon> for concatenation, even if only on strings. I say python
Antoon> should have used something else for concatenation (string
Antoon> concatenation included)
To me, nothing is more natural than "ab" + "cd" == "abcd". Also [1,2]
+ [3,4] == [1,2,3,4]. "Dot product" is not really too useful in real
world (non-mathematical) apps.
--
Ville Vainio http://tinyurl.com/2prnb
--
http://mail.python.org/mailman/listinfo/python-list
Re: Why tuple with one item is no tuple
>>>>> "Ville" == Ville Vainio <[EMAIL PROTECTED]> writes: Ville> To me, nothing is more natural than "ab" + "cd" == Ville> "abcd". Also [1,2] + [3,4] == [1,2,3,4]. "Dot product" is Ville> not really too useful in real world (non-mathematical) Ville> apps. ... and of course by "dot product", I don't mean dot product at all. I was thinking of summing vectors, which is not that much more common either. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: itertools to iter transition (WAS: Pre-PEP: Dictionary accumulator methods)
>>>>> "Steven" == Steven Bethard <[EMAIL PROTECTED]> writes: Steven> to be documented as a builtin type. I don't find the Steven> argument "builtin type methods are hard to find" Steven> convincing -- the solution here is to fix the Steven> documentation, not refuse to add builtin types. Yep - that's why we should perhaps fix the documentation first :-). Steven> I guess the real questions are[1]: Steven> * How much does iter feel like a type? Guess this depends on the person. I've never thought of it as a type. It's too fundamental a concept to coerce into a type, even thought protocol == type in a sense. Steven> [1] There's also the question of how much you believe in Steven> OO tenets like "functions closely associated with a type Steven> should be members of that type"... The issue that really bothers me here is bloating the builtin space. We already have an uncomfortable amount of builtin functions. Of course the additions that have been suggested would not pollute the builtin namespace, but they would still be there, taking space. I'd rather see a more modular and 'slimmer' Python, what with the advent of Python for S60 and other embedded uses. Perhaps what you need is 'from usefulstuff import *', with usefulstuff having os, sys, 'itertools as it', &c. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: itertools to iter transition (WAS: Pre-PEP: Dictionary accumulator methods)
>>>>> "Steven" == Steven Bethard <[EMAIL PROTECTED]> writes: Steven> Certainly a valid point. How would you feel about adding Steven> just a select few itertools functions, perhaps just Steven> islice, chain and tee? A minimal set would not be that offensive, yes. But then we would have two places to look for itertools functionality, which may not be desirable. One thing that might be worth keeping in mind is that some of itertools functionality is going to become obsolete come py3k (izip->zip), and some is already (imap). At least such operations should not be dumped into the builtin iter. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Case-insensitive dict, non-destructive, fast, anyone?
I need a dict (well, it would be optimal anyway) class that stores the
keys as strings without coercing the case to upper or lower, but still
provides fast lookup (i.e. uses hash table).
>> d = CiDict([('Hi', 12),('hoho',13)])
>> d['hi']
12
>> d.keys()
['Hi','hoho']
Note that 'Hi' preserved the case. I imagine that 'Hi' and 'hi' would
need to share the same hash value in order for the lookup to be fast.
Anyone have a an implementation that I could use? Quick googling only
produced implementations that coerce all keys to lowercase.
--
Ville Vainio http://tinyurl.com/2prnb
--
http://mail.python.org/mailman/listinfo/python-list
Re: Case-insensitive dict, non-destructive, fast, anyone?
>>>>> "Daniel" == Daniel Dittmar <[EMAIL PROTECTED]> writes: Daniel> Ville Vainio wrote: >> I need a dict (well, it would be optimal anyway) class that >> stores the keys as strings without coercing the case to upper >> or lower, but still provides fast lookup (i.e. uses hash >> table). Daniel> Store the original key together with the value and use a Daniel> lowercase key for lookup. That's what I thought initially, but the strings take most of the space in dict and I didn't feel like doubling the size. It would be the "simplest thing that could possibly work", though. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Case-insensitive dict, non-destructive, fast, anyone?
>>>>> "Bengt" == Bengt Richter <[EMAIL PROTECTED]> writes: Bengt> I wonder if a dict with a general override hook for hashing Bengt> all keys would be useful. E.g., a dict.__keyhash__ that Bengt> would take key as arg and default as now returning Bengt> key.__hash__() but that you could override. Seems like this There would need to be an override hook for key comparison as well (I suppose it always uses == operation now?). But yes, I think it would be *much* more useful than any 'keytransform' feature - is there any use for 'keytransform' feature apart from the uses that would be better covered by hash/comparison hooks? It would be lovely to have something like this in the stdlib (or anywhere, for that matter). Think about the use cases for hashing via by os.path.normcase, str.lower... -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: boring the reader to death (wasRe: Lambda: the Ultimate Design Flaw
>>>>> "Sunnan" == Sunnan <[EMAIL PROTECTED]> writes:
Sunnan> It's just that I'm having a hard time matching that quote
Sunnan> to what I though python was about. I thought boring code
Sunnan> was considered a virtue in python. ("Explicit is better
Sunnan> than implicit", "sparse is better than dense".)
Boring code is code that numbs your senses with constant flow of
boilerplate crap, memory management and redundant type declarations
and general blah blah that you skip when you are trying to figure out
what a piece of code does. It's a code that you wish you could train a
monkey to write for you while you go for lunch. Think C++ or Java.
--
Ville Vainio http://tinyurl.com/2prnb
--
http://mail.python.org/mailman/listinfo/python-list
Re: boring the reader to death (wasRe: Lambda: the Ultimate DesignFlaw
>>>>> "Sunnan" == Sunnan <[EMAIL PROTECTED]> writes: Sunnan> languages". I'm not sure whether I'd consider python Sunnan> particularly terse, though, but I don't know enough about Sunnan> it yet. (I've read a Read up on list comprehensions and generator expressions. You'll see the terse side of Python (and genexps look kinda poetic too ;-). -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Best editor?
>>>>> "Miki" == Miki Tebeka <[EMAIL PROTECTED]> writes: Miki> Emacs (or VIm in my case) takes time to learn. However when Miki> you start to understand it and know you way around it'll do Miki> things no other editor will do for you. Other editors also do stuff Emacs won't do. Code completion is a killer feature and emacs sucks at it (yes, w/ Cedet too). Emacs is pretty good for Python if you can't wait for something like Eclipse+pydev to start (which is a good choice, and worth learning). Emacs is not necessarily worth learning unless you are an emacs user already. Emacs also looks so horrible in Linux that I tend to go for Kate when I'm at home. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: boring the reader to death (wasRe: Lambda: the Ultimate Design Flaw
>>>>> "Sunnan" == Sunnan <[EMAIL PROTECTED]> writes: Sunnan> Ville Vainio wrote: Sunnan> Also, Guido recently urged people to explicitly write Sunnan> recursions rather than to use reduce - which I thought was Sunnan> completely in line with what I've seen as python's goals: Sunnan> readability/understandability as more important than Sunnan> terseness/non-boringness. The problem w/ reduce is that it's not intuitive. You'll have to stop to think what the code w/ reduce does - effectively converting it to a normal loop (not recursion!) in your head. It's a net loss when you compare it to just reading an explicit loop as written in code. Sunnan> Yesterday, I read some marketing prop describing a Sunnan> proprietary IDE (don't remember what language) as Sunnan> "exciting", and I went "Ugh, no thanks! Give me calm Sunnan> computing." And then I thought - wait: I just ranted about Sunnan> boringness on comp.lang.python. Can't boring and calm Sunnan> sometimes mean the same thing? Not for me at least. 'Boring' implies a certain sense of frustration, not getting anywhere and generally feeling like you are wasting your time. Human attention is a limited resource, and being bored leads to loss of attention. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Best editor?
>>>>> "caneff" == ChinStrap <[EMAIL PROTECTED]> writes: caneff> Anyone want to send me a configuration setup with Python caneff> in mind, and decent colors? http://www.emacswiki.org/cgi-bin/wiki/ColorTheme -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Best editor?
>>>>> "jjl" == John J Lee <[EMAIL PROTECTED]> writes: >> Other editors also do stuff Emacs won't do. Code completion is a >> killer feature and emacs sucks at it (yes, w/ Cedet too). jjl> I thought that too, but then I bound dabbrev-expand to F4, jjl> and it seems even better than 'proper' completion (for jjl> reducing keystrokes, anyway). But does not work when you don't know/can't recall what methods are available for the object you are looking at. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: IPython - problem with using US international keyboard input scheme on W2K
>>>>> "Claudio" == Claudio Grondi <[EMAIL PROTECTED]> writes: Claudio> Is it already known, that after switching the keyboard Claudio> input scheme on German Windows 2000 to english USA Claudio> International IPython generates \x00" instead of " when Claudio> trying to input quotation marks? This has been reported previously - apparently it's a problem with Gary's readline module (or however it was called ;-), and hacking it solved the problem for someone. I suggest you search the ipython mailing list archives, or post this question there. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Programming Language for Systems Administrator
>>>>> "Sizer" == Sizer <[EMAIL PROTECTED]> writes: Sizer> Looking at my followup, I really didn't make it clear that Sizer> you'll have to learn some bash scripting to be an effective Sizer> *nix administrator, just because so many parts of the Sizer> system use bash scripting. But python is much nicer to Sizer> write anything non-trivial in. If you don't need to edit already existing system scripts, you don't really need to know bash scripting. For debugging purposes, it's easy to see what commands the script executes to perform a task. You just need to know about `backticks` and $ENV_VARS, but that's more general Unix knowledge than actual shell scripting. So IMHO learning bash scripting might be a waste of time, and it should be learnt 'as you go' - i.e. if/when you eventually bump into a problem where you need to be able to do bash scripting. There's the 'Unix romantic' movement that still thinks shell scripts are a good idea, but this is my .02EUR to point out that not everyone agrees with them. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: IPython - problem with using US international keyboard input scheme on W2K
>>>>> "Claudio" == Claudio Grondi <[EMAIL PROTECTED]> writes: Claudio> Considering what I found in the ipython mailing archives Claudio> and the fact, that after the fix with displaying colors Claudio> on bright backgrounds Gary had no time yet to get in Claudio> touch with me about the code I have sent him, I suppose, Claudio> that there will be no new releases addressing this Claudio> problem soon, right? No idea. There have been multiple complaints about the issue (and functional patches to fix the problem), so I wouldn't be surprised if this issue was solved quickly enough. Claudio> lazy at the moment, because instead of trying to fix it Claudio> just switched back to Idle ... Don't get too lazy, you're not alone with this problem. I get a beep every time I try to type a scandinavian character (ÃÃ) on ipython console, luckily I never have to do that :-). -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
win32 readline maintenance (was Re: IPython - problem with...
>>>>> "Fernando" == Fernando Perez <[EMAIL PROTECTED]> writes: Fernando> Bummer. I wonder, if the changes are minor and easy, Fernando> perhaps you (or someone else) could offer Gary to take Fernando> over maintenance of readline/win32? It sounds Someone on the ipython mailing list already had patches for it - I think it was for Belgian keyboards. She didn't submit the patches, just asked whether she should submit them. Fernando> like he is perhaps too busy to keep up with the patches Fernando> and improvements, so perhaps it's time for someone else Fernando> to take over? That kind of library, while Optimally, something like this should be in the pywin32 package. I suppose it could be hosted at scipy if someone was to take over the maintenance? It's open source, so the maintenance doesn't need to be "transferred" - just put up version control somewhere and we'll see what happens :-). In the meantime I would suggest win32 users to do as I do and use a different keyboard layout. US layout is better for programming anyway and you learn it in a day or two. Settings->Control Panel->Regional Options->Input Locales. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Programming Language for Systems Administrator
>>>>> "beliavsky" == beliavsky <[EMAIL PROTECTED]> writes: beliavsky> The key difference between the Unix approach and the beliavsky> MSH one is that rather than creating a "pipeline" based beliavsky> on textual input and output, MSH passes data between beliavsky> the various commandlets as arbitrary objects. They clearly read my rant from last summer http://groups.google.com/groups?threadm=du7brj2mpg9.fsf%40mozart.cc.tut.fi ;-) -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Programming Language for Systems Administrator
>>>>> "zsolt" == pythonUser 07 <[EMAIL PROTECTED]> writes: zsolt> Python is great, but having much "admin" type experience, zsolt> I've found python to be less than Ideal when dealing with zsolt> system calls and standard Input Ouput. Have you tried the 'subprocess' module to see whether it solves your problems, new in 2.4? That said, I've never had the problems you describe with normal popen* calls either. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: templating system
>>>>> "Erik" == Erik Max Francis <[EMAIL PROTECTED]> writes: Erik> All I meant by that note was that EmPy was not primarily Erik> designed for blazing speed; that is, it could easily be made Erik> much more efficient in a lot of ways. I've never had a need It would be interesting to see benchmarks comparing different templating system. I suppose a web templating system like PSP (of mod_python) would be optimized for speed. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Nokia to speak at Python-UK next week
>>>>> "Nick" == Nick Craig-Wood <[EMAIL PROTECTED]> writes: Nick> Not entirely on topic, but does anyone know if there is a Nick> series 80 python? Or if the series 60 python runs on a Nick> series 80 phone (eg communicator 9300/9500)? Nope & nope. It would be easy-ish to get Python working on a console level on 9300/9500 if there was access to the source code... There's also an open source implementation of Python for UIQ (UI toolkit used by SonyEricsson) See http://www.mobilewhack.com/programming/python/ -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Regular Expressions - Python vs Perl
>>>>> "Ilpo" == Ilpo NyyssÃnen writes: Ilpo> James Stroud <[EMAIL PROTECTED]> writes: >> Is it relevant that Python can produce compiled expressions? I >> don't think that there is such a thing with Perl. Ilpo> The problem in python here is that it needs to always Ilpo> recompile the regexp. I would like to have a way to write a Ilpo> regexp as a constant and then python should compile that Ilpo> regexp to the byte-code file. Ilpo> This is a problem when one has a big amount of regexps. One Ilpo> example is the xmlproc parser in PyXML, Read the source for sre.py, esp. _compile. The compiled regexps are cached, so when you invoke e.g. re.match(), it doesn't recompile the regexp. So this point is moot, and perl's approach is excessive special casing. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Regular Expressions - Python vs Perl
>>>>> "Ilpo" == Ilpo NyyssÃnen writes: Ilpo> Of course it caches those when running. The point is that it Ilpo> needs to recompile every time you have restarted the Ilpo> program. With short lived command line programs this really Ilpo> can be a problem. I didn't imagine it could be longer than 1 second overhead - and if you have so many regexps, it must do something so nontrivial that 1 second doesn't matter. Perhaps I have a different mindset about this :-). Ilpo> And yes, I have read the source of sre.py and I have made an Ilpo> ugly module that digs the compiled data and pickles it to a Ilpo> file and then in next startup it reads that file and puts Ilpo> the stuff back to the cache. What's so ugly about it? The fact that you need to rewrite the cache when you change some of the regexps? I can't imagine you change more than, say, 10 of the regexps a day (compiling of which is an insignificant performance hit) and when you "ship" the script, you will freeze the regexps anyway. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Caching compiled regexps across sessions (was Re: Regular Expressions - Python vs Perl)
>>>>> "Ilpo" == Ilpo NyyssÃnen writes: >> so you picked the wrong file format for the task, and the slowest Ilpo> What would you recommend instead? Ilpo> I have searched alternatives, but somehow I still find XML Ilpo> the best there is. It is a standard format with standard Ilpo> programming API. Ilpo> I don't want to lose my calendar data. XML as a standard Ilpo> format makes it easier to convert later to some other Ilpo> format. As a textual format it is also readable as raw also Ilpo> and this eases debugging. Use pickle, perhaps, for optimal speed and code non-ugliness. You can always use xml as import/export format, perhaps even dumping the db to xml at the end of each day. Ilpo> And my point is that the regular expression compilation can Ilpo> be a problem in python. The current regular expression Ilpo> engine is just unusable slow in short lived programs with a Ilpo> bit bigger amount of regexps. And fixing it should not be Ilpo> that hard: an easy improvement would be to add some kind of Ilpo> storing mechanism for the compiled regexps. Are there any Ilpo> reasons not to do this? It should start life as a third-party module (perhaps written by you, who knows :-). If it is deemed useful and clean enough, it could be integrated w/ python proper. This is clearly something that should not be in the python core, because the regexps themselves aren't there either. >> python has shipped with a fast XML parser since 2.1, or so. Ilpo> With what features? validation? I really want a validating Ilpo> parser with a DOM interface. (Or something better than DOM, Ilpo> must be object oriented.) Check out (coincidentally) Fredrik's elementtree: http://effbot.org/zone/element-index.htm Ilpo> I don't want to make my programs ugly (read: use some more Ilpo> low level interface) and error prone (read: no validation) Ilpo> to make them fast. Why don't you use external validation on the created xml? Validating it every time sounds like way too much like Javaic B&D to be fun anymore. Pickle should serve you well, and would probably remove about half of your code. "Do the simplest thing that could possibly work" and all that. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Python or PHP?
>>>>> "Leif" == Leif K-Brooks <[EMAIL PROTECTED]> writes:
Leif> Lad wrote:
>> Is anyone capable of providing Python advantages over PHP if there are
>> any?
Leif> Python is a programming language in more ways than simple Turing
Leif> completeness. PHP isn't.
+1 QOTW.
--
Ville Vainio http://tinyurl.com/2prnb
--
http://mail.python.org/mailman/listinfo/python-list
Re: Object oriented storage with validation (was: Re: Caching compiled regexps across sessions (was Re: Regular Expressions - Python vs Perl))
>>>>> "Ilpo" == Ilpo NyyssÃnen writes: Ilpo> Pickle doesn't have validation. I am not comfortable for Ilpo> using it as storage format that should be reliable over Ilpo> years when the program evolves. It also doesn't tell me if That's why you should implement xml import/export mechanism and use the xml file as the "canonical" data, while the pickle is only a cache for the data. Ilpo> How can it work automatically in separate module? Replacing Ilpo> the re.compile with something sounds possible way of getting Ilpo> the regexps, but how and where to store the compiled data? Ilpo> Is there a way to put it to the byte code file? Do what you already did - dump the regexp cache to a separate file. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Python or PHP?
>>>>> "John" == John Bokma <[EMAIL PROTECTED]> writes: >> Nah, they aren't slow. They just have to worry about more things than >> the Python developers. John> Do you have references to this? I would love to see if John> indeed 100 Python programmers do implement, say 5 CS tasks John> faster compared to 100 Perl programmers, on average. I am quite sure that given random sample of python and perl programmers, the python programmers would be faster. Less thinking is necessarily, no $ chars and generally less punctuation to worry about, no error handling needed (exceptions take care of it automatically). I would also venture to guess that random (adult) Python programmers would be of higher skill level as far as programming in general goes (know more languages, have a "good taste"...). -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Python or PHP?
>>>>> "John" == John Bokma <[EMAIL PROTECTED]> writes:
John> Who told you Perl can't do exceptions?
Back when I learned (heh, I never 'really' learned, but knew enough to
write programs in it) perl, almost every function call was followed by
or die("blah");
i.e. the user had to check the error code. If the function would have
raised an exception instead, such check would be redundant because it
would never be executed.
In Python, all error conditions raise exceptions. If python
'supported' exceptions but standard library functions didn't raise
them, the feature would not be worth much.
--
Ville Vainio http://tinyurl.com/2prnb
--
http://mail.python.org/mailman/listinfo/python-list
Re: What's do list comprehensions do that generator expressions don't?
>>>>> "Jeremy" == Jeremy Bowers <[EMAIL PROTECTED]> writes: Jeremy> On Sun, 24 Apr 2005 22:59:12 -0700, Robert Kern wrote: >> Never. If you really need a list >> >> list(x*x for x in xrange(10)) >> >> Sadly, we can't remove list comprehensions until 3.0. Jeremy> Why "remove" them? Instead, we have these things called Jeremy> "comprehensions" (which, now that I say that, seems a Jeremy> rather odd name), and you can control whether they result Jeremy> in a list or a generator with () or []. Still, list comprehensions should be implemented in terms of genexps to get rid of the LC variable that is visible outside the scope of the LC. Jeremy> should be relatively simple), it's not worth breaking that Jeremy> code. Well, the code that relies on the dangling variable deserves to break. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
