[issue18471] Typo in heapq documentation
New submission from François Pinard: Within http://docs.python.org/3/library/heapq.html#theory, a sentence begins with When an event schedule while it should be spelled When an event schedules. The same may be observed in Python 2 documentation. -- assignee: docs@python components: Documentation messages: 193145 nosy: docs@python, icule priority: normal severity: normal status: open title: Typo in heapq documentation versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18471 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
RELEASED: Pymacs 0.25
Hello to everybody, and Emacs users in the Python community. Pymacs 0.25 is now available. There has been a while, so I advise current Pymacs users to switch with caution. - Python 3 is now supported. This required new installation mechanics, and a Python pre-processor written for the circumstance (named **). - Pymacs now installs a single Python file instead of a Python module. Nice thanks to Pymacs contributors. It surely has been fun working with you all! -- Pymacs is a powerful tool which, once started from Emacs, allows both-way communication between Emacs Lisp and Python. Pymacs aims Python as an extension language for Emacs rather than the other way around, and this asymmetry is reflected in some design choices. Within Emacs Lisp code, one may load and use Python modules. Python functions may themselves use Emacs services, and handle Emacs Lisp objects kept in Emacs Lisp space. For more information, see http://pymacs.progiciels-bpi.ca/ . You may fetch the distribution as one of: - https://github.com/pinard/Pymacs/tarball/v0.25 - https://github.com/pinard/Pymacs/zipball/v0.25 -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/
RELEASED: Pymacs 0.25
Hello to everybody, and Emacs users in the Python community. Pymacs 0.25 is now available. There has been a while, so I advise current Pymacs users to switch with caution. - Python 3 is now supported. This required new installation mechanics, and a Python pre-processor written for the circumstance (named **). - Pymacs now installs a single Python file instead of a Python module. Nice thanks to Pymacs contributors. It surely has been fun working with you all! -- Pymacs is a powerful tool which, once started from Emacs, allows both-way communication between Emacs Lisp and Python. Pymacs aims Python as an extension language for Emacs rather than the other way around, and this asymmetry is reflected in some design choices. Within Emacs Lisp code, one may load and use Python modules. Python functions may themselves use Emacs services, and handle Emacs Lisp objects kept in Emacs Lisp space. For more information, see http://pymacs.progiciels-bpi.ca/ . You may fetch the distribution as one of: - https://github.com/pinard/Pymacs/tarball/v0.25 - https://github.com/pinard/Pymacs/zipball/v0.25 -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
RELEASED: Pymacs 0.23
Hello to everybody, and Emacs users in the Python community. Here is Pymacs 0.23! There has been a while, so I advise current Pymacs users to switch with caution. All reported bugs have been squashed, if we except one about Emacs quit (C-g) not being obeyed gracefully. A few suggestions have been postponed, to be pondered later. The manual is now in reST format, and everything Allout is gone. Postscript and PDF files are not anymore part of the distribution, you may find them on the Web site, or use the Makefile if you have needed tools. Examples have been moved out of the manual into a new contrib/ subdirectory, which also holds a few new contributions. The example of a Python back-end for Emacs Gnus has been deleted. Python 1.5.2 compatibility has been dropped; use Python 2.2 or better. The Pymacs manual explains installation procedure, now simplified. The pymacs-services script is gone, this should ease installing Pymacs on MS Windows. There is also a small, still naive validation suite. The communication protocol has been revised: more clarity, less magic. Zombie objects are less dreadful by default. The API now supports False and True constants, and Unicode strings (within limits set by Emacs). Special thanks to those who helped me at creating or testing this release. Pymacs is a powerful tool which, once started from Emacs, allows both-way communication between Emacs Lisp and Python. Pymacs aims Python as an extension language for Emacs rather than the other way around, and this asymmetry is reflected in some design choices. Within Emacs Lisp code, one may load and use Python modules. Python functions may themselves use Emacs services, and handle Emacs Lisp objects kept in Emacs Lisp space. The main Pymacs site is `http://pymacs.progiciels-bpi.ca/', and you may fetch `http://pymacs.progiciels-bpi.ca/archives/Pymacs.tar.gz'. Report problems and suggestions to `mailto:[EMAIL PROTECTED]'. -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations.html
RELEASED: Pymacs 0.23
Hello to everybody, and Emacs users in the Python community. Here is Pymacs 0.23! There has been a while, so I advise current Pymacs users to switch with caution. All reported bugs have been squashed, if we except one about Emacs quit (C-g) not being obeyed gracefully. A few suggestions have been postponed, to be pondered later. The manual is now in reST format, and everything Allout is gone. Postscript and PDF files are not anymore part of the distribution, you may find them on the Web site, or use the Makefile if you have needed tools. Examples have been moved out of the manual into a new contrib/ subdirectory, which also holds a few new contributions. The example of a Python back-end for Emacs Gnus has been deleted. Python 1.5.2 compatibility has been dropped; use Python 2.2 or better. The Pymacs manual explains installation procedure, now simplified. The pymacs-services script is gone, this should ease installing Pymacs on MS Windows. There is also a small, still naive validation suite. The communication protocol has been revised: more clarity, less magic. Zombie objects are less dreadful by default. The API now supports False and True constants, and Unicode strings (within limits set by Emacs). Special thanks to those who helped me at creating or testing this release. Pymacs is a powerful tool which, once started from Emacs, allows both-way communication between Emacs Lisp and Python. Pymacs aims Python as an extension language for Emacs rather than the other way around, and this asymmetry is reflected in some design choices. Within Emacs Lisp code, one may load and use Python modules. Python functions may themselves use Emacs services, and handle Emacs Lisp objects kept in Emacs Lisp space. The main Pymacs site is `http://pymacs.progiciels-bpi.ca/', and you may fetch `http://pymacs.progiciels-bpi.ca/archives/Pymacs.tar.gz'. Report problems and suggestions to `mailto:[EMAIL PROTECTED]'. -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Comparing dictionaries, is this valid Python?
Hi, people. I noticed today that dictionaries seem to support `==' comparison. (Retrospectively, it is strange that I never needed it before! :-) Yet, before relying on this, I seeked for confirmation in the Python manuals, and did not succeed in finding it. In particular: http://www.python.org/doc/2.3.5/lib/typesmapping.html is silent on the subject. As for: http://www.python.org/doc/2.3.5/lib/comparisons.html it only says Comparison operations are supported by all objects, which is a little vague, and no promise that comparisons are meaningful (for example, one might wonder what would exactly mean the comparison of open files). The node even says: Two more operations with the same syntactic priority, in and not in, are supported only by sequence types (below)., which suggests that the information might not be fully up-to-date, at least regarding dictionaries. Would someone know where I could find a confirmation that comparing dictionaries with `==' has the meaning one would expect (even this is debatable!), that is, same set of keys, and for each key, same values? -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: Comparing dictionaries, is this valid Python?
[Peter Hansen] it only says Comparison operations are supported by all objects [...] I'm not checking the 2.3.5 version, but that latest one is fairly clear on what comparisons on mappings do: http://docs.python.org/ref/comparisons.html Yes, indeed. Thanks a lot! -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: Bitching about the documentation...
[A.M. Kuchling] On Tue, 6 Dec 2005 00:05:38 -0500, François Pinard [EMAIL PROTECTED] wrote: It's a relatively recent phenomenon that maintainers go berzerk, foaming at the mouth over forms, borders, colors, and various other mania! :-) It's largely to ensure that the ideas aren't lost. E-mail sits around in an inbox until it gets deliberately deleted or gets lost in a disk crash or system upgrade gone wrong. Or sorted properly by the recipient, the way he sees best fit, in the tracker of his own choice. I know I'm repeating myself, but my point just does not seem to get through. The maintainer should manage his way as a grown up, instead of expecting the world to learn his ways and manage in his place. You may suggest that I should process my e-mail more promptly. No, I'm not suggesting you how to work, no more that I would accept that you force me into working your way. If any of us wants to force the other to speak through robots, that one is not far from unspeakable... If the message was important, they'll resend it. This is despising contributions. If someone sends me a message which I find important, I do take means so that message does not get lost, and that it will even suvive me for some while. This is why things need to go into public trackers, or wiki pages. Whatever means the maintainer wants to fill his preservation needs, he is free to use them. The problem arises when the maintainer wants imposing his own work methods on others. Let contributors be merely contributors, and learn how to recognise contributions as such and say thank you, instead of trying to turn contributors into maintainers. -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: Bitching about the documentation...
[EMAIL PROTECTED] Let me repeat this for the umpteenth time: You do not have to learn LaTeX to contribute to docs. Submit plain text. One of us with some LaTeX knowledge will do the markup. Content is the hard part. Markup is nothing, so don't let it be a barrier for you. More than LaTeX, the main frozener is when people in charge tell you to use bug trackers to speak to them. This is like standing up with someone, having a conversation, and your partner suddenly tells you: If you want to speak to me, please study this form, carefully read the small print, fill it properly and send the yellow copy at this address. Surprised, you ask: Why should I do that?, and he replies: I might forget our conversation if you don't fill a form for me. Even more suprіsed, you say: Gosh, can't you manage your own notes yourself, as you see them fit? Most grown up people are able to take care of themselves, you know. I just do not like filling these forms! Besides, _my_ time is quite precious. Astonished, you just cannot believe what you hear. Life is so short, you think, why one would ought to stand with such guys? As the room is full of other interesting people, you happily move on towards them. -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: Bitching about the documentation...
[Ben Finney] please study this form, carefully read the small print, fill it properly and send the yellow copy at this address. ... so that it can go with all the other requests I get at various times from various people. If he wants pink forms with blue borders, let him grant himself with pink forms with blue borders. His way of managing has not to be mine. If he declares being unable to read information unless it is written on a pink form with blue borders, he has a serious communication problem, that should not receive encouragement from me. Astonished, you just cannot believe what you hear. Life is so short, you think, why one would ought to stand with such guys? Perhaps because you have asked them to do something that benefits you, Or perhaps not so specifically. When I (attempt to) submit a Python problem (documentation or otherwise), I'm hoping some benefit to the Python community in the long run. One of those humble drops which, accumulated, make oceans. Most of times, in practice, I already solved my actual problem. I'm merely trying to be a good citizen. However, when people tell me I'm not a good citizen unless _I_ fill pink forms with blue borders, I think they lost part of their good judgement. If they really want pink forms, they should serve themselves by filling pink forms, and leave me and the world alone with these forms. As the room is full of other interesting people, you happily move on towards them. If you just want to have conversations, talk to whomever you like. If you want someone specific to voluntarily do something, yes, you'll have to meet them halfway by helping them help you. I do not want to force anyone to anything. This is mostly volunteer work. You know that. The problem I'm reporting here is this pink form mania. _I_ would volunteer something, that they'd ask for pink forms. I've been in the area of free software maintainance for a very long while, collobarated with maybe a hundred of maintainers, and corresponded with surely many thousands of users. No doubt it was a lot of work overall, but at least, communication was easy going (usually). It's a relatively recent phenomenon that maintainers go berzerk, foaming at the mouth over forms, borders, colors, and various other mania! :-) -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: Detect character encoding
[Diez B. Roggisch] Michal wrote: is there any way how to detect string encoding in Python? Recode might be of help here, it has such heuristics built in AFAIK. If we are speaking about the same Recode ☺, there are some built in tools that could help a human to discover a charset, but this requires work and time, and is far from fully automated as one might dream. While some charsets could be guessed almost correctly by automatic means, most are difficult to recognise. The whole problem is not easy. -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: Setting PYTHONPATH from Makefile
[EMAIL PROTECTED] I have a Makefile target that uses a python script, like: %.abc: %.def python myscript.py If this was a tcsh script, I would just do: setenv PYTHONPATH /path/to/stuff python myscript.py but this cannot be done from a Makefile. Use: %.abc: %.def PYTHONPATH=/path/to/stuff python myscript.py In fact, within Make or outside Make, for any shell command, you may write: VAR1=VALUE1 VAR2=VALUE2 ... COMMAND ARGUMENTS so temporarily setting VAR1, VAR2... in the environment for the duration of COMMAND only. This is a useful feature of the shell. -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: Estimating memory use?
[Fredrik Lundh] the internal RE byte code format is version dependent, so pickle stores the patterns instead. Oh! Nice to know. That explains why, when I was learning Python, my initial experiment with pickles left me with the (probably wrong) feeling that they were not worth the trouble. It might be worth a note in the documentation, somewhere appropriate. -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: 3-dimensional plot in Python?
[Frithiof Andreas Jensen] [EMAIL PROTECTED] I want to make a 3d plot. x is a vector(discrete), y is also a vector(discrete), for each pairwise x,y I have a value z(x,y)(it is not a function, just discrete values for each pair of x,y). I want to show them on a two dimensional plot by showing z(x,y) with colors. SciPy is your friend: Provides interfaces to several plot engines, including gnuplot. For such things, I like R (from http://www.r-project.org), for which also exist a few Python interfaces (I use http://rpy.sourceforge.net). For communication between Python and R, Python Numeric facilities are usable, yet not required. Moreover, with 3D-accelerated cards or simulations thereof, OpenGL tools (see http://rgl.neoscientists.org) allow you to interactively wander into your plot, somehow. The combination is worth. What may appear as a drawback is the need to become acquainted with R, the system and the language. But if you happen to do scientific works, this really is a worth investment. -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: modify dictionary while iterating
[EMAIL PROTECTED]
I wish to pop/del some items out of dictionary while iterating over it.
a = { 'a':1, 'b':2 }
for k, v in a.iteritems():
if v==2:
del a[k]
A simple change would be using items() instead of iteritems().
Or else, you may prefer to loop over keys, and retrieve values, either:
for k in a.keys():
if a[k] == 2:
del a[k]
or:
for k in set(a):
if a[k] == 2:
del a[k]
But in no way, you may directly iterate over the original dictionary
while altering its keys, this is explicitly forbidden in Python.
--
François Pinard http://pinard.progiciels-bpi.ca
--
http://mail.python.org/mailman/listinfo/python-list
Re: Recompile AST?
[EMAIL PROTECTED] Is it possible to recompile the AST generated by compiler.parse, back into code or an executable code object? My aim here is to allow a script to manipulate Python code as elements within a list. However, it doesn't look like the module has any native methods designed to do this. Pynits does something like this for pretty-printing Python statements, from within Vim. I did not touch this project for a while, yet I still intend to revisit it in a few weeks or months (for an actual need). You may peek at: http://fp-etc.progiciels-bpi.ca/pynits.html -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: Vim IS a capable IDE [was Re: Vim capable IDE?]
[Chris Lasher] Thanks for the replies, guys! I had no idea Vim was capable of doing some of those things. One detail which should be more widely known, in my opinion, is the capability of Vim (if compiled properly) to use Python has an extension language. That is, you may add new Vim commands to your liking (presuming you know how to program), writing them in Python. -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: Continuous system simulation in Python
[Robert Kern] [...] an ODE integrator would probably want to adaptively select its timesteps as opposed to laying out a uniform discretization upfront. Eons ago, I gave myself such a little beast (but really found in an Appendix of a book on simulation), which I use since then whenever I need it, not so often in these days. If you are curious, see: http://fp-etc.progiciels-bpi.ca/rke.html yet I'm sure there is just plenty of such things, all around. The above is in C, not in Python. I vaguely remember having once rewritten the thing in Python, then discarded the result as not fast enough for the need I then had. If I really needed to use it nowadays, I'll probably try to quickly link it through Pyrex. Or just look around a bit for some already made, and maybe better solution. :-) It is easy and convenient, when writing a mixed discrete and continuous simulation system, to tie the advancement control of the various active ODE solvers within the main loop of the discrete event scheduler. -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: Does python support the expression a = b | 1???
[Wenhua Zhao] a = b | 1 a = b if b != nil else a =1 Is there such expression in python? Hi. Merely write: a = b or 1 In Python, there is no `nil'. `a' will receive 1 instead of the value of `b' only if `b' is either zero, None, False, or empty in some way. -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 350: Codetags
[Tom Anderson] ISO 8601 suggests writing date-and-times like 2005-09-26T12:34:56 - using a T as the separator between date and time. I don't really like the look of it, but it is a standard, so i'd suggest using it. ISO 8601 suggests a few alternate writings, and the ``T`` you mention is for only one of them, meant for those cases where embedded spaces are not acceptable. Other ISO 8601 writings accept embedded spaces, and this is how ISO 8601 is generally used by people, so far that I can see. -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: Parser suggestion
[Jorge Godoy] You're someone [...] You make me shy! :-) Nevertheless, thanks for the appreciation! :-) It looks like it stopped being developed circa 2002... How can I be sure that if I find a bug I'll be able to discuss it with the developer if it's 3 years since the last release of his code? SPARK is rock solid for me, and for the little doubts or improvements I wanted, I remember having written to John Aycock, who always replied. But of course, without having experienced it yourself, I understand that one may have doubts. I also did not have any need for writing to Jonh in a few years. In any case, SPARK is a single module file, and not such a big one after all. I very slightly adapted it to my own needs and habits, and merely copy it from project to project since then. One warning is worth being told about SPARK. As it accepts a wider variety of grammars, it uses algorithms that may be slow depending on your grammar design, and may become slow when you have errors in your source. Compromises are needed. In all cases I used it so far, whenever the input to parse was sizeable, it was easy for me to split the source in smaller chunks with boundaries recognisable by other means, and calling the parser on each chunk instead of globally on the whole thing. This yielded reasonable parsing speed in production code. With SPARK, you have to provide a tokenizer. SPARK offers one based on regular expressions as in Python, I found out I often prefer writing my own instead. If you have to process FORTRAN code, you may have some difficulty in this area (yet I may be all wrong by saying so, as my FORTRAN is very rusty, and I did not keep up with the evolution of FORTRAN standards). At a time in the past, FORTRAN did allow spurious, ignored whitespace about everywhere outside strings, would it be within identifiers. Whitespace can (could) also be spared between tokens where it would have been clearly mandatory in any other language I know. So, the split between the lexical and syntactic analysis for FORTRAN is (or at least once was) fairly fuzzy. But this is theoretical. In practice, FORTRAN programmers almost never resort to insane use of whitespace. So you may probably resort to easier, standard two-level analysis, rather than FORTRAN as formally defined, and still be winning! -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 350: Codetags
[Bengt Richter] The most detailed discussion I could find was http://hydracen.com/dx/iso8601.htm Also of interest:: http://www.cl.cam.ac.uk/~mgk25/iso-time.html IMO they [ISO] ought to think of another way to get funded). People have been complaining for decades. ISO seemingly run a high overhead. :-) Anyway, the 'T' looks to me to be optional by mutual agreement between particular information exchangers, but otherwise required? I quickly poke around on the net, and the ``T`` is often presented as required, yet I really thought I read otherwise somewhere. Not much of an argument, I once scrutinized the ISO standard itself, yet I likely do not remember much of it! This was quite a while ago, for a French-written study and report I wrote under contract (archives at http://www.progiciels-bpi.ca/man/normes/index.html :-). Yet, I do not remember having retained the 8601 standard in that study. -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: Parser suggestion
[Jorge Godoy] SPARK (Scanning Parsing And Rewriting Kit) http://pages.cpsc.ucalgary.ca/~aycock/spark/ It looks like it stopped being developed circa 2002... From 2002 to now Python had a lot of improvements and I'd rather use a maintained tool for this project. At least one that keeps up with Python's development... While this way of thinking is in the fashion, and often happens to be right, it does not really apply in the SPARK case. SPARK works fine and well, and is probably the most elegant and pythonic of the series. If it it does not really need to be further developed, and does not have much to gain from recent Python releases, I do not see why it should be released once in a while merely to entertain the crowd. -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: A Moronicity of Guido van Rossum
[Delaney, Timothy (Tim)] Tony Meyer wrote: It's made worse because he uses so many words that you'd expect to find in legitimate c.l.p messages. It's this last bit that's the problem. I've got no problems filtering other types of spam messages to the list, but XL adds so many non-spam terms that the from field gets declared a statistical anomaly :( My email reader automatically marks any message naming him, anywhere, as deleted on entry, here. I opened this one nevertheless, out of curiosity, because the message was from Tim Delaney, who knows better! I made it fairly easy to manage those few cases which escape Bayesian filters. For something I do not want to read, I merely select a small part of the message acting like a clue, then hit Alt-Ctrl-K, which pops up a small menu (author, subject, body, etc.). I select `body', and that's it. Emails are later deleted on entry. The keybinding is known to the window manager (Openbox here), which launches a small Python script to update tables for the mail fetcher (another Python script), and the mail reader (Mutt in my case). All of this is very convenient. -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Let's enjoy this list! [Re: Re: cElementTree clear semantics]
[D H] I think it means you should fuck off, asshole. Such language looks very inappropriate to me in a public list, and builds a bad and long-lasting prejudice against those resorting to it. Flamers should rather, for their own image, email each other privately on their matters (yet D.H. is not providing his/her email address in the last messages I've seen). Flamers being in the strong need of an audience may easily find special forums for people enjoying flames. As for the Python list, let's keep it the calm and enjoyable place it usually is. Resist the temptation of feeding flames, rather ignore or merely learn to killfile the (happily few) abusers we got. Enough said for now! Keep happy, all of you. :-) -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: unittest setup
[George Sakkis] Yes, py.test: http://codespeak.net/py/current/doc/test.html. The whole http://codespeak.net site contains many interesting projects, which are all worth a good look! However, there is a generic ``LICENSE`` file claiming copyrights on all files, without explaining what the copyright conditions are. This file also delegates copyright issues to individual files, which are usually silent on the matter. Could this whole issue be clarified? Or did I miss something I should not have? -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: NaN Vs None
[Peck, Jon] In choosing a way to represent a value of no information for a float, would it be better to use NaN or None? None has the advantage of standard behavior across platforms, but NaN seems to propagate more easily – at least on Windows. [...] What I do for these things is creating a Missing type which behaves like a number, that is, it has all __FUNCTION__ magic required by numbers. I then create either a single missing constant or very few such missing constants, in which case each one representing a particular way or flavor of a missing number (unknown, not applicable, uncomputable, etc.) The magic functions for Missing should know how to combine the few missing constants with numbers, and with other missing constants, for returning the proper one. It's easier with only one missing constant. You also need to take care of comparisons and logical operators on missing values. My usual convention is that missing values propagate within booleans and behave like False when tested. Sometimes, I also need missing strings. That's more difficult to implement, because of the numerous string methods and ramifications. -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: Software bugs aren't inevitable
[Jerzy Karczmarczuk] Steven D'Aprano recommends iteration over recursion: For instance, try these two simple functions for the nth number in the Fibonacci sequence: def fibr(n): Recursive version of Fibonacci sequence. if n == 0: return 0 elif n == 1: return 1 else:return fibr(n-1) + fibr(n-2) [...] please refrain from giving nonsensical examples, since NOBODY serious programs something in the style of your recursive version. Such anti-advertizing of recursion says less about the recursion than about yourself. [...] I did not look recently, but many introductory texts to computer science, and many, many serious teachers as well, introduce recursion using Fibonacci numbers and Towers of Hanoi. So, there is no need to be harsh on your correspondent, unless you feel like being harsh on a whole generation of teachers as well! :-) This being said, for one, I always found _insane_ presenting recursion to new programmers using such examples, which are both very easily, and much better written non-recursively. It does not help beginners at taking recursion any seriously. This is handicapping somehow, as recursion could be so useful when properly understood and applied. -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: Why do Pythoneers reinvent the wheel?
[Tim Daneliuk] OO ideas predate C++ considerably. The idea of encapsulation and abstract data types goes back to the 1960s IIRC. Did not Simula-67 have it all already? When C++ came along, much later, I asked someone knowledgeable in the field of language design what was his opinion about C++. He answered very laconically: Simula-- . And this was not far from fully true: Simula had many virtues which are still missing from C++. Moreover, a language like Simula cannot be made up of thin air, it only crystallizes a long maturation of many trends. The term OO may have been coined later, but the concepts were already there. In computer science, I often saw old concepts resurrecting with new names, and then mistaken for recent inventions. New ideas are not so frequent... -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: using % operator to print possibly unitialized data attributes
[Adam Monsen] The following code uses the % operator to print possibly unitialized data attributes: 8 class J: name = '' value = '' def __str__(self): vals = self.__class__.__dict__ vals.update(self.__dict__) return 'name=%(name)s value=%(value)s' % vals j = J() j.name = j object print j 8 A couple of questions: * is there a simpler or more elegant way to do this? * how can I get this to work for new-style classes? One solution which I used a few times, and which also opens the way to many other niceties, is to manage so `vals' is a `dict'-like type of your own. Then, you write its `__getitem__' method the way you want. If I remember well, one of the niceties is that whenever `%(EXPR)s' is used in a format string, EXPR may be a string (well balanced with regard to parentheses) which you may then choose to evaluate, for any definition of evaluate which is fruitful for your application. :-) -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: Decrypting GPG/PGP email messages
[Piet van Oostrum] Alessandro Bottoni [EMAIL PROTECTED] (AB) wrote: AB Of course, I want to be sure that only the allowed people is AB able to send such dangerous messages to my server so I will ask AB my users to encrypt and digitally sign their messages using AB Thunderbird, Enigmail and GPG ... What benefit is there in encrypting the messages? It would only prevent people intercepting the message from seeing what's inside, but it won't give you any additional protection on the server. Whenever a message contains sensitive information, it is a good idea to crypt it. Humans, and not only computers, may be harmful! :-) There are cases where information may not leak, when it vehicles private information about people. Companies also have industrial secrets. The mere fact that two people are communicating is often a secret in itself. And if somebody can intercept the messages there is a much bigger danger: They could save the message and replay it later. You can't protect against this with encryption (well, with encryption they won't know what they are doing). Neither with a digital signature. Protection against replay is easily guaranteed by sequencing requests, that is, including a sequence number within the message, each originator his sequence. A digital signature prevents someone from tampering with the sequence number without being detected. -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: Fighting Spam with Python
[David MacQuigg] Getting these methods widely and effectively used is our big challenge, and one that I hope to accomplish with my efforts. I wish one of these methods, either yours or one of these few others which were developed and proposed in the recent years, will succeed. It might be useful, for someone involved like you are (thanks for all of us!), that you make a survey of those others, trying to understand why they failed to acquire popularity, not repeating the same errors if any. -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: Fighting Spam with Python
[David MacQuigg] The key new features needed in a spam filter are the ability to extract the sender's identity (not that of the latest forwarder), and to factor into the spam score the reputation of that identity. This will only work if your system is immune to forgeries, while being largely widespread. In the flow we envision, the spam filter is the final process, used only on the 5% that is hard to classify. 80% will get an immediate reject. 15% will get an immediate accept without filtering, because the sender is authenticated and has a good reputation. Eventually, all reputable senders will join the 15%, and the 5% will shrink to where we can ignore it. It's fun to read statistics about a vision! :-) You might find www.spambayes.org of interest, in several ways. Spambayes is surprisingly good as it already stands. -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: Binary Trees in Python
[Jorgen Grahn] Neither C++ nor Python has tree structures in their standard libraries. I assume that's because there is no single interface that is proven to suit everybody's needs. It is already easy writing tree constants using recursive tuples or lists. To process simple trees in Python, I usually subclass some Node type from list, and write the traversal methods that suit the application. The sub-classing already allow for indexing sub-nodes by self[index], and iterating over all by for subnode in self:, etc. In my experience, it all goes pretty easily, while staying simple. However, things related to balancing, finding paths between nodes, or searching for patterns, etc. may require more work. There are surely a flurry of tree algorithms out there. What are the actual needs you have, and would want to see covered by a library? -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
How to devise run-time pluggable classes? (MRO problem)
Hi, everybody. I wish someone could advise me. I'm running in circles, trying to find an elegant way to devise run-time pluggable classes. It all goes around method resolution order, I guess. (We already use various solutions, but the maintenance burden is high.) We have a common module containing many basic classes, but for the sake of simplicity here, I'll use only Element and Connection. Next to this common module, we have many plugin modules importing it, and each plugin also defines an Element class having common.Element among its bases, and a Connection class having common.Connection among its bases. Or nearly, as some plugins just do not override common classes that just fit like they are. Plugins are really meant to enrich common classes. The common module and all plugins are part of a single package, but there are many other packages meant to provide work schemas, installed separately and maintained by different programmers. Each work schema package contains a core schema module which, after having imported the already installed common module above, defines tons of classes having either common.Element or common.Connection in their bases, relating them, and a schema class reaching everything, for applications to use. And finally, we have a flurry of applications. These applications import at least one and typically a few work schemas, and for each, specify _at run time_ which plugin to use (we use an URL-like syntax for specifying plugins, work schemas, and other various parameters, these URLs being read from configuration files while applications progress). So, while all work schemas are programmed to use classes from the common module, I would need at run time that all base classes be automatically promoted into plugin classes, depending on plugin as selected at run time, for being able to benefit from enriched methods. More or less, it might mean something like the virtual substitution of common classes by corresponding plugin classes whenever they appear in the class bases of work schemas, and consequently virtually altering the MRO of such classes so plugin methods override common methods, yet common methods staying available for fall back, that is, if not overridden by plugins. I feel ready to allow some complexity to the common module, but would like the overall approach to be as clean and unobtrusive as possible everywhere else, (that is, for plugins, work schemas, and applications). It ought to be overall simple. So, zealots: no Zope nor Twisted! :-). Another constraint is that the same work schema may be used at run-time with two different plugins, and this means that ideally, a work schema may not be altered (in a non-reentrant way) for a particular plugin. This is a lesser constraint, because it occurs only occasionally, and I presume that we could afford unusual stunts whenever necessary. -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: creating/modifying sparse files on linux
[EMAIL PROTECTED] Is there any simple way of generating this 1MB string (other than keep appending to a string until it reaches 1MB len)? You might of course use 'x' * 100 for fairly quickly generating a single string holding one million `x'. Yet, your idea of generating a sparse file is interesting. I never tried it with Python, but would not see why Python would not allow it. Did someone ever played with sparse files in Python? (One problem with sparse files is that it is next to impossible for a normal user to create an exact copy. There is no fast way to read read them either.) -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: Recommendations for CVS systems
[Aahz] For anything mission-critical, I wouldn't want to rely on a free license. For anything mission-critical, I wouldn't want to rely on closed sources... Could the best be open source and non-free license? :-) -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: Recommendations for CVS systems
[Mike Meyer] [...] I generally wind up cursing at [subversion] at least once a day. Would you accept elaborating a bit on the motivations of the cursing? Your message says Perforce does nice things, one might fuzzily imply that Subversion is bad or misbehaves on the same, but I do not read any definite assertion against Subversion. Having Perforce better does not necessarily makes Subversion bad. So my question. :-) -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: [ANN] pylint 0.7
[Sylvain Thénault] I'm pleased to announce a new release of PyLint. Bonjour Sylvain. J'ai la compulsion de dire bonjour, et merci! (On peut me tutoyer sans problème.) Ce logiciel `pylint', que je viens d'installer et d'essayer pour la première fois ce matin (donc, j'écris encore sur l'effet d'une première impression), me semble vraiment excellent. Plaisir supplémentaire, `logilab.common' semble contenir de bien belles choses, intéressantes pour moi, je vais regarder ça de plus près. Étant moi-même plutôt tatillon sur les questions stylistiques, je suis heureux de trouver quelqu'un qui, en plus de parler ma langue, possède probablement le même défaut. Please send any bugs or comments on the mailing list. Dois-je vraiment passer par là? Les discussions sont nécessairement un petit peu plus impersonnelles sur une liste. Si oui, alors je le ferai, bien sûr. J'imagine qu'il faut alors s'y inscrire aussi? De petites choses qui m'ont tout de suite sauté aux yeux: * `pylint --version' devrait fournir l'adresse où rapporter les problèmes. * `pylint --generate-rcfile' engendre un fichier qui possède trop d'espace blanc intempestif, en particulier à la fin de plusieurs lignes, et aussi, à la toute fin du fichier. Il serait intéressant aussi que le fichier engendré se tienne dans 79 colonnes: pas toujours possible pour le code, j'en conviens, mais au moins faisable pour les commentaires. * `pylint --parseable=y' pourrait peut-être, sous option, éviter les noms de fichiers absolus et garder une notation relative, cela éliminerait passablement de bruit lorsque le répertoire courant est niché profondément. * Malgré son origine française, `pylint' n'est pas sensible à un locale français. J'imagine que l'internationalisation n'est pas prévue? Merci bien pour PYLINTHOME et PYLINTRC, les variables d'environnement. J'en fait déjà bon usage. :-) D'une certaine manière dans la même mentalité de `pylint', j'ai produit une sorte de redresseur stylistique que j'utilise directement de l'intérieur de Vim. J'ai probablement pensé un peu à Emacs tout aussi bien en l'écrivant, mais je n'ai pas utilisé Emacs depuis un bon moment. Je désire bientôt replonger dans ce redresseur et le dépoussiérer sérieusement, pour un autre gros projet. Il vaudrait peut-être la peine de voir s'il m'est possible d'harmoniser mon outil au tien, et vice-versa peut-être, un peu. Du même jet, il m'intrigue de comparer le module `compiler' de Python 2.3, qui ne me satisfait plutôt bien, mais pas tout-à-fait, avec le module `astng' de Logilab. Donc, en bref, survole: http://fp-etc.progiciels-bpi.ca/showfile.html?name=pynits/pynits.txtmode=vim pour sentir si nos approches ont quelques atomes crochus! :-) Si oui, cela peut ouvrir la porte à quelques bonnes discussions sur l'art et la manière, en Python. Ma mère disait parfois: Des goûts et des couleurs, on ne discute pas. Mais il y en a de meilleurs que d'autres. -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: keylogger in Python
[Michael Hoffman] Jay wrote: yo, thanks for the great input. And the only reason i want to create a python based keylogger is because there is none. Just a fun project... But im gonna do some more research on the keyboard drivers and stuff like that and to learn how to attach my python porgrams into the sub-processes so that it would instead log every char instead of just char in the IDE. I think this is going to be much harder than you think, and I imagine this will only end in frustration for you. You will not be able to do it well with just Python. I would recommend a different fun project. I'm just stumbling on that message, and did not follow the whole thread, sorry if I repeat things already discussed. My point is that Python is able to do surprising things, given the `fcntl' and `ioctl' modules. Surely on Linux, logging keys under X-Windows or under virtual terminals are quite different matters. Let me share a related experience for virtual terminals. I once had to rush the port on Linux a few QNX applications, written in C, which were using the QNX term library for input and display. In console mode, the QNX keyboard is richer than the Linux one. As users wanted to retain the _exact_ keyboard functionality, I saw no choice but reading raw scan codes on the Linux side. So, I wrote a term library emulator as a thin C layer, which was itself using a Python module (Python was to be transparently embedded by the emulated library) for doing the bulk of keyboard processing. It was something pretty heretic to do, I know. But Python was more than fast enough for handling the low-level keyboard reading, for applications otherwise all written in C. But it allowed the port to be done quickly. While debugging such a thing, you often loose the keyboard and with it, the capability of switching terminals, so you have to devise some extra machinery for restoring the keyboard into a usable state. -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: keylogger in Python
[Michael Hoffman] You think this is a suitable beginner project? One surely learns a lot! :-) And for that matter, it doesn't sound like you were doing keylogging, as it is usually understood to mean globally logging keypresses, no matter the application being presented to the user. One possible avenue to keylogging might be to start a shell, over the keyboard processing layer, presuming the shell do only simple things over its standard input. But most likely, the shell is playing termios trickery and such things. So one might have to use pty's to get a working solution. Agreed, this is not all evident, and probably too much of a challenge for a beginner. -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: Difference between and '
[EMAIL PROTECTED] Can someone tell me the difference between single quote and double quote? There is no strong reason to use one and avoid the other. Yet, while representing strings, Python itself has a _preference_ for single quotes. Programmers can put this duality to good use, by adopting reasonable conventions, which are nothing more than conventions! :-) I would guess many people choose one over the other for minimizing the amount of backslash escape needed. Some people keep double quotes for strings that would later undergo formatting, maybe because in most shells and some other languages, double quotes allow for substitution and single quotes prevent it. But in my opinion, while not dismissing a lot of wisdom developed within other languages, it may be foolish letting other languages blindly dictate what is best Python style. Personally, I keep single quotes for computer strings, and double quotes for human strings. To segregate between computer and human character for a string, I merely ask myself: If I wanted to use this program in another language, would I want this particular string translated or not?. Yes means double quotes, no means single quotes. As single quotes are often use within human text, as apostrophes, this was a wise choice as far as shell escaping goes. This is extendable to triple-quoted strings. I use triple-double quotes for doc strings meant to hold documentation, which is the usual case. If doc strings are used for BNF snippets, like with SPARK, or any other machine data, triple-single quotes are mandatory by my own convention. -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: Difference between and '
[Robert Kern] One habit that seems to crop up, though, is that I will use '' for internal strings and for strings that will eventually get seen by the user. Don't ask me why. One sure thing is that it would help, later, if you ever want to internationalise a Python program. Not that it occurs that often! :-) -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: Difference between and '
[Terry Hancock]
On Friday 22 July 2005 08:09 am, François Pinard wrote:
[Robert Kern]
One habit that seems to crop up, though, is that I will use '' for
internal strings and for strings that will eventually get seen
by the user. Don't ask me why.
One sure thing is that it would help, later, if you ever want to
internationalise a Python program. Not that it occurs that often! :-)
Whoa. Why? Does xgettext not recognize _('')?
Yes, of course.
The most tedious part of internationalising a project is the selection
of strings to be translated, among all program strings, and wrapping
these within the special _(...) construct. If you can _already_ rely
on the fact double-quote strings are always to be wrapped, and that
single-quote strings are never to be wrapped, the tedious part is
already done, or almost. A few relatively quick editor commands are
may complete that aspect of the work (provided you use a reasonably
featureful editor).
As for Using xgettext or its Python counterpart, this is usually burned
into the release engineering (Makefile, distutils, or else), and is not
much of an effort, once you found a good recipe or example for it.
--
François Pinard http://pinard.progiciels-bpi.ca
--
http://mail.python.org/mailman/listinfo/python-list
Re: automatically assigning names to indexes
[EMAIL PROTECTED] I know its been done before, but I'm hacking away on a simple Vector class. [...] However, I'd like to add attribute access (magically), so I can do this: [...] Has anyone got any ideas on how this might be done? I needed something this last week, while toying with rotations. Allow me to humbly offer my solution, meant for more than one class. Yet for brievety, I'm limiting my example to a single class. A few constructors are used in the example, but the corresponding classes are missing. I hesitated a bit between having my rotation objects be modifiable or not, and finally opted for the later (consequently, the constructor is neatly called for a resulting object). If you really want a modifiable object, derive from `list' instead of deriving from `tuple', rename `NamedTuple' into `NamedList', and wihin sub-classes, initialise your object with `__init__(self, ...)' rather than with `__new__(cls, ...)'. __metaclass__ = type import math # Almost zero, but not yet. epsilon = 1e-9 from math import pi half_pi = .5*pi class NamedTuple(tuple): class __metaclass__(type): def __new__(cls, name, bases, definitions): self = type.__new__(cls, name, bases, definitions) if hasattr(self, '__names__'): def make_property(index): def getter(self): return self[index] return property(getter) for index, name in enumerate(self.__names__): setattr(self, name, make_property(index)) return self class Quaternion(NamedTuple): __names__ = 'w', 'x', 'y', 'z' def __new__(cls, w, x, y, z): l = 1./math.sqrt(w*w + x*x + y*y + z*z) return cls.new(w*l, x*l, y*l, z*l) def new(cls, w, x, y, z): if w 0.: self = tuple.__new__(cls, (-w, -x, -y, -z)) else: self = tuple.__new__(cls, (w, x, y, z)) assert self.is_normal(), self return self new = classmethod(new) def is_normal(self): # For debugging only. w, x, y, z = self return abs(w*w + x*x + y*y + z*z - 1.) epsilon and w = 0. def __eq__(self, other): w1, x1, y1, z1 = self w2, x2, y2, z2 = other return abs(w1-w2) + abs(x1-x2) + abs(y1-y2) + abs(z1-z2) epsilon def __ne__(self, other): return not self == other def __mul__(self, other): w1, x1, y1, z1 = self w2, x2, y2, z2 = other return Quaternion.new(w1*w2 - x1*x2 - y1*y2 - z1*z2, w1*x2 + x1*w2 + y1*z2 - z1*y2, w1*y2 + y1*w2 - x1*z2 + z1*x2, w1*z2 + z1*w2 + x1*y2 - y1*x2) def __div__(self, other): w1, x1, y1, z1 = self w2, x2, y2, z2 = other return Quaternion.new( w1*w2 + x1*x2 + y1*y2 + z1*z2, -w1*x2 + x1*w2 - y1*z2 + z1*y2, -w1*y2 + y1*w2 + x1*z2 - z1*x2, -w1*z2 + z1*w2 - x1*y2 + y1*x2) def __rdiv__(self, other): if not isinstance(other, (int, long, float)): raise TypeError(unsupported operand type(s) for /) w, x, y, z = self return Quaternion.new(w, -x, -y, -z) __truediv__ = __div__ __rtruediv__ = __rdiv__ def euler(self): w, x, y, z = self x2 = x + x y2 = y + y z2 = z + z xx2 = x2*x yy2 = y2*y zz2 = z2*z wx2 = x2*w wy2 = y2*w wz2 = z2*w xy2 = x2*y yz2 = y2*z zx2 = z2*x siny = wy2 - zx2 if abs(abs(siny) - 1) epsilon: return Euler.new(math.asin(siny), math.atan2(yz2 + wx2, 1. - xx2 - yy2), math.atan2(xy2 + wz2, 1. - yy2 - zz2)) if siny 0.: y = half_pi else: y = -half_pi return Euler.new(math.atan2(-(yz2 - wx2), 1. - xx2 - zz2), y, 0.) def matrix(self): w, x, y, z = self x2 = x + x y2 = y + y z2 = z + z xx2 = x2*x yy2 = y2*y zz2 = z2*z wx2 = x2*w wy2 = y2*w wz2 = z2*w xy2 = x2*y yz2 = y2*z zx2 = z2*x return Matrix(1. - yy2 - zz2, xy2 + wz2, zx2 - wy2, xy2 - wz2, 1. - xx2 - zz2, yz2 + wx2, zx2 + wy2, yz2 - wx2, 1. - xx2 - yy2) -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: computer algebra packages
[Florian Diesch] Probably this is usable for you (I never used any of them): This system MAXIMA is [...] based on the original implementation of Macsyma at MIT [...] Wow! A derivative of Joel Moses' integrator!! I was not aware this existed, so thanks for the pointer. It worked out of the box for me! Description: A user-friendly frontend for MAXIMA Mascyma is (trying to be) a user-friendly graphical frontend for the Computer Algebra System GNU MAXIMA. It is written in Python and provides two GUIs, one of which based on PyGTK, the other based on wxPython. I was not successful googling for this one. Would you have an URL handy? -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: computer algebra packages
[Robert Kern] François Pinard wrote: [Florian Diesch] Mascyma is (trying to be) a user-friendly graphical frontend for the Computer Algebra System GNU MAXIMA. It is written in Python and provides two GUIs, one of which based on PyGTK, the other based on wxPython. I was not successful googling for this one. Would you have an URL handy? Note the deliberate spelling, and cut-and-paste. Thanks. The `Mascyma' versus `Macsyma' subtlety escaped my scrutiny :-). http://home.arcor.de/mulk/projects/mascyma/index.xhtml.de Their CVS server (the only download choice) is not responding. So I'll forget Mascyma for now. Maxima does work, that's a lot already! :-) I perused what I could find about Python on algebra or symbolic calculus, and nothing I saw, so far, stands even a pale comparison with Maxima. -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: f*cking re module
[Mike Meyer] Steven D'Aprano [EMAIL PROTECTED] writes: Is there any possible sequence of bytes that will not be a valid Perl expression or operator? Perl has lots of syntax, and good warning facilities, it is not so bad. [...] TECO, where guessing what your name did as a command sequence was a popular past time? Yes, this is much more likely to be meaningful! Yet, don't laugh at this venerable editor. Remember that Emacs started as an *E*xtended set of TECO *mac*ros, as its name still say. :-) I once worked with a PL/I compiler (on a big IBM mainframe), which was trying to be helpful by spitting pages of: Error SUCH AND SUCH, assuming that THIS AND THIS was meant. and continuing compilation nevertheless. It was a common joke to say that PL/I would compile some random valid program out of any garbage! -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Compiler error recovery [was: Re: f*cking re module]
[Rocco Moretti] François Pinard wrote: I once worked with a PL/I compiler (on a big IBM mainframe), which was trying to be helpful by spitting pages of: Error SUCH AND SUCH, assuming that THIS AND THIS was meant. and continuing compilation nevertheless. It was a common joke to say that PL/I would compile some random valid program out of any garbage! We may laugh now (and then), but it was likely a valid design decision at the time. [...] Error-checking-by-compiling only works if you have cheap computing power you can run attended. (Can you imagine what TDD would be like if you had to wait 24+ hrs between code executions?) Of course, all granted.[1] The only way to be really productive, in those times, was to round-robin oneself between a dozen simultaneous projects, or so, pushing on each one in turn while concentrating hard to avoid spoiling one run, before resubmitting that project and moving to the next. This kind of seek for productivity was somehow exhausting for the mind. Nowadays, things are infinitely easier. Even if easier, Python is sadly original in stopping at the first syntax error, probably for avoiding all concerns about error recovery, which is not always an easy matter. I suspect it might be easier with Python than with many other languages. [1] PL/I was aggressively aiming both syntactic and semantic recovery. -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: distutils is able to handle...
[George Sakkis] I would suggest SCons (http://www.scons.org/), a modern make/automake/autoconf replacement that uses python for its configuration files instead of yet another cryptic half-baked mini-language or XML. Python might not be the most legible way to describe what a Makefile has to describe, it asks for more syntax that we really need. On the other hand, it is convenient having Python handy for extending the capabilities of your description file, that is, having Python has a provisional, supplementary card, instead the only and mandatory one. I'm exploring with some pleasure Bram Moolenaar's A-A-P tool (see http://www.a-a-p.org). This is implemented in Python, but does not force people into Python syntax for Makefiles. It might be a nicer compromise. As usual from Bram, documentation is abundant and useful. -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: Lisp development with macros faster than Python development?..
[Raymond Hettinger] [EMAIL PROTECTED] wrote: It got me curious if Lisp is inherently faster to develop complex apps in. With Lisp or Forth, a master programmer has unlimited power and expressiveness. With Python, even a regular guy can reach for the stars. A few years ago, I much hesitated between Scheme and Python as my next day-to-day programming language. My feeling at the time was that Scheme is a very fast language to write into, and in which one can implement new concepts cleanly and compactly. Maybe Python is a bit slower to write, but this is compensated by the fact Python is more legible when it comes to later maintenance, or when many people have to share work on a big set of sources. There is some heaviness and complexity in Python internals, Scheme are purer and simpler by comparison. On its bright side, Python has a nice and comprehensive library, and an interesting community of users. These probably make most of the difference. -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: f*cking re module
[D H] Gustavo Niemeyer wrote: That's what I love in that news group. Someone comes with a stupid and arrogant question, and someone else answers in a calm and reasonable way. ...and then someone else comes along and calls the first person stupid and arrogant, which is deemed QOTW. :) Hey! The question, not the person! One might say the subject, but then, it has to be the subject of the message, of course! :-) -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: map/filter/reduce/lambda opinions and background
[Ivan Van Laningham] [Tom Anderson] [Guido] I expect tons of disagreement in the feedback, all from ex-Lisp-or-Scheme folks. :-) I disagree strongly with Guido's proposals, and i am not an ex-Lisp, -Scheme or -any-other-functional-language programmer; my only other real language is Java. I wonder if i'm an outlier. So, if you're a pythonista who loves map and lambda, and disagrees with Guido, what's your background? Functional or not? I'm a pythonista who doesn't love them. Same here. `lambda' could go away. Yet `map' is sometimes useful... And I've spent months inside of Lisp/Emacs Lisp/Scheme [...] I worked on Lisp / Scheme / Emacs-Lisp for many dozens of years. Moreover, a few times for unusual machines, I implemented Lisps. (I have the world's second largest .emacs file [my friend Andy Glew has the largest], even though I can't use it on Windows;-). You are a shameless lier! :-) It just _cannot_ beat the size of mine, at least not so long ago when I still was an Emacs user. And despite its size, my .emacs worked on a lot of systems, Windows included. Personally, I find that Lisp its derivatives put your head in a very weird place. Lisp / Scheme are very OK! Usable for a wide range of applications, including system' -- with the proper choices, they can be fairly speedy as well. Yet, for ubiquitous and day-to-day work, Python is nicer! :-) -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: Assigning to None (was Re: Question about Python)
[Peter Hansen] Mike Meyer wrote: Yes. I once grabbed an old program that did assignments to None. But that's always been a bad idea. What was the use case!? People used to assign None to itself as a keyword argument in function headers. The goal was to make a local copy of the reference, which was then accessed faster than the global thing. -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: Assigning to None
[Roy Smith] 4) foo, bar = gen_tuple(stuff)[0:1]. In some ways, this is the cleanest because it doesn't pollute the namespace with an un-needed variable, but I think it's the least readable. Less legible often means more error prone. For example, here, foo, bar = gen_tuple(stuff)[:2] would work better. -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: Assigning to None
[Rocco Moretti] foo, bar, _ = gen_tuple(stuff) as '_' is already special cased (last result in interactive mode), and is already used for don't care sematics in Prolog. `_' is also the `gettext' function in internationalised programs. It so seems that `_' is in great demand! :-) -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: staticmethod and classmethod
[Bruno Desthuilliers] C Gillespie a écrit : Does anyone know of any examples on how ( where) to use staticmethods and classmethods? Here's an example from a ldap lib [...] I recently had a use case for class methods while converting a PL/I program to Python: a lot of global declarations, where in many cases, procs could be regrouped around well identified subsets of globals. The idea is to create a class for each related group of globals. The global declarations themselves become class variables of that class, and related procs become class methods meant to act on these class variables. For best clarity and legibility while doing so, one should use all lowercase class names in such cases, and use `self' instead of `cls' for the first formal argument of class methods[1]. Then, one use these classes as if they were each the single instance of a similar class with usual methods. If one later changes his/her mind and wants more usual objects, and not allocated statically (!), merely remove all classmethod declarations, capitalise the first letter of class names, and create one instance per class into the all lowercase name of the class. That's seemingly all. -- [1] I already found out a good while ago, in many other cases unrelated to this one, but notably in metaclasses, that `self' is often (not always) clearer than `cls'. Classes are objects, too! :-) -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
German spam event [was: Re: Schily ueber Deutschland]
[Paul Rubin] I don't think that post was really from MAL. It seems to be a sporgery attack on the newsgroup. Sigh. For the last two days, I receive quite an amount of robotic rejects, after my name was used as the forged From: for an apparently massive spam invoice written in German. At the same time, I noticed an increase of German-written spam filtering through a few lists I'm subscribed to, and the Python list among others. Such forged From appears all the time as far as I am concerned, and had for years now. But something significant happened this weekend. -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: pyvm -- faster python
[Paul Rubin] It's true that CPython doesn't have a compiler and that's a serious deficiency. Hi, Paul. I did not closely follow all of the thread, so maybe my remark below, only repeats what others might have said and I missed? Deep down, why or how not having a [traditional, to-native-code] compiler is a deficiency for CPython? We already know that such a beast would not increase speed so significantly, while using much more memory. It is true that a standard traditional compiler for CPython would allow one would be to check the box: [x] has a compiler in the fashion of the day language information sheet, and for some readers, not having that box checked is a deficiency in itself. :-) So far, it seems that the only way to get speed is to attach static type information to some variables. Some compilation avenues do it through information added either in Python source code or in extraneous declarative files, other approaches do it by delaying compilation until such information is discovered at run-time. The former taints the purity of real CPython as the only source. The later often shows spectacular speed gain, but not always, and may bloat size unboudedly. -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: How return no return ?
[Ximo] I want that the return sentence don't return anything, how can I do it? `return' always return something (if we except the case of generators). Used without arguments, it returns None, as you discovered already. If a function falls through its end, None is implicitely returned. A function always have a value. I do not understand the need of not returning anything. What do you mean? What is the real need? [...] pass don't run too. `pass' surely runs. However, `pass' is not a `return' statement. -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: pyvm -- faster python
[Paul Rubin] François Pinard [EMAIL PROTECTED] writes: Deep down, why or how not having a [traditional, to-native-code] compiler is a deficiency for CPython? We already know that such a beast would not increase speed so significantly, while using much more memory. I'd say the opposite. The 4x speedup from Psyco is quite significant. The speedup would be even greater if the language itself were more compiler-friendly. Psyco is not a traditional compiler. Compilation occurs at run-time, as typing information is not available without observation. So far, it seems that the only way to get speed is to attach static type information to some variables. No of course not, there's quite a bit of overhead in interpretation in general. Plus, having to do a dictionary lookup for 'bar' in every call like foo.bar() adds overhead and I don't think I'd call fixing that as similar to adding static type info. The dictionary lookup does not occur for local variables. Changes are planned in Python so lookups may be avoided in a few cases of global variables. But until (and despite!) such changes occur, compilation does not buy you much, here. This has been much studied and debated. Some compilation avenues do it through information added either in Python source code or in extraneous declarative files, other approaches do it by delaying compilation until such information is discovered at run-time. Also, lots of times one can do type inference at compile time. Yes, particularily in simple or small programs. I vaguely remember that the unborn Viper (or Vyper?) was promising compile time type inference. It seems that so far, in many years, no one really succeeded in demonstrating a definite advantage in this direction, at least, not enough for the community to follow in. The former taints the purity of real CPython as the only source. I don't understand this. What purity? Why is real CPython the only source? There are dozens of C compilers and none of them is the only source. Why should Python be different? Because it is. There are not dozens of Python compilers. A few, maybe. Pyrex gives me a lot of speed, given I taint my Python sources with cdefs, ctypes, etc. Oh, I'm absolutely happy with Pyrex when I starve for speed, but I know and you know that we are not writing pure Python then. And if, for not touching sources, one supplements them with separate declarative files, my Python code may look pure, but I have to maintain those files as well, and Python is not my only source anymore. So, to get back to the origin of our argument, I'm still not tempted to think that Python not having a compiler makes it deficient, because having a compiler (at least in the traditional acceptation of the term) would not buy it much enough. -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: pyvm -- faster python
[Stelios Xanthakis] I'm afraid this may end up dead before unborn too. So it depends what people want. If nobody cares, [...] People might not care so much about what could be done about your project, unless you give them proper and complete means for evaluating the state of affairs. Your project is very likely to die if you keep your sources closed, and yourself loose interest in the project. Opening your sources is no guarantee either that the community will adopt your project. But this might give your project a better chance. -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: Q: The `print' statement over Unicode
[Thomas Heller] François Pinard [EMAIL PROTECTED] writes: [...] given file `question.py' with this contents: # -*- coding: UTF-8 -*- texte = unicode(Fran\xe7ois, 'latin1') print type(texte), repr(texte), texte print type(texte), repr(texte), str(texte) doing `python question.py' yields: type 'unicode' u'Fran\xe7ois' François type 'unicode' u'Fran\xe7ois' Traceback (most recent call last): File question.py, line 4, in ? print type(texte), repr(texte), str(texte) UnicodeEncodeError: 'ascii' codec can't encode character u'\xe7' \ in position 4: ordinal not in range(128) [...] why is the first `print' working over its third argument, but not the second? How does `print' convert that Unicode string to a 8-bit string for output, if not through `str()'? What is missing to the documentation, or to my way of understanding it? AFAIK, print uses sys.stdout.encoding to encode the unicode string. Much thanks for this information. I was not aware of this file attribute. Looking around, I found a quick description in the Library Reference, under 2.3.8 File Objects. However, I did not find in the documentation the rules stating how or when this attribute receives a value, and in particular here, for the case of `sys.stdout'. The Reference Manual, under 6.6 The print statement, is silent about how Unicode strings are handled. Am I looking in the wrong places, or else, should not the standard documentation more handily explain such things? -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: Q: The `print' statement over Unicode
[Martin von Löwis]
François Pinard wrote:
Am I looking in the wrong places, or else, should not the standard
documentation more handily explain such things?
It should, but, alas, it doesn't. Contributions are welcome.
My contributions are not that welcome. If they were, the core team
would not try forcing me into using robots and bug trackers! :-)
The algorithm to set sys.std{in,out}.encoding is in
sysmodule.c:_PySys_Init and pythonrun.c:Py_InitializeEx
and goes roughly as follows:
- On Windows, if isatty returns true, use GetConsoleCP and
GetConsoleOutputCP.
- On Unix, if isatty returns true, langinfo.h is present,
CODESET is defined, and nl_langinfo(CODESET) returns a
non-empty string, use that.
- otherwise, .encoding will not be set.
Thanks. Your kind explanation, above, should make it, as is, somewhere
in the documentation -- until Xah decides to rewrite it, of course! :-).
--
François Pinard http://pinard.progiciels-bpi.ca
--
http://mail.python.org/mailman/listinfo/python-list
Re: How To Reply
[Peter Hansen] You are forced to cut and paste if you want to get the messages in a digest. I doubt any mail program has been designed to know how to do anything smarter, Lars Magne Ingebrigtsen's wonderful Gnus (a much boosted, combined news/mail reader, running within or over Emacs) knows about digests. (Moreover, with not so much trickery, it is Python extensible. I vaguely remember having written one or two Python backends for Gnus.) -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Q: The `print' statement over Unicode
Hi, people. I hope someone would like to enlighten me. For any application handling Unicode internally, I'm usually careful at properly converting those Unicode strings into 8-bit strings before writing them out. However, this morning, I mistakenly forgot to do so before using one Unicode string (containing a non-ASCII character) as an argument to the `print' statement, and I did _not_ get an error. This is rather surprising to me. I reread the section of the Python reference manual (version 2.3.4, this machine uses 2.3.3 currently), and it does not say anything about a special processing for Unicode strings. In my understanding, when `print' is given an argument which is not already a string (I read: 8-bit string), it first gets converted into a string (I read: calling __str__). But if I call `str()' explicitly, _then_ I get an error as expected. The question is, why is there no error if I do not call `str()' explicity? For example, given file `question.py' with this contents: # -*- coding: UTF-8 -*- texte = unicode(Fran\xe7ois, 'latin1') print type(texte), repr(texte), texte print type(texte), repr(texte), str(texte) doing `python question.py' yields: type 'unicode' u'Fran\xe7ois' François type 'unicode' u'Fran\xe7ois' Traceback (most recent call last): File question.py, line 4, in ? print type(texte), repr(texte), str(texte) UnicodeEncodeError: 'ascii' codec can't encode character u'\xe7' \ in position 4: ordinal not in range(128) (last line wrapped for legibility). So (trying to be crystal clear), why is the first `print' working over its third argument, but not the second? How does `print' convert that Unicode string to a 8-bit string for output, if not through `str()'? What is missing to the documentation, or to my way of understanding it? -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: WordPress Python Library 1.0
[Michele Ferretti] http://www.blackbirdblog.it/programmazione/progetti/28 Quoted above, the full content of your article. Is it a message? It surely does not look like an English sentence. Should we start a browser each time we see an URL? Many of us are not in such an Internet starvation. If you want to raise our appetite, maybe a few words of introduction or explanation would be welcome. :-) -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: compare two voices
[Qiangning Hong] I just want to compare two sound WAVE file, not what the students or the teacher really saying. For example, if the teacher recorded his standard pronouncation of god, then the student saying good will get a higher score than the student saying evil because good sounds more like god. If I had this problem and was alone, I would likely create one audiogram (I mean a spectral frequency analysis over time) for each voice sample. Normally, this is presented with frequency on the vertical axis, time on the horizontal axis, and gray value for frequency amplitude. There are a few tools available for doing this, yet integrating them in another application may require some work. Now, because of voice pitch differences and elocution speed, the audiograms would somehow look alike, yet scaled differently in both directions. The problem you now have is to recognise that an image is similar to part of another, so here, I would likely do some research on various transforms (like Hough's and any other of the same kind) that might ease normalisation prior to comparison. Image classification techniques (they do this a lot in satellite imagery) for recognizing similar textures in audiograms, and so, clues for matching images. A few image classification programs which have been previously announced here, I did not look at them yet, but who knows, they may be helpful. Then, if the above work is done correctly and meaningfully, you now want to compute correlations between normalised audiograms. More correlated they are, more likely the original pronunciation were. Now, if I had this problem and could call friends, I would surely phone one or two of them, who work at companies offering voice recognition devices or services. They will be likely reluctant at sharing advanced algorithms, as these give them industrial advantage over competitors. I try to use the value returned from rms(add(a, mul(b, -findfactor(a, b as the score. But the result is not good. Oh, absolutely no chance that such a simple thing would ever work. :-) -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Rudeness on this list [Re: rudeness was: Python licence again]
[Michael Hoffman] [EMAIL PROTECTED] wrote: I started to read the postings on this list and was dismayed at the depth of rudeness on here. I saw no evidence of rudeness whatsoever. [...] It may be related to cultural differences, who knows. Some people are sensible to rude behaviour or language, while others just do not notice: I might guess they grew and learned to live in such environments. As seen from here, the Python mailing list quality has been degrading significantly for the last half-year or so. It is a bit unavoidable as Python gains popularity and attracts people of all obediences. One helping attitude, for everybody, would be to remember that we have readers from everywhere on this planet, and that softness and politeness is probably a good common denominator for people to be happy on the average. If you happen to live in a harsh country, best is to become conscious of the difference, and try to respect others. Do you remember those years when Tim Peters was our effective softening device? The list was then one of the nicest place one can be. After a few polite replies, abusive people were generally ignored by all members, and even institutional flamers were getting discouraged by the lack of fuel, eventually leaving for elswehere. Nice times indeed! :-). -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: def a((b,c,d),e):
[George Sakkis] François Pinard wrote: The most useful place for implicit tuple unpacking, in my experience, is likely at the left of the `in' keyword in `for' statements (and it is even nicer when one avoids extraneous parentheses). ... and would be nicest (IMO) if default arguments and *varargs were allowed too; check http://tinyurl.com/dcb2q for a relevant thread. It's appealing, indeed, trying to create more uniformity between tuple unpacking and argument passing. There are two approaches towards such uniformity, either upgrading tuple unpacking (as the above thread discusses) or downgrading argument passing (as suggested by those who found atrocious the current behaviour). I started recently to study the R system and language, and saw many good ideas in there about argument passing. Translated in Python terms, it would mean that `*varargs' and `**keywords' are not necessary last, that named keywords may be intermixed with positional keywords, that keywords may be abbreviated, and much more hairy, that the default values for keywords are not pre-evaluated at `def' time, and that the computation of actual expressions given as arguments is lazily postponed until their first use within the function. It surely looks all strange at first, but these choices are surprisingly productive in practice, as I merely begin to understand. Curious minds may start at http://cran.r-project.org/doc/manuals/R-lang.html#Arguments and read down. I do not know if there will ever be cross-pollinisation between R and Python, but I would guess good things might came out of this... -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: def a((b,c,d),e):
[George Sakkis] Allowing non-default arguments after *varargs doesn't make sense, In R, one may use the ... format argument anywhere in the argument list, but may later test if a non-default argument was provided or not. I tend to write R a bit like I would write Python, but hopefully, I'll eventually understand R enough that I could break that habit. keywords may be abbreviated, and much more hairy, Hmm.. -1 on this. It may save a few keystrokes, but it's not good for readability and maintenability. That was my first impression too. Yet, interactively, I found that feature very convenient. Already with Python, I use shortcuts interactively that I would not write nor keep in real, saved, permanent programs. And for very common functions and features, which are not really fluctuating anymore, some abbreviations became well known idioms. the computation of actual expressions given as arguments is lazily postponed until their first use within the function. Is this like an implicit lambda before each argument ? Not exactly true, but that's surely a way of understanding it. Such things are not new: I first saw them in Algol-60, except that once an argument has been evaluated, it is cached and not evaluated again. It's true that in R, much more than in Python, evaluation of an argument may often be computationally expensive. Moreover, in R, the initial writing of the argument is preserved on the form of a parsed tree which can be operated upon. This allow for strange things (at least for a Python eye), like computing the symbolic derivative of an argument. I toyed with this facility to build mathematical images, and then, animations. For an exemple, see: http://pinard.progiciels-bpi.ca/plaisir/NRart/ and from there, click on `nr.image' near the end. If so, why does it have to be restricted to function arguments ? It seems to me that argument passing and lazy evaluation are orthogonal dimensions. In R, laziness is automatic while calling functions, but not otherwise, and from what I saw so far, less meaningful in other contexts anyway. However, I think laziness is available explicitely if needed (there is library function that returns a promise of its argument). Or for a more exotic use: def prologLikeSum(a=s-b, b=s-a, s=a+b): return a,b,s prologLikeSum(1,2) == prologLikeSum(1,s=3) == prologLikeSum(b=2,s=3) == (1,2,3) This is exactly how R people use the feature most of the times (at least so far that I naively saw, as I'm still pretty new at all this). This seems pretty hard to change though. Oh, I would not even dream about it for Python. The idea would have to make its way first within the developers, and this might take years, if ever. The best I (we) could do is keep the idea in the air, for a good while. It would likely never survive all the debates it would generate. But who knows! :-) [...] and even worse, [bindings] would have to be computed for each call, as the prologLikeSum example shows. Yet, already, as it stands, argument passing in Python is not innocuous. A bit more, a bit less, nobody would notice! :-) -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: def a((b,c,d),e):
[Diez B. Roggisch] AdSR wrote: It appears that you can specify a function explicitly to take n-tuples as arguments. [...] Has anyone actually used it in real code? I do not use it often in practice, but sometimes, yes. If the feature was not there, it would be easy to do an explicit tuple unpacking from the argument at the start of the function. It allows me to spare inventing a name for the compound formal argument. :-) [...] as a limited form of pattern-matching [...] In one application, written long ago, I had a flurry of functions kept in a list, which were tried in turn until the call does not raise an Exception, so indicating a match. Since then, I used other means, first hoping to save at least the time it takes for creating a traceback object (but I did not time it), and later trying to get a better-than-linear time while trying to find the correct function. I never considered the feature to be atrocious. Implicit tuple unpacking occurs in a few places in Python already, it is only elegant that it also occurs while functions receive their argument. The most useful place for implicit tuple unpacking, in my experience, is likely at the left of the `in' keyword in `for' statements (and it is even nicer when one avoids extraneous parentheses). -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: Compute pi to base 12 using Python?
[Doug Schwarz] The chromatic scale is based on one twelfth powers of two, i.e., if the frequency of a note in the scale is f(n), then the frequency of the next note is given by f(n+1) = f(n) * 2^(1/12) This easy view of things has been known for a long time, but has only been popular (relatively) recently. Traditionally, scale designers were definitely running after rational proportions between scale notes, not fearing some problems they necessarily create, because such scales are often nicer and interesting to the musical ear. I should relate this discussion to Python somehow! :-) Easy, as I have a few Python programs doing various scale computations -- I should try to bundle these together somewhere in my personal Web site, some day... -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: Compute pi to base 12 using Python?
[Bengt Richter] It might also be interesting to keep a running sum of the base 12 values and use sum % 88 to select piano keys, to let it walk intervals outside of a single octave ;-) The generated would then run from the low octaves to high octaves monotically, then start over again and again. Maybe a more interesting approach might be to pick the note in the same octave, the octave below or above, where the new note is closest to the preceding one. a random walk picture was interesting. Using the closest note would have similarity with a random walk, given digits are seemingly random. On a random walk, one gets away from the departure point on average, the distance being proportional to sqrt(N) where N is the number of steps. So, when using the closest note, one would need a corrective device nevertheless so notes are kept near the middle of the range of comfortable audible frequencies. Anyone have an easy python midi interface for windows to play on the sound card? I could generate a .wav file to play tones, but midi would be much more compact ;-) There are surely many. I use my own (Python) interfaces on Linux, and even there, by combining a few tools, it is rather easy to get .WAV files out of MIDI. In any case, googling around might help. -- Franois Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: Lambda: the Ultimate Design Flaw
[Aahz] I'll agree that Python currently has many examples of more than one way to do things (and even Python 3.0 won't remove every example [...]). But I won't agree that Only One Way has been abandoned as a design principle. To summarize, instead of saying Python has only one way to do it, rather say Python will eventually have only one way to do it, and with such a wording, nobody will not be mislead. -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: Lambda: the Ultimate Design Flaw
[Aahz] [François] Many of us are using Python today, week after week, year long. So let's be pragmatic. Python is what it became and now is. Let's not define it as a memory from the past nor as a futuristic dream. You're free to continue using 1.5.2. [...] Sure, of course. Yet, our friendly argument is sliding away from was it originally was. The point was about not asserting in this forum that Python has only one way to do it, because this is not true anymore. The principle has been, it may be back in some distant future, but now it is not. -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: Best editor?
[Harry George] 5. When I do Extreme Programming, the other author(s) tend to be using emacs, vim, or nedit. [...] Speaking of, when everybody uses Emacs, there is a way for Emacs for allowing many users, each on a different networked machine, all on the very same buffer, simultaneously. This sharing has been useful to us in a number of occasions, and we had scripts for quickly initiating such collaboration at any time (resolving `xauth' matters, for example). Note that it requires a lot of confidence between the collaborating users, as they all have extended powers on the editing session. -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: Best editor?
[John J. Lee] François Pinard [EMAIL PROTECTED] writes: [...] Overall, Vim is also cleaner than Emacs, and this pleases me. [...] Is this still true when comparing XEmacs vs. vim? (rather than GNU Emacs vs. vim) I've always used GNU Emacs, but I have got the impression that XEmacs is (was?) cleaner in some ways. I have much less experience with XEmacs. One friend of mine (Horvje) is quite involved in XEmacs development, and he convinced me to give it a serious and honest try. I did, yet never as deeply as I learned Emacs. My feeling has been that XEmacs, despite cleaner and offering a lot, in the realm of attractive chrome and original features, is slower overall and a bit less stable than GNU Emacs (Richard just _hates_ when one opposes XEmacs to GNU Emacs, and by doing so, involuntarily suggesting that XEmacs might not be GNU! But I'm not in GNU politics nowadays! :-). What most discouraged me is that fact that, at the time of my tries, neither Allout nor RMAIL were supported, both of which I was heavily using[1]. And also a few other gooddies as well. I know from users that Pymacs, which allows for Python usage from within Emacs, is supported in XEmacs just as well as in GNU Emacs. [1] Now in Vim, I switched from RMAIL to plain `mbox', and now use Mutt as a mail user agent -- which I find blazingly speedy even on big folders. For Allout, I rewrote an Allout support for Vim, as I could not walk away from it -- alternative solutions were too heavy. -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: Best editor?
[Aahz] Use vim. 80% of the power of emacs at 20% of the learning curve. I used Emacs for a long while, and learned it a bit thoroughly. I also learned Vim mor recently, and still have many things to study. See http://pinard.progiciels-bpi.ca/opinions/editors.html for some (incomplete) thoughts on both, Emacs in particular. If you do only light use of editors, both Emacs and Vim are rather easy, despite tinily annoying for some details, each its own details :-). If you deeply use them, they both require a lot of learning, eventually. Emacs does a few things that are difficult in Vim, but we can usually live without those few things, not overly missing them. Both editors are also extensible with Python, and Vim does Python a bit more nicely. Overall, Vim is also cleaner than Emacs, and this pleases me. This in between light and deep use that Aahz is most right: Vim offers many niceties that undoubtedly require some learning, yet significantly less than Emacs. Emacs has a lot more knobs to adjust, which is not always so advantageous for average users, and overkill for casual users. Whatever Emacs or Vim, learn to extend it with Python. There, you get a great deal of added power and flexibility for almost free, assuming and given that you already are a Python lover. -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: sparse sets of integers?
[runes] You have sets in Python 2.3x and 2.4x. I don't know if they can handle your amounts of data, but i guess so. The original poster (OP) spoke about 10**13 numbers, if I remember correctly (I did not keep the original message). It all depends on the real sparsity of the spare sets! :-) If not sparse enough, this might be a bit inordinate for standard Python sets on most machines, also given that each Python integer uses a lot more than 4 bytes... On the other hand, the OP also wrote that the numbers he handles are grouped in big and compact intervals, separated by big unpopulated holes. So maybe his data could be represented in Python as a user-written type hiding a sorted list of intervals, for which it should be relatively easy to write set functions. That might make the problem tractable enough, with reasonably speedy processing. As last resort, the wanted sets could be represented as sorted files of numbers. Slower, but set operations would also be easy to write. -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: Lambda: the Ultimate Design Flaw
[Sunnan] [...] for Pythons ideal of having one canonical, explicit way to program. No doubt it once was true, but I guess this ideal has been abandoned a few years ago. My honest feeling is that it would be a mis-representation of Python, assertng today that this is still one of the Python's ideals. -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: Lambda: the Ultimate Design Flaw
[Aahz] =?iso-8859-1?Q?Fran=E7ois?= Pinard [EMAIL PROTECTED] wrote: No doubt it once was true, but I guess this ideal has been abandoned a few years ago. My honest feeling is that it would be a mis-representation of Python, assertng today that this is still one of the Python's ideals. Mind providing evidence rather than simply citing your feelings? The important word was honest, not feeling. :-) Yes, there's certainly redundancy in Python right now, [...] See here, I'm not asking you for proofs. :-) but a large portion of that will go away in Python 3.0. And when will that be? The principle of there is only way to do it was observable in Python 1.5.2, and started to disappear at that time. How many years between 1.5.2 and 3.0? So where's the abandonment of the ideal? Many of us are using Python today, week after week, year long. So let's be pragmatic. Python is what it became and now is. Let's not define it as a memory from the past nor as a futuristic dream. -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: Specifying __slots__ in a dynamically generated type
[Ron Garret] Is it really impossible to specify __slots__ using the type constructor? It does not work? I vaguely remember having needed to do this once or twice, and it worked immediatly as expected. Unless I remember wrongly, you only have to preset `__slots__' in the dict you give to `type'. -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
[Tutor] Re: What is object()
[Hameed Khan] and what are new style classes?. http://www.python.org/2.2.3/descrintro.html is a good read on this subject. -- François Pinard http://www.iro.umontreal.ca/~pinard ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor -- http://mail.python.org/mailman/listinfo/python-list
Re: intrusive posts
[Tim Churches] Charles Hartman wrote: On Mar 23, 2005, at 7:10 PM, [EMAIL PROTECTED] wrote: Is there no way of filtering this recurring offensive material from the list? Yes: http://spambayes.sourceforge.net/ Works a treat. Likely, the question was pertaining to ways by which the submission to the mailing list could be filtered at the mailing list level (using Spambayes, or any other mean). The mailing list already uses filters, which seem to not be effective for the quoted spam. The question was likely not about how each and every of the list members should filter the list contents on his/her own. -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: a program to delete duplicate files
[Patrick Useldinger] Shouldn't you add the additional comparison time that has to be done after hash calculation? Hashes do not give 100% guarantee. If there's a large number of identical hashes, you'd still need to read all of these files to make sure. Identical hashes for different files? The probability of this happening should be extremely small, or else, your hash function is not a good one. I once was over-cautious about relying on hashes only, without actually comparing files. A friend convinced me, doing maths, that with a good hash function, the probability of a false match was much, much smaller than the probability of my computer returning the wrong answer, despite thorough comparisons, due to some electronic glitch or cosmic ray. So, my cautious attitude was by far, for all practical means, a waste. Similar arguments apply, say, for the confidence we may have in probabilistic algorithms for the determination of number primality. -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: shuffle the lines of a large file
[Joerg Schuster] I am looking for a method to shuffle the lines of a large file. If speed and space are not a concern, I would be tempted to presume that this can be organised without too much difficulty. However, looking for speed handling a big file, while keeping equiprobability of all possible permutations, might be sensibly more difficult. I vaguely remember having read something along these lines (not shuffling as you mean it, but still, reorganising a lengthy file) in Knuth's Art of Computer Programming, in one of the exercises within the chapter on Sorting methods (volume 3). That's long ago, but if I remember well, Knuth did not consider this as an easy exercise. -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: shuffle the lines of a large file
[Heiko Wundram] Replying to oneself is bad, [...] Not necessarily. :-) -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: Trees
[Alex Le Dain] Is there a generic tree module that can enable me to sort and use trees (and nodes). Basically having methods such as .AddNode(), .GetAllChildren(), .FindNode() etc. Is this handled natively with any of the core modules? Using only standard Python, look at the suite of `xml...' modules. cheers, Alex. P.S. - Your signature and company disclaimer use more than 30 lines. That's really a lot. I hope you can bring them down to reason! :-) -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: [ANN] Python 2.4 Quick Reference available
[Michael Hoffman] To be honest I doubt open will be extended in this manner. I did not read Guido's arguments for a while, so I may remember them wrongly. So, take me with a grain of salt. I would not think Guido is arguing for the sole sake of arguing. Maybe his plans or visions will change, but until such changes are announced, I've no reason to doubt them :-). All in all, `file' is now probably to be considered safer than `open', despite Guido advises to prefer `open'. -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: What's wrong with `is not None`?
[Stefan Behnel] Frans Englich schrieb: What is the equivalent expression which is more secure; `!= None`? If I want to check for None, I always do it with is. It's a constant after all... So do I. There is only one None object, for which an `is' test is especially appropriate. -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: A great Alan Kay quote
[Peter Hansen] Then Perl is an agglutination of styles, while Python might be considered a crystallization of features... Grosso modo, yes. Yet, we should recognise that Python agglutinated a few crystals in the recent years. :-) It gave up some of its purity for practical reasons. We got rather far from the There is only one way to do it! that once was Python motto. -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: a new Perl/Python a day
[Andy Gross] On Jan 10, 2005, at 12:11 AM, Scott Bryce wrote: No. Perl may have some interesting idiosyncrasies I [...] still have to look at the documentation to remember that I need to type '$|' to turn buffering off. Ditto for the rest of the perl line-noise syntax. Behind each language, there is a culture. The Perl man pages give many mnemonic tricks to remember special variable names like the above, and if you are willing to play the game the way it was written, you might even have some fun at it, and easily be proficient at this line-noise. I did a lot of Perl for many years, and still appreciate what Perl is (or at least was). Python does not change Perl in my eyes. However, Python is significantly more legible and maintainable, the comparison merely stresses the unreadability of Perl. No doubt that I prefer Python, but Python not being there, Perl would be quite useful to me. -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: A rational proposal
[Batista, Facundo] To convert a Decimal to Rational, [...] Hi, people. I am not closely following this thread and do not know if this has been discussed before. Sorry if I'm repeating known arguments... Decimal to Rational is easy. The interesting problem is how to best convert a float to Rational. For example, do we want pi (3.1415926...) converted as 3, 22/7 or 355/113? This pretty much depends of the error we are ready to tolerate. We do not always want a hairy Rational. Given a tolerance, the question is to find the simplest Rational corresponding to a float. I once needed to solve that particular problem, and gave myself a Rational type merely (I called it Fraction). Let me append it here, in case it could be useful to your project. If you provide the constructor with a float and no tolerance, it should yield the best possible Rational for the float representation on that machine. -- François Pinard http://pinard.progiciels-bpi.ca #!/usr/bin/env python # Copyright 2000 Progiciels Bourbeau-Pinard inc. # Franois Pinard [EMAIL PROTECTED], 2000. def Fraction(num, den=1, tolerance=0): \ Return the _simplest_ fraction approximating NUM/DEN, given that the approximation error may not exceed TOLERANCE. The returned fraction has a special type which may be used in later numeric computations. if type(0.) in (type(num), type(den)): num, den = num/den, 1L while long(num) != num: num, den = 2.*num, 2L*den num = long(num) elif den 0: num = -num den = -den d = gcd(abs(num), den) value = SimplifiedFraction(num/d, den/d) if tolerance 0: value = ContinuedFraction(value, tolerance).simplify() return value class SimplifiedFraction: triples = 0 # set to 1 for a:b:c printing def __init__(self, num, den): self.num = num self.den = den def __repr__(self): num = self.num den = self.den if den == 1: return '%.f' % num if self.triples: if num 0 and num den: return '%.f:%.f:%.f' % (num / den, num % den, den) if num 0 and -num den: return '-%.f:%.f:%.f' % (-num / den, -num % den, den) return '%.f:%.f' % (num, den) def __coerce__(self, other): if isinstance(other, SimplifiedFraction): return self, other if type(other) in (type(0), type(0L)): return self, SimplifiedFraction(other, 1) if type(other) is type(0.): return float(self), other def __int__(self): if self.num 0: return -(-self.num / self.den) return self.num / self.den def __float__(self): return float(self.num) / float(self.den) def __neg__(self): return SimplifiedFraction(-self.num, self.den) def __pos__(self): return self def __abs__(self): return SimplifiedFraction(abs(self.num), self.den) def __cmp__(self, other): d = gcd(self.den, other.den) if d == 1: return cmp(self.num*other.den, other.num*self.den) return cmp(self.num*(other.den/d), other.num*(self.den/d)) def __add__(self, other): d1 = gcd(self.den, other.den) if d1 == 1: return SimplifiedFraction(self.num*other.den + other.num*self.den, self.den*other.den) t = self.num*(other.den/d1) + other.num*(self.den/d1) d2 = gcd(t, d1) return SimplifiedFraction(t/d2, (self.den/d1) * (other.den/d2)) def __sub__(self, other): d1 = gcd(self.den, other.den) if d1 == 1: return SimplifiedFraction(self.num*other.den - other.num*self.den, self.den*other.den) t = self.num*(other.den/d1) - other.num*(self.den/d1) d2 = gcd(t, d1) return SimplifiedFraction(t/d2, (self.den/d1) * (other.den/d2)) def __mul__(self, other): d1 = gcd(self.num, other.den) d2 = gcd(self.den, other.num) return SimplifiedFraction((self.num/d1) * (other.num/d2), (self.den/d2) * (other.den/d1)) def __div__(self, other): d1 = gcd(self.num, other.num) d2 = gcd(self.den, other.den) return SimplifiedFraction((self.num/d1) * (other.den/d2), (self.den/d2) * (other.num/d1)) def __radd__(self, other): return other.__add__(self) def __rsub__(self, other): return other.__sub__(self) def __rmul__(self, other): return other.__mul__(self) def __rdiv__(self, other): return other.__div__(self) def gcd(a, b): while b: a, b = b, a % b return a class ContinuedFraction: def __init__(self, value, tolerance): integer = int(value) residual = value - integer self.integers = [integer] while residual != 0 and abs(value - self.simplify()) tolerance
Re: Sorting in huge files
[Paul] Thanks! I definitely didn't want to go into any elaborate programming for this, and the Unix sort is perfect for this. It sorted a tenth of my data in about 8 min, which is entirely satisfactory to me (assuming it will take ~ 20 times more to do the whole thing). Your answer greatly helped! Paul I was to reply a bit more elaborately, but if you are happy with `sort' that's quite nice, you do have a solution. :-) One of my old cases was a bit more difficult in that the comparison algorithm was not _simple_ enough to easily translate into computing a key once, that could be then saved into the record. The comparison had to stay live with the sort and the whole somehow sort co-routined with the application. I wrote a dual-tournament sort aiming a polyphased merge, and transported the algorithm through machines and languages. Not so long ago, I finally saved the whole algorithm in Python for the record, but found it to be too slow to be practical for huge tasks. Nowadays, given the same kind of problem, the size and speed of machines is such that I would dare trying Timsort (the standard Python sort) over a mmap-ed file, right from within Python. My guess is that it could very reasonably work, despite requiring almost no development time. -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
