🌐 Mailman 3 July 2008 - Python-list - python.org

Function editing with Vim throws IndentError
by ptn Aug. 4, 2008

Aug. 4, 2008

Hi everybody, I have a weird problem. Say I have a .py file with some functions in it, like this: # (...) def foo(): print("bar") When I open it and add a line to one of the functions, # (...) def foo(): troz = "bar" print(troz) I get the following traceback from the interpreter: Traceback (most recent call last): File "SOMEWHERE/example.py", line ?? troz = "bar" ^ IndentationError: unindent does not match any outer indentation level And so I'm forced to rewrite the function entirely just to add the new line. I thought that my problem was the w option from formatoptions, so I changed my .vimrc file to this: augroup filetype autocmd BufNewFile,BufRead *.txt set filetype=human augroup END autocmd FileType human setlocal formatoptions+=ta2w autocmd FileType lisp,scheme,python,c,java,vim setlocal formatoptions-=ta2w But the problem didn't go away. I don't think this has anything to do with the tabs and spaces, because I have them set up like this: set tabstop=4 shiftwidth=4 expandtab which is the standard way to handle them. The scripts I load are: qbuf, TagList, indent/python.vim and a reduced version of the standard python.vim Could someone provide some pointers? Thanks, Pablo Torres N.

7 14

Re: [unittest] Run setUp only once
by Nikolaus Rath Aug. 4, 2008

Aug. 4, 2008

Jean-Paul Calderone <exarkun(a)divmod.com> writes: > On Tue, 29 Jul 2008 19:26:09 +0200, Nikolaus Rath <nikolaus(a)rath.org> wrote: >>Jean-Paul Calderone <exarkun(a)divmod.com> writes: >>> On Tue, 29 Jul 2008 16:35:55 +0200, Nikolaus Rath <nikolaus(a)rath.org> wrote: >>>>Hello, >>>> >>>>I have a number of conceptually separate tests that nevertheless need >>>>a common, complicated and expensive setup. >>>> >>>>Unfortunately, unittest runs the setUp method once for each defined >>>>test, even if they're part of the same class as in >>>> >>>>class TwoTests(unittest.TestCase): >>>> def setUp(self): >>>> # do something very time consuming >>>> >>>> def testOneThing(self): >>>> >>>> >>>> def testADifferentThing(self): >>>> >>>> >>>>which would call setUp twice. >>>> >>>> >>>>Is there any way to avoid this, without packing all the unrelated >>>>tests into one big function? >>>> >>> >>> class TwoTests(unittest.TestCase): >>> setUpResult = None >>> >>> def setUp(self): >>> if self.setUpResult is None: >>> self.setUpResult = computeIt() >>> >>> ... >>> >>> There are plenty of variations on this pattern. >> >> >>But at least this variation doesn't work, because unittest apparently >>also creates two separate TwoTests instances for the two tests. Isn't >>there some way to convince unittest to reuse the same instance instead >>of trying to solve the problem in the test code itself? >> > > Eh sorry, you're right, the above is broken. `setUpResult` should be > a class attribute instead of an instance attribute. Yeah, well, I guess that would work. But to me this looks really more like a nasty hack.. isn't there a proper solution? Best, -Nikolaus -- »It is not worth an intelligent man's time to be in the majority. By definition, there are already enough people to do that.« -J.H. Hardy PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C

4 3

Re: A bug in difflib module? (find_longest_match)
by n00m Aug. 4, 2008

Aug. 4, 2008

Gabriel Genellina: > En Thu, 01 May 2008 04:35:17 -0300, n00m <n00m(a)narod.ru> escribi�: > > > from random import randint > > > > s1 = '' > > s2 = '' > > > > for i in xrange(1000): > > s1 += chr(randint(97,122)) > > s2 += chr(randint(97,122)) > > > > print s1[:25] > > print s2[:25] > > > > import difflib > > > > s = difflib.SequenceMatcher(None, s1, s2) > > > > print s.find_longest_match(0, len(s1), 0, len(s2)) > > > > > > > >>>> ============== RESTART ==================== > >>>> > > yymgzldocfaafcborxbpqyade > > urvwtnkwfmcduybjqmrleflqx > > (0, 0, 0) > >>>> > > > > I think it's line #314 in difflib "who's to blame" -- > > Me too. Could you think of some alternative? Simply disabling that > "popularity check" would slow down the algorithm, according to the > comments. > > -- > Gabriel Genellina No idea :)

