ANN:Dict4Ini 0.3 released!
This module is used to process ini format configuration file. It acts just like a dict, but you can also access it's sections and options with attribute syntax, just like x.test. == What's it features == * as simple as others * you can access options according to dict syntax, just like x['name']['o'] = 1, x['name'].keys(), x['name'].values(), etc. * you also can access options according to attr syntax, just like x.name.o = 1, x.name.keys(), x.name.values(), etc. So the name must be Identifier or single word. * you can save comments in it(but this feature is not tested so much) * support multi level section, subsection name will just like: [firsub/secsub] * can save config items order * support multi data types: string, unicode, int, float, list/tuple, dict, etc, you can save them to or regain them from config file * can convert to dict '''new''' * It's a little module, just for my mind, so if you like, you could try it, but if you don't like, just skip it, that's ok == Where can I download it? == * Visit the http://wiki.woodpecker.org.cn/moin/Dict4Ini site * Download it from here attachment:dict4ini.py == What's new? == * 2005/12/09 Version 0.3 * Adding dict() method, then you can change the DictIni object to dict type, so you can really use it as a dict alternative -- I like python! My Blog: http://www.donews.net/limodou NewEdit Maillist: http://groups.google.com/group/NewEdit -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations.html
Re: Proposal: Inline Import
Kent Johnson wrote: Shane Hathaway wrote: I'm talking about using imports *everywhere*. The penalty would be appreciable. Have you tried it? D:\Projects\CBpython -m timeit -s import re import re 100 loops, best of 3: 1.36 usec per loop You need a lot of imports before 1 usec becomes appreciable. Let me fully elaborate the heresy I'm suggesting: I am talking about inline imports on every other line of code. The obvious implementation would drop performance by a double digit percentage. And your proposal is doing the import anyway, just under the hood. How will you avoid the same penalty? The more complex implementation, which I suggested in the first message, is to maintain a per-module dictionary of imported objects (distinct from the global namespace.) This would make inline imports have almost exactly the same runtime cost as a global namespace lookup. But never mind, this proposal is a distraction from the real issue. See the next thread I'm starting. Shane -- http://mail.python.org/mailman/listinfo/python-list
Re: how to put form and display its result(data from database) on the same window?
Peter Hansen [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: I have designed a web application. In its one window I put a form. User can click submit button of this form to run a pathon script to get data from database. Then User get a new window which display the result. Now I want to put the form and display data on the same window. How I can do this? The most modern approach to this, and one which appears to be evolving into a defacto standard, is AJAX (see http://en.wikipedia.org/wiki/AJAX and others). It's a non-trivial solution to your problem, however, at least in terms of the learning curve involved. It's also a serious case of overkill for the rather simple problem he presented. All he needs is one function to create the form, and one function to create the results, and do: def PresentTable(): PrintTheForm() if i_have_received_data: PrintTheResultTable() -- - Tim Roberts, [EMAIL PROTECTED] Providenza Boekelheide, Inc. -- http://mail.python.org/mailman/listinfo/python-list
Re: newby question: Splitting a string - separator
James Stroud [EMAIL PROTECTED] wrote: The one I like best goes like this: py data = Guido van Rossum Tim Peters Thomas Liesner py names = [n for n in data.split() if n] py names ['Guido', 'van', 'Rossum', 'Tim', 'Peters', 'Thomas', 'Liesner'] I think it is theoretically faster (and more pythonic) than using regexes. But it is slower than this, which produces EXACTLY the same (incorrect) result: data = Guido van Rossum Tim Peters Thomas Liesner names = data.split() -- - Tim Roberts, [EMAIL PROTECTED] Providenza Boekelheide, Inc. -- http://mail.python.org/mailman/listinfo/python-list
Re: How to detect the presence of a html file
Irmen de Jong [EMAIL PROTECTED] wrote: BartlebyScrivener wrote: Even weirder, os.path.isfile(r'c://bookmarks.html') Never mind. It works that way from the command line, too. Never tried it before. Forward slashes as path separator only works on NTFS volumes I believe. Wrong. They work on all Microsoft operating systems back to at least MS-DOS 5, and on every version of Windows. The command interpreters don't accept them, but all of the APIs do. -- - Tim Roberts, [EMAIL PROTECTED] Providenza Boekelheide, Inc. -- http://mail.python.org/mailman/listinfo/python-list
Re: PHP = Perl Improved
Xah Lee [EMAIL PROTECTED] wrote: recently i got a project that involves the use of php. In 2 days, i read almost the entirety of the php doc. Finding it a breeze because it is roughly based on Perl, of which i have mastery. i felt a sensation of neatness, as if php = Perl Improved, for a dedicated job of server-side scripting. The design of the PHP language is not too bad, and the standard library is extensive. It is quite possible to write well-structured, class-based web programs with PHP. However, it seems that almost no one actually does so. Virtually all of the vast PHP code samples on the web are crap. Maybe the simplicity of the language encourages inexperienced programmers who write spaghetti code without a thought to the structure; I don't know the exact cause, but I have seen it more often than not. -- - Tim Roberts, [EMAIL PROTECTED] Providenza Boekelheide, Inc. -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie question - clearing screen @ interactive prompt
Hey matt, Thanks a ton! This works!! Have a great day Kaizer. -- http://mail.python.org/mailman/listinfo/python-list
Re: pyqt
Kuljo wrote: - Can I execute bash commands in a python script (e.g. ls -l or grep)? Yes, for instance with os.system or os.popen. It won't be portable though. - In the QT Designer there are also KDE-widgets but I'm not sucseeded to get them work in pyqt (it says: self.kProgress1 = KProgress(self,kProgress1) NameError: global name 'KProgress' is not defined). Are the not implemented there or I should install some additional software? PyKDE. -- Giovanni Bajo -- http://mail.python.org/mailman/listinfo/python-list
Re: Proposal: Inline Import
Shane Hathaway wrote: Benji York wrote: Why not: 1) jump to the top of the file when you need to do an import (1G in Vim), 2) add the import, 3) jump back to where you were (Ctrl-o in Vim) and keep coding. This isn't Vim specific, I suspect all decent editors have similar capabilities (I know Emacs does). Thus eliminating the unpleasant scan step. That's something the computer should do for me. It's busywork. Eclipse practically eliminates this busywork when I'm writing Java code: if I autocomplete a name, it also quietly adds the corresponding import statement. It also generates import statements when I copy/past e code. The structure of the Java language makes this relatively easy. And there's so much more busywork in Java that it's probably worth automating. See http://www.artima.com/weblogs/viewpost.jsp?thread=42242 In Python, it's harder to do autocompletion with the level of accuracy required for import statement generation. However, inline imports could eliminate the need to generate import statements. Oh, and py.std does something similar to what you want: http://codespeak.net/py/current/doc/misc.html#the-py-std-hook. Either form of inline import (py.std or my proposal) is a major idiomatic change. I can't be too much of a cowboy and start using idioms that are completely different from standard Python usage; my code would become unmaintainable. Thus a prerequisite for using inline import is broad approval. Shane Good luck. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC www.holdenweb.com PyCon TX 2006 www.python.org/pycon/ -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
Zeljko Vrba wrote:
On 2005-12-08, Steven D'Aprano [EMAIL PROTECTED] wrote:
Making a mistake in indentation level is precisely analogous to leaving
out markers in other languages. If your editor is smart enough, and the
But look at the following example:
if a:
some_code1
if b:
some_code2
If I accidentaly delete if b:, then some_code2 gets under the if a: which is
not intended. With braces (or other delimiters):
if(a) {
some_code1;
}
if(b) {
some_code2;
}
if I delete if(b) I get a syntax error about unmatched braces. IMO, the
right
way to handle braces in C is always to include them, even when they are not
technically obligatory. I code like that for a long time and it has saved me
a lot of headache.
My advice would be to stop using punch cards and start using a sensible
text editor. Your use case is somewhat unconvincing in the 21st century.
regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/
--
http://mail.python.org/mailman/listinfo/python-list
Managing import statements
Let's talk about the problem I really want help with. I brought up a proposal earlier, but it was only half serious. I realize Python is too sacred to accept such a heretical change. ;-) Here's the real problem: maintaining import statements when moving sizable blocks of code between modules is hairy and error prone. I move major code sections almost every day. I'm constantly restructuring the code to make it clearer and simpler, to minimize duplication, and to meet new requirements. To give you an idea of the size I'm talking about, just today I moved around 600 lines between about 8 modules, resulting in a 1400 line diff. It wasn't just cut-n-paste, either: nearly every line I moved needed adjustment to work in its new context. While moving and adjusting the code, I also adjusted the import statements. When I finished, I ran the test suite, and sure enough, I had missed some imports. While the test suite helps a lot, it's prohibitively difficult to cover all code in the test suite, and I had lingering doubts about the correctness of all those import statements. So I examined them some more and found a couple more mistakes. Altogether I estimate I spent 20% of my time just examining and fixing import statements, and who knows what other imports I missed. I'm surprised this problem isn't more familiar to the group. Perhaps some thought I was asking a newbie question. I'm definitely a newbie in the sum of human knowledge, but at least I've learned some tiny fraction of it that includes Python, DRY, test-first methodology, OOP, design patterns, XP, and other things that are commonly understood by this group. Let's move beyond that. I'm looking for ways to gain just a little more productivity, and improving the process of managing imports could be low-hanging fruit. So, how about PyDev? Does it generate import statements for you? I've never succeeded in configuring PyDev to perform autocompletion, but if someone can say it's worth the effort, I'd be willing to spend time debugging my PyDev configuration. How about PyLint / PyChecker? Can I configure one of them to tell me only about missing / extra imports? Last time I used one of those tools, it spewed excessively pedantic warnings. Should I reconsider? Is there a tool that simply scans each module and updates the import statements, subject to my approval? Maybe someone has worked on this, but I haven't found the right Google incantation to discover it. Shane -- http://mail.python.org/mailman/listinfo/python-list
Re: Proposal: Inline Import
Steve Holden wrote: Shane Hathaway wrote: The structure of the Java language makes this relatively easy. And there's so much more busywork in Java that it's probably worth automating. See http://www.artima.com/weblogs/viewpost.jsp?thread=42242 Agreed. Here's my take on Java vs. Python: http://hathawaymix.org/Weblog/2004-06-16 Shane -- http://mail.python.org/mailman/listinfo/python-list
Re: lambda (and reduce) are valuable
Alan aka David Isaac wrote: #evaluate polynomial (coefs) at x using Horner's rule def horner(coefs,x): return reduce(lambda a1,a2: a1*x+a2,coefs) It just cannot get simpler or more expressive. But is it correct? a0, a1, a2 = 1, 2, 3 x = 2 a0 + x*(a1 + x*(a2)) 17 def horner(coefs, x): return reduce(lambda a1, a2: a1*x + a2, coefs) ... horner([a0, a1, a2], x) 11 Are we merely employing different conventions for the order of coefficients or is that simple and expressive lambda/reduce stuff obscuring an error? Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: newby question: Splitting a string - separator
James Stroud wrote: py data = Guido van Rossum Tim Peters Thomas Liesner py names = [n for n in data.split() if n] py names ['Guido', 'van', 'Rossum', 'Tim', 'Peters', 'Thomas', 'Liesner'] I think it is theoretically faster (and more pythonic) than using regexes. Unfortunately it gives the wrong result. Just an example. Here is the correct version: names = [n for n in data.split( ) if n] where correct is still wrong, and theoretically faster means slightly slower (at least if fix your version, and precompile the pattern). /F -- http://mail.python.org/mailman/listinfo/python-list
Re: lambda (and reduce) are valuable
Peter Otten wrote: Alan aka David Isaac wrote: #evaluate polynomial (coefs) at x using Horner's rule def horner(coefs,x): return reduce(lambda a1,a2: a1*x+a2,coefs) It just cannot get simpler or more expressive. But is it correct? a0, a1, a2 = 1, 2, 3 x = 2 a0 + x*(a1 + x*(a2)) 17 def horner(coefs, x): return reduce(lambda a1, a2: a1*x + a2, coefs) ... horner([a0, a1, a2], x) 11 Are we merely employing different conventions for the order of coefficients or is that simple and expressive lambda/reduce stuff obscuring an error? I think horner needs the coefs be reversed, comparing with how we like to express polynomial in general, that is how I read those math formulas about horner anyway. -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
On 2005-12-10, Steve Holden [EMAIL PROTECTED] wrote:
My advice would be to stop using punch cards and start using a sensible
text editor.
Such as..?
Find me an editor which has folds like in VIM, regexp search/replace within
two keystrokes (ESC,:), marks to easily navigate text in 2 keystrokes (mx, 'x),
can handle indentation-level matching as well as VIM can handle {}()[], etc.
And, unlike emacs, respects all (not just some) settings that are put in its
config file. Something that works satisfactorily out-of-the box without having
to learn a new programming language/platform (like emacs).
--
http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
Zeljko Vrba enlightened us with:
Find me an editor which has folds like in VIM, regexp search/replace
within two keystrokes (ESC,:), marks to easily navigate text in 2
keystrokes (mx, 'x), can handle indentation-level matching as well
as VIM can handle {}()[], etc. And, unlike emacs, respects all (not
just some) settings that are put in its config file. Something that
works satisfactorily out-of-the box without having to learn a new
programming language/platform (like emacs).
Found it! VIM!
Sybren
--
The problem with the world is stupidity. Not saying there should be a
capital punishment for stupidity, but why don't we just take the
safety labels off of everything and let the problem solve itself?
Frank Zappa
--
http://mail.python.org/mailman/listinfo/python-list
Re: Encoding of file names
Tom Anderson wrote: This is a fact, but it is not a key thing. Of course Windows is applying a non-roundtrippable character encoding. What else could it do? Well, i'm no great thinker, but i'd say that errors should never pass silently, and that in the face of ambiguity, one should refuse the temptation to guess. So, as i said in my post, if the name couldn't be translated losslessly, an error should be raised. I believe this would not work, the way the API is structured. You do first FindFirstFile, getting a file name and a ahandle. Then you do FindNextFile repeatedly, passing the handle. An error of FindFirstFile is indicated by returning an invalid handle. So if you wanted FindFirstFile to return an error for unencodable file names, it would not be possible to get a listing of the other files in the directory. FindFirstFile also gives the 8.3 file name (if present), and that is valid without problems. Regards, Martin -- http://mail.python.org/mailman/listinfo/python-list
Re: Properties transfer between instances of different classes, without subclassing
Pierre wrote: Ideally, 'tabv.cold' would give me 'tabv', masked where the values are 10. I don't want to make 'Tabl' a subclass of 'Temp'. I'd like to use it more generically, so that when I define a 3rd class 'Color', I could initiate 'Tabv' with an instance of 'Color', accessing the 'Color' properties without the 'Temp' properties. I guess interfaces could make your day: http://www.zope.org/Products/ZopeInterface --- Heiko. -- http://mail.python.org/mailman/listinfo/python-list
Re: Documentation suggestions
A.M. Kuchling wrote: BThe associated text currently isn't very helpful, but I'm not sure how to make it better. Maybe it could be 'item-title', from 'dc:title' by dc:creator. Then the text for your file would be 'The zlib module', from '(the eff-bot guide to) The Standard Python Library' by Fredrik Lundh. that should work. if it turns out that this doesn't scale (has anyone put up that library reference wiki yet? ;-), you can always add an override option to the file that holds the seealso URL list. Can I safely treat the dc:identifier field as the URL for the work as a whole? Then I could turn the book title into a hyperlink. that should be safe. the DC documentation is a bit convoluted, but if I understand things correctly, the dc:identifier field should, by default, contain an URI. (doing a full type check involves checking the xsi:type attribute for dcterms:URI (evil!), but simply stripping the whitespace and checking that the rest starts with http://; should be good enough.) /F -- http://mail.python.org/mailman/listinfo/python-list
Re: Another newbie question
Mike Meyer wrote: And you've once again missed the point. The reason you don't manipulate the attributes directly is because it violates encapsulation, and tightens the coupling between your class and the classes it uses. It means you see the implementation details of the classes you are using, meaning that if that changes, your class has to be changed to match. One of Python's greatnesses is that a property is, for all means an purposes, a fully virtual instance attribute/member. If you follow the KISS principle, as long as your (naive? probably) implementation of the class has real attributes and their manipulation is meaningful makes sense from an external point of view, just leave it at that. If you happen to change the implementation for whatever reason and happen to remove the real attributes, just create virtual attributes with a property and be done with it. Wrapping everything just because you can and considering that encapsulation is only truly done if you never happen to touch what's under the hood (even without knowing it) is the Java Way, this is Python. In Python, the interface of an object instance is always virtualized because you can never know if you're manipulating real attributes or property-spawned virtual attributes. _that_, in my opinion, is not knowing about the implementation details. While a Java object is mineral (set in stone) and trying to abstract everything from the start (and generate 50 pages documentation for each class to be sure that you didn't miss anything) kind of makes sense, a Python object is an organic, morphing, living entity. Don't abstract everything and over-engineer from the start just because you can and because you'd do it in Java or C#, only abstract (from your point of view) when you *have to*. And remember that Java's Object Oriented Programming is not the only one worth using, even though some people would like to make you believe it. -- http://mail.python.org/mailman/listinfo/python-list
Re: Dr. Dobb's Python-URL! - weekly Python news and links (Dec 7)
skip wrote: Python has more web application frameworks than keywords. - Skip Montanaro (but probably others going back years) Cameron Incorrect. Thanks to Fredrik Lundh ... Yeah, I wondered about that. I was only parroting what I'd seen in Harald's post. I just couldn't remember who'd said it. the oldest reference I have is from june 2004: http://online.effbot.org/2004_06_01_archive.htm#europython-1 cheers /F -- http://mail.python.org/mailman/listinfo/python-list
Re: slice notation as values?
On 2005-12-09, Duncan Booth [EMAIL PROTECTED] wrote:
Antoon Pardon wrote:
If the user can write
for key in tree['a':'b']:
then he can write:
for key in tree['a':'b'].iteritems():
No he can't. tree['a':'b'] would provide a list
of keys that all start with an 'a'. Such a list
doesn't have an iteritems method. It wouldn't even
contain the information to construct items.
Why would it produce a list?
Correction, it produces an iterator.
Slicing a *list* produces a list, slicing a tuple produces a tuple, slicing
a string produces a string. I would expect slicing any other type would
also return you a new object of the same type.
But iterating over a list, tuple or string, give you the elements
of a list, tuple or string one by one. Iterating over a dict
doesn't give you the elements one by one, but only the keys.
In general I use slices over a tree because I only want to iterate
over a specific subdomain of the keys. I'm not iterested in make
a tree over the subdomain. Making such a subtree would be an
enormous waste of resources.
So even if we agree that tree['a':'b'] should create a subtree.
Then I still would want a way to iterate over a subdomain of
the keys in the tree without creating a subtree. Yes this
would create more than one way to do the same thing. But
this is already so with builtin dicts where a number of methods
give you different ways to do things, apparantly because
according to circumstances one is more efficient than the other.
So lets agree that tree['a':'b'] would produce a subtree. Then
I still would prefer the possibility to do something like:
for key in tree.iterkeys('a':'b')
Instead of having to write
for key in tree['a':'b'].iterkeys()
Sure I can now do it like this:
for key in tree.iterkeys('a','b')
But the way default arguments work, prevents you from having
this work in an analague way as a slice.
With slice notation you could have the following two cases:
for key in tree.iterkeys('a':)
for key in tree.iterkeys(:'b')
But you can't do
for key in tree.iterkeys('a',)
or more regrettably, you can't do:
for key in tree.iterkeys(,'b')
I also think that other functions could benefit. For instance suppose
you want to iterate over every second element in a list. Sure you
can use an extended slice or use some kind of while. But why not extend
enumerate to include an optional slice parameter, so you could do it as
follows:
for el in enumerate(lst,::2)
If you have an iterable, you sometime want to iterate over only a part
of it. The only way now to do so seems to be to either use a while
loop or create a second iterable over your limited domain and iterate
over the subiterable. I think it would be a an improvement if an
iterator could be constructed to just go over the subdomain within
your iterable. I also think that the most natural way to define
that subdomain would be by using slice notation.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
Re: subset permutations
Jay Parlar wrote: On Dec 8, 2005, at 5:29 PM, [EMAIL PROTECTED] wrote: Hello all, I'm a beginner with programming. Trying to teach myself with that excellent rat book. Unfortunately I just can't seem to figure out a simple problem that has come up at my work (biology lab): let's say I have a list ['A','C','D','E','F','G','H','I','K','L','M','N','P','Q','R','S','T','V ','W','Y'] . I need to generate permutations of this list. I have found plenty of code on the web to generate ALL possible permutations. What I need are all possible 4-letter permutations. I cannot seem to figure out how to modify Mike Davie's permutation generator http://www.bigbold.com/snippets/posts/show/753 to acheive this. Any help would be appreciated. The 'kSubsets' function here: http://www.gflanagan.net/site/python/05/kSubsetGenerator.html should give you the combinations, though how well it does so is another matter. (Only tested roughly). Then: import string choice = string.letters[26:] combinations = list(kSubsets(choice,4)) print combinations To get the permutations(no repeats) you can just permute each combination, for which the Permutation class here: http://www.gflanagan.net/site/python/05/Johnson.html might help. Eg. def kPerms( alist, k ): ... n = len(alist) ... for vector in nkRange(n,k): ... for perm in Permutation(vector): ... ret = [] ... for i in perm: ... ret.append( alist[i-1] ) ... yield ret ... x = list( kPerms(choice, 3) ) print x Gerard -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
Zeljko Vrba wrote:
On 2005-12-10, Steve Holden [EMAIL PROTECTED] wrote:
My advice would be to stop using punch cards and start using a sensible
text editor.
Such as..?
Since choice of text editor tends to be a religious issue, that will
have to be your decision, not mine.
Find me an editor which has folds like in VIM, regexp search/replace within
two keystrokes (ESC,:), marks to easily navigate text in 2 keystrokes (mx,
'x),
can handle indentation-level matching as well as VIM can handle {}()[], etc.
And, unlike emacs, respects all (not just some) settings that are put in its
config file. Something that works satisfactorily out-of-the box without having
to learn a new programming language/platform (like emacs).
Jusr choose one that minimises your propemsity to accidentally delete
lines.
regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/
--
http://mail.python.org/mailman/listinfo/python-list
Re: binascii.crc32 results not matching
Peter Hansen wrote: Larry Bates wrote: I'm trying to get the results of binascii.crc32 to match the results of another utility that produces 32 bit unsigned CRCs. What other utility? As Tim says, there are many CRC32s... the background notes on this one happen to stumble out at the top of the list in response to googling for zip file crc32 checksum polynomial, though I'm sure there are easier ways. The binascii docs say its CRC32 is compatible with the Zip file checksum, but they don't describe it further. Generally CRCs are described in terms of their polynomial, though just quoting that isn't sufficient to describe their behaviour, but if you happen to know the polynomial for your utility, someone else can probably point you to a more appropriate routine, or perhaps explain what you were doing wrong if the binascii one is actually the right one.. -Peter Check out the unit test in the following. http://sourceforge.net/projects/crcmod/ I went to a lot of trouble to get the results to match the results of binascii.crc32. As you will see, there are a couple of extra operations even after you get the polynomial and bit ordering correct. Ray -- http://mail.python.org/mailman/listinfo/python-list
Re: Managing import statements
On 12/10/05, Shane Hathaway [EMAIL PROTECTED] wrote: Let's talk about the problem I really want help with. I brought up a proposal earlier, but it was only half serious. I realize Python is too sacred to accept such a heretical change. ;-) Here's the real problem: maintaining import statements when moving sizable blocks of code between modules is hairy and error prone. I move major code sections almost every day. I'm constantly restructuring the code to make it clearer and simpler, to minimize duplication, and to meet new requirements. To give you an idea of the size I'm talking about, just today I moved around 600 lines between about 8 modules, resulting in a 1400 line diff. It wasn't just cut-n-paste, either: nearly every line I moved needed adjustment to work in its new context. You might want to invest in refactoring tools, like the ever-popular Bicycle Repair Man, which can help ensure that you rename things correctly. While moving and adjusting the code, I also adjusted the import statements. When I finished, I ran the test suite, and sure enough, I had missed some imports. While the test suite helps a lot, it's prohibitively difficult to cover all code in the test suite, and I had lingering doubts about the correctness of all those import statements. So I examined them some more and found a couple more mistakes. Altogether I estimate I spent 20% of my time just examining and fixing import statements, and who knows what other imports I missed. Both PyLint and PyChecker can detect missing imports (as well as redundant ones) for you. I'm surprised this problem isn't more familiar to the group. Perhaps some thought I was asking a newbie question. I'm definitely a newbie in the sum of human knowledge, but at least I've learned some tiny fraction of it that includes Python, DRY, test-first methodology, OOP, design patterns, XP, and other things that are commonly understood by this group. Let's move beyond that. I'm looking for ways to gain just a little more productivity, and improving the process of managing imports could be low-hanging fruit. It is probably because most people don't regularly switch that much code around, or use that many modules. I think the fact that you move that much code between modules is probably a code smell in and of itself - you're clearly moving and changing responsibilities. Refactoring in smaller chunks, less extreme refactoring, correcting the imports as you go, and avoiding inline imports without a really good reason will probably help you a lot more than a new syntax. So, how about PyDev? Does it generate import statements for you? I've never succeeded in configuring PyDev to perform autocompletion, but if someone can say it's worth the effort, I'd be willing to spend time debugging my PyDev configuration. PyDev will not generate import statements for you. How about PyLint / PyChecker? Can I configure one of them to tell me only about missing / extra imports? Last time I used one of those tools, it spewed excessively pedantic warnings. Should I reconsider? Yes. Spend an afternoon looking at PyLints options, get rid of the stuff you don't like, and use it regularly. PyDev has PyLint integration, which is nice. Is there a tool that simply scans each module and updates the import statements, subject to my approval? Maybe someone has worked on this, but I haven't found the right Google incantation to discover it. Assuming that you keep your global namespace pure, then you can do this yourself pretty simply. If you don't, there is no way for anything to know that you want symbol foo from module bar and not from module baz. I don't think I've ever imported more than a dozen modules into any given file. I rarely find it neccesary to move huge chunks of code between my modules - the biggest such I did was when I moved from a single-file proof of concept to a real modular structure, and that only took me an hour or so. If I'd done it modularly to start with it would have been fine. Shane -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: lambda (and reduce) are valuable
On 12/9/05, David Isaac [EMAIL PROTECTED] wrote: Jibes against the lambda-clingers lead eventually to serious questions of style in regard to variable namespacing, lifespan, cleanup, and so on: http://groups.google.com/group/comp.lang.python/browse_thread/thread/ad0e15cb6b8f2c32/ Alan Isaac [EMAIL PROTECTED] wrote: #evaluate polynomial (coefs) at x using Horner's rule def horner(coefs,x): return reduce(lambda a1,a2: a1*x+a2,coefs) Cameron Laird [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I *think* you're supporting a claim about the value of lambda with a specific example. Do I have that right? Are you saying that your definition of horner() would suffer greatly without lambda? It is a simple example of how lambda and reduce can be very expressive. Anyone who understands Horner's rule can see at a glance that this code implements it. Anyone who has bothered to learn what lambda and reduce do can see at a glance what the algorithm is. It just cannot get simpler or more expressive. Suffer greatly? Surely not. For suffer greatly you would probably need to turn to people who do a lot of event-driven GUI programming. But suffer, yes. Simplicity and expressiveness are valuable. That is the point. As someone who does a tremendous amount of event-driven GUI programming, I'd like to take a moment to speak out against people using us as a testament to the virtues of lamda. Event handlers are the most important part of event-driven code, and making them real functions with real names is crucial to maintainable code. The only reason to ever use a lamdba in Python is because you don't want to give a function a name, and that is just not a compelling use case for GUI events. Cheers, Alan Isaac -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: binascii.crc32 results not matching
Raymond L. Buvel wrote: Check out the unit test in the following. http://sourceforge.net/projects/crcmod/ I went to a lot of trouble to get the results to match the results of binascii.crc32. As you will see, there are a couple of extra operations even after you get the polynomial and bit ordering correct. Beautiful! -- http://mail.python.org/mailman/listinfo/python-list
Re: how to put form and display its result(data from database) on the same window?
Tim Roberts wrote: Peter Hansen [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: ... Now I want to put the form and display data on the same window. The most modern approach to this...is AJAX (see http://en.wikipedia.org/wiki/AJAX and others). It's a non-trivial solution to your problem, however, at least in terms of the learning curve involved. It's also a serious case of overkill for the rather simple problem he presented. All he needs is one function to create the form, and one function to create the results, and do: def PresentTable(): PrintTheForm() if i_have_received_data: PrintTheResultTable() Well, it's a matter of interpretation, isn't it? Given his vague requirements above, it's quite valid to assume that he wants to avoid the effects of the browser loading a new page, even if that page looks like the previous one a lot. You may be quite right in your *guess* that he doesn't need that, but there isn't enough information present in his request for either of us to know. (But you're quite correct *if he doesn't care about refreshing the window when the form is submitted* that Ajax is overkill. I should probably have asked for more detail in the question before suggesting Ajax.) -Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: Another newbie question
On Sat, 10 Dec 2005 01:28:52 -0500, Mike Meyer wrote: Steven D'Aprano [EMAIL PROTECTED] writes: On Thu, 08 Dec 2005 20:46:33 -0500, Mike Meyer wrote: Steven D'Aprano [EMAIL PROTECTED] writes: Paul Rubin wrote: Steven D'Aprano [EMAIL PROTECTED] writes: Yes. Reaching through objects to do things is usually a bad idea. I don't necessarily disagree, but I don't understand why you say this. Why it is bad? The traditional OOP spirit is to encapsulate the object's entire behavior in the class definition. Uh huh. Say I have: class Coordinate: def __init__(self, x=0.0, y=0.0): self.x = x self.y = y pt = Coordinate(1.0, 2.5) Presumably then I also need add_y_ord, sub_y_ord, rsub_y_ord, div_y_ord, and so on for every method that floats understand, plus *another* set of methods that do the same thing for the x ordinate. And in every case, these Coordinate methods are trivial one-liners. Do people really do this? Yes, but usually with better API design. For instance, your Coordinate class might have scale, translate, rotate and move methods. Which I obviously left as exercises for the reader. Did I really need to specify the entire API for an example like this? Given that we're talking about API design, then yes, you do. With only partial examples, you'll only get partial conclusions. I think you and I are coming at this problem from different directions. To my mind, the Coordinate class was complete in potentia, and did not need to be listed because I was not operating on a Coordinate instance as a whole. If you go back and look at my example, I was explicit about wanting to do something with a single ordinate, not a coordinate pair. Listing the entire API for the Coordinate class would be a waste of time, since I wasn't concerned about Coordinate.rotate(), Coordinate.reflect() or any other method applying to a coordinate pair. In particular, you can get most of your meaningless methods out of a properly designed Coordinate API. For example, add/sub_x/y_ord can all be handled with move(delta_x = 0, delta_y = 0). Here is my example again: [quote] Then, somewhere in my application, I need twice the value of the y ordinate. I would simply say: value = 2*pt.y [end quote] I didn't say I wanted a coordinate pair where the y ordinate was double that of the original coordinate pair. I wanted twice the y ordinate, which is a single real number, not a coordinate pair. [snip] And you've once again missed the point. The reason you don't manipulate the attributes directly is because it violates encapsulation, and tightens the coupling between your class and the classes it uses. It means you see the implementation details of the classes you are using, meaning that if that changes, your class has to be changed to match. Yes. And this is a potential problem for some classes. The wise programmer will recognise which classes have implementations likely to change, and code defensively by using sufficient abstraction and encapsulation to avoid later problems. The not-so-wise programmer takes abstraction as an end itself, and consequently spends more time and effort defending against events which almost certainly will never happen than it would have taken to deal with it if they did. Do you lie awake at nights worrying that in Python 2.6 sys.stdout will be renamed to sys.standard_output, and that it will no longer have a write() method? According to the law of Demeter, you should, and the writers of the sys module should have abstracted the fact that stdout is a file away by providing a sys.write_to_stdout() function. That is precisely the sort of behaviour which I maintain is unnecessary. The bad side of the Guideline of Demeter is that following it requires you to fill your class with trivial, unnecessary getter and setter methods, plus methods for arithmetic operations, and so on. No, it requires you to actually *think* about your API, instead of just allowing every class to poke around inside your implementation. But I *want* other classes to poke around inside my implementation. That's a virtue, not a vice. My API says: In addition to the full set of methods which operate on the coordinate as a whole, you can operate on the individual ordinates via instance.x and instance.y which are floats. Your API says: In addition to the full set of methods which operate on the coordinate as a whole, you can operate on the individual ordinates via methods add_x, add_y, mult_x, mult_y, sub_x, sub_y, rsub_x, rsub_y, div_x, div_y, rdiv_x, rdiv_y, exp_x, exp_y, rexp_x, rexp_y...; the APIs of these methods are: ... My class is written, tested and complete before you've even decided on your API. And you don't even really get the benefit of abstraction: I have two public attributes (x and y) that I can't change without breaking other people's code, you've got sixteen-plus methods that you can't change without breaking other people's code. (It goes without
Re: binascii.crc32 results not matching
[Raymond L. Buvel] Check out the unit test in the following. http://sourceforge.net/projects/crcmod/ Cool! I went to a lot of trouble to get the results to match the results of binascii.crc32. As you will see, there are a couple of extra operations even after you get the polynomial and bit ordering correct. Nevertheless, the purpose of binascii.crc32 is to compute exactly the same result as most zip programs give. All the details (including what look to you like extra operations ;-)) were specified by RFC 1952 (the GZIP file format specification). As a result, binascii.crc32 matches, e.g., the CRCs reported by WinZip on Windows, and gives the same results as zlib.crc32 (as implemented by the zlib developers). -- http://mail.python.org/mailman/listinfo/python-list
Re: binascii.crc32 results not matching
Tim Peters wrote: [Raymond L. Buvel] Check out the unit test in the following. http://sourceforge.net/projects/crcmod/ Cool! I went to a lot of trouble to get the results to match the results of binascii.crc32. As you will see, there are a couple of extra operations even after you get the polynomial and bit ordering correct. Nevertheless, the purpose of binascii.crc32 is to compute exactly the same result as most zip programs give. All the details (including what look to you like extra operations ;-)) were specified by RFC 1952 (the GZIP file format specification). As a result, binascii.crc32 matches, e.g., the CRCs reported by WinZip on Windows, and gives the same results as zlib.crc32 (as implemented by the zlib developers). Since there are probably others following this thread, it should be pointed out that the specification of those extra operations is to avoid some pathalogical conditions that you can get with a simplistic CRC operation. For example, using 0 as the starting value will give a value of zero for an arbitrary string of zeros. Consequently, a file starting with a string of zeros will have the same CRC as one with the zeros stripped off. While starting with 0x will give a non-zero value. -- http://mail.python.org/mailman/listinfo/python-list
newbie question
i have this program === from sys import * import math import math, Numeric from code import * from string import * from math import * from dataSet import * from string import * def drawAsciiFile(): _fileName=str(argv[1]) __localdataSet=DataSet(_fileName) #_PlotCols=string.split(str(argv[2]),' ') #_PlotColsInt=[] '''for s in _PlotCols: _PlotColsInt.append(int(s)) CountourPlots(__localdataSet,_PlotColsInt) ''' print __data=__localdataSet.GetData() print max(__data[:,11]) if __name__ == __main__: drawAsciiFile() how i can link it to read my file examle.txt? thanks michael -- http://mail.python.org/mailman/listinfo/python-list
Re: Documentation suggestions
I wrote: if it turns out that this doesn't scale (has anyone put up that library reference wiki yet? ;-) if anyone's interested, here's a seealso file for the python library reference: http://effbot.org/zone/seealso-python-library.xml this was generated from the global module index by this script: http://effbot.org/zone/seealso-python-library.htm still waiting for that wiki ;-) /F -- http://mail.python.org/mailman/listinfo/python-list
Re: slice notation as values?
Antoon Pardon wrote:
So lets agree that tree['a':'b'] would produce a subtree. Then
I still would prefer the possibility to do something like:
for key in tree.iterkeys('a':'b')
Instead of having to write
for key in tree['a':'b'].iterkeys()
Sure I can now do it like this:
for key in tree.iterkeys('a','b')
But the way default arguments work, prevents you from having
this work in an analague way as a slice.
How so? Can't you just pass the *args to the slice contstructor? E.g.::
def iterkeys(self, *args):
keyslice = slice(*args)
...
Then you can use the slice object just as you would have otherwise.
STeVe
--
http://mail.python.org/mailman/listinfo/python-list
Re: Another newbie question
On 2005-12-10, Steven D'Aprano [EMAIL PROTECTED] wrote: On Sat, 10 Dec 2005 01:28:52 -0500, Mike Meyer wrote: The not-so-wise programmer takes abstraction as an end itself, and consequently spends more time and effort defending against events which almost certainly will never happen than it would have taken to deal with it if they did. Do you lie awake at nights worrying that in Python 2.6 sys.stdout will be renamed to sys.standard_output, and that it will no longer have a write() method? According to the law of Demeter, you should, and the writers of the sys module should have abstracted the fact that stdout is a file away by providing a sys.write_to_stdout() function. I find this a strange interpretation. sys is a module, not an instance. Sure you can use the same notation and there are similarities but I think the differences are more important here. That is precisely the sort of behaviour which I maintain is unnecessary. The bad side of the Guideline of Demeter is that following it requires you to fill your class with trivial, unnecessary getter and setter methods, plus methods for arithmetic operations, and so on. No, it requires you to actually *think* about your API, instead of just allowing every class to poke around inside your implementation. But I *want* other classes to poke around inside my implementation. That's a virtue, not a vice. My API says: In addition to the full set of methods which operate on the coordinate as a whole, you can operate on the individual ordinates via instance.x and instance.y which are floats. Yikes. I would never do that. Doing so would tie my code unnecesary close to yours and would make it too difficult to change to an other class with a different implementation like one using tuples or lists instead of a seperate x and y instances. Your API says: In addition to the full set of methods which operate on the coordinate as a whole, you can operate on the individual ordinates via methods add_x, add_y, mult_x, mult_y, sub_x, sub_y, rsub_x, rsub_y, div_x, div_y, rdiv_x, rdiv_y, exp_x, exp_y, rexp_x, rexp_y...; the APIs of these methods are: ... Who in heavens name would need those? Maybe there is no x or y because the implementation uses a list or a tuple, maybe the implementation uses polar coordinates because that is more usefull for the application it was planned for. Sure a way to unpack your coordinate in a number of individual ordinate variables could be usefull for when you want to manipulate such an individual number. My class is written, tested and complete before you've even decided on your API. And you don't even really get the benefit of abstraction: I have two public attributes (x and y) that I can't change without breaking other people's code, you've got sixteen-plus methods that you can't change without breaking other people's code. No he would have none. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: slice notation as values?
Antoon Pardon wrote:
In general I use slices over a tree because I only want to iterate
over a specific subdomain of the keys. I'm not iterested in make
a tree over the subdomain. Making such a subtree would be an
enormous waste of resources.
Probably not unless you have really large data structures. If you have
something like a dbhash which would be inefficient to copy then both the
original view of the data structure and the slices could share the same
data. Creating a slice doesn't *have* to copy anything just so long as the
semantics are clear.
With slice notation you could have the following two cases:
for key in tree.iterkeys('a':)
for key in tree.iterkeys(:'b')
x['a':] is short for x['a':None]
x[:'b'] is short for x[None:'b']
But you can't do
for key in tree.iterkeys('a',)
or more regrettably, you can't do:
for key in tree.iterkeys(,'b')
If your datatype defines iterkeys to accept start and end arguments then
you can do:
for key in tree.iterkeys('a',None)
for key in tree.iterkeys(None,'b')
which is directly equivalent to the slices, or you can do:
for key in tree.iterkeys(start='a')
for key in tree.iterkeys(stop='b')
which is more explicit.
I also think that other functions could benefit. For instance suppose
you want to iterate over every second element in a list. Sure you
can use an extended slice or use some kind of while. But why not
extend enumerate to include an optional slice parameter, so you could
do it as follows:
for el in enumerate(lst,::2)
'Why not'? Because it makes for a more complicated interface for something
you can already do quite easily.
--
http://mail.python.org/mailman/listinfo/python-list
Re: slice notation as values?
On 2005-12-10, Steven Bethard [EMAIL PROTECTED] wrote:
Antoon Pardon wrote:
So lets agree that tree['a':'b'] would produce a subtree. Then
I still would prefer the possibility to do something like:
for key in tree.iterkeys('a':'b')
Instead of having to write
for key in tree['a':'b'].iterkeys()
Sure I can now do it like this:
for key in tree.iterkeys('a','b')
But the way default arguments work, prevents you from having
this work in an analague way as a slice.
How so? Can't you just pass the *args to the slice contstructor? E.g.::
def iterkeys(self, *args):
keyslice = slice(*args)
...
Then you can use the slice object just as you would have otherwise.
This doesn't work for a number of reasons,
1)
slice()
Traceback (most recent call last):
File stdin, line 1, in ?
TypeError: slice expected at least 1 arguments, got 0
2) It doens't give a clear way to indicate the following
kind of slice: tree.iterkeys('a':). Because of the
follwing:
slice('a')
slice(None, 'a', None)
which would be equivallent to tree.iterkeys(:'a')
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
Re: Another newbie question
Mike Meyer [EMAIL PROTECTED] wrote: ... it. Nothing you do with zim.foo or zim.foo.bar can change the state of zim. The only invariants you need to check are bar's, which you do at the exit to it's baz method. So foo's class is not allowed to have as its invariant any formula depending on the attributes of its attribute bar, such as bar.x23 or the like? Of course you can do such things. But it's a silly thing to do. That I guess this is the crux of our disagreement -- much like, it seems to me, your disagreement with Xavier and Steven on the other half of this thread, as I'll try to explain in the following. invariant should be written as x 23 for the class bar is an instance Let's, for definiteness, say that bar is an instance of class Bar. Now, my point is that absolutely not all instances of Bar are constrained to always have their x attribute 23 -- in general, their x's can vary all over the place; rather, the constraint applies very specifically to this one instance of Bar -- the one held by foo (an instance of Foo) as foo's attribute bar. Let's try to see if I can make a trivially simple use case. Say I'm using a framework to model statical structures in civil engineering. I have classes such as Truss, Beam, Pier, Column, Girder, and so forth. So in a given structure (class Foo) I might have a certain instance of Beam, attribute beam1 of instances of Foo, which carries a certain load (dependent on the overall loads borne by each given instance of Foo), and transfers it to an instance of Pier (attribute pier1 of instances of Foo) and one of Girder (attribute girder1 ditto). Each of these structural elements will of course be able to exhibit as attributes all of its *individual* characteristics -- but the exact manner of *relationship* between the elements depends on how they're assembled in a given structure, and so it's properly the business of the structure, not the elements. So, one invariant that had better hold to ensure a certain instance foo of Foo is not about to crash, may be, depending on how Foo's detailed structual geometry is, something like: foo.beam1.force_transferred_A = foo.pier1.max_load_top AND foo.beam1.force_transferred_B = foo.girder1.max_load_A The natural place to state this invariant is in class Foo, by expressing 'foo' as 'self' in Python (or omitting it in languages which imply such a lookup, of course). If I'm not allowed (because you think it's silly!) to express a class invariant in terms of attributes of the attributes of an instance of that class, I basically have to write tons of boilerplate, violating encapsulation, to express what are really attributes of attributes of foo as if they were attributes of foo directly, e.g. def beam1_force_transferred_A(): return beam1.force_transferred_A (or other syntax to the same purpose). After going through this pointless (truly silly) exercise I can finally code the invariant as self.beam1_force_transferred_A = self.pier1_max_load_top AND (etc). Changing a lot of dots into underscores -- what a way to waste programmer time! And all to NO advantage, please note, since: of. Invariants are intended to be used to check the state of the class, not the state of arbitary other objects. Doing the latter requires that you have to check the invariants of every object pretty much every time anything changes. ...in the end the invariant DOES have to be checked when anything relevant changes, anyway, with or without the silly extra indirection. But besides the wasted work, there is a loss of conceptual integrity: I don't WANT Foo to have to expose the internal details that beam1's reference point A transfers the force to pier1's top, etc etc, elevating all of these internal structural details to the dignity of attributes of Foo. Foo should expose only its externally visible attributes: loads and forces on all the relevant points, geometric details of the exterior, and structural parameters that are relevant for operating safety margins, for example. The point is that the internal state of an object foo which composes other objects (foo's attributes) beam1, pier1, etc, INCLUDES some attributes of those other objects -- thus stating that the need to check those attributes' relationships in Foo's class invariant is SILLY, strikes me as totally out of place. If the state is only of internal relevance, important e.g. in invariants but not to be externally exposed, what I think of as very silly instead is a style which forces me to build a lot of pseudoattributes of Foo (not to be exposed) by mindless delegation to attributes of attributes. Invariants are a tool. Used wisely, they make finding and fixing some logic bugs much easier than it would be otherwise. Used unwisely, they don't do anything but make the code bigger. I disagree, most intensely and deeply, that any reference to an attribute of an attribute of self in the body of an invariant is necessarily unwise. I'm also quite
Re: small inconsistency in ElementTree (1.2.6)
ascii strings and unicode strings are perfectly interchangable, with
some minor exceptions.
It's not only translate, it's decode too...
why would you use decode on the strings you get back from ET ?
Long story... some time ago when computers wouldn't support charsets
people
invented so called cyrillic fonts - ie a font that has cyrillic
glyphs
mapped on the latin posstions. Since our cyrillic alphabet has 31
characters, some characters in said fonts were mapped to { or ~ etc..
Of
course this ,,sollution is awful but it was the only one at the
time.
So I'm making a python script that takes an OpenDocument file and
translates
it to UTF-8...
ps. I use translate now, but I was making a general note that unicode
and
string objects are not 100% interchangeable. translate, encode, decode
are
especially problematic.
anyway, I wrap the output of ET in unicode() now... I don't see
another, better, sollution.
--
http://mail.python.org/mailman/listinfo/python-list
Re: newbie question
How about this: python your_program.py examle.txt Bermi wrote: how i can link it to read my file examle.txt? -- http://mail.python.org/mailman/listinfo/python-list
Re: Managing import statements
On Sat, 10 Dec 2005 02:21:39 -0700, Shane Hathaway [EMAIL PROTECTED] wrote: Let's talk about the problem I really want help with. I brought up a proposal earlier, but it was only half serious. I realize Python is too sacred to accept such a heretical change. ;-) Here's the real problem: maintaining import statements when moving sizable blocks of code between modules is hairy and error prone. I move major code sections almost every day. I'm constantly restructuring the code to make it clearer and simpler, to minimize duplication, and to meet new requirements. To give you an idea of the size I'm talking about, just today I moved around 600 lines between about 8 modules, resulting in a 1400 line diff. It wasn't just cut-n-paste, either: nearly every line I moved needed adjustment to work in its new context. While moving and adjusting the code, I also adjusted the import statements. When I finished, I ran the test suite, and sure enough, I had missed some imports. While the test suite helps a lot, it's prohibitively difficult to cover all code in the test suite, and I had I don't know about this :) lingering doubts about the correctness of all those import statements. So I examined them some more and found a couple more mistakes. Altogether I estimate I spent 20% of my time just examining and fixing import statements, and who knows what other imports I missed. I'm surprised this problem isn't more familiar to the group. Perhaps some thought I was asking a newbie question. I'm definitely a newbie in the sum of human knowledge, but at least I've learned some tiny fraction of it that includes Python, DRY, test-first methodology, OOP, design patterns, XP, and other things that are commonly understood by this group. Let's move beyond that. I'm looking for ways to gain just a little more productivity, and improving the process of managing imports could be low-hanging fruit. So, how about PyDev? Does it generate import statements for you? I've never succeeded in configuring PyDev to perform autocompletion, but if someone can say it's worth the effort, I'd be willing to spend time debugging my PyDev configuration. How about PyLint / PyChecker? Can I configure one of them to tell me only about missing / extra imports? Last time I used one of those tools, it spewed excessively pedantic warnings. Should I reconsider? I use pyflakes for this: http://divmod.org/trac/wiki/DivmodPyflakes. The *only* things it tells me about are modules that are imported but never used and names that are used but not defined. It's false positive rate is something like 1 in 10,000. Is there a tool that simply scans each module and updates the import statements, subject to my approval? Maybe someone has worked on this, but I haven't found the right Google incantation to discover it. This is something I've long wanted to add to pyflakes (or as another feature of pyflakes/emacs integration). Jean-Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
On Sat, 10 Dec 2005, Sybren Stuvel wrote:
Zeljko Vrba enlightened us with:
Find me an editor which has folds like in VIM, regexp search/replace
within two keystrokes (ESC,:), marks to easily navigate text in 2
keystrokes (mx, 'x), can handle indentation-level matching as well as
VIM can handle {}()[], etc. And, unlike emacs, respects all (not just
some) settings that are put in its config file. Something that works
satisfactorily out-of-the box without having to learn a new programming
language/platform (like emacs).
Found it! VIM!
ED IS THE STANDARD TEXT EDITOR.
tom
--
Argumentative and pedantic, oh, yes. Although it's properly called
correct -- Huge
--
http://mail.python.org/mailman/listinfo/python-list
Re: binascii.crc32 results not matching
Peter Hansen wrote:
Larry Bates wrote:
I'm trying to get the results of binascii.crc32
to match the results of another utility that produces
32 bit unsigned CRCs.
What other utility? As Tim says, there are many CRC32s... the
background notes on this one happen to stumble out at the top of the
list in response to googling for zip file crc32 checksum polynomial,
though I'm sure there are easier ways. The binascii docs say its CRC32
is compatible with the Zip file checksum, but they don't describe it
further.
Generally CRCs are described in terms of their polynomial, though just
quoting that isn't sufficient to describe their behaviour, but if you
happen to know the polynomial for your utility, someone else can
probably point you to a more appropriate routine, or perhaps explain
what you were doing wrong if the binascii one is actually the right one..
-Peter
It was a .DLL written by an employee that has long since
left the company. We want to move the code to Linux for
nightly checking of files. I don't know what to do but
post some long code. See below:
/
INCLUDES
/
#include windows.h
#include string.h
#include malloc.h
#include stdio.h
#include stdlib.h
#include filecrc.h
/
ModuleName: filecrc.c
Author: Syscon Computers - Modified by Barry Weck
Project:PowerBuilder External File CRC function
Date created: May. 18, 1999
Last Modified: Jun. 09, 1999
Module Owner: Syscon Computers
Module description:
This module implements a algorithm for calculating the CRC (Cyclic
Redundency Check) of a binary file. This function is meant to be
compiled as a 16 bit Microsoft Windows (Tm) DLL with either the 16 bit C
compilers of Borland or Microsoft. Compilation under other other
compilers has not been tested. The requirement of 16-bit DLL is
nessesitated by the version of PowerBuilder used by syscon.
This module was written by a third party and was then modified by
subcontractor Barry Weck. The code is copyrighted and owned by Syscon
Computers, Inc. of Tuscaloosa Alabama (C) 1999.
/
/
DATA
/
static unsigned long ccitt_32[256] =
{
0xUL, 0x77073096UL, 0xee0e612cUL, 0x990951baUL, 0x076dc419UL,
0x706af48fUL, 0xe963a535UL, 0x9e6495a3UL,
0x0edb8832UL, 0x79dcb8a4UL, 0xe0d5e91eUL, 0x97d2d988UL, 0x09b64c2bUL,
0x7eb17cbdUL, 0xe7b82d07UL, 0x90bf1d91UL,
0x1db71064UL, 0x6ab020f2UL, 0xf3b97148UL, 0x84be41deUL, 0x1adad47dUL,
0x6ddde4ebUL, 0xf4d4b551UL, 0x83d385c7UL,
0x136c9856UL, 0x646ba8c0UL, 0xfd62f97aUL, 0x8a65c9ecUL, 0x14015c4fUL,
0x63066cd9UL, 0xfa0f3d63UL, 0x8d080df5UL,
0x3b6e20c8UL, 0x4c69105eUL, 0xd56041e4UL, 0xa2677172UL, 0x3c03e4d1UL,
0x4b04d447UL, 0xd20d85fdUL, 0xa50ab56bUL,
0x35b5a8faUL, 0x42b2986cUL, 0xdbbbc9d6UL, 0xacbcf940UL, 0x32d86ce3UL,
0x45df5c75UL, 0xdcd60dcfUL, 0xabd13d59UL,
0x26d930acUL, 0x51de003aUL, 0xc8d75180UL, 0xbfd06116UL, 0x21b4f4b5UL,
0x56b3c423UL, 0xcfba9599UL, 0xb8bda50fUL,
0x2802b89eUL, 0x5f058808UL, 0xc60cd9b2UL, 0xb10be924UL, 0x2f6f7c87UL,
0x58684c11UL, 0xc1611dabUL, 0xb6662d3dUL,
0x76dc4190UL, 0x01db7106UL, 0x98d220bcUL, 0xefd5102aUL, 0x71b18589UL,
0x06b6b51fUL, 0x9fbfe4a5UL, 0xe8b8d433UL,
0x7807c9a2UL, 0x0f00f934UL, 0x9609a88eUL, 0xe10e9818UL, 0x7f6a0dbbUL,
0x086d3d2dUL, 0x91646c97UL, 0xe6635c01UL,
0x6b6b51f4UL, 0x1c6c6162UL, 0x856530d8UL, 0xf262004eUL, 0x6c0695edUL,
0x1b01a57bUL, 0x8208f4c1UL, 0xf50fc457UL,
0x65b0d9c6UL, 0x12b7e950UL, 0x8bbeb8eaUL, 0xfcb9887cUL, 0x62dd1ddfUL,
0x15da2d49UL, 0x8cd37cf3UL, 0xfbd44c65UL,
0x4db26158UL, 0x3ab551ceUL, 0xa3bc0074UL, 0xd4bb30e2UL, 0x4adfa541UL,
0x3dd895d7UL, 0xa4d1c46dUL, 0xd3d6f4fbUL,
0x4369e96aUL, 0x346ed9fcUL, 0xad678846UL, 0xda60b8d0UL, 0x44042d73UL,
0x33031de5UL, 0xaa0a4c5fUL, 0xdd0d7cc9UL,
0x5005713cUL, 0x270241aaUL, 0xbe0b1010UL, 0xc90c2086UL, 0x5768b525UL,
0x206f85b3UL, 0xb966d409UL, 0xce61e49fUL,
0x5edef90eUL, 0x29d9c998UL, 0xb0d09822UL, 0xc7d7a8b4UL, 0x59b33d17UL,
0x2eb40d81UL, 0xb7bd5c3bUL, 0xc0ba6cadUL,
0xedb88320UL, 0x9abfb3b6UL, 0x03b6e20cUL, 0x74b1d29aUL, 0xead54739UL,
0x9dd277afUL, 0x04db2615UL, 0x73dc1683UL,
0xe3630b12UL, 0x94643b84UL, 0x0d6d6a3eUL, 0x7a6a5aa8UL, 0xe40ecf0bUL,
0x9309ff9dUL, 0x0a00ae27UL, 0x7d079eb1UL,
0xf00f9344UL, 0x8708a3d2UL, 0x1e01f268UL, 0x6906c2feUL, 0xf762575dUL,
0x806567cbUL, 0x196c3671UL, 0x6e6b06e7UL,
0xfed41b76UL, 0x89d32be0UL, 0x10da7a5aUL, 0x67dd4accUL, 0xf9b9df6fUL,
0x8ebeeff9UL, 0x17b7be43UL, 0x60b08ed5UL,
0xd6d6a3e8UL, 0xa1d1937eUL, 0x38d8c2c4UL,
Re: slice notation as values?
On 2005-12-10, Duncan Booth [EMAIL PROTECTED] wrote:
Antoon Pardon wrote:
In general I use slices over a tree because I only want to iterate
over a specific subdomain of the keys. I'm not iterested in make
a tree over the subdomain. Making such a subtree would be an
enormous waste of resources.
Probably not unless you have really large data structures. If you have
something like a dbhash which would be inefficient to copy then both the
original view of the data structure and the slices could share the same
data. Creating a slice doesn't *have* to copy anything just so long as the
semantics are clear.
With slice notation you could have the following two cases:
for key in tree.iterkeys('a':)
for key in tree.iterkeys(:'b')
x['a':] is short for x['a':None]
x[:'b'] is short for x[None:'b']
That is beside the point. The user doesn't have to know that
in order to use slices. In point of fact I think that if
tomorrow they changed the default to something different
not a single program would break.
But you can't do
for key in tree.iterkeys('a',)
or more regrettably, you can't do:
for key in tree.iterkeys(,'b')
If your datatype defines iterkeys to accept start and end arguments then
you can do:
for key in tree.iterkeys('a',None)
for key in tree.iterkeys(None,'b')
which is directly equivalent to the slices, or you can do:
for key in tree.iterkeys(start='a')
for key in tree.iterkeys(stop='b')
which is more explicit.
Yes we could do all that. The question remains why we should burden
the user with all this extra information he has to know now in order
to use this method, while there is a clear notation he can use
without all this.
The user doesn't has to type:
lst[5:None] or lst[None:7],
Neither has he to type something like
lst[start=5] or lst[stop=7]
There are circumstances when the user needs to provide slice
information to a function. Why not allow him to use the
same notation as he can use in subscribtion. What reason
is there to limit a specific notation for a value to
specific circumstances. To me this looks as arbitrary
as would bracket notation not be allowed as an argument
but that you would be obligated to use list((a,b,...)) in
calls instead of [a,b,...]
It wouldn't prevent you to do anything from what you can
do now with python, it would only make a number of things
unnecesary cumbersome.
So yes, my proposal will not allow you to do anything you
can;t already do now. It would just allow you to do a number
of things in a less cumbersome way.
I also think that other functions could benefit. For instance suppose
you want to iterate over every second element in a list. Sure you
can use an extended slice or use some kind of while. But why not
extend enumerate to include an optional slice parameter, so you could
do it as follows:
for el in enumerate(lst,::2)
'Why not'? Because it makes for a more complicated interface for something
you can already do quite easily.
Do you think so? This IMO should provide (0,lst[0]), (2,lst[2]),
(4,lst[4]) ...
I haven't found a way to do this easily. Except for something like:
start = 0:
while start len(lst):
yield start, lst[start]
start += 2
But if you accept this, then there was no need for enumerate in the
first place. So eager to learn something new, how do you do this
quite easily?
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
problems binding a dictionary
this has to be a very silly thing. I have a function foo taking a dictionary as parameters. i.e.: def foo(**kwargs): pass when I call foo(param1='blah',param2='bleh',param3='blih') everything is fine. but when I do: def foo(**kwargs): ... pass ... d=dict(param1='blah',param2='bleh',param3='blih') foo(d) I get: Traceback (most recent call last): File stdin, line 1, in ? TypeError: foo() takes exactly 0 arguments (1 given) Why? how do I pass the dictionary *d* to foo()? Thanks, - Josh. -- http://mail.python.org/mailman/listinfo/python-list
Re: Thoughts on object representation in a dictionary
py [EMAIL PROTECTED] writes: Well the other thing is that I am allowed to store strings in this dictionary...so I can't just store the Engine and Body object and later use them. this is just a requirement (which i dont understand either)...but its what I have to do. Probably so that the object store can later be moved offline, with the shelve module or DB API or something like that. So my question is there a good way of storing this information in a nested dictionary such that if I receive this dictionary I could easily pull it apart and create Engine and Body objects with the information? Any suggestions at all? keep in mind I am limited to using a dictionary of strings...thats it. The spirit of the thing would be serialize the objects, maybe with cPickle, as Steven suggests. A kludgy way to thwart the policy might be to store the objects in a list instead of a dictionary: x[0], x[1], etc. Then have a dictionary mapping keys to subscripts in the list. The subscripts would be stringified ints: '0','1',... . -- http://mail.python.org/mailman/listinfo/python-list
Re: problems binding a dictionary
[EMAIL PROTECTED] wrote: this has to be a very silly thing. I have a function foo taking a dictionary as parameters. i.e.: def foo(**kwargs): pass when I call foo(param1='blah',param2='bleh',param3='blih') everything is fine. but when I do: def foo(**kwargs): ... pass ... d=dict(param1='blah',param2='bleh',param3='blih') foo(d) I get: Traceback (most recent call last): File stdin, line 1, in ? TypeError: foo() takes exactly 0 arguments (1 given) Why? how do I pass the dictionary *d* to foo()? Thanks, - Josh. I mean, short of defining as foo(*args), or foo(dict). -- http://mail.python.org/mailman/listinfo/python-list
Re: problems binding a dictionary
You're not 'exploding' the dict to the param1='blah' etc form - you-re actually passing it in as a single dict object. To solve this, add a ** to the front of a dict you want to explode in a function, just as you'd add a * to explode a sequence. -- http://mail.python.org/mailman/listinfo/python-list
Re: binascii.crc32 results not matching
Larry Bates wrote: def CalculateCrc(buffer, crc): /snip/ The algorithm looks very much like the source code for binascii.crc32 (but I'm not a C programmer). does your Python version give the right result ? if so, the following might be somewhat helpful: def test1(text, crc=0): # larry's code result = CalculateCrc(text, crc) return hex(result[0]) def test2(text, crc=0): import Image # using pil's crc32 api a = (crc 16) ^ 65535 b = (crc 65535) ^ 65535 a, b = Image.core.crc32(text, (a, b)) a ^= 65535 b ^= 65535 return 0x%04X%04XL % (a, b) def test(text): print test1(text), test2(text) test(hello) test(goodbye) this prints 0xF032519BL 0xF032519BL 0x90E3070AL 0x90E3070AL no time to sort out the int/long mess for binascii.crc32, but it pro- bably needs the same tweaking as PIL (which handles the CRC as two 16-bit numbers, to avoid sign hell). /F -- http://mail.python.org/mailman/listinfo/python-list
Re: Proposal: Inline Import
Shane Hathaway [EMAIL PROTECTED] writes: Let me fully elaborate the heresy I'm suggesting: I am talking about inline imports on every other line of code. The obvious implementation would drop performance by a double digit percentage. No, it wouldn't. The semantics of import pretty much require that the drop in performance would most likely be negligible. And your proposal is doing the import anyway, just under the hood. How will you avoid the same penalty? The more complex implementation, which I suggested in the first message, is to maintain a per-module dictionary of imported objects (distinct from the global namespace.) This would make inline imports have almost exactly the same runtime cost as a global namespace lookup. If you put an import near every reference to a module, then each import would have almost exactly the same runtime cost as a global namespace lookup. Your per-module dictionary of imported object doesn't represent a significant improvement in module lookup time. The extra cost comes from having to look up the module in the namespace after you import it. However, the actual import has at most the same runtime cost as looking up the module name, and may cost noticably less. These costs will be swamped by the lookup cost for non-module symbols in most code. If looking up some symbols is a noticable part of your run-time the standard fix is to bind the objects you are finding into your local namespace. Import already allows this, with from foo import bar. That will make references to the name run as much fater than your proposed inline import than it runs faster than doing an import before every line that references a module. In summary, the performance hit from doing many imports may be significant compared to the cost only doing one import, but that still represents only a small fraction of the total runtime of most code. In the cases where that isn't the case, we already have a solution available with better performance than any of the previously discussed methods. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Another newbie question
Steven D'Aprano [EMAIL PROTECTED] writes: In particular, you can get most of your meaningless methods out of a properly designed Coordinate API. For example, add/sub_x/y_ord can all be handled with move(delta_x = 0, delta_y = 0). Here is my example again: [quote] Then, somewhere in my application, I need twice the value of the y ordinate. I would simply say: value = 2*pt.y [end quote] I didn't say I wanted a coordinate pair where the y ordinate was double that of the original coordinate pair. I wanted twice the y ordinate, which is a single real number, not a coordinate pair. Here you're not manipulating the attribute to change the class - you're just using the value of the attribute. That's what they're there for. And you've once again missed the point. The reason you don't manipulate the attributes directly is because it violates encapsulation, and tightens the coupling between your class and the classes it uses. It means you see the implementation details of the classes you are using, meaning that if that changes, your class has to be changed to match. Yes. And this is a potential problem for some classes. The wise programmer will recognise which classes have implementations likely to change, and code defensively by using sufficient abstraction and encapsulation to avoid later problems. Except only the omniscennt programmer can do that perfectly. The experienced programmers knows that requiments change over the lifetime of a project, including things that the customer swears on a stack of holy books will never change. Do you lie awake at nights worrying that in Python 2.6 sys.stdout will be renamed to sys.standard_output, and that it will no longer have a write() method? According to the law of Demeter, you should, and the writers of the sys module should have abstracted the fact that stdout is a file away by providing a sys.write_to_stdout() function. That is precisely the sort of behaviour which I maintain is unnecessary. And that's not the kind of behavior I'm talking about here, nor is it the kind of behavior that the LoD is designed to help you with (those are two different things). The bad side of the Guideline of Demeter is that following it requires you to fill your class with trivial, unnecessary getter and setter methods, plus methods for arithmetic operations, and so on. No, it requires you to actually *think* about your API, instead of just allowing every class to poke around inside your implementation. But I *want* other classes to poke around inside my implementation. That's a virtue, not a vice. My API says: In addition to the full set of methods which operate on the coordinate as a whole, you can operate on the individual ordinates via instance.x and instance.y which are floats. That's an API which makes changing the object more difficult. It may be the best API for the case at hand, but you should be aware of the downsides. Your API says: Actually, this is *your* API. In addition to the full set of methods which operate on the coordinate as a whole, you can operate on the individual ordinates via methods add_x, add_y, mult_x, mult_y, sub_x, sub_y, rsub_x, rsub_y, div_x, div_y, rdiv_x, rdiv_y, exp_x, exp_y, rexp_x, rexp_y...; the APIs of these methods are: ... That would be a piss-poor API design. Any designer who knows what they are doing should be able to turn out a better API than that given a reasonable set of real-world requirements. My class is written, tested and complete before you've even decided on your API. And you don't even really get the benefit of abstraction: I have two public attributes (x and y) that I can't change without breaking other people's code, you've got sixteen-plus methods that you can't change without breaking other people's code. The end result is that your code is *less* abstract than mine: your code has to specify everything about ordinates: they can be added, they can be subtracted, they can be multiplied, they can be printed, and so on. That's far more concrete and far less abstract than mine, which simply says ordinates are floats, and leave the implementation of floats up to Python. Again, this is *your* API, not mine. You're forcing an ugly, obvious API instead of assuming the designer has some smidgen of ability. I've already pointed out one trivial way to deal with this, and there are others. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Managing import statements
Jean-Paul Calderone wrote: On Sat, 10 Dec 2005 02:21:39 -0700, Shane Hathaway [EMAIL PROTECTED] wrote: How about PyLint / PyChecker? Can I configure one of them to tell me only about missing / extra imports? Last time I used one of those tools, it spewed excessively pedantic warnings. Should I reconsider? I use pyflakes for this: http://divmod.org/trac/wiki/DivmodPyflakes. The *only* things it tells me about are modules that are imported but never used and names that are used but n Do any of these tools (PyLint, PyChecker, pyflakes) work with Jython? To do so they would have to work with Python 2.1, primarily... Thanks, Kent -- http://mail.python.org/mailman/listinfo/python-list
Re: calculate system disk space
A little somehting I rigged up when I found the Python call to be Linux
specific:
mount_list
Taste the system and return a list of mount points.
On UNIX this will return what a df will return
On DOS based systems run through a list of common drive letters and
test them
to see if a mount point exists. Whether a floppy or CDROM on DOS is
currently active may present challenges.
Curtis W. Rendon 6/27/200 v.01
6/27/2004 v.1 using df to make portable, and some DOS tricks to get
active
drives. Will try chkdsk on DOS to try to get drive size as statvfs()
doesn't exist on any system I have access to...
import sys,os,string
from stat import *
def mount_list():
returns a list of mount points
doslist=['a:\\','b:\\','c:\\','d:\\','e:\\','f:\\','g:\\','h:\\','i:\\','j:\\','k:\\','l:\\','m:\\','n:\\','o:\\','p:\\','q:\\','r:\\','s:\\','t:\\','u:\\','v:\\','w:\\','x:\\','y:\\','z:\\']
mount_list=[]
see what kind of system
if UNIX like
use os.path.ismount(path) from /... use df?
if DOS like
os.path.exists(path) for a list of common drive letters
if sys.platform[:3] == 'win':
#dos like
doslistlen=len(doslist)
for apath in doslist:
if os.path.exists(apath):
#maybe stat check first... yeah, it's there...
if os.path.isdir(apath):
mode = os.stat(apath)
try:
dummy=os.listdir(apath)
mount_list.append(apath)
except:
continue
else:
continue
return (mount_list)
else:
#UNIX like
AIX and SYSV are somewhat different than the GNU/BSD df, try to
catch
them. This is for AIX, at this time I don't have a SYS5 available
to see
what the sys.platform returns... CWR
if 'aix' in sys.platform.lower():
df_file=os.popen('df')
while True:
df_list=df_file.readline()
if not df_list:
break #EOF
dflistlower = df_list.lower()
if 'filesystem' in dflistlower:
continue
if 'proc' in dflistlower:
continue
file_sys,disc_size,disc_avail,disc_cap_pct,inodes,inodes_pct,mount=df_list.split()
mount_list.append(mount)
else:
df_file=os.popen('df')
while True:
df_list=df_file.readline()
if not df_list:
break #EOF
dflistlower = df_list.lower()
if 'filesystem' in dflistlower:
continue
if 'proc' in dflistlower:
continue
file_sys,disc_size,disc_used,disc_avail,disc_cap_pct,mount=df_list.split()
mount_list.append(mount)
return (mount_list)
have another function that returns max,used for each...
maybe in discmonitor
def size(mount_point):
if sys.platform[:3] == 'win':
#dos like
dos_cmd='dir /s '+ mount_point
check_file=os.popen(dos_cmd)
while True:
check_list=check_file.readline()
if not check_list:
break #EOF
if 'total files listed' in check_list.lower():
check_list=check_file.readline()
if 'file' in check_list.lower():
if 'bytes' in check_list.lower():
numfile,filtxt,rawnum,junk=check_list.split(None,3)
total_used=string.replace(rawnum,',','')
#return (0,int(total_size),int(total_size))
#break
check_list=check_file.readline()
if 'dir' in check_list.lower():
if 'free' in check_list.lower():
numdir,dirtxt,rawnum,base,junk=check_list.split(None,4)
multiplier=1
if 'mb' in base.lower():
multiplier=100
if 'kb' in base.lower():
multiplier=1000
rawnum=string.replace(rawnum,',','')
free_space=float(rawnum)*multiplier
#print
(0,int(free_space)+int(total_used),int(total_used))
return
(0,int(free_space)+int(total_used),int(total_used))
else:
continue
else:
#UNIX like
AIX and SYSV are somewhat different than the GNU/BSD df, try to
catch
them. This is for AIX, at this time I don't have a SYS5 available
to see
what the sys.platform returns... CWR
df_cmd = 'df '+ mount_point
if 'aix' in sys.platform.lower():
df_file=os.popen(df_cmd)
while True:
df_list=df_file.readline()
if not df_list:
break #EOF
dflistlower = df_list.lower()
if 'filesystem' in dflistlower:
continue
if 'proc' in dflistlower:
continue
file_sys,disc_size,disc_avail,disc_cap_pct,inodes,inodes_pct,mount=df_list.split()
return(0,int(disc_size),int(disc_size)-int(disc_avail))
else:
df_file=os.popen(df_cmd)
while True:
df_list=df_file.readline()
if not df_list:
break #EOF
dflistlower = df_list.lower()
if 'filesystem' in dflistlower:
Re: Managing import statements
Jean-Paul Calderone wrote: On Sat, 10 Dec 2005 02:21:39 -0700, Shane Hathaway [EMAIL PROTECTED] wrote: How about PyLint / PyChecker? Can I configure one of them to tell me only about missing / extra imports? Last time I used one of those tools, it spewed excessively pedantic warnings. Should I reconsider? I use pyflakes for this: http://divmod.org/trac/wiki/DivmodPyflakes. The *only* things it tells me about are modules that are imported but never used and names that are used but not defined. It's false positive rate is something like 1 in 10,000. That's definitely a good lead. Thanks. This is something I've long wanted to add to pyflakes (or as another feature of pyflakes/emacs integration). Is there a community around pyflakes? If I wanted to contribute to it, could I? Shane -- http://mail.python.org/mailman/listinfo/python-list
Re: Proposal: Inline Import
Shane Hathaway [EMAIL PROTECTED] writes:
Xavier Morel wrote:
Shane Hathaway wrote:
Thoughts?
import re; name_expr = re.compile('[a-zA-Z]+')
name_expr
_sre.SRE_Pattern object at 0x00F9D338
the import statement can be called anywhere in the code, why would
you add strange syntactic sugar that doesn't actually bring anything?
That syntax is verbose and avoided by most coders because of the speed
penalty. It doesn't replace the idiom of importing everything at the
top of the module.
What's really got me down is the level of effort required to move code
between modules. After I cut 100 lines from a 500 line module and
paste them to a different 500 line module, I have to examine every
import in both modules as well as examine the code I moved for missing
imports. And I still miss a lot of cases. My test suite catches a lot
of the mistakes, but it can't catch everything.
I understand this use case.
You can use pychecker to find NameErrors without actually running the
code. Unfortunately, it doesn't (at least not always) find imports
which are not needed.
Thomas
--
http://mail.python.org/mailman/listinfo/python-list
Re: Another newbie question
[EMAIL PROTECTED] (Alex Martelli) writes: Mike Meyer [EMAIL PROTECTED] wrote: ... it. Nothing you do with zim.foo or zim.foo.bar can change the state of zim. The only invariants you need to check are bar's, which you do at the exit to it's baz method. So foo's class is not allowed to have as its invariant any formula depending on the attributes of its attribute bar, such as bar.x23 or the like? Of course you can do such things. But it's a silly thing to do. That I guess this is the crux of our disagreement -- much like, it seems to me, your disagreement with Xavier and Steven on the other half of this thread, as I'll try to explain in the following. invariant should be written as x 23 for the class bar is an instance Let's, for definiteness, say that bar is an instance of class Bar. Now, my point is that absolutely not all instances of Bar are constrained to always have their x attribute 23 -- in general, their x's can vary all over the place; rather, the constraint applies very specifically to this one instance of Bar -- the one held by foo (an instance of Foo) as foo's attribute bar. Well, the hard-core solution is to note that your class doesn't really deal with the type Bar, but deals with a subtype of Bar for which x 23 in all cases. Since types are represented by classes, you should subclass Bar so you have a class that represents this subtype. The class is trivial (with Eiffel conventions): class RESTRICTED_BAR inherits BAR invariant x 23 END So, one invariant that had better hold to ensure a certain instance foo of Foo is not about to crash, may be, depending on how Foo's detailed structual geometry is, something like: foo.beam1.force_transferred_A = foo.pier1.max_load_top AND foo.beam1.force_transferred_B = foo.girder1.max_load_A The natural place to state this invariant is in class Foo, by expressing 'foo' as 'self' in Python (or omitting it in languages which imply such a lookup, of course). I don't think that's the natural place. It's certainly one place to consider, and may be the best one. However, it might work equally well to use preconditions on the methods that add the beam and pier to Foo to verify that the beam and pier in question are valid. If the attributes of the beam and pier can't change, this would be the right way to do it. If I'm not allowed (because you think it's silly!) to express a class invariant in terms of attributes of the attributes of an instance of that class, I basically have to write tons of boilerplate, violating encapsulation, to express what are really attributes of attributes of foo as if they were attributes of foo directly, e.g. [...] (etc). Changing a lot of dots into underscores -- what a way to waste programmer time! And all to NO advantage, please note, since: If you knew it was going to be to no advantage, why did you write the boilerplate? That's also pretty silly. Care to provide reasons for your wanting to do this? of. Invariants are intended to be used to check the state of the class, not the state of arbitary other objects. Doing the latter requires that you have to check the invariants of every object pretty much every time anything changes. ...in the end the invariant DOES have to be checked when anything relevant changes, anyway, with or without the silly extra indirection. No, it doesn't have to be checked. Even invariants that don't suffer from this don't have to be checked. It would be nice if every invariant was checked every time it might be violated, but that's not practical. If checking relationships between attributes attributes is the best you can do, you do that, knowing that instead of an invariant violation raising an exception after the code that violates it, the exception may raised after the first method of your class that is called after the invariant is violated. That's harder to debug than the other way, but if it's the best you can get, it's the best you can get. But besides the wasted work, there is a loss of conceptual integrity: I don't WANT Foo to have to expose the internal details that beam1's reference point A transfers the force to pier1's top, etc etc, elevating all of these internal structural details to the dignity of attributes of Foo. Foo should expose only its externally visible attributes: loads and forces on all the relevant points, geometric details of the exterior, and structural parameters that are relevant for operating safety margins, for example. You're right. Choosing to do that would be a bad idea. I have no idea why you would do that in any language I'm familiar with. I'd be interested in hearing about the language you use that requires you to do that. Invariants are a tool. Used wisely, they make finding and fixing some logic bugs much easier than it would be otherwise. Used unwisely, they don't do anything but make the code bigger. I disagree, most intensely and deeply, that any reference to an attribute of an
Re: Proposal: Inline Import
Shane Hathaway wrote: Benji York wrote: OK, good. You won't have to worry about that. :) You didn't give a reason for disliking it. Oh, I don't particularly dislike it. I hadn't come up with a reason to like or dislike it, other than a predilection for the status quo. -- Benji York -- http://mail.python.org/mailman/listinfo/python-list
Re: Managing import statements
Chris Mellon wrote: On 12/10/05, Shane Hathaway [EMAIL PROTECTED] wrote: I'm surprised this problem isn't more familiar to the group. Perhaps some thought I was asking a newbie question. I'm definitely a newbie in the sum of human knowledge, but at least I've learned some tiny fraction of it that includes Python, DRY, test-first methodology, OOP, design patterns, XP, and other things that are commonly understood by this group. Let's move beyond that. I'm looking for ways to gain just a little more productivity, and improving the process of managing imports could be low-hanging fruit. It is probably because most people don't regularly switch that much code around, or use that many modules. I think the fact that you move that much code between modules is probably a code smell in and of itself - you're clearly moving and changing responsibilities. Refactoring in smaller chunks, less extreme refactoring, correcting the imports as you go, and avoiding inline imports without a really good reason will probably help you a lot more than a new syntax. That's an insightful suggestion, but I'm pretty sure I'm doing it right. :-) I fill my mind with the way the code should look and behave when it's done, then I go through the code and change everything that doesn't match the picture. As the code moves closer to production and bugs become more expensive, I add a step to the process where I perform more formal refactoring, but that process takes much longer. The problems caused by the informal process are less expensive than the formal process. Yes. Spend an afternoon looking at PyLints options, get rid of the stuff you don't like, and use it regularly. PyDev has PyLint integration, which is nice. Ok, thanks. I don't think I've ever imported more than a dozen modules into any given file. I rarely find it neccesary to move huge chunks of code between my modules - the biggest such I did was when I moved from a single-file proof of concept to a real modular structure, and that only took me an hour or so. If I'd done it modularly to start with it would have been fine. Well, code moves a lot in the immature phases of large applications like Zope and distributed systems. Shane -- http://mail.python.org/mailman/listinfo/python-list
Re: Proposal: Inline Import
Benji York wrote: Shane Hathaway wrote: Benji York wrote: OK, good. You won't have to worry about that. :) You didn't give a reason for disliking it. Oh, I don't particularly dislike it. I hadn't come up with a reason to like or dislike it, other than a predilection for the status quo. I definitely sympathize. I don't want to see random changes in Python, either. The inline import idea was a bit intriguing when it surfaced, though. :-) Shane -- http://mail.python.org/mailman/listinfo/python-list
Re: calculate system disk space
[EMAIL PROTECTED] wrote: A little somehting I rigged up when I found the Python call to be Linux specific: os.stat isn't Linux-specific, isn't even Unix-specific, works just fine under Windows. Under Windows you don't have sparse files though, so there are no fields which give you the block-size of the device or the block-count of a file, just the st_size field which gives you the data size of the file. --- Heiko. -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: pygene - genetic algorithms package
Erik Max Francis wrote: Sure thing. Obviously I'll post an announcement here when it's ready. I'm really happy to see that someone is working on Python based GP implementation :) I'm currently trying to get into GP world (I'm the GP newbie you talked about :P) and, as I'm a Python programmer, I look towards Python based solutions. Unfortunately there are no active Python GP projects (maybe except Pyro, but I'm not sure how GP is implemented there) so I'm forced to play with Java based systems, which isn't what I like. Are you able to give any approximated date of PSI release? Cheers -- eXt -- http://mail.python.org/mailman/listinfo/python-list
Re: binascii.crc32 results not matching
Larry Bates wrote: snip a lot of code Looking over the code, it seems very inefficient and hard to understand. You really should check out the following. http://sourceforge.net/projects/crcmod/ It will allow you to generate efficient CRC functions for use in Python and in C or C++. The only thing you need to input is the polynomial, the bit ordering, and the starting value. The unit test gives a number of polynomials including the one you are using which is: polynomial: 0x104C11DB7, bit reverse algorithm If you are just looking for a utility on Linux to do nightly checking of files, I strongly recommend md5sum. My timing tests indicate that the MD5 algorithm is comparable or slightly faster than a 32-bit CRC and certainly faster than the code you are trying to port. It also has the advantage of being a standard Linux command so you don't need to code anything. Ray -- http://mail.python.org/mailman/listinfo/python-list
Re: slice notation as values?
Antoon Pardon wrote: On 2005-12-10, Duncan Booth [EMAIL PROTECTED] wrote: [snip] I also think that other functions could benefit. For instance suppose you want to iterate over every second element in a list. Sure you can use an extended slice or use some kind of while. But why not extend enumerate to include an optional slice parameter, so you could do it as follows: for el in enumerate(lst,::2) 'Why not'? Because it makes for a more complicated interface for something you can already do quite easily. Do you think so? This IMO should provide (0,lst[0]), (2,lst[2]), (4,lst[4]) ... I haven't found a way to do this easily. Except for something like: start = 0: while start len(lst): yield start, lst[start] start += 2 But if you accept this, then there was no need for enumerate in the first place. So eager to learn something new, how do you do this quite easily? lst = ['ham','eggs','bacon','spam','foo','bar','baz'] list(enumerate(lst))[::2] [(0, 'ham'), (2, 'bacon'), (4, 'foo'), (6, 'baz')] No changes to the language necessary. -- http://mail.python.org/mailman/listinfo/python-list
locawapp-001.zip
LocaWapp: localhost web applications V.0.0.1 (2005 Dec 10)
Copyright (C) 2005 RDJ
This code is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY.
http://LocaWapp.blogspot.com
- Run with:
python run.py
- or:
python run.py 8081
- and browse with:
http://localhost:8080/locawapp/main.py
- or:
http://localhost:8081/locawapp/main.py
- If this is good for you, then you can help me developing with:
HTML + CSS + JS + PYTHON = LocaWapp
---
- Put your application in root:
[your_application]
[locawapp]
__init__.py
common.py
main.py
[static]
logo.gif
main.css
main.js
README.TXT
run.py
- Your application must to have init and main (for convention):
[your_application]
__init__.py
main.py
- main.py is a web application, then it has locawapp_main function:
def locawapp_main(request):
[...]
return [string]
- See locawapp.main.py and locawapp.common.py
- Send me your comment, thanks :-)
- Bye
http://LocaWapp.blogspot.com
class Server:
def __init__(self,port):
self.resp = None
self.session = {'_stopServer':False}
s = socket.socket(socket.AF_INET,socket.SOCK_STREAM)
s.bind(('127.0.0.1',port))
s.listen(5)
while 1:
self.resp = ''
conn,addr = s.accept()
data = ''
while 1:
tmp = conn.recv(BUFFER)
if tmp == '':
break
data += tmp
end = data.find('\r\n\r\n')
if end != -1:
data2 =
data[:end].split('\r\n')
method = data2[0].split(' ')
method[1] =
urllib.unquote(method[1])
header = {}
for r in data2[1:]:
rr = r.split(': ')
header[rr[0]] = rr[1]
if method[0] == 'GET':
self.getResp(method,header,None)
elif method[0] == 'POST':
cnt_len =
int(header['Content-Length'])
content = data[end+4:]
while len(content)
cnt_len:
tmp =
conn.recv(BUFFER)
if tmp == '':
break
content += tmp
content =
content[:cnt_len] # for MSIE 5.5 that append \r\n
content =
urllib.unquote(content)
self.getResp(method,header,content)
break
conn.send(self.resp)
conn.close()
if self.session['_stopServer']:
break
s.close()
def getResp(self,method,header,content):
url = method[1].split('?')
path = url[0][1:]
ext = os.path.splitext(path)
try:
if ext[1] == '.py':
get = {}
if len(url) == 2:
get = self.getParams(url[1])
post = {}
if content != None:
post = self.getParams(content)
request = {
'header':header,
'get':get,
'post':post,
'session':self.session
}
exec 'import ' +
ext[0].replace('/','.') + ' as app'
response = app.locawapp_main(request)
self.resp =
self.makeResp(200,'text/html',response['content'])
else:
try:
f = open(path,'rb')
fs = f.read()
f.close()
self.resp =
self.makeResp(200,self.getCntType(ext[1]),fs)
except IOError:
double underscore attributes?
Entering
dir(5)
I get
['__abs__', '__add__', '__and__', '__class__', '__cmp__', '__coerce__',
'__delattr__', '__div__', '__divmod__', '__doc__', '__float__',
'__floordiv__', '__getattribute__', '__getnewargs__', '__hash__',
'__hex__', '__init__', '__int__', '__invert__', '__long__',
'__lshift__', '__mod__', '__mul__', '__neg__', '__new__',
'__nonzero__', '__oct__', '__or__', '__pos__', '__pow__', '__radd__',
'__rand__', '__rdiv__', '__rdivmod__', '__reduce__', '__reduce_ex__',
'__repr__', '__rfloordiv__', '__rlshift__', '__rmod__', '__rmul__',
'__ror__', '__rpow__', '__rrshift__', '__rshift__', '__rsub__',
'__rtruediv__', '__rxor__', '__setattr__', '__str__', '__sub__',
'__truediv__', '__xor__']
Every time I use dir(some module) I get a lot of attributes with double
underscore, for example __add__. Ok, I thought __add__ must be a method
which I can apply like this
5.__add(8)
However Python responded
SyntaxError: invalid syntax
I tried
help(5.__add__)
but got
SyntaxError: invalid syntax
However when I tried with a list
help([5,6].__add__)
I got
Help on method-wrapper object:
__add__ = class method-wrapper(object)
| Methods defined here:
|
| __call__(...)
| x.__call__(...) == x(...)
|
| __getattribute__(...)
| x.__getattribute__('name') == x.name
Not that I understand much of this but at least I got some response.
Now I went to Python Library Reference and searched for __add__ but
got zero hits.
Could someone explain the use of __add__ (and similar double underscore
attributes) and what their use is.
Bob
--
http://mail.python.org/mailman/listinfo/python-list
Re: Another newbie question
Mike Meyer [EMAIL PROTECTED] wrote: ... Well, the hard-core solution is to note that your class doesn't really deal with the type Bar, but deals with a subtype of Bar for which x 23 in all cases. Since types are represented by classes, you should subclass Bar so you have a class that represents this subtype. The class is trivial (with Eiffel conventions): class RESTRICTED_BAR inherits BAR invariant x 23 END Yes, but then once again you have to publicize something (an aspect of a class invariant) which should be dealt with internally; also, this approach does not at all generalize to bar1.x23 OR bar2.x23 and any other nontrivial constraint involving expressions on more than attributes of a single instance's attribute and compile-time constants. So, besides hard-coreness, this is just too limited to serve. So, one invariant that had better hold to ensure a certain instance foo of Foo is not about to crash, may be, depending on how Foo's detailed structual geometry is, something like: foo.beam1.force_transferred_A = foo.pier1.max_load_top AND foo.beam1.force_transferred_B = foo.girder1.max_load_A The natural place to state this invariant is in class Foo, by expressing 'foo' as 'self' in Python (or omitting it in languages which imply such a lookup, of course). I don't think that's the natural place. It's certainly one place to consider, and may be the best one. However, it might work equally well to use preconditions on the methods that add the beam and pier to Foo to verify that the beam and pier in question are valid. If the attributes of the beam and pier can't change, this would be the right way to do it. What ever gave you the impression that the loads on beams and piers (and therefore the forces they transfer) can't change? That would be a pretty weird way to design a framework for structural modeling in any language except a strictly functional (immutable-data) one, and I've already pointed out that functional languages, thanks to their immutable data approach, are very different from ones (like Eiffel or Python) where data routinely does get changed. If I'm not allowed (because you think it's silly!) to express a class invariant in terms of attributes of the attributes of an instance of that class, I basically have to write tons of boilerplate, violating encapsulation, to express what are really attributes of attributes of foo as if they were attributes of foo directly, e.g. [...] (etc). Changing a lot of dots into underscores -- what a way to waste programmer time! And all to NO advantage, please note, since: If you knew it was going to be to no advantage, why did you write the boilerplate? That's also pretty silly. Care to provide reasons for your wanting to do this? If I had to program under a styleguide which enforces the style preferences you have expressed, then the stupid boilerplate would allow my program to be accepted by the stylechecker, thus letting my code be committed into the source control system; presumably that would be necessary for me to keep my job (thus drawing a salary) or getting paid for my consultancy billed hours. Just like, say, if your styleguide forbade the use of vowels in identifiers, I might have a tool to convert such vowels into consonants before I committed my code. I'm not saying there cannot be monetary advantage for me to obey the deleterious and inappropriate rules of any given arbitrary styleguide: it may be a necessary condition for substantial monetary gains or other preferments. I'm saying there is no advantage whatsoever to the organization as a whole in imposing arbitrary constraints such as, no vowels in identifiers, or, no access to attributes of attributes in invariants. of. Invariants are intended to be used to check the state of the class, not the state of arbitary other objects. Doing the latter requires that you have to check the invariants of every object pretty much every time anything changes. ...in the end the invariant DOES have to be checked when anything relevant changes, anyway, with or without the silly extra indirection. No, it doesn't have to be checked. Even invariants that don't suffer from this don't have to be checked. It would be nice if every invariant was checked every time it might be violated, but that's not practical. If checking relationships between attributes attributes is the best you can do, you do that, knowing that instead of an invariant violation raising an exception after the code that violates it, the exception may raised after the first method of your class that is called after the invariant is violated. That's harder to debug than the other way, but if it's the best you can get, it's the best you can get. Let's silently gloss on the detail that calling invariant something that is in fact not guaranteed not to vary (or at least not to vary without raising exceptions) is a recipe for semantic confusion;-)
Re: How to find the type ...
Thank you ALL for help and explanation Regards, L. -- http://mail.python.org/mailman/listinfo/python-list
Re: double underscore attributes?
[EMAIL PROTECTED] wrote: Now I went to Python Library Reference and searched for __add__ but got zero hits. http://python.org/doc/2.4.2/ref/specialnames.html -- http://mail.python.org/mailman/listinfo/python-list
Re: slice notation as values?
Antoon Pardon wrote: Will it ever be possible to write things like: a = 4:9 I made a silly recipe to do something like this a while ago, not that I'd recommend using it. But I also think it wouldn't be too far-fetched to allow slice creation using a syntax like the above... http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/415500 -- Brian Beck Adventurer of the First Order -- http://mail.python.org/mailman/listinfo/python-list
Re: double underscore attributes?
Hi Bob, see this my example: class A: ... def __add__(a,b): ... print a,b ... a = A() b = A() a + b __main__.A instance at 0x80c5a74 __main__.A instance at 0x80c6234 -- http://mail.python.org/mailman/listinfo/python-list
Re: Another newbie question
Mike Meyer [EMAIL PROTECTED] wrote: In addition to the full set of methods which operate on the coordinate as a whole, you can operate on the individual ordinates via instance.x and instance.y which are floats. That's an API which makes changing the object more difficult. It may be the best API for the case at hand, but you should be aware of the downsides. Since x and y are important abstractions of a 2-D coordinate, I disagree that exposing them makes changing the object more difficult, as long of course as I can, if and when needed, change them into properties (or otherwise obtain similar effects -- before we had properties in Python, __setattr__ was still quite usable in such cases, for example, although properties are clearly simpler and more direct). You could make a case for a 2D coordinate class being sufficiently primitive to have immutable instances, of course (by analogy with numbers and strings) -- in that design, you would provide no mutators, and therefore neither would you provide setters (with any syntax) for x and y, obviously. However, a framework for 2D geometry entirely based on immutable-instance classes would probably be unwieldy (except in a fully functional language); as long as we have a language whose normal style allows data mutation, we'll probably fit better into it by allowing mutable geometrical primitives at some level -- and as soon as the mutable primitives are reached, settable attributes and their syntax and semantics come to the fore again... Alex -- http://mail.python.org/mailman/listinfo/python-list
Re: problems binding a dictionary
[EMAIL PROTECTED] wrote: this has to be a very silly thing. I have a function foo taking a dictionary as parameters. i.e.: def foo(**kwargs): pass when I call foo(param1='blah',param2='bleh',param3='blih') everything is fine. but when I do: def foo(**kwargs): ... pass ... d=dict(param1='blah',param2='bleh',param3='blih') foo(d) I get: Traceback (most recent call last): File stdin, line 1, in ? TypeError: foo() takes exactly 0 arguments (1 given) Why? how do I pass the dictionary *d* to foo()? Thanks, - Josh. simply because your parameter definition expect keyword parameter passing, and you are passing a paramater by placement. You should call the function like this: f(mykey=d) or, since d is dict, you could use d's key/vals as keyword parameter: f(**d) which equivalent to doing: f(param1='blah',param2='bleh',param3='blih') -- dsw -- http://mail.python.org/mailman/listinfo/python-list
Re: slice notation as values?
Antoon Pardon wrote:
On 2005-12-10, Steven Bethard [EMAIL PROTECTED] wrote:
Antoon Pardon wrote:
So lets agree that tree['a':'b'] would produce a subtree. Then
I still would prefer the possibility to do something like:
for key in tree.iterkeys('a':'b')
Instead of having to write
for key in tree['a':'b'].iterkeys()
Sure I can now do it like this:
for key in tree.iterkeys('a','b')
But the way default arguments work, prevents you from having
this work in an analague way as a slice.
How so? Can't you just pass the *args to the slice contstructor? E.g.::
def iterkeys(self, *args):
keyslice = slice(*args)
...
Then you can use the slice object just as you would have otherwise.
This doesn't work for a number of reasons,
1)
slice()
Traceback (most recent call last):
File stdin, line 1, in ?
TypeError: slice expected at least 1 arguments, got 0
I wasn't sure whether or not the slice argument was optional.
Apparently it's intended to be, so you have to make one special case:
def iterkeys(self, *args):
keyslice = args and slice(*args) or slice(None, None, None)
2) It doens't give a clear way to indicate the following
kind of slice: tree.iterkeys('a':). Because of the
follwing:
slice('a')
slice(None, 'a', None)
which would be equivallent to tree.iterkeys(:'a')
Well, it certainly gives a way to indicate it:
tree.iterkeys(None, 'a')
Whether or not it's a clear way is too subjective of a topic for me to
get into. That's best left to Guido[1]. My point is that it *does*
work, and covers (or can be slightly altered to cover) all the
functionality you want. That doesn't mean you have to like the API for
it, of course.
STeVe
[1] By which I mean that you should submit a PEP on the idea, and let
Guido decide which way is prettier. Just be sure to give all the
equivalent examples - i.e. calling the slice constructor with the
appropriate arguments.
--
http://mail.python.org/mailman/listinfo/python-list
Re: double underscore attributes?
[EMAIL PROTECTED] wrote: Every time I use dir(some module) I get a lot of attributes with double underscore, for example __add__. Ok, I thought __add__ must be a method which I can apply like this 5.__add(8) However Python responded SyntaxError: invalid syntax I tried help(5.__add__) but got SyntaxError: invalid syntax Note that these SyntaxErrors are due to how Python parses floats: 5. 5.0 5.__add__(8) Traceback ( File interactive input, line 1 5.__add__(8) ^ SyntaxError: invalid syntax (5).__add__(8) 13 HTH, STeVe -- http://mail.python.org/mailman/listinfo/python-list
Re: double underscore attributes?
[EMAIL PROTECTED] wrote: ... Every time I use dir(some module) I get a lot of attributes with double underscore, for example __add__. Ok, I thought __add__ must be a method which I can apply like this ... I tried help(5.__add__) but got SyntaxError: invalid syntax That's because the parser thinks 5. is a float, rather than the integer 5 with a dot after it. If you want to refer to an attribute of an integer literal, you can use (5).__add__ or 5 .__add__ (with a space). -- http://mail.python.org/mailman/listinfo/python-list
Re: Proposal: Inline Import
Shane Hathaway wrote: Let me fully elaborate the heresy I'm suggesting: I am talking about inline imports on every other line of code. The obvious implementation would drop performance by a double digit percentage. Module importing is already idempotent. If you try to import an already-imported module, inline or not, the second (or subsequent) imports are no-operations. -- Erik Max Francis [EMAIL PROTECTED] http://www.alcyone.com/max/ San Jose, CA, USA 37 20 N 121 53 W AIM erikmaxfrancis Golf is a good walk spoiled. -- Mark Twain -- http://mail.python.org/mailman/listinfo/python-list
Re: Another newbie question
[EMAIL PROTECTED] (Alex Martelli) writes: Mike Meyer [EMAIL PROTECTED] wrote: ... Well, the hard-core solution is to note that your class doesn't really deal with the type Bar, but deals with a subtype of Bar for which x 23 in all cases. Since types are represented by classes, you should subclass Bar so you have a class that represents this subtype. The class is trivial (with Eiffel conventions): class RESTRICTED_BAR inherits BAR invariant x 23 END Yes, but then once again you have to publicize something (an aspect of a class invariant) which should be dealt with internally Contracts are intended to be public; they are part of the the class's short form, which is the part that's intended for public consumption. If your vision of invariants is that they are for internal use only, and clients don't need to know them, then you probably ought to be considering another language. also, this approach does not at all generalize to bar1.x23 OR bar2.x23 and any other nontrivial constraint involving expressions on more than attributes of a single instance's attribute and compile-time constants. So, besides hard-coreness, this is just too limited to serve. I believe it's the best solution for the case at hand. It causes the violation of the invariant to be caught as early as possible. As I mentioned elsewhere, it's not suitable for all cases, so you have to use other, possibly less effective, tools. So, one invariant that had better hold to ensure a certain instance foo of Foo is not about to crash, may be, depending on how Foo's detailed structual geometry is, something like: foo.beam1.force_transferred_A = foo.pier1.max_load_top AND foo.beam1.force_transferred_B = foo.girder1.max_load_A The natural place to state this invariant is in class Foo, by expressing 'foo' as 'self' in Python (or omitting it in languages which imply such a lookup, of course). I don't think that's the natural place. It's certainly one place to consider, and may be the best one. However, it might work equally well to use preconditions on the methods that add the beam and pier to Foo to verify that the beam and pier in question are valid. If the attributes of the beam and pier can't change, this would be the right way to do it. What ever gave you the impression that the loads on beams and piers (and therefore the forces they transfer) can't change? Your incomplete specification of the problem. You didn't say whether or not they could change, so I pointed out what might - key word, that - be a better solution for a more complete specification. If I'm not allowed (because you think it's silly!) to express a class invariant in terms of attributes of the attributes of an instance of that class, I basically have to write tons of boilerplate, violating encapsulation, to express what are really attributes of attributes of foo as if they were attributes of foo directly, e.g. [...] (etc). Changing a lot of dots into underscores -- what a way to waste programmer time! And all to NO advantage, please note, since: If you knew it was going to be to no advantage, why did you write the boilerplate? That's also pretty silly. Care to provide reasons for your wanting to do this? If I had to program under a styleguide which enforces the style preferences you have expressed, then the stupid boilerplate would allow my program to be accepted by the stylechecker, thus letting my code be committed into the source control system; presumably that would be necessary for me to keep my job (thus drawing a salary) or getting paid for my consultancy billed hours. Just like, say, if your styleguide forbade the use of vowels in identifiers, I might have a tool to convert such vowels into consonants before I committed my code. I'm not saying there cannot be monetary advantage for me to obey the deleterious and inappropriate rules of any given arbitrary styleguide: it may be a necessary condition for substantial monetary gains or other preferments. I'm saying there is no advantage whatsoever to the organization as a whole in imposing arbitrary constraints such as, no vowels in identifiers, or, no access to attributes of attributes in invariants. True. But if you think this is an arbitary constraint, why did you impose it in the first place? of. Invariants are intended to be used to check the state of the class, not the state of arbitary other objects. Doing the latter requires that you have to check the invariants of every object pretty much every time anything changes. ...in the end the invariant DOES have to be checked when anything relevant changes, anyway, with or without the silly extra indirection. No, it doesn't have to be checked. Even invariants that don't suffer from this don't have to be checked. It would be nice if every invariant was checked every time it might be violated, but that's not practical. If checking relationships between
Re: binascii.crc32 results not matching
Larry Bates wrote: snip lots of code The algorithm looks very much like the source code for binascii.crc32 (but I'm not a C programmer). Well... As you have access to the code, you might actually just create a thin Python-Wrapper around this so that you can get comparable results. In case you're unable to do so, send me the C-file (I'm not so keen on copy-pasting code which was reformatted due to mail), and I'll send you an extension module back. --- Heiko. -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
On 2005-12-10, Tom Anderson [EMAIL PROTECTED] wrote: ED IS THE STANDARD TEXT EDITOR. And: INDENTATION SUCKS BIG TIME. Using indentation without block termination markers is opposite of the way we write spoken language, terminating each sentence with . Ever wondered why we use such things in written language, when people are much better in guessing what the writer wanted to say then computers? -- http://mail.python.org/mailman/listinfo/python-list
Re: calculate system disk space
Heiko Wundram: Under Windows you don't have sparse files though, so there are no fields ... Does too! http://msdn.microsoft.com/library/en-us/fileio/fs/fsctl_set_sparse.asp They're fairly rare though. Neil -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: pygene - genetic algorithms package
eXt wrote: I'm really happy to see that someone is working on Python based GP implementation :) I'm currently trying to get into GP world (I'm the GP newbie you talked about :P) and, as I'm a Python programmer, I look towards Python based solutions. Unfortunately there are no active Python GP projects (maybe except Pyro, but I'm not sure how GP is implemented there) so I'm forced to play with Java based systems, which isn't what I like. Are you able to give any approximated date of PSI release? Unfortunately I can't give a precise date. If I have the time, a polished working system with at least the basics should only take a week or so to finish up. Unfortunately, I have a big deadline coming up in my day job, so I'm probably not going to get much time to work on it for the next week or two. Hopefully I'll have a basic system ready by New Year's, but I can't really make any promises. The best way to encourage me to get it done is probably to keep me talking about it :-). -- Erik Max Francis [EMAIL PROTECTED] http://www.alcyone.com/max/ San Jose, CA, USA 37 20 N 121 53 W AIM erikmaxfrancis You are my martyr / I'm a vestige of a revolution -- Lamya -- http://mail.python.org/mailman/listinfo/python-list
Re: double underscore attributes?
[EMAIL PROTECTED] wrote: Could someone explain the use of __add__ (and similar double underscore attributes) and what their use is. Bob Methods with double leading and trailing underscores are basically magic methods with specific meanings for the Python interpreter. You're not supposed to use them directly (in most cases) as they are wrapped by syntactic sugar or part of protocol's implementation. __add__, for example, is the definition of the + operator, using (5).__add__(8) is exactly the same as using 5+8. To get a list of most of these magic methods, check the Python documentation on the operator module. These magic methods allow you to emulate numbers, sequences, iterators, or even callables (allowing you to use an object as a function). Be really careful with them though, one of the things that plagued (and still plague) C++ is the abuse of operators overloading and modification of their meaning. -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
Zeljko Vrba wrote: Using indentation without block termination markers is opposite of the way we write spoken language, terminating each sentence with . Ever wondered why we use such things in written language, when people are much better in guessing what the writer wanted to say then computers? Interesting. Python's use of indentation comes from ABC, which based the design partially on extensive testing on human beings. Humans often use indentation for grouping, and colons to introduce a new level or group are at least as common. In fact, most humans can understand the structure of a Python program even if they've never programmed before. I guess writers don't use indentation to group text on your planet. /F -- http://mail.python.org/mailman/listinfo/python-list
OO in Python? ^^
Hi, sorry for my ignorance, but after reading the Python tutorial on python.org, I'm sort of, well surprised about the lack of OOP capabilities in python. Honestly, I don't even see the point at all of how OO actually works in Python. For one, is there any good reason why I should ever inherit from a class? ^^ There is no functionality to check if a subclass correctly implements an inherited interface and polymorphism seems to be missing in Python as well. I kind of can't imagine in which circumstances inheritance in Python helps. For example: class Base: def foo(self): # I'd like to say that children must implement foo pass class Child(Base): pass # works Does inheritance in Python boil down to a mere code sharing? And how do I formulate polymorphism in Python? Example: class D1(Base): def foo(self): print D1 class D2(Base): def foo(self): print D2 obj = Base() # I want a base class reference which is polymorphic if (need D1): obj = D1() else: obj = D2() I could as well leave the whole inheritance stuff out and the program would still work (?). Please give me hope that Python is still worth learning :-/ Regards, Matthias -- http://mail.python.org/mailman/listinfo/python-list
Re: OO in Python? ^^
Matthias Kaeppler wrote: snip a whole lot of talk of someone still thinking in terms of C Let this enlighten your way, young padawan: [EMAIL PROTECTED] ~/gtk-gnutella-downloads $ python Python 2.4.2 (#1, Oct 31 2005, 17:45:13) [GCC 3.4.4 (Gentoo 3.4.4-r1, ssp-3.4.4-1.0, pie-8.7.8)] on linux2 Type help, copyright, credits or license for more information. import this The Zen of Python, by Tim Peters Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. Now is better than never. Although never is often better than *right* now. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea -- let's do more of those! And, _do_ (don't only read) the tutorial, and you'll understand why the short example code you posted isn't pythonic, to say the least: http://www.python.org/doc/2.4.2/tut/tut.html and why inheritance in Python is necessary, but on a whole different level of what you're thinking. Oh, and on a last note, if you're german, you might as well join de.comp.lang.python. --- Heiko. -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: pygene - genetic algorithms package
Erik Max Francis wrote: Unfortunately I can't give a precise date. If I have the time, a polished working system with at least the basics should only take a week or so to finish up. Unfortunately, I have a big deadline coming up in my day job, so I'm probably not going to get much time to work on it for the next week or two. Hopefully I'll have a basic system ready by New Year's, but I can't really make any promises. Sure, I understand You :). Thanks for answer. The best way to encourage me to get it done is probably to keep me talking about it :-). As I did :) -- eXt -- http://mail.python.org/mailman/listinfo/python-list
Re: OO in Python? ^^
Matthias Kaeppler wrote: polymorphism seems to be missing in Python QOTW! /F -- http://mail.python.org/mailman/listinfo/python-list
Re: OO in Python? ^^
Fredrik Lundh wrote: Matthias Kaeppler wrote: polymorphism seems to be missing in Python QOTW! Let's have some UQOTW: the un-quote of the week! ;-) --- Heiko. -- http://mail.python.org/mailman/listinfo/python-list
Re: Another newbie question
[EMAIL PROTECTED] (Alex Martelli) writes: Mike Meyer [EMAIL PROTECTED] wrote: In addition to the full set of methods which operate on the coordinate as a whole, you can operate on the individual ordinates via instance.x and instance.y which are floats. That's an API which makes changing the object more difficult. It may be the best API for the case at hand, but you should be aware of the downsides. Since x and y are important abstractions of a 2-D coordinate, I disagree that exposing them makes changing the object more difficult, as long of course as I can, if and when needed, change them into properties (or otherwise obtain similar effects -- before we had properties in Python, __setattr__ was still quite usable in such cases, for example, although properties are clearly simpler and more direct). Exposing them doesn't make making changes more difficult. Allowing them to be used to manipulate the object makes some changes more difficult. Properties makes the set of such changes smaller, but it doesn't make them vanish. Take our much-abused coordinate example, and assume you've exposed the x and y coordinates as attributes. Now we have a changing requirement - we want to get to make the polar coordinates available. To keep the API consistent, they should be another pair of attributes, r and theta. Thanks to Pythons nice properties, we can implement these with a pair of getters, and compute them on the fly. If x and y can't be manipulated individually, you're done. If they can, you have more work to do. If nothing else, you have to decide that you're going to provide an incomplete interface, in that users will be able to manipulate the object with some attributes but not others for no obvious good reason. To avoid that, you'll have to add code to run the coordinate transformations in reverse, which wouldn't otherwise be needed. Properties make this possible, which is a great thing. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: OO in Python? ^^
Matthias Kaeppler wrote: class Base: def foo(self): # I'd like to say that children must implement foo pass def foo(self): raise NotImplementedError(Subclasses must implement foo) Now calling foo on a child instance will fail if it hasn't implemented foo. And how do I formulate polymorphism in Python? Example: class D1(Base): def foo(self): print D1 class D2(Base): def foo(self): print D2 obj = Base() # I want a base class reference which is polymorphic if (need D1): obj = D1() else: obj = D2() I have no idea what you're trying to do here and how it relates to polymorphism. -- Brian Beck Adventurer of the First Order -- http://mail.python.org/mailman/listinfo/python-list
Re: Dectecting dir changes
I do need to stick to FTP though as indicated I could run it on a different port. Limit comes more from the client side capabilities. Did some reading about twisted and I now understand that things in general are single threaded. I started working my way through the twisted finger tutorial. While it appears that it may be useful for someone writing a new protocol it doesn't seem to useful for someone just trying to hook into an existing one. While I do appreciate the suggestions but I have to say that if the twisted folks spent half the time writing documentation as they do code - twisted would probably get used a lot more Python folks. Didn't get much encouragement/assistance from the twisted irc channel either. Perhaps the fella I chatted with hadn't had his coffee yet ;) -- http://mail.python.org/mailman/listinfo/python-list
Re: Dectecting dir changes
chuck wrote: While I do appreciate the suggestions but I have to say that if the twisted folks spent half the time writing documentation as they do code - twisted would probably get used a lot more Python folks. Didn't get much encouragement/assistance from the twisted irc channel either. Perhaps the fella I chatted with hadn't had his coffee yet ;) or maybe it's a medication issue. your experience isn't exactly unique: http://twistedmatrix.com/pipermail/twisted-python/2005-May/010380.html In this e-mail thread, someone wrote that people who say Twisted has no docs ought to be stabbed in the face. Obviously, this was intended as humor, but I believe that this social custom, along with as other related social customs in Twistedland, deter people from some other cultures from participating. /F -- http://mail.python.org/mailman/listinfo/python-list
Re: OO in Python? ^^
Brian Beck wrote:
class D1(Base):
def foo(self):
print D1
class D2(Base):
def foo(self):
print D2
obj = Base() # I want a base class reference which is polymorphic
if (need D1):
obj = D1()
else:
obj = D2()
I have no idea what you're trying to do here and how it relates to
polymorphism.
He's translating C++ code directly to Python. obj = Base() creates a
variable of type Base(), to which you can assign different object types (D
(), D2()) which implement the Base interface (are derived from Base).
Err... At least I think it's what this code is supposed to mean...
In C++ you'd do:
Base *baseob;
if( i want d1 ) {
baseob = (Base*)new D1();
} else {
baseob = (Base*)new D2();
}
baseob-foo();
(should, if foo is declared virtual in Base, produce d1 for D1, and d2
for D2)
At least IIRC, it's been quite some time since I programmed C++... ;-)
*shudder*
--- Heiko.
--
http://mail.python.org/mailman/listinfo/python-list
Re: OO in Python? ^^
In article [EMAIL PROTECTED], Matthias Kaeppler [EMAIL PROTECTED] wrote: ... obj = Base() # I want a base class reference which is polymorphic obj now refers to an instance of Base. if (need D1): obj = D1() obj now refers to an instance of D1(). The Base instance is unreferenced. else: obj = D2() obj now refers to an instance of D2(). The Base instance is unreferenced. Note that there is no code path that results in obj still referring to an instance of Base. Unless making a Base had side effects, there is no use in the first line. I could as well leave the whole inheritance stuff out and the program would still work (?). That program might. Please give me hope that Python is still worth learning :-/ Python has inheritance and polymorphism, implemented via dictionaries. Python's various types of namespace are implemented with dictionaries. Type this in to the Python interpreter: class Base: def foo(self): print 'in Base.foo' class D1(Base): def foo(self): print 'in D1.foo' Base.foo(self) class D2(Base): def foo(self): print 'in D2.foo' Base.foo(self) def makeObj(): return needD1 and D1() or D2() needD1 = True makeObj().foo() needD1 = False makeObj().foo() TonyN.:'[EMAIL PROTECTED] ' http://www.georgeanelson.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: OO in Python? ^^
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matthias == Matthias Kaeppler [EMAIL PROTECTED] writes: Matthias sorry for my ignorance, but after reading the Python Matthias tutorial on python.org, I'm sort of, well surprised about Matthias the lack of OOP capabilities in python. Honestly, I don't Matthias even see the point at all of how OO actually works in Matthias Python. It's very common for Python newbies, especially those with backgrounds in languages such as C++, Java etc. to not really 'get' the Python way of handling types until they've had a fair amount of experience with Python. If you want to program Pythonically, you must first unlearn a number of things. For instance, in e.g. the Java tradition, if a function needs a triangle object, it'll take a triangle object as an argument. If it can handle any type of shape, it'll either take a shape base class instance as an argument or there'll be some kind of shape interface that it can take. Argument types are strictly controlled. Not so with Python. A Python solution will typically take any type of object as an argument so long as it behaves as expected, and if it doesn't, we deal with the resulting exception (or don't, depending on what we're trying to accomplish). For instance, if the function from before that wants a shape really only needs to call an area method, anything with an area method can be used successfully as an argument. Some have dubbed this kind of type check 'duck typing': if it walks like a duck and quacks like a duck, chances are it'll be a duck. To those who are used to (more or less) strong, static type checks, this will seem a reckless approach, but it really works rather well, and subtle type errors are, in my experience, as rare in Python as in any other language. In my opinion, the tricks the C*/Java people occasionally do to get around the type system, such as casting to the fundamental object type, are worse because they're seldom expected and resulting errors thus typically more subtle. In my very first post on this news group a number of years ago, I asked for an equivalent of Java's interfaces. The only reply I got was that I didn't need them. While the reason was very obvious, even with what I knew about Python, it still took a while to sink in. From what I can tell, you're in somewhat the same situation, and the two of us are far from unique. As I said in the beginning, Python newbies with a background in statically typed languages typically have a lot to unlearn, but in my opinion, it's well worth it. Martin -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using Mailcrypt+GnuPG http://www.gnupg.org iEYEARECAAYFAkOba8oACgkQYu1fMmOQldXzcgCg0JEGTEG7xC/yAx8C1VFO8H1R LWwAnRJ8AxHBe8YoHcDC5oGRfYaPHTfX =HdTR -END PGP SIGNATURE- -- http://mail.python.org/mailman/listinfo/python-list
Re: OO in Python? ^^
Heiko Wundram wrote: Matthias Kaeppler wrote: snip a whole lot of talk of someone still thinking in terms of C Well, unless you are (or he is) in with the GNOME crowd, C probably isn't really the object-oriented language acting as inspiration here. [Zen of Python] Of course the ZoP (Zen of Python) is deep guidance for those languishing in some design dilemma or other, but not exactly helpful, concrete advice in this context. (I'm also getting pretty jaded with the recent trend of the ZoP being quoted almost once per thread on comp.lang.python, mostly as a substitute for any real justification of Python's design or any discussion of the motivations behind its design.) That said, the questioner does appear to be thinking of object-oriented programming from a statically-typed perspective, and I'd agree that, ZoP or otherwise, a change in perspective and a willingness to accept other, equally legitimate approaches to object-orientation will lead to a deeper understanding and appreciation of the Python language. Anyway, it appears that the questioner is confusing declarations with instantiation, amongst other things: And how do I formulate polymorphism in Python? Example: class D1(Base): def foo(self): print D1 class D2(Base): def foo(self): print D2 obj = Base() # I want a base class reference which is polymorphic Well, here one actually gets a reference to a Base object. I know that in C++ or Java, you'd say, I don't care exactly what kind of Base-like object I have right now, but I want to be able to hold a reference to one. But in Python, this statement is redundant: names/variables potentially refer to objects of any type; one doesn't need to declare what type of objects a name will refer to. if (need D1): obj = D1() else: obj = D2() Without the above declaration, this will just work. If one needs an instance of D1, one will assign a new D1 object to obj; otherwise, one will assign a new D2 object to obj. Now, when one calls the foo method on obj, Python will just find whichever implementation of that method exists on obj and call it. In fact, when one does call the method, some time later in the program, the object held by obj doesn't even need to be instantiated from a related class: as long as the foo method exists, Python will attempt to invoke it, and this will even succeed if the arguments are compatible. All this is quite different to various other object-oriented languages because many of them use other mechanisms to find out whether such a method exists for any object referred to by the obj variable. With such languages, defining a base class with the foo method and defining subclasses with that method all helps the compiler to determine whether it is possible to find such a method on an object referred to by obj. Python bypasses most of that by doing a run-time check and actually looking at what methods are available just at the point in time a method is being called. I could as well leave the whole inheritance stuff out and the program would still work (?). Correct. Rewinding... Does inheritance in Python boil down to a mere code sharing? In Python, inheritance is arguably most useful for code sharing, yes. That said, things like mix-in classes show that this isn't as uninteresting as one might think. Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
Zeljko Vrba [EMAIL PROTECTED] wrote in news:[EMAIL PROTECTED]: On 2005-12-10, Tom Anderson [EMAIL PROTECTED] wrote: ED IS THE STANDARD TEXT EDITOR. And: INDENTATION SUCKS BIG TIME. Using indentation without block termination markers is opposite of the way we write spoken language, terminating each sentence with . Ever wondered why we use such things in written language, when people are much better in guessing what the writer wanted to say then computers? I believe I may have seen cases in written spoken language where paragraphs were indented, or otherwise separated with whitespace. It's even possible that I've seen some examples of written languages that use no periods at all! And what's more, I've seen more than one *computer* language that uses no terminating periods! Why, it boggles the mind. Despite the arguments advanced by those whose previous computer languages used braces and semicolons, there actually are more ways to separate complete statements than with punctuation. Make a grocery list. Do you terminate each item with punctuation? Write a headline for a newspaper. Is punctuation always included? Read a mediaeval manuscript. Do you find punctuation? Whitespace? How about Egyptian hieroglyphs, Chinese ideograms, Ogham runes? Because you're accustomed to one set of conventions, you may find Python's set strange at first. Please try it, and don't fight it. See if your objections don't fade away. If you're like most Python newbies, you'll stop thinking about brackets before long, and if you're like a lot of us, you'll wonder what those funny squiggles mean when you are forced to revert to one of those more primitive languages. -- rzed -- http://mail.python.org/mailman/listinfo/python-list
Re: OO in Python? ^^
Heiko Wundram wrote: Fredrik Lundh wrote: Matthias Kaeppler wrote: polymorphism seems to be missing in Python QOTW! Let's have some UQOTW: the un-quote of the week! ;-) +1 -- http://mail.python.org/mailman/listinfo/python-list
