Re: [Tutor] Efficiency of Doxygen on Python vs C++?

[ALAN GAULD]

> My friend clarifies: "It's not the efficiency of doxygen that's the 
> question. The problem is that you can add fields to objects as you go in 
> Python so you need to do a deep analysis of the code to determine the class 
> structure which you don't have to do with C++ (or Java)."

That's true itds one of the "benefits" of a dynamic language, but it does 
make the code harder to parse.

> He mentioned numbers like maybe ~20+x slower on lines-of-code 
> for Python vs C++.

That sounds high, I would have expected no more than 5-10 times longer.
But of course against that we have the advantage that there will be far fewer 
lines to parse in a Python project,  typically only a third or a quarter of 
the number of lines - sometimes less than that.

> A second friend of mine who is an XML/Java enthusiast echoed similar 
> comments about scalability in large builds with weakly-typed dynamic 
> languages such as Python.

The concept of a "large build" doesn't really exist in an interpreted 
language like Python. OTOH I probably wouldn't usePython for a 
very large project - say over a million lines of code in C++ - for a 
variety of other reasons. eg. Python could do it but the coordination of 
multi team projects becomes harder without tools like static type 
checking.

Alan G



___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Simple way to compare Two lists

[Alan Gauld]

"jim stockford" <[EMAIL PROTECTED]> wrote 

> Why is a dict lookup constant time. I.e. if there's a
> loop that walks a (shorter) list and compares each
> element with each element of a dict, what's going
> on to make this faster than an outer loop walking
> a list and an inner loop walking a second list?

A dict is essentially random access, the interpreter can 
find the item in a single jump(*) whereas with a list it 
must cycle through the entire list. So an 'in' check
with a dict is basically a single indexing operation. 
An 'in' check with a list is a pass through, on average, 
half the list.

Against that has to be factored the overhead of 
converting the big list to a dict of course. Where 
one list is much shorter than the other a loop check 
of the lists may work out faster but in most cases 
the dict check should win out.

Finally, the dict solution breaks down where there 
are multiple entries of the same value since a dict 
needs unique keys. If you had two lists with a high 
number of duplicate entries then it could give a 
false positive depending on your definition of how 
the comparison should work.

But as in all performance related issues, don't
optimise until you have a problem and use measurement 
to check results. 

(*) Actually hashing algorithms often wind up with a 
few entries against a hash node so it is a jump plus an 
iteration over a few elements. But it is only a few, on a 
thousand element dict you might find some nodes 
with two or three entries but not more.

-- 
Alan Gauld
Author of the Learn to Program web site
http://www.freenetpages.co.uk/hp/alan.gauld

___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Efficiency of Doxygen on Python vs C++?

[Alan Gauld]

"Stephen McInerney" <[EMAIL PROTECTED]> wrote

> Yes but it's still a canonical question about analysis of 
> weakly-typed
> dynamic languages, since my Java friend makes separate comments
> about scalability when analyzing large builds - he claims 1-5m lines 
> of
> code is a threshold.

There is no doubt that analyzing large projects in dynamic languages
(its not much to do with strong or weak typing IMHO) is always
more difficult than in classical static languages. There used to be 
huge
complaints about C because it needed a two-pass compiler whereas
Pascal was designed to be compiled in a single pass - one reason
Delphi can compete with VB in build speed!

However because of the expressive power of these languages you
very rarely get huge projects. Based on anecdotal evidence only I
doubt if thare are any Python projects with over 1m lines of code.
A 1m line Python project would be equivalent in function to a 5m+
line project in C++ or Java, and there aren't that many of those!
Also at these sizes execution speed usually becomes a priority
and interpreted languages are invariably slower in that area.