3 2

Re: scanf in python
by AMD Aug. 3, 2008

Aug. 3, 2008

> AMD wrote: > >> I had seen this pure python implementation, but it is not as fast or >> as elegant as would be an implementation written in C directly within >> python with no need for import. > > maybe you should wait with disparaging comments about how Python is not > what you want it to be until you've learned the language? > > </F> > Hello Fredrik, I didn't think my comment would offend anyone, I'm sorry if it did. I have been developping in Python for about 5 years, my company uses Python as a scripting language for all of its products. We use Jython for our server products. I think I know it pretty well by now. So I think I have earned the right to try to suggest improvements to the language or at least intelligent discussion of new features without need for offensive comments, don't you think? André

3 2

Genetic programming: pygene, pygp, AST, or (gasp) Lisp?
by John Ladasky Aug. 3, 2008

Aug. 3, 2008

Hi folks, I've played around with neural nets for a while. I wrote my own slow, pure-Python NN package. I knew that there were Python NN packages out there -- but I couldn't really understand their features and documentation at first, not without some hands-on experience. I haven't yet solved any interesting problems with NN, but I learned a lot about both NN and about Python along the way. One of the unpleasant things I learned about NN was their propensity for becoming trapped in local minima. I also learned about overfitting, wasting many hours of CPU time in the process. In short, simple neural nets have disappointed me. I have now asked myself: wouldn't it be cool if, when you ceased to make progress on an optimization algorithm, you could divide your data set with an "if" statement, which would evolve a useful dividing line through your data set -- and then, develop divergent solutions to explain each subset better? In mathematical terms: Round 1 of evolutionary programming leads to a single, but sub-optimal solution, probably a solution in a local minimum: b = f(a) Round 2 would start by elaborating the solution of round 1, adding a condition that is initially meaningless: if disc(a) < c: b = f1(a) else: b = f2(a) Initially, f1() = f2() = the original f(). Therefore, the output of the starting state of round 2 will be identical to the output of the final state of round 1, regardless of the initial state of the discriminant function, disc(). But then, f1(), f2(), and disc() will all be permitted to evolve. This may provide a chance to "pop out" of the local minimum, without sacrificing any of the progress made in defining the solution of round 1. Of course, f(), f1(), f2(), and disc() could be complex functions. They would best be described with parse trees, which I've just discovered (I'm not formally trained in computer science). Some reading has led me to conclude that what I'm proposing is basically genetic programming. http://en.wikipedia.org/wiki/Genetic_programming I've tried my hand at this already in Python. I have devised a code tree class, which functions as a parse tree for functions and also handles multiple-line statements. I've tried cobbling together program strings from code trees, and then using the exec() function to run them. This is all very cool, but I'm finding it VERY cumbersome! As with neural nets, I know that there are genetic programming packages offered for Python: http://www.freenet.org.nz/python/pygene/ http://sourceforge.net/projects/pygp/ But I can't really understand what they do -- both of these packages are, alas, minimally documented. Is anyone out there using either of these? I can't tell whether they will implement algorithms of the type I've described here. Specifically, I don't know if conditional statements are included in their repertoire. Also, Pygene SEEMS to have a bent toward Boolean logic. I'm working with analog data, and I want complex, nonlinear functions. So, as with neural nets, shall I once again proceed on my own? There is apparently a layer in the Python interpreter at which code is represented as an abstract syntax tree (AST). http://docs.python.org/lib/ast.html Why not do genetic programming directly on Python code? Maybe my code tree data structure is redundant to something which already exists? But apparently Python's "_ast" module offers only one-way access -- it will generate an AST from a piece of code, but you can't modify an AST, and turn it back into executable code? I would definitely need this latter feature. ALTERNATELY -- and I don't mention this to start a flame war -- in pondering this problem I've noticed the frightening fact that Lisp seems set up to handle genetic programming by design. The s- expression syntax IS essentially a parse tree. Now, I've spent a few hours with Lisp so far, and I can't make it do much of anything -- but I DO see how Lisp could be helpful. Still, I'm reluctant to pursue a language I don't know, and which I'm finding much harder to grasp than any language I've tried before. Is there a way to interface Lisp to Python, so that I can do all the interface programming in the language I already know best -- and just do the genetic parts in Lisp? I haven't seen exception handling in Lisp, a feature I've come to love in Python. Since it is fairly easy for a randomly-generated program to generate illegal output (I already know this from my initial experiments in Python), I don't think I can live without exception handling. I also think that Python has a higher-level understanding of a variable's "type" or an object's "class" than Lisp does -- if I'm hacking at a parse tree and I want to minimize syntax errors, I need to know more than the fact that an element in an expression is an atom or a list. Producing human-readable code from my genetic programming search would be a great bonus -- and for me, at this moment, this seems to mean Algol-style syntax. (Sigh.) But it's not a requirement. Thanks for your advice!

