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
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: 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
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, 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: 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: 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. KR 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:///path-to-edna/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 path to browser 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
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
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
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
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
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: 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
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: 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
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: 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
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
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: 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=glancen=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
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: 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
hack hack type 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: 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: 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: 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: 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: 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: 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: 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: 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: - 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: 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
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: 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
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: 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: 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: 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: 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: 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
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
$ 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
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
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 to
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
newer success stories please... 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: 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
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
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
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
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
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: 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
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: 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: 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
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 have more than a glimmer of an idea about the distinction you are making. It's not the one I'm trying to make. decorators may not be implemented as declarations, but they cognitively act as declarations, and that's what I care about here. I have nothing against a declarative style _per se_ -- it just doesn't fit Python's everything happens at runtime overall worldview, and that simple and powerful worldview is a good part of what makes Python tick SO
Re: Coding style article with interesting section on white space
[EMAIL PROTECTED] wrote: Michael Tobis wrote: (unwisely taking the bait...) If you like your language to look like this http://www.cs.rpi.edu/~szymansk/OOF90/bugs.html then more power to you. Thanks for pointing out that interesting article on Fortran 90 bugs. How long would a comparable C++ list be? Even Python has gotchas, for example the difference between deep and shallow copies. The reply C++ is even worse, while debatable either way, seems to be a common response from Fortran defenders. It misses the point. What the scientific community needs, whether they know it or not, is high-performance Python if that's possible, or something as close to it as possible. Specifically, something with serious introspective power and economy of expression. I prefer my languages to be portable, terse and expressive. Fortran programmers are generally happy with the portability of the language. Until they try to port something...? Honestly, I can't imagine where anyone would get this impression. Now, about the terseness and expressiveness? For scientific computation, consider the case of Numeric and Numarray. I'm not happy with these, because they either make temporary arrays with wild abandon, or enforce an unnatural style of expression. I could see how they would be useful to others but they are awkward in long-time spatially coarse finite difference/finite volume/spectral calculations, which is the problem space I care about. As for non-coarse (finite element) integrations (where rectangular decompositions do not suffice) it seems to me that using Fortran is sheer madness, even though there are real pointers now. I do not suggest that Python is currently competitive with C++ or Fortran. I simply agree with http://www.fortranstatement.com that something new ought to be designed, that a backward compatible Fortran2003 cannot possibly be it, and that attention to fortran diverts resources from teh osrt of genuine progress that ought to be possible. The recent Pystone Benchmark message says that Python is only 75% as fast on Linux as on Windows. Fortran programs do not suffer this performance hit and are in this respect more portable. In theory, as has been mentioned, one could use a faster compiler to compile CPython on Linux, but AFAIK this has not yet been done. Without disagreeing with Alex Martelli's response to this, I find it nonsensical on other grounds. Performance portability has nothing to do with what I'm talking about. The answer belies the attitude that programmers are there to put in time and expend effort, because the only resource worth considering is production cycles on a big machine. This attitude explains why working with Fortran is so unpleasant an experience for anyone who has been exposed to other languages. An alternative attitude is that the amount of human effort put into solving a problem is a relevant factor. In this view, portability is actually about build effort, not runtime performance. Perhaps the Fortran community finds this idea surprising? Getting a python package working usually amounts to an install command to the OS and an import command to the interpreter. Then you can get down to work. Getting a Fortran package working involves not only an endless dance with obscure compiler flags and library links, but then a set of workarounds for codes that produce expected results on one compiler and compile failures or even different results on another. The day when project cost was dominated by machine time as opposed to programmer time is coming to a close. Fortran is a meaningful solution only to the extent that programmer time is not just secondary but actually negligible as a cost. The assumption that portability is somehow about performance belies total lack of concern for the programmer as a resource, and therefore to the time-to-solution of any new class of scientific problem. The result of this habit of thought (entirely appropriate to 1955) is that in an environment where fortran is expected, new problems are interpreted as changes to old problems, and the packages become vast and bloated. Since most of these legacy codes in practice predate any concept of design-for-test, they are also almost certainly wrong, in the sense that they are unlikely to implement the mathematics they purport to implement. Usually they are close enough for some purposes, but it's impossible to delimit what purposes are inside or outside the range of application. Nobody is stopping Python developers from working on projects like Psyco. They aren't helping either, for the most part. Psyco aside, institutions that ought to be supporting development of high-performance high-expressiveness scientific languages are not doing so. Institutions with a Fortran legacy base are confused between maintaining the existing investment and expanding it. The former is frequently a mistake already, but the latter is a mistake almost always. This mistake drives investment
bound vs unbound functions
I'm trying to do metaprogramming. I'm sure I've got this all wrong wrong wrong, but somehow my approach hasn't yet hit a brick wall. Anyway, I'd like to dynamically add a method to an instance at instantiation time. Something like ## In [71]: class quux(object): : def __init__(self,stuff): : template = def foo(self,b): print b + %s % stuff : exec(template) : self.bazz = foo : In [72]: q = quux(5) In [73]: q.bazz(4) --- TypeError Traceback (most recent call last) /Users/tobis/PyNSol/console TypeError: foo() takes exactly 2 arguments (1 given) In [74]: q.bazz(not much,4) 9 So the straightforward question is why, even though bazz is a method of class quux, it doesn't have that extra call parameter 'self'. Is this a problem? If I actually need a reference to self is it OK to do: In [76]: q.bazz(q,4) ? The more vague question is why do people despise 'exec', and how should I do this sort of thing instead? mt PS - any idea how to get past google's stupid formatting these days? I thought they were supposed to like python, but they just ignore leading blanks. -- http://mail.python.org/mailman/listinfo/python-list
Re: naive doc question
I wouldn't call the responses here helpful; they seem overspecific. I had a similar problem which led to the follwing code. After I came up with this I saw a very similar utility was derived in Dive into Python. see http://diveintopython.org/power_of_introspection/index.html#apihelper.divein Anyway the following is intended as an interactive utility to explore the callables of modules and classes. I always have it imported into my interactive sessions. So import it and try sm(dict) . .# sm() .# showmethods . .def sm(namespace,terse=0,maxchars=300): . . report the callables of a namespace . .returns a nice string representation of the public callables of the .namespace and the first maxchars bytes of their respective docstrings . .if terse, truncates the docstring at the first newline . . . d = namespace.__dict__ . l = [str(x) + \t\t + str(d[x].__doc__)[:maxchars] for x in d.keys() \ .if callable(d[x]) and not x.startswith(_)] . if terse: . l = [x.split(\n)[0] for x in l] . l.sort() . return \n=\n.join(l) -- http://mail.python.org/mailman/listinfo/python-list
Re: Coding style article with interesting section on white space
(unwisely taking the bait...) If you like your language to look like this http://www.cs.rpi.edu/~szymansk/OOF90/bugs.html then more power to you. I prefer my languages to be portable, terse and expressive. That's why I like Python. If you want your language to be obscure, ill-defined and inconsistent across platforms, by all means go to comp.lang.fortran . There is no fundamental reason why a language with expressive power much like Python's cannot have run-time performance comparable to Fortran's. Unfortunately, Fortran's dominance of the relatively small scientific computation universe has prevented such a language from emerging. The solutions which interest me in the short run are 1) writing a code generation layer from Python to a compiled language (possibly F77 though I will try to get away with C) and 2) wrapping legacy Fortran in Python. The latter is quite regularly subverted by non-standard binary data structures across compilers and a pretty profound disinterest in interoperability by the people designing the Fortran standard that makes their interest look more like turf protection and less like an interest in the progress of science. In the long run, hopefully a high-performance language that has significant capacity for abstraction and introspection will emerge. People keep trying various ways to coax Python into that role. Maybe it will work, or maybe a fresh start is needed. Awkwardly bolting even more conetmporary concepts onto Fortran is not going to achieve bringing computational science up to date. Python fundamentally respects the programmer. Fortran started from a point of respecting only the machine, (which is why Fortrans up to F77, having a well-defined objective, were reasonable) but now it is a motley collection of half-baked and confusing compromises between runtime performance, backward compatibility, and awkward efforts at keeping up with trends in computer languages. So-called object oriented Fortran makes the most baroque Java look elegant and expressive. For more see http://www.fortranstatement.com Language matters. You can't really write Python in any language. mt -- http://mail.python.org/mailman/listinfo/python-list