Once you get over 10 million lines (C++ eqiuiv)  the only languages
I've seen being used are C++, ADA and COBOL which are all
specifically designed for that scale of project. (There may be a
few big Java projects around but I've never seen one that size)
Also on projects this big the actual coding effort becomes
vanishingly small, often less than 10% of the total effort, whereas
on small projects coding can be as much as 30% or more.
So in small projects the choice of language has a much bigger impact.

Its an old fashioned enineering trade off - speed of construction v 
speed
of execution. And if analyzing code is of importance then that becomes
one more factor. In an increasing number of modern projects speed
of construction is top priority. (Ease of maintenance is another 
factor
too and interpreted languages also tend to win out there)

HTH,

-- 
Alan Gauld
Author of the Learn to Program web site
http://www.freenetpages.co.uk/hp/alan.gauld 


___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Opening Multiple Files

[Luke Paireepinart]

Paulo Quaglio wrote:
> Hi everyone,
> Thanks for all suggestions. Let me just preface this by saying that 
> I’m new to both python and programming. I started learning 3 months 
> ago with online tutorials and reading the questions you guys post. So, 
> thank you all very, very much…and I apologize if I’m doing something 
> really stupid..:-) OK. I’ve solved the problem of opening several 
> files to process “as a batch” with glob.glob(). Only now did I realize 
> that the program and files need to be in the same folder…. Now I have 
> another problem.
> 1- I want to open several files and count the total number of words. 
> If I do this with only 1 file, it works great. With several files ( 
> now with glob), it outputs the total count for each file individually 
> and not the whole corpus (see comment in the program below).
> 2- I also want the program to output a word frequency list (we do this 
> a lot in corpus linguistics). When I do this with only one file, the 
> program works great (with a dictionary). With several files, I end up 
> with several frequency lists, one for each file. This sounds like a 
> loop type of problem, doesn’t it? I looked at the indentations too and 
> I can’t find what the problem is. Your comments, suggestions, etc are 
> greatly appreciated. Thanks again for all your help. Paulo
> Here goes what I have.
I'm going to make some general observations as well as try to answer 
your original question.
> # The program is intended to output a word frequency list (including 
> all words in all files) and the total word count
> def sortfile(): # I created a function
I think analyze_corpus or something in this vein would be a better name, 
because this doesn't sort files as far as I can tell.
> filename = glob.glob('*.txt') # this works great! Thanks!
This is not really a file name but a list, so filelist would be more 
appropriate, or just files
> for allfiles in filename:
'allfiles' is not a very appropriate name. Each time through the loop, 
the variable 'allfiles' contains a different item from the 'filename' 
list. it doesn't contain all the files simultaneously. 'fileobj' or 
something of this sort would be better. 'file' is a reserved keyword, 
however.
> infile = open(allfiles, 'r')
> lines = list(infile)
It would be more clear to me what you're doing if you used the file 
object method 'readlines'
lines = infile.readlines()
This might also be more efficient, or it might be less efficient, or it 
might be doing the same thing.
readlines is what I usually see here, though.
> infile.close()
> words = [] # initializes list of words
> wordcounter = 0
> for line in lines:
here your iterator name is more appropriate, because it's singular 
(which it should be, because it's a single object it's bound to - 
exceptions would be when iterating over lists of lists, for example)
> line = line.lower() # after this, I have some clunky code to get rid 
> of punctuation
> words = words + line.split()
You should probably use the 'append' method of the list, 
words.append(line.split())
As far as removing punctuation, you can just build your whole words list 
in one line, like so:
words = [''.join([x for x in word if x.isalpha()]) for word in line.split()]
replace isalpha with isalnum if you want to match numbers too.
Note that this makes blank words as a side-effect. It's too late in the 
night for me to come up with a fix for this,
but you probably shouldn't use that list comprehension anyway, 
especially if you have no idea what it's doing.
> wordfreq = [words.count(wrd)for wrd in words] # counts the freq of 
> each word in a list
put a space between 'words.count(wrd)' and 'for' so it's clearer what's 
happening.
I'm assuming words.count is defined somewhere else that you didn't include?
I don't know if list comprehension is the best way to do this, because 
words could contain redundant entries.
> dictionary = dict(zip(words, wordfreq))
> frequency_list = [(dictionary[key], key)for key in dictionary]
Why do you need to make a dictionary here? why not just use the 
zip(words,wordfreq) directly?
> frequency_list.sort()
> frequency_list.reverse()
> for item in frequency_list:
> wordcounter = wordcounter + 1
> print item
> print "Total # of words:", wordcounter # this will give the word count 
> of the last file the program reads.
> print "Total # of words:", wordcounter # if I put it here, I get the 
> total count after each file
Don't just put it random places, think about what your loop is doing and 
how to fix the problem.
Your outer-most loop is looping over each file. within this loop you 
count the number of words in the file.
Logically, for a total tally of the number of words in all files, you'd 
have a variable defined before the start of the loop,
and then add the tally of each file's words to the total tally variable. 
Does this make sense? Can you figure out how to do this?

