Re: Win32 python and excel macros
[EMAIL PROTECTED] wrote:
> Hi Experts,
>
> Looking for a very quick bit on of advice on how to make some python
> code run. I'm a newbie to both VBA and Python, so i apologise if this
> is very easy but i'm about to tear my hair out after googling for the
> last 3 days.
>
> I have written a large python script which inside of it creates an
> Excel table, the name of this file and how many objects can change for
> each project i run.
>
> I have then written a VBA script which takes the info from Excel and
> drops it into a PowerPoint Pres.
>
> Both of these procedures work fine, but i am coming unstuck when i try
> to apply the macro, (or .xla) file to the new tables autmatically. Can
> anyone give me any guidance on this?
>
> The macro is called sub is CTP and the add-in file is CTP.XLA
>
> Below is the code i've managed to 'Stick' together
>
> Mike
>
> import win32com.client
> xl = win32com.client.Dispatch("Excel.Application")
> ppt = win32com.client.Dispatch("PowerPoint.Application")
> xl.Visible = 1 #open MS Excel
> ppt.Visible = 1 #open MS Powerpoint
> xl.Workbooks.Open('Z:\\projects\\surveys\\SPSS - Generic files\\big
> output.xls') #A table for a project
> xl.Workbooks.Open('Z:\\projects\\surveys\\SPSS - Generic
> files\\CTP.xla') # Stored macro add-in
> ppt.Presentations.Open('Z:\\projects\\surveys\\SPSS - Generic
> files\\Basic Template.ppt')
> xl.Application.ExecuteExcel4macro('CTP!CTP.xla()"[big output.XLS]')
It doesn't really make sense to apply a *file* to a *file* - you apply
a sub or function in that file to a range in the other file (I'm
assuming that your table is stored as a range of cells). What
ExcecuteExcel4Macro is expecting as input is a string along the lines
of
'CTP!MacroName(Workbooks("big output").Range("A1:C100"))'
(experiment with using "" instead of " since VBA requires embedded " to
be escaped by "" - but since you are writing this in Python it might
not be necessary). Maybe experiment with writing a VBA macro in Excel
which can successfuly launch the macro you need and then translate the
appropriate snippet to your python script. Also - are you sure that the
add-in macro is an old-style Excel4 macro? That would make it about 10
years old or deliberately retro. If not - the run method might be more
appropriate.
You should probably open the workbooks in such a way that big
output.xls is the active workbook (and not ctp.xla) since most add-ins
assume that the calling workbook is the active workbook (although - I
don't know how an old-style pre-VBA Excel4 macro handled things). Thus
you would probably want to open big output.xls last (or use
xl.Application.Workbooks("big output").Activate ) to make sure that it
is the active workbook. Also - do you even have to open ctp.xla
explicitly? If it is an installed add-in then that line might be
redundant.
A final potential problem is that big output.xls might require a
reference to ctp.xla. This sometimes happens when you try to invoke
add-in code from another VBA project - but I would think that the
ExecuteExcel4macro would bypass that.
I can't comment on the python part of the equation - I am a complete
newbie there.
You might consider reposting this in microsoft.public.excel.programming
since many of the regular posters there know a lot about automating
Excel from scripting languages. They could at least help you with the
VBA side of the equation.
I hope that my random thoughts don't misguide you too much.
-John Coleman
--
http://mail.python.org/mailman/listinfo/python-list
Re: Win32 python and excel macros
Mike P wrote: > After just running trying that update it hits the macro perfectly but > hten i get an error message after i type in a couple of values.. as per > below > > Traceback (most recent call last): > File "", line 148, in ? > File ">", line 14, in Run > File "C:\Python24\Lib\site-packages\win32com\client\dynamic.py", line > 258, in _ApplyTypes_ > result = self._oleobj_.InvokeTypes(*(dispid, LCID, wFlags, retType, > argTypes) + args) > pywintypes.com_error: (-2147352567, 'Exception occurred.', (0, None, > None, None, 0, -2146827284), None) > > > I know you said you didn't know much about python, so if any other > experts outthere can give me a clue.. i'll be very appreciative > > Mike Mike, Maybe you can use a little error handling in the VBA code to see if the error is in the VBA or in the Python (or both) At the top of the sub that you call put the line On Error GoTo err_handler and at the bottom of the sub (right before the end sub) put: err_handler: If Err.Number > 0 Then MsgBox "Error " & Err.Number & ": " & Err.Description End If This will also give you some idea of what the error is from VBA's perspective (although the error descriptions are not always very informative). HTH -John Coleman -- http://mail.python.org/mailman/listinfo/python-list
Re: question about True values
Paul Rubin wrote: > John Salerno <[EMAIL PROTECTED]> writes: > > I'm a little confused. Why doesn't s evaluate to True in the first > > part, but it does in the second? Is the first statement something > > different? > > No. True and False are boolean values, where booleans are a different > data type from strings, just like strings are different from integers. > > >>> if s: > print 'hi' > > converts s to a boolean during evaluation. That is, it's the same as > > if bool(s): print 'hi' > > bool(s) is a function that converts s to a bool. If s is a string, > bool(s) is true if s is nonempty, false otherwise. > > A comparable thing with integers: suppose > >x = 3.1 > > then "x == 3" is false, but "int(x) == 3" is true. But then why is 3.0 == 3 true? They are different types. -- http://mail.python.org/mailman/listinfo/python-list
Re: question about True values
Paul Rubin wrote: > "John Coleman" <[EMAIL PROTECTED]> writes: > > > then "x == 3" is false, but "int(x) == 3" is true. > > But then why is 3.0 == 3 true? They are different types. > > The 3 gets converted to float, like when you say > > x = 3.1 + 3 > > the result is 6.1. Yes - it just seems that there isn't a principled reason for implicitly converting 3 to 3.0 in 3.0 == 3 but not implicitly converting "cat" to boolean in "cat" == true. There is something to be said about SML's rigourous approach where 3.0 = 3 isn't even allowed since it is considered ill-typed. Nevertheless, it is doubtlessly convientent to be able to compare integers and doubles directly in the natural way and there is little practical reason to compare a string with a truth value so Python's solution does have common sense on its side. -- http://mail.python.org/mailman/listinfo/python-list
Re: question about True values
Martin v. Löwis wrote: > John Coleman schrieb: > > Yes - it just seems that there isn't a principled reason for implicitly > > converting 3 to 3.0 in 3.0 == 3 but not implicitly converting "cat" to > > boolean in "cat" == true. > > Sure there is: equality should be transitive. So while we have > 3 == 3L == 3.0 == 3.0+0j > and can therefore imply that 3 == 3.0+0j, we should not get > 5 == True == ["foo"] > and therefore imply that 5 == ["foo"]. > > The phenomenon really exists only for numeric types (that two > values of different types still represent the same "thing"), > so it's not surprising that this doesn't readily extend to > other types. > > In Python, there are only very few similar cases: byte strings > and unicode strings sometimes compare equal (but, since 2.5, > don't compare unequal very often); lists and tuples could be > considered to have equal values, but don't actually do compare > equal. > > Regards, > Martin Very good point, though one could argue perhaps that when one is comparing an object with a truth value then one is implicitly asking for the truth value of that object i.e. how it would function if used in an if statement, etc. This would make code like 'if s: ' equivalent to 'if s == True:' with a possible gain in readability. But - as you demonstrate the cost of that (minimal) gain in readability would be too high. In any event - I think it is mostly bad style to use a non-boolean variable in 'if s:' - it reminds me too much of obscure C code (though others might disagree). -John Coleman -- http://mail.python.org/mailman/listinfo/python-list
Re: question about True values
Donn Cave wrote: > In article <[EMAIL PROTECTED]>, > "John Coleman" <[EMAIL PROTECTED]> wrote: > > > Very good point, though one could argue perhaps that when one is > > comparing an object with a truth value then one is implicitly asking > > for the truth value of that object > > On the contrary -- since there is normally no need to ever > compare an object with a truth value, then I would interpret > this usage as an attempt to distinguish True or False from > other objects in general. Some kind of placeholders for > missing values, who knows. I'm not saying it's a great idea, > but it could work in recent versions of Python. > > > This would make code like 'if s: ' equivalent > > to 'if s == True:' with a possible gain in readability. But - as you > > demonstrate the cost of that (minimal) gain in readability would be too > > high. In any event - I think it is mostly bad style to use a > > non-boolean variable in 'if s:' - it reminds me too much of obscure C > > code (though others might disagree). > > Others will indeed disagree. I don't think you'll find > much support for this position. But it's not as bad as > your notion that "if s == True", where s is not a boolean > object, might represent a gain in readability. That really > redefines readability. > >Donn Cave, [EMAIL PROTECTED] As far as readability goes - most computer languages have a surface syntax which is (by design) vaguely similiar to the syntax of a natural language like English. Thus statements roughly correspond to sentences. For example, you can see a subject-verb-object pattern in "x=3". Given a genuinely boolean construct like x < 2, "if x < 2:" *sounds* right to a human reader. Similarly, given a good boolean variable with a descriptive name like "found", the fragment "if found:" sounds ok. But - given a non-boolean variable like "product_name" - writing "if product_name:" sounds (to my ears) a little jarring - it sounds like a sentence fragment. It's like saying "If Bob" - If Bob *what*? Goes to the store? answers the telephone? Finish the damn thought! Now, if you were to (from some strange reason) use "product_name" as if it were a truth value then (to my ears) it would both make your intentions more clear and sound less fragmentary if you could say "if product_name == True:". When you use "product_name" as the condition of an if statement then in that context it is *functioning* as a truth value so (naively) what could be wrong with comparing it to a truth value? I don't advocate any change in Python here - just pointing out that the idea of allowing "if s:" and "if s == True:" to be always equivalent in the interest of readability isn't *that* strange. It doesn't constitute a redefinition of readability. As far as using non-booleans as conditions - I just think that if you want a certain block of code to be executed only if, for example, a list is non-empty, why not *say* so? I think "if my_list != []:" just reads better than "if my_list:". I would think that my preferences there mesh with "Explicit is better than implicit" but apparently not. I'm just starting out with Python with most of my programming in recent years being in various dialects of Visual Basic (which probably explains a lot). What attracts me to Python so far is the cool slice operations, the iterators, the libraries and the convience of programming in a REPL environment. So far, the ability to use "cat" as a part-time substitute for True just strikes me as a curiousity - but maybe that will change with time. -John Coleman -- http://mail.python.org/mailman/listinfo/python-list
Observation on "Core Python Programming"
Greetings, My copy of the second edition of Chun's "Core Python Programming" just arrived from Amazon on Friday. What really jumped out at me is an interesting feature about how it sequences its topics, namely, (user-defined) functions are not introduced until chapter 11, fully 400 pages into the book. This contrasts strongly with a traditional "Introduction to language X" book which has a chapter sequence roughy like: Chapter 1) Intro - Hello World Chapter 2) Variables Chapter 3) If, if-else Chapter 4) Loops Chapter 5) Functions and/or subroutines The exact details vary from book to book and language to language of course, but usually the above topics are covered in the first 100-150 pages since it is hard to do anything interesting until all of these tools are under your belt. Chun's book by contrast is able, on the strength of Python's built-in functions, to cover a fair amount of relatively interesting things (dictionaries, file IO, exception handling, etc.) before introducing user-defined functions. I don't want to read too much into this, but the mere fact that it is possible to write a Python book in this fashion seems to confirm the "batteries are included" philosophy of Python. Perhaps there is less need to learn how to roll your own batteries as soon as possible. -John Coleman -- http://mail.python.org/mailman/listinfo/python-list
Re: Observation on "Core Python Programming"
A is not ommitted from DBECAFG - it just appears in a non-standard order. If the book simply ommitted functions then it would be a shocking ommission. As it is, it is just a curious way of sequencing topics. Functions are in chapter 11 out of 23 chapters - sounds like the "core" of the book to me. Chun does emphasize the first-class status of functions in Python - something which is fairly important to me since I have dabbled on and off with functional programming the last few years (mostly SML) and am interested in seeing the extend to which Python is genuinely "multi-paradigm" - able to blend the functional and imperative (and OO) paradigms together. -John Coleman Nick Vatamaniuc wrote: > I would consider that an omission. Functions are very important in > Python. I think the user/reader should see the _def_ and _class_ > statement fairly soon in the introduction. The name of the book is > thus somewhat misleading, because functions are at the "core" of > Python. > > Functions should be right there with the integers, strings, files, > lists and dictionaries. Another important point to stress, in my > opinion, is that functions are first-class objects. In other words > functions can be passes around just like strings and numbers! > > -Nick Vatamaniuc > > > John Coleman wrote: > > Greetings, > >My copy of the second edition of Chun's "Core Python Programming" > > just arrived from Amazon on Friday. What really jumped out at me is an > > interesting feature about how it sequences its topics, namely, > > (user-defined) functions are not introduced until chapter 11, fully 400 > > pages into the book. This contrasts strongly with a traditional > > "Introduction to language X" book which has a chapter sequence roughy > > like: > > > > Chapter 1) Intro - Hello World > > Chapter 2) Variables > > Chapter 3) If, if-else > > Chapter 4) Loops > > Chapter 5) Functions and/or subroutines > > > > The exact details vary from book to book and language to language of > > course, but usually the above topics are covered in the first 100-150 > > pages since it is hard to do anything interesting until all of these > > tools are under your belt. Chun's book by contrast is able, on the > > strength of Python's built-in functions, to cover a fair amount of > > relatively interesting things (dictionaries, file IO, exception > > handling, etc.) before introducing user-defined functions. > > > > I don't want to read too much into this, but the mere fact that it is > > possible to write a Python book in this fashion seems to confirm the > > "batteries are included" philosophy of Python. Perhaps there is less > > need to learn how to roll your own batteries as soon as possible. > > > > -John Coleman -- http://mail.python.org/mailman/listinfo/python-list
Re: Observation on "Core Python Programming"
John Salerno wrote:
> John Coleman wrote:
> > Greetings,
> >My copy of the second edition of Chun's "Core Python Programming"
> > just arrived from Amazon on Friday.
>
> Who would you say the book is aimed at? Advanced programmers? I thought
> about getting it, but I'm not sure if it will be either 1) too much
> repetition of the basics I've already learned (which isn't necessarily a
> bad thing), or 2) too advanced for me right now.
>
> Thanks.
It strikes me as being aimed at intermediate programmers who don't have
much familiarity with Python. I bought it since my only other book on
Python ("Learning Python" by Lutz) is somewhat dated now and because I
find that I'm a slow learner and it usually takes me a couple of books
by independent authors to "get" a language. The publisher's page is
more informative than what you see on Amazon. You can see the table of
contents and read a sample chapter there to help you decide if the book
is for you:
http://vig.prenhall.com/catalog/academic/product/1,4096,0130260363,00.html
HTH
-John Coleman
--
http://mail.python.org/mailman/listinfo/python-list
Re: Observation on "Core Python Programming"
John Coleman wrote:
> John Salerno wrote:
> > John Coleman wrote:
> > > Greetings,
> > >My copy of the second edition of Chun's "Core Python Programming"
> > > just arrived from Amazon on Friday.
> >
> > Who would you say the book is aimed at? Advanced programmers? I thought
> > about getting it, but I'm not sure if it will be either 1) too much
> > repetition of the basics I've already learned (which isn't necessarily a
> > bad thing), or 2) too advanced for me right now.
> >
> > Thanks.
>
> It strikes me as being aimed at intermediate programmers who don't have
> much familiarity with Python. I bought it since my only other book on
> Python ("Learning Python" by Lutz) is somewhat dated now and because I
> find that I'm a slow learner and it usually takes me a couple of books
> by independent authors to "get" a language. The publisher's page is
> more informative than what you see on Amazon. You can see the table of
> contents and read a sample chapter there to help you decide if the book
> is for you:
> http://vig.prenhall.com/catalog/academic/product/1,4096,0130260363,00.html
>
> HTH
>
> -John Coleman
I just realized that I gave the link to the first edition site. The
second edition site doesn't give a sample chapter (but does give the
complete preface) and still provides a good feel for the book:
http://vig.prenhall.com/catalog/academic/product/0,1144,0132269937,00.html
Sorry for any confusion
-John Coleman
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python in sci/tech applications
Maybe I don't know what I'm looking for, but I downloaded Enthought a few days ago and don't seem to find MinGW on my system. There are 2 relatively small (totalling about 13 kb IIRC) *python* files deeply buried in the distribution with mingw in their filename but nothing like a gcc compiler. I've mostly used visual studio or code warrior for C compiling, so again - maybe I don't know what I am looking for. -John Coleman p.s. Pretty cool sig line - the older I get, the more enigmatic the world seems. I appreciate all of the effort that Enthought puts into their distribution. Robert Kern wrote: > Steve Holden wrote: > > Robert Kern wrote: > >> [EMAIL PROTECTED] wrote: > >> > >>> Robert Kern: > >>> > >>>> We distribute mingw set up to do this with our "Enthought > >>>> Edition" Python distribution. > >>>> http://code.enthought.com/enthon/ > >>> Sorry, maybe I'm blind but I don't see MinGW listed in that page... > >>> Maybe it's included but not listed... > >> > >> It's there. > >> > > Well I tend to believe you, but Firefox is calling you a liar: a search > > fails at "min". > > Sorry, by "it's there" I meant "it is actually included in the distribution > regardless of any omissions on the web page." > > > Do you anticipate a 2.5-based release any time soon? > > We'll start working on it soon, at least. > > -- > Robert Kern > > "I have come to believe that the whole world is an enigma, a harmless enigma > that is made terrible by our own mad attempt to interpret it as though it > had > an underlying truth." >-- Umberto Eco -- http://mail.python.org/mailman/listinfo/python-list
Re: Python in sci/tech applications
Robert Kern wrote: > John Coleman wrote: > > Maybe I don't know what I'm looking for, but I downloaded Enthought a > > few days ago and don't seem to find MinGW on my system. There are 2 > > relatively small (totalling about 13 kb IIRC) *python* files deeply > > buried in the distribution with mingw in their filename but nothing > > like a gcc compiler. I've mostly used visual studio or code warrior for > > C compiling, so again - maybe I don't know what I am looking for. > > It is in c:\Python24\Enthought\mingw32\, IIRC (I don't have it in front of > me). > Add c:\Python24\Enthought\mingw32\bin\ to your PATH environment variable, and > gcc.exe should be executable. > I have no such sub-directory. I'll try an uninstall-install. When I did the original installation the installer hung at the end and I had to manually close it. The Python interpreter was there and worked properly and all of the goodies like numby and chaco were there so I wrote it off as nothing more then a failure to close properly, but evidently I missed an essential part of the installation. -John Coleman > -- > Robert Kern > > "I have come to believe that the whole world is an enigma, a harmless enigma > that is made terrible by our own mad attempt to interpret it as though it > had > an underlying truth." >-- Umberto Eco -- http://mail.python.org/mailman/listinfo/python-list
Re: Python in sci/tech applications
John Coleman wrote: > Robert Kern wrote: > > John Coleman wrote: > > > Maybe I don't know what I'm looking for, but I downloaded Enthought a > > > few days ago and don't seem to find MinGW on my system. There are 2 > > > relatively small (totalling about 13 kb IIRC) *python* files deeply > > > buried in the distribution with mingw in their filename but nothing > > > like a gcc compiler. I've mostly used visual studio or code warrior for > > > C compiling, so again - maybe I don't know what I am looking for. > > > > It is in c:\Python24\Enthought\mingw32\, IIRC (I don't have it in front of > > me). > > Add c:\Python24\Enthought\mingw32\bin\ to your PATH environment variable, > > and > > gcc.exe should be executable. > > > I have no such sub-directory. I'll try an uninstall-install. When I did > the original installation the installer hung at the end and I had to > manually close it. The Python interpreter was there and worked properly > and all of the goodies like numby and chaco were there so I wrote it > off as nothing more then a failure to close properly, but evidently I > missed an essential part of the installation. > > -John Coleman Problem fixed. I had clicked on the 10-05-06 download (thinking that enthought_setup-1.1.0.msi led to the set up the full enthought package), but this is evidently only a partial download. I tried it a second time with the same results, but perhaps I wasn't using the "browse and install" option correctly (clicking that button on the enstaller caused a lot of files to be transfered, but there didn't seem to be any real list to browse). In any event, the August download worked like a charm and had it all, including mingw. Thanks for your help. -John Coleman -- http://mail.python.org/mailman/listinfo/python-list
Is Python a Zen language?
Greetings, I have a rough classification of languages into 2 classes: Zen languages and tool languages. A tool language is a language that is, well, a *tool* for programming a computer. C is the prototypical tool language. Most languages in the Algol family are tool languages. Visual Basic and Java are also tool languages. On the other hand, a Zen language is a language which is purported to transform your way of thinking about programming. Lisp, Scheme, Forth, Smalltalk and (maybe) C++ are Zen languages. Disciples acknowledge that it is difficult to pick up these languages but claim that, if you persevere, you sooner or later reach a state of computational satori in which it all makes sense. Interestingly enough, these languages often have books which approach scriptural status e.g. SICP for Scheme. So (assuming my classification makes sense) which is Python? The emphasis on simplicity and the beginner-friendly nature of it seems to put it in the tool category. On the other hand, the emphasis on the ONE TRUE WAY to accomplish most tasks and the tendency for participants in this newsgroup to criticize one another's code as being "unpythonic" seems to move it towards the Zen category. Of course, even tool languages have their idioms which the novice needs to pick up, so maybe this isn't decisive, but I detect an element of zeal in this newsgroup that I don't detect in (say) Excel VBA programming newsgroups. No value judgement is intended by my classification. There is no denying that Zen languages are often very powerful tools (for those who have reached satori) and that there is a Zen to really mastering, say, C. Personally, I have never been able to master any Zen language but can pick up tool languages fairly quickly, so I prefer tool languages. This is probably because I am not a programmer (I'm a mathematician who likes to program as a hobby and for numerical simulations) and so don't have the time to invest in picking up a Zen language. Hard-core hackers might presumably lean towards the Zen languages. Just curious -John Coleman -- http://mail.python.org/mailman/listinfo/python-list
Re: Is Python a Zen language?
Ron Stephens wrote: > Actually, Python has the distinction of being both a great tool > language *and* a great Zen language. That's what makes Python so cool > ;-))) > > Ron Stephens > Python411 > www.awaretek.com/python/index.html This would explain why the question is so hard to answer. It is a slam-dunk that Lisp is Zen and VBA is tool - but python really is a bit hard to classify. This is somewhat similar to the way that python seems to straddle the gap between imperative and functional languages. It has something from each worlds (whether it has the *best* from each world is a separate question) -John Coleman -- http://mail.python.org/mailman/listinfo/python-list
Re: Is Python a Zen language?
Bryan Olson wrote: > John Coleman wrote: > >I have a rough classification of languages into 2 classes: Zen > > languages and tool languages. A tool language is a language that is, > > well, a *tool* for programming a computer. C is the prototypical tool > > language. Most languages in the Algol family are tool languages. Visual > > Basic and Java are also tool languages. On the other hand, a Zen > > language is a language which is purported to transform your way of > > thinking about programming. Lisp, Scheme, Forth, Smalltalk and (maybe) > > C++ are Zen languages. > > I think that's a horrible classification. Every language is both. > "Transform your way of thinking" from what? There is no > distinguished canonical view of what a programming language looks > like, from which all others must be strange and wondrous > transformations. > > Lisp and Forth are not tools for programming a computer? Of course > they are. Algol and Java don't transform people's thinking about > programming? Nonsense. > > > -- > --Bryan You seem to have completly overlooked both the hedge word "rough" in my first sentence and the qualifications in my third paragraph. I probably was not sufficiently clear that I was describing some fairly sunjective impressions. It is a simple observation that devotees of the Scheme language view their language as more than *just* a tool for programming computers. To quote from the introduction to the first edition of SICP: "we want to establish the idea that a computer language is not just a way of getting a computer to perform operations but rather that it is a novel formal medium for expressing ideas about methodology" (http://mitpress.mit.edu/sicp/full-text/book/book.html). It is also a simple observation that experts in VBScript *don't* walk around talking like that. Scheme and VBScript are of course both Turing complete, but they seem to have radically different cultures. Do you disagree? Or, if you agree that there is a difference but don't like the words "Zen" vs. "tool" to describe it, how would you articulate the difference? Again, just curious. -John Coleman -- http://mail.python.org/mailman/listinfo/python-list
Re: Is Python a Zen language?
Crutcher wrote:
> You are a very silly person. You have tripped so many of my internet
> bullshit triggers that I think perhaps you are trolling. All languages
> alter the way you think. They structure the nature of questions you can
> ask, and problems you can solve.
>
> Do you understand 'Zen', by which I mean, have you devoted at least 5
> years of study (real, 5+ hrs/week studdy) to it? (btw, I have not). If
> your answer is no, then you are just using this to be cool.
>
> And if you can say 'no value judgment is intended by my
> classification', you have absolutely no right to talk about the nature
> of language, let alone go about labeling things 'Zen languages'.
> Honestly, classification is an act of valuation, it requires an
> introspective assesment of your personal language system. This stuff is
> _old_, not new, not novell.
>
> Go read a book.
> Like this one: http://www.aber.ac.uk/media/Documents/S4B/the_book.html
If appearing silly is the price of satisfying your curiousity then so
be it. I would, however, like to point out that there is a well
established usage of the word "Zen" in computer science. A trip to
almost any bookstore will unearth many books with titles like "Zen and
the Art of Cascading Style Sheets", etc. A similar usage appears with
the word "Tao", e.g., "The Tao of Objects". These usages seem to point
to a deep, intuitive understanding that eludes many beginners and is
difficult to put into words. My point is simply that, for some
languages L, "Zen and the art of L" or "The Tao of L" are plausible
titles ("Zen and the Art of Lisp Programming" would be plausible) but
for some languages they wouldn't ("The Tao of Fortran" ?) Do you
disagree? If you do, how would *you* articulate the difference in
culture between something like Scheme and something like Fortran?
I have no doubt that this usage of terms from Eastern Mysticism must be
annoying to someone such as yourself who has actually studied it, but
the genie can't be put back into the bottle. It is no longer really
plausible to be a purist regarding words like "Zen" or "Tao" - it just
makes you appear pedantic.
Hopefully I have tripped less of your "internet bullshit triggers" this
time. If not, you should really adjust your settings.
-John Coleman
--
http://mail.python.org/mailman/listinfo/python-list
Does '#hash' mean anything in IDLE?
Greetings, I am currently trying to learn Python through the excellent "Learning Python" book. I wrote my first non-trivial program, which began with several comment lines. One of the comment lines began with '#hash'. IDLE doesn't colorize it as a comment line but instead colors the word 'hash' in purple as if it were a key word. Wierd. The behavior seems easy to trigger: Just open up a new window in IDLE and enter these two lines: #This is a test #hash should still be a comment line Then, after saving, the second line is not colored as a comment line though the first is. Is this a bug, or do comment lines which begin with #hash have some special meaning? My program ran fine, so it seems that the interpreter itself is ignoring the line. -John Coleman -- http://mail.python.org/mailman/listinfo/python-list
Re: Does '#hash' mean anything in IDLE?
John Coleman wrote: > Greetings, >I am currently trying to learn Python through the excellent > "Learning Python" book. I wrote my first non-trivial program, which > began with several comment lines. One of the comment lines began with > '#hash'. IDLE doesn't colorize it as a comment line but instead colors > the word 'hash' in purple as if it were a key word. Wierd. The behavior > seems easy to trigger: Just open up a new window in IDLE and enter > these two lines: > > #This is a test > #hash should still be a comment line > > Then, after saving, the second line is not colored as a comment line > though the first is. > Is this a bug, or do comment lines which begin with #hash have some > special meaning? > My program ran fine, so it seems that the interpreter itself is > ignoring the line. > > -John Coleman It isn't just #hash, but also things like #dict, #int, #len at the start of a comment line which defeats IDLE's colorization algorithm. Interestingly, things like #while or #for behave as expected so it seems to be built-ins rather than keywords which are the problem. To answer my own question - this is pretty clearly a (harmless) bug. -John Coleman -- http://mail.python.org/mailman/listinfo/python-list
Re: Does '#hash' mean anything in IDLE?
John Salerno wrote:
> John Coleman wrote:
> > John Coleman wrote:
> >> Greetings,
> >>I am currently trying to learn Python through the excellent
> >> "Learning Python" book.
>
> me too!
>
> > It isn't just #hash, but also things like #dict, #int, #len at the
> > start of a comment line which defeats IDLE's colorization algorithm.
> > Interestingly, things like #while or #for behave as expected so it
> > seems to be built-ins rather than keywords which are the problem. To
> > answer my own question - this is pretty clearly a (harmless) bug.
>
> also notice that putting a space after # stops the problem
How do you like Python so far? I like dictionary objects the best so
far. I'm coming to Python from VBScript, so I already knew the value of
such things, but in Python they are better supported.
Here is the program I was talking about, which *really* shows the power
of dictionaries:
*
#Python program to discover word with most 1-word anagrams
#The following hash function has the property
#that words which are anagrams of each other
#hash to the same string. It assumes that input
#is lower case in range 'a' to 'z'
def letter_hash(word):
codes = 26 * [0]
for c in word:
codes[ord(c)-97] +=1
return_string = ''
for i in range(26):
j = codes[i]
if j > 0:
return_string += (str(j)+chr(i+97))
return return_string
#main program:
hashes = {}
#first load dictionary of hashes
for line in open('C:\\yawl.txt').readlines():
word = line.strip().lower() #to be safe
my_hash = letter_hash(word)
hashes.setdefault(my_hash,[]).append(word)
#now find word with most anagrams
max_len = 0
max_words = []
for word_list in hashes.itervalues():
if len(word_list) > max_len:
max_len = len(word_list)
max_words = word_list
print max_words
**
"yawl" stands for "Yet Another Word List". It is a text-list of some
240,000 English words, including all sorts of archaic and technical
phrases. Google for "yawl word list" if you want to track down a copy.
The output is
['apers', 'apres', 'asper', 'pares', 'parse', 'pears', 'prase',
'presa', 'rapes', 'reaps', 'spaer', 'spare', 'spear']
These 13 words are anagrams of each other. They contain some pretty
obscure words: asper is a 17th century Turkish coin and spaer is an
archaic Scottish-dialect word word for prophet (you can see "speaker"
if you squint).
-John Coleman
--
http://mail.python.org/mailman/listinfo/python-list
Re: Does '#hash' mean anything in IDLE?
Blackbird wrote: > John Coleman <[EMAIL PROTECTED]> skrev: > > > John Salerno wrote: > >> John Coleman wrote: > >>> John Coleman wrote: > >>>> Greetings, > >>>>I am currently trying to learn Python through the excellent > >>>> "Learning Python" book. > >> > >> me too! > >> > >>> It isn't just #hash, but also things like #dict, #int, #len at the > >>> start of a comment line which defeats IDLE's colorization algorithm. > >>> Interestingly, things like #while or #for behave as expected so it > >>> seems to be built-ins rather than keywords which are the problem. To > >>> answer my own question - this is pretty clearly a (harmless) bug. > >> > >> also notice that putting a space after # stops the problem > > > > How do you like Python so far? I like dictionary objects the best so > > far. I'm coming to Python from VBScript, so I already knew the value > > of such things, but in Python they are better supported. > > > > Here is the program I was talking about, which *really* shows the > > power of dictionaries: > > > > > > * > > > > #Python program to discover word with most 1-word anagrams > >[...] > > Nice! > > I think this simpler version of letter_hash should work too: > > def letter_hash(word): > w = [c for c in word] > w.sort() > return "".join(w) Nice suggestion. No need to actually count the multiplicity as long as you don't lose the information. Your function is much more readable than mine. -John Coleman -- http://mail.python.org/mailman/listinfo/python-list
Re: Does '#hash' mean anything in IDLE?
Scott David Daniels wrote: > John Coleman wrote: > > Blackbird wrote: > >> I think this simpler version of letter_hash should work too: > >> > >> def letter_hash(word): > >> w = [c for c in word] > >> w.sort() > >> return "".join(w) > > And, for 2.4 or later: > > def letter_hash(word): > return "".join(sorted(word)) > > sorted takes an iterable, and strings are iterables. > > --Scott David Daniels > [EMAIL PROTECTED] Impressive. It is this ability to create single expressions (like "".join(sorted(word))) which take the place of entire algorithms in other languages which I find one of the most striking features of Python. -John Coleman -- http://mail.python.org/mailman/listinfo/python-list