7 7

Re: Attack a sacred Python Cow
by Bruno Desthuilliers Aug. 3, 2008

Aug. 3, 2008

Derek Martin a écrit : > On Sun, Jul 27, 2008 at 08:19:17AM +0000, Steven D'Aprano wrote: >>> You take the name down to a single letter. As I suggested in an earlier >>> post on this thread, why not take it down to zero letters? >> The question isn't "why not", but "why". The status quo works well as it >> is, even if it isn't perfect. Prove that implicit self is a good idea -- >> or at least prove that it is an idea worth considering. > > Come on, this sounds like a schoolyard argument. This comes down to a > matter of style, and as such, is impossible to prove. It's largely a > question of individual preference. > > That said, the argument in favor is rather simple: > > 1. This is an extremely common idiom in Python > 2. It is completely unnecessary, and the language does not suffer for > making it implicit > 3. Making it implicit reduces typing, reduces opportunities for > mistakes, and arguably increases consistency. "arguably", indeed, cf below. > As for the latter part of #3, self (or some other variable) is > required in the parameter list of object methods, It's actually the parameter list of the *function* that is used as the implementation of a method. Not quite the same thing. And then, consistency mandates that the target object of the method is part of the parameter list of the *function*, since that's how you make objects availables to a function. > however when the > method is *called*, it is omitted. Certainly not. You need to lookup the corresponding attribute *on a given object* to get the method. Whether you write some_object.some_method() or some_function(some_object) you still need to explicitely mention some_object. > It is implied, supplied by Python. Neither. The target object is passed to the function by the method object, which is itself returned by the __get__ method of function objects, which is one possible application of the more general descriptor protocol (the same protocol that is used for computed attributes). IOW, there's nothing specific to 'methods' here, just the use of two general features (functions and the descriptor protocol). FWIW, you can write your own callable, and write it so it behave just like a function here: import types class MyCallable(object): def __call__(self, obj): print "calling %s with %s" % (self, obj) def __get__(self, instance, cls): return types.MethodType(self.__call__, instance, cls) class Foo(object): bar = MyCallable() print Foo.bar f = Foo() f.bar() > Thus when an object method is called, it must be called with one fewer > arguments than those which are defined. This can be confusing, > especially to new programmers. This is confusing as long as you insist on saying that what you "def"ined is a method - which is not the case. > It can also be argued that it makes the code less ugly, though again, > that's a matter of preference. > >> It's not enough to show that a change "isn't bad" -- you have to show >> that it is actively good. > > But he did... he pointed out that *it saves work*, without actually > being bad. Benefit, without drawback. Sounds good to me! > >> "Don't need to look at the method signature" is not an argument in favour >> of implicit self. > > Yes, actually, it is. It isn't, since there's no "method signature" to look at !-) > If there is a well-defined feature of Python > which provides access to the object within itself, The point is that you don't get access to the object "within itself". You get access to an object *within a function*. The fact that a function is defined within a class statement doesn't imply any "magic", it just creates a function object, bind it to a name, and make that object an attribute of the class. You have the very same result by defining the function outside the class statement and binding it within the class statement, by defining the function outside the class and binding it to the class outside the class statement, by binding the name to a lambda within the class statement etc... > then the > opportunities for mistakes when someone decides to use something else > are lessened. > >> You don't need to look at the method signature when you're using an >> explicit self either. > > That isn't necessarily true. If you're using someone else's code, and > they didn't use "self" -- or worse yet, if they chose this variable's > name randomly throughout their classes -- then you may well need to > look back to see what was used. > > It's bad programming, but the world is full of bad programmers, and we > don't always have the choice not to use their code. Isn't one of > Python's goals to minimize opportunities for bad programming? Nope. That's Java's goal. Python's goals are to maximize opportunities for good programming, which is quite different. > Providing a keyword equivalent to self and removing the need to name > it in object methods is one way to do that. It's also a way to make Python more complicated than it needs to be. At least with the current state, you define your functions the same way regardless of how they are defined, and the implementation is (relatively) easy to explain. Special-casing functions definition that happens within a class statement would only introduce a special case. Then you'd have to explain why you need to specify the target object in the function's parameters when the function is defined outside the class but not when it's defined within the class. IOW : there's one arguably good reason to drop the target object from functions used as methods implementation, which is to make Python looks more like Java, and there's at least two good reason to keep it the way it is, which are simplicity (no special case) and consistency (no special case). Anyway, the BDFL has the final word, and it looks like he's not going to change anything here - but anyone is free to propose a PEP, isn't it ?