Not sure what your frequency problem is. Try to abstract what your code 
is doing to as high a level as yo

Re: [Tutor] Opening Multiple Files

[Alan Gauld]

"Paulo Quaglio" <[EMAIL PROTECTED]> wrote

>  I've solved the problem of opening several files to process "as a 
> batch"
> with glob.glob(). Only now did I realize that the program and files
> need to be in the same folder..

They don't but you do need to pass a valid path to open()
Thus if your code is running from folder X and the files
are in folder Y you need to tell open to open Y/filename
rather than just filename. Similarly you need to tell glob
to glob(Y/pattern)

The other possibility is to change the working directory to
Y using os.chdir(Y)

>   1- I want to open several files and count the total number of 
> words.
> If I do this with only 1 file, it works great. With several files 
> ( now with glob),
> it outputs the total count for each file individually and not the 
> whole corpus

So you will need to store that result in a variable and add the 
totals:
total = 0
for file in filelist:
result = linesInFile(file)
print file, ": ", result  # might not need/want this
total += result
print total

>   2- I also want the program to output a word frequency list
> (we do this a lot in corpus linguistics). When I do this with only 
> one file,
> the program works great (with a dictionary). With several files, I 
> end up
> with several frequency lists, one for each file.

Make the dictionary outside your loop and pass it into the full
analysis program:

# PSEUDO CODE ONLY!
words = {}
total = 0
for file in Flist
words, count = analyzeFile(file, words)
total += count
print total
for word in words:
   print word, ':', words[word]

def AnalyzeFile(f, w)
 linecount = 0
 for line in f:
 for word in line.split()
  w[word] = w.get(word,0) + 1
 return w,linecount

> This sounds like a loop type of problem, doesn't it?

No it sounds like a variable position problem, and possibly
a namespace issue too.

HTH,

-- 
Alan Gauld
Author of the Learn to Program web site
http://www.freenetpages.co.uk/hp/alan.gauld 


___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Efficiency of Doxygen on Python vs C++?

[Stephen McInerney]

Hi Alan,

> > My friend clarifies: "It's not the efficiency of doxygen that's the
> > question. The problem is that you can add fields to objects as you go in
> > Python so you need to do a deep analysis of the code to determine the 
>class
> > structure which you don't have to do with C++ (or Java)."
>
>That's true it's one of the "benefits" of a dynamic language, but it does
>make the code harder to parse.

Is this not just evidence of a very bad Python coding style?
Should we not always declare *all* class fields in the class definition
by assigning to them, even if the assignment is token or dummy
i.e. 'None', "", [], {} etc.

> > He mentioned numbers like maybe ~20+x slower on lines-of-code
> > for Python vs C++.
>
>That sounds high, I would have expected no more than 5-10 times longer.
>But of course against that we have the advantage that there will be far 
>fewer
>lines to parse in a Python project,  typically only a third or a quarter of
>the number of lines - sometimes less than that.

Can you cite us a literature source for saying that Python is 3-4x more
expressive  per line-of-code than C++?
Would come in handy for evangelizing.

> > A second friend of mine who is an XML/Java enthusiast echoed similar
> > comments about scalability in large builds with weakly-typed dynamic
> > languages such as Python.
>
>The concept of a "large build" doesn't really exist in an interpreted
>language like Python. OTOH I probably wouldn't usePython for a
>very large project - say over a million lines of code in C++ - for a
>variety of other reasons. eg. Python could do it but the coordination of
>multi team projects becomes harder without tools like static type
>checking.

Has anyone ever tried pragmas for hinting about member types as I suggested?

Stephen

_
A new home for Mom, no cleanup required. All starts here. 
http://www.reallivemoms.com?ocid=TXT_TAGHM&loc=us

___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Efficiency of Doxygen on Python vs C++?

[Duncan Gibson]

> Is this not just evidence of a very bad Python coding style?
> Should we not always declare *all* class fields in the class definition
> by assigning to them, even if the assignment is token or dummy
> i.e. 'None', "", [], {} etc.

this is one of the many things that pylint can warn you about.
It's like pychecker but customisable for your coding standards.
See http://www.logilab.org/project/eid/857

Cheers
Duncan
___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Efficiency of Doxygen on Python vs C++?

[Kent Johnson]

