Dex Tracker .011 beta (tracker for csound) released
Dex Tracker beta .11 is out new features include a code generater for a simple sampler utilities for combing all files in a .csd/.orc A utility to remove all instruments from a orc/sco combination. The ability to place a help file in a .html or .txt file (other formats may be added later). The ability to use the old winsound from csound 4 (some assembly required). A handfull of instrumets that are already set up for use in the tracker. public domain tools Harmonise used to generate score files and space a file generator to be used with gen28 and to be used with csound opcode space are included in this version. csound command line help and csound utility list have been added as tools along with the command line. Files required to run the project are on the homepage. https://sourceforge.net/project/showfiles.php?group_id=156455package... -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations.html
Re: merits of Lisp vs Python
Paddy wrote: http://en.wikipedia.org/wiki/Doctest I pity the hoplelessly anti-intellectual douche-bag who inflicted this undergraduate misfeature upon the programming language. This must be some unofficial patch that still has a hope of being shot down in flames, right? -- http://mail.python.org/mailman/listinfo/python-list
play video file
hi... plase take me a simple code for a run a video file with tkinter??? or pymedia... thanks fabri -- http://mail.python.org/mailman/listinfo/python-list
doubt in curses module
hii, iam new to python. i want to use function keys in my program, so i went through the curses module, but in that module it shows a different window object and after pressing the our desired function key in it, that will return the ascii value of that key to the command prompt. so, i want to hide or dissable the window object, can anyone tell me how it will be possible... it is very urgent -- http://mail.python.org/mailman/listinfo/python-list
Re: need guidance on sending emails with attachment with python.
hi jonathan, it is understandable from your point of view I wont say you were rood. but my question was different. I am very new to doing programmed emails. all I need to know is that will I need to use outlook or any thing to send emails to pop3 or smtp? I want to know because I wont like to make use of outlook or any thing to do my work. I know the python libraries are there but I want to know what these libraries will make use of on my windows machine. Krishnakant. -- http://mail.python.org/mailman/listinfo/python-list
sys.stdin.encoding
The following line in my code is failing because sys.stdin.encoding is Null. This has only started happening since I started working with Pydef in Eclipse SDK. Any ideas? uni=unicode(word,sys.stdin.encoding) Thanks, Aine. -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Kaz Kylheku wrote: Paddy wrote: http://en.wikipedia.org/wiki/Doctest I pity the hoplelessly anti-intellectual douche-bag who inflicted this undergraduate misfeature upon the programming language. This must be some unofficial patch that still has a hope of being shot down in flames, right? Sour grapes. Eh :-) Or were you going to follow up with some intellectual argument to support your adjectives? 1. pity 2. hopelessly 3. anti-intellectual 4. douche-bag 5. inflicted 6. undergraduate 7. misfeature 8. unofficial patch 9. shot down in flames That's a lot of hate in 2 sentences for judging a novel feature you barely came across. -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
[EMAIL PROTECTED] ha escrito: - Lisp is hard to learn (because of all those parenthesis) I cannot understand why. It is like if you claim that packaging things in boxes is difficult to learn. HTML and XML have more brackets than LISP (usually double) for structuring data and everyone has learned HTML. -- http://mail.python.org/mailman/listinfo/python-list
Re: sys.stdin.encoding
[EMAIL PROTECTED] wrote: The following line in my code is failing because sys.stdin.encoding is Null. I'll guess you mean None rather than Null. This has only started happening since I started working with Pydef in Eclipse SDK. Any ideas? uni=unicode(word,sys.stdin.encoding) You could give it a fallback value: uni = unicode(word, sys.stdin.encoding or sys.getdefaultencoding()) or even just: uni = unicode(word, sys.stdin.encoding or 'ascii') which should be the same in all reasonable universes (although I did get bitten recently when someone had changed the default encoding in a system). -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Paddy wrote: Does Lisp have a doctest-like module as part of its standard distribution? No, and it never will. The wording you are using betrays cluelessness. Lisp is an ANSI standard language. Its distribution is a stack of paper. There isn't a ``standard distribution'' of Lisp any more than there is such a thing of C++. There are advantages to doctest being one of Pythons standard modules. There are also advantages in being able to tell idiots who have terrible language extension ideas that they can simply roll their own crap---and kindly keep it from spreading. This is generally what happens in intelligent, mature programming language communities. For instance, whenever someone comes along who thinks he has a great idea for the C programming language, the standar answer is: Wonderful! Implement the feature into a major compiler like GCC, to show that it's feasible. Gain some experience with it in some community of users, work out any wrinkles, and then come back. In the Lisp community, we can do one better than that by saying: Your feature can be easily implemented in Lisp and loaded by whoever wants to use it. So, i.e. don't bother. Lisp disarms the nutjobs who want to inflict harm on the world by fancying themselves as programming language designers. They are reduced to the same humble level as other software developers, because the best they can do is write something which is just optionally loaded like any other module, and easily altered beyond their original design or rejected entirely. Those who are not happy with the lack of worship run off an invent shitty little languages for hordes of newbies, being careful that in the designs of those languages, they don't introduce anything from Lisp which would land them in the same predicament from which they escaped. -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
[Paddy] http://en.wikipedia.org/wiki/Doctest [Kaz Kylheku] I pity the hoplelessly anti-intellectual douche-bag who inflicted this undergraduate misfeature upon the programming language. As a blind misshapen dwarf, I get far too much pity as it is, but I appreciate your willingness to share yours. If you like, feel free to give this precious gift to another. I get the impression that pity is something you don't feel often, and it would be a shame to waste it. This must be some unofficial patch that still has a hope of being shot down in flames, right? Alas, no. It was secretly snuck into Python's standard library in the 2.1 release (2001), and although we've done our best to hide it, it's widely used now. Strangely enough, it's especially popular among intellectuals ;-) -- http://mail.python.org/mailman/listinfo/python-list
Re: play video file
On 11 Dec 2006 00:10:59 -0800, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: hi... plase take me a simple code for a run a video file with tkinter??? or pymedia... thanks fabri -- http://mail.python.org/mailman/listinfo/python-list It cant be more simple than this but with pygame! most of the pymedia examples use pygame for overlay. http://godsongera.blogspot.com/2006/12/play-mpeg-file-with-python.html from pygame import display,movie overlay = display.set_mode((800,600)) m=movie.Movie(some.mpg) m.set_display(overlay) m.paly() -- Godson Gera, http://godson.auroinfo.com -- http://mail.python.org/mailman/listinfo/python-list
sovrascrivere
ciao.. ho creato i tasti con le immagini def creaImmagine(self): img = tk.PhotoImage(file=self.ico1) b = tk.Button(root, image=img, command=self.allaPressione) b.pack(side='left',padx=25) b.configure (width=80, height=80) b.image = img mi resta solo un problema.. questo metodo viene richamato più volte, ma i tasti non vengono sovrasritti bensì aggiunti (a sinistra). come faccio per sovrascriverli? ho provato con destroy, ma finisce che non mi crea neppure l'immagine. oppure senza sovrascriverli mi basterebbe cambiare l'immagine all'interno (ma credo che il modo migliore sia sovrascriverli). ah...prima che mi scordi.. windows e tkinter. grazie fabri -- http://mail.python.org/mailman/listinfo/python-list
Re: sys.stdin.encoding
Duncan Booth skrev: [EMAIL PROTECTED] wrote: The following line in my code is failing because sys.stdin.encoding is Null. I'll guess you mean None rather than Null. This has only started happening since I started working with Pydef in Eclipse SDK. Any ideas? uni=unicode(word,sys.stdin.encoding) You could give it a fallback value: uni = unicode(word, sys.stdin.encoding or sys.getdefaultencoding()) or even just: uni = unicode(word, sys.stdin.encoding or 'ascii') which should be the same in all reasonable universes (although I did get bitten recently when someone had changed the default encoding in a system). Thanks for your help. The problem now is that I cant enter the Swedish characters åöä etc without getting the following error - Enter word Påe Traceback (most recent call last): File C:\Documents and Settings\workspace\simple\src\main.py, line 25, in module archive.Test() File C:\Documents and Settings\workspace\simple\src\verb.py, line 192, in Test uni=unicode(word,sys.stdin.encoding or sys.getdefaultencoding()) UnicodeDecodeError: 'ascii' codec can't decode byte 0xe5 in position 1: ordinal not in range(128) The call to sys.getdefaultencoding() returns ascii. Since I can enter the characters åöä on the command line in Pydef/Eclipse doesn't that mean that the stdin is not ascii? What should I do? Thanks again, Aine. -- http://mail.python.org/mailman/listinfo/python-list
Re: sys.stdin.encoding
[EMAIL PROTECTED] schrieb: The following line in my code is failing because sys.stdin.encoding is Null. This has only started happening since I started working with Pydef in Eclipse SDK. Any ideas? uni=unicode(word,sys.stdin.encoding) That's a problem with pydev, where the standard machinery to determine the terminal's encoding fail. I have no idea yet how to fix this. Regards, Martin -- http://mail.python.org/mailman/listinfo/python-list
wxPython: Icon aus base64 decoded Image
Hallo zusammen,
in meine Anwendung ist ein Bild eingebettet und oben in der Leiste soll
ein Icon erscheinen.
Ausserdem will ich nur _eine_ Datei ausgeben, also ohne zusärtliche
Bild-Dateien etc.
Dazu habe ich das Bild in base64 codiert und als String im Skript
gespeichert, siehe unten. Beim Ausführen des Skripts wird dieser
String decodiert, in ein Image umgewandelt und als Bitmap dargestellt.
Funzt prima.
# Base64 codiertes Bild, einmalig ausserhalb des Skripts
import base64
file = open('smallPic.png',rb)
pic = file.read()
pic_b64 = pic.encode(base64)
# ergibt einen String wie 'iVBORw0KGgoTkSuQmCC\n'
# Danach im Skript:
self.staticImage =
wx.ImageFromStream(StringIO(pic_b64.decode(base64)))
self.staticBitmap =
wx.StaticBitmap(bitmap=wx.BitmapFromImage(self.staticImage,
wx.BITMAP_TYPE_PNG),
name='staticBitmap3', parent=self.panel1, pos=wx.Point(8,
96),
size=wx.Size(168, 72), style=0)
Wie gesagt, funkzt prima!
Und jetzt das Icon:
# Base64 codiertes Bild, einmalig ausserhalb des Skripts
import base64
file = open('smallIcon.ico',rb)
ico = file.read()
ico_b64 = ico.encode(base64)
# ergibt einen String wie
'==123445342gsgadfgdghsfhsdhxfghxfghTRGdfg\n'
# Danach im Skript:
icon = base64.b64decode(ico_b64)
self.SetIcon(wx.Icon(icon, wx.BITMAP_TYPE_ICO))
-- Fehler beim Start der Anwendung: Failed to load icom from the
file
Wo ist der Fehler und was muss ich machen, damit das Icon angezeigt
wird?
Besten Dank und schöne Grüsse,
Roland
--
E-Mail-Adresse ist reply-fähig, wird aber nicht gelesen.
Besser: r_2 bei Ge Em Ix oder hier in der NG
--
http://mail.python.org/mailman/listinfo/python-list
Re: sys.stdin.encoding
[EMAIL PROTECTED] wrote: The call to sys.getdefaultencoding() returns ascii. Since I can enter the characters åöä on the command line in Pydef/Eclipse doesn't that mean that the stdin is not ascii? What should I do? I think that depends on what sort of script you are writing. If it is just something for personal use on a single machine, or if you know that the same encoding is going to be used on all systems where you have this problem, then you could hardwire the encoding to whatever it should be (maybe 'latin1'). If it is to be used across a variety of systems with different encodings then you'll have to figure out some way to find the correct encoding. -- http://mail.python.org/mailman/listinfo/python-list
sovrascrivere
ciao.. ho creato i tasti con le immagini def creaImmagine(self): img = tk.PhotoImage(file=self.ico1) b = tk.Button(root, image=img, command=self.allaPressione) b.pack(side='left',padx=25) b.configure (width=80, height=80) b.image = img mi resta solo un problema.. questo metodo viene richamato più volte, ma i tasti non vengono sovrasritti bensì aggiunti (a sinistra). come faccio per sovrascriverli? ho provato con destroy, ma finisce che non mi crea neppure l'immagine. oppure senza sovrascriverli mi basterebbe cambiare l'immagine all'interno (ma credo che il modo migliore sia sovrascriverli). ah...prima che mi scordi.. windows e tkinter. grazie fabri -- http://mail.python.org/mailman/listinfo/python-list
Re: sys.stdin.encoding
Duncan Booth skrev: [EMAIL PROTECTED] wrote: The call to sys.getdefaultencoding() returns ascii. Since I can enter the characters åöä on the command line in Pydef/Eclipse doesn't that mean that the stdin is not ascii? What should I do? I think that depends on what sort of script you are writing. If it is just something for personal use on a single machine, or if you know that the same encoding is going to be used on all systems where you have this problem, then you could hardwire the encoding to whatever it should be (maybe 'latin1'). If it is to be used across a variety of systems with different encodings then you'll have to figure out some way to find the correct encoding. Yeah I'm only learning python so I think I can go with latin1. Cheers, Aine. -- http://mail.python.org/mailman/listinfo/python-list
Re: sys.stdin.encoding
[EMAIL PROTECTED] wrote: Duncan Booth skrev: [EMAIL PROTECTED] wrote: The following line in my code is failing because sys.stdin.encoding is Null. I'll guess you mean None rather than Null. This has only started happening since I started working with Pydef in Eclipse SDK. Any ideas? uni=unicode(word,sys.stdin.encoding) You could give it a fallback value: uni = unicode(word, sys.stdin.encoding or sys.getdefaultencoding()) or even just: uni = unicode(word, sys.stdin.encoding or 'ascii') which should be the same in all reasonable universes (although I did get bitten recently when someone had changed the default encoding in a system). Thanks for your help. The problem now is that I cant enter the Swedish characters åöä etc without getting the following error - Enter word Påe Traceback (most recent call last): File C:\Documents and Settings\workspace\simple\src\main.py, line 25, in module archive.Test() File C:\Documents and Settings\workspace\simple\src\verb.py, line 192, in Test uni=unicode(word,sys.stdin.encoding or sys.getdefaultencoding()) UnicodeDecodeError: 'ascii' codec can't decode byte 0xe5 in position 1: ordinal not in range(128) The call to sys.getdefaultencoding() returns ascii. Since I can enter the characters åöä on the command line in Pydef/Eclipse doesn't that mean that the stdin is not ascii? What should I do? The workaround in your case is: in the beginning of your program: import sys if hasattr(sys.stdin, 'encoding'): console_encoding = sys.stdin.encoding else: import locale locale_name, console_encoding = locale.getdefaultlocale() and later: uni = unicode(word, console_encoding) But don't think it's portable, if you use other IDE or OS, it may not work. It would be better if PyDev implemented sys.stdin.encoding -- Leo -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
On 11 Dec 2006 00:27:28 -0800, Ravi Teja [EMAIL PROTECTED] tried to confuse everyone with this message: That's a lot of hate in 2 sentences for judging a novel feature you barely came across. But, you have to admit that it looks horrible (at least at the first glance). If there's some programming style that I absolutely can't stand, it would be the one where programmer writes a huge block of commentary describing what a function does, followed by one-liner of code, which contains the same amount of information in itself. With doctest it is even worse, because examples also contain superfluous information. Everyone can just copy-paste the code in REPL and see what happens when you execute it. Besides that, there are many reasons why tests should be stored in a separate file, or at least not in the same function that they are testing. Also Wikipedia article contains some Cons of doctest that look pretty nasty: * Large numbers of tests in a docstring can become unwieldy. docstrings should be pruned and excised tests put in external file(s). * Tests producing large amounts of output make for large docstrings. * Debugging integration is far from perfect * 'print' (or 'trace') debugging is not possible (because it intervenes with the test result) * Test setup has to be either copied or hidden away from the test, making the overall environment harder to understand. * Many of the complex assertions of existing unit tests frameworks do not exist, (e.g. assertRaises, assertEquals, assertAlmostEqual, ...), although some are not necessary. * Failing assertions are very hard to debug (Especially in Web applications if the expected result is a web page with a lot of HTML) It's not surprising that no one uses this stuff for serious work. -- |Don't believe this - you're not worthless ,gr-.ru |It's us against millions and we can't take them all... | ue il | |But we can take them on! | @ma | | (A Wilhelm Scream - The Rip)|__| -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
On Sun, 2006-12-10 at 01:28 -0800, Kay Schluehr wrote: Who really wants to write web apps? Web apps are just an excuse for Pythonistas to write web frameworks. I've been lurking, waiting for the right moment to toss in my two cents, and finally, and here it is. I've been using Python heavily for many years (since late 1.5.1) and frankly I've gotten a bit bored with it. I think your statement indirectly (and unintentionally I'm sure) sums up why. Python is certainly pragmatic. Python has *everything* you'd want for writing applications: extensive libraries, flexibility, etc. Unfortunately, writing applications is boring. The way I like to overcome this boredom (and hence stay productive) is by writing clever code. I don't mean obfuscated one-liners (although I'm guilty of that too), rather I mean generalizing code, creating frameworks and then developing the application in that framework, that sort of thing. Python has been pretty good for me so far in keeping the ceiling high enough that I could stretch but not bump my head too often. I suspect I'm not alone in this need (hence the unusual number of web frameworks written in Python). However lately I've noticed that the ceiling is quite apparent: Python programmers are free to define DSL's via functions, classes, clever operator overloading, etc, but not in the one way that actually makes them really interesting: macros. It might be true that macros would make it more difficult for someone else to understand my code (although I doubt much more than say, Zope or Twisted, or any of the popular ORMs floating about). Regardless, let's take a moment to consider another point of view: I. DON'T. CARE. That's right. I don't care if anyone else can read it. Frankly I may not even care if *I* can read it in a year. Every year I look back at what I've written the previous year and think about how much better I could have done it *this* year. This has gone on for over twenty years now and I suspect that if that fact ever changed it would probably be time for me to retire from programming as I'd have stopped learning (or would at least be bored out of my mind). The majority of code is throwaway. That is, whatever need it was written to fulfill will cease to exist, the coder will think of some brilliant new approach that requires a major rewrite, another programmer with different ideas will rewrite it from the ground up (probably in a new language), a library will appear that renders it moot, etc, etc. While I'm sure there is a huge base of ancient code out there somewhere, faithfully powering our banks and dams and pushing fractions of pennies about, I simply don't care. Someone may have to read it, please god don't let it be me. I don't care about old application code. It's effing boring. I don't just program because it pays the bills. I program because I *like to program*. That means not having arbitrary limits to what I can express so that some hypothetical 8th grader can come along in some future decade and grok some one-off program I hacked together over a weekend. If I write code during a drunken binge, then dammit, I'll run that code in another drunken binge. If not, then I'll damn well rewrite it when I'm sober. I neither want nor need moral programming imperatives handed down from above. I will write crappy code whenever I damn well feel like it. If I learn something from it, all the better. If not, well that's my choice as an adult to take that path. There is lots of talk about how, if Python had macros, everyone would create their own mini-languages and it would be a virtual Tower of Babel, etc, etc. Perhaps. But of course, given how much syntax Python has grown since 1.5 (most of which is there to compensate for statement-oriented syntax and lack of macros) I'd suggest that perhaps the tower is already being built directly into the language. As an aside, it's pretty sad when many of the c.l.lisp folks on this thread seem more polite in general than the c.l.py crowd. Lisp may have expression-based syntax and macros, but it's also got Eric Naggum. If we can't have the nice features of Lisp, let's at least not adopt its downsides. Regards, Cliff P.S. As a disclaimer, I *have* had a few beers tonight already and have, in fact, been binge-coding, so if this seems like a rant, I reserve the right to deny all knowledge of anything I may have written up to this point. -- http://mail.python.org/mailman/listinfo/python-list
Re: sys.stdin.encoding
Martin v. Löwis wrote: [EMAIL PROTECTED] schrieb: The following line in my code is failing because sys.stdin.encoding is Null. This has only started happening since I started working with Pydef in Eclipse SDK. Any ideas? uni=unicode(word,sys.stdin.encoding) That's a problem with pydev, where the standard machinery to determine the terminal's encoding fail. I have no idea yet how to fix this. Environmental variable TERMENCODING ? Heck, maybe this will catch on and will be used by other languages, libraries, terminals, etc. It's not really Python only problem. -- Leo -- http://mail.python.org/mailman/listinfo/python-list
Avoiding invalid literal for int() exception
v = raw_input(Enter: ) Enter: kjjkj int(v) Traceback (most recent call last): File stdin, line 1, in module ValueError: invalid literal for int() with base 10: 'kjjkj' In my program I need to be able to enter char strings or int strings on the command line. Then I use an if-elif structure to establish which is which. For example - if uniList[0].lower() in (e,exit): # uniList stores a unicode string origionally taken from stdin return elif uniList[0].lower() in (h,help): verb.PrintVerb() elif uniList[0].lower() in (p,pass): break elif int(uniList[0]) in range(0,10): verb.SetImportance(int(uniList[0])) break else: verb.AddNewVerb((uniList[0]) How could I avoid the ValueError exception if uniList[0] == Åker? I was thinking of having something like - formatError = False try: iVal = int(uniList[0]) if iVal not in range range(0,10): formatError = True catch ValueError: iVal = -1 if uniList[0].lower() in (e,exit): # uniList stores a unicode string origionally taken from stdin return elif uniList[0].lower() in (h,help): verb.PrintVerb() elif uniList[0].lower() in (p,pass): break elif iVal != -1 and not formatError: verb.SetImportance(iVal) break elif not formatError: verb.VerbEntered((uniList[0]) else: print Enter numbers between 0 and 10... Is this the correct way to do this in your opinion? Sorry, I'm totally new to python and exceptions. Thanks, Aine. -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Timofei Shatrov wrote: It's not surprising that no one uses this stuff for serious work. Well, I replaced all my unittests with doctests long ago, and I am not the only one following this way (see the Zope 3 project for instance). Michele Simionato -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
[EMAIL PROTECTED] wrote: compilers are GREATLY facilitated by having a macro facility because (at first blush) all you need to do is to macro-expand down to something you know how to turn into code. There's no way you could compile Python to efficient machine code just by macro expansion. You'd also need some very heavy-duty type inferencing. Python is extremely dynamic, even more so than Lisp. That's why compiling Python is hard, not because it doesn't have macros. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Ken Tilton wrote: But with Lisp one does not have to clean up the indentation manually after thrashing away at ones code. That's not how I would describe the experience I have when I'm editing Python code. When moving a set of statements in Python, you are usually selecting a set of complete lines, cutting them out and then pasting them in between two other lines somewhere else. Having done that, the lines you've just pasted in are selected. Now it's just a matter of using using your editor's block-shifting commands to move them left or right until they're in the correct horizontal position. I find this to be quite a smooth and natural process -- no thrashing involved at all. Having edited both Lisp and Python code fairly extensively, I can't say that I find editing Python code to be any more difficult or error prone. On the plus side, Python makes less demands on the capabilities of the editor. All you really need is block-shifting commands. Bracket matching is handy for expressions but not vital, and you certainly don't need bracket-based auto-indenting. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
How do I edit a PythonWin path to import custom built modules???
Hi Guys, I've been using the following IDE, Pythonwin - Python IDE and GUI Framework for Windows. Copyright 1994-2001 Mark Hammond With respect to my work, I had created my own modules (.py files) in drives and folders other than the python root. I know that if I need to import these modules, I need to specify the path of the directory where I've put my modules. I've tried the Edit Python Path sub menu in the menu Tools of PythonWin, but I could not add a new path i.e.- D:\\\\ATS. Could any one please let me know how could I add a new path to access my own modules. Thanks in advance, Mohan Swaminathan. -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Timofei Shatrov wrote: But, you have to admit that it looks horrible (at least at the first glance). If there's some programming style that I absolutely can't stand, it would be the one where programmer writes a huge block of commentary describing what a function does, followed by one-liner of code You Sir, are no fan of Literate Programming :-). information in itself. With doctest it is even worse, because examples also contain superfluous information. Everyone can just copy-paste the code in REPL and see what happens when you execute it. And doctest automates such REPL tests. Like macros, don't knock it till you try it. Besides that, there are many reasons why tests should be stored in a separate file, or at least not in the same function that they are testing. You need not have doctest as a part of source code. You can also create a separate documentation file that contains prose as well as tests intervening. http://www.python.org/doc/lib/doctest-simple-testfile.html Combine it with ReStructured Text and you have a wonderful documentation and testing solution in one place. Personally, I like this a lot better than Javadoc style documentation where usage examples are often absent. Also Wikipedia article contains some Cons of doctest that look pretty nasty: Of course, doctest is hardly the ultimate testing solution. But it does an admirable job for many cases where you don't need to setup elaborate tests. It's not surprising that no one uses this stuff for serious work. I have seen enough libraries that use doctest. Zope, Twisted and Paste are some of the popular Python projects in that use it. Epydoc supports it as well. -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
On Dec 11, 8:07 am, Kaz Kylheku [EMAIL PROTECTED] wrote: Paddy wrote: http://en.wikipedia.org/wiki/DoctestI pity the hoplelessly anti-intellectual douche-bag who inflicted this undergraduate misfeature upon the programming language. Oh wow! So much invective. So little reason. Doctest is very easy to try. 1/ Get python installed on your machine: http://wiki.python.org/moin/BeginnersGuide/Download 2/ Use a tutorial to get up to speed in Python: http://wiki.python.org/moin/BeginnersGuide/Programmers 3/ Try Doctest. http://www.python.org/pycon/dc2004/papers/4/ http://en.wikipedia.org/wiki/Doctest http://www.python.org/doc/lib/module-doctest.html This must be some unofficial patch that still has a hope of being shot down in flames, right? Try doctest and you will see why it is not. - Paddy. -- http://mail.python.org/mailman/listinfo/python-list
Re: Automatic debugging of copy by reference errors?
Russ wrote: The copy by reference semantics of Python give it great efficiency but are also its achille's heel for tough-to-find bugs. You need to stop using the term copy by reference, because it's meaningless. Just remember that assignment in Python is always reference assignment. If you want something copied, you need to be explicit about it. I later discovered that a particularly nasty bug was due to the fact that my constructor copied the initializing list by reference. The reason you made that mistake was that you were using the wrong mental model for how assignment works in Python -- probably one that you brought over from some other language. When you become more familiar with Python, you won't make mistakes like that anywhere near as often. And if you do, you'll be better at recognising the symptoms, so the cause won't be hard to track down. So a fundamental question in Python, it seems to me, is when to take the performance hit and use copy or deepcopy. Again, this is something you'll find easier when you've had more experience with Python. Generally, you only need to copy something when you want an independent object that you can manipulate without affecting anything else, although that probably doesn't sound very helpful. In your vector example, it depends on whether you want your vectors to be mutable or immutable. It sounds like you were treating them as mutable, i.e. able to be modified in-place. In that case, each vector obviously needs to be a new object with the initial values copied into it. The alternative would be to treat your vectors as immutable, i.e. once created you never change their contents, and any operation, such as adding two vectors, produces a new vector holding the result. In that case, two vectors could happily share a reference to a list of values (as long as there is nothing else that might modify the contents of the list). -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
(message (Hello 'Paul) (you :wrote :on '(10 Dec 2006 21:06:56 -0800)) ( ?? read the book. PR Which book? Paul Graham's On Lisp. or just refreshing your knowledge about CPS transformaction might be sufficient. i've found very good explanation of CPS transformaction in the book Programming Languages:Application and Interpretation Shriram Krishnamurthi Brown University it's not Common Lisp but Scheme though, but it's very interesting since it shows how continuations can be used for better web programming. both books are available online. ?? but once you convert it to CPS, you just operate with closures. stack ?? is just a lexical variables caught into closure. do you know what does ?? CPS mean at all?? PR I once understood the basic notion but confess to have never been PR clear on the fine points. However, I don't see how you can do it with PR CL closures since CL semantics do not guarantee tail recursion PR optimization. If you code a loop with closures and CPS, you will blow PR the stack. most CL implementation do tail call optimization, unless you're running debug mode -- in that case you'd prefer full stack. however, it's possible to implement tail call optimizations in non-tail-call optimizing language. i think it's called trampolined style. example can be found in PAIP book: interpreter of Scheme is implemented in Common Lisp. CPS transformation found in ARNESI implements that -- you might notice on the macroexpansion i've showed in prev example function drive-cps. it's defined following way: (defun drive-cps (cps-lambda) (catch 'done (loop for f = cps-lambda then (funcall f additional (lambda () ...) is inserted in the code to delay evaluation. code becomes like this: (drive-cps (block1) (lambda () (block2)) thus for each CPS tear-point it's able to throw stale stack frames away. here's an example of CPS-transformed eternal loop (macroexpand '(with-call/cc (loop for i upfrom 1 do (print i) do (call/cc (lambda (cont) cont) (DRIVE-CPS (LET ((#:CPS-LET-I-1712 1)) (DECLARE (TYPE NUMBER #:CPS-LET-I-1712)) (LABELS ((#:TAGBODY-TAG-NEXT-LOOP-1713 () (PROGN (PRINT #:CPS-LET-I-1712) (LAMBDA () (FUNCALL #'TOPLEVEL-K (FUNCALL #'(LAMBDA (CONT) CONT) (MAKE-CALL/CC-K (LAMBDA (#:V-1717) (DECLARE (IGNORE #:V-1717)) (PROGN (PROGN (SETQ #:CPS-LET-I-1712 (1+ #:CPS-LET-I-1712))) (#:TAGBODY-TAG-NEXT-LOOP-1713)) (#:TAGBODY-TAG-NEXT-LOOP-1713 ) (With-best-regards '(Alex Mizrahi) :aka 'killer_storm) People who lust for the Feel of keys on their fingertips (c) Inity) -- http://mail.python.org/mailman/listinfo/python-list
Re: Avoiding invalid literal for int() exception
In [EMAIL PROTECTED], aine_canby wrote: elif uniList[0].lower() in (p,pass): break elif int(uniList[0]) in range(0,10): Replace this line with: elif uniList[0].isdigit() and 0 = int(uniList[0]) 10: verb.SetImportance(int(uniList[0])) break else: verb.AddNewVerb((uniList[0]) You may want to give `uniList[0]` a name before entering the ``if``/``elif`` construct to avoid accessing the first element over and over. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: Avoiding invalid literal for int() exception
[EMAIL PROTECTED] wrote: v = raw_input(Enter: ) Enter: kjjkj int(v) Traceback (most recent call last): File stdin, line 1, in module ValueError: invalid literal for int() with base 10: 'kjjkj' In my program I need to be able to enter char strings or int strings on the command line. Then I use an if-elif structure to establish which is which. For example - if uniList[0].lower() in (e,exit): # uniList stores a unicode string origionally taken from stdin return elif uniList[0].lower() in (h,help): verb.PrintVerb() elif uniList[0].lower() in (p,pass): break elif int(uniList[0]) in range(0,10): verb.SetImportance(int(uniList[0])) break else: verb.AddNewVerb((uniList[0]) How could I avoid the ValueError exception if uniList[0] == Åker? I was thinking of having something like - formatError = False try: iVal = int(uniList[0]) if iVal not in range range(0,10): formatError = True catch ValueError: Perhaps you meant except ValueError: :-) iVal = -1 Consider using uniList[0].isdigit() -- see http://docs.python.org/lib/string-methods.html HTH, John -- http://mail.python.org/mailman/listinfo/python-list
Re: Avoiding invalid literal for int() exception
John Machin skrev: [EMAIL PROTECTED] wrote: v = raw_input(Enter: ) Enter: kjjkj int(v) Traceback (most recent call last): File stdin, line 1, in module ValueError: invalid literal for int() with base 10: 'kjjkj' In my program I need to be able to enter char strings or int strings on the command line. Then I use an if-elif structure to establish which is which. For example - if uniList[0].lower() in (e,exit): # uniList stores a unicode string origionally taken from stdin return elif uniList[0].lower() in (h,help): verb.PrintVerb() elif uniList[0].lower() in (p,pass): break elif int(uniList[0]) in range(0,10): verb.SetImportance(int(uniList[0])) break else: verb.AddNewVerb((uniList[0]) How could I avoid the ValueError exception if uniList[0] == Åker? I was thinking of having something like - formatError = False try: iVal = int(uniList[0]) if iVal not in range range(0,10): formatError = True catch ValueError: Perhaps you meant except ValueError: :-) iVal = -1 Consider using uniList[0].isdigit() -- see http://docs.python.org/lib/string-methods.html HTH, John Yes, thanks for your help. -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Alex Mizrahi [EMAIL PROTECTED] writes: PR Which book? Paul Graham's On Lisp. Oh ok, someone mentioned that was online, and I just bookmarked it. I'll look at it when I'm more awake. Programming Languages:Application and Interpretation Shriram Krishnamurthi Brown University it's not Common Lisp but Scheme though, but it's very interesting since it shows how continuations can be used for better web programming. Scheme probably makes more sense for this type of book--it's simpler than CL. most CL implementation do tail call optimization, unless you're running debug mode -- in that case you'd prefer full stack. I'd rather stick to what the CL standard says, rather than what some implementation might happen to do. CL does not guarantee TCO so these code transformation schemes mustn't rely on it. optimizing language. i think it's called trampolined style. example can be found in PAIP book: interpreter of Scheme is implemented in This book doesn't seem to be online. But anyway I think you mean, compile the Scheme code into one giant CL function, which is no longer really a clean mapping of Scheme to CL, it's just writing an interpreter. And I think that interpreter has to do its own management of environments rather than letting the CL runtime do it. So basically it says CL is turing-complete and can do everything, which we already knew ;-). (defun drive-cps (cps-lambda) (catch 'done (loop for f = cps-lambda then (funcall f Part of the problem I'm having with these examples is I don't know all the different macros being used. But I think I understand one part of what was confusing me before: your call/cc macros depend on a nonstandard feature of some CL implementations. You can't write a call/cc macro in standard CL--you instead have to write something that transforms the entire program. I think even with TCO though, you still can't do coroutines with CL macros (but you can do them with real call/cc). The point is that you have to do something like TCO on calls that are not tail calls and actually have to return. You again have to transform the whole program, not just expand a call/cc macro locally inside functions that use it. -- http://mail.python.org/mailman/listinfo/python-list
Pb ReportLab (ttfonts.py)
Hi!
I try to generate PDF from Python 2.5 + ReporLab_lib, and, I have:
C:\Python25\reportlab\pdfbase\ttfonts.py:407: DeprecationWarning: struct
integer overflow masking is deprecated
stm.write(pack(LLL, checksum, offset, len(data)))
C:\Python25\reportlab\pdfbase\ttfonts.py:419: DeprecationWarning: struct
integer overflow masking is deprecated
stm.write(pack('L', checksum))
(note : the same script run Ok with Python 2.4.3)
One idea?
Thanks you by advance
Michel Claveau
--
http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Maybe this was already mentioned in this thread and I didn't see it. Anyway, I find that Scheme (so I am talking about Scheme as a member of the lisp family) has pedagogical advantages over Python. 1. There are a range of excellent books that will introduce not just Scheme but programming and computer science to audiences with varied background and previous programming experience. 1.1. I do not know of any Python equivalents to The Little Schemer and The Seasoned Schemer. These teach you recursion and the art of scheme programming. I think Core Python Programming (and, to a lesser extent, Learning Python) might teach some of the art of python programming, but the focus, style, and effectivenes are quite different (and, I'd say, not as successful; you can read the little schemer in a couple of long train commutes; there is no way you can do that with Core Python Programming.). Sure, the style of The little Schemer is not for everyone. 1.2. How to design programs is obviously a much broader, comprehensive, detailed, and far-reaching textbook than (the nice) How to think like a computer scientist; learning with Python. 1.3. SICP has no counterpart in the Python world. I've read some people have taught SICP like using Python (and that there is a new course at MIT, taught by Abelson and/or Sussman, that will use Python, not Scheme; but this is not a course that really substitutes the original for which SICP was written). But SICP remains SICP. It'd be nice to see something similar in Python. 1.4. More advanced material is available as Programming Languages: Application and Interpretation (Krishnamurthi). I know of no Python counterpart in the range and depth of topics covered. 1.5. Last, but not least, lots of this material is available on-line. So you can check it out before buying the dead-tree version. 2. PLT scheme and Dr. Scheme are a wonderful learning environment for Scheme, with no equivalent in Python. Its not just the great debugging and tracing facilities, but also who you can restrict the language you use to concentrate on some key features, so as to build incrementally (to avoid the forest from preventing you to see some specific trees). Interestingly, I think there has been at least one attempt to build something similar for Python on top of Dr. Scheme (in PyCon 2004 or 2005?). 3. Schemers (some Schemers at least) are making a strong effort to teach CS to audiences of varied backgrounds and experiences. They even have a sequence that starts from basically 0, teaches you Scheme, and ends up including Java (I guess this is catering to the but I really need Java to get a job when I get out of here!). That Scheme is way ahead of Python in this area I think has been recognized by relevant members of the Python community (comp.lnag.python not long ago). 4. Python, instead, has the wealth of nutshells, pocket guides, etc. Which are fine (I always have my Ptyhon in a Nuthsell and Python Pocket Reference nearby when writing Python). But I doubt these books really teach you basic computer science as the above do. They are of the applied kind (and here probably the only Lisp coutnerpart might be Practical Common Lisp). Why does all this matters (or at least matters to me, who am considering moving most of my programming from Python to Scheme and CL)? a) If the issue of teaching programming to a kid/adolescent arises, I'd definitely have a lot more resources, which also teach much more than just a language, if I choose Scheme. (And, no, I do not think a parenthesis is inherently more scary than a tab for someone who is new to both). b) I have no formal CS training; I am a biologist and statistician by training and have used Basic, C/C++, Pascal, Fortran, R (oh, and RPL, that minor language of the HP48 calc., which I used extensively for 18 months for writing lots of animal behavior recording programs). But once and for all, I'd like to learn some basic CS, while learning how to use a language. I have a strong feeling that, with the Scheme route, this will be fulfilled. Not with Python. (Sure, this is also fulfilled with Mozart/Oz and Concepts and Techniques and Models of Comp. Progr., but Mozart/Oz does not seem as ready for the types of projects I work on and there are speed issues). The first three chapters of SICP and the first four chapters of CTM so far have really been mind-expanding. None of the Python books I've read have felt anyway similar (Python has felt cozy, nice, easy to use; not eye opening). c) Now, if Scheme/CL were just toy languages we could dismiss all the above by saying we are not talking about why kids learn XYZ, nor why CS ignorants like you prefer to be spoon fed basic CS concepts by learning language UVW. But of course, I think that neither Scheme nor CL are just toy languages. Just my 2 cents. Ramon -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Paul Rubin wrote: Alex Mizrahi [EMAIL PROTECTED] writes: Programming Languages:Application and Interpretation Shriram Krishnamurthi Brown University This book doesn't seem to be online. http://cs.brown.edu/~sk/Publications/Books/ProgLangs/ Michele Simionato -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Michele Simionato [EMAIL PROTECTED] writes: Programming Languages:Application and Interpretation Shriram Krishnamurthi Brown University This book doesn't seem to be online. http://cs.brown.edu/~sk/Publications/Books/ProgLangs/ Thanks! -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
[EMAIL PROTECTED] wrote: I challenge anyone making psychological claims about language X (for any X) being easier to either read/learn/use than language Y (for any Y) to come up with any valid evidence whatever. Put aside,that I don't understand meaning of term psychological claim in that context. It is obvious that different medium of information exchange provides different levels of readability for humans. And accordingly easier/harder to learn/use. Regards, Dmitry -- http://mail.python.org/mailman/listinfo/python-list
Re: need guidance on sending emails with attachment with python.
here's the function I've been using for while :P
import smtplib
from email.MIMEMultipart import MIMEMultipart
from email.MIMEBase import MIMEBase
from email.MIMEText import MIMEText
from email.Utils import COMMASPACE, formatdate
from email import Encoders
def sendMail(arrRecipients, sender, subject, message, files=[]):
Sends email with attachements
# SMTP address
smtpserver = '' # provide a smtp here in string format
# authentification section
AUTHREQUIRED = 0 # if you need to use SMTP AUTH set to 1
smtpuser = '' # for SMTP AUTH, set SMTP username here
smtppass = '' # for SMTP AUTH, set SMTP password here
# Building the body of the email
mssg = MIMEMultipart()
mssg['From'] = sender
mssg['To'] = COMMASPACE.join(arrRecipients)
mssg['Date'] = formatdate(localtime=True)
mssg['Subject'] = subject
mssg.attach( MIMEText(message) )
# attachments
for file in files:
part = MIMEBase('application', octet-stream)
part.set_payload( open(file,rb).read() )
Encoders.encode_base64(part)
part.add_header('Content-Disposition', 'attachment;
filename=%s' % os.path.basename(file))
mssg.attach(part)
session = smtplib.SMTP(smtpserver)
if AUTHREQUIRED:
session.login(smtpuser, smtppass)
smtpresult = session.sendmail(sender, arrRecipients,
mssg.as_string())
if smtpresult:
errstr =
for recip in smtpresult.keys():
errstr = Could not delivery mail to: %s
Server said: %s
%s
%s % (recip, smtpresult[recip][0], smtpresult[recip][1], errstr)
raise smtplib.SMTPException, errstr
krishnakant Mane a écrit :
hello,
I am a bit confused.
I want to make a program that will take some data from a database and
make a string of text. and send it to the respective email id of a
person.
next I also want to send an attachment of a photo along with the email.
I will be required to make this program run on windows xp.
can some one guide me as to how I can achieve this?
what I will need on windows to send emails?
I believe yahoo, gmail, rediff and msn supports pop3 and smtp?
correct me if I am wrong on this.
secondly what library is used on windows to do this?
I know there must be python libraries to do this,
but apart from that I don't know what all I will need on my windows
machine to send emails to mostly yahoo, gmail and msn.
Please give me some idea about it.
Krishnakant.
--
http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
(message (Hello 'Paul) (you :wrote :on '(11 Dec 2006 04:14:20 -0800)) ( ?? optimizing language. i think it's called trampolined style. ?? example can be found in PAIP book: interpreter of Scheme is implemented in PR This book doesn't seem to be online. But anyway I think you mean, PR compile the Scheme code into one giant CL function, which is no longer PR really a clean mapping of Scheme to CL, it's just writing an PR interpreter. And I think that interpreter has to do its own PR management of environments rather than letting the CL runtime do it. PR So basically it says CL is turing-complete and can do everything, PR which we already knew ;-). point is that writting some custom interpreter in CL is very easy AND you can still use all other features of CL AND communicate with other DSLs. PR the different macros being used. But I think I understand one part of PR what was confusing me before: your call/cc macros depend on a PR nonstandard feature of some CL implementations. no, it's standard Common Lisp. it's an ARNESI library. it's very standard -- i was able to run non-modified code in Armed Bear Common Lisp implementation (it's running on JVM), that is very new and does not fully support the standard -- but nevertheless, CPS code runs out of the box on it. PR You can't write a call/cc macro in standard CL--you instead have to PR write something that transforms the entire program. yes, i cannot write just call/cc -- i should wrap code into with-call/cc. with-call/cc macro performs transformation of the code to CPS -- and then call/cc is enabled. i can enable call/cc for specific functions -- i define them with defun/cc instead of defun. so, i can define both normal CL functions and call/cc enabled functions. typically, call/cc is required only in a few pieces of program where interrupts come, so it's OK. if i'm going to support generators, i only need to run CPS tranformation on the body of generator function -- that will tear it in yield points. PR I think even with TCO though, you still can't do coroutines with CL PR macros (but you can do them with real call/cc). The point is that you PR have to do something like TCO on calls that are not tail calls and PR actually have to return. You again have to transform the whole PR program, not just expand a call/cc macro locally inside functions that PR use it. i think only functions that are coroutines should be fully transformed. ) (With-best-regards '(Alex Mizrahi) :aka 'killer_storm) People who lust for the Feel of keys on their fingertips (c) Inity) -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Steven D'Aprano schrieb: On Sat, 09 Dec 2006 14:57:08 -0500, Bill Atkins wrote: Paul Rubin http://[EMAIL PROTECTED] writes: There is just not that much boilerplate in Python code, so there's not so much need to hide it. Well, of course there is. There are always going to be patterns in the code you write that could be collapsed. Language has nothing to do with it; Lisp without macros would still be susceptible to boilerplate. Here's a concrete example: (let ((control-code (read-next-control-code connection))) (ecase control-code (+break+ (kill-connection connection) (throw :broken-by-client)) (+status+ (send-status-summary connection)) ((+noop+ +keep-alive+ ;; +X+ indicates a constant Eight lines, excluding the comment, and it doesn't handle the case where control-code is not one of +break+, +status+, +noop+ or +keep-alive+, although the ecase macro does. And how many lines of code is ecase? All of that boilerplate is handled by the macro. In Python, I would need to do something like: control_code = connection.read_next_control_code() if control_code == +break+: connection.kill() throw blah else if control_code == +status+: connection.send_status_summary() else if control_code == +noop+ || control_code == +keep_alive+: else: error CONTROL_CODE fell through conditional cascade; was not one of +BREAK+, +STATUS+, +NOOP+, +KEEP_ALIVE+ Your Python syntax is rather wonky, but that's incidental. Nine lines, including handling the case where control_code is none of the four constants. Ten if you add the pass statement that it actually needs. And it is completely self-contained, with no external functions or macros to understand. Counting source lines is not the important thing. Look at the complexity and the number of tokens. The Lisp code is easier, because it is more abstract. You are closer in saying what you want. Counting tokens: (let ((control-code (read-next-control-code connection))) 4 (ecase control-code 2 (+break+1 (kill-connection connection) 2 (throw :broken-by-client))2 (+status+ 1 (send-status-summary connection)) 2 ((+noop+ +keep-alive+ 2 == 16 control_code = connection.read_next_control_code() 4 if control_code == +break+: 4 connection.kill() 2 throw blah2 else if control_code == +status+: 4 connection.send_status_summary() 2 else if control_code == +noop+ || control_code == +keep_alive+: 8 else: 1 error CONTROL_CODE fell through conditional cascade; 2 was not one of +BREAK+, +STATUS+, +NOOP+, +KEEP_ALIVE+ == 29 plus a pass, would make 30 vs 16 Brain-units. André -- -- http://mail.python.org/mailman/listinfo/python-list
Re: Pb ReportLab (ttfonts.py)
In [EMAIL PROTECTED], Méta-MCI wrote:
Hi!
I try to generate PDF from Python 2.5 + ReporLab_lib, and, I have:
C:\Python25\reportlab\pdfbase\ttfonts.py:407: DeprecationWarning: struct
integer overflow masking is deprecated
stm.write(pack(LLL, checksum, offset, len(data)))
C:\Python25\reportlab\pdfbase\ttfonts.py:419: DeprecationWarning: struct
integer overflow masking is deprecated
stm.write(pack('L', checksum))
Does the PDF generation work? Those are just warnings.
Ciao,
Marc 'BlackJack' Rintsch
--
http://mail.python.org/mailman/listinfo/python-list
Re: About alternatives to Matlab
[EMAIL PROTECTED] wrote: On 10.12.2006, at 11:23, Jon Harrop wrote: F# addresses this by adding operator overloading. However, you have to add more type annotations... That sounds interesting, but I'd have to see this in practice to form an opinion. As long as F# is a Windows-only language, I am not interested in it anyway. F# runs under Linux with Mono. OCaml already supports 9 architectures and optimised to AMD64 earlier than gcc. How many do you want? It's not a matter of number, it's a matter of availability when new processors appear on the market. How much time passes on average between the availability of a new processor type and the availability of a native code compiler for OCaml? OCaml had AMD64 support before many other language. It had a better optimiser before gcc... -- Dr Jon D Harrop, Flying Frog Consultancy Objective CAML for Scientists http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Alex Mizrahi [EMAIL PROTECTED] writes: PR the different macros being used. But I think I understand one part of PR what was confusing me before: your call/cc macros depend on a PR nonstandard feature of some CL implementations. no, it's standard Common Lisp. it's an ARNESI library. it's very standard -- The ARNESI doc at: http://common-lisp.net/project/bese/docs/arnesi/html/Automatically_Converting_a_Subset_of_Common_Lisp_to_CPS.html begins: By transforming common lisp code into CPS we allow a restricted form of CALL/CC. While we use the name call/cc what we actually provide is more like the shift/reset operators (where with-call/cc is reset and call/cc is shift). I don't know what shift/reset are but the above says that call/cc in the Scheme sense is not really implemented. There are also a bunch of limitations on what can be in the call/cc body, e.g. you can't use unwind-protect. Anyway, the nonstandard feature is tail call optimization, if you're turning continuations into closures, and that's just for the simple case of dealing with loops written in CPS. E.g.: if you write (defun sum_to_n (n optional (acc 0)) ;; (sum_to_n n) computes sum of integers from 0 to n (if (= n 0) 0 (sum_to_n (- 1 n) (+ n acc This function is properly tail recursive (unless I messed up) so with (sum_to_n 100) the CPS version is supposed to return the right answer if you wait long enough. It is not allowed to overflow the stack. This is guaranteed to work in Scheme but is not guaranteed in CL. And as I think we agree, with coroutines it gets even worse. -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Paul Rubin http://[EMAIL PROTECTED] writes: (defun sum_to_n (n optional (acc 0)) ;; (sum_to_n n) computes sum of integers from 0 to n (if (= n 0) 0 (sum_to_n (- 1 n) (+ n acc Of course meant: (defun sum_to_n (n optional (acc 0)) ;; (sum_to_n n) computes sum of integers from 0 to n (if (= n 0) acc (sum_to_n (- 1 n) (+ n acc I've made that same error several times in Haskell as well. I'm not used to this. -- http://mail.python.org/mailman/listinfo/python-list
Re: Pb ReportLab (ttfonts.py)
Méta-MCI wrote:
I try to generate PDF from Python 2.5 + ReporLab_lib, and, I have:
C:\Python25\reportlab\pdfbase\ttfonts.py:407: DeprecationWarning: struct
integer overflow masking is deprecated
stm.write(pack(LLL, checksum, offset, len(data)))
C:\Python25\reportlab\pdfbase\ttfonts.py:419: DeprecationWarning: struct
integer overflow masking is deprecated
stm.write(pack('L', checksum))
(note : the same script run Ok with Python 2.4.3)
One idea?
it's a deprecation warning. the code runs under Python 2.5, but will
probably break in future releases. check with the reportlab folks for
updates.
if you want to turn the messages off, use the filterwarnings function in
the warnings module (see the docs for details).
/F
--
http://mail.python.org/mailman/listinfo/python-list
Re: About alternatives to Matlab
Carl Banks wrote: Jon Harrop wrote: What about translating the current Python interpreter into a language with a GC, like MLton-compiled SML? That would probably make it much faster, more reliable and easier to develop. I doubt it would work too well. MLton-compiled SML's semantics differ from Python's in subtle ways, and covering the edge cases usually means you have to do all the stuff you thought you would avoid by using another dynamically-typed language. Translating MTton-compiled SML integers to Python ints would work probably 99 percent of the time, but in the end you'd essentially have to reimplement the Python int type. If you're going to go through all that work, you might as well translate it to C or directly to machine code. That's not what I meant. I was referring to translating the Python _interpreter_ into another language, not translating Python programs into other languages. MLton-compiled SML is especially fast at symbolic manipulation, e.g. interpreters, so it will be probably be as fast or faster than the current Python interpreter. Then you can start boiling the interpreter down, removing the GC for a start because MLton already has a much better GC... -- Dr Jon D Harrop, Flying Frog Consultancy Objective CAML for Scientists http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet -- http://mail.python.org/mailman/listinfo/python-list
Re: About alternatives to Matlab
Jon Harrop [EMAIL PROTECTED] writes: F# runs under Linux with Mono. Interesting, where do I get it, and is there source? I've never been interested in Mono but maybe this is a reason. How does the compiled code compare to OCaml or MLton code? -- http://mail.python.org/mailman/listinfo/python-list
Re: About alternatives to Matlab
Jon Harrop [EMAIL PROTECTED] writes: That's not what I meant. I was referring to translating the Python _interpreter_ into another language, not translating Python programs into other languages. MLton-compiled SML is especially fast at symbolic manipulation, e.g. interpreters, so it will be probably be as fast or faster than the current Python interpreter. Then you can start boiling the interpreter down, removing the GC for a start because MLton already has a much better GC... Well, work is already under way (already mentioned) to implement Python in Python, including a reasonable compiler (Psyco). The big deficiency of MLton from a concurrency perspective is inability to use multiprocessors. Of course CPython has the same deficiency. Same with OCaml. Is the ML community trying to do anything about this? -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Juan R. wrote: [EMAIL PROTECTED] ha escrito: - Lisp is hard to learn (because of all those parenthesis) I cannot understand why. It is like if you claim that packaging things in boxes is difficult to learn. HTML and XML have more brackets than LISP (usually double) for structuring data and everyone has learned HTML. I think maybe you missed the point I was making. To make it clearer I'm saying that the arguments that are being made over and over again against Lisp in this thread have been the antithesis of my experience since moving from Python to Lisp. I just prefer personal experience to popular misconceptions :-) Phil -- http://mail.python.org/mailman/listinfo/python-list
A Call to Arms for Python Advocacy
As the Python Advocacy Coordinator, I've put up some wiki pages on the Python website for which I'm soliciting ideas, writing and graphics. Some of the material exists scattered about and just needs locating and organizing. http://wiki.python.org/moin/Advocacy First there is a need for whitepapers and flyers - I've put up a list of suggested topics w/notes at: http://wiki.python.org/moin/AdvocacyWritingTasks And there are fields for signing up for specific documents. We also have a page of possible magazine articles if that's more your style: http://wiki.python.org/moin/ArticleIdeas. These works are to be formed into advocacy kits for various audiences. So far we have the following ideas for kits: - College Student's Python Advocacy Kit - IT Department Python Advocacy Kit - University Educator's Python Advocacy Kit - K-12 Educator's Python Advocacy Kit - Research Lab Python Advocacy Kit The table of contents for the various kits can be found at: http://wiki.python.org/moin/Advocacy#AdvocacyKits Did we miss your kit? And what would you include in any of these? Next, we are seeking reusable/retargetable teaching materials, such as those under a Creative Commons license. We need slide presentations and class handouts. Now I know there are a great many slide presentations on the web about Python. I can google them all but we're not looking for just any presentation, we're looking for the best of field. You can find the collection point at: http://wiki.python.org/moin/Advocacy#TeachingMaterials Last, perhaps you can dash off an idea or two for promotional merchandise. This could be the usuals like shirts but also posters, bumper stickers and buttons. What would you like to have? And with what graphics or slogans? We can reuse some of the slogans from the PyCon Slogan Contest, but are there others? Our collection point for promo item ideas is at: http://wiki.python.org/moin/Advocacy/WearablesGadgets All materials will be credited to the authors to the extent possible by the delivery media. Make your mark. Jeff Rush [EMAIL PROTECTED] Python Advocacy Coordinator -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Steven D'Aprano schrieb: With Lisp macros, even that isn't guaranteed. Now, if Lispers would say Oh yes, macros give you great power, and with great power comes great responsibility. Be careful. Well, macros are one (big) thing that Lisp has and which many other languages don't have. Their are other things too, and some of them are in Python as well, which is a very nice scripting language. Often macros save just some bits of code. Saving one loc is not much you might say. But think about it the other way around. How would you like it to call doodleShooble() each time before you use the if statement? Of course you would not like it. The good thing about Lisp is, that you can eliminate this pattern. Apropos pattern.. most design patterns are not (very) visible in Lisp. Many of them can be abstracted away with macros+functional programming. André -- -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Bill Atkins schrieb: Bill Atkins [EMAIL PROTECTED] writes: every corner of the language? Please. Why are you so post-happy when it's quite obvious that you don't know enough about Lisp to attack it? In addition to macros that define classes or methods, a common macro is the WITH-* macro, which sets up some kind of context, runs the body inside that context, and then does some cleanup. For example, my Lisp vendor, LispWorks, provides the macro MP:WITH-LOCK : (mp:with-lock (*the-big-lock*) (do-something-atomic) (something-else) (almost-odone)) The generated first seizes a process lock called *THE-BIG-LOCK*, runs the code in the body and then releases the lock. I never have to worry that I've taken a lock without releasing it, because LispWorks has encoded that behaviour into MP:WITH-LOCK (and if they handn't, this macro is trivial to write). Now I can tell if I'm keeping a lock around too long because all the code that appears inside this WITH-LOCK is all the code that I'm locking. Further, the generated code is surrounded by an UNWIND-PROTECT, which means that if an error is raised or anything abnormal happens in the dynamic scope of the UNWIND-PROTECT, Lisp will run cleanup code as it flees back up the stack. So if there is an error in my code, it does not prevent other processes from seizing that lock, because it will be released as the error is signaled. Here is the expansion: CL-USER 7 (write (macroexpand '(mp:with-lock (*the-big-lock*) (do-something-atomic) (something-else) (almost-odone))) :pretty t :case :downcase) (let ((#:g17553 *the-big-lock*)) (when (mp:process-lock #:g17553) (unwind-protect (progn (do-something-atomic) (something-else) (almost-odone)) (mp::in-process-unlock #:g17553 Now it happens what Graham described. The blub programmer will explain that this is not needed, because he can do the same thing in blub. In Python you could write a function withLock that takes a lock and a function. Then you can say def throwAway001(): doSomethingAtomic() somethingElse() almostOdone() withLock(theBigLock, throwAway001) or maybe withLock(theBigLock, lambda (): doSomethingAtomic() somethingElse() almostOdone()) So Lisp saves you the lambda (): or def throwAway001():. That is nice I would say. Why write it if the computer could do that for you? André -- -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Paddy [EMAIL PROTECTED] writes: [EMAIL PROTECTED] wrote: Python has to rely more on using the right algorithm... This sound familiar: Macros are dangerous! Yes. I changed my opinion on advocating Python having macros in one of our long threads on the subject. Maintainance counts. Yes, it does, but that should take you to exactly the opposite conclusion. Compilers make you lazy. This is new to me. In fact, for the compiled languages available to me. Using them *first* would be the difficult choice. These are not real sentences, but if you're saying that compiled languages make programming more difficult, then you're simply using the wrong compiled languages. Lisp is a dynamic language that also supports compilation to native code. Unlike Lisp, Python does not have a ubiquitous compiler. It is therefore made to interface nicely with compiled languages. Other compiled What on earth does this mean? You're saying that because Python doesn't have a compiler, it can interface more easily to compiled languages? That's nonsense. Further, most Lisp implementations support an interface to C that doesn't require you to write and compile C code in order to use C extensions in Lisp. Can Python do the same more nicely than Lisp? language users see the need for dynamic interpreted languages like Python and maintain links Python such as the Boost Python C++ wrapper. IronPython for .NET, Jython for Java. Lisp is its own interpreter and compiler, which should be a great advantage, but only if you don't make the mistake of ignoring the wealth of code out there that is written in other languages. Um. -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Paul Rubin schrieb: Steven D'Aprano [EMAIL PROTECTED] writes: Now, if you want to tell me that, despite all the talk, Lisp coders don't actually create new syntax or mini-languages all that often, that they just use macros as functions, then the question becomes: why do you need macros then if you are just using them as functions? Why not use functions? Macros let you write what amounts to functions that don't evaluate their arguments. Think of the endless clpy wars over the ternary conditional operator. You want to write something like def ternary(test, iftrue, iffalse): if test: return iftrue else iffalse but because of side effects, you don't want a = cond(test, f(x), g(x)) to evaluate both f and g. That is trivial to do with a macro but can't be done with a function. I think you could do that with functional programming. You can protect the evaluation by encapsulating the args in a function object? def f_Args(x): return x def g_Args(x): return x and then a = cond(test, f, g, f_Args(x), g_Args(x)) if you adopt cond. But of course it is getting ugly. So a macro can free you from this extra code. André -- -- http://mail.python.org/mailman/listinfo/python-list
Re: Automatic debugging of copy by reference errors?
Carl Banks wrote: Niels L Ellegaard wrote: Marc 'BlackJack' Rintsch wrote: In [EMAIL PROTECTED], Niels L Ellegaard wrote: I have been using scipy for some time now, but in the beginning I made a few mistakes with copying by reference. But copying by reference is the way Python works. Python never copies objects unless you explicitly ask for it. So what you want is a warning for *every* assignment. Maybe I am on the wrong track here, but just to clarify myself: I wanted a each object to know whether or not it was being referred to by a living object, and I wanted to warn the user whenever he tried to change an object that was being refered to by a living object. This really wouldn't work, trust us. Objects do not know who references them, and are not notified when bound to a symbol or added to a container. However, I do think you're right about one thing: it would be nice to have a tool that can catch errors of this sort, even if it's imperfect (as it must be). ISTM the big catch for Fortran programmers is when a mutable container is referenced from multiple places; thus a change via one reference will confusingly show up via the other one. As a Fortranner, I agree. Is there an explanation online of why Python treats lists the way it does? I did not see this question in the Python FAQs at http://www.python.org/doc/faq/ . Here is a short Python code and a Fortran 95 equivalent. a= [1] c= a[:] b= a b[0] = 10 print a,b,c output: [10] [10] [1] program xalias implicit none integer, target :: a(1) integer:: c(1) integer, pointer :: b(:) a = [1] c = a b = a b(1) = 10 print*,a,b,c end program xalias output: 10 10 1 It is possible to get similar behavior when assigning an array (list) in Fortran as in Python, but one must explicitly use a pointer and = instead of =. This works well IMO, causing fewer surprises, and I have never heard Fortranners complain about it. Another way of writing the Fortran code so that a and b occupy the same memory is to use EQUIVALENCE. program xequivalence implicit none integer :: a(1),b(1) integer :: c(1) equivalence (a,b) a= [1] c= a b= a b(1) = 10 print*,a,b,c end program xequivalence output: 10 10 1 EQUIVALENCE is considered a harmful feature of early FORTRAN http://www.ibiblio.org/pub/languages/fortran/ch1-5.html . -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
greg [EMAIL PROTECTED] writes: [EMAIL PROTECTED] wrote: compilers are GREATLY facilitated by having a macro facility because (at first blush) all you need to do is to macro-expand down to something you know how to turn into code. There's no way you could compile Python to efficient machine code just by macro expansion. You'd also need some very heavy-duty type inferencing. When I used to use Ruby a lot, I believed this line that the Ruby community fed itself (and apparently Python feeds itself as well): Ruby/Python has to be interpreted because it's too dynamic. This is wrong, of course. A compiler shifts a lot of decisions that an interpreter would have to make at runtime to compile-time. There is no reason a dynamic language can't enjoy this efficiency. On the other hand, if Python is doing a hash lookup on every function call, as Alex Mizrahi claims, compilation may not do much to smooth over such awkwardness. Python is extremely dynamic, even more so than Lisp. That's why compiling Python is hard, not because it doesn't have macros. Uh huh. More so than Lisp? Just making stuff up now? Despite its dynamism, Lisp is quite compilable. For example, I can redefine classes, functions, macros, etc. at runtime and compiled code referring to the old code will still work. You are conflating dynamism with interpretedness, and that's incorrect. -- http://mail.python.org/mailman/listinfo/python-list
Newbie: Installing packages on windows
Hi, I'm reading the python tutorials on docs.python.org, but I'm still not sure how install a package. I have downloaded pylint in zip form from www.logilab.org, but I'm unsure what to do with it. The file I wish to test (i.e. the file I have writen myself) is located in C:\Python25\ Hope you can help, Barry. -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
greg [EMAIL PROTECTED] writes: When moving a set of statements in Python, you are usually selecting a set of complete lines, cutting them out and then pasting them in between two other lines somewhere else. You're missing Ken's point, which is that in Lisp an s-expression represents a single concept - I can cut out the second form of an IF and know that I'm cutting the entire test-form. I don't have to choose the correct set of complete lines to correctly move code around. Having edited both Lisp and Python code fairly extensively, I can't say that I find editing Python code to be any more difficult or error prone. How extensively? On the plus side, Python makes less demands on the capabilities of the editor. All you really need is block-shifting commands. Bracket matching is handy for expressions but not vital, and you certainly don't need bracket-based auto-indenting. Oh, please. So we should restrict the power of the languages we choose just to make sure that our code can be edited in Notepad? -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
[EMAIL PROTECTED] ha escrito: Juan R. wrote: [EMAIL PROTECTED] ha escrito: - Lisp is hard to learn (because of all those parenthesis) I cannot understand why. It is like if you claim that packaging things in boxes is difficult to learn. HTML and XML have more brackets than LISP (usually double) for structuring data and everyone has learned HTML. I think maybe you missed the point I was making. Yes i did, sorry To make it clearer I'm saying that the arguments that are being made over and over again against Lisp in this thread have been the antithesis of my experience since moving from Python to Lisp. I just prefer personal experience to popular misconceptions :-) I often count 'parentheses' used in other approaches. E.g. the LISP-based [HTML [@:XMLNS http://www.w3.org/1999/xhtml] [HEAD [TITLE Test page]] [BODY]] is SLiP (Python) html(xmlns=http://www.w3.org/1999/xhtml;): head(): title(): Test page body(): LISP-based: 5 ( 5 ) 1 @ 1 : Python: 4 ( 4 ) 1 = 4 4 : -- http://mail.python.org/mailman/listinfo/python-list
Re: alternate language
In article [EMAIL PROTECTED], Bryan [EMAIL PROTECTED] wrote: what is a good alternate language to learn? i just want something to expand my mind and hopefully reduce or delay any chance of alzheimer's. i would especially like to hear from those of you who learned python _before_ these languages. haskell, erlang, ocaml, mozart/oz, rebel, etc. I have no experience with any of these. Of course, now I will give my opinions. :-) Just based on my experience with Python, C, C++, BASIC (several flavors), Fortran 77 (mostly). i don't require any of these features, but extra browny points for any of the following: interactive interpreter Python has several. batteries included Not sure what you mean here. Certainly the standard Python packages would offer you an immediately usable Python from Terminal and some other interpreters. But there are LOTS of add-ons available. A big plus with Open Source. Keeping them coordinated is a task, though (a big minus with Open Source). Overall, I haven't had to mess too much to get lots of usability from Python, especially for Scientific computing. can integrate with c Yes. Several approaches, but none trivial. compiles to native code No. can use a gui toolkit such as wx Yep. Wx is here for Python. Also a book on it by Rappin and Dunn (Manning , publ. 2006) doesn't take 60 hour weeks over years to master You'll be writing code on day 1. Useful code, too. Very, very nice language to learn and use. I recommend Python in a Nutshell by Martelli (O'Reilly Publ.) to read as you learn. Lots of online tutorials. See Python.org, SourceForge and google. I think you can get pretty good at Python coding in a month or so. Along with Perl and Ruby, Python is really a very popular interpreted/scripting language rather than a niche language (which I think most of the ones you mentioned are somewhat niche). That means there's a big, helpful community out there to talk to and lots of code available. I do all my new coding in it and then when I need speed in some routine I rewrite it in C as a Python extension. I can develop many times faster than I could in C/C++ or Fortran or BASIC (even). I cannot compare, however, to the languages you mentioned. Sorry. -- Lou Pecora (my views are my own) REMOVE THIS to email me. -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
[EMAIL PROTECTED] schrieb: Now, speaking as a scientist, permit me to make a small practical suggestion: Why not just figure out a way to simplify some brand of Python -- make parens (or whatever) optionally replace whitespace and line breaks as syntax -- and then add a simple macro facility -- macros are actually a very simple extension if you have homogenous syntax, homogenizing your syntax to the point where macros are possible is the hard part -- and just see what happens. The problem is not so much to add a macro facility ( or source transformer ) but to soften it and make the macro facility actually *simple* to use. Note that you don't need to replace whitespaces. The Python parser is LL(1) and whitespace is almost completely abstracted away once the Python source was tokenized successfully ( there is exactly one non-terminal in the Python grammar, the suite NT, that uses INDENT and DEDENT as moral equivalents for left- and right parens ). Note also that a homogenous syntax is not that important when analyzing parse trees ( on the contrary, the more different structures the better ) but when synthesizing new ones by fitting different fragments of them together. There are two basic approaches. In one you start with a piece of source code ( a template ) and enhance the source description slightly with somewhat like template parameters that keep source fragments and expand them. In this case you also need an unquoting mechanism or a way to evaluate code within the template. The second approach acts with high level wrappers of more low level source trees ( just like ASTs are high level wrappers of concrete syntax trees in most languages ). In Python one might even use operator overloading to hide the AST structure and provide a more convenient syntax. But this only describes the transformational aspect. The definitional part is not less important. I try to consider a grammar description of a full programming language as as script in an own little language ( actually it is and the grammars grammar is often just an EBNF grammar description ). This however presumes that enhancing grammars to enhance languages is a reasonable approach not just in a Lex-Yacc ( or ANTLR ) setting. The next question concerns compositionality of language enhancements or composition of even completely independent language definitions and transformers both on source and on binary level. While this is not feasible in general without creating ambiguities, I believe this problem can be reduced to ambiguity detection in the underlying grammars. One of two general things are likely to happen: Either people will not use them, and they will languish and die, and then at least you can say; Been there, done that to the Lisp community. Or, more likely, the some subset of the Python community will get it, and will figure out how useful they are, although it might take some time. And then you might find yourself with a wonderful new tool. I think so too. You might even get a compiler out of the deal, at a pretty low cost, too! If you get macros, and get a compiler, I'm pretty sure that you will have no problem winning over the Lisp community, who would LOVE to have your extensive libraries, and that you will probably be able to maintain and improve your flagging position wrt Ruby (which, according to Matz, is more-or-less just Lisp w/o macros.) Just a moment ago you called programmers of other languages flies which I found annoying and now you offer LOVE in big letters? I don't even think the competition to Ruby matters. Once an easy to use metaprogramming system could be done for Python it could be ported with some adaptions to other languages with more complicated syntax ( non LL(1) parsable ). Kay -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
On Dec 11, 2:17 pm, Bill Atkins [EMAIL PROTECTED] wrote: Paddy [EMAIL PROTECTED] writes: [EMAIL PROTECTED] wrote: Python has to rely more on using the right algorithm... This sound familiar: Macros are dangerous! Yes. I changed my opinion on advocating Python having macros in one of our long threads on the subject. Maintainance counts.Yes, it does, but that should take you to exactly the opposite conclusion. I won't duplicate the arguments against macros made elsewhere in the thread. Compilers make you lazy. This is new to me. In fact, for the compiled languages available to me. Using them *first* would be the difficult choice.These are not real sentences, but if you're saying that compiled languages make programming more difficult, then you're simply using the wrong compiled languages. Lisp is a dynamic language that also supports compilation to native code. Lisp was not a compiled language available to me, and even after my use of Cadence Skill, I would not consider Lisp for writing an extension unless Lisp had a library close to what I wanted, and there was a good way to link Python to the compiled Lisp code. Unlike Lisp, Python does not have a ubiquitous compiler. It is therefore made to interface nicely with compiled languages. Other compiledWhat on earth does this mean? You're saying that because Python doesn't have a compiler, it can interface more easily to compiled languages? That's nonsense. No. I am saying that *because* it does not have a compiler, it has been *made to* integrate nicely with compiled languages; and further, I am saying that because some compiled language package maintainers see the advantages of using dynamic languages, they support Python integration. Further, most Lisp implementations support an interface to C that doesn't require you to write and compile C code in order to use C extensions in Lisp. Can Python do the same more nicely than Lisp? Python does the same. It might well be nicer but I do not know how Lisp does this. http://docs.python.org/dev/lib/module-ctypes.html http://www.boost.org/libs/python/doc/ http://www.python.org/pypi/pyobjc/1.3.5 (The last is used within Apple for some aspects of development). The above list is not exhaustive language users see the need for dynamic interpreted languages like Python and maintain links Python such as the Boost Python C++ wrapper. IronPython for .NET, Jython for Java. Lisp is its own interpreter and compiler, which should be a great advantage, but only if you don't make the mistake of ignoring the wealth of code out there that is written in other languages. Um. Yep. - Paddy. -- http://mail.python.org/mailman/listinfo/python-list
Re: Automatic debugging of copy by reference errors?
In [EMAIL PROTECTED], Beliavsky wrote: ISTM the big catch for Fortran programmers is when a mutable container is referenced from multiple places; thus a change via one reference will confusingly show up via the other one. As a Fortranner, I agree. Is there an explanation online of why Python treats lists the way it does? I did not see this question in the Python FAQs at http://www.python.org/doc/faq/ . This question sounds as if lists are treated somehow special. They are treated like any other object in Python. Any assignment binds an object to a name or puts a reference into a container object. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Bill Atkins [EMAIL PROTECTED] writes: There's no way you could compile Python to efficient machine code just by macro expansion. You'd also need some very heavy-duty type inferencing. When I used to use Ruby a lot, I believed this line that the Ruby community fed itself (and apparently Python feeds itself as well): Ruby/Python has to be interpreted because it's too dynamic. I don't think you can reasonably compile Python just by what we'd usually call macro expansion. You need fancier compiler techniques. Python is extremely dynamic, even more so than Lisp. That's why compiling Python is hard, not because it doesn't have macros. Uh huh. More so than Lisp? Just making stuff up now? Python is more dynamic than Lisp. Despite its dynamism, Lisp is quite compilable. Yes. Lisp is dynamic, but less so than Python. And not by coincidence, Lisp is more compilable than Python. For example, I can redefine classes, functions, macros, etc. at runtime and compiled code referring to the old code will still work. You are conflating dynamism with interpretedness, and that's incorrect. If you say foo.frob() in Python, that's supposed to look up 'frob' in a dictionary hanging off of foo. You can modify the contents of this dictionary any time you want. The Lisp equivalent would be some generic function (frob foo) that you define with CLOS in the usual way, but then there's some hashtable that lets you redefine frob at any time by modifying it (i.e. just a normal hashtable that you poke with setf, no special notification to the class system). This can happen anywhere in the code, in another thread, or whatever. You can even replace that hashtable with another hashtable. You can also insert (at any time) a __getattr__ method into foo's class, that is a user-supplied function that replaces the hash lookup. This stuff is all quite hard to optimize the way CLOS can be optimized. I'd like to hope Python tones down these aspects of its dynamism as it continues to evolve. -- http://mail.python.org/mailman/listinfo/python-list
Re: How do I edit a PythonWin path to import custom built modules???
mohan wrote: I had created my own modules (.py files) in drives and folders other than the python root. Probably easiest if you keep them all in one place. Then add that place to your path by going into Control Panel|System|Advanced|Environment Variables and adding the path to the path variable. Hope that helps. rd -- http://mail.python.org/mailman/listinfo/python-list
Encapsulating conditional execution based on list membership - how do you do it?
I have a series of scripts which retrieve files. None of these scripts
should continue if the file to be retrieved already exists in the
archive. Here is the code:
if f in path(self.storage.archive).files('*'):
print f, exists in archive. Not continuing
sys.exit()
self.storage is a class which gives me object-oriented access to the
filesystem directories that will be manipulated by the script. E.g.
self.storage.archive is a string which refers to a certain directory.
Initializing this object initializes all the members (input, archive,
output, workfiles) and makes all the correct directories.
ok, so I'm thinking of adding a method to the storage class so I can do
this:
self.storage.archive_has(f, print_msg=True) and sys.exit()
but really there is no need to hardcode which storage directory. So I'm
thinking:
self.storage.memberof('archive', f, print_msg=Tree) and sys.exit()
Is that the best solution you can think of?
--
http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
In [EMAIL PROTECTED], Kay Schluehr wrote: Once an easy to use metaprogramming system could be done for Python it could be ported with some adaptions to other languages with more complicated syntax ( non LL(1) parsable ). FYI: Here's how Nemerle does macros: http://nemerle.org/Macros I guess you can't really transform Nemerle into a completely different language, but it is at least interesting to see such a feature in language with a more complex syntax than Lisp. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
ElementTree, XML and Unicode -- C0 Controls
Hi all, The unicode code points in the -001F range -- except newline, tab, carriage return -- are not legal XML 1.0 characters. Attempts to serialize and deserialize such strings with ElementTree will fail: elt = Element(root, char=u\u) xml = tostring(elt) xml 'root char=\x00 /' fromstring(xml) [...] xml.parsers.expat.ExpatError: not well-formed (invalid token): line 1, column 12 Good ! But I was expecting a failure *earlier*, in the tostring function -- I basically assumed that ElementTree would refuse to generate a XML fragment that is not well-formed. Could anyone comment on the rationale behind the current behavior ? Is it a performance issue, the search for non-valid unicode code points being too expensive ? Cheers, SB -- http://mail.python.org/mailman/listinfo/python-list
SSH File Transfer Protocol or SFTP
Is there a module in Python available that I can use for uploading files via SFTP (SSH File Transfer Protocol)? Or do you think that FTP protocol for files uploading is OK? Thank you for replies Lad. -- http://mail.python.org/mailman/listinfo/python-list
Re: SSH File Transfer Protocol or SFTP
On 11 Dec 2006 07:29:27 -0800, Lad [EMAIL PROTECTED] wrote: Is there a module in Python available that I can use for uploading files via SFTP (SSH File Transfer Protocol)? Or do you think that FTP protocol for files uploading is OK? Thank you for replies Lad. Twisted Conch includes support for both SFTP servers and clients. http://twistedmatrix.com/trac/wiki/TwistedConch Jean-Paul -- http://mail.python.org/mailman/listinfo/python-list
Rinning Excel macro's with Jython?
Is there a way to run Excel macro's with jython? Similar to the win32com in python? Thank you. -- http://mail.python.org/mailman/listinfo/python-list
Re: SSH File Transfer Protocol or SFTP
Lad wrote: Is there a module in Python available that I can use for uploading files via SFTP (SSH File Transfer Protocol)? Or do you think that FTP protocol for files uploading is OK? Thank you for replies Lad. You probably want Paramiko (http://www.lag.net/paramiko/). It provides extensive support for the SSH protocol, and ships with, among other things, a sample script demonstrating SFTP. Regards, Jan -- http://mail.python.org/mailman/listinfo/python-list
Re: Pyparsing troubles
[EMAIL PROTECTED] writes: Hello, I have written a small pyparsing parser to recognize dates in the style november 1st. I wrote something to the effect of: expression = task + date and tried to parse Doctor's appointment on november 1st, hoping that task would be Doctor's appointment and date would be on november 1st (the parser does match on november 1st to date). I have set task as Regex(.*?), ZeroOrMore(Word(alphas)), etc, but I can't get it to match, it matches everything to task and ignores date until it gets to the end of the string. Can anyone help? As described, this is a Natural Language Programming (NLP) problem, which means you will have a lot more trouble with understanding what you want to do than in coding it. Also, dates are notoriously tough to parse, because of so many variants, so there are libraries to do just that. If you want to tackle it systematically: 1. Get a corpus of texts which illustrate the ways the users might state the date. E.g., 2006-11-01, 1-Nov-06, November 1, Nov. first, first of November, 10 days prior to Veterans Day, next week, . 2. If you can control the input, much better. Either by a form which forces specific values for day, month, year, hour, minute, or by requiring IETF format (-mm-ddThh:mm:ss). 3. Determine the syntax rules for each example. If possible, abstract these to general rules which work on more than one example. 4. At this point, you should know enough to decide if it is a: a) Regular expression, parseable with a regexp engine b) Context Free Grammar (CFG), parseable with a LL(1) or LALR(1) parser. c) Context Dependent Grammar, parseable with an ad hoc parser with special rules. d) Free text, not parseable in the normal sense, but perhaps understandable with statistical analysis NLP techniques. f) Hodgepodge not amenable to machine analysis. 5. Then we could look at using pyparser. But we'd have to see the pyparser code you tried. -- Harry George PLM Engineering Architecture -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Paul Rubin http://[EMAIL PROTECTED] writes: If you say foo.frob() in Python, that's supposed to look up 'frob' in a dictionary hanging off of foo. You can modify the contents of this dictionary any time you want. You can redefine CLOS methods at run time any time you like, so this doesn't make Python more /dynamic/ than CLOS. Maybe you should replace more dynamic with less managable, if that's what you mean? -- (espen) -- http://mail.python.org/mailman/listinfo/python-list
Re: ElementTree, XML and Unicode -- C0 Controls
Sébastien Boisgérault wrote: Could anyone comment on the rationale behind the current behavior ? Is it a performance issue, the search for non-valid unicode code points being too expensive ? the default serializer doesn't do any validation or well-formedness checks at all; it assumes that you know what you're doing. /F -- http://mail.python.org/mailman/listinfo/python-list
Re: SSH File Transfer Protocol or SFTP
Lad wrote: Is there a module in Python available that I can use for uploading files via SFTP (SSH File Transfer Protocol)? Or do you think that FTP protocol for files uploading is OK? Thank you for replies Lad. I believe there are many of those, personally i am using paramiko : http://www.lag.net/paramiko/ HIH -avell -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Bill Atkins wrote: greg [EMAIL PROTECTED] writes: On the plus side, Python makes less demands on the capabilities of the editor. All you really need is block-shifting commands. Bracket matching is handy for expressions but not vital, and you certainly don't need bracket-based auto-indenting. Oh, please. So we should restrict the power of the languages we choose just to make sure that our code can be edited in Notepad? Perhaps not. The use of a decent editor seems a fair requirement for any language. But one of the things that I dislike about Java, .NET and to some extent XML (XML Schema for instance), is that the only way to really be productive in these languages/environments is to use tools that generate or otherwise manage huge amounts of code for you based on whatever GUI settings. If the language is so complex or verbose that you can't really use it without a GUI tool, then why bother having a language in the first place. Furthermore these tools are typically expensive and to run comfortably they require more processing power and memory than the lightweight ultra-portable type laptops that I like so much can provide. I can't speak about Lisp, but the great thing about Python, IMHO, is that you can get quite far with not much more than Notepad. I find this important because I find GUIs a very tedious and ineffective way to describe whatever it is that I am trying to implement. Perhaps I'm just getting old ... Regards, Jan -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Marc 'BlackJack' Rintsch schrieb: In [EMAIL PROTECTED], Kay Schluehr wrote: Once an easy to use metaprogramming system could be done for Python it could be ported with some adaptions to other languages with more complicated syntax ( non LL(1) parsable ). FYI: Here's how Nemerle does macros: http://nemerle.org/Macros I guess you can't really transform Nemerle into a completely different language, but it is at least interesting to see such a feature in language with a more complex syntax than Lisp. Ciao, Marc 'BlackJack' Rintsch Hi Mark, there are quite a lot of meta programming systems ( MPS ) for non Lispy languages ( O'Caml, Haskell, Java of course and also Dylan as a member of the Lisp family with non homogenous syntax ). I hope I will find time in the new year to review and compare them to the grammar based approach I described in the grandparent post and follow myself with EasyExtend for Python - which is *radical* and somewhat in between a language specific MPS and Lex/Yacc. The idea to separate the MPS from the host language but providing a multi-language framework is somewhat complementary to that of PyPy that is a framework that supports several backends for one language. -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Espen Vestre [EMAIL PROTECTED] writes: If you say foo.frob() in Python, that's supposed to look up 'frob' in a dictionary hanging off of foo. You can modify the contents of this dictionary any time you want. You can redefine CLOS methods at run time any time you like, so this doesn't make Python more /dynamic/ than CLOS. Maybe you should replace more dynamic with less managable, if that's what you mean? Can you redefine CLOS methods without calling CLOS functions that tell the object system what to expect (so it can do things like update the MRO cache)? I.e. can you redefine them by poking some random dictionary? You can in Python. I don't claim that's a good thing. -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Marc 'BlackJack' Rintsch [EMAIL PROTECTED] writes: FYI: Here's how Nemerle does macros: http://nemerle.org/Macros I guess you can't really transform Nemerle into a completely different language, but it is at least interesting to see such a feature in language with a more complex syntax than Lisp. Nobody seems to concerned that Haskell lacks macros. What's up with that? -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Bill Atkins wrote: On the plus side, Python makes less demands on the capabilities of the editor. All you really need is block-shifting commands. Bracket matching is handy for expressions but not vital, and you certainly don't need bracket-based auto-indenting. Oh, please. So we should restrict the power of the languages we choose just to make sure that our code can be edited in Notepad? In the real world, it's a non-negligible consideration, IMO. I find myself needing to write code on machines that aren't my usual dev machine at least a couple of times a year, and not having to install a particular editor is nice (especially in terms of keeping the modifications to someone else's machine down to a minimum). It's hardly a dealbreaker for a particular language, but it's far from worthless. -- http://mail.python.org/mailman/listinfo/python-list
Help with weave.blitz()
Hello, I'm a new scipy user, and I'm trying to speed up some array code with weave. I'm running xp with gcc from cgywin, and scipy.weave.test() returns an OK status. I'm trying to speed up the code below. I've found a couple of examples of weave on the web, and I think it should be straight forward, but I keep getting the following error when calling weave.blitz(expr). It's complaining about the variable being assigned, I've tried listing it in the blitz call with no luck. Any help is appreciated. PS I've also posted to scipy.org Thank you, Frank ***ERROR*** Traceback (most recent call last): File D:/Documents/Homework/MTMG310/Project/hw6r3VectorizeWeave.py, line 436, in -toplevel- prof.runcall(main) File C:\Python24\Lib\hotshot\__init__.py, line 76, in runcall return self._prof.runcall(func, args, kw) File D:/Documents/Homework/MTMG310/Project/hw6r3VectorizeWeave.py, line 383, in main findw(w,wprior,phiprior,uprior,vprior) File D:/Documents/Homework/MTMG310/Project/hw6r3VectorizeWeave.py, line 136, in findw weave.blitz(expr) File C:\Python24\Lib\site-packages\scipy\weave\blitz_tools.py, line 35, in blitz if check_size and not size_check.check_expr(expr,local_dict,global_dict): File C:\Python24\Lib\site-packages\scipy\weave\size_check.py, line 51, in check_expr exec(expr,values) File string, line 1 wnext[1:grows-1,1:gcols-1] =( alpha * w[1:grows-1,1:gcols-1] + ax * (w[1:grows-1,0:gcols-2] + w[1:grows-1,2:gcols]) + ^ SyntaxError: invalid syntax ***CODE*** def findw(wnext,wprior,phiprior,uprior,vprior): #format here is x[i,j] where i's are rows, j's columns, use flipud() to get the #print out consistent with the spacial up-down directions #assign local names that are more #inline with the class notation w = wprior phi = phiprior u = uprior v = vprior #three of the BC are known so just set them #symetry plane wnext[0,0:gcols] = 0.0 #upper wall wnext[gN,0:gcols] = 2.0/gdy**2 * (phi[gN,0:gcols] - phi[gN-1,0:gcols]) #inlet, off the walls wnext[1:grows-1,0] = 0.0 upos = where(u0) vpos = where(v0) Sx = ones_like(u) Sx[upos] = 0.0 xSx = 1.0 - Sx Sy = ones_like(v) Sy[vpos] = 0.0 ySy = 1.0 - Sy uw = u*w vw = v*w ax = gnu*gdt/gdx**2 ay = gnu*gdt/gdy**2 dtdx = gdt/gdx dtdy = gdt/gdy alpha = (1.0 - 2.0*ax - 2.0*ay) #interior nodes expr = \ wnext[1:grows-1,1:gcols-1] =( alpha * w[1:grows-1,1:gcols-1] + ax * (w[1:grows-1,0:gcols-2] + w[1:grows-1,2:gcols]) + ay * (w[0:grows-2,1:gcols-1] + w[2:grows,1:gcols-1]) - dtdx * (xSx[1:grows-1,1:gcols-1] * (uw[1:grows-1,1:gcols-1] - uw[1:grows-1,0:gcols-2]) - Sx[1:grows-1,1:gcols-1] * (uw[1:grows-1,2:gcols] - uw[1:grows-1,1:gcols-1])) - dtdy * (ySy[1:grows-1,1:gcols-1] * (vw[1:grows-1,1:gcols-1] - vw[1:grows-1,0:gcols-2]) - Sy[1:grows-1,1:gcols-1] * (vw[1:grows-1,2:gcols] - vw[1:grows-1,1:gcols-1])) ) #weave.inline(expr,['wnext','w','Sx','xSx','Sy','ySy','uw','vw','ax','ay','dtdx','dtdy','alpha','grows','gcols']) #weave.inline(expr,['wnext'],compiler='gcc',verbose=2) #weave.blitz(expr,['wnext','w','Sx','xSx','Sy','ySy','uw','vw','ax','ay','dtdx','dtdy','alpha','grows','gcols']) #weave.blitz(expr,size_check=1) #weave.inline(expr,['wnext']) weave.blitz(expr) ##for j in range(1,gasizej-1): ##for i in range(1,gasizei-1): ## ##wnext[i,j] =( w[i,j] + gnu*gdt/gdx**2 * (w[i,j-1] - 2.0*w[i,j] + w[i,j+1]) + ## gnu*gdt/gdy**2 * (w[i-1,j] - 2.0*w[i,j] + w[i+1,j]) - ## (1.0 - Sx[i,j]) * gdt/gdx * (uw[i,j] - uw[i,j-1]) - ## Sx[i,j] * gdt/gdx * (uw[i,j+1] - uw[i,j]) - ## (1.0 - Sy[i,j]) * gdt/gdy * (vw[i,j] - vw[i-1,j]) - ## Sy[i,j] * gdt/gdy * (vw[i+1,j] - vw[i,j]) ) ##print ***wnext ##print i: , i, j: , j, wnext[i,j]: , wnext[i,j] #final BC at outlet, off walls wnext[1:grows-1,gM] = wnext[1:grows-1,gM-1] -- http://mail.python.org/mailman/listinfo/python-list
Re: alternate language
In article [EMAIL PROTECTED], Lou Pecora [EMAIL PROTECTED] wrote: In article [EMAIL PROTECTED], Bryan [EMAIL PROTECTED] wrote: what is a good alternate language to learn? i just want something to expand my mind and hopefully reduce or delay any chance of alzheimer's. i would especially like to hear from those of you who learned python _before_ these languages. haskell, erlang, ocaml, mozart/oz, rebel, etc. I have no experience with any of these. Of course, now I will give my opinions. :-) Just based on my experience with Python, C, C++, BASIC (several flavors), Fortran 77 (mostly). i don't require any of these features, but extra browny points for any of the following: interactive interpreter Python has several. Um... I think the original poster is saying that he already knows Python and wants to learn another language. He particularly wants opinions from other people who have learned these languages *after* learning Python. -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ Member of the Groucho Marx Fan Club -- http://mail.python.org/mailman/listinfo/python-list
Help with install python-mysql lib on OS X
How do you install MySQL-python on a PPC OS X 10.4 machine with MySQL 4.1? And I know about the precompiled binary at macpython.org... I'm just sick of getting this warning Python 2.5 (r25:51918, Sep 19 2006, 08:49:13) [GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin Type help, copyright, credits or license for more information. import _mysql __main__:1: RuntimeWarning: Python C API version mismatch for module _mysql: This Python has API version 1013, module _mysql has version 1012. -- http://mail.python.org/mailman/listinfo/python-list
RE: merits of Lisp vs Python
After 394 postings in this thread, you all have convinced me. I am dropping all of my python code and switching to Lisp. thank-you The information contained in this message and any attachment may be proprietary, confidential, and privileged or subject to the work product doctrine and thus protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify me immediately by replying to this message and deleting it and all copies and backups thereof. Thank you. -- http://mail.python.org/mailman/listinfo/python-list
Re: wxPython: Icon aus base64 decoded Image
Roland Rickborn wrote: Wo ist der Fehler und was muss ich machen, damit das Icon angezeigt wird? I'm sorry that I can't help you, but you'll probably get more answers if you write again in English (this is comp.lang.python). Grüße, Björn -- BOFH excuse #126: it has Intel Inside -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Paul Rubin http://[EMAIL PROTECTED] writes: André Thieme [EMAIL PROTECTED] writes: Instead of function = memoize(function) one could just say: memoize(function). In Python you'd say @memoize def function(): ... But in Lisp you'd write the function, say, Damn, I need to memoize this sucker, and evaluate (memoize 'function) and the function would be memoized. I suspect you could even do this while the program was running from something like SLIME. Basically the memoize macro changes the function cell of the symbol, so from that point all the calls to the function would be to the memoized version. -- Fred Gilham [EMAIL PROTECTED] One of the authors of the Daniel Bell volume says, in horror and astonishment, that the radical right intends to repeal the twentieth century. Heaven forfend! Who would want to repeal the twentieth century, the century of horror, the century of collectivism, the century of mass destruction and genocide, who would want to repeal that! -- Murray Rothbard -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Kay Schluehr wrote: [Interesting and useful analysis of issues in language homogenization snipped.] You might even get a compiler out of the deal, at a pretty low cost, too! If you get macros, and get a compiler, I'm pretty sure that you will have no problem winning over the Lisp community, who would LOVE to have your extensive libraries, and that you will probably be able to maintain and improve your flagging position wrt Ruby (which, according to Matz, is more-or-less just Lisp w/o macros.) Just a moment ago you called programmers of other languages flies which I found annoying and now you offer LOVE in big letters? Since everyone seems to have taken offence and this remark, let me hereby apologize for the unintended implication. For the record, I quote myself in full: Common) Lisp is the only industrial strength language with both pure compositionality and a real compiler. What Python has is stupid slogans (It fits your brain. Only one way to do things.) and an infinite community of flies that, for some inexplicable reason, believe these stupid slogns. These flies are, however, quite useful because they produce infinite numbers of random libraries, some of which end up being useful. But consider: Tcl replaced Csh, Perl replaced Tcl, Python is rapidly replacing Perl, and Ruby is simultaneously and even more rapidly replacing Python. Each is closer to Lisp than the last; the world is returning to Lisp and is dragging the flies with it. Eventually the flies will descend upon Lisp itself and will bring with them their infinite number of random libraries, and then things will be where they should have been 20 years ago, but got sidetracked by Tcl and other line noise. I've already admitted that this was both a poor choice of words and, as pointed out by Carl, an ad hominem argument. However, if you read the whole thing you'll see that I'm really railing against the silly It fits your brain and Only one way to do things marketing hype, and programmers who seem to swallow and repeat it, not programmers in general, nor even python programmers in general. In the last part it say: Eventually the flies will descend upon Lisp itself and will bring with them their infinite number of random libraries, ... Note that I'm looking forward to this! So, although flies was a poor choice of words, for which I whole heartedly apologize to those who might have taken offence (and I do understand the reading and why you might take offense at this given the context!), what I meant to say was: Hey, all you busy little pythonistas creating a million interesting libraries (and some not, but that's fine) come over here and help do that for our language too! Maybe beavers would have been a better animal. Mea Culpa! Regardless, the topic of the rest our conversation -- how to put macros and a compiler into Python -- stands as an interesting possibility because it would enable us to come to you rather than the other way around -- I'd be happy either way. -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Paul Rubin http://[EMAIL PROTECTED] writes: Nobody seems to concerned that Haskell lacks macros. What's up with that? Haskell is lazy, so it doesn't need macros (well, it would be more accurate to say that by not evaluating function arguments until they are needed it makes many of the usual macro usecases moot). lazyness has a nontrivial cost, however, both runtime and cognitive. hoping he's not answering a rhetorical question, --m -- I'm on a seafood diet -- I see food and I eat it. -- anonymous -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Steven D'Aprano schrieb: On Sat, 09 Dec 2006 22:41:12 -0500, Ken Tilton wrote: I know that. It was more of a rhetorical question -- Lispers are either trying to emphasis the radical nature of what you can do with macros, or understate it and make them seem just like functions. Yep, both. The first is rare. CLOS is one, my Cells (ported this summer to PyCells as part of SoC 2006) is another. The latter is the norm. If macros' advanced usage is rare, and most usage of macros could be done by functions, then maybe that explains why so many coders don't miss them. You can't do with functions what you can do with macros. Macros are just parameterized code. A template. Compare it with HTML templates html body Your name is ?py print name.getUser(loggedInUser) ?.br Welcome! /body /html The page that arrives the user does not include any template code anymore. Just plain html. Same happens with Lisp macros. After compilation (preprocessing the html template by Zope) there are no macros left. So in the end you have just some Lisp functions. So one does not *need* macros, in the sense of turing completeness. But at the same time one can meet lots of places where templates can make sense and where they are used. Even the programmers of Zope thought of them as a plus for productivity. In Lisp you don't always design one huge macro after the other, which really saves a lot of code. Many macros save one or two short lines of code. This might sound not important. But it sums up. Somewhere else I asked you to imagine how you would like it if you had to call doodleBoodle() before each if-statement to make it work. That would be plain stupid if you had to. So if you meet something in code that you use several times, then you factor that repeating block of code out into a function that takes another function which will get called in the right environment. And macros help here only to save one or two loc. But as I said, it sums up. André -- -- http://mail.python.org/mailman/listinfo/python-list
Re: alternate language
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Aahz) wrote: In article [EMAIL PROTECTED], Lou Pecora [EMAIL PROTECTED] wrote: In article [EMAIL PROTECTED], Bryan [EMAIL PROTECTED] wrote: what is a good alternate language to learn? i just want something to expand my mind and hopefully reduce or delay any chance of alzheimer's. i would especially like to hear from those of you who learned python _before_ these languages. haskell, erlang, ocaml, mozart/oz, rebel, etc. I have no experience with any of these. Of course, now I will give my opinions. :-) Just based on my experience with Python, C, C++, BASIC (several flavors), Fortran 77 (mostly). i don't require any of these features, but extra browny points for any of the following: interactive interpreter Python has several. Um... I think the original poster is saying that he already knows Python and wants to learn another language. He particularly wants opinions from other people who have learned these languages *after* learning Python. Oh...never mind. :-) -- Lou Pecora (my views are my own) REMOVE THIS to email me. -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie: Installing packages on windows
[EMAIL PROTECTED] wrote: I'm reading the python tutorials on docs.python.org, but I'm still not sure how install a package. I have downloaded pylint in zip form from www.logilab.org, but I'm unsure what to do with it. The file I wish to test (i.e. the file I have writen myself) is located in C:\Python25\ step 1: look for a README file in the ZIP archive, and follow the instructions in that file. /F -- http://mail.python.org/mailman/listinfo/python-list
Re: alternate language
Bryan wrote: what is a good alternate language to learn? i just want something to expand my mind and hopefully reduce or delay any chance of alzheimer's. i would especially like to hear from those of you who learned python _before_ these languages. haskell, erlang, ocaml, mozart/oz, rebel, etc. i don't require any of these features, but extra browny points for any of the following: interactive interpreter batteries included can integrate with c compiles to native code can use a gui toolkit such as wx doesn't take 60 hour weeks over years to master Chicken Scheme: http://www.call-with-current-continuation.org (not sure about wx, but there are various GUI wrappers available) Michele Simionato -- http://mail.python.org/mailman/listinfo/python-list
How can I get involved
Hey all, I'm messaging this group for the first time. Basically I've been a (pretty intensive) Python programmer for the past 2 years. I started a software company which has just released an SDK (v1.0b - developer preview) for developing web applications in Python. Key points: 1) It comes with a non-relational schema-free database we designed 2) The application server is based on CherryPy 3) The UI engine is XSLT based (but it also supports Cheetah and Clearsilver via plugins - out of the box) Basically, I really love the language and I'm looking for ways to get involved in the community and contribute. My past (pre-Python) experience has been mainly in web-technologies - Java, PHP, ASP and a little bit of C. Any ideas? Prateek -- http://mail.python.org/mailman/listinfo/python-list
os.popen3 hangs in Windows XP SP1, SP2. Python 2.5 2.4. Consistent test case.
Hi all,
I have a consistent test case where os.popen3() hangs in Windows. The
system hangs when retrieving the lines from the child process stdout.
I know there were several reports related to os.popen3() hanging under
Windows in this group before.
I stumbled on a case where a piece of code works in some occasions and
hangs consistently given different data. It performs exactly the same
on 3 different computers running Windows:
- computer 1: XP, SP1, Python 2.4.3
- computer 2: XP, SP2, Python 2.4.3
- computer 3: XP, SP2, Python 2.5
I know that a bug
(http://sourceforge.net/tracker/index.php?func=detailaid=527783group_id=5470atid=105470)
related to popen3 hanging was opened and closed as 'not-a-bug'.
However I think that the test case I have is not a application problem
(a deadlock) and is a true problem with popen3() under Windows (but I
could be wrong.)
What I have is:
- a test script: tpopen.py.
- It uses nosetests.py to execute unit tests: it runs:
- test_roman.py, a test script for :
- roman.py, a modified version of Mark Pilgrims's roman.py
module, I used to test nosetests.
#--
The test case I have is a short program that invokes nosetests to run a
test_roman.py:
- The script topen.py is executed on the command line with::
topen test_roman
- topen.py executes
stdin, stdout, stderr = os.popen3('nosetests --nocapture
test_roman')
- The program runs properly if it then executes the following code
right after the call to os.popen3()::
stderr_lines = list(stderr)
stdin.close()
stderr.close()
pgm_exit_code = stdout.close() or 0
- The program hangs when it tries to read stdout (**but only ** when it
is running nosetests for the test_roman.py). The code following the
call to os.popen3() is::
for line in stdout:
sys.stdout.write(line) # prints almost all nosetests
stdout lines except for some at the end!
# then it HANGS.
stderr_lines = list(stderr)
stdin.close()
stderr.close()
pgm_exit_code = stdout.close() or 0
Note that it also hangs if topen.py executes:
stdin, stdout, stderr = os.popen3('nosetests test_roman')
Or if I modify the print statements inside test_roman.py, the unit test
scrip executed by nosetests.py.
I also tried changing the order of the closing of the stream (like
doing stdin.close() right after the popen3() call). No impact.
Note that popen3() call does not hang if topen runs other unit test
scripts i have.
#-
QUESTIONS:
- Can any one see a problem with the order of execution that could
cause a deadlock here (topen.py code posted below)?
- Should I post a new Python bug, providing the complete test code or,
re-open the above mentioned bug?
# tpopen.py
---
import sys
import os
#
-
# p o p e n 3 ( ) -- Execute a popen3 command --
# ^^^
#
def popen3(command,
stdout_parser=None,
stderr_parser=None,
default_stdout_value=None,
default_stderr_value=None) :
pgm_exit_code = 0
stdout_value, stderr_value = default_stdout_value,
default_stderr_value
stdin, stdout, stderr = os.popen3(command)
stdin.close()
if stdout_parser:
stdout_value = stdout_parser(stdout)
if stderr_parser:
stderr_value = stderr_parser(stderr)
stderr.close()
pgm_exit_code = stdout.close() or 0
return (stdout_value, stderr_value, pgm_exit_code)
#
-
cmd1 = 'nosetests ' + sys.argv[1]
cmd2 = 'nosetests --nocapture ' + sys.argv[1]
def print_stream(stream):
for line in stream:
sys.stdout.write(line)
print '- CMD 1 , no stdout print : does not hang '
stdout, stderr_lines, pgm_exit_code = popen3(cmd1, None, list)
print 'stderr_lines: ', stderr_lines
print 'program exit code : ', pgm_exit_code
print '- CMD 2 : HANGS after printing almost all stdout -'
stdout, stderr_lines, pgm_exit_code = popen3(cmd2, print_stream, list)
print 'stderr_lines: ', stderr_lines
print 'program exit code : ', pgm_exit_code
print '- CMD 1 , stdout print : HANGS ---'
stdout, stderr_lines, pgm_exit_code = popen3(cmd1, print_stream, list)
print 'stderr_lines: ', stderr_lines
print 'program exit code : ', pgm_exit_code
#
-
--
Pierre Rouleau
--
http://mail.python.org/mailman/listinfo/python-list
Re: Automatic debugging of copy by reference errors?
greg wrote: You need to stop using the term copy by reference, because it's meaningless. Just remember that assignment I agree that copy by reference is a bad choice of words. I meant pass by reference and assign by reference. But the effect is to make a virtual copy, so although the phrase is perhaps misleading, it is not meaningless. cut Again, this is something you'll find easier when you've had more experience with Python. Generally, you only need to copy something when you want an independent object that you can manipulate without affecting anything else, although that probably doesn't sound very helpful. Yes, I realize that, but deciding *when* you need a copy is the hard part. -- http://mail.python.org/mailman/listinfo/python-list