14 31

current week / weeks in year - best practice
by Aljosa Mohorovic Aug. 2, 2008

Aug. 2, 2008

i use this to find out current week and total number of weeks for current year: now = datetime.now() weeks_in_year = int(date(now.year, 12, 31).strftime("%W")) current_week = int(date(now.year, now.month, now.day).strftime("%W")) is this the best way or is there a better way? Aljosa Mohorovic

3 4

Re: Swap memory in Python ? - three questions
by John Nagle Aug. 2, 2008

Aug. 2, 2008

Robert LaMarca wrote: > Hi, > > I am using numpy and wish to create very large arrays. My system is AMD 64 > x 2 Ubuntu 8.04. Ubuntu should be 64 bit. I have 3gb RAM and a 15 GB swap > drive. Does a full 64-bit version of CPython, one where all pointers and sizes are 64 bits, even exist? John Nagle

2 1

How to request data from a lazily-created tree structure ?
by méchoui Aug. 2, 2008

Aug. 2, 2008

Problem: - You have tree structure (XML-like) that you don't want to create 100% in memory, because it just takes too long (for instance, you need a http request to request the information from a slow distant site). - But you want to be able to request data from it, such has "give me all nodes that are under a "//foo/bar" tree, and have a child with an "baz" attribute of value "zzz". Question : Do you have any other idea to request data from a lazily-created tree structure ? And does it make sense to create a DOM-like structure and to use a generic XPath engine to request the tree ? (and does this generic XPath engine exist ?) The idea is to have the tree structure created on the fly (we are in python), only when the XPath engine requests the data. Hopefully the XPath engine will not request all the data from the tree (if the request is smart enough and does not contain **, for instance). Thanks

2 8

Re: Change PC to Win or Windows
by Lie Aug. 2, 2008

Aug. 2, 2008

