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
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
Re: Python internal design
>>>>> "Emre" == Emre Turkay <[EMAIL PROTECTED]> writes: Emre> Hi Folks, Emre> I am designing a tool, in which there are dynamic types and Emre> variables with these types. In this respect, it is more like Emre> an interpreted language design. Emre> I wonder how these issues are implemented in Python are Emre> there any documents or articles about it, which I can read Emre> and get an idea. It's built around string lookup. obj.stuff() -> look up what object is associated with string 'stuff', get the object, see how it can be called, call it. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: names of methods, exported functions
>>>>> "Mayer" == Mayer <[EMAIL PROTECTED]> writes: Mayer> Hello: Mayer> Is there a way to see at the python prompt the names of all Mayer> the public methods of a class or the names exported by a Mayer> module? I know that If you use ipython, you can press after the period, e.g. [~]|128> import re [~]|129> re. re.DOTALL re.MULTILINE re.__all__re.error re.search re.I re.S re.__doc__re.escape re.split re.IGNORECASE re.U re.__file__ re.findallre.sub re.L re.UNICODEre.__name__ re.finditer re.subn re.LOCALE re.VERBOSEre.compilere.match re.template re.M re.X re.engine re.purge re.__class__ [~]|129> re. ISTR the completion can be added to plain old python prompt as well, through rlcompleter. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Which IDE is recommended?
>>>>> "pydev" == Brian Beck <[EMAIL PROTECTED]> writes: pydev> * PyDev isn't yet mature enough to make it practical for me What version? PyDev has increased in maturity quite a bit lately. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Which IDE is recommended?
>>>>> "Brian" == Brian Beck <[EMAIL PROTECTED]> writes: Brian> Oh yeah, and what's with not being able to configure the Brian> code completion key sequence. How about *no* key sequence? Brian> That's the way every other IDE I've used does it. This is Brian> more like semi-automatic code completion. It works like that for me. I type: import os os. And I get the list of completions. Perhaps you are just being impatient? Also, make sure that Preferences/pydev/code completion has "Autocomplete on '.'" box checked. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Which IDE is recommended?
>>>>> "Brian" == Brian Beck <[EMAIL PROTECTED]> writes: Brian> Okay, sorry for spamming the newsgroup so much, but I Brian> installed 0.9.3 properly and the same issues I mentioned Brian> before persist. Code completion for imports or locals don't Brian> work at all -- the space thing was PyDev just listing all Brian> the built-ins, with none of my modules or locals included Brian> in the list. This is another thing that works fine for me. Have you tried starting with an empty file to see whether there is something in your source file that trips up pydev? Whining at the pydev mailing list might work as well. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Which IDE is recommended?
>>>>> "Brian" == Brian Beck <[EMAIL PROTECTED]> writes: Brian> Ville Vainio wrote: >> Perhaps you are just being impatient? >> >> Also, make sure that Preferences/pydev/code completion has >> "Autocomplete on '.'" box checked. Brian> Yeah, that option is enabled. I actually just discovered Brian> that it does work in the example you give and for other Brian> modules in the standard library. But calls to standard Brian> library modules only occur maybe twice in any of my big Brian> scripts... the problem is I've been trying code completion Brian> with third-party modules and local classes, which still Brian> doesn't work. >From the faq at http://pydev.sourceforge.net/faq.html: How do I set the PYTHONPATH for code completion to work in my project? To set the PYTHONPATH for code completion purposes, you have to right click your project root, choose properties->PyDev PYTHONPATH and set it. The Restore PYTHONPATH button should get your enviroment PYTHONPATH and automatically set it. If it does not work, check python interpreter is correctly set (see questions above). Does this help? -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: large dictionary creation takes a LOT of time.
>>>>> "Kent" == Kent Johnson <[EMAIL PROTECTED]> writes: Kent> if frequency.has_key(word): Kent> frequency[word] += 1 Kent> else: Kent> frequency[word] = 1 This is a good place to use 'get' method of dict: frequency[word] = frequency.get(word,0) + 1 -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Which IDE is recommended?
>>>>> "John" == John J Lee <[EMAIL PROTECTED]> writes: John> Dave Cook <[EMAIL PROTECTED]> writes: John> What are those compelling features of Pydev, for an emacs John> user? http://pydev.sourceforge.net/features.html Code completion and debugger are the most obvious ones. Eclipse itself is also quite a "feature". -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
IPython 0.7.3 beta 2 is out!
Yes, next version of IPython is closing in on final release around the years end, with lots of new exiting features (full list TBD, but it *does* include proper python 2.5 support if that's what you've been waiting for). Get the 0.7.3 beta 2 it at http://projects.scipy.org/ipython/ipython/wiki/Release/0.7.3 And remember to run %upgrade if you are already using an older version. -- http://mail.python.org/mailman/listinfo/python-list
IPython 0.7.3 upgrade notes
Something I forgot to emphasize in the announcement, knowing that not everyone reads the release notes - if you are upgrading from a previous version of IPython, you must either: - Delete your ~/ipython (or ~/_ipython) directory OR - Run %upgrade once IPython starts. -- http://mail.python.org/mailman/listinfo/python-list
Re: IPython 0.7.3 upgrade notes
Ville Vainio wrote: > Something I forgot to emphasize in the announcement, knowing that not > everyone reads the release notes - if you are upgrading from a previous > version of IPython, you must either: > > - Delete your ~/ipython (or ~/_ipython) directory OR > - Run %upgrade once IPython starts. (And if you are wondering what all of this is about, due to c.l.p.announce moderator approval waitn period, see http://projects.scipy.org/ipython/ipython/wiki/Release/0.7.3 -- http://mail.python.org/mailman/listinfo/python-list
Re: IPython 0.7.3 upgrade notes
Ville Vainio wrote: > Something I forgot to emphasize in the announcement, knowing that not > everyone reads the release notes - if you are upgrading from a previous > version of IPython, you must either: > > - Delete your ~/ipython (or ~/_ipython) directory OR > - Run %upgrade once IPython starts. And if you are wondering what all of this is about, due to c.l.p.announce moderator approval wait period, see http://projects.scipy.org/ipython/ipython/wiki/Release/0.7.3 -- http://mail.python.org/mailman/listinfo/python-list
IPython 0.7.3 is out
Hi all, The IPython team is happy to release version 0.7.3, with a lot of new enhancements, as well as many bug fixes (including full Python 2.5 support). We hope you all enjoy it, and please report any problems as usual. WHAT is IPython? 1. An interactive shell superior to Python's default. IPython has many features for object introspection, system shell access, and its own special command system for adding functionality when working interactively. 2. An embeddable, ready to use interpreter for your own programs. IPython can be started with a single call from inside another program, providing access to the current namespace. 3. A flexible framework which can be used as the base environment for other systems with Python as the underlying language. 4. A shell for interactive usage of threaded graphical toolkits. IPython has support for interactive, non-blocking control of GTK, Qt and WX applications via special threading flags. The normal Python shell can only do this for Tkinter applications. Where to get it --- IPython's homepage is at: http://ipython.scipy.org and downloads are at: http://ipython.scipy.org/dist We've provided: - Source download (.tar.gz) - A Python Egg (http://peak.telecommunity.com/DevCenter/PythonEggs). - A native win32 installer. We note that IPython is now officially part of most major Linux and BSD distributions, so packages for this version should be coming soon, as the respective maintainers have the time to follow their packaging procedures. Many thanks to Jack Moffit, Norbert Tretkowski, Andrea Riciputi, Dryice Liu and Will Maier for the packaging work, which helps users get IPython more conveniently. Many thanks to Enthought for their continued hosting support for IPython. Release notes - See http://projects.scipy.org/ipython/ipython/wiki/Release/0.7.3/Features for notable new features in this release. Enjoy, and as usual please report any problems. The IPython team. -- http://mail.python.org/mailman/listinfo/python-list