Stephen McInerney wrote:
> Hi Alan,
> 
>>> My friend clarifies: "It's not the efficiency of doxygen that's the
>>> question. The problem is that you can add fields to objects as you go in
>>> Python so you need to do a deep analysis of the code to determine the 
>> class
>>> structure which you don't have to do with C++ (or Java)."
>> That's true it's one of the "benefits" of a dynamic language, but it does
>> make the code harder to parse.
> 
> Is this not just evidence of a very bad Python coding style?
> Should we not always declare *all* class fields in the class definition
> by assigning to them, even if the assignment is token or dummy
> i.e. 'None', "", [], {} etc.

Not necessarily. Python *is* highly dynamic. It's not just limited to 
simple data attributes. Base classes can be determined at runtime, 
methods can be added to classes or redefined, metaclasses can do all 
kinds of magic, etc etc.

> Can you cite us a literature source for saying that Python is 3-4x more
> expressive  per line-of-code than C++?
> Would come in handy for evangelizing.

See http://wiki.python.org/moin/LanguageComparisons
The Prechelt paper is a research paper. Some of the other links provide 
examples where you can draw your own conclusions.

I have done a few comparisons of Python with Java here:
http://personalpages.tds.net/~kent37/stories/00017.html

Kent
___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Python Book Recommendations [Was:[Re: Security]]

[Chris Calloway]

bhaaluu wrote:
> Perhaps these concerns should be directed to either the
> maintainers of Python.Org ( http://python.org/ ), or to
> the author of the Software Carpentry Course?

I sent a pointer both to the lead maintainer (Dr. Greg Wilson at Univ. 
Toronto) and to Titus Brown who, along with Chris Lasher, is having a 
Software Carpentry sprint at SciPy'07 at Caltech tomorrow. So this is a 
timely observation. :) Titus wrote back that it "sure does sound wrong," 
so I would bet on it getting fixed tomorrow.

SWC has been around since 1998. It started as an 800KUSD Dept. of Energy 
project at Los Alamos for a design competition with cash prizes. It 
resulted in several tools including Roundup and SCons. It received 
27KUSD in funding from the PSF in 2006. It is taught to scientists at 
Univ of Toronto, Indiana Univ, and Caltech. Dr. Wilson wrote about it in 
the magazine of Sigma Xi:

http://www.americanscientist.org/template/AssetDetail/assetid/48548

It has moved around a lot. It's current official home is on scipy.org:

http://www.swc.scipy.org/

There are several links to older SWC URLs on python.org. None of them 
are in the wiki where they could be easily fixed, however.

-- 
Sincerely,

Chris Calloway
http://www.seacoos.org
office: 332 Chapman Hall   phone: (919) 962-4323
mail: Campus Box #3300, UNC-CH, Chapel Hill, NC 27599



___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Efficiency of Doxygen on Python vs C++?

[Eric Brunson]

Stephen McInerney wrote:
> Hi Alan,
>
>   
>>> My friend clarifies: "It's not the efficiency of doxygen that's the
>>> question. The problem is that you can add fields to objects as you go in
>>> Python so you need to do a deep analysis of the code to determine the 
>>>   
>> class
>> 
>>> structure which you don't have to do with C++ (or Java)."
>>>   
>> That's true it's one of the "benefits" of a dynamic language, but it does
>> make the code harder to parse.
>> 
>
> Is this not just evidence of a very bad Python coding style?
> Should we not always declare *all* class fields in the class definition
> by assigning to them, even if the assignment is token or dummy
> i.e. 'None', "", [], {} etc.
>
>   

Absolutely not.  I have several classes that build themselves 
dynamically at runtime.  As an example, one of them reads the data 
dictionary of a database.  You may as well suggest that you define all 
your dictionary keys at the beginning of the program.

>>> He mentioned numbers like maybe ~20+x slower on lines-of-code
>>> for Python vs C++.
>>>   
>> That sounds high, I would have expected no more than 5-10 times longer.
>> But of course against that we have the advantage that there will be far 
>> fewer
>> lines to parse in a Python project,  typically only a third or a quarter of
>> the number of lines - sometimes less than that.
>> 
>
> Can you cite us a literature source for saying that Python is 3-4x more
> expressive  per line-of-code than C++?
> Would come in handy for evangelizing.
>
>   
>>> A second friend of mine who is an XML/Java enthusiast echoed similar
>>> comments about scalability in large builds with weakly-typed dynamic
>>> languages such as Python.
>>>   
>> The concept of a "large build" doesn't really exist in an interpreted
>> language like Python. OTOH I probably wouldn't usePython for a
>> very large project - say over a million lines of code in C++ - for a
>> variety of other reasons. eg. Python could do it but the coordination of
>> multi team projects becomes harder without tools like static type
>> checking.
>> 
>
> Has anyone ever tried pragmas for hinting about member types as I suggested?
>
> Stephen
>
> _
> A new home for Mom, no cleanup required. All starts here. 
> http://www.reallivemoms.com?ocid=TXT_TAGHM&loc=us
>
> ___
> Tutor maillist  -  Tutor@python.org
> http://mail.python.org/mailman/listinfo/tutor
>   