On Mon, 2008-07-21 at 16:45 -0400, Derek Martin wrote: > On Mon, Jul 21, 2008 at 12:32:00PM -0700, Lie wrote: > > > The term "PC" is commonly used in English, in the United States > > > and other English speaking countries, to mean a computer running > > > Microsoft Windows. > > > > As far as I am aware, they're like that because most people aren't > > even aware that there are other OSes than Microsoft Windows. > > You are missing two points. > > The first one: It doesn't matter what the reasons are for the > terminology to be common. It only matters that it IS common. It is; > and it is therefore "correct" in the sense that it conveys a meaning > to the overwhelming majority of English speakers, which is the > intended one. > True, it doesn't actually matters, but it is a proof that it is technically incorrect to apply PC JUST to Windows-based PC. It is arguable whether the term should only be exclusively to IBM-PC or whether the term should be expanded to include its clones. But I'm against on using it just to refer Windows-based PC exclusively, since it is neither Microsoft's marketing term nor a literal meaning conveyed in the term. > As for the question of whether or not it is appropriate to refer to > Windows installations as "PC", it's as simple as that. It is, by > definition (via common usage). That is what this thread is about. > Common usage isn't always correct. For example, a physicist would not use weight when he meant mass. Although in daily use he might not care much, but in technical environment doing so would embarrass him. In this analogy, I consider download page for a software source code to be a technical area. > The reason why the world hasn't evolved to the two predictable cases > > ("all kinds of microcomputers" or "IBM-PC and clones"), is what I'll > > explain below. > > Your explanation is irrelevant to the argument of whether or not the > term PC is an inappropriate term to describe a Windows installation, > which is what this thread is about. That is the premise put forth by > the OP, and that is the notion to which I am responding. It simply is > not wrong or inappropriate in any sense; it is in fact correct, > regardless of how the meaning or usage resulted, and regardless of any > ADDITIONAL meanings the term may have. > > For what it's worth, your explanation is also WRONG; the term PC > began to be popularly used in the United States to describe > Intel-based Microsoft machines when there was a proliferation of other > kinds of personal computers available to consumers. When it was first > used this way, the IBM PC was *NOT* the most popular personal computer... > the Commodore 64 was. > True, but PC is IBM's marketing term, thus it originally belongs to them. Nevertheless, it is NOT Window's marketing term and the literal meaning of Personal Computer is in no way means Windows-based computers ONLY. > It dates from a time when the Commodore VIC-20 > and C64, Atari 400 and 800, Timex Sinclair, and other computers were > all very popluar home machines. But they aren't called PC, why? Because IBM hasn't invented the term. Nowadays, they might be called as PC or not depending on which side are you in: "PC as IBM-PC" or "PC as personal computer" (note the lower case) > The term probably originated primarily because IBM chose to name their > computer the IBM PC, and because of Americans' predeliction to > abbreviate everything that's more than 2 syllables. ;-) > > > > It wasn't something that Apple started; it's been used this way > > > in increasingly common usage for at least 20 years, although > > > exactly what combination of hardware and software was being > > > refered to as a "PC" has evolved over that timeframe. > > > > Apple popularizes the term by explicit marketing, > > And here is the last point you are missing: Apple does no such > thing. They did, by using the term PC to refer to other computers. IF they have used the term "Regular PC", noone would have complained, it's just like an apple farmer advertising his "Super Apples" and calls other apples "Regular Apples", there would be nothing wrong about it. But there is this specific apple farmer who advertised his apple as "Orange" and calls other apples as "Apples", which makes a problem since "Orange" is just a different variants of apple, and is still an apple. This kind of advertising Apple (the computer company) used is misleading, since it implied that their PC is not a PC. > They are only using a term in a way that has previously been > popularized by the computer industry as a whole, and its market (i.e. > consumers, predominantly American consumers historically) for > *DECADES*. > If I'm not mistaken, their ad campaign mentioning PCs is > less than 10 years old (though I can't quickly find any references as > to the date). The popularization of the term PC to refer to > Intel-compatible machines running Microsoft OSes PREDATES APPLE'S AD > CAMPAIGN BY OVER 10 YEARS. When did I say that Apple was the first one to start the term's misuse? Apple's is only making the term's misuse more widespread, nevertheless they might be the largest computer company that tried to _actively_ spread its misuse by persistently using the term in their ads in that manner. But even without Apple, yes, it is true that the misuse would still get widespread, simply because of Microsoft's dominance. > Therefore none of your points are valid or relevant, as to the > question of whether the usage of the term "PC" to describe windows > builds of Python is appropriate. > Because you are missing all the points. > Can we return to the subject of Python now? yes, in short, don't use PCBuild to refer Windows-only build. PCBuild should contain a universal build that is compatible with all platforms a PC is usually based on (i.e. it shouldn't exist except if such thing is possible).

3 3