Re: How Compute # of Days between Two Dates?
from datetime import datetime # batteries included today = datetime.now() xmas = datetime(today.year,12,25) if (xmas - today).days > 1: print "%d days until Christmas" % (xmas - today).days else: print "Merry Christmas!" -- http://mail.python.org/mailman/listinfo/python-list
Re: precedence of [] vs .
On Aug 14, 6:01 pm, "Calvin Spealman" <[EMAIL PROTECTED]> wrote: > > attribute access (foo.bar) binds more tightly than subscripting (foo[bar]). That certainly looks right, and in retrospect I wonder that I even doubted it. But even the official docs seem to me to specify otherwise: http://docs.python.org/ref/summary.html mt -- http://mail.python.org/mailman/listinfo/python-list
precedence of [] vs .
I wrote some code to test the precedence of getitem vs getattr; it shows that getitem binds tighter. I have been handed some code that relies on the observed behavior. However, the Nutshell precedence list claims the opposite. Is the Nutshell wrong or am I missing something or is this a bug? class a(object): def __getitem__(self,item): return str(item)[:-1] class b(object): def __getattr__(self,item): return str(item)[::-1] Albert = a() print Albert['abcd'] # prints 'abc' Barney = b() print Barney.abc # print 'cba' print Barney.Albert['abcd'] # raises TypeError; tries to evaluate 'treblA'['abcd'] # I expected 'cba' based on Nutshell 2d Ed p 50 -- http://mail.python.org/mailman/listinfo/python-list
Re: internet searching program
I think you are talking about "screen scraping". Your program can get the html for the page, and search for an appropriate pattern. Look at the source for a YouTube view page and you will see a string var embedUrl = 'http:// You can write code to search for that in the html text. But embedUrl is not a standard javascript item; it is part of the YouTube design. You will be relying on that, and if YouTube changes how they provide such a string, you will be out of luck; at best you will have to rewrite part of your code. In other words, screen scraping relies on the site not doing a major reworking and on you doing a little reverse engineering of the page source. So how to get the html into your program? In python the answer to that is urllib. http://docs.python.org/lib/module-urllib.html mt -- http://mail.python.org/mailman/listinfo/python-list
Re: Calling external program from within python
These answers are too elaborate and abstract for the question. Emmanouil, Here is a program "myprog" which takes input and writes output to a file. It happens to be python but it could be anything. # #!/usr/bin/env python a = int(raw_input("enter thing 1 ")) b = int(raw_input("enter thing 2 ")) c = raw_input("enter output file name ") f = open(c,"w") f.write("answer is %s\n" % str(a + b)) f.close() # Here is python code which runs that program # import os f = os.popen("/path/to/myprog","w") f.write("3\n4\noutputname\n") #can also do three separate writes if that is more convenient f.close() # For some reason os.popen is deprecated in favor of the more verbose subprocess.Popen, but this will work for a while. Here is an even simpler approach that will take you a long way. This should be very easy to understand. # import os params = open("temp","w") params.write("3\n") params.write("4\n") params.write("outputname2\n") params.close() os.system("/path/to/myprog < temp") # If you want python to pick up the stdout of your program as well look into popen2. Try basing your solution on those and if you have any problems let us know what they are. In most cases such as you describe these will work. mt -- http://mail.python.org/mailman/listinfo/python-list
Re: Not entirely serious: recursive lambda?
Thanks all! What a remarkable set of answers, intelligent, thought provoking and informative without exception. Of course, now I can't use Paul's version; it hardly counts as a japh if someone else wrote it! It is probably the closest to my original vision, alas. Miles' second suggestion was the one I was fumbling toward; I will study it. No spoilers please. best mt -- http://mail.python.org/mailman/listinfo/python-list
Not entirely serious: recursive lambda?
I came across the "japh" concept today and decided to do one of my own, obviously, interpreting the 'p' somewhat loosely, http://en.wikipedia.org/wiki/JAPH but I'm not entirely satisfied with it: # japh, for certain values of 'p' f=lambda(r,N):N and f((" acdefijlmnopqrstuv"[N%19]+r,N/19))or(r,N) print f( ("",reduce(lambda c,m:c*95+''.join(map(chr,range(32,127))).index(m), "!b)'1Mgh0z+fYQ]g::i^<&y~g)cnE-d=K&{GMNQ1gx+ooY<~L##N'X]P2<@XYXwX3z", 0)))[0] it bothers me that there are two statements. (In case you are wondering what they do, it's all essentially about changing from base 95 to base 19. It's based loosely on this fine, simple recipe by Drew Perttula which I have found to be useful on several occasions: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/111286 ) Anyway, I'd much prefer an even uglier japh like this: # does not work print (lambda(r,N):N and ((" acdefijlmnopqrstuv"[N%19]+r,N/ 19))or(r,N))( ("",reduce(lambda c,m:c*95+''.join(map(chr,range(32,127))).index(m), "!b)'1Mgh0z+fYQ]g::i^<&y~g)cnE-d=K&{GMNQ1gx+ooY<~L##N'X]P2<@XYXwX3z", 0)))[0] but what would be for an unnamed function to call itself? I realize that lambda is something of an orphan and was arguably a bad idea for anything besides obfuscation, but obfuscation is exactly my purpose here. Can a lambda call itself without giving itself a name? Google was not my friend on this one, and I suspect there is no answer. Relax, I am not going to submit a PEP about it. mt -- http://mail.python.org/mailman/listinfo/python-list
Re: Preferred method for "Assignment by value"
http://effbot.org/zone/python-objects.htm still says it best. mt -- http://mail.python.org/mailman/listinfo/python-list
Re: Magic function
On Jan 11, 8:40 pm, Steven D'Aprano <[EMAIL PROTECTED] cybersource.com.au> wrote: > Read the OP's post again. His (her?) users aren't expected to create the > toolkit, merely to use it. To create good toolkits you need both a master > programmer and an expert in the field. It is an advantage if they are the > same person. But to use such a good toolkit, you shouldn't need to be a > master programmer. It appears we are in agreement, then. But that leaves me in a position where I can't understand your complaint. There's no reason I can see for the sort of compromise you ask for. Clean abstractions benefit from their cleanliness. Of course the users will have a lot to learn regardless, but that's the point. A user has to decide whether to take on a new tool. If that learning is about meaningless incantations (the way beginning programmers are currently taught to say "abracadabra public static void main") users will be less impressed with the advantage of the abstractions and be less likely to engage the new methods on offer. If the learning exposes new potential, that makes your tool more attractive. What's more, the next higher layer of abstraction will be easier to compose if the composer of that abstraction doesn't have to make the sort of compromise you suggest. Abstractions that stay out of the way until you need to expand on them is a big part of what Python is all about. It's not clear that this is the sort of application where cutting corners makes sense, so I don't see how your advice is justified. mt -- http://mail.python.org/mailman/listinfo/python-list
Re: Magic function
On Jan 11, 6:15 pm, Steven D'Aprano <[EMAIL PROTECTED] cybersource.com.au> wrote: > Your users are *scientists*, and you don't trust their intellectual > ability to learn a programming language as simple as Python? > > Instead of spending time and effort writing, debugging and maintaining > such a fragile approach, why not invest in a couple of introductory books > on Python programming and require your scientists to go through the first > few chapters? Or write out a one-page "cheat sheet" showing them simple > examples. Or, and probably most effectively, make sure all your classes > have doc strings with lots of examples, and teach them how to use help(). > > Some people problems are best dealt with by a technical solution, and > some are not. > > -- > Steven I am currently talking very similar trash on my blog, See http://initforthegold.blogspot.com/2008/01/staying-geeky.html and http://initforthegold.blogspot.com/2007/12/why-is-climate-modeling-stuck.html You seem to think that learning the simple language is equivalent to grasping the expressive power that the language provides. Yes, users are scientists. Therefore they do not have the time or interest to gain the depth of skill to identify the right abstractions to do their work. There are many abstractions that could be useful in science that are currently provided with awkward libraries or messy one-off codes. The idea that a scientist should be expected to be able to write correct and useful Python is reasonable. I and the OP are relying on it. The idea that a scientist should be expected to identify and build clever and elegant abstractions is not. If you think every scientist can be a really good programmer you underestimate at least one of what good scientists do or what good programmers do or what existing high performance scientific codes are called upon to do. mt -- http://mail.python.org/mailman/listinfo/python-list
Re: Research-oriented Python mailing list?
Perhaps what you are looking for is here: http://www.scipy.org/Mailing_Lists mt -- http://mail.python.org/mailman/listinfo/python-list
Re: yet another indentation proposal
On Aug 19, 11:51 pm, James Stroud <[EMAIL PROTECTED]> wrote: > What's wrong with just saying the current indent level? I'd much rather > hear "indent 4" than "tab tab tab tab". Alternatively, you might also consider writing a simple pre and postprocessor so that you could read and write python the way you would prefer In that you could cope with the existing code base and the existing compiler could cope with code you write. mt -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie question
http://diveintopython.org/ mt -- http://mail.python.org/mailman/listinfo/python-list
Re: the one python book
On Aug 4, 9:32 am, Neil Cerutti <[EMAIL PROTECTED]> wrot > With Python, you won't find anything like that. Python is too > huge. That's silly. Python is small in the sense that C is small. The Python standard library is probably much bigger than the C standard library, but Kernghan and Richie don't cover it. K&R is a unique book. I have never seen anything comparable for any language. The closest Python equivalent is the official docs: http://docs.python.org/ I think the core Python bookshelf is: Learning Python (Lutxz & Ascher) and/or Dive Into Python (Pilgrim) for tutorial Python in a Nutshell (Martelli) AND Python Essential Reference (Beazley) for reference The latter two books are not perfect (both indexes are infuriating) but I usually find that I can find what I am looking for in one or the other. Like most people I eventually plan to read Moby Dick, War and Peace, and Lutz's Programming Python. Maybe when I retire. mt -- http://mail.python.org/mailman/listinfo/python-list
Re: converting 64-bit fixed-point to float
It appears to be correct for positive numbers. if conval >= 2**16: conval -= 2**32 would appear to patch things up. It's not very pretty, though. You could at least start with input1 = [c_ushort(item) for item in input] instead of your first 9 lines. mt -- http://mail.python.org/mailman/listinfo/python-list
Re: CP4E revival
On May 24, 5:03 am, Richard Jones <[EMAIL PROTECTED]> wrote: > Michael Tobis wrote: > >http://tinyurl.com/yr62r3 > > > seems to short-circuit some pointless hoop-jumping to get you to the > > article. > > Hoop-jumping implemented to prevent just this kind of direct linking (and > thus not saving of the PDF to local disk to view, and thus increasing the > load on the server). > > Thanks for abusing the free service being provided to the Python Papers > journal. > > Richard OK, oops, I'll take the tinyurl link down anywhere I can; I really didn't (and still don't) quite get the server side issue but so be it. (I thought it was a measure to ensure a license to view, which is not in fact required in this case.) On the other hand, given the modest reaction to the article (pro or con) I am not getting the sense that it has generated a lot of traffic. I'd prefer flames about the content, though. mt -- http://mail.python.org/mailman/listinfo/python-list
CP4E revival
Is education Python's killer app? I think it could be. I used the occasion of the Python Papers to motivate my efforts, and you can see what I came up with here on pages 8-15. The part that makes me especially queasy is the CP4E section on pages 10-11. I wish I had more to say there. It's fairly clear to those of us who weren't there that there were some problems, but it's not especially clear what they were or what we should learn from them. I'd very much appreciate input from those who were actually there! Anyway http://tinyurl.com/yr62r3 seems to short-circuit some pointless hoop-jumping to get you to the article. If that doesn't work, try going to http://pyjournal.cgpublisher.com/ and looking for the spring 2007 edition. I suggest a concerted effort by the community toward leveraging the OLPC/Sugar momentum to revive the idea of Python as tool for teaching some programming as a useful part of universal education. mt -- http://mail.python.org/mailman/listinfo/python-list
Re: NOOOOB
Different strokes for different folks. You might get better advice about where to start if you tell us a bit about yourself. Do you have any other programming experience? Do you have specific goals in mind as a programmer? mt -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Newbie Suggestions
I think http://www.diveintopython.org/ would be very suitable for you. mt -- http://mail.python.org/mailman/listinfo/python-list
Re: How to cleanly pause/stop a long running function?
> Doing a Ctrl+C > interrupt would be a not-so-clean-way of performing such a thing, and > it would quit the application altogether. I'd rather have the function > return a status object of what it has accomplished thus far. Just in case you are unaware that you can explicitly handle ^C in your python code, look up the KeyboardInterrupt exception. mt -- http://mail.python.org/mailman/listinfo/python-list
Re: interesting exercise
On May 9, 2:41 pm, [EMAIL PROTECTED] wrote: > On May 9, 1:13 am, Charles Sanders <[EMAIL PROTECTED]> > wrote: > > or even this monstrosity ... > > > def permute2( s, n ): > >return [ ''.join([ s[int(i/len(s)**j)%len(s)] > > for j in range(n-1,-1,-1)]) > >for i in range(len(s)**n) ] > > > print "permute2('abc',2) =", permute2('abc',2) > > print "len(permute2('13579',3)) =", len(permute2('13579',3)) > > > permute2('abc',2) = ['aa', 'ab', 'ac', 'ba', 'bb', 'bc', > > 'ca', 'cb', 'cc'] > > len(permute2('13579',3)) = 125 > > > Charles > > Could you explain, this one, actually? Don't forget StopIteration. Heh, it's cute. Not sure what the issue is with StopIteration. He is modeling the problem as casting an integer to base N. It's terse, but it does way too much arithmetic and isn't very readable. The following uses the same idea more readably and (I expect, untested) more efficiently, if less tersely. It actually is not too bad for real code, though I much prefer your recursive list comprehension and will use that. def getdigits(number,base,length,alphabet): residual = number result = "" for column in range(length): residual,digit = divmod(residual,base) result = alphabet[digit] + result return result def permu(alphabet,wordlength): total = len(alphabet)**wordlength return [getdigits(index,len(alphabet),wordlength,alphabet) for index in range(total)] if __name__ == "__main__": print permu("abc",2) print len(permu("13579",3)) mt -- http://mail.python.org/mailman/listinfo/python-list
Re: interesting exercise
Thanks castironpi and alex, for this: def p(a,b): if not b: return [''] return [i+j for i in a for j in p(a,b-1)] That is a thing of beauty! As usual you guys didn't disappoint. (Validity check of alphabet removed; you didn't check for duplicate characters.) Here is the bloated mess I came up with. I did see that it had to be recursive, and was proud of myself for getting it pretty much on the first try, but the thing still reeks of my sorry old fortran-addled mentality. def validAlphabet(alphabet): if not isinstance(alphabet,str): return False if len(alphabet) > 256: return False for index in range(len(alphabet)-1): if not alphabet[index] < alphabet[index+1]: return False return True def nextword(word,alphabet): if len(word) == 1: index = alphabet.find(word) if index < 0: raise ValueError("bad token found %s" % word) if index == len(alphabet) -1: return None else: return alphabet[index+1] else: a = nextword(word[1:],alphabet) if a: return word[0] + a else: b = nextword(word[0],alphabet) if b: return b + (len(word) - 1) * alphabet[0] else: return None def allwords(length,alphabet="01"): if not validAlphabet(alphabet): raise ValueError("bad token list %s" % alphabet) word = length * alphabet[0] result = [word] while word < length * alphabet[-1]: word = nextword(word,alphabet)) result.append(word) return result ## if __name__ == "__main__": for item in allwords(5,"abc"): print item -- http://mail.python.org/mailman/listinfo/python-list
interesting exercise
I want a list of all ordered permutations of a given length of a set of tokens. Each token is a single character, and for convenience, they are passed as a string in ascending ASCII order. For example permute("abc",2) should return ["aa","ab","ac","ba","bb","bc","ca","cb","cc"] and permute("13579",3) should return a list of 125 elements ["111","113", ... ,"997","999"] permute("axc",N) or permute("2446",N) should raise ValueError as the alphabet is not strictly sorted. I have a reasonably elegant solution but it's a bit verbose (a couple dozen lines which I'll post later if there is interest). Is there some clever Pythonism I didn't spot? thanks mt -- http://mail.python.org/mailman/listinfo/python-list
Re: New to Python - Easy way to open a text file
I think it's pretty clear that we aren't understanding what you mean by "open a text file and disply its content". I conclude that by "edna" you mean this thing: http://edna.sourceforge.net/ I suspect you are not asking a Python question at all. Did you try opening file:edna-0.6/templates/default.ezt in your browser? This will show you the design of your (unpopulated) template rendered in your browser. Notes: 1) yes you do need three slashes after "file:" for some reason I've never comprehended 2) you will need to replace with your local system path to the edna directory. (In firefox you can, alternatively, browse to the file from File->open; Safari will balk at the ezt extension; I don't know what other browsers will do.) If this is more like what your are after, consider that your question was misleading (and entirely unrelated to Python). The edna miling list is here: http://www.lyra.org/mailman/listinfo/edna hth mt -- http://mail.python.org/mailman/listinfo/python-list
Re: Fortran vs Python - Newbie Question
I feel obligated to fan the flames a bit by pointing to http://www.fortranstatement.com/ a site which advocates discontinuing development of Fortran and does a good job of summarizing the problems with the contemporary development of that language. I am not convinced that a new high performance language (Chapel, Fortress, etc.) is necessary. Rather, I feel that FORTRAN 77 is a mature tool, and that it, in combination with a powerful dynamic language (Python being my choice) is entirely sufficient for any foreseeable scientific computing. Fortran 90 and successors (F9* in the following) provide a baroque and elaborate effort to bolt modern computing methods over a finely honed special purpose tool (F77) that manages large numerical arrays spectacularly well. It is as if you decided to add a web search engine (an elaborate, developing set of requirements) to grep (a finely honed special purpose tool). It makes much more sense to add greplike features to your websearch tool than to try to foist "Grep95" (competing with the Google search engine) on everyone who ever needs to find a misplaced text file. F77 interfaces smoothly and neatly with Python. F9* continues to be the single most difficult case for interoperability with any other contemporary algorithmic language. Fortunately there is hope within the new standard, where an "interoperability" flag will force F2003 to deliver arrays that are exportable. In exchange for this balkiness, F9* offers crude and verbose implementations of encapsulation and inheritance. I am sure Dr Beliavsky and some others are productive with F9*, but I would strongly advocate against it for anyone in a position to make a choice in the matter. Some people are competent with hand-powered drills, but I wouldn't set up a furniture production line with them on that basis. The performance and library advantages of Fortran are all available in F77. Higher level abstractions can easily be wrapped around the low level structures using Python and f2py. Making the combination performance-efficient requires some skill, but making a pure Fortran implementation efficient does no less so. I don't think we should or can abandon the excellent infrastructure provided by the Fortran of a generation ago. However, I am totally unconvinced that there is a point to a backward compatible extension to F77 that tries to support OOP and other abstractions unimaginable in the early days of Fortran. F77 and its numerical libraries are mature and complete. I think we should treat it as a remarkable set of packages, and move on. For any purposes I know of not involving an existing F9* legacy, I believe that Python plus F77 is as good as or superior to F9* alone. This includes the total time needed to learn the tools, (I think it is easier to learn Python, F77 and f2py than to learn F9* alone to any comparable skill level.) total time needed to develop the code, whole system performance, testability and maintainability. Once Python gets a first-class array type things will be even smoother as I understand it. mt -- http://mail.python.org/mailman/listinfo/python-list
Re: Turn off line wrap for lists?
_ wrote: > (I did google for this, I promise) > > How do I get python NOT to insert newlines into string representations > of lists when I do something like this: > > strCollector += "%s" % (['a', 'list', 'with', 'lots', 'of', 'elements'] > * 100) It shouldn't and doesn't insert newlines. ## >>> strCollector = "%s" % (['a', 'list', 'with', 'lots', 'of', 'elements'] * >>> 100) >>> strCollector.split("\n")[0] == strCollector True ## mt -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Programming Books?
I am not happy with any of the Python-as-a-First-Language books out there. My vague inclination to write one has not yet formed into a firm intention, but it's close. Of the books that are out there, Learning Python and Dive Into Python are best for the hobbyist as opposed to classroom setting, but my sense is that both of them go a bit too fast for the typical beginner with no formal training. In the classroom setting, Zelle's book or Hetland's are good, but they are a bit dry for the hobbyist. In my opinion, if you are just looking for a pleasant exploration of whether you enjoy programming, one option to consider is Python Programming for the Absolute Beginner by Michael Dawson, which focuses on developing games. mt -- http://mail.python.org/mailman/listinfo/python-list
Re: Quoting relevant material for response (was: Re: python vs perl lines of code)
OT, sort of, but... [EMAIL PROTECTED] wrote: >If that > quoting mechanism is available on the web interface and I haven't found > it - I'd love to know how to use it. Click "show options" and THEN hit "reply". It's a bit counterintuitive, but the entire message to which you reply is then shown. It is best to (as I've just done) erase the parts you aren't replying to. If you are replying to multiple selected parts of the message it is good form to indicate the gaps with ellipses ("..."). It's worth noting that this group predates Google by severalyears, that usenet predates it by well over a decade, and that Google is only one of several alternative ways of participating (though it is my own preference) and that its conventions have emerged for good reasons. see http://en.wikipedia.org/wiki/Usenet and http://en.wikipedia.org/Google_Groups mt -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
> According to your silly rule the shortest book on a subject would be the > best. Now why is that false? No, according to the rule, the shorter of two books **containing the same information** would be best. I don't think I'm a zealot. The original quote said "all else equal". Certainly legible code is better than, hence not equal to, illegible code. I would say that having played Python golf once, the complexity of the competitive keystroke-minimizing code is much higher than the complexity of the equivalent sane, readable, maintainable code. (Actually, it also turns out to involve a good deal of coding that isn't in the final source, but let's not go there.) The point is I did NOT say he programs best who *types* least, and I don't believe that. In fact, that's what makes the comparison interesting. I had always thought that Pythonistas type more than Perlists, though I prefer Python anyway. The presumption was based on the fact that Perl (as language and culture) takes delight in saving keystrokes at the expense of clarity ($_ and all that) while Python makes no special effort in that direction. If real world Python code is substantially more terse *despite* this cultural difference, it is a fact worthy of some note. Let me add my voice to those clamoring for Edward to release his code while I'm here, though. mt -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
John Bokma wrote: > "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > > Ok I'm going to end with a flamebait - but I would posit, ALL OTHER > > THINGS BEING EQUAL - that a smaller number of characters and lines in > > code is more maintainable than larger number of characters and lines in > > the code. > And I think that's why a lot of people posted very negative, in the hope > that people would not be tempted to make the above very dumb statement. Since it's too late to avoid such temptation, could you explain why you are willing to go so far as to call that statement "very dumb"? I, for one, consider it rather wise. When I am teaching programming, or advocating Python, I generally try to include the following advice, attributed to A. de St.-Exupery: "La perfection est atteinte non quand il ne reste rien à ajouter, mais quand il ne reste rien à enlever." The relevant corrolary is, "he programs best who programs least". I would have thought this was conventional wisdom among all dynamic language communities. Isn't that the whole point? By all means go back to C++ if you like to have three lines for each idea instead of the other way around. However, since I habitually make such a fuss about this, I'd hate to be wrong. Please do explain why you think this idea that terseness is a virtue is foolish. mt -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
Sorry, data about reports about X *is* data about X unless you believe the reports are uninfluenced by X. Like any proxy measure, it introduces noise and uncertainty, but it is still data. I can't imagine a motivation for Edward to make this up, so I accept his anecdotes as data. While it is possible to imagine developing a lab experiment to compare the terseness of Python and Perl, it is unlikely that funding is or should be available for the effort. This doesn't make it an uninteresting question. Is the widely held belief that real-world Perl is terser than real-world Python true? So far we have only the two reports from Edward. Still anyone programming in the dynamic languages world would acknowledge that they are quite striking and provocative. I don't see the purpose of this controversy, but it reminds me of some rather cynical attacks on climate science, and I don't like it at all. We don't always have the luxury of vast data of impeccable quality, but we still need to make judgements about the world. mt -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
"The plural of anecdote is not data." It's a pithy quote, but it isn't QOTW in my book, simply because it isn't true in general. Talk to some paleoclimatologists. There is no way to get uniform measures of ancient climate. What should we do then? Should we ignore the information we have? Are the fortuitously preserved fossils of the very deep past to be ignored just because we can't get an unbiased sample? In fact, the more difficult it is to get systematic data, the more valuable the anecdote. There is a number that represents the character ratio for equivalent skill applied to equivalent tasks across all domains to which both languages are applied. A single programmer's results on this matter do in fact constitute a sample. A single sample is not a very good estimator, but it is not devoid of skill or information either. In the present case Edward gave us some advice that he thought he was making a fair comparison, one which would appear counterintuitive to anyone who has worked in both languages. Perlists tend to giggle and cackle every time they save a keystroke; Pythonistas do not have this personality quirk. If Python is nevertheless terser it is a strong argument in Python's favor vis-a-vis Perl. Edward also asked if others had similar experiences. If others did, the assemblage of their opinions would in fact consttitute data. I have no idea why people are giving him such grief over this request. My only data point, er, anecdotal evidence, is this. To take things to an unrealistic extreme, consider the puzzle at http://pycontest.net (Python Golf). When I first thought about this, I assumed that Perl would defeat Python in the character count, but as I worked at the puzzle I came to the (to me) counterintuitive realization that it probably would not. I'd be interested in seeing the results of an inter-language golf contest. Of course, such games don't tell us much about real code, but I'm inclined to agree with Edward's impression that Python is, in practice, terse compared to Perl, and I, too, would like to hear about other examples, and because I think the plural of "anecdote" is, in fact, "data". mt -- http://mail.python.org/mailman/listinfo/python-list
Re: a flattening operator?
I think by "regular expressions" you mean "expressions". "regular expressions" are what you get from "import re" . mt -- http://mail.python.org/mailman/listinfo/python-list
Re: proposed Python logo
A more Monty sort of Python logo would be fine with me. A flying sheep perhaps? An exploding penguin? A giant hedgehog? A dog license with the word "dog" crossed out and "cat" written in crayon? A great big book on how to put your budgie down? This http://www.informatik.uni-trier.de/~roth/bilder/mpfc/GUMBY3.JPG chap? I'm not sure that conveys the intended gravitas to the corporate community, though. mt -- http://mail.python.org/mailman/listinfo/python-list
Re: Pythonesque interface.
www.pygame.org Yes but he obviously wants this to be delivered to the browser. (Also the site is broken today... ) This comes up a lot, but I don't think there's an answer to it as yet. mt -- http://mail.python.org/mailman/listinfo/python-list
Re: proposed Python logo
> Not that I'm disagreeing, but how to you rate "resonance with the product"? Hmm, I'm not a marketing professional, but this is would I would do with my focus groups: Ask people familar with the product to name what they like about the image, and what they like about the product, and look for analogies between them. Ask them what they dislike about the image and the product, and minimize overlap. (The main thing I dislike about Python is that the documentation is too sketchy. It's very unclear what the official logo represents. So another strike against it; it reminds me of the confusion I often face on making use of an unfamiliar module.) Ask people who are unfamiliar with the product who are potential users what they have heard good and bad about the product, and its strengths and weaknesses compared to its competition. Compare with their impressions of the logo. I am my own focus group, but people who are following this thread can simply show the existing logo to people and ask for their impressions. Try showing it (without the text) to non-Pythonista programmers, who probably haven't seen python.org lately, without telling them what it represents. See what their associations are. I've already explained my negative associations with the official logo, and some of the positive ones of my prototype alternative. See the post that started this thread and the thread it links to. The best snake-and-language logos I have seen are the Twisted-Matrix one and the PyCon one. But I think my idea can be developed too. I think the colon as snake-eyes thing is a big win. We would think affectionately of the snake every time we type the unnecessary colon. -- http://mail.python.org/mailman/listinfo/python-list
Re: proposed Python logo
> Sorry dude, but it looks like a hairdryer! I'm afraid you have a point :-/ . > I think that the current logo is fine. Much more professional than the old > image. Yes, it is a MUCH more professional rendering than the old image, and it leaves a MUCH better first impression of the homepage. That said, and conceding that the first impression is positive, I don't see how it represents Python. More to the point, the longer I look at it the less I like it, and I would NOT wear it on a T-shirt. > The + formation is positive enough, and it has a yin-yang > feel to it which to me conjures up the image of balance, not > divisiveness. Both the cross and the yin-yang have religious associations, which will be positive for some and negative for others but will certainly be unrepresentative of what Python is. This would be a great logo for Taoist Christians, if such a group exists. How is Python about "balance"? It is about abstraction, composition, the whole greater than the parts, yes, but there's nothing there that really draws on duality. So the whole two-ness of the thing is one of the parts that disturbs me. mt -- http://mail.python.org/mailman/listinfo/python-list
Re: proposed Python logo
Don't you think the Python Boys ought to have something to say about it? Eric Idle is going to be at my favorite Borders bookstore in half an hour. Should I go ask him? (I'm not going to do that; it's just an odd coincidence from my point of view.) I think there are trademark issues similar to the Apple vs Apple ones. Perhaps we would have to promise them not to have a sense of humor. mt -- http://mail.python.org/mailman/listinfo/python-list
Re: what has python added to programming languages? (lets be esoteric, shall we ; )
Although somewhat more elegant, Python slices follow Matlab's slice notation. In simpler cases they are identical. mt -- http://mail.python.org/mailman/listinfo/python-list
Re: proposed Python logo
> Too rigid-looking somehow. Hey, I'm an amateur... There are lots of variations on the concept I can think of. I want someone with a lot of design talent *and a little familiarity with the language* to take enough interest to have a go at it. At least (unlike the tadpoles) it has some resonance with the product it's trying to represent. mt -- http://mail.python.org/mailman/listinfo/python-list
Re: Looking for a programming resource for newbees
You may be interested in Programming Patterns in Python: http://www.amazon.com/gp/product/0130409561/103-9277940-9267015?v=glance&n=283155 It's out of print but Amazon has some; not everyone likes it but I think it tries to do what you are asking for. mt -- http://mail.python.org/mailman/listinfo/python-list
proposed Python logo
"Is this the right room for an argument?" http://geosci.uchicago.edu/~tobis/snake.png ok, so my execution is pretty crude, but you can at least see my idea. I trust you to imagine it professionally executed in cheerful colors. Advantages of proposed logo over existing logo -- represents an actual python involved in python-like behavior, rather than two tadpoles has a sense of dynamism and forward motion, as opposed to backwardness and upside-downiness the eyes form a colon, thus remeniscent of python code, and the coil is indicative of the "more than meets the eye" that a python object so remarkably delivers also, pythons coil around their eggs! succeeds in making snake into a letter "P" without making it face backwards, and yet resists the unfortunate temptation to use a forked tongue to make a "y" numerous variations and animations immediately present themsleves no obvious references to religious icons will sell T shirts and lapel pins; a swag clock is an obvious possibility (did I mention ( http://tinyurl.com/rkq3s ) that I don't like the current logo?) Much as it would be an ego-boost for me to have some version of this idea used for the language, I'm almost as happy with repurposing the most excellent PyCon logo if that is OK with everyone involved. But imo we can't fully promote the power of Python with tadpoles. mt -- http://mail.python.org/mailman/listinfo/python-list
Re: Calling Python from Matlab
I'm afraid I can't be very helpful to you, but you could be most helpful to some of us. Can you elaborate on what specifically you found difficult? In some circles Python is regarded as a direct competitor to Matlab. Your preference for Python for "other things than standard mathematical work" in a scientific or engineering context could be most useful if you have some real-world examples. Also, can you elaborate on what (if anything) it is about Matlab that you feel you can't replicate in Python? Are you aware of matplotlib and numpy? thanks mt -- http://mail.python.org/mailman/listinfo/python-list
iPython and doctest
It appears that doctest does not work straightforwardly within iPython. I would like to be able to use doctest within a file conditionally, so that I can develop it within ipython and test it otherwise. It would seem that this would work: Python 2.4.1 (#2, Mar 31 2005, 00:05:10) [GCC 3.3 20030304 (Apple Computer, Inc. build 1666)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import testme >>> testme._test() >>> but it doesn't (the test above fails, but reports nothing) I am finding the documentation for doctest ironically impenetrable and **would** be interested in adding some examples and explanatory text to it, but I need to understand what is going on rather better than I do. Meanwhile I am settling for this: # testme.py def foo(): """ Should return 42 >>> foo() 42 """ return 43 def _test(): import doctest doctest.testmod() if __name__ == "__main__": try: __IP # check if we are in iPython except: _test() print "ok" Then In [4]:!python testme.py works (reports the error) just fine! So I don't even have to bail out of iPython to run the tests. mt -- http://mail.python.org/mailman/listinfo/python-list
iPython and doctest
It appears that doctest does not work straightforwardly within iPython. I would like to be able to use doctest within a file conditionally, so that I can develop it within ipython and test it otherwise. It would seem that this would work: Python 2.4.1 (#2, Mar 31 2005, 00:05:10) [GCC 3.3 20030304 (Apple Computer, Inc. build 1666)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import testme >>> testme._test() >>> but it doesn't (the test above fails, but reports nothing) I am finding the documentation for doctest ironically impenetrable and **would** be interested in adding some examples and explanatory text to it, but I need to understand what is going on rather better than I do. Meanwhile I am settling for this: # testme.py def foo(): """ Should return 42 >>> foo() 42 """ return 43 def _test(): import doctest doctest.testmod() if __name__ == "__main__": try: __IP # check if we are in iPython except: _test() print "ok" Then In [4]:!python testme.py works (reports the error) just fine! So I don't even have to bail out of iPython to run the tests. mt -- http://mail.python.org/mailman/listinfo/python-list
Re: More pythonic circle?
Proving yet again that it's possible to write Fortran in any language. You aren't getting any benefit from numpy or python here. Are you aiming for speed or legibility? Also, with this code, you are using radius for the dimensions of the enclosing box, as well as the radius of the circle, so it's guaranteed to not to actually produce a whole circle. Recall what python does with negative indices! I'll bet this does the trick for you and runs faster than what you've got def circle(rad = 5,max_x = 20, max_y = 20,cx = 10, cy= 10, value=255): radsq = rad * rad return numpy.array([[((x - cx) ** 2 + (y - cy) ** 2 < radsq) and value or 0 for x in range(max_x)] for y in range(max_y)],'u') I think the pure numpy solution should be something like (untested) def circle(rad = 5,max_x = 20, max_y = 20,cx = 10, cy= 10, value=255): def sqdist(x,y): return (x - cx) * (x - cx) + (y - cy) * (y - cy) distarray = numpy.fromfunction(sqdist,(max_y,max_x)) return numpy.asarray(numpy.choose(greater(distarray,rad*rad),(0,value),'u') Neither approach will get you the eightfold speedup that the messy code was aimed at, but in practice they will spend less time at the interpreter level and will likely run faster. mt -- http://mail.python.org/mailman/listinfo/python-list
Re: programming puzzles?
Yeah, this was *much* easier than I expected. My candidate was in second place according to /usr/share/dict/words which has ixodid but not dioxid; I'm really not confident that dioxid is a word. I recall that I had also found the third place word now that I look at it. What I had to do was print out all combinations of letters that could make between 999,000 and 1,001,000 and then eyeball them. The factorization was a trick because I had only 16 bit ints if I recall right; I think hacked it in floats. I am amazed at how fast the Python ran and how easy it was to solve. I found "ixodid" in two reasonable lines of Python or one over-long ugly one, (in addition to what I already posted). It runs in about 15 seconds on a G4 powerbook. All in memory! I once spent three whole days on this. Hundreds of lines of Fortran, pages and pages of fanfold paper. Argh. mt -- http://mail.python.org/mailman/listinfo/python-list
Re: programming puzzles?
Yeah, this was *much* easier than I expected. My candidate was in second place according to /usr/share/dict/words which has ixodid but not dioxid; I'm really not confident that dioxid is a word. I recall that I had also found the third place word now that I look at it. What I had to do was print out all combinations of letters that could make between 999,000 and 1,001,000 and then eyeball them. The factorization was a trick because I had only 16 bit ints if I recall right; I think hacked it in floats. I am amazed at how fast the Python ran and how easy it was to solve. I found "ixodid" in two reasonable lines of Python or one over-long ugly one, (in addition to what I already posted). It runs in about 15 seconds on a G4 powerbook. All in memory! I once spent three whole days on this. Hundreds of lines of Fortran, pages and pages of fanfold paper. Argh. mt -- http://mail.python.org/mailman/listinfo/python-list
Re: programming puzzles?
The first piece of code that I ever voluntarily wrote was intended to solve this puzzle: Assign the number 2 to 'a', 3 to 'b' ... 27 to 'z'. To each word assign the value of the product of its characters. Find the English (or language of your choice) word whose product is closest to a million (or number of your choice). I didn't have a lexicon handy. So I just printed out the letter combinations closest to a million and manually played Jumble with them. This was on a PDP-11 using Fortran, so you should have no problem doing this in Python. The prize was a VCR, which was a big deal in those days, but I didn't have a Green Card yet, so I didn't submit my answer, for (probably unfounded) fear the immigration authorities would give me a hard time for unauthorized income. My answer returned 999856 for its product. Can you do better? You can go further. If you have a unix-like system you already have a lexicon, probably at /usr/share/dict/words . Compare various ways to solve this problem for performance, for arbitrary ciphers, which you can pass in as a dictionary like {'a':2,'b':4,'c':5 etc. To get you started here's the calculation, which may be interesting in itself. I don't have the Fortran, but I'm sure it was MUCH longer than this! # cipher0= {} for i in range(ord('a'),ord('z')+1): cipher0[chr(i)] = i - ord('a') + 2 from operator import mul def numify(word,cipher=cipher0): return reduce(mul,[cipher[c] for c in word]) if __name__ == "__main__": print numify("hello") # prints 146016 mt -- http://mail.python.org/mailman/listinfo/python-list
Re: Seems like I want a pre-processor, but...
Well, Bill Mill and I simultaneously and independently decided to write a preprocessor to strip out the unfortunate "@" decorator syntax. I think we were both aiming at a polemic purpose rather than a practical one, but as time fades it seems less clear what we were simultaneously inspired to achieve. Each of us did a crude pass at it and then on encountering each other's approach realized a truly satisfactory implementation would probably be harder than it was worth... In any case isn't ipython an instance of a useful preprocessor? mt -- http://mail.python.org/mailman/listinfo/python-list
Re: Try Python!
We had some discussion of this in the edu-sig meeting at PyCon. I alleged that I had read that there is no such thing as a Python sandbox. Others claimed that one could simply preprocess and disallow "dangerous" constructs. My allegation was based on an argument from authority; I recalled reading the assertion from one of the c.l.p. regulars that I consider authoritative, though I don't remember which (Frederick, Alex, Aahz perhaps?). This is all in relation to why the rexec module went away, and is certainly relevant to what can be achieved in the sphere of teaching with python in general, and teaching python with python in particular. I refer you in particular to these messages from BDFL: http://mail.python.org/pipermail/python-dev/2002-December/031246.html http://mail.python.org/pipermail/python-dev/2002-December/031251.html So what is the scoop? Why does Guido say there is no such thing as a secure Python, and (as is generally reasonable) presuming he is correct on the matter, how can these sites work safely? thanks mt -- http://mail.python.org/mailman/listinfo/python-list
Re: Remove integer from float number
I think you ought to make your own class and define some of the special methods. mt -- http://mail.python.org/mailman/listinfo/python-list
Re: a problem to solve
Yeah, I misread the question, but the gist of my query remains. > The odds are 100% if there is at least one solution. Let's not get too philosophical. My question was whether there was an a priori reason for believing that there is a solution. > You want permutations with replacement, so there are 8**4 = 4096 Agreed. My mistake. >> These will turn on 15 lights in each set of 20, of which the number of >> possibilities is C(15,20)**4 = 57779667567968256L > No, there are only 8 possible patterns on each panel. > Not every possible 15 lamp pattern is realized Right, but that is exactly my point. This is the number of possible selections of 15 out of 20 made four times. Any attempt will be a member of that space. Then the probability of hitting a solution at random is the ratio of solutions to that space. So I think my chance of success on a sinlge selection, assuming random design of the switch banks, is correct: 1.9e-05 My error gave me the wrong multiplier. It's 4096 rather than 1820. So now I'm goinq with a 7.79% chance of randomly setting up the problem to yield a solution. Still seems somwhat unlikely that there would be a solution unless the problem were set up in advance. (homework? a puzzle book?), I am just wondering where the puzzle came from. Was there more than one solution? mt -- http://mail.python.org/mailman/listinfo/python-list
Re: a problem to solve
First do a little estimation. We know we have to find four out of 16 switches, so the number of possibilities to search is only C(4,16) = 1820, so an exhaustive search will work. These will turn on 15 lights in each set of 20, of which the number of possibilities is C(15,20)**4 = 57779667567968256L The number of these that are successes is the number of ways to pick 3 out of 4 twenty times: 4**20 = 1099511627776L For each pick, your chance of success is then float(1099511627776L)/57779667567968256L = 1.9029386530869287e-05 You get 1820 distinct tries. Assuming no overlap (which slightly overestimates your chances if it's a false assumption), the odds that there is a solution are 1820 * 1.9029386530869287e-05 = 0.034633483486182101 or about 3.5%. Not great. There seem to be some symmetries I haven't used, which may conceivably help your cause. I just wonder if you have some basis for beleiving that there is a solution. mt -- http://mail.python.org/mailman/listinfo/python-list
Re: import random module
Wow. Six simultaneous responses! Python rocks! Anyway, I actually tried it, and persisted through the secondary confusion about the lurking .pyc file, so even though I'm in sixth place I get points for completeness... mt -- http://mail.python.org/mailman/listinfo/python-list
Re: import random module
1) remove the file random.pyc in your working directory 2) rename the file random.py to something else and run it. The import mechanism is looking for random.pyc or random.py, but you have already named your file that! Your current directory is above your library directory in python's search path, so it finds that before it finds the library module. mt -- http://mail.python.org/mailman/listinfo/python-list
Re: - Python Newcomer Starting with Coding
Are you sure this is what you want to do? It seems an odd objective for a preliminary effort. Forgive me if I am reading this wrong, but I am concerned that you think you need to do all this work to use the package. If so, you are asking the wrong questions. Please look into the PYTHONPATH environment variable and the sys.path list within Python. mt -- http://mail.python.org/mailman/listinfo/python-list
Re: New-style Python icons
OK, but Python IS clever, so its logo ought to be too. Since you are acknowledging they are tadpoles, I guess you've heard my gripes... mt -- http://mail.python.org/mailman/listinfo/python-list
Re: New-style Python icons
I think this is great work but imagine what you could do with a real logo! Besides the pleasant colors what do you like about it? I have in mind something with a coil motif but I can't execute it worth a damn. mt -- http://mail.python.org/mailman/listinfo/python-list
Re: can't rebind magic methods
Still a bit confused actually. Any explanation of the following? mt def getf(method,name): def f(self, *a, **k): return method(self.val, *a, **k) f.func_name = name return f class myint(object): def __init__(self, val): self.val = int(val) for spec in 'str repr hash hex oct pow add'.split(): name = '__%s__' % spec method = getattr(int, name) # comment this out to get the non-working case setattr(myint,name,getf(method,name)) # works # uncomment three lines to get the non-working case # raises TypeError: "expected 1 arguments, got 0" at method invocation # why isn't this equivalent to the setattr above? # def f(self, *a, **k): return method(self.val, *a, **k) # f.func_name = name # setattr(myint,name,f) # doesn't work if __name__ == "__main__": a = myint(42) print a print oct(a) -- http://mail.python.org/mailman/listinfo/python-list
Re: can't rebind magic methods
Thanks! Only a minor correction: the last line should be _setdelegate(myint, int,'__%s__' % spec) The business with f.func_name struck me as unnecessary, but I was quite wrong. This was an interesting exercise for me. Thanks. Michael -- http://mail.python.org/mailman/listinfo/python-list
can't rebind magic methods
I'd appreciate an explanation of why this doesn't work and any workarounds. It's not a showstopper, but I'd like to pseudo-inherit a bunch of magic methods from an attribute, and would prefer to abstract the definitions into a loop rather than write them all out. thanks mt ### import new class myint(object): def __init__(self,val): self.val = int(val) def mystr(self): return self.val.__str__() self.__str__ = new.instancemethod(mystr,self,mint) #doesn't work self.str = new.instancemethod(mystr,self,mint) """ # this works def __str__(self): return self.val.__str__() """ if __name__ == "__main__": a = myint(3) b = a a.val = 42 print b # want "42" print b.str() # works -- http://mail.python.org/mailman/listinfo/python-list
Re: Printable string for 'self'
> What were you planning to do with this object exactly that didn't involve > binding it to any other names during its lifetime? Nothing so silly as that. The idea is not to prevent other references from binding to the object, but to allow the object to ensure that a certain symbol always points to it. I no longer suspect that this is a good enough idea to redesign the language, but it seems to come up regularly. I will elaborate on my use case later, as I am still looking for a satisfactory workaround. I think that someone working on a logo-like platform wanted to be able to assign permanent names to his turtles, which is an easier case to understand. In both cases there is the idea to construct a platform for programmers of intermediate skill, to expose the python environment as well as powerful objects that they don't need to modify, but need to be able to access by name. It would be good to be able to guarantee that the name would be a valid reference to the object in question. mt -- http://mail.python.org/mailman/listinfo/python-list
Re: Printable string for 'self'
This behavior seems to be commonly wanted by people discovering Python, and it is the rare case of something one can imagine that is really a stretch to achieve in Python. Because more or less than one name may refer to an object, in general an object can't know its name. You can get part of the way there with fred = C("fred") and assign the string to self.name in the constructor. But you must strictly enforce a convention in your code that the reference fred is not reassigned to another referent for this to be of much use. I got in some trouble in these parts a few months back for advocating some sort of immutable reference, like fred -> C("fred") where any reassignment of the refernce during the lifetime of the referent would raise an exception. This seems to be seen as wrongheaded by greater pythonistas than myself. I don't fully understand *why* this is a bad idea, but my intuitive idea that it would be very valuable has gone away. mt -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie Class/Counter question
Paul, thanks for the enlightening intro to pyparsing! We don't really know what the application is (I suspect it's homework), but whether it's homework or a real-world one-off this all seems like overkill to me. There's a time for elegance and a time for quick and dirty. Assuming line oriented input as shown, I can do it in 9 simple lines (or 7, if there is no "level3" or higher case) with no imports, no regular expressions, and no user defined classes. However, I hate to submit someone's homework. Anyway, Provo seems confused, and should focus more on technique, I think. Remember that "simple is better than complex" and "readability counts". Try to find a way to take smaller steps toward your goal. mt -- http://mail.python.org/mailman/listinfo/python-list
Re: New python.org site
I think a logo contest is a good idea, and I am already working on my entry. I could also imagine a stylesheet contest. The issue is who does the judging and what are the criteria. Steve, what you say is true. Possibly people who are experienced in making a six page site for their aunt's catering business may not understand how much the site implementation is constrained by the huge amount of existing content, nor what an excellent effort the rework is, nor what a good product was achieved. I am trying to make the point that the silly logo cancels out a good bit of the benefit of the site in appealing to the uncommitted. A brand that people love is usually a part of a product that people love, and there needs to be some correspondence. A pink bunny is a fine brand for flashlight batteries, but not a good one for motorcycles. For a language which cannot avoid associations with a ten meter snake, a pair of tadpoles just says "we don't really mean it, never mind". The twistedmatrix logo and the pycon logo take advantage of the associations. The tadpoles try to avoid them, and to make matters worse pick up a vague and oddly disturbing religious affiliation in the process. If we are serious about promoting the language, they really have got to go. The contest can specify the dimensions of the logo image to match those of the one currently on the site. The amount of work required to replace the existing logo with a more appropriate one would amount to just changing one reference in a stylesheet. Michael -- http://mail.python.org/mailman/listinfo/python-list
Re: Cheese Shop -> BSOL?
I like cheeseshop just fine, but have been a Monty Python fan since they appeared on the CBC in, I think, 1969. I'm one of those people who is always surprised when a MP bon mot is greeted with confusion and the suspicion that I have finally lost my mind altogether. So... If we are moving to the snake motif (which probably would be better marketing): "Pythons lay eggs which they arrange in a pile. They coil around the pile until all eggs have hatched. Since pythons cannot regulate their internal body temperature, they cannot incubate their eggs per se; instead, they raise the temperature of their eggs by small movements of their body-essentially, they "shiver". This is one of only a few documented cases of parental behaviour in snakes." --Wikipedia article "python" Pythons build no nests. Their eggs are found in coils. coil.python.org ? Tadpoles ( http://python.org/images/python-logo.gif ) are immature frogs. If we keep the logo, we can change the name of the language to "frog". Then the eggs would be found in lilypad.frog.org . I personally do not like this choice but it would have the virtue of consistency. (Did I mention that I don't like the logo?) mt -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Evangelism
The name isn't changing, so it's a "make lemonade" situation. What's the best use we can make of the name; how do we make it stick in people's minds positively? How do we make a positive image out of it? Shy tadpoles, by the way, ( http://python.org/images/python-logo.gif ) isn't it. mt -- http://mail.python.org/mailman/listinfo/python-list
Re: Python advocacy in scientific computation
I think I agree with Steve here. I suspect you should either have sufficiently trained your users in Python, or have limited them to one-line statements which you could then strip of leading whitespace before passing them to Python, or even offered the alternative of one or the other. This would not have been much extra work. As for shell scripts generating Python code, I am not sure what you were trying to do, but if you're going that far why not just replace the shell script with a python script altogether? os.system() is your friend. I also agree with Steve that I can't see what this has to do with makefiles. (But then I think "make" is a thoroughly bad idea in the first place, and think os.system() is my friend.) mt -- http://mail.python.org/mailman/listinfo/python-list
Re: New python.org website
> No one > of the complainers and negativists do claim that they could do it much > better. Indeed, I do not have to be able to write a particular program to notice it has bugs. On the other hand, (since I think the design, while not brilliant, is good) fixing the logo is something that can be achieved without too much fuss. > But I think at times it might be usefull to consult > professional aid. In the case of the logo design, I am not sure I agree. I think the twisted logo http://saph.twistedmatrix.com/blog/archives/twisted.png and the PyCon logo http://mirrors.ccs.neu.edu/Python/pub/old-www/pics/pycon-logo.gif were probably not designed by professional designers but rather by people who appreciate Python, and yet do have more appeal to the community and the outside world alike. If we are going to use a snake motif, we should use snakes that look like snakes. I suspect the current shy-tadpoles design was outsourced. (At one point NBC abandoned their very recognizable peacock for a totally vapid geometric design, for which they paid many thousands of dollars. (Including a huge settlement with a Nebraska TV station whose logo they had essentially copied) Eventually they reverted to a somewhat stylized peacock, which was a much better idea.) See http://en.wikipedia.org/wiki/National_Broadcasting_Company_logos It's also interesting in passing to notice that another one of NBC's non-peacock logos was called the "snake", for reasons that will escape anyone who has not seen it animated. In any case, I will probably take a little more time to make the case that the shy tadpoles logo is a mistake. Finally, I disagree that the current logo is better than the neutral but consistently used php logo or the very clever java coffee mug logo, and notably the Ruby on Rails logo, which is first rate. mt -- http://mail.python.org/mailman/listinfo/python-list
Re: New python.org website
While the new one is much better than the old website, the logo strikes me as awful. I tried to suggest repurposing the much better PyCon logo, but it didn't raise the vast groundswell of support I wanted it to. But for whatever its worth I'll try again. My rant is here: http://tinyurl.com/rkq3s mt -- http://mail.python.org/mailman/listinfo/python-list
Re: Python advocacy in scientific computation
> Indentation > makes all kinds of inlined code extremely clumsy or practically impossible > in Python. This is the only sensible argument against the indentation thing I've heard. Python squirms about being inlined in a presentation template. Making a direct competitor to PHP in pure Python is problematic. While there are workarounds which are not hard to envision, it seems like the right answer is not to inline small fragments of Python code in HTML, which is probably the wrong approach for any serious work anyway. This problem does, however, seem to interfere with adoption by beginning web programmers, who may conceivably end up in PHP or perhaps Perl Mason out of an ill-considered expedience. Why this should matter in this discussion, about scientific programming, escapes me though. When you say "all kinds" of inlined code, do you have any other examples besides HTML? mt -- http://mail.python.org/mailman/listinfo/python-list
Re: Python advocacy in scientific computation
> I have met no problems using F90 together with f2py Thank you for the correction. I should have qualified my statement. Our group must cope with F90 derived types to wrap a library that we need. f2py fails to handle this case. While the f2py site alleges that someone is working on this, I contacted the fellow and he said it was on hold. To our knowledge only the (officially unreleased) Babel toolkit can handle F9* derived types. I would be pleased to know of alternatives. To be fair, Babel remains in development, and so perhaps it will become less unwieldy, and the developers have been very helpful to us. Still, it certainly is not as simple a matter as f2py or swig. mt -- http://mail.python.org/mailman/listinfo/python-list
Re: Python advocacy in scientific computation
1) indentation: I claim that this is a trivial matter. Indentation is enforced, but if you want to end all your blocks with #end, feel free. Or write a preprocessor to go from your preferred block style to python's 2) self.something tedious to look at. Again, you can somewhat work around this if you like. Just use "s" or "_" instead of "self". 3) missing 4) multithreading and parallel execution impossible This is simply false, though admittedly the MPI libraries need a little work. Mike Steder of our group is likely to release an alternative. A good way to think of Python is as a powerful extension to C. So using MPI from Python just amounts to setting up a communicator in C and wrapping the MPI calls. As for less tightly coupled threads on a single processor, Python is adept at it. I think the issues with multiple processors are much more those of a server farm than those of a computational cluster. We have been encountering no fundamental difficulty in cluster programs using Python. 5) "I don't like numpy's array slicing" ? this is unclear. It is somewhat different form Matlab's, but much more powerful. 1) pass by reference Python names are all references. The model is a little peculiar to Fortran and C people, but rather similar to the Java model. 2) matplotlib A correct install can be difficult, but once it works it rocks. ipython (a.k.a. pylab) is also a very nice work environment. 3D plots remain unavailable at present. 3) speed Speed matters less in Python than in other languages because Python plays so well with others. For many applications, NumPy is fine. Otherwise write your own C or C++ or F77; building the Python bindings is trivial. (F9* is problematic, though in fact we do some calling of F90 from Python using the Babel toolkit) 4) useful libraries yes. for your svd example see Hinsen's Scientific package. In general, Python's claim of "batteries included" applies to scientific code. mt -- http://mail.python.org/mailman/listinfo/python-list
Re: Python advocacy in scientific computation
> $ rm `find . -name "*.pyc"` Ouch. Is that a true story? While we're remeniscing about bad typos and DEC, I should tell the story about the guy who clobberred his work because his English wasn't very strong. Under RT-11, all file management was handled by a program called PIP. For example to get a list of files in the current working directory you would enter PIP *.* /LI . Well this fellow, from one of those countries where our long "e" sound is their "i" sound, mournfully announced "I vanted a deerectory so I typed 'PIP *.* /DE' " That one is true. mt -- http://mail.python.org/mailman/listinfo/python-list
Re: Python advocacy in scientific computation
There is a range of folks doing scientific programming. Not all of them are described correctly by your summary, but many are. The article is aimed not at them, but rather at institutions that develop engineered Fortran models using multipuurpose teams and formal methods. I appreciate your comments, because I see that there should be another article aimed at desktop programmers. One of the things python addresses best is the division of labor, where the subtle concepts are available to those who need them and hidden from those who don't need them. From what I understand of your work (and what I have seen of the work of two other neuroscientists, actually) Python would be a good choice for you. That said, the level of computational skill in many scientists is alarming. Why do we expect to spend six semesters learning mathematics and expect to pick up computing "on the side"? It baffles me. Frankly, saying "I don't need version control" sounds to me no less foolish than saying "I don't need logarithms". (Perhaps you don't but someday soon you will.) "Speed of excecution is an issue, regardless of what computer science folks try to tell you." strikes me as nothing short of hallucinatory. No informed person says that speed is never an issue, and a great deal of effort is spent on speed. Where do you suppose your Fortran compiler came from in the first place? For someone without legacy code to worry about, fussing with Fortran for single-user one-off codes strikes me as a weak choice. If you are hitting Matlab's performance or memory limits, you should take the time to learn something about computation, not because you are idle, but because you are busy. Or if you prefer, because your competitors will be learning how to be more productive while you put all your efforts into coping with crude tools. The peculiar lack of communication between computer scientists and application scientists is real; but I believe the fault is not all on one side. The fact that you have a PhD does not prove that you know everything you need to know, and I strongly recommend you reconsider this attitude. For one thing, you misjudged which side of the divide I started on. Michael Tobis (While I dislike credentialism on usenet, I will reply in kind. I hold a Ph.D. in geophysical fluid dynamics.) -- http://mail.python.org/mailman/listinfo/python-list
Re: newbie question
I think the answers so far are unnecessarily confusing and off the mark. Here is what I think you think you want to know: 1) import only works once. If you try import again, it will see the module already exists, and will ignore you 2) the functionality you think you want is reload. >>> reload mymodule will essentially reimport mymodule after the first time. However, what you think you want is not what you want, which is why the experienced people are giving misleading and overcomplicated answers. Normally reload is a fairly advanced feature and beginners don't need it. Usually, an import statement invokes a module containing a bunch of definitions (usually functions or classes, but sometimes even constants), but it doesn't DO anything unless it is invoked as the main program. So after you satisfy yourself that "reload" does what you want, try to think about how you would work things so you don't need it. For instance, instead of something like #mystuff.py print "hello ", print "world" # end of file >>> import mystuff hello world >>> import mystuff >>> is ### newstuff.py def newstuff(): print "hello", print " world" # end of file >>> from newstuff import newstuff >>> newstuff() hello, world >>> newstuff() hello, world hth mt -- http://mail.python.org/mailman/listinfo/python-list
Python advocacy in scientific computation
Someone asked me to write a brief essay regarding the value-add proposition for Python in the Fortran community. Slightly modified to remove a few climatology-related specifics, here it is. I would welcome comments and corrections, and would be happy to contribute some version of this to the Python website if it is of interest. === The established use of Fortran in continuum models such as climate models has some benefits, including very high performance and flexibility in dealing with regular arrays, backward compatibility with the existing code base, and the familiarity with the language among the modeling community. Fortran 90 and later versions have taken many of the lessons of object oriented programming and adapted them so that logical separation of modules is supported, allowing for more effective development of large systems. However, there are many purposes to which Fortran is ill-suited which are increasingly part of the modeling environment. These include: source and version control and audit trails for runs, build system management, test specification, deployment testing (across multiple platforms), post-processing analysis, run-time and asynchronous visualization, distributed control and ensemble management. To achieve these goals, a combination of shell scripts, specialized build tools, specialized applications written in several object-oriented languages, and various web and network deployment strategies have been deployed in an ad hoc manner. Not only has much duplication of effort occurred, a great deal of struggling up the learning curves of various technologies has been required as one need or another has been addressed in various ad hoc ways. A new need arises as the ambitions of physical modeling increase; this is the rapid prototyping and testing of new model components. As the number of possible configurations of a model increases, the expense and difficulty of both unit testing and integration testing becomes more demanding. Fortunately, there is Python. Python is a very flexible language that has captured the enthusiasm of commercial and scientific programmers alike. The perception of Python programmers coming from almost any other language is that they are suddenly dramatically several times more productive than previously, in terms of functionality delivered per unit of programmer time. One slogan of the Python community is that the language "fits your brain". Why this might be the case is an interesting question. There are no startling computer science breakthroughs original to the language, Rather, Python afficionados will claim that the language combines the best features of such various languages as Lisp, Perl, Java, and Matlab. Eschewing allegiance to a specific theory of how to program, Python's design instead offers the best practices from many other software cultures. The synergies among these programming modes is in some ways harder to explain than to experience. The Python novice may nevertheless observe that a single language can take the place of shell scripts, makefiles, desktop computation environments, compiled languages to build GUIs, and scripting languages to build web interfaces. In addition, Python is useful as a wrapper for Fortran modules, facilitating the implementation of true test-driven design processes in Fortran models. Another Python advocacy slogan is "batteries included". The point here is that (in part because Python is dramatically easier to write than other languages) there is a very broad range of very powerful standard libraries that make many tasks which are difficult in other languages astonishingly easy in Python. For instance, drawing upon the standard libraries (no additional download required) a portable webserver (runnable on both Microsoft and Unix-based platforms) can be implemented in seven lines of code. (See http://effbot.org/librarybook/simplehttpserver.htm ) Installation of pure python packages is also very easy, and installation of mixed language products with a Python component is generally not significantly harder than a comparable product with no Python component. Among the Python components and Python bindings of special interest to scientists are the elegant and powerful matplotlib plotting package, which began by emulating and now surpasses the plotting features of Matlab, SWIG, which allows for runtime interoperability with various languages, f2py which specifically interoperates with Fortran, NetCDF libraries (which cope with NetCDF files with dramatically less fuss than the standard C or Fortran bindings), statistics packages including bindings to the R language, linear algebra packages, various platform-specific and portable GUI libraries, genetic algorithms, optimization libraries, and bindings for high performance differential equation solvers (notably, using the Argonne National Laboratory package PetSC). An especially interesting Python trick for runtime visualization in models that were not designed
Re: Is python very slow compared to C
> Read his post again. He didn't ask a specific question at all, and he > certainly didn't mention execution speed. agreed > He asked a vague, meaningless question about whether Python was "slow > compared to C". No, that is both wrong and gratuitously harsh. He had heard vague meaningless complaints about whether Python was "slow compared to C" and asked us to "pinpoint the issue", i.e., to determine in what sense the allegation might be true. That is a precise and meaningful question and being asked in a commendable fashion. mt -- http://mail.python.org/mailman/listinfo/python-list
Re: Is python very slow compared to C
Experienced programmers learning Python should read this: http://effbot.org/zone/python-objects.htm Try to understand the advantages of this approach, and understand its costs. Essentially, everything you do in Python (or related languages) involves resolving a name. Sometimes the number of dictionary look-ups (name dereferences) required to do anything is very expensive in runtime performance. If your code is not compute-bound (as most codes are not; these days communication-bound or limited by database performance are more common) the increase in your own performance will be much more important. If your code does do so much computing (as mine do) that performance matters, you may still find Python useful, but it is less of a slam-dunk. mt -- http://mail.python.org/mailman/listinfo/python-list
Re: VB to Python migration
An incremental approach and a redesign are not the same thing. It might be insurmountably difficult to acheeve both in a move to another platform. mt -- http://mail.python.org/mailman/listinfo/python-list
Re: beta.python.org content
What about some permutation of the PyCon logo? It is really quite brilliant. Solves many problems: dynamic, doesn't just sit there, looks like it is moving toward a goal direction of motion surprising and memorable refers to software in the minds of experienced coders takes advantage of the snake association without being creepy reassuring to corporate types but fun and T-shirt friendly can be permuted in lots of amusing ways, optionally as output from code first impression is cheerful, second impression is cleverness http://www.python.org/pycon/2006/logo.png Kudos to whoever came up with that, by the way! mt -- http://mail.python.org/mailman/listinfo/python-list
Re: beta.python.org content
I like the design, though I'd prefer stronger colors. I think it would be a major improvement except for the logo. I agree with others that the logo is a serious disappointment. Although the symmetry has some initial appeal, I do not see or want to see a two-ness about Python, and I find it disturbing and distracting even without the vague cruciform aspects. In fact, just keeping the top snake would be MUCH better. I want a logo I can be as enthusiastic about as I am about the language, but it will be hard to get unanimity about that, and I can certainly see the need to compromise. Still it's my impression that this one is a big mistake. Unlike, say, the Sun logo which I enjoy looking at (and of which this is a cheap ripoff), this is like the Microsoft Office logo, which I find explicitly off-putting, raising negative associations. I might be convinced that its wrongness will outweigh all the remaining benefits of the redesign. Good: http://cswww.essex.ac.uk/PLANET/summer-school-02/sun-logo-new.GIF Makes you think of cleverness, symmetry, networking, collaboration, energy. It reinforces my positive feelings toward this company. Bad: http://www.genbeta.com/archivos/images/logo_office_2003.jpg Makes you think about petty politics, imbalance, who gets the window office, injustice, asymmetry, deformity. I detest this logo, and it reinforces my avoidance of this company. Bad: http://beta.python.org/images/python-logo.gif Nice font on the text, but the image raises: What is that animal? Is it a snake? If it is, why is it so short? Why are there two of them? Or is it one snake with two heads? Ewww. Why is one facing backwards and the other upside-down? Is that a crucifix? Why would someone make a cross out of snakes? These are people to avoid. Very unsatisfactory, sorry. mt -- http://mail.python.org/mailman/listinfo/python-list
Re: beta.python.org content
newer success stories please... mt -- http://mail.python.org/mailman/listinfo/python-list
Re: Which Python web framework is most like Ruby on Rails?
Clearly the Ruby/Rails folks are making an effort to place themselves as an easy-to-learn first language for people who might otherwise drift into the rather awkward template-first way of thinking that is PHP. I note that the Rails people are closely affiliated with the 37signals people who in turn are closely linked with some advertising professionals. Python people don't really think that way. As a community we really seem to inherit the open source dysfunction of trying harder to impress each other than to reach out to the rest of the world. The problem is that this makes for amazing brilliance that is more or less invisible to most of the world. This leaves me believing that the commercial future is probably brighter for Ruby vs Python. This won't affect the fact that Python is probably still going to prevail in the scientific community, since scientists aren't all that susceptible to promotion. That being the case I don't think I myself will jump ship. Since I am casting my lot with Python rather than Ruby, I think we should take the friendly rivalry seriously rather than just shrugging it off. Python MUST attract some of the most promising novice programmers, and I believe that was part of its original design. As a consequence Python MUST settle on a strong web framework that includes the best of the existing frameworks, and polish it for maximum accessibility as well as power. Just on the basis of momentum rather than any strong technical argument (which I am not well-qualified to make) I suggest we consider settling on Django and doing what we can to improve it and its documentation. mt -- http://mail.python.org/mailman/listinfo/python-list
Re: assignment to reference
I apparently don't understand this question in the same way the way others do. I think the question is about the mutability of strings. To my understanding of your question, it is impossible, at least if the referenced objects are strings or other objects of immutable type. 'cabbage' cannot be changed into 'coconut', though list('cabbage') can be changed to list('coconut') in place. >>> x = list('cabbage') >>> id(x) 458640 >>> y = list('coconut') >>> id(y) 458736 >>> x[:] = y[:] >>> x ['c', 'o', 'c', 'o', 'n', 'u', 't'] >>> id (x) 458640 >>> "".join(x) 'coconut' You would need to be doing a LOT of these for any of this to be worth the bother, or else have some rather exotic application you aren't telling us about. If I am reading you right the eval() is a red herring. I agree with the others that you don't want an eval() here and you're better off with a dict, but I am not sure that answers your question. mt -- http://mail.python.org/mailman/listinfo/python-list
Re: Hi All - Newby
> confusion regarding some of the basics... Reset your brain. This came up recently, and despite there being a pending quibble, I think it's extremely useful to the experienced programmer/new Pythonista: http://effbot.org/zone/python-objects.htm And since Frederik is apparenlty reading this thread, it gives me an opportunity to say thanks for it! mt -- http://mail.python.org/mailman/listinfo/python-list
PyNSol: Objects as Scaffolding
An article of mine, entitled "PyNSol: Objects as Scaffolding" has appeared in Computing in Science and Engineering. You can read it at http://www.computer.org/portal/site/cise/ or alternatively at http://geosci.uchicago.edu/~tobis/ciseps.pdf It's not so much an article about a software project as it is an article using that project to present an alternative way of thinking about how object oriented programming (and Python!) can relate to high performance simulations. I welcome comments. mt -- Michael Tobis Geophysical Sciences University of Chicago -- http://mail.python.org/mailman/listinfo/python-list
Re: declarations summary
Well, many scientists and engineers don't have the time, motivation or ability to master the intricacies of recent fortran vintages either. That's the problem. Very large codes written by teams of software engineers for well-delimited application spaces will continue to be written in some version of Fortran. I hope the follwoing will explain why this causes me difficulty. Toy codes will probably move from Matlab to Python soon enough, if only because Python, iPython and Matplotlib are free. It's the middle ground, large codes as modified by single researchers, where much of the real work of research gets done, and the infrastructure for this use case is abysmal. The near-term solution I'm coming to is code generation. As much as possible I intend to present a clean Python interface to the scientist and generate efficient compilable code behind their back. Among the questions I'm trying to address is whether Python can or will ever be so efficient that much of my work in this direction will be abandoned. In that case, I can focus on the expression side, and leave the efficiency question alone in the expectation that PyPy (or something) will take care of it someday. Another question is which language I should use as the back end. C or even F77 can be coupled into the interactive environment on the fly. Actual production work, of course, gains nothing from interactivity, but we are still envisioning a significant scientist/developer use case; in fact, that's the point. Whether I like it or not, the group I work with is interested in is in F90 source. (CCSM) This has proven awkward to integrate into Python, though not impossible for some compilers thanks to the work of the Babel and Chasm groups. In practice, had the professional coders developing CCSM used C++ rather than Fortran90 (or even had they stuck to F77), we would be in a better position to expose a well-defined low-complexity high-efficiency layer to the non-CS specialist physical scientist. That's a mouthful, I admit, but (trust me) the world would be a better place if it were done. So such advantages as do exist for a professional full-time computational science group in developing CCSM in F90 have ended up as a hindrance to what my constituency regards as the most important use case. Beliavsky's summary of what is available is a taxonomy of distinct islands of production with tenuous connections between them. I don't want quick-code slow-run "alternatives" to slow-code high-performance production codes. I want, and my users need, a unified scientific software environment which provides powerful expression without sacrificing performance or interoperability. Do I expect Fortran to go away? Not anytime soon. Do I expect an alternative to emerge? Indeed I do, and I hope to be part of said emergence. In fact, I don't know what the high-performance scientific computer language of the year 2020 will look like, but I, for one, would like it to be called "Python". mt -- http://mail.python.org/mailman/listinfo/python-list
Re: declarations summary
Alex Martelli wrote: > Michael Tobis <[EMAIL PROTECTED]> wrote: >... > > .x = 1 > > .def foo(): > > . if False: > > . global x > > . x = 2 > > .foo() > > .print x > > > > prints "1" > > Wrong: > >>> foo() > >>> print x > 2 > > And indeed, that IS the problem. Right. That's what I meant. Sorry, that was a thinkographical error. mt -- http://mail.python.org/mailman/listinfo/python-list
declarations summary
Summary of my understanding of a recent interesting thread: General usage has "declaration" meaning "statement which does not generate executable bytecode but merely affects the compiler". My assertion that decorator syntax is "declarative" is therefore formally false. The common assertion that "Python is 100% executable" is an exageration, but not because of the introduction of decorator syntax. The "global" statement, however is not executable and is recognized as a declaration. Both "global" and "@", though have the characteristics that 1) they don't fit comfortably into Python syntax and 2) they at least conceptually affect the reference and not the referent. In suport of the first point, unlike any other block, decorators can appear at only particular places in the file. Meanwhile globals are counterintuitively indifferent to whether they are nested in code branches that don't execute. .x = 1 .def foo(): . if False: . global x . x = 2 .foo() .print x prints "1" These are implemented in different ways and both seem to be somehow unsatisfactory. They also seem to have something in common. However, for me to call them both "declarations" was incorrect. Pythonistas appear to be averse to any declarations (in the sense of compiler directives) besides "global". The resistance to "@" is a lost cause, even though a dramatically superior def foo(a,b,c) decoby bar" syntax was proposed. I find this hard to justify, as a deocrator is clearly a modifier of an immediately following function declaration rather than a freeestanding executable block. If it were feasible,I'd even prefer def foo(a,b,c) decoby [baz,quux]: so that the list of decorators could be dynamically constructued at define time. Anyway, it's this sort of reference-modifier that's at issue here, whether or not the implementation is truly declarative. Now that there's two, can there be more? Should there be? It's not difficult for me to imagine at least two other things I'd want to do with references: 1) make them immutable (making life easier for the compiler) 2) make them refer only to objects with certain properties (strong duck-typing). Also there's the question of typo-driven bugs, where an attempted rebinding of "epsilon" instead cerated a reference called "epselon". (The epselon bug) This is the bane of fortran, and after generations it was generally agreed that optionally one could require all references to be declared (implicit none). Perl went throgh a similar process and implemented a "use strict" module. Experienced Pythonistas are oddly resistant to even contemplating this change, though in the Fortran and Perl worlds their usage quickly became practically universal. I believe that enthusiasm for this construct in other languages is so strong that it should be prominently addressed in Python introductions and surveys, and that questions in this regard should be expected from newbies and patiently addressed. I also don't fully understand the profound aversion to this idea. I myself am going back and forth on all this. I despise the fact that good fortran90 code often has more declarations than executables. Ed Ream (LEO's author) pointed out to me the Edward-Tufte-ness of Python. No wasted ink (except maybe the colons, which I do sometimes find myself forgetting on long edits...) I don't want Python to look like f90. What would be the point? On the other hand, I think compiler writers are too attached to cleverly divining the intention of the programmer. Much of the effort of the compiler could be obviated by judicious use of declarations and other hints in cases where they matter. Correct code could always be generated without these hints, but code could be made more runtime-efficient with them. People who are running codes that are a compute-bound tend not to be beginners, and could put up with some clutter when tuning their code. In the end, I think the intuition of what's Pythonic is enormously valuable, and I'm continuing to learn from discussions here every day. As a result, I'm inclined to believe in the grounds of authority that this sort of trick does not belong in Python. That said it seems unlikely that any version of Python will ever be competitive as a high-performance numerical computing language because nothing can be known about bindings at compile time, as we are constantly being remineded here. I'll be happy if Python knocks my socks off yet again, but I can't see counting on it. So the successor to Fortran (presuming it isn't C++, which I do presume) may be influenced by Python, but probably it won't be Python. mt -- http://mail.python.org/mailman/listinfo/python-list
Re: variable declaration
> All in all, I fail to see what gains would be expected by making Python > into a single-assignment or single-binding language, even on a module by > module basis, to repay this kind of awkwardness. Just to be clear, if anyone was suggesting that, it wasn't me. It would be helpful on occasion in a numarray development context to have *specific* refererences be bound only once, and I wouldn't be surprised if the compiler couldn't use that information to good advantage too. However, this subthread is about whether rebinding is completely avoidable. Others including you have come up with better reasons than I did that it's not. If rebinding is normal, I think the 'epselon' bug can't be dismissed as completely avoidable. This is something that I gather you disagree with on the presumption that everyone who writes Python is sufficently talented that they can use their skills to avoid getting too far into this trap. Since I'm very much a believer in Python as a beginner's language, that doesn't satisfy me. "Declarations are impractical" would satisfy me, but so far I'm not completely convinced of that. mt -- http://mail.python.org/mailman/listinfo/python-list
Re: pythonic equivalent of Mathematica's FixedPoint function
We apologise for the previous apology. http://arago4.tn.utwente.nl/stonedead/albums-cds/sketches/another-monty-python-record/apologies.html -- mt -- http://mail.python.org/mailman/listinfo/python-list
Re: variable declaration
> How common is it for a local variable to be bound in > more than one place within a function? It's more natural for a beginner to read or write .mystr = "" .for snippet in snippets: . if ilike(snippet): . mystr = mystr + snippet than .mylist = [] .for snippet in snippets: . if ilike(snippet): . mylist.append(snippet) .mystr = "".join(mylist) for instance. While the latter is superior in some ways, I frequently find my fingers tossing off the former approach. Of course in this case it's not hard to come up with mystr = "".join([snippet in snippets if ilike(snippet)]) but it's also not too hard to imagine cases where the list comprehension would be too complex or would require too much refactoring. I don't know that it's ever necessary to rebind, but it is, in fact, common, and perhaps too easy. In numeric Python, avoiding rebinding turns out to be a nontrivial skill. mt -- http://mail.python.org/mailman/listinfo/python-list
Re: variable declaration
Given the behavior, the documentation is gratifyingly correct. Given that the syntax is legal, though, the behavior is not what one would intuitively expect, and is therefore unPythonic by (rather dramatically) violating the principle of least surprise. It's also, to me, understandable why it's difficult for the language design to avoid this behavior. This little discovery of mine sheds some considerable light on the awkwardness of what you guys will deign to call "declarations". This being the case, I can understand the resistance to "declarations" in Python. I had thought, until the current conversation and this experiment, that the globals statement, er, declaration was just another executable, especially given all the stress on Python's being purely executable. I still see "global" and "@" as expressions of the same fundamental problem, even though decorators are not implemented as declarations. They both take effect in a non-intuitive sequence and they both affect the reference rather than the referent. This points out the problem that Python has in qualifying references rather than referents. Since BDFL is contemplating some optional typing, does this also imply qualifying the references? Maybe you wizard types can agree that there is a useful abstraction that I'm talking about here, whether you wish to call it "declarations" or not, and try to factor out some sort of consistent strategy for dealing with it, perhaps in P3K. (I will try to be in a position to help someday, but I have a long way to go.) Language features that modify references rather than referents appear to be problematic. Python clearly chafes at these. Yet there are at least a few compelling reasons to want them. -- mt -- http://mail.python.org/mailman/listinfo/python-list
Re: variable declaration
Alex Martelli wrote: > Michael Tobis <[EMAIL PROTECTED]> wrote: > he can perfectly > well correct his misexpression if he cares to -- not my job to try to > read his mind and perform exegesis on his words. Well, I hate to try to tell you your job, but it doesn't seem to be to be all that great of a marketing strategy to actively chase people away... Hey, he might have been a Nutshell customer. > I think it would have been true, but weak and insufficient. Not only > experienced Python users have that opinion: lack of declarations didn't > faze me even I was a total newbie It did me, and it did many others. Perhaps you are unrepresentative. It's one thing to say "no can do, sorry", it's another to say "you don't need this anyway and if you think you do you aren't worthy". In fact, it was your book I spent the most time thumbing through looking for the "use strict" equivalent that I was absolutely certain must exist. Hell, even Fortran eventually gave in to "IMPLICIT NONE". It's practically the only thing I've ever expected to find in Python that hasn't vastly exceeded my expectations, aand I'm sure Alexander is not the only person to be put off by it. In fact, I'd recommend a paragraph early in the Nutshell book saying "there are no declarations, no use strict, no implicit none, sorry, forget it", and an index listing under "declarations" pointing to a detailed exegesis of their nonexistence. It would have saved me some time. It's true that in some sense an assignment is all the declaration you need. I think Carl Banks's point (what we think of as assignment as a carryover from other languages is really rebinding, and in many cases can be avoided) is also helpful. But that doesn't make the "epselon" bug go away, and wanting to have a way to catch it quickly isn't, to my mind, obviously a criminal act. Also, based on what DogWalker demonstrates, it's really not that alien to Python and should be feasible. > > Also, the assertion that "Python has no declarations whatsoever" is no > > longer obviously true. In the 2.4 decorator syntax, a decorator line is > > not executable, but rather a modifier to a subsequent symbol binding. I > > call it a declaration. > > You may call it a strawberry, if you wish, but that doesn't mean it will > taste good with fresh cream. It's nothing more and nothing less than an > arguably weird syntax for a perfectly executable statement: This may well be true in implementation, but cognitively it is a declaration that modifies the reference and not the referent. I see that it is a big deal to ask for more of these, but I don't see why. > > Let me add that I remain unconvinced that a language cannot combine the > > best features of Python with very high performance, which is ultimately > > I'm also unconvinced. Fortunately, so is the EU, so they have approved > very substantial financing for the pypy project, which aims in good part > exactly at probing this issue. I hope this works out, but it's hard for me to see how pypy will avoid lots of hashing through dictionaries. I'm willing to help it by declaring an immutable reference. Here, don't look this up; it always points to that. I'm guessing that this will also be considered a bad idea, and maybe someday I'll understand why. I'm looking for insight, not controversy. > If any single individual can be called > the ideator of pypy, I think it's Armin Rigo, well-known for his > excellent psyco specializing-compiler for Python: I'm hoping I can make the meeting. Maybe proximity to the core group will help me approach the sort of enlightenment I seek. Just being in the vicinity of Ian Bicking's aura on occasion has been most inspiring. > Almost nobody really liked the splat-syntax for decorators, except of > course Guido, who's the only one who really counts (the BDFL). But that > was strictly a syntax-sugar issue Um, sugar isn't exactly what I'd call it. I think it matters a lot though. Python's being easy on the eyes is not a trivial advantage for some people, myself incuded. > If "declarative statement" means anything, I guess it means "having to > tell stuff to the compiler to be taken into account during compilation > but irrelevant at runtime". Python does have one such wart, the > 'global' statement, and it's just as ugly as one might imagine, but > fortunately quite marginal, so one can almost forget it. I am trying to talk about having expressive power in constraining references as well as the referents. Python studiously avoids this, but decorators change that. I am not deep enough into the mojo as yet to h
Re: variable declaration
This is definitely a wart: ... z = 42.3 ... ... def f(): ...if False: ... global z ...z = -666 ... ... f() ... print z -- http://mail.python.org/mailman/listinfo/python-list
Re: variable declaration
> that's a nice theory, but since the decorator line is executed by the inter- > preter, it's a little weak. Well, uh, who else would process it? "use strict' and 'my epsilon' in perl are executed by the perl interpreter as well, but they have a declarative flavor. A decorator is a modifier to a subsequent binding, and it modifies the reference and not the referent. So how is it anythng but declarative? -- mt -- http://mail.python.org/mailman/listinfo/python-list
Re: variable declaration
With all due respect, I think "so go away if you don't like it" is excessive, and "so go away if you don't like it and you obviously don't like it so definitely go away" is more so. The writer is obviously neither a native speaker of English nor an accomplished user of Python, so there are two language issues here. Try expressing your reply in Russian before deciding that "very ugly" means exactly what you think it does. I think just saying that "experienced Python users have not found the lack of declarations to be a major hindrance" would have been more appropriate. Also, the assertion that "Python has no declarations whatsoever" is no longer obviously true. In the 2.4 decorator syntax, a decorator line is not executable, but rather a modifier to a subsequent symbol binding. I call it a declaration. I found this disappointing in that it seems to me a violation of "Special cases aren't special enough to break the rules" but on further reflection it enables consideration of what a whole slew of declarative constructs could achieve. To begin with, now that the design constraint of "no declarations" has been shown to be less than absolute, why not allow for perl-style ('use strict') declarations? It actually is very useful in the small-script space (up to a few hundred lines) where the best Perl codes live. Let me add that I remain unconvinced that a language cannot combine the best features of Python with very high performance, which is ultimately what I want. It seems to me that such a language (possibly Python, possibly a Python fork, possibly something else) will need substantial programmer control over references as well as referents. It seems to me that Python has a weaker case for purity in this regard now that the dam has been breached with decorator syntax, which is, I think, a declaration. Let me conclude with the confession that I'm still on the steep part of the learning curve (if it ever flattens out at all...). Python has definitely significantly modified how I think about things, and I deeply appreciate all the efforts of you veterans. So I say this all with some trepidation, because I don't want to join Alexander in inadvertently offending you. And since I presumably missed some intense flame wars about decorators by only a couple of months, this may be a real hornet's nest I am poking. In summary, again with all due respect and gratitude for the spectacularly excellent product that Python is today, I wonder *why* this strong aversion to declarative statements, and *whether* decorator syntax constitutes a violation of it. I'd appreciate any responses or links. -- mt -- http://mail.python.org/mailman/listinfo/python-list
Re: Fortran pros and cons (was Re: Coding style article with interesting section on white space)
[EMAIL PROTECTED] wrote: > Michael Tobis wrote: > Fortran 90/95 is more expressive than Fortran 77 in many ways, as > described in ... > http://www.nr.com/CiP97.pdf . > > ... expresses more science per > line of code and per programming workday. The example shown on p 10 illustrates a shorter piece of code in f90 than in f77, but it is not obviously more expressive or less complex. Arguably the f77 code is easier to write and maintain, even though it has more linefeeds in it, so I find the example far from compelling. In fact, I find the f90 example impenetrable. Specifically, what does array_copy(source,dest,n,nn) do? I note that n and nn are uninitialized at call time. Are these outputs from array_copy(), appearing, in that inimitable Fortran way, in the call signature? Here it is in Python with NumArray: b = sort(compress(less(v,200.) * greater(v,100.),m )) result = b[(len(b)+3)//4] I certainly think this example is competitive for whatever that's worth. It has the added benefit of handling the case of an empty list with a nice catchable IndexError exception. However, if this were intended to be maintainable code I would find it most effectively expressed something like this: ... def magthresh(vel,mag,vmin=100.,vmax=200.): ...selector = less(vel,vmax) * greater(vel,vmin) ...sortedmags = sort(compress(selector,mag)) ...if len(sortedmags): ... index = (len(sortedmags) + 3) // 4 ... return sortedmags[index] ...else: ... raise IndexError,"No velocities in range." mt -- http://mail.python.org/mailman/listinfo/python-list