___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Efficiency of Doxygen on Python vs C++?

[Alan Gauld]

"Stephen McInerney" <[EMAIL PROTECTED]> wrote
>>lines to parse in a Python project,  typically only a third or a 
>>quarter of
>>the number of lines - sometimes less than that.
>
> Can you cite us a literature source for saying that Python is 3-4x 
> more
> expressive  per line-of-code than C++?

I don't have any literature to hand that gives those figures but in
Code Complete (Sec 3.5) Steve McConnell gives siome relatie figures
which indicates that TurboBasic is about twice as effective as C per 
line
and given my experience comparing Python to TurboBasic I'd figure
Python to be at east twice as effective as TB.

On the two projects that I have done comparisons with Java the
ratio has been about 3 times less code in Python - but both small
samples - less than 1000 lines of Java, 300+ lines of Python.
And my one comparison with C++ gave a 5 fold improvement
but is not a fair comparison since much of the C++ was
providing class equivalents for Python dictionaries, which I
know I could have bought if I'd looked hard enough.

I think there are some studies of SmallTalk productivity which
suggested that ST was around 5 times more effective than C,
and I'd guess Python was nearly as effective as ST. So that
kind of ties in too, but still based mainly on my experience
I'm afraid.

Not much help but something.

Alan G. 


___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Efficiency of Doxygen on Python vs C++?

[Stephen McInerney]

Eric, you misunderstood my point.
I said you make a **token** assignment in the class defn simply
to do two things:
- 1) identify all the members in one place
- 2) annotate each member's type, as much as you can

e.g.:
class C
s = []
d = {}
ot = (None, None)

I didn't say you make the actual assignment. Obviously you can't
in most cases.

Regards,
Stephen


>From: Eric Brunson <[EMAIL PROTECTED]>

>>Is this not just evidence of a very bad Python coding style?
>>Should we not always declare *all* class fields in the class definition
>>by assigning to them, even if the assignment is token or dummy
>>i.e. 'None', "", [], {} etc.
>>
>>
>
>Absolutely not.  I have several classes that build themselves dynamically 
>at runtime.  As an example, one of them reads the data dictionary of a 
>database.  You may as well suggest that you define all your dictionary keys 
>at the beginning of the program.

_
A new home for Mom, no cleanup required. All starts here. 
http://www.reallivemoms.com?ocid=TXT_TAGHM&loc=us

___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Efficiency of Doxygen on Python vs C++?

[Alan Gauld]

"Stephen McInerney" <[EMAIL PROTECTED]> wrote

> Eric, you misunderstood my point.
> I said you make a **token** assignment in the class defn simply
> to do two things:
> - 1) identify all the members in one place
> - 2) annotate each member's type, as much as you can

I'm sure Eric can explain for himself but what I think he was saying
was that his classes define themselves at runtime. They read the
names of the fields and type information from the database metadata
and create the attributes accordingly. Thus he doesn't know what
his class attributes will be until the program runs. He may not even
know the names of his classes until he reads the database
tablenames.

This is exactly the kind of tricky coding that is possible in a 
dynamic
language which is next tio impossible in static compiled code, unless
you write your own 'little language interpreter' inside the compiled
program. This kind of abstract meta programming is extremely tricky
to get right but at least it's possible in something like Python.
But it makes analyzing the code very complex since much of the
working code is being created by the config code at runtime.

I've never actually tried this in Python but have done similar things
in Lisp. In C++ you usually have to create classes in advance for
every possible eventuality then use a factory class (or big switch
statement) to create the desitred instances. That's a lot of excess
code which is still less reliable and robust.

Of course I could be misreading Eric's intent...

Alan G. 


___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Python Book Recommendations [Was:[Re: Security]]

[wesley chun]

> > up to the object's
> > mutability on whether assignment to that object is possible.
>
> As long as I'm nitpicking...well, I guess I don't know what you mean by
> assignment to an object. Assignment is to names, not objects. There is
> nothing you can do in a function to bind a new object to a name in the
> caller.

nope, it's not as complicated as you've made it... i only meant to
describe that you can modify mutable objects (and not immutable ones).
 in other words, if you have myList = [1, 2, 3], you can say myList[0]
= 4.  i'm assigning integer 4 to the myList object as its 1st element
at index 0 -- that's what my wording meant.  i realized later that i
could have been more clear because of what you said, binding names to
objects. and yes, everyone needs to be more careful with their wording
as to not confuse others.

-- wesley
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
"Core Python Programming", Prentice Hall, (c)2007,2001
http://corepython.com

wesley.j.chun :: wescpy-at-gmail.com
python training and technical consulting
cyberweb.consulting : silicon valley, ca
http://cyberwebconsulting.com
___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Efficiency of Doxygen on Python vs C++?

[Eric Brunson]

We're definitely on the same wavelength, Alan.  :-)

Alan Gauld wrote:
> "Stephen McInerney" <[EMAIL PROTECTED]> wrote
>
>   
>> Eric, you misunderstood my point.
>> I said you make a **token** assignment in the class defn simply
>> to do two things:
>> - 1) identify all the members in one place
>> - 2) annotate each member's type, as much as you can
>> 
>
> I'm sure Eric can explain for himself but what I think he was saying
> was that his classes define themselves at runtime. They read the
> names of the fields and type information from the database metadata
> and create the attributes accordingly. Thus he doesn't know what
> his class attributes will be until the program runs. He may not even
> know the names of his classes until he reads the database
> tablenames.
>
> This is exactly the kind of tricky coding that is possible in a 
> dynamic
> language which is next tio impossible in static compiled code, unless
> you write your own 'little language interpreter' inside the compiled
> program. This kind of abstract meta programming is extremely tricky
> to get right but at least it's possible in something like Python.
> But it makes analyzing the code very complex since much of the
> working code is being created by the config code at runtime.
>
> I've never actually tried this in Python but have done similar things
> in Lisp. In C++ you usually have to create classes in advance for
> every possible eventuality then use a factory class (or big switch
> statement) to create the desitred instances. That's a lot of excess
> code which is still less reliable and robust.
>
> Of course I could be misreading Eric's intent...
>
> Alan G. 
>
>
> ___
> Tutor maillist  -  Tutor@python.org
> http://mail.python.org/mailman/listinfo/tutor
>   

___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Efficiency of Doxygen on Python vs C++?

[Stephen McInerney]

Oh ok, I see.

Yes I've also programmed classes that dynamically declare themselves
(mine was for XML parsing).

Presumably static analyzers like Doxygen etc. can't handle those so
they lie outside the scope of what we were discussing.

I was asking if it's a recognized good programming practice to
declare and initialize *all* members in the class defn.
I think I'm hearing a general yes on that - any other opinions?

Stephen

>From: Eric Brunson <[EMAIL PROTECTED]>
>To: Alan Gauld <[EMAIL PROTECTED]>
>CC: tutor@python.org
>Subject: Re: [Tutor] Efficiency of Doxygen on Python vs C++?
>Date: Fri, 17 Aug 2007 18:37:54 -0600
>
>
>We're definitely on the same wavelength, Alan.  :-)
>
>Alan Gauld wrote:
> > "Stephen McInerney" <[EMAIL PROTECTED]> wrote
> >
> >
> >> Eric, you misunderstood my point.
> >> I said you make a **token** assignment in the class defn simply
> >> to do two things:
> >> - 1) identify all the members in one place
> >> - 2) annotate each member's type, as much as you can
> >>
> >
> > I'm sure Eric can explain for himself but what I think he was saying
> > was that his classes define themselves at runtime. They read the
> > names of the fields and type information from the database metadata
> > and create the attributes accordingly. Thus he doesn't know what
> > his class attributes will be until the program runs. He may not even
> > know the names of his classes until he reads the database
> > tablenames.
> >
> > This is exactly the kind of tricky coding that is possible in a
> > dynamic
> > language which is next tio impossible in static compiled code, unless
> > you write your own 'little language interpreter' inside the compiled
> > program. This kind of abstract meta programming is extremely tricky
> > to get right but at least it's possible in something like Python.
> > But it makes analyzing the code very complex since much of the
> > working code is being created by the config code at runtime.
> >
> > I've never actually tried this in Python but have done similar things
> > in Lisp. In C++ you usually have to create classes in advance for
> > every possible eventuality then use a factory class (or big switch
> > statement) to create the desitred instances. That's a lot of excess
> > code which is still less reliable and robust.
> >
> > Of course I could be misreading Eric's intent...
> >
> > Alan G.
> >
> >
> > ___
> > Tutor maillist  -  Tutor@python.org
> > http://mail.python.org/mailman/listinfo/tutor
> >
>
>___
>Tutor maillist  -  Tutor@python.org
>http://mail.python.org/mailman/listinfo/tutor

_
Puzzles, trivia teasers, word scrambles and more. Play for your chance to 
win! http://club.live.com/home.aspx?icid=CLUB_hotmailtextlink

___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Efficiency of Doxygen on Python vs C++?

[Kent Johnson]

Stephen McInerney wrote:

> I was asking if it's a recognized good programming practice to
> declare and initialize *all* members in the class defn.

What do you mean by "initialize *all* members in the class defn"? Your 
original example was not syntactically correct Python. You wrote:

class C
s = []
d = {}
ot = (None, None)

If by this you meant to define all the variables at class scope:

class C:
   s = []
   d = {}
   ot = (None, None)

then I would say emphatically no, this is not even common practice, let 
alone a recognized best practice.

If you mean to initialize the variables in the __init__() method:
class C:
   def __init__(self):
 self.s = []
 self.d = {}
 self.ot = (None, None)

maybe this is more common but I don't think I have ever seen it 
recommended to initialize all variables in the __init__() method. 
Certainly there are times when it makes sense to have some of the 
initialization in other methods that are called from __init__(). So if 
by "recognized good programming practice" you mean something like 
"commonly recommended" I would say no, it is not.

 > I think I'm hearing a general yes on that - any other opinions?

Not sure where you think you are hearing a yes, I am hearing a lot of 
objections.

Kent
___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Python Book Recommendations [Was:[Re: Security]]

[Dick Moores]

At 08:19 AM 8/17/2007, Chris Calloway wrote:
>bhaaluu wrote:
> > Perhaps these concerns should be directed to either the
> > maintainers of Python.Org ( http://python.org/ ), or to
> > the author of the Software Carpentry Course?
>
>I sent a pointer both to the lead maintainer (Dr. Greg Wilson at Univ.
>Toronto) and to Titus Brown who, along with Chris Lasher, is having a
>Software Carpentry sprint at SciPy'07 at Caltech tomorrow. So this is a
>timely observation. :) Titus wrote back that it "sure does sound wrong,"
>so I would bet on it getting fixed tomorrow.
>
>SWC has been around since 1998. It started as an 800KUSD Dept. of Energy
>project at Los Alamos for a design competition with cash prizes. It
>resulted in several tools including Roundup and SCons. It received
>27KUSD in funding from the PSF in 2006. It is taught to scientists at
>Univ of Toronto, Indiana Univ, and Caltech. Dr. Wilson wrote about it in
>the magazine of Sigma Xi:
>
>http://www.americanscientist.org/template/AssetDetail/assetid/48548
>
>It has moved around a lot. It's current official home is on scipy.org:
>
>http://www.swc.scipy.org/
>
>There are several links to older SWC URLs on python.org. None of them
>are in the wiki where they could be easily fixed, however.

Chris, THANK YOU, especially for the link, .

My thanks also to Alan, Wesley, and bhaaluu. What a great list Tutor is!

An appreciative noob,

Dick Moores

___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

[Tutor] What is a "symbolic debugger"

[Dick Moores]

In the "Python Book Recommendations [Was:[Re: Security]]" thread, 
Chris Calloway included a link to the American Scientist article, 
"Where's the Real Bottleneck in Scientific Computing?". In that 
article I saw a term, "symbolic debugger", I  had been wondering 
about for a while. Google was of little help (to me, at least), and 
searching Wikipedia on "symbolic debugger" gets me the Debugger 
article "Redirected from Symbolic debugger". I'm beginning to think 
that the debugger I want to learn, WinPdb, is also a symbolic 
debugger, but what's "symbolic" about it?

Thanks,

Dick Moores


___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor